Chapter-2

Software Life Cycle Models

Presented By
Dr. Sasmita Rani Behera
1
 Software Life Cycle
• A life cycle model prescribes the different activities
that need to be carried out to develop a s/w product &
the sequencing of these activities.
• The s/w life cycle is also sometimes referred to as the
systems development life cycle (SDLC) by some
author.
• Software life cycle (or software process):
– series of identifiable stages that a software
product undergoes during its life time:
• Feasibility study
• requirements analysis and specification,
• design,
• coding,
• testing
• maintenance. 2
 Life Cycle Model
• Almost every business organization carries out its
business through some sequence of well-defined
steps (called business process).
• Similarly, manufacturing industry follow certain
steps (called manufacturing process) to develop
their product.
• Software life cycle can be considered as the
business process for s/w development, and
therefore a s/w life cycle is also often referred to
as a s/w process.

3
 Why Life Cycle Model ?
• A written description:
– forms a common understanding of
activities among the software developers.
– helps in identifying inconsistencies,
redundancies, and omissions in the
development process.

4
 Life Cycle Model
• The 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.
• When a program is developed by a single
programmer :
– he has the freedom to decide his exact steps.

5
 Life Cycle Model (CONT.)

• When a software product is being

developed by a team:
– there must be a precise understanding among
team members as to when to do what,
– Otherwise, it would lead to project failure.

• A life cycle model:

– defines entry and exit criteria for every phase.
– A phase is considered to be complete:
• only when all its exit criteria are satisfied.

6
 Advantages Life Cycle Model
• It becomes easier for software project
managers:
– to monitor the progress of the project.
• When a life cycle model is adhered to,
– the project manager can at any time fairly
accurately tell,
• at which stage (e.g., design, code, test, etc. ) of
the project is.
– Otherwise, 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.
7
 Life Cycle Model (CONT.)

• Many life cycle models have been proposed.

• We will confine our attention to a few important
and commonly used models.

1. Classical waterfall 7. RAD

2. Iterative waterfall, 8. Agile
3. V-Model, 9. Extreme
4. Prototyping, 10. Scrum
5. Incremental 11. Spiral
6. Evolutionary

8
 Classical Waterfall Model
• Classical waterfall model divides the life
cycle into 6 different phases:
– feasibility study,
– requirements analysis and specification,
– design,
– coding and unit testing,
– integration and system testing,
– maintenance.

9
 Classical Waterfall Model
Feasibility Study

Req. Analysis & specification

Design

Coding & unit testing

Integration & system testing

Maintenance
10
 Relative Effort for Phases
• Phases between feasibility
60
study and testing
– known as development phases. 50
• Among development phases, 40
– testing phase consumes the 30
maximum effort.

% Effort
20
• Among all life cycle phases
– maintenance phase consumes 10
maximum effort.
0

Maintenance
Design
Req. Sp

Test
Coding
Phases

11
 Feasibility Study
• Main aim of feasibility study: determine whether
developing the product
– financially worthwhile
– technically feasible.

• 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 behaviour of the system.

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

• Perform a cost/benefit analysis:

– to determine which solution is the best.
– you may determine that none of the solutions
is feasible due to:
• high cost,
• resource constraints,
• technical reasons. 13
 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.

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

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

• Engineers doing requirements analysis and

specification:
– are designated as analysts.

16
 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.
• Ambiguities and contradictions:
– must be identified
– resolved by discussions with the customers.
• Next, requirements are organized:
– into a Software Requirements Specification (SRS)
document.

17
 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:
Structured Analysis
– traditional approach
Structured Design
– Object-oriented approach.

18
 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 sub functions as well.
• 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).
19
 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.

20
 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:
1. employees, 2. managers,
3. pay-roll register, 4. Departments, etc.
• 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.
• 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.
• 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.
22
 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.

M1 M2

M3 M4
23
 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.
There are three kinds of system testing:
1. α-testing:- It is performed by the development team.
2. β-testing:- It is performed by a friendly set of customers.
3. Acceptance testing:- It is performed by the customer himself
after the product delivery to determine whether to accept or reject
the delivered product.

24
 Maintenance
• Maintenance of any software product:
– requires much more effort than to develop the product itself.
– development effort to maintenance effort is typically 40:60.
• Corrective maintenance:
– Correct errors which were not discovered during the product
development phases.
• Perfective maintenance:
– Improve performance of the system
– enhance functionalities of the system.
• Adaptive maintenance:
– Port software to a new environment,
• e.g. to a new computer or to a new operating system.

25
 Motivation of Iterative Waterfall Model
• 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.

• Defects usually get detected much later in the

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

26
 Motivation of Iterative Waterfall Model
• 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.

27
Iterative Waterfall Model (CONT.)
 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.

29
 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 the most widely used
model.
– Almost every other model is derived from the waterfall
model.

30
 Phase Overlap
• As some errors are detected in the later phase,
which leads to reworked.
• So, we can’t say completion of the activities
means completion of the phase, resulting phase
overlap.
• Benefit- When a developer completes his work
early, can proceed to the next phase without
waiting for the other members to complete.

31
 Phase Overlap

Requirements analysis and specification

Feasibility study

Testing
Coding
Effort

Design

Time

