Document No : SPI-PILOT-LIFE-CYCLE-MODELS

Copy No :

Software Development Life Cycle Models

Version 1.0

TATA CONSULTANCY SERVICES SPI-Pilot branches April 1999

DOCUMENT RELEASE NOTICE Notice No.: ADD-QMS-01 Client Project Name : TCS (Internal) : SEPG Version No. Description This document covers the various Software Development Life Cycle models approved for use in the SPI Pilot branches.

Document details: Software Development Life 1.0 Cycle models

Revision details: Action taken (add/del/chg) Preceding page No. New page No. Revision Description

Change Register serial numbers covered : The documents or revised pages are subject to document control. Please keep them up-to-date using the release notices from the distributor of the document. These are confidential documents. Unauthorized access or copying is prohibited.

Approved by: ________________________________ Date: _______ Authorized by: ________________________________ Date: ________

PF2060C DOCUMENT REVISION LIST Client Project : TCS - INTERNAL : Software Engineering Process Group (SEPG)

Document Name : Software Development Life Cycle models Release Notice Reference (for release): ADD-QMS-01 Rev. No Revision date Revision description Page No. Prev page No Action taken Addenda/ New page Release Notice reference

Acknowledgement This document is prepared and released by TCS, SEEPZ. The SPI branches have received a copy of this document through QC, Mumbai. document has been reviewed, reformatted and is being released by SPI branches so that it can be used by these branches. Henceforth, the SPI branches will maintain this document and update if necessary. Pilot This Pilot Pilot

CONTENTS

Intergroup dependencies tracking procedure Software Development Life Cycle....................................................................................6 Introduction...................................................................................................................6 Purpose of this document.............................................................................................6 Scope of this document................................................................................................6 Life Cycle Models.............................................................................................................7 The Spiral Model..........................................................................................................7 The Modified Waterfall (Sashimi Model) Model............................................................8 Joint Application Design (JAD).....................................................................................9 Prototype....................................................................................................................10 Rapid Application Development (RAD).......................................................................10 Evolutionary................................................................................................................11 Throw Away................................................................................................................11 Comparison of Models...................................................................................................12 References.....................................................................................................................14

Software Development Life Cycle Models

Version 1.0

Software Development Life Cycle

Introduction
To achieve quality in both process and product, a systematic approach is required for development, operation and maintenance of any project. To adopt a systematic development, a suitable and pertinent life cycle model is required. Some of the existing life cycle models are: The Spiral Model The Water fall Model The Modified Waterfall (Sashimi Model) Model Joint Application Design (JAD) Prototype

Purpose of this document

The purpose of this document is to outline the various life cycle models, which the projects may adopt to maintain quality in process and product.

Scope of this document

The scope of this document covers the definition of life cycle, the various models available and when to use those models.

______________________________________________________________________ Internal of 9 Page 6

Software Development Life Cycle Models

Version 1.0

Life Cycle Models

The Spiral Model
A well-managed development project should take a, straight line approach, right from feasibility report to analysis, design, testing, and acceptance to operation. But in actuality, the project needs to proceed iteratively by taking a spiral path. The project starts with the analysis phase, then proceeds towards design, moves back to analysis and then design, followed by coding (version 1.0) and back to design and so forth. The ground rules of management control of a project need to be changed. Emphasis should be on delivery of products - data flow diagrams, structure charts, and function versions - rather than on completion of activities. The basic idea behind this model is that you start on a small scale, in the middle of the core functionality, explore the risks (such as poorly understood requirements and architecture, potential performance problems, problems in underlying technology etc.) and then make a plan to handle the risks. This should be followed by a commitment to approach, for the next iteration. Each iteration moves your project to a larger scale. One layer of the project is rolled first, to check what was actually wanted, and then, work on the next layer is started. Each iteration involves the following steps: 1) To determine objectives, alternatives and constraints 2) To identify and resolve risks 3) To evaluate alternatives 4) To develop the deliverables for that iteration, and to verify their correctness 5) To plan the next iteration 6) To commit to an approach for the net iteration (if you decide to have one)

When to Use:
If the project is large and complex and if feedback is considered for the entire development cycle, then this type of life cycle model can be considered.

______________________________________________________________________ Internal of 9 Page 7

Software Development Life Cycle Models

Version 1.0

The Waterfall Model

In the Waterfall model, the different phases of the software development life cycle are explicitly recognized as given below: PSU (Project start up) ===> RQA ===> HLD ===> LLD ===> CONSTRUCTION ===> SYSTEM TESTING ===> ACCEPTANCE TEST ===> PACKAGE & RELEASE ===> OPERATION & MAINTENANCE. In this model, the project takes a straight line path. Since different phases are explicitly recognized, the finalisation of the Contract is seen with reference to delivery and payment schedules of different phases. Since requirement validation is not done in an explicit manner, it may result in design and development of large quantities of unusable code. It may also result in extensive rework later, as document-driven standards, force elaborate specifications of poorly understood user interfaces and decision- support functions.

