The document discusses several software life-cycle models: 1) Code-and-fix model - writing code without design or requirements, fixing as needed, which leads to maintenance issues. 2) Waterfall model - phases are completed sequentially with documentation and approval between phases. 3) Rapid prototyping - an initial prototype gets feedback before completing development. 4) Open-source model - an informal process where individuals voluntarily maintain software over time through corrective, perfective and adaptive changes based on user reports.

1. 1
Systems and Software Engineering
Software Life-Cycle Models

2. 2
Life-Cycle Model
• It specifies the various phases/workflows of the
software process, such as the requirements,
analysis (specification), design, implementation,
and postdelivery maintenance, and the order in
which they are to be carried out.

3. Software engineering
• Software engineering: the profession, practiced by
developers, concerned with creating and maintaining
software applications by applying technologies and practices
from computer science, project management, and other
fields.

4. 4
Roles of people in software
• people involved in software production
– customer / client: wants software built
• often doesn't know what he/she wants
– managers / designers: plan software
• difficult to foresee all problems and issues in advance
– developers: write code to implement software
• it is hard to write complex code for large systems
– testers: perform quality assurance (QA)
• it is impossible to test every combination of actions
– users: purchase and use software product
• users can be fickle and can misunderstand the product

5. 5
Problems with software today
• Example: Space shuttle software
– cost: $10 Billion, millions of dollars more than planned
– time: 3 years late
– quality: first launch of Columbia was cancelled because of a
synchronization problem with the Shuttle's 5 onboard computers
• error was traced back to a change made 2 years earlier when a
programmer changed a delay factor in an interrupt handler from 50 to 80
milliseconds
• the likelihood of the error was small enough, that the error caused no harm
during thousands of hours of testing
• substantial errors still exist in the code
– astronauts are supplied with a book of known software problems "Program
Notes and Waivers"
– reusability: shuttle software cannot be reused
• Have to develop each software product from scratch

6. 6
Ad-hoc software development
• ad-hoc development: creating software without
any formal guidelines or process
• what are some disadvantages of ad-hoc
development?
some important actions (testing, design) may go ignored
not clear when to start or stop doing each task
does not scale well to multiple people
not easy to review or evaluate one's work

7. 7
The software lifecycle
• software lifecycle: series of steps / phases, through which
software is produced
– can take months or years to complete
• goals of each phase:
– mark out a clear set of steps to perform
– produce a tangible document or item
– allow for review of work
– specify actions to perform in the next phase
• common observation: The later a problem is found in
software, the more costly it is to fix

8. 8
Lifecycle phases
• standard phases
1. Requirements Analysis & Specification
2. Design
3. Implementation, Integration
4. Testing, Profiling, Quality Assurance
5. Operation and Maintenance
• other possible phases
– risk assessment: examining what actions are critical and
performing them first (part of Spiral model)
– prototyping: making a quick version of the product and using it
to guide design decisions

9. 9
One view of SW cycle phases
Subsystems
Structured By
class...
class...
class...
Source
Code
Implemented
By
Solution
Domain
Objects
Realized By
System
Design
Object
Design
Implemen-
tation
Testing
Application
Domain
Objects
Expressed in Terms
Of
Test
Cases
?
Verified
By
class.... ?
Requirements
Elicitation
Use Case
Model
Analysis

10. 10
Some software models
• Several models for developing software (besides ad-
hoc) have been attempted:
– code-and-fix: write some code, debug it, repeat until
finished
– evolutionary: build initial requirement spec, write it, then
"evolve" the spec and code as needed
– waterfall: perform the standard phases (requirements,
design, code, test) in sequence
– rapid prototyping: write an initial "throwaway" version of the
product, then design, code, test
– spiral: assess risks at each step, and do the most critical
action immediately

11. 11
Software Development in Theory
• Ideally, software is developed
as
– Linear
– Starting from scratch

12. 12
Software Development in Practice
• In the real world, software development is totally
different and is more chaotic
– Software professionals make mistakes
– The client’s requirements change while the software
product is being developed
– A software product is a model of the real world, and
the real world is continually changing.

