285 - Processes Mid

http://www.openloop.com/education/classes/umn_98/umn_cpp/crc.htm​

Agile / Scrum

  • Daily stand ups in the morning
  • Sprint Demo and Planning every two weeks

Kanban

  • Start with what you do now
  • Agree to pursue incremental, evolutionary change
  • Respect the current process, roles, responsibilities and titles
  • Leadership at all levels

Task Set

  • A list of the task to be accomplished
  • A list of the work products to be produced
  • A list of the quality assurance filters to be applied

Process Patterns

a consistent method for describing problem solutions within the context of the software process.

  • Stage patterns—(depicting the steps that need to be done in order to perform a stage of the process)defines a problem associated with a framework activity for the process.
  • Task patterns—( detailed steps to execute a specific task of the process.)defines a problem associated with a software engineering action or work task **and relevant to successful software engineering practice
  • Phase patterns—(depicting the interaction of two or more stage process patterns in order to execute the phase)define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

Prescriptive Models

  • The Waterfall Model
  • The V-Model
  • The Incremental Model
  • Prototyping
  • The Spiral
  • Concurrent
  • The Unified Process (UP)

Personal Software Process

  • Planning
  • High-level design
  • High-level design review
  • Development
  • Postmortem

Agile Development

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agility

  • Effective (rapid and adaptive) response to change
  • Effective communication among all stakeholders
  • Drawing the customer onto the team
  • Organizing a team so that it is in control of the work performed

/////An Agile Process

  • Is driven by customer descriptions of what is required (scenarios)
  • Recognizes that plans are short-lived
  • Develops software iteratively with a heavy emphasis on construction activities
  • Delivers multiple ‘software increments’
  • Adapts as changes occur

Human Factors

  • competence
  • common focus
  • collaboration
  • decision-making ability
  • self-organization

Extreme Programming (XP)

  • Planning
    • Begins with the creation of “user stories”
    • Agile team assesses each story and assigns a cost
    • Stories are grouped to for a deliverable increment
    • A commitment is made on delivery date
  • Design
    • Encourage the use of CRC cards
    • Encourages “refactoring”—an iterative refinement of the internal program design
  • Coding
    • Encourages “pair programming”
    • Recommends the construction of a unit test for a store before coding commences
  • Test
    • All unit tests are executed daily
    • “Acceptance tests” are defined by the customer

Adaptive Software Development

  • Mission-driven planning
  • Component-based focus
  • Uses “time-boxing”
  • Explicit consideration of risks
  • Emphasizes collaboration for requirements gathering
  • Emphasizes “learning” throughout the process

Dynamic Systems Development Method

  • All changes during development are reversible.
  • Requirements are baselined at a high level
  • Testing is integrated throughout the life-cycle.

Scrum

  • Testing and documentation are on-going as the product is constructed
  • Work occurs in “sprints” and is derived from a “backlog” of existing requirements
  • Meetings are very short and sometimes conducted without chairs

Crystal

  • Face-to-face communication
  • Suggests the use of “reflection workshops” to review the work habits of the team

Feature Driven Development

  • Emphasis is on defining “features” and it is a client-valued function
  • Uses a feature template
  • A features list is created and “plan by feature” is conducted

Agile Modeling

  • Model with a purpose
  • Use multiple models
  • Travel light
  • Content is more important than representation
  • Adapt locally

Principles

Principles that Guide Process

  • Be agile : Whether the process model you choose is prescriptive or agile, the basic tenets of agile development should govern your approach.
  • Focus on quality at every step : focus on the quality of the work product that has been produced
  • Be ready to adapt : When necessary, adapt your approach to constraints imposed by the problem, the people, and the project itself
  • Build an effective team : Build a self-organizing team that has mutual trust and respect.

Principles that Guide Practice

  • Divide and conquer : analysis and design should always emphasize separation of concern
  • understand the use of abstraction : an abstraction is a simplification of some complex element of a system used to communication meaning in a single phrase
  • Strive for consistency : A familiar context makes software easier to use
  • Focus on the transfer of information : Pay special attention to the analysis, design, construction, and testing of interfaces
  • Look for patterns : create a body of literature to help software developers resolve recurring problems

Communication Principles

  • Listen : focus on the speaker’s words
  • Prepare before you communicate : Spend the time to understand the problem before you meet with others
  • Face-to-face communication is best : when some other representation of the relevant information is present.

Planning Principles

  • Understand the scope of the project : Scope provides the software team with a destination
  • Involve the customer in the planning activity : The customer defines priorities and establishes project constraints.
  • Be realistic : People don’t work 100 percent of every day.

