Software Life Cycle

Models

1
 Classical Waterfall Model
● Classical waterfall model divides life cycle
into phases:
– feasibility study,
– requirements analysis and specification,
– design,
– coding and unit testing,
– integration and system testing,
– maintenance.

2
Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

3
 Relative Effort for Phases
● Phases between feasibility
study and testing
– known as development phases.
Relative Effort
● Among all life cycle phases
– maintenance phase consumes
maximum effort.

● Among development phases,

– testing phase consumes the
maximum effort.

4
Classical Waterfall
Model

5
1. Classical Waterfall Model
● 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 specific methodologies for:

– specification,
– design,
– testing,
– project management, etc.

6
7
 Feasibility Study
● First roughly understand what the customer
wants:
– different 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.

8
 Activities during Feasibility Study
● Work out an overall understanding of the
problem.
● Main aim of feasibility study:determine whether developing
the product
– financially worthwhile

– technically feasible.

● Formulate different solution strategies.

● Examine alternate solution strategies in terms
of:
● resources required,
● cost of development, and
9
● development time.
 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.

10
Goals of Requirements Analysis
● Collect all related data from the
customer:
– analyze the collected data to clearly
understand what the customer wants,
– find out any inconsistencies and
incompleteness in the requirements,
– resolve all inconsistencies and
incompleteness.

11
 Requirements Gathering
● Gathering relevant data:
– usually collected from the end-users
through interviews and discussions.
– For example, for a business accounting
software:
● interview all the accountants of the
organization to find out their requirements.

12
 Requirements Analysis (CONT.)

● The data you initially collect from

the users:
– would usually contain several
contradictions and ambiguities:
– each user typically has only a
partial and incomplete view of the
system.

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

14
 Design
● Design phase transforms requirements specification:
into a form suitable for implementation in some
programming language.
● In technical terms:
– during design phase, software architecture is derived
from the SRS document.
● Two design approaches:
– traditional approach,

– object oriented approach.

15
 Traditional Design Approach

● Consists of two activities:

– Structured analysis
– Structured design

16
Structured Analysis Activity

● Identify all the functions to be

performed.
● Identify data flow among the functions.
● Decompose each function recursively into
sub-functions.
– Identify data flow among the subfunctions as
well.

17
 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).

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

19
 Object Oriented Design
● First identify various objects (real world
entities) occurring in the problem:
– identify the relationships among the objects.
– For example, the objects in a pay-roll
software may be:
● employees,
● managers,
● pay-roll register,
● Departments, etc.

20
 Object Oriented Design (CONT.)

● Object structure
– further refined to obtain the detailed
design.
● OOD has several advantages:
– lower development effort,
– lower development time,
– better maintainability.

21
 Implementation
● Purpose of implementation phase
(aka coding and unit testing
phase):
– translate software design into
source code.

22
 Implementation

● During the implementation phase:

– each module of the design is coded,
– each module is unit tested
● tested independently as a stand alone unit,
and debugged,
– each module is documented.

23
 Implementation (CONT.)

● The purpose of unit testing:

– test if individual modules work correctly.
● The end product of implementation
phase:
– a set of program modules that have been
tested individually.

24
 Integration and System
Testing
● Different modules are integrated in a
planned manner:
– modules are almost never integrated in one
shot.
– Normally integration is carried out through a
number of steps.

● During each integration step,

– the partially integrated system is tested.

25
Integration and System
Testing

M1 M2

M3 M4

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

27
 Maintenance
● Maintenance of any software
product:
– requires much more effort than
the effort to develop the product
itself.
– development effort to
maintenance effort is typically
40:60.

28
 Waterfall model problems
● Inflexible partitioning of the project
into distinct stages
● This makes it difficult to respond to
changing customer requirements
● No Feedback paths
● Inefficient error corrections

29
 Which is not a software life cycle model?
● (a) Waterfall model (b) Spiral model
● (c) Prototyping model (d) Capability maturity
model

