Life Cycle Models

(Lect 2--3)

2/7/2026 1
 Plan

⚫ Today: Waterfall model and its

derivatives, evolutionary model, and RAD

⚫ Next class: Overview of agile models:

Extreme Programming (XP) and Scrum
as example models

2
 Software Life Cycle
Conceptualize

Specify
Retire

Design
Maintain

Deliver Code

Test
3
 Life Cycle Model
⚫ A software life cycle model (also process
model or SDLC):
− A descriptive and diagrammatic model of a
software life cycle:
− Identifies all the activities undertaken during
product development,

− Establishes a precedence ordering among the

different activities,

− Divides life cycle into phases.

4
 Life Cycle Model (CONT.)

⚫ Each life cycle phase (activity) consists

of subactivities.
− Forexample, the design stage
might consist of:
⚫ structured analysis
⚫ structured design

5
 Why Model Life Cycle?
⚫ A graphical and written description:
− Helps a common understanding of activities
among the software developers.
− Helps to identify inconsistencies,
redundancies, and omissions in the
development process.
− Helps in tailoring a process model for
specific projects.
6
 Life Cycle Model (CONT.)

⚫ A development team must identify a

suitable life cycle model:
− and then adhere to it.
− Primary advantage of adhering to a
life cycle model:
⚫ Helps development of software in a
systematic and disciplined manner.
7
 Life Cycle Model (CONT.)

⚫ When a single programmer develops software---

− The problem is within the grasp of an individual.

− He has the freedom to decide his exact steps and

still succeed. Exploratory model, or

− Code➔Test ➔Design

− Code➔Design ➔Test ➔ Code

− Specify ➔code ➔Design ➔Test etc.

8
 Life Cycle Model (CONT.)

⚫ When a software product is being

developed by a team:
− There must be a good understanding among
team members as to when to do what,

− Otherwise, it would lead to chaos and project

failure.

− Remember, each member is only helping with

some part of the project.
9
 Life Cycle Model (CONT.)

⚫ Recipe for a software project to never

succeed:
− one engineer starts writing code for some
part,
− another concentrates on writing the test
document first for some other part,
− yet another engineer first defines the file
structure for some parrt
− another defines the I/O for his portion first.
10
 Entry and Exit Criteria

⚫ A life cycle model:

− Definesentry and exit criteria for
every phase.
−A phase is considered to be
complete:
⚫ Only when all its exit criteria are
satisfied.

11
 Life Cycle Model
⚫ The phase exit criteria for the software
requirements specification phase:
− Software Requirements Specification
(SRS) document is complete, reviewed,
and approved by the customer.

⚫ A phase can start:

− Only if its phase-entry criteria have
been satisfied.

12
 Milestones in Life Cycle

⚫ Milestones make it easier for software

project managers:
− Helpmonitor the progress of the
project.
− Phaseentry and exit are
important milestones.

13
 Life Cycle and Project Management

⚫ When a life cycle model is followed:

− The project manager can at any time fairly
accurately tell,

⚫ At which stage (e.g., design, code, test,

etc.) the project is.
⚫ That is how much time and effort is
required to complete the project.

14
Project Management Without Life Cycle Model

⚫ It becomes very difficult to track the

progress of the project.
− The project manager would have to depend
on the guesses of the team members.

⚫ This usually leads to a problem:

− known as the 99% complete syndrome.

15
 Myth: Deliverables and Milestones

Myth:
“The only deliverable for a successful
project is the working program.”

Reality:
Documentation of all aspects of software
development is needed to ensure
maintainability.
16
 Life Cycle Model
⚫ Many life cycle models have been proposed.
⚫ We confine our attention to a few important
and commonly used models.
− Classical and Iterative waterfall models
− V model,
− Evolutionary,
− Prototyping
− Spiral model, and
− Agile models
17
 Software Life Cycle

⚫ Software life cycle (or software process):

− Series of identifiable stages that a
software product undergoes during its
lifetime:
⚫ Feasibility study
⚫ Requirements analysis and specification,
⚫ Design,
⚫ Coding,
⚫ Testing
⚫ Maintenance.

18
 Classical Waterfall Model

⚫ The classical waterfall model divides the

life cycle into the following phases:
− Feasibility study,
− Requirements analysis and specification,
Conceptualize
− Design, Specify
Retire

− Coding and unit testing,

Design

Integration and system

Maintain
−
testing, Deliver Code

− Maintenance. Test 19
 Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
20
 Relative Effort for Phases

⚫ Phases between feasibility

study and testing 60
50
− Called development phases.
40

Relative Effort
⚫ Among all life cycle phases 30
− The maintenance phase 20
consumes maximum effort. 10

Among development phases, 0

Maintnce
⚫

Coding
Design

Test
Req. Sp
− The testing phase consumes
the maximum effort.

21
 Classical Waterfall Model (CONT.)

⚫ Most organizations usually define:

− Standards on the outputs (deliverables) produced at
the end of every phase
− Entry and exit criteria for every phase.

⚫ They also prescribe methodologies for:

− Specification,
− Design,
− Testing,
− Project management, etc.
22
 Software Development Methodology (SDM)

⚫ The guidelines and methodologies of an

organization:
− Called the organization's software
development methodology.

⚫ Software development organizations:

− Expect fresh engineers to master the

organization's software development

methodology.
23
 The Business Case
⚫ Identifies the problem or opportunity

⚫ States why the project might be worth

doing

⚫ Gives initial benefits, costs, risks (very

rough)

⚫ Helps management decide whether the

idea is worth evaluating further
24
 The business case