Modeling Principles

  • Requirements models : represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain.
    • The information domain of a problem must be represented and understood.
    • The functions that the software performs must be defined.
    • The behavior of the software must be represented.
  • Design models : represent characteristics of the software that help practitioners to construct it effectively
    • Design should be traceable to the requirements model.
    • Always consider the architecture of the system to be built.
    • Design of data is as important as design of processing functions.

Agile Modeling Principles

  • The primary goal of the software team is to build software, not create models.
  • Travel light—don’t create more models than you need.
  • Strive to produce the simplest model that will describe the problem or the software.

Construction Principles

  • Coding principles and concepts are closely aligned programming style, programming languages, and programming methods.
  • Testing principles and concepts lead to the design of tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort.

////Preparation Principles

  • Understand of the problem you’re trying to solve.
  • Understand basic design principles and concepts
  • Pick a programming language that meets the needs

////Coding Principles

  • Consider the use of pair programming
  • Select data structures that will meet the needs of the design.
  • Understand the software architecture and create interfaces that are consistent with it.

////Validation Principles

  • Conduct a code walkthrough when appropriate.
  • Perform unit tests and correct errors you’ve uncovered.
  • Refactor the code.

Testing Principles

  • All tests should be traceable to customer requirements.
  • Tests should be planned long before testing begins.
  • Exhaustive testing is not possible.
  • Testing should begin “in the small” and progress toward testing “in the large.

Deployment Principles

  • Customer expectations for the software must be managed.
  • A complete delivery package should be assembled and tested.
  • Buggy software should be fixed first, delivered later.
  • Appropriate instructional materials must be provided to end-users.

Requirement

Requirements Engineering

  • Inception : Recognize multiple points of view
  • Elicitation :
    • to identify the problem
    • propose elements of the solution
    • negotiate different approaches
    • specify a preliminary set of solution requirements
  • Elaboration : create an analysis model that identifies data, function and behavioral requirements
  • Negotiation : agree on a deliverable system that is realistic for developers and customers

Quality Function Deployment

  • Function deployment : determine the values of each function
  • Information deployment : identifies data objects and events
  • Task deployment : examine the behavior of system
  • Value analysis : determine the relative priority of requirement

Building the Analysis Model

  • Scenario-based elements : Use-case —descriptions of the interaction between an “actor” and the system
  • Class-based elements
  • Behavioral elements : State diagram
  • Flow-oriented elements : Data flow diagram

Negotiating Requirements

  • Identify the key stakeholders
  • Determine each of the stakeholders “win conditions”
  • Negotiate

Requirements Modeling

The bridge between system description and design model

Scenario-Based Modeling

  • Inception and elicitation
  • Requirements gathering meetings
  • list the functions or activities performed by a specific actor

Domain Analysis : Define the domain to be investigated, Collect a representative sample of applications in the domain.

  • Uses-case Diagram
    • actors represent roles people or devices play as the system functions
    • users can play a number of different roles for a given scenario
  • Activity Diagram
  • Swimlane diagram

Data Modeling: examines data objects independently of processing, focuses attention on the data domain

  • Data Object : a representation of almost any composite information that must be understood by software. can be a thing, external entity, a role and event
  • Attributes : as an aspect, quality, characteristic, or descriptor of the object
  • Relationship : Data objects are connected to one another in different ways.

Class-Based Modeling :

CRC Models:

Class-responsibility-collaborator (CRC)

  • Class : name of the classes
  • responsibilities : attributes and operations that are relevant for the class
  • collaborator: relationships between classes

Associations and Dependencies

Two analysis classes are often related to one another in some fashion

  • In UML these relationships are called associations.
  • Associations can be refined by indicating multiplicity

Design Concepts

Good software design should exhibit:

  • Firmness: A program should not have any bugs that inhibit its function.
  • Commodity: A program should be suitable for the purposes for which it was intended.
  • Delight: The experience of using the program should be pleasurable one.

Design and Quality

  • the design must implement all of the explicit requirements
  • the design must be a readable, understandable guide
  • the design should provide a complete picture of the software

Quality Guidelines

  • A design should exhibit an architecture
  • A design should be modular
  • A design should contain distinct representations

