Life Cycle Models

-2-
PROCESS MODELS
(PROJECT LIFE CYCLE MODELS)
Software Process Models 1

What is Software Life Cycle Models ?
 Descriptive and diagrammatic representation of the
software life cycle.
 Represents all the activities required to make a software

product transit through its life cycle phases.
 Therefore, it is a series of identifiable stages that a

software product undergoes during its lifetime.
 A software life cycle model is often referred to as

software process model.

Why use a Life Cycle Model ?
 Encourages development of software in a systematic and

discipline manner.
 For a team project - tells when to do what.
 If we are not following any Life Cycle Model – project

failure is guaranteed.

CLASSIC WATERFALL MODEL
Investigation,
Feasibility study
Requirement
analysis, design
Coding & unit

testing
Integration &
system testing
Maintenance

PHASE WISE EFFORTS REQUIREMENT
Requirement analysis 2%
Design 12%
Coding & unit testing 8%
Int. & system testing 20%
Maintenance 58%

Feasibility Study
 Statement of the problem (problem/opportunity)
 Summary of findings & recommendations
 Details of finding
o Methods
o Procedures
o Output reports
o File structures
o Cost & benefit analysis
 Recommendations & conclusions
o Personnel assignment
o Cost
o Project schedule & target dates
Requirement analysis
 Detailed study of the business needs of the
organization.
 Options for changing the business process may
be considered.
 Analysis gathers the requirements for the
system.
 Analyze in detail the information needs of end
users.
 Develop the logical input, processing, output,
data storage and control requirements of the
system to meet user needs.
 Develop specifications for HW, SW, People, data
resources.

Design
 Focus on
High level design (macro level requirements)
Low level design (individual programs to work)
Interface design (how do interfaces look like)
Data design (what data will be required)
 Define software overall structure
 Derive the software architecture from SRS document
o Traditional design approach
• Structured analysis of requirement (identify
functions)
• Structured design (data flow diagrams)
o Object-oriented approach (identify objects in
problem and solution domain and identify the
relations between the objects)
Coding & Unit testing
 Translate the software design into source code.
 Each component of the design is implemented as a
program module.
 The program modules are tested individually.
 A coding standard is used.
 A template to lay out the function, module headers,
commenting guidelines, variable and function naming
convention, maximum number of source lines permitted
in each module are considered.
 Each module testing in isolation is conducted to debug
the errors and smooth running of the module.
 Unit testing should have precise test case definition,
testing criteria and management of test cases.

Integration and System testing
 After coding and unit testing, different modules are integrated
in a planned manner.
 Integration is carried out incrementally in a number of steps.
 The integrated part is added to a partial system, then it is
system tested till all the modules are integrated into the
system.
 The goal of system testing is to ensure that the developed
system confirms to its requirements laid down in SRS.
 α-testing: the system testing performed by
development team.
 Β-testing: the system testing by a friendly set of
customers.
 acceptance testing: the system testing performed by
the customer himself after the product delivery to
accept/reject the software product.

System test plan
 System testing is carried out as per the plan document.

 Test plan identifies all testing-related activities to perform,
specifies the testing schedule, allocates the resources.
 The plan lists all the test cases and expected outputs.
 System test plan is documented after the requirement
specification is made. The document is called test report.
 Test report summarizes the outcome of all testing
activities those are carried out in the testing phase.

Maintenance
This phase requires maximum effort as compared to the
effort necessary to develop the software product. The
effort to develop and maintain the software is roughly
40:60. This phase involves in one or more of the
following activities:
 Corrective maintenance: to correct errors that were
not discovered during product development phases.
 Perfective maintenance: to enhance the
functionalities of the system according to the
customer requirements.
 Adaptive maintenance: porting the software to work in
a new environment. (ex- port the system to work on
another platform/operating system).

• The main drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway. One phase has to be completed before
moving onto the next phase. Phases are rigid.
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Therefore, this model is only appropriate when the
requirements are well-understood and changes will be
fairly limited during the design process.
• Few business systems have stable requirements.
Difficult to handle all types of risks.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
Advantages
• In this model, the software is developed in a very
systematic manner.
• There is a distinct compartmentalization between various
phases. Therefore, no overlapping of activities. High
clarity.
• Proper planning of resources and distribution of efforts
can be done.
• Though time consuming, after the development we can
expect a perfect product.
• The feedback mechanism help the system to come error
free.

Phase containment of errors
 It is the principle of detecting errors as close to their points of
introduction as possible.
 Detecting an error at a later phase will incur higher cost.
 It is desirable to detect the error in the same phase.
 Since all the errors can not be detected in the same phase,
they should be detected as early as possible.
Requirement analysis
Design
Testing
Feasibility study
Coding
Effort
Time
ITERATIVE WATERFALL MODEL
Feasibility
study.
Requirement
Analysis &
specification
Design
Coding &
unit testing
Integration &
system testing
Maintenance
Investigation Planning Architecture Code Enhance