⚫ Benefits of the
delivered project must
Benefits
outweigh costs
Costs ⚫ Costs include:
- Development
Rs - Operation
Rs
• Benefits:
– Quantifiable
– Non-quantifiable
25
 Feasibility Study

⚫ Main aim of feasibility study: determine

whether developing the product
− Financially worthwhile
− Technically feasible.

⚫ Roughly understand what the customer wants:

− Data which would be input to the system,
− Processing needed on these data,
− Output data to be produced by the system,
− Various constraints on the behavior of the system.
26
 Case Study

⚫ SPF Scheme for CIL

⚫ CIL has a large number of employees,
exceeding 200,000.

⚫ Mining being a risky profession:

− Casualties are high

⚫ Though there is a PF:

− But settlement time is high

⚫ There is a need for SPF:

− For faster disbursement of benefits
27
 Activities During Feasibility Study

⚫ Work out an overall understanding of the

problem.
⚫ Formulate different solution strategies.
⚫ Examine alternate solution strategies in
terms of:
⚫ resources required,
⚫ cost of development, and
⚫ development time.
28
 Feasibility Study

Operational
feasibility

Measure of how
suitable system
Four feasibility
development will
tests:
be to the
company Schedule
feasibility

Economic
feasibility
(also called Technical
cost/benefit feasibility
feasibility)

29
Feasibility Study Activities

Assesses
feasibility
of each
alternative
solution

Presented to
Recommends steering
the most committee,
feasible which decides
solution for how system will
the project be developed

30
 Activities during Feasibility Study

⚫ Perform a cost/benefit analysis:

− Determine which solution is the best.
− May also find that none of the
solutions is feasible due to:
⚫ high cost,
⚫ resource constraints,
⚫ technical reasons.
31
 Cost-benefit analysis (CBA)

⚫ Need to identify all the costs which could

be:
− Development costs
− Set-up
− Operational costs

⚫ Identify the value of benefits

⚫ Check that benefits are greater than

costs
32
 Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
33
 Requirements Analysis and Specification

⚫ Aim of this phase:

− Understand the exact requirements of
the customer,

− Document them properly.

⚫ Consists of two distinct activities:

− Requirements gathering and analysis

− Requirements specification.

34
 Goals of Requirements Analysis

⚫ Collect all related data from the customer:

− Analyze the collected data to clearly
understand what customer wants,
− Find out any inconsistencies and
incompleteness in the requirements,
− Resolve all inconsistencies and
incompleteness.

35
 Requirements Gathering

⚫ Gathering relevant data:

− Usually collected from the end-users
through interviews and discussions.

− Example: for a business accounting

software:
⚫ Interview all the organization’s accountants to
find out their requirements.

36
 Requirements Analysis (Cont...)

⚫ The data you initially collect from the

users:
− Usually contains several
contradictions and ambiguities.
− Why?
− Each user typically has only a partial and
incomplete view of the system.

37
 Requirements Analysis (Cont...)

⚫ Ambiguities and contradictions:

− must be identified
− resolved by discussions with the customers.

⚫ Next, requirements are organized:

− into a Software Requirements Specification
(SRS) document.

38
 Classical Waterfall Model

Feasibility Study

Req. Analysis

Design
Design

Coding

Testing

Maintenance
39
 Design

⚫ During the design phase requirements

specification is transformed into :
− A form suitable for implementation in
some programming language.

40
 Design

⚫ In technical terms:
− During the design phase, software
architecture is defined.

⚫ Two commonly used design approaches:

− Traditional approach,
− Object-oriented approach.

41
 Traditional Design Approach

⚫ Also known as procedural approach

⚫ Consists of two activities:
− Structured analysis
− Structured design

42
 Structured Analysis (CONT.)

⚫ Carried out using Data flow diagrams

(DFDs).

⚫ After structured analysis, carry out

structured design:
− Architectural design (or high-level design)
− Detailed design (or low-level design).

43
 Structured Design

⚫ High-level design:
− decompose the system into modules,
− represent invocation relationships among the
modules.

⚫ Detailed design:
− different modules designed in greater detail:
⚫ data structures and algorithms for each module are
designed.

44
 Object-Oriented Design

⚫ First identify various objects (real-world

entities) occurring in the problem:
− Identify the relationships among objects.
− For example, the objects in a pay-roll
software may be:
⚫ employees,
⚫ managers,
⚫ pay-roll register,
⚫ Departments, etc.

45
 Object Oriented Design (CONT.)

⚫ Object structure is further refined to

obtain the detailed design.

⚫ OOD has several advantages:

− Lower development effort,
− Lower development time,
− Better maintainability.

46
 Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
47
 Coding and Unit Testing

⚫ During this phase:

− Each module of the design is coded,

− Each module is unit-tested

⚫ That is, tested independently as a stand-alone
unit, and debugged.

− Each module is documented.

48
 Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
49
 Integration and System Testing

⚫ Different modules are integrated in a

planned manner:
− Modules are usually integrated through a
number of steps.
⚫ After each integration step,
− the partially integrated system is tested.

M1 M2 M5 M7

M3 M4 M6 M8 50
 System Testing
⚫ After all the modules have been
successfully integrated and tested:
− System testing is carried out.

⚫ Goal of system testing:

− Ensure that the developed system functions

according to its requirements as specified in
the SRS document.

51
 Classical Waterfall Model
Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
52
 Maintenance

⚫ Maintenance of any software:

− Requires much more effort than the effort
to develop the product itself.

− Development effort to maintenance effort

is typically 40:60. 60

Relative Effort
50
40
30
20
10
0

Maintnce
Coding
Design

Test
Req. Sp
53
 Maintenance (CONT.)