When to Use:
This type of model is suitable for small projects or for projects where the needs are clearly specified. Generally, when this model is used, feedback is taken from the client, time to time (but not frequently).

The Modified Waterfall (Sashimi Model) Model

Most of the weaknesses in the Waterfall model arise, not from problems with the activities, but from the treatment of the activities as disjoint, sequential phases. These major weaknesses can be modified with relatively minor modification of phase overlapping. The traditional waterfall model allows for minimal overlapping between phases at the end-of-phase review. This model suggests a stronger degree of overlapping, for example, by suggesting that you might be well into architectural design and perhaps part way into detailed design before you consider requirement analysis to be complete. This is a reasonable approach for many projects, which tend to gain important insights into what they are doing as they move through their development cycles and which aspect functions poorly, with strictly sequential development plans. This model has disadvantages too. Because there is overlapping among phases, milestones are more ambiguous, and it is harder to track progress accurately. Performing activities, simultaneously, can lead to miscommunication, ______________________________________________________________________ Internal of 9 Page 8

Software Development Life Cycle Models

Version 1.0

mistaken assumption and inefficiency.

When to use:
This type of model is commonly used in projects where functionality is either not well defined or is complex. In such a case, the Contract finalisation should be done with well-defined conditions. The Contract should clearly mention the duration of the project, as the milestones are somewhat ambiguous in this type of model.

Joint Application Design (JAD)

JAD is a method that can accelerate the analysis process without taking shortcuts through the analysis phases. It changes the user-analyst interaction model to accelerate the analysis and design processes. JAD attempts to overcome the most serious bottleneck in analysis, fact-finding. Fact-finding is the process of collecting facts, opinions and priorities from users. During analysis, these facts, opinions and priorities address the problems and opportunities in the current system (Survey and Study phase), user requirements (the Definition phase), and technical solutions (the Selection phase). JAD replaces the conventional method of fact-finding with group oriented techniques. In JAD, you should get all users, managers, analysts and other interested parties in one room, for an extended Group Discussion. This will isolate the problems that come from conventional fact- finding method, in a quick manner. JAD requires several conditions. First, the Management must be willing to release workers from their day-to-day jobs to participate in the session. Second, the Management must be willing to participate in the sessions themselves. The Management must also foster an environment of co-operation and listening when working with subordinates during the session. JAD session's participation should be explicitly mentioned in the Contract. JAD techniques make use of CASE (Computer Assisted System Engineering) technology to develop and display models during the actual work sessions.

When to Use:
JAD can be used: To accelerate system analysis and design without going in for shortcut methods in the analysis and design phases. ______________________________________________________________________ Internal of 9 Page 9

Software Development Life Cycle Models

Version 1.0

To avoid problems that arise from the conventional fact-finding method. If the management is ready to spare their employees for regular meetings during the development cycle of the project.

Prototype
The design-by-prototyping strategy is being used by an increasing number of businesses. Usually it gives a feel of the product in the early stage and how it will work in the future. End-users and the management, who make recommendations about requirements, methods and formats, review each prototype system. The prototype is then corrected, enhanced, or refined to reflect new requirements. Prototyping technology makes such revisions relatively straightforward. Prototyping can be classified as: Rapid Application Development (RAD) Evolutionary Throw away

Rapid Application Development (RAD)

It is the simplest type of prototyping, albeit a very powerful one. Rapid prototyping allows you to create and test input designs, output designs, terminal dialogues and simple procedures. The procedure for Rapid Prototyping is as follows. The prototyping tool is used to create screens or reports along with headings, comments, help messages, error messages, error diagnostics, additional editing rules and instructions. Once this is completed, the screens can be demonstrated to end-users and normal operation is simulated. The end-users can tell the analyst what they dont prefer and what needs to be added, deleted or changed. Once the design is approved, the analyst can generate codes for several alternative technical environments.

When to use:
If the system requires a front end tool like Developer 2000, Visual Basics, Power Builder and if the user knows about his requirements, then this type of prototyping can be done efficiently, effectively and rapidly. Moreover Contract finalisation can be done according to the type of functionality and depending on the number of screens. ______________________________________________________________________ Internal of 9 Page 10

Software Development Life Cycle Models

Version 1.0

Evolutionary
In an Evolutionary prototype, major functions are developed early in the project schedule, followed by a rigorous approach so that the user can get an early feeling of the product. These developed functions are further optimized to the expedient needs of users along with an addition of the remaining functions. Since continuous feedback is taken from the client, additional functionality may be added from time to time, as the product takes shape (as no software is perfect).

