ObjectOriented and Classical Software Engineering Fifth Edition, WCBMcGrawHill, 2002 Stephen R' Scha

1
Object-Oriented and Classical Software
Engineering Fifth Edition, WCB/McGraw-Hill,
2002Stephen R. Schachsrs_at_vuse.vanderbilt.edu
2
CHAPTER 3
SOFTWARE LIFE-CYCLE MODELS
3
Overview

• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Extreme programming
• Synchronize-and-stabilize model
• Spiral model
• Object-oriented life-cycle models
• Comparison of life-cycle models

4
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

5
Build and Fix Model

• Problems
• No specifications
• No design
• Totally unsatisfactory expensive since it
  changes code after it is produced! Plus no
  documentation done!
• Need life-cycle model
• Game plan
• Phases
• Milestones

6
Waterfall Model

• Requirements determined by client SQA group
• Specs drawn up. Checked by SQA. Client signs.
• Draw up software project management plan
  (detailed timetable for developing software).
  Plan checked by SQA. Client approves time and
  cost estimates.
• Design phase begins.
• may find incomplete, contrary, or ambiguous
  specs.
• Then feed back to step 2.
• client must approve new specs
• Program.
• may find design flaws too slow, etc.
• feed back to step 4 or steps 1, 2
• integrate code as modules are finished

7
Waterfall Model

• Testing.
• client does acceptance testing
• deliverables include user manual and other
  documents
• Installation.
• Now in maintenance phase
• Maintenance may require changes in specs.
• May require changes in documents

8
Waterfall Model

• Characterized by
• Feedback loops
• Documentation-driven (no phase is done until docs
  are done!)
• Advantages
• Documentation is enforced
• Every deliverable checked by SQA
• Testing done in every phase
• Maintenance easier

9
Waterfall Model (cont)

• Disadvantages
• Specifications
• Joe and Jane Johnson build house. Architect
  gives 20 page specification document. Joe and
  Jane sign, but dont understand.
• This is exactly what software specs are like.

10
Waterfall Model (cont)

• Disadvantages
• Specifications
• Mark Marberry buys suit by mail. Does not get
  photos, but a written description. Mark buys
  based on the written description.
• In same way client rarely sees software until it
  is finished in waterfall model
• Note that using flowcharts doesnt help visualize
  what the final software will do.

11
Rapid Prototyping Model

• A rapid prototype is a working model functionally
  equivalent to a subset of the product.
• if product is an accounting system, prototype
  might only be the screens and report printing,
  but not DB connectivity.
• First step in model is to develop rapid
  prototype.
• When client accepts prototype, specs are drawn up.

12
Rapid Prototyping Model

• Linear model
• less need for feedback
• working prototype has been verified by client, so
  specs more likely correct.
• many design problems have already been
  identified.
• Rapid
• prototype built quickly
• less feedback so entire process completed more
  quickly.

13
Three Key Points

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

14
Waterfall and Rapid Prototyping Models

• Waterfall model
• Many successes
• Client needs may not be met
• Rapid prototyping model
• Not proved
• Has own problems
• Solution
• Rapid prototyping for requirements phase
• Waterfall for rest of life cycle

15
Incremental Model

• Software is built piece by piece.
• Divide project into builds
• a build consists of code pieces from various
  modules interacting to provide a specific
  functional capability.

16
Incremental Model

• Example builds
• project is a submarine
• the navigation system is a build
• the weapons control system is a build.
• project is an OS
• the scheduler is a build
• the file management system is a build.

17
Incremental Model

• At each stage of the model,
• a new build is coded
• then integrated into the structure
• which is tested as a whole.
• Process stops when product achieves target
  functionality (ie, satisfies specs).

18
Incremental Model

• Manager decides how to break product into builds.
• too few get build-and-fix approach
• too many more time spent in integration testing
  than in implementing.

19
Incremental Model (contd)

• Waterfall, rapid prototyping models
• Operational quality complete product at end
• adequate testing and documentation.
• had projected delivery date
• Incremental model
• Operational quality portion of product within
  weeks (at each build)
• this satisfies a subset of requirements and
  client can begin using immediately.
• Less traumaticdont change system all at once.
• Smaller capital outlay, rapid return on investment

20
Incremental Model (contd)

• Each additional build has to be incorporated into
  the existing structure.
• Existing structure must be extensible.
• Thus need open architecture
• maintenance easier.can add features easier

21
Incremental Model (contd)

• Too easy to degenerate into the build-and-fix
  model.
• Requirements, specs, and architectural design
  must be completed before implementing builds.
• Contradictory requirements
• developer must view product as a whole to begin
  with a design that will support the entire
  product.
