Computer Sciene of Udayana State University

March 7, 2009

Three Models of System Development Life Cycle(SDLC)

Filed under: Computer Science — ignaga @ 2:29 AM

1. Waterfall Model

Small to medium database software projects are generally broken down into six




The relationship of each stage to the others can be roughly described as a waterfall, where the outputs from a specific stage serve as the initial inputs for the following stage. During each stage, additional information is gathered or developed, combined with the inputs, and used to produce the stage deliverables. It is important to note that the additional information is restricted in scope; “new ideas” that would take the project in directions not anticipated by the initial set of high-level requirements are not incorporated into the project. Rather, ideas for new capabilities or features that are out-of-scope are preserved for later consideration. After the project is completed, the Primary Developer Representative (PDR) and Primary End-User Representative (PER), in concert with other customer and development team personnel develop a list of recommendations for enhancement of the current software.

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

• Porting an existing product to a new platform.

• New version of an existing product

2. Iterative Model

An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

Consider an iterative lifecycle model which consists of repeating the following four phases in sequence:

A Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements.

A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

An Implementation and Test phase, when the software is coded, integrated and tested.

A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.



For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made. The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

3. Spiral Model



Spiral Model

The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. In the spiral model, software is developed in a series of incremental releases. During early iteration, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

The goal of the spiral model of the software production process is to provide a framework also called task regions, for designing such as processes, guided by the risk levels in the project at hand. The spiral model may be viewed as a met model, because it can be accommodate any process development model. The main characteristic of the spiral model is that it is cyclic and not linear like the waterfall model. The spiral model allows us to restate the issue of robustness versus correctness. After one cycle of the spiral, unstated requirements are checked as part of the robustness of the application. Each cycle consists of six stages, and each stage is represented by one quadrant of the Cartesian diagram.

· User feedback

· Planning

· Risk analysis

· Engineering

· Construction and release

· Customer evaluation.

The Spiral’s Steps

1. Define requirements

Through user involvement and analysis of existing system

2. Initial new system design

3. Construct and evaluate an initial prototype

Rough (skeletal) system attribute framework

4. Construct a further (refined) prototype

Basing it on evaluation of initial prototype

Defining its scope

Planning its development

Implementing it

5. Overall (system-wide) risk assessment

6. Prototype assessment (as per step 4) and possible development of further prototypes

7. Repeat steps 1-5 until refined prototype meets user expectations

8. Construct the system (based on final refined prototype)

9. Test and maintain the system


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: