ECE 355, Winter 2007

Software Processes
- Life-cycle Models (Process Models)
Build-and-Fix
Waterfall
Rapid Prototyping
Incremental
Evolutionary
Spiral
- Process Improvements: CMM
- Metrics: product and process
Handouts: 6
Prepared by: Sagar Naik

1
 SE Process?
• A process defines
– Who is doing what, when and how in the development of
a software system
• S/W development activities and their ordering
» Requirement elicitation
» Specification
» Design
» Code
» Test: unit, integration, system
» Maintain

New or changed New or changed system

requirements
SE Process

2
 Process vs. Product
Process: the only thing you retain
The asset that distinguishes you from
your competitor en route to a product
The asset that gets you to your next product
The asset that determines key properties of Process Tools
Automation
your products

Template

Participants
People Project

Result

 Gets you revenue …

Product

3
 Lightweight vs. Heavyweight Processes

Lightweight Heavyweight
(eXtreme Programming: XP) (Waterfall)

- Focus on working code, rather - Document driven

than documentation - Elaborate workflow definitions
- Focus on direct communication - Many different roles
- between developers, and - Many checkpoints
- between developers and customer - Highly bureaucratic
- Low management overhead - High management overhead

Important:
- Choose a process depending on the type of product being developed.
- For large systems, management is a big problem  choose a strictly managed process
- For small systems, more informality is possible …

- Inappropriate selection of a process  high cost

4
 Build-and-Fix Model
• Properties
• No planning
Build first
• Only product: working code version

• Adv: Good for small systems

• Disadvantage Modify until
client is
– Increasing code size  rapidly satisfied

decreasing understandability
and maintainability

Maintenance

-Need a life-cycle model

- “Game plan”
- Phases
- Milestones
Retirement

5
 Waterfall Model
• Properties Requirements Changed Req.

Verify Verify
» Sequential steps
» Feedback loops
» Documentation-driven Specification

• Advantages Verify

» Documentation
» Easier maintenance Design

• Disadvantages Verify

» Complete and frozen

specification up-front
Code
may not be feasible
» Customer involvement Test
in the first phase only
» Sequential and Integration
complete execution of
phases are often not Test
desirable
» The product becomes
Maintain
available very late in the
process
6
Retirement
 Rapid Prototyping Model
• Prototyping + Waterfall Prototype Changed Req.

• Do not turn the rapid prototype into Verify Verify

the product
• Never replace the design phase Specification
• Comparison: Verify
• Waterfall model
– try to get it right the 1st time
Design
• Rapid prototyping
– frequent change + discard Verify

• Advantages
• Requirements better specified and Code
validated Test
• Early feasibility analysis
• Strong involvement of the
Integration
customer in prototyping
• Disadvantages Test

• Higher development effort

• Danger that due to schedule slip, the Maintain
prototype becomes part of the product

7
Retirement
 Incremental

Release 1
Design Coding Test Deployment
Requirements

Release 2
Design Coding Test Deployment
Release 3
Design Coding Test Deployment

Each release adds more functionality,

i.e., a new increment

(Some call it iterative) 8

 Incremental Model (contd)
• Waterfall, rapid prototyping models
– Operational quality complete product at end
• Incremental model
– Operational quality portion of product within weeks
– Less traumatic
– Smaller capital outlay, rapid return on investment

9
 Evolutionary

Version 1
Requirements Design Coding Test Deployment
Version 1
Requirements Design Coding Test Deployment

Version 1 Feedback
Requirements Design Coding Test Deployment

New versions implement new and

evolving requirements

(Some call it iterative)

10
 Evolutionary Model (contd.)
• Advantages
• Constant customer involvement and validation
• Allows for good risk management
• Disadvantages
• Build-and-fix danger

11
Spiral Model

12
 Spiral model

Deter mine ob jectiv es