⚫ Corrective maintenance:
− Correct errors that were not discovered
during the product development phases.
⚫ Perfective maintenance:
− Improve implementation of the system
− enhance functionalities of the system.
⚫ Adaptive maintenance:
− Port software to a new environment,
⚫ e.g. to a new computer or a new operating
system. 54
 Iterative Waterfall Model

⚫ The classical waterfall model is

idealistic:
− Assumes that no defect is introduced
during any development activity.
− In practice:
⚫ Defects do get introduced in almost every
phase of the life cycle.

55
 Iterative Waterfall Model (CONT.)

⚫ Defects usually get detected much

later in the life cycle:
− For example, a design defect might go
unnoticed till the coding or testing phase.

56
 Iterative Waterfall Model (CONT.)

⚫ Once a defect is detected:

− The phase in which it occurred needs to be
reworked.
− Redo some of the work done during that and
all subsequent phases.

⚫ Therefore need feedback paths in the

classical waterfall model.

57
 Iterative Waterfall Model (CONT.)

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
58
 Phase Containment of Errors
(Cont...)

⚫ Errors should be detected:

• In the same phase in which they are
introduced.

⚫ For example:
• If a design problem is detected in the
design phase itself,
• The problem can be taken care of much more
easily
• Compared to say if it is identified at the end of
the integration and system testing phase. 59
Cartoonist’s View…

Grows over Lifecycle…

60
 Phase Containment of Errors
⚫ Reason: rework must be carried out not only in
the design but also to code and test phases.

⚫ The principle of detecting errors as close to

its point of introduction as possible:
− is known as phase containment of errors.

⚫ The iterative waterfall model is by far the

most widely used model.
− Almost every other model is derived from the
waterfall model.
61
 Waterfall Strengths

⚫ Easy to understand, easy to use

⚫ Provides a reference to inexperienced

staff

⚫ Milestones are well understood by the team

⚫ Provides requirements stability

⚫ Facilitates strong management control (plan,

staff, track)

62
 Waterfall Deficiencies

⚫ All requirements must be known upfront

⚫ Deliverables created for each phase are

considered frozen – inhibits flexibility

⚫ Can give a false impression of progress

⚫ Integration is one big bang at the end

⚫ Little opportunity for customers to pre-

view the system.

63
 When to use the Waterfall Model

⚫ Requirements are very well-understood

and stable
⚫ Technology is understood

⚫ Experienced Development team

64
 Classical Waterfall Model (CONT.)

⚫ Irrespective of the life cycle model

followed:
− The documents should reflect a
classical waterfall model of
development,
− Comprehension of the documents is
facilitated.
65
 Classical Waterfall Model (CONT.)

⚫ Metaphor of mathematical theorem

proving:
−A mathematician presents a proof as a
single chain of deductions,
⚫ Even though the proof might have come
from a convoluted set of partial attempts,
blind alleys, and backtracks.

66
 Questions
⚫ What problems may be encountered if a project
manager recommends using the iterative waterfall
model for a customization project?
⚫ Give one example project situation for which the
waterfall model is suitable.
⚫ Give one example project situation for which the
waterfall model is unsuitable.
⚫ What is a milestone? Give one example of a
milestone.
⚫ In what way are milestones useful?
⚫ How frequently should milestones be placed?
67
 Questions
⚫ Suppose the sales manager of your company
informs the top management of your company
that he sees tremendous potential for a
wearable health monitor.
− The wearable health monitor would measure vital
body parameters such as heart rate, temperature,
blood pressure, etc, and maintain a log.

⚫ How would you perform the feasibility study?

68
 V Model

2/7/2026 69
 V Model

⚫ It is a variant of the Waterfall:

− emphasizes verification and validation
− V&V activities are spread over the
entire life cycle.

⚫ In every phase of development:

− Testing activities are planned in
parallel with development.
70
Project& Production,
Requirements Operation &
Planning Maintenance

Product System&
Requirements& Acceptance
Specification Testing
Analysis

Architecture Integration&
High Level Testing
Design

Detailed Unit
Design testing

Coding 71
 V Model Steps
⚫ Planning

⚫ Requirements ⚫ System and acceptance

Specification and testing
Analysis

⚫ Design ⚫ Integration and Testing

⚫ Coding ⚫ Unit testing

72
 V Model: Strengths

⚫ Starting from the early stages of

software development:
− Emphasize planning for verification and
validation of the software

⚫ Each deliverable is made testable

⚫ Easy to use

73
 V Model Weaknesses

⚫ Does not support overlapping of phases

⚫ Does not handle iterations or phases

⚫ Does not easily handle later changes in

requirements

⚫ Does not support risk analysis activities

74
 When to use V Model

⚫ Natural choice for systems requiring

high reliability:
− Embedded control applications

⚫ All requirements are known up-front

⚫ Solution and technology are known

75
 Prototyping Model

2/7/2026 76
 Prototyping Model
⚫ A derivative of the waterfall model.
⚫ Before starting actual development,
− A working prototype of the system should
first be built.

⚫ A prototype is a toy implementation of a

system:
− Limited functional capabilities,
− Low reliability,
− Inefficient performance. 77
 Advantages of prototyping
⚫ Learning by doing: useful where
requirements are only partially known
⚫ Improved communication
⚫ Improved user involvement
⚫ Reduces the need for documentation
⚫ Reduces maintenance costs i.e.
changes after the application goes
live 78
 Reasons for Developing a Prototype

⚫ Illustrate to the customer:

− input data formats, messages, reports, or
interactive dialogs.

⚫ Examine technical issues associated with

