SOFTWARE DEVELOPMENT LIFE CYCLE

LIFE CYCLE MODEL

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the
software life cycle. A life cycle model represents all the activities required to make a software product transit
through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other
words, a life cycle model maps the different activities performed on a software product from its inception to
retirement. Different life cycle models may map the basic development activities to phases in different ways.
Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models
though the activities may be carried out in different orders in different life cycle models. During any life cycle
phase, more than one activity may also be carried out.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and then adhere to it.
Without using of a particular life cycle model the development of a software product would not be in a
systematic and disciplined manner. When a software product is being developed by a team there must be a clear
understanding among team members about when and what to do. Otherwise it would lead to chaos and project
failure. This problem can be illustrated by using an example. Suppose a software development problem is
divided into several parts and the parts are assigned to the team members. From then on, suppose the team
members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible
that one member might start writing the code for his part, another might decide to prepare the test documents
first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one
of the perfect recipes for project failure. A software life cycle model defines entry and exit criteria for every
phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model
the entry and exit criteria for a phase cannot be recognized. Without software life cycle models it becomes
difficult for software project managers to monitor the progress of the project.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as well as some
disadvantages. A few important and commonly used life cycle models are as follows:

 Waterfall Model
 Prototyping Model
 Spiral Model
 Incremental model
 Rapid Application Development(RAD) Model

Waterfall Model
Also known as linear sequential model, is a systematic sequential approach to software development that
begins at system level and progresses through analysis, design, implementation, testing and deployment.
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.

Prototype Model

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities,
low reliability, and inefficient performance compared to the actual software. A prototype is usually built using
several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. A prototype
usually turns out to be a very crude version of the actual system.

Applicable: When your customer has a legitimate need but it clueless about the details, develop a prototype
as a first step. The prototype can serve as “The first system”
Many researchers and engineers advocate that if you want to develop a good product you must plan to throw
away the first version. The experience gained in developing the prototype can be used to develop the final
product.
 Requirements

Quick design

Prototypes Implementation Refinement

of the requirements
Customer’s
Evaluation
Accepted not accepted

Actual design

Actual
Actual implementation
Development
Testing

Deployment

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

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)
Spiral SDLC Model

The Spiral model of software development is shown in fig. The diagrammatic representation of this model
appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral
represents a phase of the software process. For example, the innermost loop might be concerned with feasibility
study, the next loop with requirements specification, the next one with design, and so on. Each phase in this
model is split into four sectors (or quadrants) as shown in figure. The following activities are carried out during
each phase of a spiral model.

Spiral Quadrant
1. 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.

2. Evaluate alternatives, identify and resolve risks

• A detailed analysis is carried out for each identified project risk.

 • Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate,
a prototype system may be developed.

3. Develop next-level product

• Develop and validate the next level of the product after resolving the identified risks.
• Typical activites:

– Create a design

– Review design

– Develop code

– Inspect code

– Test product

4. Plan next phase

• Review the results achieved so far with the customer and plan the next iteration around the spiral.
• Progressively more complete version of the software gets built with each iteration around the spiral.

Spiral Model Strengths

• Provides early indication of insurmountable risks, without much cost

• Users see the system early because of rapid prototyping tools

• Critical high-risk functions are developed first

• The design does not have to be perfect

• Users can be closely tied to all lifecycle steps

• Early and frequent feedback from users

• Cumulative costs assessed frequently

Spiral Model Weaknesses

• Time spent for evaluating risks too large for small or low-risk projects

• 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

• Developers must be reassigned during non-development phase activities

 • May be hard to define objective, verifiable milestones that indicate readiness to proceed through the
next iteration

When to use Spiral Model

• When the customer’s requirements are complex

• When creation of a prototype is appropriate

• When costs and risk evaluation is important

• For medium to high-risk projects

• Long-term project commitment unwise because of potential changes to economic priorities

• Users are unsure of their needs

• Requirements are complex

• New product line

• Significant changes are expected (research and exploration)

Incremental model

Incremental model is an evolution of waterfall model.The product is designed, implemented, integrated and
tested as a series of incremental builds. It is a popular model software evolution used many commercial
software companies and system vendor.

When an incremental model is used, the first increment is often a core product. The core product is used by
the customer or undergoes a detailed review. As a result of use and/or evaluation a plan is developed for the
next increment. The plan addresses the modification to the core product to better meet the needs of the
customer and delivery of additional features and functionality. Software is constructed in a step-by-step
manner. While a software product is being developed, each step adds to what has already been completed.

• Construct a partial implementation of a total system

• Then slowly add increased functionality
• The incremental model prioritizes requirements of the system and then implements them in groups.
• Each subsequent release of the system adds function to the previous release, until all designed
functionality has been implemented.

Incremental software development model may be applicable to projects where:

  Software Requirements are well defined, but realization may be delayed.

 The basic software functionality are required early

Advantages of Incremental Model

• Develop high-risk or major functions first

• Each release delivers an operational product

• Customer can respond to each build

• Uses “divide and conquer” breakdown of tasks

• Lowers initial delivery cost

• Initial product delivery is faster

• Customers get important functionality early

• Risk of changing requirements is reduced

Disadvantages Incremental Model

• Requires good planning and design

• Requires early definition of a complete and fully functional system to allow for the definition of
increments
• Well-defined module interfaces are required (some will be developed long before others)
• Total cost of the complete system is not lower
When to use the Incremental Model

• Risk, funding, schedule, program complexity, or need for early realization of benefits.
• Most of the requirements are known up-front but are expected to evolve over time
• A need to get basic functionality to the market early
• On projects which have lengthy development schedules
• On a project with new technology