13. 13
1. Code-and-Fix Life-Cycle Model
The easiest way to develop software
The most expensive way for maintenance (i.e.,
maintenance nightmare)
• No design
• No specifications

14. 14
Code-and-Fix Life-Cycle Model (Cont.)
• The product is implemented without requirements or
specifications, or any attempt at design.
• The developers simply throw code together and
rework it as many times as necessary to satisfy the
client.
• It is used in small project and is totally unsatisfactory
for products of any reasonable size.

15. 15
2. Waterfall Life-Cycle Model
• The linear life cycle
model with feedback
loops
– The waterfall model
cannot show the order of
events

16. 16
Waterfall Life-Cycle Model
(Cont.)
• No phase is complete until the documentation for that
phase has been completed and the products of that phase
have been approved by the software quality assurance
(SQA) group.
• If the products of an earlier phase have to be changed as a
consequence of following a feedback loop, that earlier
phase is deemed to be complete only when the
documentation for the phase has been modified and the
modifications have been checked by the SQA group.

17. 17
Waterfall Life-Cycle Model
(Cont.)
• Advantages:
– Documentation is provided at each phase
– All the products of each phase (including the
documentation) are meticulously checked by SQA. 
Maintenance is easier
• Disadvantages:
– Specification documents are long, detailed, and boring
to read.

18. 18
3. Rapid-Prototyping
Life-Cycle Model
• Linear
model
• ―Rapid‖

19. 19
Rapid-Prototyping Life-Cycle Model (Cont.)
• A rapid prototype is a working model that is functionally
equivalent to a subset of the product.
• The first step is to build a rapid prototype and let the client
and future users interact and experiment with the rapid
prototype.
• Strength:
– The development of the product is essentially linear, proceeding
from the rapid prototype to the delivered product.
– The feedback loops of the waterfall model are less likely to be
needed in the rapid prototyping model.
– It is built rapidly and modified rapidly to reflect the client’s needs. 
Speed is of the essence.

20. 20
Rapid-Prototyping Life-Cycle Model (Cont.)
• Weakness:
–One the client’s real needs have been
determined, the rapid prototype
implementation is discarded.
• The lessons learned from the rapid
prototype implementation are retained and
used in subsequent development phases.

21. 21
4. Open-Source Life-Cycle Model
Postdelivery maintenance life-cycle model

22. 22
Open-Source Life-Cycle Model
(Cont.)
• The first informal phase
– One individual builds an initial version and makes it
available via the Internet (e.g., SourceForge.net)
– If there is sufficient interest in the project, the initial version
is widely downloaded; users become co-developers; and
the product is extended
• Key point: Individuals generally work voluntarily on an
open-source project in their spare time

23. 23
Open-Source Life-Cycle Model
(Cont.)
• 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‖

24. 24
Open-Source Life-Cycle Model
(Cont.)
• An initial working version is produced using the rapid-
prototyping model, the code-and-fix model, and the open-
source life-cycle model.
• The initial version of the rapid-prototyping model is then
discarded. The initial versions of Code-and-fix model and
open-source life-cycle model become the target product
• There are generally no specifications and no design.
However, open-source software production has attracted
some of the world’s finest software experts. They can
function effectively without specifications or designs

25. 25
Open-Source Life-Cycle Model (Cont.)
• A point will be reached when the open-source product is no
longer maintainable
• 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), and
Database management systems (MySQL)
– There cannot be open-source development of a software product to be
used in just one commercial organization
– The open-source life-cycle model is inapplicable unless the target
product is viewed by a wide range of users as useful

26. 26
Open-Source vs. Closed-Source
• Closed-source software is maintained and tested by employees
– Users can submit failure reports but never fault reports
• Open-source software is generally maintained by unpaid
volunteers
– Users are strongly encouraged to submit defect reports, both failure
reports and fault reports
• 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

27. 27
Open-Source vs. Closed-Source
(Cont.)
• New versions of closed-source software are typically
released roughly once a year
– After careful testing by the SQA group
• The core group releases a new version of an open-source
product as soon as it is ready
– Perhaps a month or even a day after the previous version was
released
– The core group performs minimal testing
– Extensive testing is performed by the members of the peripheral
group in the course of utilizing the software
– ―Release early and often‖

