cse 7315 - sw project management / module 5 - software lifecycles and processes copyright ©...

Slide # 1CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M05

August 1, 2006

SMU CSE 7315Planning and Managing a

Software Project

Module 05Software Lifecycles and

Processes

August 1, 2006

CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and

ProcessesCopyright © 1995-2006, Dennis J. Frailey,

All Rights Reserved

Slide # 2

CSE7315M05

Goal of This Module

• To examine different kinds of software lifecycles / process models– Advantages and disadvantages– How to select

August 1, 2006



All Rights Reserved

Slide # 3

CSE7315M05

Software Lifecycles• The software lifecycle is the top level

view of the software process• The specific lifecycle chosen depends

on the software to be built - its goals and requirements and its intended uses

• Selection of the software lifecycle model(s) is a primary responsibility of a software manager

August 1, 2006



All Rights Reserved

Slide # 4

CSE7315M05

Recall that there are Many Possible Software Lifecycles

within a Project Lifecycle

Phase 2 Phase 3 Phase 4 Phase nPhase 1 ....c: Software

Lifecycle

b: Software Lifecycle

d: Software Lifecycle

a: Software Lifecycle

August 1, 2006



All Rights Reserved

Slide # 5

CSE7315M05

Tailoring the Software Lifecycle

• Generally one tailors a given lifecycle model to fit the specific needs of the software

• You may need several lifecycles corresponding to different kinds of software

August 1, 2006



All Rights Reserved

Slide # 6

CSE7315M05

You May Want to Construct a Matrix to Plan the Lifecycles

Lifecycle# 2

ProductsLifecycl

e# 3Lifecycl

e# 4Lifecycl

e# 1

Mission SW

Support SW

Factory Test SW

Simulator

X

X

X

X

August 1, 2006



All Rights Reserved

Slide # 7

CSE7315M05

This Chart May Help You Decide How to Group Software

ProductsMission Critical

Support IncidentalLife

Critical

Testing Deliverable Products

Throwaway

Part of a Deliverable Product

Reused in Deliverable

Products

Criticality of Function

A M O U N T

O F

U S E

August 1, 2006



All Rights Reserved

Slide # 8

CSE7315M05

Entry Criteria for aSoftware Lifecycle

• The Goal is defined and measurable– Throwaway or production or ???– Purpose, requirements, etc.

• The Requirements are allocated to the software– Suggestion: use a trace matrix to show

what requirements are associated with what software items

… continued

August 1, 2006



All Rights Reserved

Slide # 9

CSE7315M05

Entry Criteria for aSoftware Lifecycle

(continued)

• Intended use and end-users are clear

• Applicable standards of quality and such are clearly stated

• Deliverables are clearly known

August 1, 2006



All Rights Reserved

Slide # 10

CSE7315M05

Ideal Requirements • Complete (every requirement is known and

allocated)• Sufficient (every required feature is

specified)• Consistent (no requirements contradict

each other)• Unambiguous (only one possible

interpretation)• Testable (you can tell when they are met)

August 1, 2006



All Rights Reserved

Slide # 11

CSE7315M05

Actual Requirements

• Some requirements will be:– TBD (unknown - to be determined)– Wrong– Missing– Vague or unclear

• Some requirements will– Contradict others– Not be testable– Change in mid-stream

• Technology changes• Customer understanding of problem changes• Problem changes

August 1, 2006



All Rights Reserved

Slide # 12

CSE7315M05

Risk Management for Imperfect Requirements

• Define a process to accept requirements changes

• Assign someone to be responsible to manage requirements changes– including involvement of software staff

• Select lifecycle based on level of expected requirements stability

• Get ranges for TBD requirements• Work to eliminate wrong and missing

requirements

August 1, 2006



All Rights Reserved

Slide # 13

CSE7315M05

Interface Requirements• How does your software interface to

other parts of the system?• This is just as important as other

requirements• Make sure the interface requirements

are– Documented– Under Control– Contained in (or controlled by) a SINGLE

document or other control point

August 1, 2006



All Rights Reserved

Slide # 14

CSE7315M05

Who is Establishing the Requirements? All

Stakeholders!• End user -- will use the software• Champion -- will pay for it• Marketing -- will sell it• Accountants and Lawyers -- will protect

but may not understand the product or the process

• Political factors– Such as engineers -- who “know better”

than the customer

August 1, 2006



All Rights Reserved

Slide # 15

CSE7315M05

The Software ProcessThis is the detailed process for carrying out the

various steps of the software lifecycle model

Integration & TestDesign CodingRequirements

Unit TestWrite

Test CodeWrite Code

CodeWalkthrough

Lifecycle (Top Level

of SW Process)

More Detailed Software Process

August 1, 2006



All Rights Reserved

Slide # 16