product development:
− Often major design decisions depend on
issues like:
⚫ Response time of a hardware controller,
⚫ Efficiency of a sorting algorithm, etc.
79
 Prototyping Model (CONT.)

⚫ Another reason for developing a

prototype:
− It is impossible to “get it right” the first
time,
− We must plan to throw away the first
version:
⚫ If we want to develop a good software.

80
 Prototyping Model (CONT.)

⚫ Start with approximate requirements.

⚫ Carry out a quick design.
⚫ Prototype model is built using several
shortcuts:
− Short-cuts might involve:
⚫ Using inefficient, inaccurate, or dummy
functions.
⚫ A table look-up rather than performing the
actual computations.
81
 Prototyping Model (CONT.)

⚫ The developed prototype is submitted to

the customer for his evaluation:
− Based on the user feedback, the prototype
is refined.

− This cycle continues until the user approves

the prototype.

⚫ The actual system is developed using the

waterfall approach.
82
 Prototyping Model (CONT.)

Build Prototype

Requirements Customer Customer

Evaluation of Design
Gathering Quick Design Prototype satisfied

Refine
Requirements Implement

Test

Maintain83
 Prototyping Model (CONT.)

⚫ Requirements analysis and specification phase

becomes redundant:
− Final working prototype (incorporating all user
feedback) serves as an animated requirements
specification.

⚫ Design and code for the prototype is usually

thrown away:
− However, experience gathered from developing the
prototype helps a great deal while developing the
actual software.
84
 Prototyping Model (CONT.)

⚫ Even though construction of a working

prototype model involves additional cost ---
overall development cost might be lower for:
− Systems with unclear user requirements,
− Systems with unresolved technical issues.

⚫ Many user requirements get properly defined

and technical issues get resolved:
− These would have appeared later as change requests
and resulted in incurring massive redesign costs.
85
 Prototyping: Other advantages

⚫ The resulting software: more usable

⚫ User needs are better accommodated
⚫ The design may be of higher quality
⚫ The resulting software is possibly easier
to maintain
⚫ Overall, the development may incur less
effort
86

SE, Software Lifecycle, Hans van Vliet, ©2008 86

 Prototyping: disadvantages

⚫ Sometimes expensive

⚫ Susceptible to over-engineering:
− Designers start to incorporate
sophistication that they could not
incorporate in the prototype.

87

SE, Software Lifecycle, Hans van Vliet, ©2008 87

Major Difficulties of Waterfall-Based Models

1. Difficulty in accommodating change

requests during development.
▪ 40% of requirements change during
development

2. High cost incurred in developing

custom applications.

3. “Heavy weight processes.”

88
 Documentation.

Source: Robert Martin 89

Major difficulties of Waterfall-Based Life Cycle
Models

⚫ Requirements for the system are

determined at the start:
− Are assumed to be fixed from that
point on.

− Long-term planning is made based on

this.

90
“… the assumption that one can specify a
satisfactory system in advance, get bids
for its construction, have it built, and
install it. …this assumption is
fundamentally wrong and many software
acquisition problems spring from this…”
Frederick Brooks

91
 Evolutionary Model

2/7/2026 92
 Evolutionary Model
⚫ Evolutionary model (aka successive versions or
incremental model):
− The system is broken down into several modules
which can be incrementally implemented and
delivered.
⚫ First develop the core modules of the
software.
⚫ The initial skeletal software is refined into
increasing levels of capability:
− By adding new functionalities in successive
versions. 93
Biological Systems

94
 Biological Systems
The waterfall model did not apply to
biological systems --- these evolved instead
of being designed.

A complex system that works

is invariably found to have
evolved from a simple system
that worked.

95
2/7/2026 © 2009 Bahill
 Evolutionary Model

⚫ “A complex system will be most successful if

implemented in small steps… “retreat” to a
previous successful step on failure…
opportunity to receive some feedback from
the real world before throwing in all
resources… and you can correct possible
errors…” Tom Glib in Software Metrics

96
 Evolutionary Model (CONT.)

⚫ Successive version of the product:

− functioning
systems capable of
performing some useful work.

−A new release may include new

functionality:
⚫ Also existing functionality in the current
release might have been enhanced.

97
 Evolutionary Model
⚫ Evolves an initial implementation with user
feedback:
− Multiple versions until the final version.

Initial
Specification version
Outline
Intermediate
description
Development versions

Final
Validation version

98
 Evolutionary Model (CONT.)

A AB A

B B

99
 Advantages of Evolutionary Model (1)

⚫ Users get a chance to experiment with a

partially developed system:
− Much before the full working version is
released,

⚫ Helps to find exact user requirements:

− Much before a fully working system is
developed.

⚫ Core modules get tested thoroughly:

− Reduces chances of errors in final product.100
 Advantages of Evolutionary Model (2)

⚫ Customers involved in the process:

− Thereforemore likely to meet the user
requirements.

⚫ Early and frequent testing:

− More likely to identify problems.

101
 Evolutionary Model: Problems
⚫ The process is intangible:
− No regular, well-defined deliverables.
⚫ The process is unpredictable:
− Hard to manage, e.g., scheduling, workforce
allocation, etc.
⚫ Systems are poorly structured:
− Continual, unpredictable changes tend to
degrade the software structure.
⚫ Systems may not even converge to a final
version. 102
 Incremental Model

2/7/2026 103
 Incremental Model
⚫ Combines the ideas from Waterfall and
Evolutionary Model.

Requirements Split into

Outline Requirements Design

Develop Validate Integrate Validate

Increment Increment Increment System

Final
System
104
 Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Incremental Model
High Level Analysis

Slice
Slice
105

Slice
 Incremental Model
