15. Software Life Cycle

Usi

ng U

ML,

Pat

tern

s, an

d Ja

vaO

bjec

t-O

rien

ted

Soft

war

e E

ngin

eeri

ng 15. Software Life Cycle

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Outline

¨ Software Life Cycle Waterfall model and its problems

Pure Waterfall Model V-Model

Iterative process models Boehm’s Spiral Model


Inherent Problems with Software Development¨ Requirements are complex

The client does not know the functional requirements in advance¨ Requirements may be changing

Technology enablers introduce new possibilities to deal with nonfunctional requirements

¨ Frequent changes are difficult to manage Identifying milestones and cost estimation is difficult

¨ There is more than one software system New system must be backward compatible with existing system

(“legacy system”) Phased development: Need to distinguish between the system

under development and already released systems¨ Let’s view these problems as the nonfunctional requirements

for a system that supports software development! This leads us to software life cycle modeling


Definitions

¨ Software lifecycle modeling: Attempt to deal with complexity and change

¨ Software lifecycle: Set of activities and their relationships to each other to support the

development of a software system

¨ Software development methodology: A collection of techniques for building models - applied across the

software lifecycle


Software Life Cycle

¨ Software construction goes through a progression of states

Development Post- Development

Pre- Development

Conception Childhood Adulthood Retirement


Typical Software Lifecycle Questions

¨ Which activities should I select for the software project?

¨ What are the dependencies between activities? Does system design depend on analysis? Does

analysis depend on design?¨ How should I schedule the activities?

Should analysis precede design? Can analysis and design be done in parallel?Should they be done iteratively?

Copyright 2002 Bernd Brügge Software Engineering II, Lecture 3: Scheduling SS 2002 7

Identifying Software Development Activities For finding activities and dependencies we can use the

same modeling techniques when modeling a system such as creating scenarios, use case models, object identification, drawing class diagrams, activity diagrams

Questions to ask: What is the problem? What is the solution? What are the mechanisms that best implement the

solution? How is the solution constructed? Is the problem solved? Can the customer use the solution? How do we deal with changes that occur during the

development? Are enhancements needed?


Possible Identification of Software Development Activities

Requirements Analysis What is the problem?

System Design What is the solution?

Program DesignWhat are the mechanismsthat best implement thesolution?

Program ImplementationHow is the solutionconstructed?

Testing Is the problem solved?

Delivery Can the customer use the solution?

Maintenance Are enhancements needed?

ProblemDomain

ImplementationDomain


Software Development as Application Domain: A Use Case Model

<<include>><<include>>

<<include>>

Client End userDeveloperProject manager

Software development

System developmentProblem definition System operation

Administrator


IEEE Std 1074: Standard for Software Lifecycle

IEEE Std 1074

Project Management

Pre-Development

Development Post-Development

Cross-Development

(Integral Processes)

> Project Initiation>Project Monitoring &Control> Software Quality Management

> Concept Exploration> System Allocation

> Requirements Analysis> Design> Implementation

> Installation> Operation & Support> Maintenance> Retirement

> V & V> Configuration Management> Documentation> Training

Process Group

Processes


Processes, Activities, and Tasks¨ Process Group: Consists of Set of Processes¨ Process: Consists of Activities¨ Activity: Consists of sub activities and tasks

ProcessGroup

Process

Activity

Development

Design

Task

DesignDatabase

Make aPurchase

Recommendation


Example

¨ The Design Process is part of Development¨ The Design Process consists of the following

Activities Perform Architectural Design Design Database (If Applicable) Design Interfaces Select or Develop Algorithms (If Applicable) Perform Detailed Design (= Object Design)

¨ The Design Database Activity has the following Tasks Review Relational Databases Review Object-Oriented Databases Make a Purchase recommendation ....


Many models have been proposed to deal with the problems of defining activities and associating them with each other

The first model proposed was the waterfall model [Royce 1970]

Life Cycle Modeling


¨ Many models have been proposed to deal with the problems of defining activities and associating them with each other

¨ The waterfall model First described by Royce in 1970

¨ There seem to be at least as many versions as there are authorities - perhaps more

Life-Cycle Model: Variations on a Theme


RequirementsProcess

SystemAllocationProcess

ConceptExplorationProcess

DesignProcess

ImplementationProcess

InstallationProcess

Operation &Support Process

Verification& Validation

Process

The Waterfall Model of the Software Life Cycle

adapted from [Royce 1970]


Problems with Waterfall Model

¨ Managers love waterfall models: Nice milestones No need to look back (linear system), one activity at a time Easy to check progress : 90% coded, 20% tested

¨ V-Model ¨ Software development is iterative

During design problems with requirements are identified During coding, design and requirement problems are found During testing, coding, design& requirement errors are found => Spiral Model


From the Waterfall Model to the V Model

System Design

Requirements

Analysis

Requirements

Engineering

Object Design

Integration Testing

System Testing

Unit Testing

Implementation

SystemTesting

Unit Testing

Integration Testing

Acceptance


Activity Diagram of a V ModelSystem

RequirementsAnalysis

Implementation

PreliminaryDesign

DetailedDesign

SoftwareRequirementsElicitation

Operation

ClientAcceptance

RequirementsAnalysis

UnitTest

SystemIntegration

& Test

ComponentIntegration

& Test

precedes

Is validated by