Fundamental Concepts

  • Abstraction—data, procedure, control
  • Architecture—the overall structure of the software
    • Structural properties.
    • Extra-functional properties
    • Families of related System
  • Patterns—”conveys the essence” of a proven design solution
    • Pattern name
    • Intent
    • Structure
    • Motivation
    • Applicability
    • Consequences
  • Separation of concerns—any complex problem can be more easily handled if it is subdivided into pieces
    • A concern is a feature or behavior that is specified as part of the requirements model for the software
    • modularity is the single attribute of software that allows a program to be intellectually manageable
    • module development cost = module integration cost
  • Hiding—controlled interfaces
  • Functional independence—single-minded function and low coupling
    • cohesion : indicates the relative functional strength of a module
    • coupling : indicates the relative independence among modules
  • Refinement—elaboration of detail for all abstractions
  • Aspects—cross-cutting concern
  • Refactoring— Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code and improves s internal structure.
    • redundancy
    • unused design elements
    • inefficient or unnecessary algorithms
  • OO design concepts—Design classes, inheritance, messages, polymorphism
  • Design Classes—provide design detail that will enable analysis classes to be implemented
    • entity classes
    • boundary classes
    • controller classes

Design Model Elements

  • Data elements
  • Architectural elements
  • Interface elements
  • Component elements
  • Deployment elements

Architectural Elements

  • information about the application domain
  • specific requirements model elements
  • the availability of architectural patterns and styles

User Interface Design

Golden Rules:

  • Place the user in control
  • Reduce the user’s memory load
  • Make the interface consistent

User Interface Design Models

  • User model — a profile of all end users of the system
  • Design model — a design realization of the user model
  • Mental model (system perception) — the user’s mental image of what the interface is
  • Implementation model — the interface “look and feel” coupled with supporting information that describe interface syntax and semantic

User Interface Design Process

interface analysis and modeling -> interface design -> interface construction -> interface validation

Task Analysis and Modeling

  • Use-cases define basic interaction
  • Task elaboration refines interactive tasks
  • Object elaboration identifies interface objects (classes)
  • Workflow analysis defines how a work process is completed when several people (and roles) are involved

Interface Design Steps

  1. define interface objects and actions
  2. define events
  3. depict each interface state
  4. Indicate how the user interprets the state of the system

Effective WebApp Interfaces

  • Effective interfaces are visually apparent and forgiving
  • Effective interfaces do not concern the user with the inner workings of the system
  • Effective applications and services perform a maximum of work

WebApp Interface Design

  • Where am I?
  • What can I do now?
  • Where have I been, where am I going?

Interface Design Principles

  • Anticipation
  • Communication
  • Consistency
  • Efficiency
  • Latency reduction

Previous test

Backlog is a prioritized feature list containing feature or subtasks that needed to be done, scrum master will update it

Non-generative patterns : it describes a context and a problem but it does not provide any clear-cut solution.
Generative patterns : describes an important and repeatable aspect of a system and that provides us with a way to build that aspect within a system of forces

Python

  • All three sequence types (tuples, strings, and lists) share much of the same syntax and functionality.
  • Key difference:
    • Tuples and strings are immutable
    • Lists are mutable

>>> t = (23, ‘abc’, 4.56, (2,3), ‘def’)

Return a copy of the container with a subset of the original members. Start copying at the first index, and stop copying before the second index.

>>> t[1:4] (‘abc’, 4.56, (2,3))

Tuples: Immutable

>>> t = (23, ‘abc’, 4.56, (2,3), ‘def’)
>>> t[2] = 3.14

Traceback (most recent call last): File "", line 1, in -toplevel- tu[2] = 3.14 TypeError: object doesn't support item assignment

+, append extend opertator

The + operator produces a new tuple, list, or string whose value is the concatenation of its arguments. 

>>> (1, 2, 3) + (4, 5, 6)
 (1, 2, 3, 4, 5, 6)
>>> [1, 2, 3] + [4, 5, 6]
 [1, 2, 3, 4, 5, 6]
>>> “Hello” + “ ” + “World”
 ‘Hello World’

The * operator produces a new tuple, list, or string that “repeats” the original content.

>>> (1, 2, 3) * 3
(1, 2, 3, 1, 2, 3, 1, 2, 3)
>>> [1, 2, 3] * 3
[1, 2, 3, 1, 2, 3, 1, 2, 3]
>>> “Hello” * 3
‘HelloHelloHello’

Confusing:

  • Extend takes a list as an argument.
  • Append takes a singleton as an argument.
>>> li.extend([9, 8, 7]) 
>>> li [1, 2, ‘i’, 3, 4, 5, ‘a’, 9, 8, 7]

>>> li.append([10, 11, 12]) 
>>> li [1, 2, ‘i’, 3, 4, 5, ‘a’, 9, 8, 7, [10, 11, 12]]

Tuples vs. Lists

  • Lists slower but more powerful than tuples.
  • Lists can be modified, and they have lots of handy operations we can perform on them.
  • Tuples are immutable and have fewer features.
  • To convert between tuples and lists use the list() and tuple() functions: li = list(tu) tu = tuple(li)

results matching ""

    No results matching ""