Software Development Process: Life Cycle Models

1
Software Development Process Life Cycle Models
Aditya P. Mathur
Department of Computer Science
Purdue University, West Lafayette
Last Update Tuesday August 19, 2003
2
Objectives

• What is a process?

• What is Software Development Process (SDP) ?

• How is SDP organized (life cycle models)?

• How is process maturity measured?

• What are the benefits of a good process ?

3
Process
Step
Step 1
Step 2
Sequential or linear process
4
Concurrent Process
Parallel or concurrent process
5
Iterative Process
Iterative process
6
Features of a process

• One or more steps.

• Each step is well defined.

• Input and output of each step is well defined and
  observable.

• Start and end of a step can be identified.

7
Process model Linear

• An arrangement of process steps.

8
Process model Concurrent
9
Process model Iterative
10
Software Development Process

• Steps correspond to one or more tasks related to
  software development.

• Tasks

• Integration

• Requirements gathering

• Test

• Requirements analysis

• Delivery

• Design

• Maintenance

• Coding

• Training

• Software life cycle Software Life Cycle consists
  of all phases from its inception until its
  retirement. These are Inception, elaboration,
  construction, transition.

11
Models of Software Life Cycle

• Build and fix

• Waterfall (classic)

• Rapid prototyping

• Incremental

• Spiral

• Unified

12
Build and fix model 1
Idea or client request
13
Build and fix model 2

• Product is constructed without specifications.

• There is no explicit design. However, a design
  will likely evolve in the mind of the developer.

• The approach might work for small programming
  projects TA 162/252.

14
Build and fix model 3

• Cost of fixing an error increases as one moves
  away from the phase in which the error was
  injected.

• There is a good chance that many errors will be
  found in the operations phase thereby leading to
  high cost of maintenance.

• Rarely used in commercial projects.

15
Waterfall model 1
Requirements phase
Verification done at the end of each phase.
16
Waterfall model 2

• Popular in the 70s.

• Requirements are determined and verified with the
  client and members of the SQA group.

• Project management plan is drawn, cost and
  duration estimated, and checked with the client
  and the SQA group

• Then the design (i.e. How is the product going
  to do what it is supposed to do.) begins and the
  project proceeds as in the figure.

17
Waterfall model 3

• Each phase terminates only when the documents are
  complete and approved by the SQA group.

• Notice the feedback loop between the Design phase
  and the Specifications phase.

• Maintenance begins when the client reports an
  error after having accepted the product. It could
  also begin due to a change in requirements after
  the client has accepted the product.

18
Waterfall model Advantages

• Disciplined approach

• Careful checking by the Software Quality
  Assurance Group at the end of each phase.

• Testing in each phase.

• Documentation available at the end of each phase.

19
Waterfall model Disdvantages

• Documents do not always convey the entire
  picture.

• Specification documents are detailed and
  difficult to read/understand for the client.

• Feedback from one phase to another might be too
  late and hence expensive.

20
Rapid prototyping model

• A working model of the product is developed
  (quickly, 1-3 months). Serves to elicit
  requirements.

• Client interacts with the prototype
  specifications are developed.

• Subsequent phases, design, coding etc., follow.
  Feedback loops less likely and fewer.

Should the prototype be discardded or refined ?
21
Incremental model 1
Requirements phase
Verification done at the end of each phase.
22
Incremental model 2

• Product architecture is designed. It serves as
  the main driver of the development process.

• Features are prioritised and increments defined.

• Product is designed, implemented, and integrated
  as a series of incremental builds.

• A build contains code from various modules to
  provide the desired functionality.

• A new build integrates code from previous build
  and new code.

23
Incremental model 3

• Client can begin using the first build.

• Facilitates early adoption by the client.

• Client pays in increments financial benefit.

• Design of the initial architecture is a difficult
  step. Poor architecture may lead to lots of
  changes in builds.

Should we construct builds in parallel?
24
Unified Development Process 1

• Key features Iterative development OO analysis
  and design.

• Development organized as a series of short
  iterations

• Each iteration produces a working, executable,
  product that might not be a deliverable.

• No rush to code. Aslso, not a long drwan design
  process.

• Lots of visual modeling aids. Unified Modeling
  Language (UML) used.

25
Unified Development Process 2

• Early iterations seek feedback from the customer.
  Risk and value to customer is managed through
  early feedback.

• Customer is engaged continuously in evaluation
  and requirements gathering.

• Architecture is built during early iterations.

26
Unified Development Process 3
27
The Unified Process

• Why a Process?
• Software projects are large, complex,
  sophisticated
• time to market is key
• many facets involved in getting to the end
• Common process should
• integrate the many facets
• provide guidance to the order of activities
• specify what artifacts need to be developed
• offer criteria for monitoring and measuring a
  project

28
The Unified Process

• Component based - meaning the software system is
  built as a set of software components
  interconnected via interfaces
• Uses the Unified Modeling Language (UML)
• Use case driven
• Architecture-centric
• Iterative and incremental

This is what makes the Unified process Unique
Component A physical and replaceable part of a
system that conforms to and provides realization
of a set of interfaces. Interface A collection
of operations that are used to specify a service
of a class or a component
29
The Unified Process
Users requirements
Software Development Process
Software System
30
The Unified Process

• Use Case driven
• A use case is a piece of functionality in the
  system that gives a user a result of value
• Use cases capture functional requirements
• Use case answers the question What is the system
  supposed to do for the user?

31
The Unified Process

• Architecture centric
• similar to architecture for building a house
• Embodies the most significant static and dynamic
  aspects of the system
• Influenced by platform, OS, DBMS etc.
• Primarily serves the realization of use cases

32
The Unified Process

• Iterative and Incremental
• commercial projects continue many months and
  years
