Software LifeCycle Models

1
Software Life-Cycle Models

• MSIT 182 Software Engineering
• Lecture 3

2
Software Life-cycle models

• Life-cycle model (formerly, process model)
• The steps through which the product progresses
• Requirements phase
• Specification phase
• Design phase
• Implementation phase
• Integration phase
• Maintenance phase
• Retirement

3
Software life-cycle models

• Build-and-fix model
• Waterfall model
• Separate and distinct phases of specification and
  development
• Evolutionary (Rapid prototyping) model
• Specification and development are interleaved
• Formal systems development
• A mathematical system model is formally
  transformed to an implementation

4
Software life-cycle models (contd)

• Incremental model
• Spiral model
• Extreme programming
• Synchronize-and-stabilize model
• Object-oriented life-cycle models
• Reuse-based development
• The system is assembled from existing components
• Comparison of life-cycle models

5
Build and Fix Model

• Problems
• No specifications
• No design
• Totally unsatisfactory
• Need a life-cycle model
• Game plan
• Phases
• Milestones

6
Waterfall Model

• Characterized by
• Feedback loops
• Documentation-driven
• Advantages
• Documentation
• Maintenance easier
• Disadvantages
• Specification document

7
Waterfall Model Phases
8
Waterfall model problems

• Inflexible partitioning of the project into
  distinct stages
• This makes it difficult to respond to changing
  customer requirements
• The drawback of the waterfall model is the
  difficulty of accommodating change after the
  process is underway
• Therefore, this model is only appropriate when
  the requirements are well-understood

9
Evolutionary development

• Exploratory development
• Objective is to work with customers and to evolve
  a final system from an initial outline
  specification. Should start with well-understood
  requirements

• Throw-away (rapid) prototyping
• Objective is to understand the system
  requirements. Should start with poorly understood
  requirements

10
Rapid Prototyping Model

• Linear model
• Rapid

11
Evolutionary development

• Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid
  prototyping) may be required
• Applicability
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
  interface)
• For short-lifetime systems

12
Three Key Points

• Do not turn the rapid prototype into the product
• Rapid prototyping may replace the specification
  phasenever the design phase
• Comparison
• Waterfall modeltry to get it right the first
  time
• Rapid prototypingfrequent change, then discard

13
Waterfall and Rapid Prototyping Models

• Waterfall model
• Many successes
• Clients needs
• Rapid prototyping model
• Not proved
• Has its own problems
• Solution
• Rapid prototyping for the requirements phase
• Waterfall model for the rest of the life cycle

14
Formal systems development

• Based on the transformation of a mathematical
  specification through different representations
  to an executable program
• Transformations are correctness-preserving so
  it is straightforward to show that the program
  conforms to its specification
• Embodied in the Cleanroom approach to software
  development

15
Formal systems development
16
Formal transformations
17
Formal systems development

• Problems
• Need for specialised skills and training to apply
  the technique
• Difficult to formally specify some aspects of the
  system such as the user interface
• Applicability
• Critical systems especially those where a safety
  or security case must be made before the system
  is put into operation

18
Process iteration

• System requirements ALWAYS evolve in the course
  of a project so process iteration where earlier
  stages are reworked is always part of the process
  for large systems
• Iteration can be applied to any of the life-cycle
  models
• Two (related) approaches
• Incremental development
• Spiral development

19
Incremental development

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality
• User requirements are prioritised and the highest
  priority requirements are included in early
  increments
• Once the development of an increment is started,
  the requirements are frozen though requirements
  for later increments can continue to evolve

20
Incremental Model

• Divide project into builds

• Problems
• Build-and-fix danger
• Contradiction in terms

21
Incremental development
22
Incremental development advantages

• Customer value can be delivered with each
  increment so system functionality is available
  earlier
• Early increments act as a prototype to help
  elicit requirements for later increments
• Lower risk of overall project failure
• The highest priority system services tend to
  receive the most testing

23
Incremental Model (contd)

• Waterfall, rapid prototyping models
• Operational quality complete product at end
• Incremental model
• Operational quality portion of product within
  weeks
• Less traumatic
• Smaller capital outlay, rapid return on
  investment
• Need open architecturemaintenance implications
• Variations used in object-oriented life cycle

24
Spiral development

• Process is represented as a spiral rather than as
  a sequence of activities with backtracking
• Each loop in the spiral represents a phase in the
  process.
• No fixed phases such as specification or design -
  loops in the spiral are chosen depending on what
  is required
• Risks are explicitly assessed and resolved
  throughout the process

25
Spiral Model

• Simplified form
• Waterfall model plus risk analysis preceding each
  phase

• Key point
• If all risks cannot be resolved, the project is
  immediately terminated

26
Simplified Spiral Model

• View of spiral

27
Spiral model sectors

• Objective setting
• Specific objectives for the phase are identified
• Risk assessment and reduction
• Risks are assessed and activities put in place to
  reduce the key risks
• Development and validation
• A development model for the system is chosen
  which can be any of the generic models
• Planning
• The project is reviewed and the next phase of the
  spiral is planned

28
Full Spiral Model

• Analysis
• Strengths
• It is easy to judge how much to test
• No distinction is made between development,
  maintenance
• Weaknesses
• For large-scale software only
• For internal (in-house) software only

• Precede each phase by
• Alternatives
• Risk analysis
• Follow each phase by
• Evaluation
• Planning of next phase
• Radial dimension cumulative cost to date
• Angular dimension progress through the spiral

29
Full Spiral Model (contd)
30
Extreme programming (XP)

• New approach to development based on the
  development and delivery of very small increments
  of functionality
• Relies on constant code improvement, user
  involvement in the development team and pairwise
  programming
• Somewhat controversial new approach
• Stories (features client wants)
• Estimate duration and cost of each story
• Select stories for next build
• Each build is divided into tasks
• Test cases for a task are drawn up first
• Pair programming
• Continuous integration of tasks

31
Unusual Features of XP

• Computers are put in the center of a large room
  lined with cubicles
• A client representative is always present
• Cannot work overtime for 2 successive weeks
• No specialization
• Refactoring
• XP has had some successes
• Good when requirements are vague or changing
• Too soon to evaluate extreme programming

32
Synchronize-and Stabilize Model

• Microsofts life-cycle model
• Requirements analysisinterview potential
  customers
• Draw up specifications
• Divide project into 3 or 4 builds
• Each build is carried out by small teams working
  in parallel
• At the end of the daysynchronize (test and
  debug)
• At the end of the buildstabilize (freeze build)
• Components always work together
• Get early insights into the operation of the
  product

33
Object-Oriented Life-Cycle Models

• Need for iteration within and between phases
• Fountain model
• Recursive/parallel life cycle
• Round-trip gestalt
• Unified software development process
• All incorporate some form of
• Iteration
• Parallelism
• Incremental development

34
Fountain Model

• Overlap (parallelism)
• Arrows (iteration)
• Smaller maintenance circle

35
Reuse-oriented development

• Based on systematic reuse where systems are
  integrated from existing components or COTS
  (Commercial-off-the-shelf) systems
• Phases

• This approach is becoming more important but
  still limited experience with it

36
Conclusions

• Different life-cycle models
• Each with its own strengths
• Each with its own weaknesses
• Criteria for deciding on a model include
• The organization
• Its management
• Skills of the employees
• The nature of the product
• Best suggestion
• Mix-and-match life-cycle model