Properties of Waterfall -based Models Managers love waterfall models:

Nice milestones No need to look back (linear system) Always one activity at a time Easy to check progress during development: 90%

coded, 20% tested However, software development is nonlinear

While a design is being developed, problems with requirements are identified

While a program is being coded, design and requirement problems are found

While a program is tested, coding errors, design errors and requirement errors are found


¨ The spiral model proposed by Boehm is an iterative model with the following activities Determine objectives and constraints Evaluate Alternatives Identify risks Resolve risks by assigning priorities to risks Develop a series of prototypes for the identified risks starting with

the highest risk. Use a waterfall model for each prototype development (“cycle”) If a risk has successfully been resolved, evaluate the results of the

“cycle” and plan the next round If a certain risk cannot be resolved, terminate the project

immediately

Spiral Model (Boehm) Deals with Iteration


Spiral ModelDetermine objectives,alternatives, & constraints

Evaluate alternatives,identify & resolve risks

Develop & ver ifynext level productPlan next phase

Requirements

Development

Integration

plan

plan

plan

Requirements

Design

validation

validation

Software SystemProduct

Riskanalysis

Riskanalysis

Prototype1Prototype2

Prototype3

Riskanalysis

Concept ofoperation

RequirementsDesign

Code

Unit Test

Integration & TestAcceptance

DetailedDesign

P1

P2

Test

Project P1

Project P2


Types of Prototypes Illustrative Prototype (Revolutionary Prototyping)

Develop the user interface with a set of storyboards Implement them on a napkin or with a user

interface builder (Visual C++, ....) Good for first dialog with client

Functional Prototype (Evolutionary Prototyping) Implement and deliver an operational system with

minimum functionality Then add more functionality Order identified by risk

Exploratory Prototype ("Hacking") Implement part of the system to learn more about

the requirements.


Process Maturity

¨ A software development process is mature if the development activities are well defined and if management has some control over the quality, budget and

schedule of the project¨ Process maturity is described with

a set of maturity levels and the associated measurements (metrics) to manage the process

¨ Assumption: With increasing maturity the risk of project failure decreases


Capability maturity levels

1. Initial Level also called ad hoc or chaotic

2. Repeatable Level Process depends on individuals ("champions")

3. Defined Level Process is institutionalized (sanctioned by management)

4. Managed Level Activities are measured and provide feedback for resource

allocation (process itself does not change)5. Optimizing Level

Process allows feedback of information to change process itself


Maturity Level 1: Chaotic Process

Ad hoc approach to software development activities No problem statement or requirements specification Output is expected

but nobody knows how to get there in a deterministic fashion

Similar projects may vary widely in productivity "when we did it last year we got it done"

Level 1 Metrics: Rate of Productivity (Baseline comparisons, Collection of data is difficult)

Product size (LOC, number of functions, etc)

Staff effort (“Man-years”, person-months)

Recommendation: Level 1 managers & developers should not concentrate on metrics and their meanings,

They should first attempt to adopt a process model (waterfall, spiral model, saw-tooth, macro/micro process lifecycle, unified process)


Maturity Level 2: Repeatable Process

Inputs and outputs are defined Input: Problem statement or requirements specification Output: Source code

Process itself is a black box ( activities within process are not known)

No intermediate products are visible No intermediate deliverables

Process is repeatable due to some individuals who know how to do it

"Champion"

Level 2 Metrics: Software size: Lines of

code, Function points, classes or method counts

Personnel efforts: person-months

Technical expertise Experience with

application domain Design experience Tools & Method

experience Employee turnover

within project


Maturity Level 3: Defined Process

Activities of software development process are well defined with clear entry and exit conditions.

Intermediate products of development are well defined and visible

Level 3 Metrics (in addition to metrics from lower maturity levels):

Requirements complexity: Number of classes, methods, interfaces

Design complexity: Number of subsystems, concurrency, platforms

Implementation complexity: Number of code modules, code complexity

Testing complexity: Number of paths to test, number of class interfaces to test

Thoroughness of Testing:

Requirements defects discovered

Design defects discovered

Code defects discovered

Failure density per unit (subsystem, code module, class


Maturity Level 4: Managed Process Uses information from early

project activities to set priorities for later project activities (intra-project feedback)

The feedback determines how and in what order resources are deployed

Effects of changes in one activity can be tracked in the others

Level 4 Metrics: Number of iterations per

activity Code reuse: Amount of

producer reuse (time designated for reuse for future projects?)

Amount of component reuse (reuse of components from other projects and components)

Defect identification: How and when (which

review) are defects discovered?

Defect density: When is testing

complete? Configuration

management: Is it used during the

development process? (Has impact on tractability of changes).

Module completion time: Rate at which modules

are completed (Slow rate indicates that the process needs to be improved).


Maturity Level 5: Optimizing Process

Measures from software development activities are used to change and improve the current process

This change can affect both the organization and the project: The organization might change its management

scheme A project may change its process model before

completion


Summary

¨ Software life cycle The development process is broken into individual pieces called

software development activities¨ No good model for modeling the process (black art)

Existing models are an inexact representation of reality Nothing really convincing is available today

¨ Software development standards IEEE 1074 Standards help, but must be taken with a grain of salt The standard allows the lifecycle to be tailored

¨ Capability Maturity Model.

Documents

15. Software Life Cycle