SelectingSoftware Development

Life Cycles

Adapted fromChapter 4, Futrell

Examples of Software Life Cycle Models

�“Classical” Waterfall�Waterfall with feedback�V-Shaped�Prototyping�Incremental�Spiral�Rapid Application Development�Combination

“Classic” Waterfall Model

Systemsengineering

Maintenance

Analysis

Design

Code

Testing• Classical engineering approach• Associated with DOD-STD-2167A• Explicit start and end points to phases• Clearly defined milestones

V&V Activities

V&V Activities

DevelopmentalTest

V&V Activities

V&V Activities

V&V Activities

Waterfall Model with Feedback

SystemRequirements

SoftwareRequirements

V&V Activities

PreliminaryDesign

DetailedDesign

Code andDebug

Test andPre-operations

OperationsandMaintenance

Strengths of the Waterfall Model

� It is easy to understand� It is easy to use (when applied to a project for which it is

suited)� It is easy to track the progress of the project using a timeline

or Gantt chart -- the completion of each phase is used as amilestone

� Allows for tight control -- defines quality control procedures� The model is well known by non-software customers and

end-users and is used by other organizations to trackprojects not related to software development

Weaknesses of the Waterfall Model

� It does not easily handle concurrent events -- developmentteams are delayed waiting on others

� It does not handle iterations among phases-- the sequentialflow is not always realistic

� The user is involved only in the beginning of the process,while gathering requirements, and at the end, duringacceptance testing

� Customers can rarely state all requirements at the beginningof the project

�The customer does not get to “see” the product untillate in the life cycle

� The model is not equipped to handle dynamic changes inrequirements over the life cycle -- deliverables are “frozen”

Project Requirements and Planning

Product Requirements

and SpecificationAnalysis

Architectural orHigh-Level Design

Detailed Design

Coding

Production,Operation, and

Maintenance

System Testing

Integration and Testing

Unit Testing

V-Shaped Model

Strengths of the V-Shaped Model

� The model is easy to understand� It is easy to use (when applied to a project for which it is

suited)� It is easy to track the progress of the project using a

timeline or Gantt chart -- the completion of each phase isused as a milestone

� The model emphasizes planning for verification andvalidation of the product in the early stages of productdevelopment

� The model encourages verification and validation of therequirements and design, not just the code of the product

Weaknesses of the V-Shaped Model

� The model does not easily handle concurrent events� It does not handle iterations of phases� The model is not equipped to handle dynamic changes in

requirements throughout the life cycle� The model is not equipped to handle dynamic changes in

requirements over the life cycle� The requirements are tested too late in the cycle to make

changes without affecting the schedule for the projectThe V-Shaped model may be modified to overcome these

weaknesses by including iteration loops to handle thechanging of requirements beyond the Analysis phase.

Prototyping Model

� Plan to throw one away� In most projects, the first system built is barely usable. It may be too slow, too big, awkward to

use, or all three. There is no alternative but to start again, starting but smarter, and build aredesigned version…

� The management question, therefore, is not whether to build a pilot system and throw it away.You will do that. The only question is whether to plan in advance to deliver a throwaway tocustomers.

- Fred Brooks, The Mythical Man-Month, 1975 p. 116

� Promising Attacks on the Conceptual Essence� The hardest single part of building a software system is deciding precisely what to build. No

other part of the conceptual work is as difficult as establishing the detailed technical requirements,including all the interfaces to people, to machines, and to other software systems. No other partof the work so cripples the resulting system If done wrong. No other part is more difficult torectify later.

� Therefore, the most important function that the software builder performs for the client is theiterative extraction and refinement of the product requirements. For the truth is, the client doesnot know what he wants.

- Fred Brooks, “No Silver Bullet, 1986

ProjectPlan

RapidAnalysis

DatabaseCreation

UserInterface

Functions

Prototype Iteration

Design Derivation

Tuning

Operation and Maintenance

UserApproval

Evolutionary Rapid Prototyping Model

Strengths of the Rapid Prototyping Model

�The end user can “see” the system requirements asthey are being gathered by the project team --customers get early interaction with system