28. 28
5. Evolution-Tree Life-Cycle Model
The model for Winburg Mini Case Study

29. 29
Evolution-Tree Life-Cycle Model (Cont.)
• The explicit order of events is shown
• At the end of each episode
– We have a baseline, a complete set of artifacts (a
constitute component of a software product)

30. 30
Moving Target Problem
• Moving Target Problem: The requirements change while the software
product is being developed. This change is inevitable
– Growing companies are always going to change
– If the individual calling for changes has sufficient clout, nothing can be done
to prevent the changes being implemented.
• The software product can be adversely impacted
– Numerous changes can induce dependencies within the code.
• Any change made to a software product can potentially cause a
regression fault. That is, a change to one part of the software induces 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
• There is no solution to the moving target problem!!

31. 31
6. Iterative and Incremental
Life-Cycle Model: Iteration
• In the real life, we cannot speak about ―the analysis phase‖
– Instead, the operations of the analysis phase are spread out over
the life cycle as a consequence of both the moving target problem
and the need to correct the inevitable mistakes
• The basic software development process is iterative
– Each successive version is intended to be closer to its target than
its predecessor

32. Iterative and Incremental
Life-Cycle Model: Incrementation
• Miller’s Law: At any one time, we can concentrate on only
approximately seven chunks (units of information) ( The Law is
often interpreted to argue that the number of objects an
average human can hold in working memory is 7 ± 2.)
• 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 the order of current
importance
• This is an incremental process

33. 33
Iterative-and-Incremental Model
Iteration and incrementation are used in conjunction with one another
1) There is no single ―requirements phase/workflow‖ or ―design phase/workflow‖
2) Instead, there are multiple instances of each phase/workflow. However, only one
phase/workflow predominates at most times.

34. 34
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
throughout the life cycle

35. 35
Iterative-and-Incremental
Life-Cycle Model (Cont.)
Iteration is performed during each incrementation

36. 36
Combine the Evolution-Tree and the
Iterative-and-Incremental Models

37. 37
Combine the Evolution-Tree and the Iterative-
and-Incremental Models (Cont.)
• Each episode corresponds to an increment
• Not every increment includes every workflow
• Increment B was not completed
• Dashed lines denote maintenance
– Episodes 2, 3: Corrective maintenance
– Episode 4: Perfective maintenance

38. 38
Risks and Other Aspects of Iteration and
Incrementation
• 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
• During each mini project, we
– Extend the artifacts (incrementation);
– Check the artifacts (test workflow); and
– If necessary, change the relevant artifacts (iteration)
• The final set of artifacts is the complete product

39. 39
Risks and Other Aspects of Iteration and
Incrementation (Cont.)
• 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

40. 40
Strength 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

41. 41
Strength of the Iterative-and-Incremental
Model (Cont.)
• We can mitigate (resolve) risks early
– Risks are invariably involved in software development
and maintenance
• We always have a working version of the software
product
– Variation: Deliver partial versions to smooth the
introduction of the new product in the client organization
• There is empirical evidence that the life-cycle model
works

42. 42
Managing Iteration and Incrementation
• The iterative-and-incremental life-cycle model is as regimented
as the waterfall model since developing a software product
using the iterative-and-incremental model is equivalent to
developing a series of smaller software products, all using the
waterfall model.
– The project as a whole is broken up into a series of waterfall mini
projects.
– During each mini-project, iteration is performed as needed.
– For each increment, the requirements, analysis, design, and
implementation phases are repeatedly performed until it is clear that no
further iteration is needed. That is: each increment is a waterfall mini
project.
• The iterative-and-incremental life-cycle model is the
waterfall model, applied successively

43. 43
7. Agile Processes:
Extreme Programming
• Extreme programming is a somewhat controversial
new approach to software development based on
the iterative-and-incremental model.
• The software development team determines the
various features (stories) the client would like the
product to support.

