Object-Oriented and

Classical Software
Engineering
Eighth Edition, WCB/McGraw-Hill, 2010

Stephen R. Schach
[email protected]
CHAPTER 2

SOFTWARE
LIFE-CYCLE
MODELS

2
Overview
• Software development in theory
• Winburg mini case study
• Lessons of the Winburg mini case study
• Teal tractors mini case study
• Iteration and incrementation
• Winburg mini case study revisited
• Risks and other aspects of iteration and
incrementation
• Managing iteration and incrementation
• Other life-cycle models
• Comparison of life-cycle models

3
2.1 Software Development in Theory

 Ideally, software is
developed as described in
Chapter 1
 Linear
 Starting from scratch

Figure 2.1
Software Development in Practice
 In the real world, software development is
totally different
 We make mistakes
 The client’s requirements change while the
software product is being developed

5
 2.2 Winburg Mini Case Study
• Episode 1: The first version is implemented

• Episode 2: A fault is found

– The product is too slow because of an implementation
fault
– Changes to the implementation are begun

• Episode 3: A new design is adopted

– A faster algorithm is used

• Episode 4: The requirements change

– Accuracy has to be increased

• Epilogue:
6
A few years later, these problems recur
Evolution-Tree Model

 Winburg Mini Case

Study

Figure 2.2
Waterfall Model

 The linear life cycle model with

feedback loops
 The waterfall model cannot show
the order of events

Figure 2.3
Return to the Evolution-Tree Model
• The explicit order of events is shown

• Example:
– Baseline at the end of Episode 3:
• Requirements1, Analysis1, Design3, Implementation3

9
2.3 Lessons of the Winburg Mini Case
Study
• In the real world, software development is
more chaotic than the Winburg mini case
study

• Changes are always needed

– A software product is a model of the real world,
which is continually changing
– Software professionals are human, and therefore
make mistakes

10
2.4 Teal Tractors Mini Case Study
• While the Teal Tractors software product is
being constructed, the requirements change

• The company is expanding into Canada

• Changes needed include:

– Additional sales regions must be added
– The product must be able to handle Canadian
taxes and other business aspects that are handled
differently
– Third, the product must be extended to handle
two different currencies, USD and CAD
11
Teal Tractors Mini Case Study (contd)
 These changes may be
 Great for the company; but
 Disastrous for the software product

12
Moving Target Problem
 A change in the requirements while the
software product is being developed

 Even if the reasons for the change are good,

the software product can be adversely
impacted

13
Moving Target Problem (contd)
 Any change made to a software product can
potentially cause a regression fault
 A fault in an apparently unrelated part of the
software

 If there are too many changes

 The entire product may have to be redesigned and
reimplemented

14
Moving Target Problem (contd)
 Change is inevitable
 Growing companies are always going to change
 If the individual calling for changes has sufficient
clout, nothing can be done about it

 There is no solution to the moving target

problem

15
2.5 Iteration and Incrementation
• In real life, we cannot speak about “the
analysis phase”
– Instead, the operations of the analysis phase are
spread out over the life cycle

• The basic software development process is

iterative
– Each successive version is intended to be closer to
its target than its predecessor

16
Miller’s Law
• At any one time, we can concentrate on only
approximately seven chunks (units of
information)

• To handle larger amounts of information, use

stepwise refinement
– Concentrate on the aspects that are currently the
most important
– Postpone aspects that are currently less critical
– Every aspect is eventually handled, but in order of
current importance

• This is an incremental process

17
Iteration and Incrementation (contd)

18 Figure 2.4
Classical Phases versus Workflows
 Sequential phases do not exist in the real world

 Instead, the five core workflows (activities) are

performed over the entire life cycle
 Requirements workflow
 Analysis workflow
 Design workflow
 Implementation workflow
 Test workflow

19
 Workflows
• All five core workflows are performed over the
entire life cycle

• However, at most times one workflow

predominates