�There is less room for confusion, miscommunicationor misunderstanding in the definition of the systemrequirements, leading to a more accurate endproduct -- customer and developer have abaseline to work against

�The model allows for flexible design anddevelopment

Weaknesses of the Rapid Prototyping Model

� If the users cannot be involved during the rapid prototypeiteration phase of the life cycle, this can have adverse effectson the final product

� The rapid prototype is a partial system during the prototypeiteration phase. If the project is risky and may not becompleted, the end user will be left with only a partial system

� The customer may expect “look and feel” of the prototype� The customer may want to have prototype delivered rather

than waiting for full, well engineered version� If the prototyping language or environment is not consistent

with the production language or environment, there can bedelays in full implementation of the production system

� Quality can suffer

Go, no godecision

Toward a completed system

Next level prototypeEngineered system

Initialrequirementsgathering andproject planning

Customerevaluation

Initialsoftwareprototype

Risk analysis based oninitial requirements

Risk analysisbasedon customerreaction

Planning based oncustomer comments

Risk analysis

EngineeringCustomer evaluation

Planning

• Partitions process into four distinct quadrants• Emphasizes evolutionary development• Accommodates 1980s paradigms• Stresses formal risk analysis

Spiral ModelSpiral Model

Evolutionary Spiral Model

Source: Software Productivity Consortium Evolutionary Spiral Process Model Guidebook

1. Understand Context

3. Plan Development

2. Analyze Risks

4. Develop Product5. Manage and Plan

Define/Refine Approach- Stakeholders- Objectives- Alternatives- Constraints

Develop/UpdateEstimate of the

Situation

Perform RiskAnalysis

ReviewRisk AnalysisPlan RiskAversion

Evaluate RiskAversion

Review Alternative

Plan andSchedule

Developand VerifyProduct

Monitor andReview

Place ProductUnder Change

Control

ReviewProgress

Update Spiral Plan

Commit toProceed

ReviewContext

Commit toRisk Aversion

Strategy

Commit toPlan

ReviewTechnicalProduct

Strengths of the Spiral Model

� The model embraces the waterfall model while allowing foriteration throughout the phases of that model

� It is driven by risk analysis and is ideal for those projectswhich represent a medium to high risk

� The users see the product early, via the proof of conceptand rapid prototypes in the development life cycle

� The users are closely tied to the development efforts� All of the money needed for the project need not be

allocated up front� The model handles changes in requirements by allowing for

iteration through the Analysis & Design phase and ExecutePhase

Weaknesses of the Spiral Model

� If the project is low risk, this model can be an expensive life cyclemodel -- much time is spent evaluating the risk after each iterationwithin the model and considerable risk assessment expertise isrequired

� It may require unrealistic overhead for small projects� The creation of a prototype may not always be the appropriate type of

product development� It hasn’t been used as widely as linear sequential� The lack of a good prototyping tool or technique can make this model

clumsy to use� Adaptations of the model include:

Replacement of the prototypes with an increment of a productIteration within one of the spirals of the model illustrated by a two headed

arrowReplacement of the prototypes with rapid application development product

iteration

RequirementsPlanning

UserDescription

Construction

CutOver

TIME

Dev

elop

men

t Effo

rt

User Community

Rapid Application Development (RAD) Model

RAD Model

businessmodelingbusinessmodeling

datamodeling

datamodeling

processmodelingprocess

modeling

applicationgeneration

applicationgeneration

testing &turnover

testing &turnover

businessmodelingbusinessmodeling

datamodeling

datamodeling

processmodelingprocess

modeling

applicationgeneration

applicationgeneration

testing &turnover

testing &turnover

TIME

Deadline

Team 1

Team 2

Strengths of the RAD Model

�The model has shown reduced cycle time dueto the use of powerful development tools

�The end user is involved throughout the lifecycle

�The system is developed by a project teamfamiliar with the problem domain; thus itcontinues to build upon this expertise

�can deliver a full product in a short time period

Weaknesses of the RAD Model

� If the users cannot be involved consistentlythroughout the life cycle, this can have adverse effectson the final product

�This model requires highly skilled and well-traineddevelopers in the use of the chosen development toolsto achieve the rapid turnaround time