30
SDLC stands for
(a) Software design life cycle
(b) Software development life cycle
(c) System development life cycle
(d) System design life cycle

31
1.1 Iterative Waterfall
Model
Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

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

33
 Iterative Waterfall Model
(CONT.)

● Once a defect is detected:

– we need to go back to the phase where it was
introduced
– redo some of the work done during that and
all subsequent phases.

● Therefore we need feedback paths in the

classical waterfall model.

34
 Iterative Waterfall Model
(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
∙ than say if it is identified at the end of
the integration and system testing phase.

35
 Phase containment of errors
● Reason: rework must be carried out not only to
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.
● Iterative waterfall model is by far the most
widely used model.
– Almost every other model is derived from the
waterfall model.
Phase Overlap

36
 Shortcomings of iterative
Waterfall Model
● Difficult to accommodate change requests.(No
scope for any modifications to the requirements)
● Incremental delivery not supported ( No
intermediate deliveries)
● Error correction unduly expensive (As defects
are noticed at the time of validation only)
● Limited customer interactions
● Heavy weight ( overemphasises documentation)
● No support for risk handling and code reuse
(susceptible to various types of risk and no
support for reusability especially in case of
software service type projects)
37
1.2 V-model

38
 1.3 Prototyping 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.

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

40
 Prototyping Model (CONT.)

● Another reason for developing a

prototype is:
– it is impossible to ``get it right'' the
first time,
– we must plan to throw away the first
product
● if we want to develop a good product.

41
 Prototyping Model (CONT.)

● Start with approximate requirements.

● Carry out a quick design.
● Prototype model is built using several
short-cuts:
– Short-cuts might involve using inefficient,
inaccurate, or dummy functions.
● A function may use a table look-up rather than
performing the actual computations.

42
 Prototyping Model (CONT.)

● The developed prototype is submitted to

the customer for his evaluation:
– Based on the user feedback, requirements
are refined.
– This cycle continues until the user approves
the prototype.
● The actual system is developed using the
classical waterfall approach.

43
 Prototyping Model (CONT.)

Build Prototype

Requirements Customer Customer

Gathering Quick Design Evaluation of satisfied Design
Prototype

Refine Implement
Requirements

Test

Maintain

44
 Prototyping Model (CONT.)

● Requirements analysis and specification phase

becomes redundant:
– final working prototype (with all user feedbacks
incorporated) serves as an animated requirements
specification.

● Design and code for the prototype is usually thrown

away:
– However, the experience gathered from developing the
prototype helps a great deal while developing the actual
product.

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

46
Strength and Weakness

47
 1.4 Incremental
Development Model
C
A AB A
B

A,B and C are modules of a software product that are

incrementally developed and delivered.

48
Incremental Model of
software development

49
 Advantages
● Error reduction

● Incremental resource deployment

50
 1.5 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 system.

● The initial product skeleton is refined into
increasing levels of capability:
– by adding new functionalities in successive versions.

51
1.5 Evolutionary Model

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

53
Advantages of Evolutionary
Model
● Users get a chance to experiment with a partially
developed system:
– much before the full working version is released,
● Helps finding exact user requirements:
– much before fully working system is developed.
● Core modules get tested thoroughly:
– reduces chances of errors in final product.

54
 Disadvantages of
Evolutionary Model
● Often, difficult to subdivide problems
into functional units:
– which can be incrementally implemented
and delivered.
– evolutionary model is useful for very
large problems,
● where it is easier to find modules for
incremental implementation.
● Ad-hoc Design
55
 RAPID APPLICATION DEVELOPMENT
MODEL
Rapid application development, or RAD, was among the first
development methods to challenge traditional waterfall development
practices.

Though often mistaken for a specific model, rapid application

development is the idea that we benefit when we treat our software
projects like clay, rather than steel.

56
5
 “Software is clay, not
steel”
- RAD

57
5
 RAPID APPLICATION
DEVELOPMENT MODEL
The major goals are as follows:

● To decrease the time taken and the cost

incurred to develop software systems.
● To limit the costs of accommodating

change requests.
● To reduce the communication gap

between the customers and the

developers.

58
The Rapid Application Development (RAD) Model

Life Cycle Activites:

With active participation of users

Requirements User Construction Cut over

Planning Description

59

59
 The Rapid Application Development (RAD) Model

Not an appropriate model in the absence of user

participation.

Reusable components are required to reduce development

time.

Highly specialized & skilled developers are required and

such developers are not easily available.

60

60
 Good RAD
Projects
A team building a
● Internal employee RAD pacemaker will
tools struggle to collect
Customer portals user feedback from
the deceased.
●

● B2C applications

● Not so good RAD

projects…
● Mission-critical
software
● Flight controls 61

● Pacemakers…
 Spiral Model
● Proposed by Boehm in 1988.
● Each loop of the spiral represents a phase of the
software process:
– the innermost loop might be concerned with system
feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.

● There are no fixed phases in this model, the

phases shown in the figure are just examples.

62
 Spiral Model (CONT.)

● The team must decide:

– how to structure the project into phases.
● Start work using some generic model:
– add extra phases
● for specific projects or when problems are
identified during a project.
● Each loop in the spiral is split into four
sectors (quadrants).

63
 Spiral Model (CONT.)

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product

64
Spiral model of the software
process

65
 Objective Setting (First
Quadrant)
● Identify objectives of the phase,
● Examine the risks associated with these
objectives.
– Risk:
● any adverse circumstance that might hamper successful
completion of a software project.

● Find alternate solutions possible.

66
 Risk Assessment and Reduction (Second
Quadrant)

● For each identified project risk,

– a detailed analysis is carried out.

● Steps are taken to reduce the risk.

● For example, if there is a risk that the
requirements are inappropriate:
– a prototype system may be developed.

67
 Spiral Model (CONT.)

● Development and Validation (Third quadrant):

– develop and validate the next level of the product.
● Review and Planning (Fourth quadrant):
– review the results achieved so far with the customer
and plan the next iteration around the spiral.
● With each iteration around the spiral:
– progressively more complete version of the software
gets built.

68
 Spiral Model as a meta
model
● Subsumes all discussed models:
– a single loop spiral represents waterfall
model.
– uses an evolutionary approach --
● iterations through the spiral are evolutionary
levels.
– enables understanding and reacting to risks
during each iteration along the spiral.
– uses:
● prototyping as a risk reduction mechanism
● retains the step-wise approach of the waterfall 69

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

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

71
Agile Development
Models
• Extreme programming (XP)
• SCRUM

72
 The Manifesto for
Agile Software Development
“We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
•Individuals and interactions over processes and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”

Kent Beck et al

73
73
What is “Agility”?
● Effective (rapid and adaptive)
response to change
● Effective communication among all

stakeholders
● Drawing the customer onto the team

● Organizing a team so that it is in

control of the work performed

Yielding …
● Rapid, incremental delivery of

software
74
74
Agility and the Cost of
Change

75
75
An Agile Process
● Is driven by customer descriptions of
what is required (scenarios)
● Recognizes that plans are short-lived
● Develops software iteratively with a
heavy emphasis on construction
activities
● Delivers multiple ‘software increments’
● Adapts as changes occur

76
76
Agile Vs. RAD

77
 Extreme Programming (XP)
● The most widely used agile process,
originally proposed by Kent Beck
● XP Planning
– Begins with the creation of “user stories”
– Agile team assesses each story and assigns
a cost
– Stories are grouped to for a deliverable
increment
– A commitment is made on delivery date
– After the first increment “project velocity”
is used to help define subsequent delivery
dates for other increments 78 78
Extreme Programming (XP)

● XP Design
– Follows the KIS principle

– Encourage the use of CRC cards

– For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
– Encourages “refactoring”—an iterative refinement of the
internal program design
● XP Coding
– Recommends the construction of a unit test for a store
before coding commences
– Encourages “pair programming”
● XP Testing
– All unit tests are executed daily

– “Acceptance tests” are defined by the customer and excuted

to assess customer visible functionality
79
79
Extreme Programming (XP)

80
80
 Scrum
● Scrum is an agile method that focuses on
managing iterative development rather than
specific agile practices.
● There are three phases in Scrum.
– The initial phase is an outline planning phase where
you establish the general objectives for the
project and design the software architecture.
– This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
– The project closure phase wraps up the project,
completes required documentation such as system
help frames and user manuals and assesses the
lessons learned from the project.
●
81
81
 Scrum terminology (a)

Scrum term Definition

Development team A self-organizing group of software developers, which should be no more than 7
people. They are responsible for developing the software and other essential
project documents.
Potentially shippable The software increment that is delivered from a sprint. The idea is that this
product increment should be ‘potentially shippable’ which means that it is in a finished state and no
further work, such as testing, is needed to incorporate it into the final product. In
practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories or
descriptions of supplementary tasks that are needed, such as architecture
definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product features
or requirements, prioritize these for development and continuously review the
product backlog to ensure that the project continues to meet critical business
needs. The Product Owner can be a customer but might also be a product
manager in a software company or other stakeholder representative.
82
 Scrum terminology (b)

Scrum term Definition

Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of as
a project manager. Others, however, may not always find it easy to see the
difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover in a
single sprint. Understanding a team’s velocity helps them estimate what
can be covered in a sprint and provides a basis for measuring improving
performance.

83
Scrum sprint cycle

84
85
 The Scrum sprint cycle
● Sprints are fixed length, normally 2–4
weeks.
● The starting point for planning is the
product backlog, which is the list of
work to be done on the project.
● The selection phase involves all of the
project team who work with the
customer to select the features and
functionality from the product backlog
to be developed during the sprint.
86
 The Sprint cycle
● Once these are agreed, the team organize
themselves to develop the software.
● During this stage the team is isolated from
the customer and the organization, with all
communications channelled through the
so-called ‘Scrum master’.
● The role of the Scrum master is to protect
the development team from external
distractions.
● At the end of the sprint, the work done is
reviewed and presented to stakeholders. The
next sprint cycle then begins.
87
87
 Teamwork in Scrum
● The ‘Scrum master’ is a facilitator who
arranges daily meetings, tracks the backlog of
work to be done, records decisions, measures
progress against the backlog and communicates
with customers and management outside of
the team.
● The whole team attends short daily meetings
(Scrums) where all team members share
information, describe their progress since the
last meeting, problems that have arisen and
what is planned for the following day.
– This means that everyone on the team knows what
is going on and, if problems arise, can re-plan 88
short-term work to cope with them.
 Scrum benefits
● The product is broken down into a set of
manageable and understandable chunks.
● Unstable requirements do not hold up
progress.
● The whole team have visibility of everything
and consequently team communication is
improved.
● Customers see on-time delivery of increments
and gain feedback on how the product works.
● Trust between customers and developers is
established and a positive culture is created in
which everyone expects the project to
succeed. 89
89
 Comparison chart
Factors Waterfall Evolutionary Spiral Iterative and Agile
Prototyping Incremental
Unclear User Poor Good Excellent Good Excellent
Requirement

Unfamiliar Technology Poor Excellent Excellent Good Poor

Complex System Good Excellent Excellent Good Poor

Reliable system Good Poor Excellent Good Good

Short Time Schedule Poor Good Poor Excellent Excellent

Strong Project Excellent Excellent Excellent Excellent Excellent

Management

Cost limitation Poor Poor Poor Excellent Excellent

Visibility of Good Excellent Excellent Good Excellent

Stakeholders
Skills limitation Good Poor Poor Good Poor

Documentation Excellent Good Good Excellent Poor

Component reusability Excellent Poor Poor Excellent Poor

90
 References
● Fundamentals of software engineering, Rajib Mall
PHI Learning Pvt. Ltd., 2018.
● Software Engineering: A Practitioner's Approach
9th Edition by Roger S. Pressman, Bruce R.
Maxim,2019.

91