44. 44
Agile Processes:
Extreme Programming (Cont.)
• Based on the features (stories) the client wants:
– The development team estimates the duration and cost
of each feature
– The client selects the features for next build using cost-
benefit analysis
– The proposed build is broken down into smaller pieces
termed tasks
– The programmer draws up test cases for a task  Test-
driven development (TDD)

45. 45
Agile Processes:
Extreme Programming (Cont.)
• Pair Programming: The programmer works together with a
partner on one screen to implement the task and ensure
that all the test cases work correctly.
• Continuous integration of tasks since a number of pairs
implement tasks in parallel
• The TDD test cases used for the task are retained and
utilized in all further integration testing.

46. 46
Unusual Features of
Extreme Programming (XP)
• The computers of the XP team are put in the center of a
large room lined with cubicles.
• A client representative works with the XP team at all times.
• Software professionals cannot work overtime for 2
successive weeks.
• There is no specialization. Instead, all members of the XP
team work on analysis, design, code, and testing.
• There is no overall design step before the various builds
are constructed. Instead, the design is modified while the
product is being built. This procedure is termed
refactoring.

47. 47
Agile Processes
• Extreme programming is one of a number of new
paradigms that are collectively referred to as agile
processes.
• Agile processes are characterized by
– Less emphasis on analysis and design
– Earlier implementation (working software is considered
more important than detailed documentation)
– Responsiveness to change in requirements
– Close collaboration with the client

48. 48
Agile Processes (Cont.)
• 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
• Agile processes demand fixed time, not fixed features

49. 49
Agile Processes (Cont.)
• 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
• 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

50. 50
Agile Processes (Cont.)
• Stand-up meetings and timeboxing are both
– Successful management techniques
– Now utilized within the context of agile processes
• Both techniques are instances of two basic
principles that underlie all agile methods:
– Communication; and
– Satisfying the client’s needs as quickly as possible

51. 51
Evaluating Agile Processes
• Agile processes have had some successes with
small-scale software development
– However, medium- and large-scale software development
is very different
• The key decider: The impact of agile processes on
postdelivery maintenance
– Refactoring is an essential component of agile processes
– Refactoring continues during maintenance
– Will refactoring increase the cost of postdelivery
maintenance?

52. 52
Evaluating Agile Processes (Cont.)
• Agile processes are good when requirements are vague or
changing
• It is too soon to evaluate agile processes
– There are not enough data yet
• Even if agile processes are proven to be disappointing
– Some features (such as pair programming) may be adopted as
mainstream software engineering practices

53. 53
8. Synchronize-and-Stabilize
Life-Cycle Model
• Microsoft’s life cycle model
• Requirements: Interview numerous potential clients for the
package and extract a list of features of highest priority to
the clients.
• Draw up specifications
• Divide the work into three or four builds.
– The 1st build: Most critical features.
– The 2nd build: The next most critical features.
– Each build is carried out by a number of small teams working in
parallel.

54. 54
Synchronize-and-Stabilize
Life-Cycle Model (Cont.)
• Synchronize at the end of each day: Put the
partially completed components together and test
and debug the resulting product.
• Stabilize at the end of each build: Fix remaining
faults and no further changes will be made to the
specifications

55. 55
Synchronize-and-Stabilize
Life-Cycle Model (Cont.)
• Advantages:
– The repeated synchronization step ensures that the
various components always work together.
– The regular execution of the partially constructed
product makes the developers gain early insight into the
operation of the product and modify the requirements if
necessary during the course of a build.

56. 56
9. Spiral Life-Cycle Model
• Simplified form
– Rapid prototyping model
plus risk analysis
preceding each phase
• If all risks cannot be
mitigated, the project is
immediately terminated

57. 57

58. 58
Full Spiral Life-Cycle Model
Radial dimension: cumulative costs to date
Angular dimension: progress through the spiral.
• Precede each phase by
– Alternatives
– Risk analysis
• Follow each phase by
– Evaluation
– Planning of the next phase

59. 59
Spiral Life-Cycle Model (Cont.)
• Minimize risk via the use of prototypes and other
means.
• Two types of risk:
– Analyzable Risk: Time and cost
– Un-analyzable Risk:
• Personnel turnover
• Difference between small-scale and large-scale software
• Evaluate the delivery promises of a hardware supplier