• to be most effective - break the project into
  iterations
• Every iteration - identify use cases,create a
  design, implement the design
• Every iteration is a complete development process

33
The Unified Process

• Look at the whole process
• Life cycle
• Artifacts
• Workflows
• Phases
• Iterations

34
The Life of the Unified Process

• Unified process repeats over a series of cycles
• Each cycle concludes with a product release
• Each cycle consists of four phases
• inception
• elaboration
• construction
• transition

35
The Life of the Unified Process
Time
Elaboration
Inception
Construction
Transition
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
1
1
1
1
Release 1
A cycle with its phases and its iterations
36
Life Cycle Models Summary 1

• Build and fix Acceptable for short programs that
  do not require maintenance.

• Waterfall Disciplined approach, document driven
  delivered product may not meet client needs.

• Rapid prototyping Ensures that delivered product
  meets client needs might become a build-and-fix
  model.

• Incremental Maximizes early return on
  investment requires open architecture may
  degenerate into build-and-fix.

37
Life Cycle Models Summary 2

• Spiral Risk driven, incorporates features of the
  above models useful for very large projects

• UDP Iterative, supports OO analysis and design
  may degenerate into code-a-bit-test-a-bit.

38
Objectives

• Why do software projects fail/succeed?

• How is process maturity measured ? Key Process
  Areas?

• How to do requirements analysis? What are UML,
  use cases, domain model, actors ?

39
Standish Report 1995
Company categorization by revenue

• Large company 500M
• Medium company 200-500M
• Small company 100-200M

Sample size 365 respondants, 8380 applications.
40
Standish Report Project categorization
Success/failure

• Resolution Type 1 On time, on budget, all
  features.

16.2

• Resolution Type 2 Completed, over time, over
  budget, fewer features.

52.7

• Resolution Type 3 Cancelled during the
  development cycle.

31.1
41
Standish Report Failure Statistics

• Success rate Large companies 9
• Medium 16.2
• Small 28

• Resolution type 2 Large 61.5
• Medium 46.7
• Small 50.4

• Resolution type 3 Medium 37.1,
• Large 29.5
• Small 21.6

42
Standish Report Cost Overruns
Cost Overruns of Responses Under 20
15.5 21 - 50 31.5 51 - 100 29.6
101 - 200 10.2 201 - 400 8.8 Over
400 4.4
43
Standish Report Time Overruns
Time Overruns of Responses Under 20 13.9
21 - 50 18.3 51 - 100 20.0 101 -
200 35.5 201 - 400 11.2 Over 400
1.1
44
Standish Report Success Profile 1

• Project Success Factors of Responses
• User Involvement 5.9
• Executive Management Support 13.9
• Clear Statement of Requirements 13.0
• Proper Planning 9.6
• Realistic Expectations 8.2

45
Standish Report Success Profile 2

• Project Success Factors of Responses
• Smaller Project Milestones 7.7
• Competent Staff 7.2
• Ownership 5.3
• Clear Vision Objectives 2.9
• Hard-Working, Focused Staff 2.4
• Other 13.9

46
Standish Report Failure stories
California DMV Started 1987. Project
cancelled 1993. Cost45M
American airlines 1994 Settled lawsuit with
Hilton/Marriott/Budget-rent-a
car CONFIRM car rental project failed
47
Standish Report Success Potential
Success Criteria Points DMV CON HYATT
ITAMARATI
1. User Involvement 19 NO ( 0) NO ( 0) YES
(19) YES (19)
2. Management Support 16 NO ( 0) YES (16) YES
(16) YES (16)
3. Clear Requirements 15 NO ( 0) NO ( 0) YES
(15) NO ( 0)
5. Realistic Expectations 10 YES (10) YES (10)
YES (10) YES (10)
10. Hard-Working Staff 3 NO ( 0) YES ( 3)
YES ( 3) YES ( 3)
TOTAL 100 10 29 100 85
48
Capability Maturity Model (CMM)
Process maturity is a measure of the discipline
used by an organization during the development of
a software product.
CMM assists in determining how mature a process
is.
Purpose To assess and help improve process in
software development organizations.
49
Capability Maturity Model (CMM)
Capability maturity levels Level
1 Initial Worst Level 2 Repeatable Level 3
Defined Level 4 Managed Level 5
Optimizing Best
50
CMM Levels 1
Initial The software
process is characterized as ad hoc,
and occasionally even as chaotic. Few processed
are defined, and success depends on individual
effort.
Lacks Reasonable process.
51
CMM Levels 2
Repeatable Basic
project management processes are established to
track cost, schedule and functionality. the
necessary process discipline is in place to
repeat earlier successes on projects with similar
applications.
Lacks Complete process.
52
CMM Levels 3
Defined The software
process for both management and
engineering activities is documented,
standardized and integrated into a standard
software process for the organization. All
projects use an approved, tailored version of the
organization's standard software process for
developing and maintaining software.
Lacks Predictable outcomes.
53
CMM Levels 4
Managed Detailed
measures of the software process and product
quality are collected. Both the software process
and products are quantitatively understood and
controlled.
Lacks Mechanism for process improvement.
54
CMM Levels 4
Optimized Continuous
process improvement is enabled by
quantitative feedback from the process and from
piloting innovative ideas and technologies.
55
Key Process Areas 1
Optimizing Defect prevention Technology change
management Process change management
Managed Quantitative process management Softwar
e quality management
56
Key Process Areas 2
Defined Organization process focus Training
programs Integrated software management Peer
reviews
Repeatable Requirements management Software
project planning Software quality
assurance Software configuration management
57
Maturity and product quality 1
58
Maturity and product quality 2
59
CMM Documents ?
http//www.sei.cmu.edu/cmm/cmms/cmms.html