CSE7315M05

Tailoring / Planning(concept)

DEFINE THE APPROACH

UNDERSTAND THE NEED

All Possible Software Lifecyclesand Processes

High Level Process(Software Lifecycle)

Specific Software Process

“V” ModelA General Model of Software Development

Requirements Analysis

Architecture Design

Detailed Design

Implementation

Unit Test

Integration Test

Acceptance Test

Test Cases Based on Requirements

Test Cases Based on Architecture

Test Cases Based on Design

Note: Test Planning Begins with

Requirements!

Note: Test Planning Begins with

Requirements!

August 1, 2006



All Rights Reserved

Slide # 18

CSE7315M05

Some General Categories of Lifecycle Models

• Linear: Do each step once, in order– Example: Waterfall model

• Incremental or Evolutionary: add to the product at each phase– Example: Spiral model

• Iterative: re-do the product at each phase

• Ad-Hoc: No set approach, do what seems appropriate at the time

August 1, 2006



All Rights Reserved

Slide # 19

CSE7315M05

Big-Bang Model (Ad-Hoc)

• Developer receives problem statement.

• Developer implements solution.

• Developer delivers result.

• Developer hopes client is satisfied.

August 1, 2006



All Rights Reserved

Slide # 20

CSE7315M05

Drawbacks of Big-Bang Model

• Little or no consistency between applications of the model– So hard to incorporate lessons learned

• Little or no discipline• Little or no documentation• Little or no transferability to others– So each developer learns on their own

Generally this model works well only for small software applications

August 1, 2006



All Rights Reserved

Slide # 21

CSE7315M05

Waterfall Model of theSoftware Process (Linear)

• Basic Idea: Software is developed in a series of phases that mimic the system lifecycle described above

• Goal: to develop, produce, and support a software product

Royce, Winston - several papers in the late 1960’s and early 1970’s outlined this model.

Royce knew of waterfall’s limitations.

August 1, 2006



All Rights Reserved

Slide # 22

CSE7315M05

Waterfall Model of theSoftware Lifecycle

RequirementsAnalysis

Design

Code

Test

Integrate

Rqmts Specs

Design Specs

Unit Tested Code

Tested Code

August 1, 2006



All Rights Reserved

Slide # 23

CSE7315M05



Design

Code

Test

Integrate

Each phase ends with a review and/or signoff

Rqmts Specs

Design Specs

Unit Tested Code

Tested Code

August 1, 2006



All Rights Reserved

Slide # 24

CSE7315M05



Design

Code

Test

Integrate

Rqmts Specs

Design Specs

Unit Tested Code

Tested Code

Each phase produces artifacts that are input to the next phase

August 1, 2006



All Rights Reserved

Slide # 25

CSE7315M05

Waterfall Assumptions

• Assumption 1: Good Requirements– system or other requirements have

been established (defined and validated);

– those requirements to be addressed by software are clearly defined

– requirements are allocated to all system components (software items)

August 1, 2006



All Rights Reserved

Slide # 26

CSE7315M05

More Waterfall Assumptions

• Assumption 2: A Good System Design– The system design is complete– Software has been fully identified– The software has been divided into

individual “products” or software items– Each software item can be developed

independently– Requirements are clearly allocated to

each software item– Interfaces are clearly defined

August 1, 2006



All Rights Reserved

Slide # 27

CSE7315M05

Typical Waterfall Phases

Exit Criteria

Software Requirements Specification (states what software must do and tests it must pass)

Software Design Specifications (sufficient to code the software)

Code Compiles

Code Passes Tests

Product Passes Tests

Phase


Design - Preliminary - Detailed

Code

Test

Integrate

Goals

Translate Allocated Requirements into Specific, Detailed Software Requirements

Come up with a Design that will Implement the Requirements

Write the Code

Test the Code

Combine Code Units

August 1, 2006



All Rights Reserved

Slide # 28

CSE7315M05

Each Phase has Other Aspects

Reviews

SW Requirements Review

Software Design Review(s)

Code Review(s)

Test Reviews

Product Acceptance Test or Review

Phase


Design

Code

Test

Integrate

Goals

Determine What the SW should Do

Determine How to do it

Do It

Does Code Work?

Does Product Work?

August 1, 2006



All Rights Reserved

Slide # 29

CSE7315M05

An Important Conceptin the Waterfall Model

• Different groups could be assigned to each phase without loss of performance or time

• This concept is the reason behind some of the documentation and review requirements

• This is a good concept in general because on a big project it may be very realistic

August 1, 2006



All Rights Reserved

Slide # 30

CSE7315M05

Problems with the Concept

• This concept is unrealistic in many cases– It is overkill for small projects– It can be costly for any size project

• The organizational structure may or may not fit these assumptions– does each phase have a different