� It can require more people� It requires a system that can be properly modularized� It can fail if reusable components are not available

Incremental Model

� One of the Evolutionary Models� Combines elements of the linear sequential

model and prototyping� Requirements of the system are prioritized� The first increment is the delivery of the core

product, providing only the highest priorityrequirements

� Subsequent iterations expand on this core(enhancement maintenance)

Incremental Model

System/informationengineering

analysisanalysis designdesign codecode testtest delivery of1st increment

analysisanalysis designdesign codecode testtest delivery of2nd increment

analysisanalysis designdesign codecode testtest

delivery of3rd increment

TIME

Strengths of the Incremental Model

� The costs of developing a system can be reduced by definingsmaller incremental releases with reduced function

� The duration of the development cycle can be reduced with thismodel, allowing the product to be released quicker, perhaps inresponse to a market window

� Delivers a usable working product quickly� Keeps all teams working� The use of this model on a project with new technology can

allow the user to adjust to the system in smaller incrementalsteps rather than leaping to a major new product

This model is often combined with other models, such as thespiral model.

Weaknesses of the Incremental Model

�The model does not allow for iteration withineach increment

�The definition of a complete, fully functionalsystem must be done early in the life cycle toallow for the definition of the increments

�Allow you to “design yourself into a corner”�It works best with an even distribution of

different priority features�It requires good planning and design

Virus Backup Outside Procurement andIntegration

Fixes V-Shaped

Disk Doublespace Waterfall

File Recovery Spiral

Memory Management Prototype

Release Vxx.xx Incremental

Microsoft Product Release using CombinedModels

Combination Model

Preliminary requirements gathering

Spiral modelPrototyping 4GTRequirementsanalysis

Design

Coding

Testing

Prototyping:n-th iteration

4GT

Spiral modeln -th iteration

4GT

Maintenance

Operational system

Selecting a Life Cycle ModelExamine project characteristic categoriesExamine project characteristic categories::

•Uncertainty of Requirements•Requirements, Functional needs of the application •Project Team, Availability of Resources•User Community•Project Type, complexity of project•Cost of Application•Cost of Future Upgrades•Discrete / Gradual Requirements Change, Volume•Ease of Use of life cycle, Reuse•Longevity of the application•Product technology•Risk

Requirements Waterfall V-Shaped Prototype Spiral RAD Incremental

Are the requirements easily defined and/or well known?

Yes Yes No No Yes No

Can the requirements be defined early in the cycle?

Yes Yes No No Yes Yes

Will the requirements change often in the cycle?

No No Yes Yes No No

Is there a need to demonstrate the requirements to achieve definition?

No No Yes Yes Yes No

Is a prrof of concept required to demonstrate capability?

No No Yes Yes Yes No

Selecting a Life Cycle ModelProject Characteristic Category MatrixRequirements

Project Team Waterfall V-Shaped Prototype Spiral RAD Incremental

Are the majority of team members new to the problem domain for the project?

No No Yes Yes No No

Are the majority of team members new to the technology domain for the project?

Yes Yes No Yes No Yes

Are the majority of team memebers new to the tools to be used on the project?

Yes Yes No Yes No No

Are the team members subject to reassignment during the life cycle?

No No Yes Yes No Yes

Is there training available for the project team if required?

No Yes No No Yes Yes

Selecting a Life Cycle ModelProject Characteristic Category MatrixProject Team

Selecting a Life Cycle ModelProject Characteristic Category MatrixUser Community

User Community Waterfall V-Shaped Prototype Spiral RAD Incremental

Will the availability of the

user representatives be restriced, or limited during the life cycle?

Yes Yes No Yes No Yes

Are the user representatives new to system

definition?

No No Yes Yes No Yes

Are the user representatives experts in the

problem domain?

No No Yes No Yes Yes

Do the users want to be

involved in all phases of the

life cycle?

No No Yes No Yes No

Selecting a Life Cycle ModelProject Characteristic Category MatrixProject Type and RiskProject Type &

Risk Waterfall V-Shaped Prototype Spiral RAD Incremental

Does the project identify a new

product direction for the

organization?

