doc 12 life cycle models

Syntel CQA Forum Life Cycle Models CQA Doc No 12

document.xls Page

Definition

Guidelines for selection1 All capabilities are needed for first delivery2 Risk of delivery is minimal3 Requirements are complete, stable, and well understood4 Technology is well understood5

6 All funding and staffing are available at the beginningWaterfall Model

The Waterfall Model assumes that distinct phases of development of a whole system exist for analysis, preliminary design, detailed design, coding and unit test, and system test.

Documentation produced at the end of each phase provides the basis for work performed in the next phase of development.

In the Waterfall Model, characterized by a single build of software (one increment), the software development effort must return to previous phases of development to fix misunderstood or unstated requirements, design flaws, and logical coding errors discovered in later phases of the model.

This model has its peak loading during the midpoint of the development activity (the design and coding phase).

System Requirements

Analysis

System Design

Software Requirements

Analysis

Preliminary Design

Detailed Design

Coding and Unit Test

Integration and Testing

Formal

Testing Qualification


Doc 12 document.xls Page

Definition

Guidelines for Selection1 Applicable to high-risk programs where prototyping will be used to minimize risk2 Requirements incomplete, unstable3 Lack of DemVal Program4 Applicable to large-scale projects5 This model has relatively flat loading during the development activities.

Spiral Model

The Spiral Model adds risk analysis and prototyping activities at the beginning of each phase defined in the Waterfall Model to address the perceived risk areas of a project

The Spiral Model focuses on significant areas of risk, studies alternative solutions, and develops prototypes and simulations to explore the strengths and weaknesses of candidate solutions.

Some implementations of the Spiral Model suggest incremental development of a system by completing its component parts in sequence.

Determine Objectives, Alternatives, Constraints

Evaluate Alternatives, Identify, Resolve Risks

Develop, Verify Next Level Product

Plan Next Phases

Prototype 1 Prototype 2

Prototype 3

Operational Prototype

Simulations, Models, Benchmarks

Risk Analysis

Risk Analysis

Risk Analysis

Risk Analysis

Concept of Operation

Requirements Plan Life-cycle Plan

Development Plan

Integration & Test Plan

Softw are Requirements

Requirements Validation

Design Validation And Verif ication

Softw are Product Design

Detailed Design

Code Unit Test

Integration & Test

Acceptance Test

Implementation

Review Commitment

Partition

Syntel CQA Forum Life Cycle Models Page

document.xls Page

Definition

Guidelines for Selection1

2 Lack of DemVal program3 Customer doesn’t fully understand requirements

Rapid Prototyping Model

The Rapid Prototyping Model is designed to develop a complete, unambiguous set of requirements early in the analysis phase of the lifecycle by conducting frequent reviews of a functional prototype by customers and users during the analysis phase.

This approach hopes to avoid delaying the detection of analysis and design problems to the integration and test phase of development, where they are more expensive to fix.

The developers create a prototype that exhibits their understanding of customer requirements. The customers and users review the prototype for conformance to their view of how the system should operate. The prototype is evolved until it becomes a dynamic operational specification of the actual requirements.

This model has the highest loading early in the development cycle, since it involves very intense customer involvement during the early phases of development with correspondingly low levels of activity during test and integration.

Analysis Prototyping Prelim. Design

Tuning Test Planning

Requirements Documents

or Case Model

System Req.

Review

Working Prototype

Online Documentation

Project Plan

(SDP)

Allocated Baseline

Reviews

Products

Phases

Preliminary System Req.

Document

Software Test Plan

Preliminary Design

Document

Updated Design

Document

Software Test

Procedures

Design Prototype

Critical Design Review

Preliminary Design Review

Detailed Design

Product Baseline

Final Software Product (CSCI)

Software Design

Document

Test Readiness

Review

Software Test

Results

Software Product

Specification

Final User Documentation

Formal Qualification

Review

Baselines

Software Specification

Review


Dos 12 document.xls Page

Definition

Guidelines for Selection1 Early capability is needed, and not all capabilities are needed at first delivery2 Requirements are well understood, and complete at the beginning of the program3 Requirements are stable4 System functionality breaks naturally into increments5 Funding and staffing are not all available at beginning6 This model has its peak loading early in the development cycle

Incremental Model

The Incremental Model determines user needs and defines the system requirements, then performs the rest of the development in a sequence of builds.

The first build incorporates a subset of the system’s planned capabilities; the next build adds more capabilities, and so on, until the system is complete. This model allows early delivery of functions to the customer as development continues on other functions.

System Requirements

Analysis

System Design

Requirements Analysis

Preliminary Design

Software Implementation

Software Integration

Detail Design

Preliminary Design

Software Qualification

Test



Detail Design

Preliminary Design

Software



Detail Design

Release to Customer

CSCI Build-2

CSCI Build-1

CSCI Build-n

Software Qualification

Qualification

Test

Test


Evolutionary Page

Definition

