Transcript Lecture for Chapter 15, Software Life Cycle

Using UML, Patterns, and Java
Object-Oriented Software Engineering
15. Software Life Cycle
Outline

Software Life Cycle
 Waterfall model and its problems


Pure Waterfall Model
V-Model
 Iterative process models

Boehm’s Spiral Model
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
Software Life Cycle

Software construction goes through a progression of states
Conception
PreDevelopment
Bernd Bruegge & Allen H. Dutoit
Childhood
Development
Adulthood
Retirement
PostDevelopment
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
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?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
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?
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
7
Possible Identification of Software Development Activities
Requirements Analysis
What is the problem?
System Design
What is the solution?
Problem
Domain
Program Implementation
What are the mechanisms
that best implement the
solution?
Implementation
How is the solution
constructed?
Domain
Testing
Is the problem solved?
Delivery
Can the customer use the solution?
Maintenance
Are enhancements needed?
Program Design
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Software Development as Application Domain: A Use
Case Model
Software development
<<include>>
<<include>>
<<include>>
Problem definition System development System operation
Client Project manager
Developer AdministratorEnd user
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
IEEE Std 1074: Standard for Software
Lifecycle
Process Group
IEEE Std 1074
Project
Management
> Project Initiation
>Project Monitoring
&Control
> Software Quality
Management
PreDevelopment
Development
> Concept
Exploration
> System
Allocation
PostDevelopment
CrossDevelopment
(Integral Processes)
> Requirements
> Installation
Analysis
> Operation &
> Design
Support
> Implementation
> Maintenance
> Retirement
>V&V
> Configuration
Management
> Documentation
> Training
Processes
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Processes, Activities, and Tasks



Process Group: Consists of Set of Processes
Process: Consists of Activities
Activity: Consists of sub activities and tasks
Process
Group
Development
Process
Design
Activity
Design
Database
Task
Bernd Bruegge & Allen H. Dutoit
Make a
Purchase
Recommendation
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
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
....
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Life Cycle Modeling
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]

Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
13
Life-Cycle Model: Variations on a Theme


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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
The Waterfall Model of
the Software Life
Cycle
Concept
Exploration
Process
System
Allocation
Process
Requirements
Process
Design
Process
Implementation
Process
Verification
& Validation
Process
adapted from [Royce 1970]
Installation
Process
Operation &
Support Process
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
15
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
From the Waterfall Model to the V Model
Acceptance
Requirements
Engineering
System
Testing
Requirements
Analysis
Integration
Testing
System Design
Unit
Testing
Object Design
Implementation
Unit
Testing
Integration
Testing
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
System
Testing 17
Activity Diagram of a V Model
System
Requirements
Analysis
precedes
Is validated by
Operation
Software
Requirements
Elicitation
Client
Acceptance
System
Integration
& Test
Requirements
Analysis
Preliminary
Design
Detailed
Design
Component
Integration
& Test
Unit
Test
Implementation
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
18
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
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
19
Spiral Model (Boehm) Deals with Iteration

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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Spiral Model
Determine objectiv es,
alternatives, & c onstraints
Evaluate alternatives,
identify & resolve risks
Risk
analysis
Risk
analysis
Project P1
Risk
analysis
P1
P rototype3
P rototype2
P rototype1
Requirements
plan
Concept of
operation
Softw are
Requirements
Development Requirements
plan validati on
Plan nex t phase
System
P roduct
Desi gn
P2
Integrat ion Desi gn
plan validati on
Det ailed
Desi gn
Code
Unit Test
Develop & verify
nex t level produc t
Integrat ion &Test
Acceptance
Test
Project P2
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
21
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.
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
22
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
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
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
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"
Copyright 2002 Bernd Brügge

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, sawtooth, macro/micro process
lifecycle, unified process)
Software Engineering II, Lecture 3: Scheduling SS 2002
25
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"
Copyright 2002 Bernd Brügge

Level 2 Metrics:
 Software size: Lines of code,
Function points, classes or
method counts
 Personnel efforts: personmonths
 Technical expertise
 Experience with
application domain
 Design experience
 Tools & Method
experience
 Employee turnover within
project
Software Engineering II, Lecture 3: Scheduling SS 2002
26
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
Copyright 2002 Bernd Brügge
 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
Software Engineering II, Lecture 3: Scheduling SS 2002
27
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)
Copyright 2002 Bernd Brügge
 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).
Software Engineering II, Lecture 3: Scheduling SS 2002
28
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
Copyright 2002 Bernd Brügge
Software Engineering II, Lecture 3: Scheduling SS 2002
29
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.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30