No No Yes Yes No Yes

Is the project a system

integration project?

No Yes Yes Yes Yes Yes

Is the project an enhancement to

an existing system?

No Yes No No Yes Yes

Is the funding for the project

expected to be stable

throughout the life cycle?

Yes Yes Yes No Yes No

Is the product expected to

have a long life in the

organization?

Yes Yes No Yes No Yes

Selecting a Life Cycle ModelWhole Class Exercise #1

A company is rewriting its payroll system to move it from an oldbatch-type mainframe to a distributed mini-computer/PC-basednetworked setup. No new functionality will be added. The statementof work calls for a conversion “as is.” Only the input and outputsubsystems will be altered for the new environment. Since it is apayroll application, testing and verification will be emphasized withinthe development activities. The schedule allows five months for theproject, with two people working on it.

What do you think is the most Appropriate Life Cycle Approach?

What is the advantage of this approach for this project?

Selecting a Life Cycle ModelWhole Class Exercise #2

A company, an electronics giant, has recently decided to venture intoa related small business area developing wristwatch communicators.The device would be similar to a two-way radio and would beexpected to work over a 50-mile radius. The company hasconsiderable previous experience on product lines similar to this, andbelieves that a cheaper price could present a value-added challenge tothe cellular market. It would like to have a working model to presentat a national electronics fair coming up six months from now.

What do you think is the most Appropriate Life Cycle Approach?

What is the advantage of this approach for this project?

Selecting a Life Cycle ModelWhole Class Exercise #3

A company has recently completed a 3-year process to develop acellular infrastructure switching system to compete with industryleaders such as Motorola and Ericsson. It is now ready to move intothe next phase where new releases will be issued approximately everyfour months. An average of 15 new features and an appropriatenumber of bug fixes will be included in each release spread acrossteams composed of one to three engineers. Development times forthe new features can range from one to five months. Some featurescan require multiple releases for full implementation.

What do you think is the most Appropriate Life Cycle Approach?

What is the advantage of this approach for this project?

Selecting a Life Cycle ModelWhole Class Exercise #4

A company has created a new small business division to develop a specializedcommunications system. Approximately 15 persons will be transferred from keyareas of the company to form the base for the venture. Some 28 additionalpeople will be hired from the outside, the bulk of which are engineers. It hasalready been decided that Object-Oriented tools and approaches will be used withC++ as the language. None of the participants has any prior knowledge of thesetechniques, but will go through ten days of training when they come on board. Inaddition, a consortium-partner of the company has just released a newworkstation platform (its first). Due to these alliances, the consortium platformwill be the development platform of choice. Training is also being scheduled forthe new workstation. The primary satellite supplier, OO Aerospace, has beenhaving major financial difficulties due to military cutbacks and has laid off about35 percent of its work force.

What do you think is the most Appropriate Life Cycle Approach?

What is the advantage of this approach for this project?

•Become familiar with the various models•Review, analyze the type of work: development,

enhancement, maintenance, etc.•Review project criteria•Identify a minimum set of phases•Identify phase activities•Establish a minimum set of deliverables•Define templates and content guides for deliverables•Evaluate progress and effectiveness of the life cycle

framework•Implement improvements

Customizing the Life Cycle Model

Approves

Preliminary Object-Oriented Analysis Models

Used to Develop

Initial Prototype User

Demonstrate to

Expanded & Refined OOA Models

Provides Feedback for

Used to Develop

Provides Feedback for

Expanded & Refined Prototype

User

Demo to

Final Requirements Specification

Latest Version Becomes

Used to Develop

Final Version of Prototype

Rapid OOA

Create Objects

Create Controls

Create Services

Iterate

Iterate

More Objects

More ControlsMore Services

More Specs

User

Demo

Feedback

NoFeedback = Approval?

Yes

Performance Testing & Tuning

Operation & Maintenance

Software Life Cycles — Summary

�There are many “models” or representations of thesoftware life cycle

�Each model has its peculiar strengths andweaknesses

�The model selected for a project or the modelsused by an organization should meet the needs ofthe organization, the type of work to be done, andthe skills and tools of the software practitionersusing the model(s)