Exploration Requirement Details Debug Adapt & Fix
Definition
(PFR) Product (PDR) (PRR) Product
feasibility Preliminary (SCR) Source Release (PPM) Project
Review Design Review Code Review Review Postmortem
(SRR) Software (CDR) Critical (ATR) Acceptance
Requirement Design Review Test Review
Review
Prototyping Model
 Suggest that before carrying out the development of
actual software, a working prototype of the system
should be built.
 Therefore, a prototype is a toy implementation of the

system – “Demo Version”.
 Exhibits limited functional capabilities, low reliability,

and inefficient performance compared to the actual
software.
 Built using several shortcuts.

Prototyping Model
 Basic Notion :
 Begins with Requirements Gathering.
 A ‘Quick Design’ is followed.
 A prototype is made, i.e. a working model of a system.
 The developed prototype is submitted to the customer for his
evaluation.
 A prototype can serve as ‘the first system’ and may be
discarded.
 Based on the customer feedback, the requirements are
refined & the prototype is modified. This is a cyclic process
and continues till the customer approves the prototype.
 Then the actual system is developed using iterative waterfall
approach.
Requirement
gathering
PROTOTYPING MODEL
Quick design
Refine requirements taking Build

customer suggestion prototype
Customer evaluation of
prototype
Accepted by customer
Design
Implement
(Coding)
Test
Maintain
Prototyping Model
 Need for a prototype in software development :
 For better understanding of the customer’s needs.
 Requirements are hard to formulate, i.e. unclear or

fuzzy.
 Feasibility of a project may be questionable, i.e.

impossible to get the perfect product in the first
attempt.
 When the technical solutions are unclear to the

development team.
Advantages
 Being Real and Tangible
o Satisfying client's (I will know it when I see it) manner
o The client can look at and try out.
o A basis for concrete comparisons and specific
requirements.
 Extracting correct and precise requirements, and

hence making sure the client gets the system
wanted.
 Creating a common reference point for both the client
and developers
 Cultivating the client participation and commitment to
the project.

Drawbacks
 Creating a False Belief
o The prototype is the final product.
o Delivery of the final product is almost immediate.
 Overselling the Prototype
o May lead the client to expect more from the final
system.
 More Difficult Management and Control
o Specific phases, milestones and deliverables are
lacking.
o Assessing the actual progress is harder.

EVOLUTIONARY MODEL
 Referred to as the successive versions model and also known

as the incremental model.
 Software is broken down into several functional units.

C
 At first, develops the core modules.
 Then, adding new functionalities in each successive version –

that’s why it is called EVOLUTIONARY MODEL.
 Each evolutionary version developed using an iterative

waterfall model.

EVOLUTIONARY MODEL
A C
A A
B B
C
A, B, C are modules of a software product that are incrementally developed

and delivered. Consider that A is a core module and B and C are additional
functionality modules.

EVOLUTIONARY MODEL
Rough requirements specification
Identify the core and other parts to be

developed incrementally
Develop the core part using an iterative

waterfall model
Collect customer feedback and modify

requirements
Develop the next identified features using an

iterative waterfall model
All features complete
Maintenance

EVOLUTIONARY MODEL
 Evolutionary Process Model also viewed as-
 Iterative Process
 Enables S/W engineers to develop increasingly more
complete versions of software.
 Incremental Model
 It combines linear sequential model with prototyping.
 Each linear sequence produces a deliverable
‘increment’ of the software.
• Often bases on Functional Completeness
• The first increment is often a core product.
 Useful when staffing is unavailable for a complete
implementation.
c

EVOLUTIONARY MODEL
Advantages :
 User gets a chance to experiment with a partially
developed software.
 Helps to accurately elicit user requirements during

C
the delivery of the different version of the software.
 Reducing chances of errors in the core modules of

the final product.
 Very popular for object-oriented software.

EVOLUTIONARY MODEL
Drawbacks :
 Difficult to divide the problem into several functional

units which can be incrementally implemented.
C
 Useful for only very large product.

SPIRAL MODEL
1. Determine
objectives & identify 2. Identify and
alternative solutions resolve risks
4. Review and plan 3. Develop the next

for the next phase level of the product

SPIRAL MODEL
 Process is represented as a spiral rather than as a sequence

of activities.
 Number of loops in the spiral is not fixed.

C
 Each loop in the spiral represents a phase in the process

(e.g., innermost loop concerned with feasibility study).
 Exact number of phase is not fixed – may vary from project

to project (e.g., design phase needs 3 or 4 consecutive loops
for some project).

SPIRAL MODEL
 Each phase is split into four sectors.
 Spiral model can be viewed as a meta model –
 A single-loop spiral actually represents the waterfallCmodel.

 Uses prototyping approach – as a risk reduction mechanism.
 Supports evolutionary model - With each iteration around
spiral, progressively gets a more complete version of
software.

SPIRAL MODEL AS PROTOTYPING MODEL

