Life Cycle Models

Software Engineering

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.

Classical Waterfall Model

Feasibility Study
Req. Analysis Design

Coding
Testing Maintenance

Relative Effort for Phases

Phases between feasibility study and testing 60
known as development phases.

Among all life cycle phases

maintenance phase consumes maximum effort.

50 40 30 20 10 0

Relative Effort

Among development phases,

testing phase consumes the maximum effort.

Maintnce

Design

Coding

Req. Sp

Test

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.

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.

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.

Iterative Waterfall Model (CONT.)

Feasibility Study Req. Analysis Design Coding Testing Maintenance

Iterative Waterfall Model (CONT.)

Errors should be detected
in the same phase in which they are introduced.

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

Prototyping Model (CONT.)

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

Prototyping Model (CONT.)

Start with approximate requirements. Carry out a quick design. Prototype model is built using several shortcuts:
Short-cuts might involve using inefficient, inaccurate, or dummy functions.

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.

Prototyping Model (CONT.)

Build Prototype Requirements Quick Design Gathering Customer Customer Evaluation of satisfied Design Prototype

Refine Requirements

Implement
Test

Maintain

Evolutionary Model
Evolutionary model ( 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.

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.

Evolutionary Model (CONT.)

C

AB

Advantages of Evolutionary Model

Users get a chance to experiment with a partially developed system Helps finding exact user requirements Core modules get tested thoroughly:
reduces chances of errors in final product.

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.

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.

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

Spiral Model (CONT.)

Determine Objectives Identify & Resolve Risks

Customer Evaluation of Prototype

Develop Next Level of Product

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.

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.

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.

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

Comparison of Different Life Cycle Models

Evolutionary model is suitable for large problems:

(CONT.)

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.

Software Development Life Cycle (SDLC)

SDLC Model
A framework that describes the activities performed at each stage of a software development project.

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 Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost

Waterfall Deficiencies
All requirements must be known upfront Deliverables created for each phase are considered frozen inhibits flexibility Does not reflect problem-solving nature of software development iterations of phases 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

Structured 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

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

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

Spiral SDLC Model

Adds risk analysis prototyping to the waterfall model Each cycle involves the same sequence of steps as the waterfall process model

Spiral Quadrant Determine objectives, alternatives and constraints

Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, interface, etc.

Spiral Quadrant Evaluate alternatives, identify and resolve risks

Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development

Spiral Model Strengths

Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users

Spiral Model Weaknesses

Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Requirements are complex New product line Significant changes are expected (research and exploration)

Software Requirements Specification

What is SRS? What is the purpose of SRS?
Who reads the SRS? Who writes the SRS?

What information is put into SRS? What do you need to do for phase 1?

What is SRS?
It is a document that you prepare:
after customer gives you their system specifications before you design the system

What is the purpose of SRS?

The SRS precisely defines the software product that will be built. [readyset.tigris.org/nonav/templates/srs.html] The SRS is your response to the customers System Specification ... and tells a potential customer how you intend to solve their problem. [CSE442 project description]

The *SRS+ specifies the requirements and the methods to be used to ensure that each requirement has been met. [source?]

Purpose (continued)
An SRS is basically an organizations understanding (in writing) or a customer or potential clients system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work.
[www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

Its a two-way insurance policy that assures that both the client and the organization understand the others requirements from that perspective at a given point in time
[www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

Purpose (continued)
1. It provides feedback to the customer. 2. It serves as an input to the design specification. 3. It serves as a product validation check.
[www.techwrl.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

Who reads the SRS?

The purpose of an SRS is to communicate with the customer:
The SRS must make clear to the customer whether you have understood their system specification correctly and completely. SRS is written in plain language (not a formal language).

Who reads (continued)

The purpose of an SRS is to communicate with the designers:
The SRS must be detailed enough that the designers can construct a design for the system from this document.

Who writes the SRS?

Developers
Architects Programmers

Technical writers Customer may be involved

Basis for User Manual

The SRS can serve as the basis for a User Manual for the software:
Use case descriptions in SRS describe required functionality of the system, from the perspective of a user. This can be extended to become a description of how to carry out these required tasks with the finished system.

What information is put into an SRS?

Varies between
organizations projects

IEEE Std 830-1998 Characteristics of a good SRS

1. 2. 3. 4. 5. Correct Unambiguous Complete Consistent Ranked for importance and/or stability 6. Verifiable 7. Modifiable 8. Traceable

 Correct: every requirement given in SRS is a requirement of the software Unambiguous: every requirement has exactly one interpretation Complete: includes all functional, performance, design, external interface requirements; definition of the response of the software to all inputs (valid and invalid) Consistent: internal consistency

 Ranked importance: essential vs. desirable Verifiable: for each requirement there must be a finite cost-effective method to verify process with which a person or machine can check that the software product meets the requirement. Modifiable: SRS must be structured to permit effective modifications (e.g. dont be redundant, keep requirements separate) Traceable: origin of each requirement is clear.

IEEE Std 830-1998: Parts of an SRS

Introduction
Purpose
deliniate purpose of SRS intended audience for SRS

Scope
identify software to be produced by name explain what sw will (not) do describe application of sw (benefits, objectives)

IEEE Std 830-1998: Parts of an SRS

Introduction (continued)
Definitions/acronyms/abbreviations References
list documents referenced by name and source

Overview
brief description of rest of SRS organization of SRS

IEEE Std 830-1998: Parts of an SRS

Overall description
Product perspective (related products?)
block diagram contraints
system interfaces identify functionality that fulfills each system requirement user interfaces hardware interfaces software interfaces how sw interacts with supporting software (purpose, message content and format) required versions

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Product perspective
contraints
communications interfaces network protocols memory requirements/limits on primary and secondary memory operations modes of operation interactive vs. unattended operation backup & recovery site adaptation requirement

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Product functions
summary of major functions sw will perform

Intended user characteristics

educational level experience technical expertise

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Constraints (limitations of developer options)
regulatory policies hardware limitations (e.g. signal timing requirements) interfaces to other applications parallel operation audit functions control functions higher-order language requirements reliability requirements criticality of the application safety and security considertations

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Assumptions and dependencies
e.g. specific OS available on HW

Apportioning of requirements
requirements that may be delayed to future versions

IEEE Std 830-1998: Parts of an SRS

Specific requirements
External interfaces Functions Performance requirements Logical database requirements Design constraints
Standards compliance

IEEE Std 830-1998: Parts of an SRS

Specific requirements (continued)
Software system attributes
Reliability Availability Security Maintainability Portability

IEEE Std 830-1998: Parts of an SRS

Specific requirements (continued)
Organizing the specific requirements
System mode User class Objects Feature Stimulus Response Functional hierarchy

Additional comments

IEEE Std 830-1998: Parts of an SRS

Supporting Information
Table of contents Index Appendixes