⚫ Waterfall: single release
⚫ Iterative: many releases (increments)
− First increment: core functionality
− Successive increments: add/fix functionality
− Final increment: the complete product
⚫ Each iteration: a short mini-project with
a separate lifecycle
− e.g., waterfall
106
 Incremental delivery
delivered
system

design build install evaluate increment

1
first incremental delivery

design build install evaluate increment

2
second incremental delivery
increment
design build install evaluate 3
third incremental delivery

107
 The incremental process

Planned Identify System Objectives

incremental
Plan increments
delivery
Incremental delivery plan

Design increment

Build the increment

Repeat for
Feedback
each Implement the increment
increment

Evaluate the results

108
Evolutionary Model With Iteration

109
 Which step first?
⚫ Some steps will be pre-requisite because
of physical dependencies
⚫ Others may be in any order

⚫ Value to cost ratios may be used

− V/C where
− V is a score 1-10 representing value to
customer
− C is a score 0-10 representing cost to
developers 110
 V/C ratios: an example

step value cost ratio

profit reports 9 1 9 2nd
online database 1 9 0.11 5th
ad hoc enquiry 5 5 1 4th
purchasing plans 9 4 2.25 3rd
profit- based pay 9 0 inf 1st
for managers

111
 Incremental and Iterative
Development (IID) Model

2/7/2026 112
⚫ “The basic idea… take advantage of what was
being learned during the development of
earlier, incremental, deliverable versions of
the system. Learning comes from both the
development and use of the system… Start
with a simple implementation of a subset of
the software requirements and iteratively
enhance the evolving sequence of versions. At
each version design modifications are made
along with adding new functional capabilities. “
Victor Basili
113
 Incremental and Iterative Development
(IID)
⚫ Key characteristics
− Consists of a planned number of iterations
− Each iteration produces a working program
− Builds system incrementally
 Monolithic approach of waterfall model
⚫ Benefits
− Facilitates and manages changes
⚫ Foundation of agile techniques
− Rational Unified Process (RUP)
− Extreme Programming (XP) 114
 Evolutionary Model with Iteration

⚫ Outcome of each iteration: tested,

integrated, executable system
⚫ Iteration length is short and fixed
− e.g. 2 weeks, 4 weeks, 6 weeks
− Takes many iterations (e.g. 10-15)

⚫ Does not “freeze” the requirements and

then speculatively design :
− Opportunity to modify requirements as well as
design
− Later iterations become stable
115
 Advantages of evolutionary model with
iteration?
⚫ Can better manage complexity by developing
one increment at a time.
⚫ Can better manage changing requirements.
⚫ Can provide partial solutions throughout the
development process.
⚫ Can get customer feedback and incorporate
them much more efficiently:
− As compared when customer feedbacks come
only after all development is complete.
116
 Advantages of Evolutionary Model with
Iteration

⚫ Training can start on an earlier release

− customer feedback taken into account

⚫ Markets can be created:

− For functionality that has never been
offered by other vendors.

⚫ Frequent releases allow developers to fix

unanticipated problems quickly.
117
 Incremental versus Evolutionary
⚫ Evolutionary iterative development implies
that the requirements, plan, estimates, and
solution evolve or are refined over the
course of the iterations, rather than fully
defined and “frozen” in a major up-front
specification effort before the
development iterations begin. Evolutionary
methods are consistent with the pattern
of unpredictable discovery and change in
new product development.” Craig Larman
118
 RAD Model

2/7/2026 119
 Rapid Application Development (RAD)
Model
⚫ Sometimes referred to as the rapid
prototyping model.
⚫ Major aims:
− Decrease the time taken and the cost incurred
to develop software systems.
− Facilitate accommodating change requests as
early as possible:
⚫ Before large investments have been made in
development and testing. 120
 Important Underlying Principle

• A way to reduce development time

and cost, and yet have flexibility to
incorporate changes:

• Make only short-term plans and make

heavy reuse of existing code.

121
 Methodology

•Plans are made for one increment at

a time.
• The time planned for each iteration is
called a time box.

•Each iteration (increment):

• Enhances the implemented
functionality of the application a
little.
122
 Methodology

• During each iteration,

• A quick-and-dirty prototype-style
software for some functionality is
developed.
• The customer evaluates the prototype
and gives his feedback.
• The prototype is refined based on the
customer feedback.
123
 How Does RAD Facilitate Faster
Development?
⚫ RAD advocates use of specialized tools:
− That supports fast creation of working
prototypes.

⚫ These specialized tools usually support the

following features:
− Visual style of development.
− Use of reusable components.
− Use of standard APIs (Application Program
Interfaces). 124
 Applications for Which RAD is
Suitable

•Customized product developed for one

or two customers only

•Performance and reliability are not

critical.

•The system can be split into several

independent modules.
125
 Application Characteristics that Render
RAD Unsuitable

• Few plug-in components are available

• High performance or reliability

required

• No precedence for similar products

exists

• The system cannot be modularized.

126
 Prototyping versus RAD

•In prototyping model:

• The developed prototype is primarily
used to gain insights into the
solution
• Choose between alternatives
• Elicit customer feedback.

•The developed prototype:

• Usually thrown away. 127
 Prototyping versus RAD

• In contrast:
• In RAD the developed prototype
evolves into the deliverable software.

• RAD leads to faster development

compared to traditional models:
• However, the quality and reliability
would be poorer.
128
 RAD versus Iterative Waterfall Model
⚫ In the iterative waterfall model,
− All product functionalities are developed
together.

⚫ In the RAD model on the other hand,

