Life Cycle Models

1
 Software
Conceptualiz
e Life Cycle
Retire Specify

Design
Maintain

Deliver Code

Test

2
 Life Cycle Model
• A software life cycle model (also process
model or SDLC):
–A descriptive and diagrammatic model of
software life cycle:
– Identifies all the activities undertaken during
product development,
– Establishes a precedence ordering among the
different activities,
– Divides life cycle into phases. 3
 Life Cycle Model (CONT.)

• Each life cycle phase consists of

several activities.
–For example, the design stage might
consist of:
• structured analysis
• structured design
• Design review
4
 Why Model Life Cycle?
• A graphical and written description:
– Helps 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.

5
 Life Cycle Model (CONT.)

• 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.
6
 Life Cycle Model (CONT.)

• When a program is developed by a single

programmer ---
– The problem is within the grasp of an individual.

– He has the freedom to decide his exact steps and still

succeed --- called Exploratory model--- One can use it in
many ways Fix

– CodeTest Design Initial

Test
Coding Do Until
Done
– CodeDesign Test  Change Code 

– Specify code Design Test  etc.

7
 Life Cycle Model (CONT.)

• When software 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 chaos and project

failure.
8
 Life Cycle Model (CONT.)

• A software project will never succeed if:

– one engineer starts writing code,
– another concentrates on writing the test
document first,
– yet another engineer first defines the file
structure
– another defines the I/O for his portion first.
9
 Phase Entry and Exit Criteria

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

10
 Life Cycle Model (CONT.)

• What is 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.
11
 Life Cycle Model: Milestones

• Milestones help software project

managers:
–Track the progress of the project.
–Phase entry and exit are
important milestones.

12
 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.
13
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.
14
 Project Deliverables: Myth and Reality
Myth:
The only deliverable for a successful project is
the working program.
Reality:
Documentation of all aspects of software
development are needed to help in
operation and maintenance.
15
• Many life cycle models have been proposed.
• We confine our attention to only a few commonly
used models.
– Waterfall Life Cycle Model (CONT.)

– V model,
– Evolutionary, Traditional models
– Prototyping
– Spiral model,
– Agile models
16
• 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, Software Life Cycle
• Testing
• Maintenance. 17
 Classical Waterfall Model
• Classical waterfall model divides life
cycle into following phases:
– Feasibility study, Conceptuali
ze
Retire Specify
– Requirements analysis and
Design
specification,
Maintai
n

– Design, Deliver Code

– Coding and unit testing, Test

– Integration and system testing,

– Maintenance. 18
 Classical Waterfall Model
Feasibility Study

Simplest and most

Req. Analysis
intuitive
Design

Coding

Testing

Maintenance
19
 Relative Effort for Phases
• Phases between feasibility study
and testing 60
50
– Called development phases.

Relative Effort
40

• Among all life cycle phases 30

20
– Maintenance phase consumes 10

Maintnce
Design
maximum effort.

Req. Sp
0

Coding
Test
• Among development phases,
– Testing phase consumes the
maximum effort.
• 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,
Process Model
– Design,
– Testing,
– Project management, etc.
 Classical Waterfall Model (CONT.)
• 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. 22
Feasibility Study Economic
feasibility
(also
called
cost/benef
it
feasibility)

Technica Feasibilit Schedul

l
y e
feasibilit Dimensi feasibilit
ons
y y

23
• Main aim of feasibility study: determine
whether developing the software is:
– Financially worthwhile Feasibility Study
– Technically feasible.
First Step
• Roughly understand what 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. 24
• SPF Scheme for CFL
• CFL has a large number of employees, exceeding
50,000.
• Majority of these are casual labourers
• Mining being a risky profession:
– Casualties are high
• Though there is a PF:
Case Study
– But settlement time is high
• There is a need of SPF:
– For faster disbursement of benefits
25
 Feasibility: Case Study
• Manager visits main office, finds out the
main functionalities required
• Visits mine site, finds out the data to be
input
• Suggests alternate solutions
• Determines the best solution
• Presents to the CFL Officials
• Go/No-Go Decision
26
 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. 27
• 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, Activities during
• resource constraints, Feasibility Study

• technical reasons.

28
 Cost benefit analysis (CBA)
• Need to identify all costs --- these could be:
– Development costs
– Set-up
– Operational costs
• Identify the value of benefits

• Check benefits are greater than costs

29
 The business case
• Benefits of delivered
Benefits project must outweigh
costs
Costs • Costs include:
- Development
Rs - Operation
Rs
• Benefits:
– Quantifiable
– Non-quantifiable
30
 The business case
• Feasibility studies should help write a
‘business case’
• Should provide a justification for starting
the project
• Should show that the benefits of the
project will exceed:
– Various costs
• Needs to take account of business risks 31
1. Executive summary
2. Project background:
 The focus must be on what, exactly, the project is undertaking, and should
not be confused with what might be a bigger picture.

3. Business opportunity
- What difference will it make? Writing an Effective
Business Case
- What if we don’t do it?

4. Costs
- Should include the cost of development, implementation, training, change
management, and operations.

5. Benefits
 Benefits usually presented in terms of revenue generation and cost
reductions.

6. Risks
− Identify risks.
− Explain how these will be managed.
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
 Requirements Analysis and Specification
• Gather requirements data from the
customer:
 Analyze the collected data to understand what
customer wants
• Remove requirements problems:
 Inconsistencies
 Anomalies
 Incompleteness
• Organize into a Software Requirements
Specification (SRS) document. 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 accountants of the
organization to find out their requirements.
36
 Requirements Analysis (Cont...)

• The data you initially collect from the

users:
–Usually contain 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
Feasibility Study
Classical
Req. Analysis
Waterfall Model

Design
Design

Coding

Testing

Maintenance

39
 Design
• During design phase requirements
specification is transformed into :
– A form suitable for implementation in
some programming language.
• Two commonly used design
approaches:
–Traditional approach,
–Object oriented approach 40
 Traditional Design Approach

• Consists of two activities:

–Structured analysis (typically carried

out by using DFD)

–Structured design
41
 Structured Design
root
• High-level design:
order query

– decompose the system into inden

t

modules, Handle-
order
Handle-
indent
Handle-
query

– represent invocation
relationships among modules.
Accept-
• Detailed design: Get-
order
order Process-
order

– different modules designed in

greater detail:
• data structures and algorithms for each
module are designed. 42
• 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,
Object-Oriented Design
• managers,

• pay-roll register,

• Departments, etc. 43
 Object Oriented Design (CONT.)
• Object structure:

– Refined to obtain the detailed design.

• OOD has several advantages:

– Lower development effort,

– Lower development time,

– Better maintainability.
44
Thank You!!