• Examples:
– At the beginning of the life cycle
• The requirements workflow predominates
– At the end of the life cycle
• The implementation and test workflows predominate

• Planning and documentation activities are

performed
20 throughout the life cycle
Iteration and Incrementation (contd)

 Iteration is performed during each incrementation

Figure 2.5
2.7 Risks and Other Aspects of Iter. and
Increm.
• We can consider the project as a whole as a set
of mini projects (increments)

• Each mini project extends the

– Requirements artifacts
– Analysis artifacts
– Design artifacts
– Implementation artifacts
– Testing artifacts

• The final set of artifacts is the complete product

22
Risks and Other Aspects of Iter. and Increm.
(contd)
 During each mini project we
 Extend the artifacts (incrementation);
 Check the artifacts (test workflow); and
 If necessary, change the relevant artifacts
(iteration)

23
Risks and Other Aspects of Iter. and Increm.
(contd)
• Each iteration can be viewed as a small but
complete waterfall life-cycle model

• During each iteration we select a portion of

the software product

• On that portion we perform the

– Classical requirements phase
– Classical analysis phase
– Classical design phase
– Classical implementation phase

24
Strengths of the Iterative-and-Incremental
Model
• There are multiple opportunities for checking
that the software product is correct
– Every iteration incorporates the test workflow
– Faults can be detected and corrected early

• The robustness of the architecture can be

determined early in the life cycle
– Architecture — the various component modules
and how they fit together
– Robustness — the property of being able to handle
extensions and changes without falling apart

25
Strengths of the Iterative-and-Incremental
Model (contd)
• We can mitigate (resolve) risks early
– Risks are invariably involved in software
development and maintenance

• We have a working version of the software

product from the start
– The client and users can experiment with this
version to determine what changes are needed

• Variation: Deliver partial versions to smooth

the introduction of the new product in the
client organization
26
2.8 Managing Iteration and
Incrementation
 The iterative-and-incremental life-cycle model
is as regimented as the waterfall model …

 … because the iterative-and-incremental life-

cycle model is the waterfall model, applied
successively

 Each increment is a waterfall mini project

27
2.9 Other Life-Cycle Models
• The following life-cycle models are presented
and compared:
– Code-and-fix life-cycle model
– Waterfall life-cycle model
– Rapid prototyping life-cycle model
– Open-source life-cycle model
– Agile processes
– Synchronize-and-stabilize life-cycle model
– Spiral life-cycle model

28
2.9.1 Code-and-Fix Model

 No design

 No
specifications
 Maintenance
nightmare

Figure 2.8
Code-and-Fix Model (contd)
 The easiest way to develop software

 The most expensive way

30
2.9.2 Waterfall Model

31
Figure 2.9
2.9.2 Waterfall Model (contd)
 Characterized by
 Feedback loops
 Documentation-driven

 Advantages
 Documentation
 Maintenance is easier
 Disadvantages
 Until the final stage of the development cycle is
complete, a working model of the software does not
lie in the hands of the client. Thus, he is hardly in a
position to inform the developers, if what has been
32 designed is exactly what he had asked for.
2.9.3 Rapid Prototyping Model

 Linear
model

 “Rapid”

Figure 2.10
2.9.4 Open-Source Life-Cycle Model
• Two informal phases

• First, one individual builds an initial version

– Made available via the Internet (e.g.,
SourceForge.net)

• Then, if there is sufficient interest in the project

– The initial version is widely downloaded
– Users become co-developers
– The product is extended

• Key point: Individuals generally work voluntarily

on an open-source project in their spare time
34
The Activities of the Second Informal Phase
• Reporting and correcting defects
– Corrective maintenance

• Adding additional functionality

– Perfective maintenance

• Porting the program to a new environment

– Adaptive maintenance

• The second informal phase consists solely of

postdelivery maintenance
– The word “co-developers” on the previous slide
should rather be “co-maintainers”

35
Open-Source Life-Cycle Model (contd)

 Postdelivery maintenance life-cycle model

