Life Cycle Models

RCS213: Software Engineering

 Life-Cycle Methodologies

Automated
tools
Processes &
procedures
Life-cycle
methodologies
Methods &
techniques

Principles

• life-cycle methodologies which organize methods and techniques into an

ordered sequence of events.
 Software Life Cycle
• Software life cycle (or software process):
• series of identifiable stages that a software product undergoes during its life time:
1. Feasibility study
2. requirements analysis and specification,
3. design,
4. coding,
5. testing
6. maintenance.

3
 4

What is a Software Process Model?

 Description of the software process that represents one view, such as the
activities, data or roles of people involved.
Examples of views Focus on…

Activities = human actions.

Workflow
What is input, output, and dependencies.

Activities = transformations of information.

Dataflow
How the input is transformed into output.

Role/Action What is the role of people involved in each step of the process?
 Life Cycle Model
• A software life cycle model (or process model):
• a descriptive and diagrammatic model of software life cycle:
• identifies all the activities required for product development,
• establishes a precedence ordering among the different
activities,
• Divides life cycle into phases.

5
 Life Cycle Model (CONT.)

• Several different activities may be carried out in each

life cycle phase.
• For example, the design stage might consist of:
• Structured analysis activity followed by
• Structured design activity.

6
 Why Model Life Cycle ?
• A written description:
• forms a common understanding of activities among the software
developers.
• helps in identifying inconsistencies, redundancies, and
omissions in the development process.
• Helps in tailoring a process model for specific projects.
• Processes are tailored for special projects.
• A documented process model
• helps to identify where the tailoring is to occur.
7
 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.
• When a program is developed by a single programmer ---
• he has the freedom to decide his exact steps.

8
 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 chaos and project failure.
• 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
 Life Cycle Model (CONT.)

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

• 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.
• This usually leads to a problem:
• known as the 99% complete syndrome.
11
 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. Waterfall
2. V-Shaped SDLC , The primary difference
3. Evolutionary prototyping, in life-cycle models is
4. Rapid Application (RAD), the sequence of, and
5. Incremental SDLC,
emphasis on these
6. spiral model , and
activities.
7. Agile Model 12
Life-cycle models
• Life-cycle models provide engineered approaches that can be used to
structure the software development process.
• These models are a convenient and idealized picture of the process we
followed to build, deliver, and evolve software systems.
• Software life-cycle models typically include phases that correspond to
these development activities.
• The primary difference in life-cycle models is the sequence of, and
emphasis on these activities.
Waterfall Model
• Requirements – defines needed
information, function, behavior,
performance and interfaces.
• Design – data structures, software
architecture, interface
representations, algorithmic details.
• Implementation – source code,
database, user documentation,
testing.
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or
schedule
 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
• Does not reflect problem-solving nature of software development –
iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be too
late)
When to use the Waterfall Model

• Requirements are very well known

• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
V-Shaped SDLC Model
V-Shaped SDLC Model
• A variant of the
Waterfall that
emphasizes the
verification and
validation of the
product.
• Testing of the product
is planned in parallel
with a corresponding
phase of development
V-Shaped Steps
• Project and Requirements Planning • Production, operation and
– allocate resources maintenance – provide for
enhancement and corrections
• System and acceptance testing –
check the entire software system in
• Product Requirements and its environment
Specification Analysis – complete
specification of the software system
• Integration and Testing – check that
modules interconnect correctly
• Architecture or High-Level Design
– defines how software functions • Unit testing – check that each
fulfill the design module acts as expected

• Detailed Design – develop • Coding – transform algorithms into

algorithms for each architectural software
component
V-Shaped Strengths
• Emphasize planning for verification and validation of the
product in early stages of product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in
requirements
• Does not contain risk analysis activities
When to use the V-Shaped Model

• Excellent choice for systems requiring high reliability

– hospital patient control applications
• All requirements are known up-front
• When it can be modified to handle changing
requirements beyond analysis phase
• Solution and technology are known
Evolutionary Prototyping Model
Evolutionary Prototyping Model
• Developers build a prototype during the requirements
phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code is brought
up to the standards needed for a final product.
Structured Evolutionary Prototyping Steps
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds
• the database
• user interface
• algorithmic functions
• The designer demonstrates the prototype, the user evaluates for problems and
suggests improvements.
• This loop continues until the user is satisfied
Structured Evolutionary Prototyping Strengths
• Customers can “see” the system requirements as they are being
gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of additional
needed functionality
Structured Evolutionary Prototyping Weaknesses

• Tendency to abandon structured program development

for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to be clarified
• As the requirements clarification stage of a waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-oriented
development.
Rapid Application Model (RAD)