Fig- Distribution of effort for various phases in the iterative waterfall model
32
 V-Model
• The model is named with its visual appearance.
• In every phase of development:
–Testing activities (verification and validation)
are planned in parallel with development results
reduction of the bugs.
• The left half of the model comprises of the
development phases and right half comprises of
validation phases.
• Suitable for the safety-critical software which
requires high reliability.

33
 Advantages of V-Model
• This model leads to a shorter testing phase.
• Here the product development is faster compared
with the iterative model.
• Here manpower utilization is more efficient, as
the testing team is occupied throughout the
development cycle.
• The test team do effective testing of the software,
as they are involved from the beginning and good
understanding of the development artifacts.

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

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

37
 Prototyping Model (CONT.)

• The third 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.

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

39
 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
iterative waterfall approach.

40
 Prototyping Model (CONT.)

Requirements
Gathering Build Prototype
Acceptance by
Customer
Customer
Quick Design Evaluation of
Prototype
Design
Refine
Requirements Implement
incorporating
customer
suggestions Test

Maintain

41
 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.
• 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.

42
 Incremental Development Model
• Incremental development 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.

43
 Incremental Development Model
• 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.
C

A A A
B B

Fig:- Incremental development model of a S/W product

A, B, C are modules of a S/W product that are incrementally

developed and delivered.
44
 Version n
Design

Code
Requirement Test
Specification Version 2
Full
Design Deploy
Software
Developed
Code

Test
Version 1

Design Deploy

Code

Test

Fig: Incremental Model of Software Development Deploy

 Advantages of Incremental 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.

46
Disadvantages of Incremental Model
• Often, difficult to subdivide problems
into functional units:
– which can be incrementally implemented
and delivered.
– It is useful for very large problems,
• where it is easier to find modules for
incremental implementation.

47
 Evolutionary Model with Iteration
• The requirements, plan, estimates and solutions
evolve over iteration.
• It is referred as design a little, build a little, test a
little, deploy a little model.
• Well suited for the object-oriented software
development projects.
• Several advantages:
– Effective elicitation of actual customer requirements
– Easy handling change requests
• Several disadvantages:
– Feature division into incremental parts can be non-trivial
– Ad hoc design
48
Rough Requirements Specification

Identify the core & other parts to be developed

incrementally

Develop the core part using an iterative waterfall

model

Collect customer feedback & modify

requirements
Delivery of the
next version to
the customer

Develop the next identified features using an

iterative waterfall model
All features complete
Maintenance

Fig: Evolutionary model of S/W development

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.

• Make only short term plans and make heavy reuse of

existing code.
• 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.

50
 (RAD) Model
• During each iteration:
– A quick-and-dirty prototype-style software for some selected
functionality is developed.
– The customer evaluates the prototype and gives his feedback.
– The prototype is refined based on the customer feedback.
• RAD achieves fast creation of working prototypes.
• Through use of specialized tools.
• These specialized tools usually support the following
features:
–Visual style of development.
–Use of reusable components.
–Use of standard APIs (Application Program Interfaces).
51
 (RAD) Model
• For which Applications is RAD 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.

52
 Extreme Programming Model
• Extreme programming (XP) was proposed by Kent Beck in 1999.
• Taking good practices to extreme
1. If code review is good:
– Always review ---pair programming
2. If testing is good:
– Continually write and execute test cases ---test-driven development
3. If incremental development is good:
– Come up with new increments every few days
4. If simplicity is good:
– Create the simplest design that will support only the currently required
functionality.

53
 Extreme Programming Model
• Taking good practices to extreme
5. If design is good,
– everybody will design daily (refactoring)
6. If architecture is important,
– everybody will work at defining and refining the architecture
(metaphor)
7. If integration testing is important,
– build and integrate test several times a day (continuous
integration)

54
 Extreme Programming Model
• XP activities for Software Development process
• 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.
• 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.
55
 Scrum Model
• Here, a project is divided into small parts of work that can be
incrementally developed and delivered over time boxes that
are called sprints.
• The software developed over a series of manageable
chunks.
• Each sprint took some couple of weeks to complete.
• At the end of each sprint:
– Stakeholders and team members meet to discuss the progress.
– Stakeholders suggest, if any progress is needed.
• Here the team members assumes three fundamental roles:
1. Software owner - communicating the customer vision to the
development team.
2. Scrum master – acts as a liaison between the software owner and the
team.
3. Team member 56
 Agile Model
• Agile: Easily moved, light, nimble, active software processes
• How agility achieved?
–Fitting the process to the project
–Avoidance of things that waste time
• The agile model was primarily designed:
–To help projects to 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.
• At a time, only one increment is planned, developed,
deployed at the customer site.
–No long-term plans are made.

57
 Methodology of Agile Model
• Face-to-face communication favoured 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 the development of small
projects.

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

• 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).
59
 Spiral Model (CONT.)

1. Determine
Objectives & 2. Identify &
identify Resolve Risks
alternative
solutions

4. Customer
Evaluation of 3. Develop the
Prototype & Next Level of the
plan for the Product
next phase

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

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

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

63
 Comparison of Different Life Cycle Models
• Classical waterfall model
– It can’t be used in practical development projects, since this model
supports no mechanism to handle the errors committed during any
of the phases.
• 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
• 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. 64