SPIRAL MODEL AS FRAMEWORK ACTIVITIES

SPIRAL MODEL AS WATERFALL & EVOLUTIONARY MODEL

SPIRAL MODEL
 When to use spiral model:
 When the project is large.
 Where the software needs continuous risk evaluations.
 Requirements are a bit complicated and require

continuous clarification.
 Software requires significant changes.
 Where enough time frame is their to get end user feedback.
 Where releases are required to be frequent.

SPIRAL MODEL
Advantages :
 Generates working software quickly and early during the
software life cycle.
C
 More flexible – exact number of phase is not fixed.
 Easier to test and debug during a smaller iteration.
 Easier to manage risk because risks are identified and
handled during each iteration.

SPIRAL MODEL
Disadvantages :
 Each phase of an iteration is rigid.
 Problems may arise pertaining to system architecture
because not all requirements are gathered up front for the
entire software life cycle. C

RAD Model
 A high-speed adaptation of the Linear Sequential
 Process model in which rapid application development
is achieved.
 To create a fully functional system within very short time
periods, e.g. 60 to 90 days.
 Effective Situation
 If the business application can be modularized in a way
that each major function to be completed in less than 3
months.
 Not all types of applications are appropriate for RAD-
 If the system cannot be properly modularized.
 If high performance is required, and performance is
tuned separately.
 When technical risks are high.
RAD Model

RAD Model
Advantages
 Short development time.
 Cost reduction due to software reuse and component-
based construction.

RAD Model
 Drawbacks
 For large projects, RAD requires sufficient human
resources to create the right number of RAD teams.
 RAD requires a high level of commitment to rapid-
fire activities.
 RAD requires developers and customers who are
committed to the schedule.
 Not appropriate projects with high technical risk and
new technologies.

COMPARISON OF DIFFERENT LIFE CYCLE MODELS
 Classical Waterfall model:

 Basic model – can't be used for practical development
projects.
 No mechanism to handle errors committed during any
phase.
 Monolithic approach.
 Iterative Classical model:

 Handling error problem can overcome in Iterative model.
 Widely used.
 Suitable for well-understood problems.
 Lengthy development process.

 Evolutionary model:
 Suitable for large problems that can be decomposed into a
set of modules for incremental development and delivery.
 Widely used for object-oriented development project.
 Customer feels the product is getting developed and get
adjusted to the new product.
 Budget allocation by phases is possible.
 Prototyping model:
 Good for projects having no well-defined user
requirements.
 Popular for user-interface part of the project. Product is
immediately visible.
 Spiral model:
 Meta model as it encompasses all other life cycle models.
 Risk handling is inherently in-built.
 Suitable for development of technically challenging
software products.
 Model is more complex than others.

Life Cycle Models

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Life Cycle Models

Загружено:

Авторское право:

Доступные форматы

-2-

Software Process Models 1

 Represents all the activities required to make a software

 Therefore, it is a series of identifiable stages that a

 A software life cycle model is often referred to as

Software Process Models 2

 Encourages development of software in a systematic and

 For a team project - tells when to do what.

 If we are not following any Life Cycle Model – project

Software Process Models 3

Coding & unit

Software Process Models 4

Software Process Models 5

Software Process Models 7

Software Process Models 9

Software Process Models 10

 System testing is carried out as per the plan document.

Software Process Models 11

Software Process Models 12

Software Process Models 14

Investigation Planning Architecture Code Enhance

 Therefore, a prototype is a toy implementation of the

 Exhibits limited functional capabilities, low reliability,

 Built using several shortcuts.

Software Process Models 17

Refine requirements taking Build

 For better understanding of the customer’s needs.

 Requirements are hard to formulate, i.e. unclear or

 Feasibility of a project may be questionable, i.e.

 When the technical solutions are unclear to the

 Extracting correct and precise requirements, and

Software Process Models 22

Software Process Models 23

 Referred to as the successive versions model and also known

 Software is broken down into several functional units.

 At first, develops the core modules.

 Then, adding new functionalities in each successive version –

 Each evolutionary version developed using an iterative

Software Process Models 24

A, B, C are modules of a software product that are incrementally developed

Software Process Models 25

Identify the core and other parts to be

Develop the core part using an iterative

Collect customer feedback and modify

Develop the next identified features using an

Software Process Models 26

Software Process Models 28

 Helps to accurately elicit user requirements during

 Reducing chances of errors in the core modules of

 Very popular for object-oriented software.

Software Process Models 29

 Difficult to divide the problem into several functional

 Useful for only very large product.

Software Process Models 30

4. Review and plan 3. Develop the next

Software Process Models 31

 Process is represented as a spiral rather than as a sequence

 Number of loops in the spiral is not fixed.

 Each loop in the spiral represents a phase in the process

 Exact number of phase is not fixed – may vary from project

Software Process Models 32

 Each phase is split into four sectors.

 Spiral model can be viewed as a meta model –