When to use:
This type of prototype will be extremely useful when the clients themselves do not know what they exactly want. So with continuous feedback from the clients, their needs can be taken care of. But in this case Contract finalisation is to be done with well-defined conditions. The contract should clearly mention the duration of the project. Baselines will be derived from functionality and time.

Throw Away
An Ad-hoc development approach is used after understanding the requirements and solutions. This ad-hoc development is done in a quick manner without strictly implementing the GUI standards as this is discarded after objectives are met. The requirements and solutions are finalized and fresh development is started with a rigorous approach.

When to use:
Sometimes the user knows about his requirements (not completely) but is hesitant about the type of solution and system provided. In such a case, a Throw Away prototype can be developed, and if the user is satisfied with the kind of service provided, then Contract finalisation can be done depending upon the work, time and effort required.

______________________________________________________________________ Internal of 9 Page 11

Software Development Life Cycle Models

Version 1.0

Comparison of Models
Different Projects have different needs, even if they all need to be developed quickly. To choose the most effective lifecycle for your project, examine your project and the various conditions. Here are some of the strengths and weaknesses of various lifecycle models.

Life cycle Model

Work with poorly understood requirements Work with poorly understood Architecture Produce highly reliable system Produce system with large envelope Can be constrained to a predefined schedule Has low overhead Allows for midcourse corrections Provides customer with progress visibility Provides management with progress visibility

Pure Waterfall Poor

Modified Waterfall Fair to Excellent Fair to Excellent Excellent Excellent Poor

Spiral Excellent

JAD Excellent

Evolutio -nary Excellent

Throw away Fair

RAD Fair

Poor

Excellent

Excellent

Poor to Fair Fair Fair Fair

Fair

Excellent

Excellent Excellent Fair

Excellent Excellent Poor to Fair Fair Fair Excellent

Fair to Excellent Fair to Excellent Fair

Fair Poor to Fair Excellent

Excellent Excellent Fair

Poor Poor Poor

Fair Excellent Excellent

Poor Fair Fair

Poor Fair Excellent

Fair Poor to Fair Fair to Excellent Fair

Fair Excellent Excellent

Fair

Fair

Excellent

Fair

Fair to Excellent

Excellent

Table 1-1. Lifecycle Model - Strengths and Weaknesses

______________________________________________________________________ Internal of 9 Page 12

Software Development Life Cycle Models

Version 1.0

Note: The ratings in the table are based on the models best potential. The actual effectiveness of any lifecycle model will depend on how you implement it. It is usually possible to do worse than the table indicates. On the other hand, if you know the model is weak in a particular area, you can address that weakness, early in your planning stage and compensate for it--perhaps by creating a hybrid of one or more of the models described. Many of the tables criteria will also be strongly influenced by development considerations other than your choice of lifecycle models. A detailed description of the lifecycle-model conditions described in table 1-1 is given below. Work with poorly understood requirements It refers to how well the lifecycle model works, when either you or your customer understands the systems requirements poorly or when your customer is prone to change requirements. It indicates how well suited the model is to exploratory software development. Work with poorly understood architecture It refers to how well the lifecycle model works when youre developing in a new application area or when youre developing in a familiar application area, but are developing unfamiliar capabilities. Produces highly reliable system It refers to how many defects a system developed with the lifecycle model is likely to have when put into operation. Produces system with large growth envelope It refers to how easily youre likely to modify the system, in size and in diversity over its lifetime. This includes modifying the system in ways that were not anticipated by the original designers. Can be constrained to a predefined schedule It refers to how well the lifecycle model supports delivery of software by an immovable drop-dead date. Has low overhead It refers to the amount of management and technical overhead required, to use the model effectively. Overhead includes planning, status tracking, document production, package acquisition, and other activities that arent directly involved in producing the software. Allows for midcourse corrections It refers to the ability to change significant aspects of the product midway through the development schedule. This does not include changing the products basic mission but does include extending the product. Provides customer with progress visibility ______________________________________________________________________ Internal of 9 Page 13

Software Development Life Cycle Models

Version 1.0

It refers to the extent to which the model automatically generates signs of progress that the customer can use to track the projects status. Provides management with progress visibility It refers to the extent to which the model automatically generates signs of progress that the management can use to track the projects status.

References
1. McConnell, Steve: Rapid Development 2. Pressman, Roger S : Software Engineering - A Practitioners approach, Fourth Edition, McGraw Hill International Edition, 1997 3. Pfleeger, Shari Lawrence, Software Engineering Theory and Practice, Prentice-Hall International Inc. ,1998

______________________________________________________________________ Internal of 9 Page 14

Software Development Life Cycle Models

Version 1.0

FEEDBACK FORM To: From: Project: The SEPG Head Tata Consultancy Services Date: Location:

Please use the space below to give your comments, suggestions, and queries or to point out errors. Please use additional sheet if necessary.

For SEPG Heads use Action assigned to: Details of action taken: Date assigned:

Internal