60. 60
Spiral Life-Cycle Model (Cont.)
• Precede each phase by determining:
– Objective of the phase;
– Alternatives for achieving the objectives;
– Constraints imposed on those alternatives.
• Strategy is analyzed from the viewpoint of risk. Attempts
are made to resolve every potential risk.
• Follow each phase by:
– The results of the phase are evaluated.
– The next phase is planned.

61. 61
Spiral Life-Cycle Mode (Cont.)
• Strengths
– The emphasis on alternatives and constraints supports
the reuse of existing software and the incorporation of
software quality as a specific objective.
– There is essentially no distinction between development
and maintenance since maintenance is another cycle of
the spiral.
• Weaknesses
– For large-scale software only
– For internal (in-house) software only

62. 62
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

63. 63

64. • Winding up
64

65. 65
Some software models
• Several models for developing software (besides ad-
hoc) have been attempted:
– code-and-fix: write some code, debug it, repeat until
finished
– evolutionary: build initial requirement spec, write it, then
"evolve" the spec and code as needed
– waterfall: perform the standard phases (requirements,
design, code, test) in sequence
– rapid prototyping: write an initial "throwaway" version of the
product, then design, code, test
– spiral: assess risks at each step, and do the most critical
action immediately

66. 66
code-and-fix model
Code First
Version
Retirement
Operations Mode
Modify until
Client is satisfied

67. 67
Problems with code-and-fix
• What are some reasons not to use the code-and-fix
model?
 code becomes expensive to fix (bugs are not found until
late in the process)
 code didn't match user's needs (no requirements phase!)
 code was not planned for modification, not flexible

68. 68
Evolutionary model
For each build:
Perform detailed
design, implement.
Test. Deliver.
Requirements
Verify
Retirement
Operations
Verify
Arch. Design

69. 69
Problems with evolutionary
• The evolutionary model is similar to code-and-fix, but it
assumes the repetitions are "evolutions" of the code, not
necessarily bug fixes. Problems with this?
 difficult to distinguish from code-and-fix
 assumes user's initial spec will be flexible; fails for:
 separate pieces that must then be integrated
 "information sclerosis": temporary fixes become permanent constraits
 bridging; new software trying to gradually replace old
 wrong order: makes lots of hard-to-change code

70. 70
Waterfall model (Royce, 1970)
Requirements
Verify
Retirement
Operations
Test
Implementation
Verify
Design
Req. Change

71. 71
Rapid prototyping model
Rapid Prototype
Verify
Retirement
Operations
Test
Re-implementation
Verify
Redesign
Req. Change

72. 72
Waterfall / Prototyping issues
• The waterfall models (with or without prototyping)
are perhaps the most common model for software
development
– we will use waterfall in this course!
• What are some positives and negatives about this
method?
+ formal, standard, has specific phases with clear goals
+ good feedback loops between adjacent phases
- rigid, too linear; not very adaptable to change in the product
- requires a lot of planning up front (not always easy / possible)
- assumes that requirements will be clear and well-understood

73. 73
Spiral model (Boehm)

74. 74
Another view of spiral model
Requirements
Verify
Retirement
Operations
Test
Implementation
Verify
Design
Req. Change
Adds a Risk Analysis
step to each phase
(phases may not be
completed in this order
any more!)
Risk Assessment
Risk Assessment
Risk Assessment

75. 75
Spiral model problems
• What are some positives and negatives about this
method?
+ focuses attention on reuse
+ accommodates changes, growth
+ eliminates errors and unattractive choices early
+ limits to how much is enough (not too much design, reqs, etc)
+ treats development, maintenance same way
- matching to contract software (doesn't work well when you're bound to a fixed inflexible contract)
- relying on developers to have risk-assessment expertise
- need for further elaboration of project steps (clearer milestones)

76. 76
Tools for software engineers
• CASE (Computer-Aided Software Engineering)
– requirements / spec generation software
– design diagram (UML) software
– integrated development environments (IDEs)
– test suites (JUnit) and benchmarking / profiling software