initiation Communication
project requirement gathering
Planning
estimating scheduling tracking
Modeling
analysis design
Construction
code test
Deployment
delivery support f eedback
Classic waterfall approach above Problems Real projects rarely follow the sequential flow that the model proposes. Difficult for the customer to state all requirements explicitly before the next step. A working version will not be available until late in the project time-span. Some project team members must wait for other members of the team to complete dependent tasks. Variation of the classic waterfall model.
increment #n
Communi c at ion Planning Modeling analys is design C o n s t ru c t i o n code t est De pl o y me n t d e l i v e ry feedbac k
increment # 2
Co mmuni c at i on Pl an ning M odeling analys is des ign C o n s t ru c t i o n code t es t De p l o y m e n t d e l i v e ry fe e d b a c k
delivery of nth increment
increment # 1
Communi c at i on Pl an ni ng Mode ling analys is des ign C o n s t ru c t i o n code t est De p l o y m e n t d e l i v e ry fe e d b a c k
delivery of 2nd increment
delivery of 1st increment
project calendar time
The incremental model RAD model.
Team # n
Mo d e lin g
business modeling data modeling process modeling
C o n st ru ct io n
Communication
Team # 2
Modeling
business modeling dat a modeling process modeling
component reuse automatic code generation testing
Planning Team # 1 Modeling
business modeling data modeling process modeling Construction
component reuse aut omat ic code generat ion test ing
Deployment
integration delivery feedback
Construction
component reuse automatic code generation testing
60 - 90 days
Drawbacks It requires sufficient human resources to create the right number of RAD teams If developers and customers are not committed to the rapid-fire activities necessary to complete the system in a time frame, it will fail. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. If high performance is an issue, and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work. RAD may not be appropriate when technical risks are high.
e.g., when a new application makes heavy use of new technology. Evolutionary model of prototyping. Problems The customer tend to be unaware that we have not considered Communication overall software quality or long-term maintainability. The developer makes implementation compromises in order to get a prototype working inappropriate OS, programming language, inefficient algorithms. It should be used to define requirements, then discarded.
Quick plan Modeling Quick design
Deployment Delivery & Feedback
Construction of prototype
Spiral approach: The 1st circuit might result in the development of a product specification. The 2nd pass might be used to develop a prototype .more sophisticated versions of software Cost and schedule are adjusted based on feedback from the
customer for each pass. It can remain operative until the software is retired. Difficult to convince customers that the evolutionary approach is controllable.
Elaboration Inception
Unified Process Model, dev by IBM.
construction
Release
software increment
transition
production
UP Phases
Inception Elaboration Construction Transition Production
Workflows Requirements Analysis Design Implementation Test Support Iterations #1 #2 #n-1 #n
Perspective Process Models: Linear, Incremental, Evolutionary 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 After the first increment project velocity is used to help define subsequent delivery dates for other increments XP Design Follows the Keep it Simple (KIS) principle Encourage the use of CRC cards (see Chapter 8) For difficult design problems, suggests the creation of spike solutionsa design prototype Encourages refactoringan iterative refinement of the internal program design XP Coding
Recommends the construction of a unit test for a store before coding commences Encourages pair programming Collective ownership Sustainable pace
Structures analysis considers data and the processes that transform the data as separate entities. Data objects are modeled in a way that defines their attributes and relationships.
system analysis description
Object-Oriented focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements. UML and the Unified Process (chap3) are predominantly object oriented. Figure 8.3, page 180
analysis model design model
Arms/ disarms system
Accesses system via Internet homeowner
sensors
Boundary Classes:
Responds to alarm event
serves as an interface environment
between the system and its
Encounters an error condition
reduces communication other classes interface communication) helps boundary class interface changes)
system administrator
Reconfigures sensors and related system features
complexity (minimizes and coordination between and the actors by providing an neutral form of maintainability (normally only will need to change when
types of boundary classes include: user interfaces (one boundary class per window) other system interfaces device interfaces Entity Classes entity classes are independent of the systems interfaces correspond to real-world entities that the system manipulates Control Classes:
responsible for coordinating boundary and entity classes receives or handles system events often one control class per use case control classes encapsulate behavior of use case
control object is created at beginning of use case and is destroyed at the end of the use case this means persistence must be considered when use cases can span a single execution of the system control classes implement the Controller Pattern uml notation + public private # protected Identifying classes: Structures External systems Devices Roles Operating procedures Places Organizations Things that are manipulated by the system to be built Analysis Classes
External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. Organizational units (e.g., division, group, team) that are relevant to an application.
Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system.
Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects. Clarifying Class Relationships: in order for an object to communicate with another object, it must have visibility to it class relationships can be: structural association aggregation composition generalization non-structural (dependency) Association One calls the other. Composition A consists of B. If A is removed, then so is B. B cannot exist without being associated with A. Em pl o y e e Aggregation B can exist without being associated h o u rsW o rk e d : u n de fi n e d pa y Rate : u n de fi n e d with A. A contains B. ca l cu l a te Pay () Generalization/Inheritance is-a-kind-of relationship GENERALIZATION/INHERITANCE------------------ S a l e s Pe rs o n Association (solid com m i ss i o n : u n de fi n e d line) cal cu l ate Pa y () Client object has link to Server object usually via an attribute Dependency (dashed line) Client object does not have intrinsic knowledge of the Server object It must be told where object is located
a
Server object is often passed as a parameter Multiplicity:
Wall
1 is used to build 1..*
WallSegment Window
1
1 is used to build
0..* is used to build
Door
0..*
Three major steps in risk management 1. Identify risks 2. Analyze risks 3. Planning risks
Class/object role -- it represents the roles the object plays. Lifeline it represents the existence of an object over a period of time Activation the time during which an object is performing an operation. Method invocation communication between objects. Solid-line arrow = synchronous Dashed-line arrow = asynchronous message syntax can follow either the UML standard syntax or that of a programming language UML standard syntax: [Guard] message (parameter)
:Billing
:Price
:Billing
: Price
[quantity > 10] discount
*[i:=1..N]: obtainItemPrice
Conditional, message iteration.