organization?

August 1, 2006



All Rights Reserved

Slide # 31

CSE7315M05

Suggested Student Study

• Determine the milestones, entry criteria, exit criteria, and goals for each phase of the waterfall model

• Use waterfall as a basis for looking at other models – Most are described in terms of how

they differ

NOTE: the essence of the waterfall model is not the names of the specific phases, but rather the

fixed, sequential nature of the phases

NOTE: the essence of the waterfall model is not the names of the specific phases, but rather the

fixed, sequential nature of the phases

August 1, 2006



All Rights Reserved

Slide # 32

CSE7315M05

Waterfall Model Benefits

• Intuitive, logical, basic structure• Tells what, not how• Includes all of the basic tasks of

software development• Adaptable to many situations by

making simple changes or tailoring

August 1, 2006



All Rights Reserved

Slide # 33

CSE7315M05

Waterfall Model Drawbacks:Waterfall Assumes that:

• Requirements are clearly understood– But they change with time (technology, customer

needs, customer understanding of problem)– As we develop we gain insight

• Phases occur sequentially– But errors may require going back to fix– Overlapping phases can be more efficient

• The customer can understand the requirements specification and verify that it is correct– Prototyping and technical interchange may be

necessary in practice

August 1, 2006



All Rights Reserved

Slide # 34

CSE7315M05

Waterfall Model with Backflow


Design

Code

Test

Integrate

Rqmts Specs

Design Specs

Unit Tested Code

Tested Code

This is what actually happens in practice

with most applications of the

model

This is what actually happens in practice

with most applications of the

model

August 1, 2006



All Rights Reserved

Slide # 35

CSE7315M05

The Waffle Principle

• “Plan to throw the first one away; you will anyhow.”

Fred Brooks, “The Mythical Man-Month: Essays on Software Engineering”, Addison Wesley, 1975.Revised in 1995.

August 1, 2006



All Rights Reserved

Slide # 36

CSE7315M05

Spiral Model (Incremental or Iterative)

• Originated by Barry Boehm in the 1970’s

• Basic idea: software is developed as a series of successively more capable prototypes, each of which is designed to build on the previous stages and to address the areas of highest riskBoehm, Barry, “A Spiral Model of Software Engineering,”

IEEE Transactions on Software Engineering, 197?

Prof. Barry

Boehm

August 1, 2006



All Rights Reserved

Slide # 37

CSE7315M05

Spiral Model (continued)

• Goal: same as waterfall: to develop, produce and support a software product

• Difference: an evolutionary series of small steps rather than a single sequence

August 1, 2006



All Rights Reserved

Slide # 38

CSE7315M05

Spiral Model

August 1, 2006



All Rights Reserved

Slide # 39

CSE7315M05

Spiral Assumptions

1) Intial requirements are established but may change based on results of prototypes

2) Good design, allocation – but may also change

3) (new) You know how to identify, analyze, and rank the risks associated with the project

August 1, 2006



All Rights Reserved

Slide # 40

CSE7315M05

Spiral Advantages

• Accommodates changes in requirements

• Facilitates risk management• Supports various forms of

incremental and evolutionary development

August 1, 2006



All Rights Reserved

Slide # 41

CSE7315M05

The “Cycles of Learning” Benefit

• You learn a lot during each iteration, which makes the next one more efficient

• Studies show that by the third or fourth iteration (when you are doing the bulk of the actual work), the development team is functioning very effectively– And the total time may be less than

one “big” iteration, as in the waterfall

August 1, 2006



All Rights Reserved

Slide # 42

CSE7315M05

Spiral Drawbacks• Admits lack of understanding– May be hard for management and

customers to accept)• Does not allow good synchronization

with other parts of the project• Hard to tell exactly where you are

and how much you have left to do– No exit criteria or time-based

milestones• Harder to manage• Can be costly - lots of “throwaway” code

August 1, 2006



All Rights Reserved

Slide # 43

CSE7315M05

Controlled-Iteration Model

• Four phases per major cycle– Inception: Negotiate and define product for

this iteration– Elaboration: Design– Construction: Create fully functional

product– Transition: Deliver product of phase as

specified• The next phase is started before the end of

the previous phase (say at 80% point).

August 1, 2006



All Rights Reserved

Slide # 44

CSE7315M05

Rational Unified Process(a form of controlled iteration)

ManagementEnvironment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Iterations within phases

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

August 1, 2006



All Rights Reserved

Slide # 45

CSE7315M05

Rapid Application Development (RAD) (Incremental

or Iterative)• An extension/extrapolation of the spiral

model• Evolved in the 1980’s and 1990’s among

developers of software for the mass market and networks (e-commerce)– Need products quickly– Products often have short lifetimes– Requirements change very rapidly– The system/environment is fluid