− Product functionalities are developed
incrementally through heavy code and design
reuse.
− Customer feedback is obtained on the
developed prototype after each iteration:
Based on this, the prototype is refined.
129
⚫
 RAD versus Iterative Waterfall Model

⚫ The iterative waterfall model:

− Does not facilitate accommodating requirement
change requests.
⚫ Iterative waterfall model does have some
important advantages:
− Use of the iterative waterfall model leads to
production of good documentation.
− Also, the developed software usually has
better quality and reliability than that
developed using RAD. 130
 RAD versus Evolutionary Model
⚫ Incremental development:
− Occurs in both evolutionary and RAD models.
⚫ However, in RAD:
− Each increment is a quick and dirty prototype,
− Whereas in the evolutionary model each
increment is systematically developed using the
iterative waterfall model.
⚫ Also, RAD develops software in shorter
increments:
− Compared to the evolutionary model
− The incremental functionalities are fairly large
in the evolutionary model.
131
 Agile Models

2/7/2026 132
Cartoonist’s View: Agile Model

133
 Agile Model
⚫ To overcome the shortcomings of the
waterfall model of development.
− Proposed in mid-1990s

⚫ The agile model was primarily designed:

− To help a project adapt to change requests

⚫ In the agile model:

− The requirements are decomposed into
many small incremental parts that can be
developed over one to four weeks each.
134
 What is Agile Software Development?

⚫ Agile: Easily moved, light, nimble,

active software processes

⚫ How is agility achieved?

− Fitting the process to the project

− Avoidance of things that waste time

135
 Ideology

⚫ Individuals and interactions over

− process and tools [Link]

⚫ Working Software over

− comprehensive documentation

⚫ Customer collaboration over

− contract negotiation

⚫ Responding to change over

− following a plan
136
 Agile Methodologies

⚫ XP

⚫ Scrum

⚫ Unified process

⚫ Crystal

⚫ DSDM

⚫ Lean
137
 Agile Model: Principal Techniques

⚫ User stories:
− Simpler than use cases.

⚫ Metaphors:
− Based on user stories, developers propose a
common vision of what is required.

⚫ Spike:
− A very simple program to explore potential
solutions should be considered.

⚫ Refactor:
− Restructure code without affecting behavior,
improve efficiency, structure, etc. 138
 Agile Model: Nitty Gritty

⚫ At a time, only one increment is planned,

developed, and deployed at the customer site.
− No long-term plans are made.

⚫ An iteration may not add significant

functionality,
− but still a new release is invariably made at the
end of each iteration

− Delivered to the customer for regular use.

139
 Methodology

⚫ Face-to-face communication is favored over

written documents.

⚫ To facilitate face-to-face communication,

− development team to share a single office space.

− Team size is deliberately kept small (5-9 people)

− This makes the agile model most suited to

developing small projects.

140
 Effectiveness of Communication Modes

Face-to-face
at whiteboard
Face-to-face
conversation
Communication Effectiveness

Video
conversation
Modeling
Phone Options
conversation

Videotape
Email
conversation

Audiotape
Documentation
Options
Paper

Cold Hot
Richness of Communication Channel
Copyright 2002-2005 Scott W. Ambler 141
Original Diagram Copyright 2002 Alistair Cockburn
 Agile Model: Principles
⚫ The primary measure of progress:
− Incremental release of working software

⚫ Important principles behind the agile model:

− Frequent delivery of versions every few weeks.
− All change requests to the requirements are
accommodated easily.
− Close cooperation between customers and
developers.
− Face-to-face communication among the
development team members.
142
 Agile Software Requirements Management
