 Life cycle model

 Need for Life cycle model

 Different life cycle models
 Classical waterfall model
 Prototype model
 Spiral model
 Life Cycle: A recognizable work phase pattern
that delivers well defined products
 Product Life Cycles: An activity pattern occurs
over the useful life of a product
 Versions: enhances functionality or quality
 Variations: different domains
 Project Life cycles: The collection of activities
that occurs over the life of a project to
produce a single release of a product
 is a descriptive and diagrammatic
representation of the software life cycle

 It maps the different activities perform on a

software product from its inception to
retirement
 Development team must identify a suitable
life cycle model
 Without any model, product would not be in
a systematic and disciplined manner
 Life cycle model defines entry and exit
criteria for every phase
 Without LCMs it would be very difficult to
monitor the progress of a project
 Waterfall Model
 Prototyping Model
 Evolutionary Model
 Spiral Model
 1970 ： Waterfall model (Royce)
 This model is considered as a theoretical way
of developing software
 This model is base for all other models
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
 Is an idealistic one – no development error
has ever committed by engineers
 All requirements must be known upfront
 Integration is one big task at the end
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Requirements are very well known
 Product definition is stable
 No significant risks
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
 1977 ： Prototyping model(Bally and others)
 Toy implementation of the system
 Customers are non-technical and usually
don’t know what they want/can have
 By implementing dummy functions
 If you want to develop a good product you
must plan for 1st version
 Better understanding of the customer needs
 How the screens might look like
 How the user interface would behave
 How the system would produce outputs
 If the technical solutions are unclear to the
development team
 When to choose prototype:
 User requirements are not complete
 Technical issues are not clear
 1988 ： Spiral model(Boehm)
 It includes the iterative nature of the
prototyping model and the linear nature of
the waterfall model
 Developing software that is revealed in
various versions
 At the end of 1st iteration, customer evaluates
the product and provide feedback
 Iteration continues throughout the life of the
software
 Requirements:
 Not well understood
 Unstable

 For medium to high-risk projects

 Functional and some non-function quality attributes are very important

 New product line

 Cost and time pressure is less important

Determine Evaluate
objectives, alternatives,
alternatives, identify and
constraints resolve risks

Plan next Develop verify

phases next level
product
 Objectives: functionality, performance,
hardware/software interface, critical success factors,
etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
 Study alternatives related to objectives and
constraints
 Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by
continuing system development
 Typical activities:

 Create a design
 Review design
 Develop code
 Inspect code
 Test product
 Typical activities
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
 Develop project plan
 Provides early indication to overcome the risks without much cost

 User can see the system early because of rapid prototyping tools

 Critical high-risk functions are developed first

 The design does not have to be perfect

 Users can be closely tied to all lifecycle steps

 Early and frequent feedback from users

 Cumulative costs assessed frequently

 Time spent for evaluating risks too large for small or low-risk projects

 Time spent for planning, resetting objectives, doing risk analysis and
prototyping may be excessive

 The model is complex

 Risk assessment expertise is required

 Spiral may continue indefinitely

 Developers must be reassigned during non-development phase activities