August 1, 2006



All Rights Reserved

Slide # 46

CSE7315M05

DefinitionRapid Application Development

(RAD)

• A collection of programming tools and methods that enables quick production of working software

• Key elements of RAD include:– use of short, incremental development

cycles– libraries of pre-compiled, commonly used

components, such as user interface elements

August 1, 2006



All Rights Reserved

Slide # 47

CSE7315M05

RADRequirements

Analysis

Design

Code

Test

Integrate

Rqmts Specs

Design Specs

Unit Tested Code

Tested Code

Design

CodeTest

Integrate


ComponentLibrary

Artifacts On-lineAnd Dynamic

Rqmts Specs Design

Specs

Code

August 1, 2006



All Rights Reserved

Slide # 48

CSE7315M05

RAD Assumptions

• Interface requirements are established early and kept relatively firm• Application requirements and

system design are fluid• Risks of quality problems are

mitigated by short product life cycles and opportunity to correct in next release

August 1, 2006



All Rights Reserved

Slide # 49

CSE7315M05

Advantages of RAD Model

• Accommodates Changes in Requirements– Each iteration can accommodate new

information about the requirements

• Produces a usable product on each iteration

• Deals effectively with the biggest risk in this specific type of software – failing to meet market windows!

August 1, 2006



All Rights Reserved

Slide # 50

CSE7315M05

The “Cycles of Learning” Benefit

• Even more than with the spiral model, you learn a lot during each iteration, which makes the next one more efficient

• Reuses proven components, so you don’t spend time reinventing

August 1, 2006



All Rights Reserved

Slide # 51

CSE7315M05

Drawbacks of the RAD Model• Hard for outsiders to understand

where you are• Can be chaotic if not managed

effectively• Comprehensive quality checks and

testing are not normally part of the process• Many documents and artifacts are

not produced or not permanent, so long term maintenance can suffer

August 1, 2006



All Rights Reserved

Slide # 52

CSE7315M05

Extreme Programming (XP) (Incremental or Iterative)

• A “lightweight” discipline of software development derived from object oriented programming and based on these principles:– Simplicity– Communication among developers– Feedback– Courage!

• Originated with the “C3” project at Chrysler Corporation in 1997

August 1, 2006



All Rights Reserved

Slide # 53

CSE7315M05

Simple Definition of XP

• A highly iterative form of RAD where the focus is on minimalism– Evolutionary design rather than

planned design• 3-week cycles are typical, even for large

projects• Don’t plan ahead because you will

probably be wrong

– Do only what must be done now - add functionality in later iterations

August 1, 2006



All Rights Reserved

Slide # 54

CSE7315M05

XP Assumptions

• Small, co-located teams• Customers will change their minds• A perfect product cannot be

produced, so get something out and then improve it

• Close customer contact with programmers

August 1, 2006



All Rights Reserved

Slide # 55

CSE7315M05

Key XP Practices

• Refactoring - ongoing redesign to respond to change

• Test first, then code• Pair programming - two people

inspect each others’ work• Continuous integration - daily

builds to solidify interfaces early

August 1, 2006



All Rights Reserved

Slide # 56

CSE7315M05

XP Drawbacks• Simplicity is not always easy to

accomplish• It is easy to drop the discipline and

descend into “hacking”• It doesn’t scale well to really large

projects• The whole thing hinges on the

developers understanding the problem well - no design specs to work from!

August 1, 2006



All Rights Reserved

Slide # 57

CSE7315M05

Summary of Module

• The lifecycle model is the top level view of the process

• There are many different software lifecycle models

• A process/lifecycle must be tailored to fit the needs of the specific project

Slide # 59CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M05

August 1, 2006

Appendix

Other Models

August 1, 2006



All Rights Reserved

Slide # 60

CSE7315M05

R = Understand RequirementsD = DesignI = ImplementE = EvaluateThese are the Basic Steps of

Any Development EffortEssentially Similar to One

Turn of the Spiral Model or One Cycle through the

Waterfall

Tornado Model – A Meta Model

Basic Development Cycle

R

I

DE

August 1, 2006



All Rights Reserved

Slide # 61

CSE7315M05

Tornado ModelSequential Application

• This application is like the spiral model

• Incremental development: each cycle adds new features

• Evolutionary development: each cycle improves the previous one

R

I

DE

August 1, 2006



All Rights Reserved

Slide # 62

CSE7315M05

Tornado ModelOther Applications

• Requirements– Simulation or prototype– To analyze alternatives

or quantify risks

• Design– Build a prototype– Test out a concept

• Implementation– Two incremental pre-

releases

R

I

DE

R

I

DER

I

DE

R

I

DE

R

I

DE

cse 7315 - sw project management / module 5 - software lifecycles and processes copyright ©...

Documents