High
{ Each iteration implement the highest-
Priority priority requirements

Each new requirement is

prioritized and added to
the stack

Requirements may be
reprioritized at any time

Requirements may be
removed at any time

Low
Priority 143
Requirements Copyright 2004 Scott W. Ambler
 Adoption Detractors
⚫ Lack of theoretical grounding
− Inconsistent and diverse definitions

⚫ High-quality people skills required

⚫ Short iterations inhibit long-term
perspective
⚫ Higher risks:
− Harder to manage feature creep and customer
expectations
− Difficult to quantify cost, time, and quality.144
 Agile Model Shortcomings

⚫ Derive agility through developing tacit

knowledge in the team, rather than any
formal document:
− Can be misinterpreted

− External review difficult to get

− When the project is complete, and the team

disperses, maintenance becomes difficult

145
 Agile vs. Plan-Driven Processes
1. Small products and 1. Large products and
teams: teams;
⚫ Scalability limited ⚫ hard to scale down
2. Untested on safety- 2. Proven for highly critical
critical products products;
3. Good for dynamic, 3. Good for stable:
but expensive for ⚫ But expensive for dynamic
stable environments. environments
4. Require experienced 4. Require only few
personnel throughout experienced personnel
5. Personnel thrive on 5. Personnel thrive on
freedom and chaos
structure and order 146
Agile Model versus Iterative Waterfall Model

⚫ The waterfall model steps through in a planned

sequence over
− Requirements-capture, analysis, design, coding, and
testing stages.

⚫ Progress is measured in terms of delivered

artifacts:
− Requirement specifications, design documents,
test plans, code reviews, etc.

⚫ In contrast agile model :

− Sequences delivery of working versions of a
product in several increments.
147
 Agile Model versus Iterative Waterfall
Model

⚫ As regards to similarity:
− Wecan say that Agile teams use the
waterfall model on a small scale.

148
 Agile versus RAD Model
⚫ Agile model does not recommend developing
prototypes:
− Systematic development of each incremental
feature is emphasized.
⚫ In contrast:
− RAD is based on designing quick-and-dirty
prototypes, which are then refined into
production-quality code.
⚫ Agile projects logically break down the
solution into many features:
− These are incrementally developed and delivered.
149
 Agile versus exploratory programming

⚫ Similarity:
− Frequent re-evaluation of plans,
− Emphasis on face-to-face communication,
− Relatively sparse use of documents.

⚫ Agile teams, however, do follow defined and

disciplined processes and carry out rigorous
designs:
− This is in contrast to chaotic coding in
exploratory programming.
150
 Extreme Programming Model

⚫ Extreme programming (XP) was proposed by

Kent Beck in 1999.

⚫ The methodology got its name from the

fact that:
− Recommends taking the best practices to
extreme levels.
− If something is good, why not do it all the
time?
151
 4 Values
⚫ Communication:
− Enhance communication among team members and
with the customers.

⚫ Simplicity:
− Build something simple that will work today rather
than something that takes time and yet is never
used
− May not pay attention to tomorrow

⚫ Feedback:
− System staying out of users is trouble waiting to
happen

⚫ Courage:
− Don’t hesitate to discard code 152
 Taking to Extreme
⚫ If code review is good:
− Always review --- pair programming

⚫ If testing is good:
− Continually write and execute test cases ---
test-driven development

⚫ If incremental development is good:

− Come up with new increments every few days

⚫ If simplicity is good:
− Create the simplest design that will support
only the currently required functionality. 153
 Taking Good Practices to Extreme
⚫ If code review is good:
− Always review --- pair programming
⚫ If testing is good:
− Continually write and execute test cases ---
test-driven development
⚫ If incremental development is good:
− Come up with new increments every few days
⚫ If simplicity is good:
− Create the simplest design that will support
only the currently required functionality. 154
 Taking to Extreme

⚫ If design is good,
− everybody will design daily (refactoring)

⚫ If architecture is important,
− everybody will work at defining and
refining the architecture (metaphor)

⚫ If integration testing is important,

− build and integrate test several times a
day (continuous integration)

155
 Best Practices
⚫ Coding:
− without code it is not possible to have a
working system.
− Utmost attention needs to be placed on
coding.

⚫ Testing:
− Testing is the primary means for developing
a fault-free product.

⚫ Listening:
− Careful listening to the customers is
essential to develop a good quality product. 156
 Best Practices

⚫ Designing:
− Without proper design, a system
implementation becomes too complex
− The dependencies within the system
become too numerous to comprehend.

⚫ Feedback:
− Feedback is important in learning
customer requirements.

157
 Full List of XP Practices
1. Planning – determine scope of the next release by
combining business priorities and technical
estimates

2. Small releases – put a simple system into

production, then release new versions in a very
short cycle
3. Metaphor – all development is guided by a simple
shared story of how the whole system works
4. Simple design – The system is designed as simply
as possible (extra complexity removed as soon as
found
5. Testing – programmers continuously write unit
tests; customers write tests for features 158
 Full List of XP Practices

7. Refactoring – programmers continuously

restructure the system without changing its
behavior to remove duplication and simplify

8. Pair-programming -- all production code is

written with two programmers on one machine

9. Collective ownership – anyone can change any

code anywhere in the system at any time.

10. Continuous integration – integrate and build the

system many times a day – every time a task is
completed.
159
 Full List of XP Practices

11. 40-hour week – work no more than 40 hours

a week as a rule

12. On-site customer – a user is on the team

and available full-time to answer questions

13. Coding standards – programmers write all

code following rules emphasizing
communication through the code

160
 Emphasizes Test-Driven Development (TDD)

⚫ Based on user story develop test cases

⚫ Implement a quick and dirty feature

every couple of days:
− Get customer feedback

− Alter if necessary

− Refactor

⚫ Take up the next feature

161
Project Characteristics that Suggest Suitability
of Extreme Programming

⚫ Projects involving new technology or

research projects.
− In this case, the requirements change
rapidly and unforeseen technical problems
need to be resolved.

⚫ Small projects:
− These are easily developed using extreme
programming.
162
Scrum
The word comes from the
English sport of rugby. Short
for “scrummage,” scrum is a
method for restarting play
either as a result of a minor
infraction or when the ball has
gone out of bounds. Players
huddle with their heads down
and jockey for control of the
ball.

163
 Scrum: Characteristics

⚫ One of the agile processes

⚫ Self-organizing teams

⚫ Product development progresses in a

series of month-long sprints

⚫ Requirements are listed in a product

backlog
164
 Daily
Scrum

Sprint
Sprint
planning
review
Scrum
Sprint
Product backlog backlog Product
increment

165
 Sprint

⚫ Scrum projects progress in a series of

“sprints”
− Analogous to XP iterations or time boxes
− Target duration is one month
⚫ Software increment is designed, coded, and
tested during a sprint 166

⚫ No changes entertained during a sprint

166
 Sprint
⚫ Fundamental process flow of Scrum

• A month-long iteration, during which an

incremental product functionality
completed

• NO outside influence can interfere with

the Scrum team during the Sprint

• Each day begins with the Daily Scrum

Meeting
167
 Scrum Framework

⚫ Roles : Product Owner, ScrumMaster, Team

⚫ Ceremonies : Sprint Planning, Sprint Review,

Sprint Retrospective, and Daily Scrum
Meeting

⚫ Artifacts : Product Backlog, Sprint Backlog,

168

and Burndown Chart

168
Key Roles and Responsibilities in Scrum Process

⚫ Product Owner
− Acts on behalf of customers to represent their
interests.
⚫ Development Team
− Team of five to nine people with cross-functional
skill sets.
⚫ Scrum Master (aka Project Manager) 169

− Facilitates scrum process and resolves impediments

and acts as a buffer between the team and outside
interference.

169
 Product Owner

⚫ Defines the features of the product

⚫ Decides on release date and content

⚫ Prioritizes new features

⚫ Adjusts features and priority every

iteration, as needed
170

⚫ Accepts or rejects work results.

170
 The Scrum Master

⚫ Represents management

⚫ Removes impediments

⚫ Ensures that the team is fully functional

and productive

⚫ Shield the team from external 171

interferences

171
 Scrum Team

⚫ Typically 5-10 people

⚫ Cross-functional
− QA, Programmers, UI Designers, etc.

⚫ Teams are self-organizing

172

⚫ Membership can change only between

sprints

172
 Ceremonies

⚫ Sprint Planning Meeting

⚫ Daily Scrum

⚫ Sprint Review Meeting

173

173
 Sprint Planning

• The goal is to produce Sprint Backlog

• Product owner works with the Team to
negotiate what Backlog Items the Team will
work on to meet Release Goals

• Scrum Master ensures that the Team agrees

to realistic goals

174
⚫ Daily Daily Scrum
⚫ 15-minutes
⚫ Stand-up meeting
⚫ Not for problem solving

⚫ Three questions:
1. What did you do yesterday 175

2. What will you do today?

3. What obstacles are in your way?

175
 Daily Scrum

• Is NOT a problem-solving session

• Is NOT a way to collect information about

WHO is behind the schedule

• Is a meeting in which team members make

informal commitments to each other and the
Scrum Master 176

• Is a good way for a Scrum Master to track the

progress of the Team

176
⚫ Team presents what it accomplished during
the sprint
⚫ Typically takes the form of a demo of new
features
⚫ Informal Sprint Review
− 2-hour prep time rule
Meeting

⚫ Participants
− Customers
− Management
− Product Owner
− Other teammates
177
 Product Backlog

⚫ A list of all desired work on the project

− Usually a combination of
⚫ story-based work (“allow user to search and
replace”)
⚫ task-based work (“improve exception
handling”)
178

⚫ List is prioritized by the Product Owner.

178
 Product Backlog

⚫ Requirements for a system, expressed

as a prioritized list of Backlog Items

− Managed and owned by Product

Owner
179

− Spreadsheet (typically)

179
Sample Product Backlog

180
 Sprint Backlog

• A subset of Product Backlog Items,

which define the work for a Sprint

– Created by Team members

– Each Item has it’s own status

181

– Updated daily

181
 Sprint Backlog during the Sprint

• Changes occur:
– Team adds new tasks whenever they need to in
order to meet the Sprint Goal
– Team can remove unnecessary tasks
– But: Sprint Backlog is only updated by the
team 182

• Estimates are updated whenever there’s

new information
182
 Burn down Charts

⚫ Are used to represent “work done”.

⚫ Are remarkably simple but effective
Information disseminators

⚫ Three Types:
− Sprint Burn down Chart (progress of the Sprint)
− Release Burn down Chart (progress of release)
183

− Product Burn down chart (progress of the

Product)

183
 Sprint Burn down Chart

⚫ Depicts the total Sprint Backlog hours

remaining per day

⚫ Shows the estimated amount of time to

complete

⚫ Ideally should burn down to zero by the end of

the Sprint 184

⚫ Usually is not a straight line

184
Sprint Burndown Chart

185

185
 Release Burndown Chart

• Will the next release be done on right time?

• How many more sprints?

• X-axis: sprints

• Y-axis: amount of story

186

points remaining

186
 Product Burndown Chart

• Is a “big picture” view of the project’s progress (all

the releases)

187

187
 Scalability of Scrum

⚫ A typical Scrum team is 6-10 people

⚫ Jeff Sutherland proposed and experimented

with up to over 800 people

⚫ "Scrum of Scrums" also called "Meta-

Scrum“
188

188
 Comparison of Different Life Cycle Models

⚫ Iterative waterfall model

− Most widely used model.
− But, suitable only for well-understood
problems.

⚫ Prototype model is suitable for projects

not well understood:
− user requirements
− technical aspects
189
Comparison of Different Life Cycle Models
(CONT.)

⚫ Evolutionary model is suitable for large

problems:
− Can be decomposed into a set of modules that
can be incrementally implemented,
− Incremental delivery of the system is
acceptable to the customer.

⚫ The spiral model:

− Suitable for development of technically
challenging software products that are
subject to several kinds of risks. 190
 Practice Questions

⚫ What are the stages of iterative

waterfall model?
⚫ What are the disadvantages of the
iterative waterfall model?
⚫ Why has agile model become so popular?
⚫ What difficulties might occur if no life
cycle model is followed?

191
 Suggest Suitable Life Cycle Model
⚫ A software for an academic institution to
automate its:
− Course registration and grading
− Fee collection
− Staff salary
− Purchase and store inventory

⚫ The software would be developed by tailoring a

similar software that was developed for
another educational institution:
− 70% reuse
− 10% new code and 20% modification 192
 Practice Questions
⚫ Which types of risks can be better
handled using the spiral model compared
to the prototyping model?

⚫ Which type of process model is suitable

for the following projects:
− A customization software
− A payroll software for contract employees
that would be add on to an existing payroll
software 193
 Practice Questions
⚫ Which lifecycle model would you select for
the following project which has been
awarded to us by a mobile phone vendor:
− A new mobile operating system
− Needs to work well efficiently with 4G systems
− Power usage minimization
− Directly upload backup data on a cloud
infrastructure maintained by the mobile phone
vendor
− Provides sensing many health parameters of the
user and alerting on any abnormality.
194
Thanks

195