Evaluate altern atives
alternatives and id en tif y, resol ve risk s
cons traint s Risk
analys is
Risk
a nalys is
Risk
a nalys is Opera-
Prot otype 3 ti onal
Prot otyp e 2 prot oype
Risk
REVIE W analysis Prot o-
ty pe 1
Require ment s plan Simulati ons, models, b en ch marks
Life-cycle plan Concept of
Operati on S/W
require ment s Prod uct
desi gn Detailed
Require ment desi gn
Develop me nt
plan valid ati on Code
Desi gn Unit tes t
Integrati on
and test p lan V&V Inte gr ati on
Pla n next p has e test
Accep tance
Serv ice test Develop, v erif y
next-level prod uct
13
 Spiral model
• Waterfall model plus
– risk analysis preceding each phase and evaluation
following each phase
• Prototyping for high-risk specifications
• Radial dimension: cumulative cost to date
• Angular dimension: progress through the spiral
• If all risks cannot be resolved, the project is
immediately terminated
• Appropriate only for big projects (high
management overhead)

14
 Process model risk problems
• Waterfall
• High risk for new systems because of
specification and design problems
• Low risk for well-understood developments using
familiar technology
• Prototyping
• Low risk for new applications because
specification and program stay in step
• High risk because of lack of process visibility
• Evolutionary and Spiral
• Middle ground between waterfall and prototyping

15
 Hybrid process models
• Large systems are usually made up of several
sub-systems
• The same process model need not be used for
all subsystems
• Prototyping for high-risk specifications
• Waterfall model for well-understood systems
• Tailor the process to a problem

16
Rational Unified Process (RUP) Model (from
IBM)
• Characteristics
– Iterative and incremental
– Use-case-driven
– Architecture-centric
– Uses UML as its modeling notation
– Provides
• Comprehensive set of document templates and process
guidelines

17
 RUP is Use-Case-Driven and Architecture-Centric
• Use cases drive numerous activities
• Creation and validation of the design model
• Definitions and procedures of the test cases
• Creation of user documentation
• Build, validate, and baseline an architecture
• Prototype the architecture to validate it
• A validated architecture serves as the baseline
• Other artifacts derive from architecture
• Product structure
• Team structure

18
 Life-cycle Phases and Major Milestones

Inception Elaboration Construction Transition

time

Lifecycle Lifecycle Initial Operational Product

Objective Architecture Capability Release
Milestone Milestone Milestone

The Rational Unified Process has four phases:

Inception - Define the scope of project
Elaboration - Plan project, specify features, baseline
architecture
Construction - Build the product
Transition - Transition the product into end user community
19
 Iterations and Phases

Inception Elaboration Construction Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Minor Milestones: Releases

An iteration is a distinct sequence of activities with an established plan and
evaluation criteria, resulting in an executable release (internal or external)

20
 XP Overview
Characteristics
• Evolutionary development
• Focus on working code that
Planning Every 2-3 implements customer needs
weeks
(rather than documents)
Write tests
• Testing is a crucial element
• Focus on flexibility and
efficiency of the process
Pair Programming
Release
+ Refactoring • Designed for small teams
(<10)
Test

Min.
Integration
daily

21
 XP Practices (I)
• Planning
– Small releases
– Start with the smallest useful feature set
– Release early and often, adding a few features each time
– Stakeholders meet to plan the next iteration
– Business people decide on business value of features
– Developers identify the technical risk of features and predict effort per feature
• Simple Design
– Always use the simplest possible design to get the job done (runs the tests and
states intentions of the programmer)
• Testing
– Test-first: write test, then implement it
– Programmers write unit tests and customers write acceptance tests
• Refactoring
– Refactoring is done continuously; the code is always kept clean

22
 XP Practices (II)
• Pair programming: all production code written by two
• One programmer is thinking about implementing the current method,
the other is thinking strategically about the whole system
• Pairs are put together dynamically
• Continuous integration
• All changes are integrated into the code-base at least daily
• The tests have to run 100% before and after the integration
• 40-hrs week
• Programmers go home on time
• Overtime is a symptom of a serious problem
• No errors by tired developers
• On-site customer
• Development team has continuous access to a real life customer/user
• Coding standards
• Everyone codes to the same standards
23
 XP Practices