Figure 2.11
Open-Source Life-Cycle Model (contd)
• Closed-source software is maintained and
tested by employees
– Users can submit failure reports but never fault
reports (the source code is not available)

• Open-source software is generally maintained

by unpaid volunteers
– Users are strongly encouraged to submit defect
reports, both failure reports and fault reports

37
Open-Source Life-Cycle Model (contd)
• Core group
– Small number of dedicated maintainers with the
inclination, the time, and the necessary skills to
submit fault reports (“fixes”)
– They take responsibility for managing the project
– They have the authority to install fixes

• Peripheral group
– Users who choose to submit defect reports from
time to time

38
Open-Source Life-Cycle Model (contd)
 Consequently, in an open-source project,
there are generally no specifications and no
design

 How have some open-source projects been so

successful without specifications or designs?

39
Open-Source Life-Cycle Model (contd)
• Open-source software production has
attracted some of the world’s finest software
experts
– They can function effectively without
specifications or designs

• However, eventually a point will be reached

when the open-source product is no longer
maintainable

40
Open-Source Life-Cycle Model (contd)
• The open-source life-cycle model is restricted
in its applicability

• It can be extremely successful for

infrastructure projects, such as
– Operating systems (Linux, OpenBSD, Mach,
Darwin)
– Web browsers (Firefox, Netscape)
– Compilers (gcc)
– Web servers (Apache)
– Database management systems (MySQL)

41
Open-Source Life-Cycle Model (contd)
• About half of the open-source projects on the
Web have not attracted a team to work on the
project

• Even where work has started, the overwhelming

preponderance will never be completed

• But when the open-source model has worked, it

has sometimes been incredibly successful
– The open-source products previously listed have
been utilized on a regular basis by millions of users

42
2.9.5 Agile Processes
• 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

43
Unusual Features of XP
• The computers are put in the center of a large
room lined with cubicles

• A client representative is always present

• Software professionals cannot work overtime

for 2 successive weeks

• Refactoring (design modification…improving

the design of existing software code)

44
Agile Processes (contd)
• A principle in the Manifesto is
– Deliver working software frequently
– Ideally every 2 or 3 weeks

• One way of achieving this is to use timeboxing

– Used for many years as a time-management
technique

• A specific amount of time is set aside for a task

– Typically 3 weeks for each iteration
– The team members then do the best job they can
during that time
45
Agile Processes (contd)
• It gives the client confidence to know that a new
version with additional functionality will arrive
every 3 weeks

• The developers know that they will have 3 weeks

(but no more) to deliver a new iteration
– Without client interference of any kind

• If it is impossible to complete the entire task in

the timebox, the work may be reduced
(“descoped”)
– Agile processes demand fixed time, not fixed features

46
Agile Processes (contd)
• Another common feature of agile processes is
stand-up meetings
– Short meetings held at a regular time each day
– Attendance is required

• Participants stand in a circle

– They do not sit around a table
– To ensure the meeting lasts no more than 15
minutes

47
Agile Processes (contd)
 The aim of a stand-up meeting is
 To raise problems
 Not solve them

 Solutions are found at follow-up meetings,

preferably held directly after the stand-up
meeting

48
2.9.6 Synchronize-and Stabilize Model
• Microsoft’s life-cycle model

• Requirements analysis — interview potential

customers

• Draw up specifications

• Divide project into 3 or 4 builds

• Each build is carried out by small teams working

in parallel

49
Synchronize-and Stabilize Model
(contd)
• At the end of the day — synchronize their
code with that of other teams (test and
debug)

• and debug (stabilize) code

• Components always work together

– Get early insights into the operation of the product

50
2.10 Comparison of Life-Cycle Models
• Different life-cycle models have been
presented
– Each with its own strengths and weaknesses

• Criteria for deciding on a model include:

– The organization
– Its management
– The skills of the employees
– The nature of the product

• Best suggestion
– “Mix-and-match” life-cycle model
51
Comparison of Life-Cycle Models
(contd)

Figure 2.14
52