Guidelines for Selection1 Early capability is needed2 Not all capabilities are needed for first delivery3 Not all requirements can be developed at once4 Requirements are expected to change5 User feedback of initial capability is needed to develop requirements6 Technology development is needed to develop requirements7 System functionality breaks naturally into increments8 Funding and staffing are not all available at the beginning of the project9 Prototyping is needed

10 This model has relatively flat loading during the development activitiesEvolutionary Model

The Evolutionary Model, like the Incremental Model, develops the system in builds, but differs from the Incremental Model in acknowledging that the user need (or some other aspect affecting the generation of system requirements) is not fully understood and that all requirements cannot be defined early in the development cycle.

The system design may be evolving in parallel with the software activities. In each build, new software requirements are defined and the existing requirements are refined. Rapid Prototyping may be used as an early build with this method.

Requirement Analysis



Preliminary Design

Detailed Design

Subsystem/ Element/ Segment

Integration

System Design

Software Implementation & Integration

Preliminary Design

Detailed Design

CSCI 1-Build 2


CSCI 1-Build 1

Preliminary Design

Detailed Design


CSCI 1-Build n

System Requirements

Analysis


Test


Test


Test


Doc 12 Advantages Page

Waterfall Spiral Rapid Incremental EvolutionaryAdvantages 1. The Waterfall Model is

widely used on projects of all sizes

1. Early attention to options for the use of existing software in the form of COTS or reusable software components

1. The Rapid Prototyping Model is well suited for the Demonstration and Validation phase of system procurement and to IR&D projects because it produces a working prototype that captures refined requirements (a live requirements document).

1. The Incremental Model delivers product to the customer earlier than some other models.

1. The Evolutionary Model shows early capability.

2. The model provides a disciplined, structured approach to the software development process

2. This model encourages the identification and evaluation of alternative solutions

2. The Rapid Prototyping Model excels in developing a complete set of system requirements. The Rapid Prototyping Model blurs the distinction between analysis, design, and coding to overcome the traditional breaks between these three activities

2. This strategy models situations where the system breaks naturally into increments.

2. This strategy anticipates changes to the system or changes because user feedback and monitoring are necessary to understand the full requirements.

3. The model provides an accurate document trail, including revision histories

3. Mechanisms are provided for incorporating software quality objectives into the software product development process

3. This model is appropriate when the system is too large to do all at once, or when funding or staffing will be provided in increments.

3. This strategy models situations where the system breaks naturally into increments

4. This method allows the identification of all types of objectives and constraints during each round of the spiral

4. This model is appropriate when the system is too large to do all at once, or when funding or staffing will be incremental.


Doc 12 Advantages Page

Waterfall Spiral Rapid Incremental Evolutionary5. This model features flexible management of the software lifecycle by accommodating a mix of software development methodologies (e.g., structured analysis, object oriented, prototyping, etc.)

5. This model is able to utilize a Rapid Prototyping capability effectively.

6. The opportunity to evaluate progress at each phase of the development process is provided by assessing risk and planning for the next phase

6. This strategy handles anticipated changes to the system or changes because user feedback and monitoring is provided to understand the full requirements.

7. Each round provides the opportunity to use simulations, system models, or prototypes to evaluate system concepts, software requirements, and software architectures. This feature accommodates the evolutionary prototyping software lifecycle model and allows simulation and software modeling tools to be integrated into the development process


Disadvantages Page

Waterfall Spiral Rapid Incremental EvolutionaryDisadvantages 1. The emphasis on

documents being the completion criteria for the phases of the Waterfall Model makes the development process less flexible

1. Effort is required to elaborate the steps of the Spiral Model. Specifically, the number of rounds of the spiral needs to be identified including the objectives and constraints of each round

1. Effort is concentrated in the analysis phase of development, which extends the time required to complete analysis. The schedule of activities and dates for deliverables will not conform to the schedule that the customer has become accustomed to for the waterfall model.

1. The model is not appropriate when the user wants to see full capabilities at the first delivery.

1. The model is not appropriate when the customer wants the full capabilities in the first delivery.

2. It assumes that requirements are fully developed early in the project. If requirements are not well understood, there is a risk that the final product may not meet customer expectations.

The model relies on the ability of the software development team and software managers to identify and manage project risks

2. Since there is not a clean break between analysis and design, the developers must ensure that the requirements are formally documented upon completion of the initial working prototype.

2. The contents and schedule for builds must be tightly controlled to ensure their integrity and quality.

2. Additional effort must be spent to ensure that the coordination between the builds is well defined.

3. The model provides an accurate document trail, including revision histories

Each stage of the spiral must be executed consistently for each round of the spiral in order to have a controlled and a well-managed software development project.

3. The customer and the contractor must revisit previous agreements concerning what is to be delivered from each phase.

3. Each successive build is dependent upon the previous build.

3. Each successive build is dependent upon the success of the previous build.

4. The model relies on the ability of the software development team and software managers to identify and manage project risks. It also forces cost estimation and project planning to occur after only a limited amount of analysis has been performed.

For the spiral model to be used effectively, an organization must have solid experience identifying, prioritizing, and mitigating risk

4. The model relies on the ability of the software development team and software managers to identify and manage project risks. Cost estimation and project planning must be performed continuously throughout the project.