• Advantages
– Simple concept
– Low management overhead (no complicated procedures to
follow, no documentation to maintain, direct communication)
– Continuous risk management (early feedback from the
customer)
– Continuous effort estimation
– Emphasis on testing
• tests help in evolution and maintenance
• Disadvantages
– Appropriate for small teams (up to 10 developers)
– If maintainers are not the people that developed the
code, good documentation is necessary
24
 Reading
• RUP
– Craig Larman, Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and the Unified Process, Prentice-Hall,
2002 (2nd edition)
• Agile development
– Kent Beck, Extreme Programming: Explained, Addison-Wesley, 1999

25
 Note: An Effective Process …
• Provides guidelines for efficient development of
quality software
• Reduces risk and increases predictability
• Captures and presents best practices
• Promotes common vision
• Provides roadmap for applying tools

26
 Software Process Improvement Initiatives
• Capability Maturity Model (CMM)
• http://www.sei.cmu.edu/cmm/cmms/cmms.html
• ISO 9000-series

27
©Steven Schach 2002 [modified]
 SW–CMM
(SEI, 1986)
– A strategy for improving the software process
– Fundamental ideas:
• Improving the software process leads to
– Improved software quality
– Delivery on time, within budget
• Improved management leads to
– Improved techniques
– Five levels of “maturity” are defined
– Organization advances stepwise from level to level

28
©Steven Schach 2002
 Levels 1 and 2
• Level 1: Initial (Most organizations world-wide are at this)
• Ad hoc approach
– Entire process is unpredictable
– Management consists of responses to crises

• Level 2: Repeatable
• Basic software management
• Management decisions should be made on the basis
of previous experience with similar products
• Measurements (“metrics”) are made
– These can be used for making cost and duration
predictions in the next project
• Problems are identified, immediate corrective action
is taken
29
 Levels 3, 4 and 5
• Level 3: Defined
– The software process is fully documented
• Managerial and technical aspects are clearly defined
• Continual efforts are made to improve quality + productivity
• Reviews are performed to improve software quality
• CASE tools are applicable now (and not at levels 1 or 2)
• Level 4: Managed
– Quality and productivity goals are set for each project
• Quality, productivity are continually monitored
• Statistical quality controls are in place
• Level 5: Optimized
– Continuous process improvement
• Statistical quality and process controls
• Feedback of knowledge from each project to the next

30
SW–CMM Summary

31
 Software Metrics

• Any type of measurement which relates to a

software system, process or related documentation
– # of lines of code in a program
– # of test cases designed per day
– # of test cases executed per day
– # of person-days required to develop a component
– # of failures observed

• Allow the software and the process to be quantified

• Should be
– Captured automatically, and
– Monitored, if possible

32
 Product Quality Metrics
• A quality metric should be a predictor of
product quality
• Note
• Most quality metrics are design quality metrics
(measure coupling and complexity)
• The relationship between these metrics and
quality has to be judged by a human
• There are no “magic thresholds,” rather the trend
of metrics over time needs to be monitored

33
 Software Metrics
• Design Metrics
• Coupling metrics
– # of calling functions or called functions
• Cyclomatic complexity
– a measure of control structure complexity
• OO metrics
– Coupling between objects (CBO)
– Depth of inheritance tree (DIT)

• Quality Metrics
– # of failures observed
– Rate of observed failure

34
 Process Metrics
• Time taken for process activities to be completed
• Ex. Calendar time to complete an activity
• Resources required for processes or activities
• Ex. Total effort in person-days
• Number of occurrences of a particular event
• Ex. Number of defects discovered

Note: Process improvement requires process measurement …

35
 Goal-Question-Metric Paradigm
• Goals
– What is the organisation trying to achieve?
– The objective of process improvement is to satisfy these goals
• Questions
– Questions about areas of uncertainty related to the goals.
– You need process knowledge to derive these
• Metrics
– Measurements to be collected to answer the questions

36
 Goal-Question-Metric Paradigm: Example
• Goal
– Reduce the requirements related defects
• Questions
– How many defects have been introduced in the
requirements phase?
– Why did the defects go undetected?
• Metrics
– Classify the defects
– Count how many are requirements related
– Answer: Why did the defect go undetected
– Take action to prevent a similar defect
37