• must also view product as a sequence of builds,
  each independent of the next
• Variations used in object-oriented life cycle

22
Incremental Model (contd)

• More risky versionpieces may not fit
• As soon as the specs of one build finished, start
  the specs on the next, etc.

What if builds dont fit together?
23
Extreme 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 task are drawn up first
• Pair programming
• Continuous integration of tasks

24
Unusual Features of XP

• Computers are put in center of large room lined
  with cubicles
• Client representative is always present
• Cannot work overtime for 2 successive weeks
• No specialization
• Refactoring

25
Evaluating XP

• XP has had some successes
• Good when requirements are vague or changing
• Too soon to evaluate XP

26
Synchronize-and Stabilize Model

• Microsofts life-cycle model
• A version of the incremental model
• Requirements analysisinterview numerous
  potential customers
• Extract a list of features with priorities set by
  the customers.
• Draw up specifications

27
Synchronize-and Stabilize Model (contd)

• Divide project into 3 or 4 builds
• Each build is carried out by small teams working
  in parallel
• First build consists of the most critical
  features
• Next build consists of next most critical
  features
• etc

28
Synchronize-and Stabilize Model (contd)

• At the end of the daysynchronize
• put together the partially completed components
• test and debug the resulting product
• ensures that components always work together
• At the end of the buildstabilize
• test the build
• freeze build (no more changes to specs allowed
• Components always work together
• Get early insights into operation of product from
  the frequent synchronizations
• allows detection of bad requirements and early
  modification

29
Spiral Model

• Every software development project has risks
• key personnel leave
• hardware manufacturer goes backrupt
• find too little (or much) has been spend on
  testing and QA
• new breakthroughs render the product useless
• competitor releases a cheaper/better product
• components of an incremental process dont fit
  together
• etc.

30
Spiral Model

• One approach to reduce risks prototypes
• rapid prototyping models used prototypes to
  reduce risk during requirements phase.
• example can build a simple form of a product to
  test a new algorithm.
• The spiral model is based on the use of
  prototypes through all phases of the development
  cycle.

31
Spiral Model

• Simplified form
• Waterfall model plus risk analysis
• Precede each phase by
• Alternatives
• Risk analysis
• Follow each phase by
• Evaluation
• Planning of next phase

32
Simplified Spiral Model

• If risks cannot be resolved, project is
  immediately terminated
• prototypes used to provide info about certain
  classes of risks.
• example timing measurements on a prototype
  indicate if product will be too slow

33
Simplified Spiral Model

• Prototypes cannot solve all risks
• example can a software team that builds small
  products also build a large one?
• example can a hardware contractor be trusted to
  deliver on time?

34
Full Spiral Model

• Radial dimension cumulative cost to date
• Angular dimension progress through the spiral
• Each cycle of the spiral corresponds to a phase
• phase begins in top left quadrant

35
Full Spiral Model

• Stage 1
• determine objectives for that phase
• determine alternatives for achieving those
  objectives
• constraints imposed on those alternatives
• result strategy for achieving objectives.
• strategy analyzed from the viewpoint of risk
• attempt to resolve every potential risk
• build prototypes if necessary
• If risks cannot be resolved, may terminate
  immediately
• or may scale back project

36
Full Spiral Model (contd)
37
Full Spiral Model

• Stage 2
• Development step
• corresponds to the requirement phase of the
  waterfall model
• validate requirements
• life-cycle plan developed
• go to next phase

38
Full Spiral Model (contd)
39
Analysis of Spiral Model

• Strengths
• Emphasis on alternatives and constraints support
  software reuse
• Easy to judge how much to test analysis of
  risks shows how much testing to be done
• No distinction between development, maintenance
  so maintenance not overlooked by software
  professionals

40
Analysis of Spiral Model

• Weaknesses
• For large-scale software only
• if risk analysis costs as much as development not
  worth it!
• For internal (in-house) software only
• external developers dont want the project
  halted!
• plus, cant break a contract with an external
  contractor
• internal developers can just be reassigned to a
  new project
• Need highly trained software developers who are
  skilled at pinpointing and analyzing possible
  risks.

41
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 within phases
• Parallelism between phases (overlap of
  activities)
• Incremental development
• Danger
• CABTAB (code-a-bit test-a-bit)
• danger of disintegrating into random approach of
  developing piecemeal.

42
Fountain Model

• Circles represent phases
• Overlapping circles indicate parallelism
• Arrows represent iteration within a phase
• Smaller maintenance circle represents reduced
  maintenance in OOP

43
Conclusions

• Different life-cycle models
• Each with own strengths
• Each with 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

44
Comparisons
45
Comparisons