Software Life Cycles

1
Software Life Cycles
ECE 417/617Elements of Software Engineering
Stan Birchfield Clemson University
2
The software crisis

• Three categories of S/W projects
• 16 successful (fully functional, on-time, and
  on-budget)
• 53 challenged (reduced functionality, late,
  over-budget)
• 31 impaired (cancelled)

from Standish Group (1995)
3
Waterfall model
Requirements Analysis
System Design
Object Design
Coding
Testing
Installation
Maintenance
adapted from Royce (1970)
4
Life cycle phases

• 5 phases of every S/W life cycle
• Communication
• Planning
• Modeling
• Construction
• Deployment

5
What is wrong with waterfall?
Requirements Analysis
System Design
Maintenance
Object Design
Installation
Coding
Testing
Interrelated ? nonlinear, sequential
6
V-model
Requirements Analysis
Acceptance Testing
is validated by
less detail
System Design
System Testing
Object Design
Unit Testing
more detail
Coding
build system
validate system
7
Incremental model
increment 3
features
version 3
A
D
C
T
M
increment 2
version 2
A
D
C
T
M
increment 1
version 1
A
D
C
T
M
time
8
Rapid application development (RAD)
Team 1
Modeling
Communication
Construction
Planning
Deployment
Team N
Modeling
Construction
60 90 days
9
Prototyping
Communication
Quick plan
Feedback
Quick modeling
Delivery
Construct Prototype

• Enables faster feedback
• Can be incorporated into other models
• But what is the danger?

10
Shark tooth model
from Michael Black
11
Spiral model
Deployment
Communication
start
Construction
Planning
Modeling
12
Unified process
software increment
inception
Communication
Planning
Deployment
elaboration
transition
Modeling
Construction
construction

• Incremental, iterative
• Unified ? same originators as UML
• Also called Rational Unified Process (RUP)

13
Unified process work products
Inception phase vision document initial use-case
model initial business case initial risk
list project plan prototype(s) ...
Elaboration phase use-case model requirements anal
ysis model preliminary model revised risk
list preliminary manual ...
Construction phase design model SW
components test plan test procedure test
cases user manual installation manual ...
Transition phase SW increment beta test
reports user feedback ...
14
Extreme programming (XP)
Kent Beck 1999
from extremeprogramming.org
15
XP principles

1. Test-driven development
2. The planning game
3. On-site customer
4. Pair programming
5. Continuous integration
6. Refactoring
7. Small releases
8. Simple design
9. System metaphor
10. Collective code ownership
11. Coding standards
12. 40-hour work week

Pros and cons?
16
Model summary

• Prescriptive models
• Waterfall
• Incremental
• RAD
• Spiral
• Concurrent development
• Component-based development
• Formal methods
• Aspect oriented
• Unified process (RUP)

• Agile models
• Extreme programming (XP)
• Adaptive software development (ASD)
• Dynamic systems development (DSDM)
• Scrum
• Crystal
• Feature driven development (FDD)
• Agile model

17
Synch-and-stabilize

• How to balance structure and flexibility?
• Solution
• Plan product with vision statement
• Translate into specification document with enough
  detail to divide the work
• Divide into parts and assign to teams
• Teams are free to implement, innovate as they
  wish
• Teams work under common environment
• Teams check-in work frequently
• Frequent (daily) builds
• Always a working system
• Easy to test, see defects, measure progress
  continually

from How Microsoft Builds Software, Cusumano
and Selby
18
Capability maturity model (CMM)

• Five levels of CMM
• PerformedAd hoc, relies on heroic efforts of
  individuals, life cycle is black box to client
  no way to interact
• RepeatableEach project has well-defined model,
  able to predict similar future projects, but
  models differ among projects
• DefinedAll managerial and technical activities
  follow documented model, customized version of
  model produced at beginning of each project
• Quantitatively managedUses quanitifiable metrics
  for measuring progress of activities and
  deliverables
• OptimizedFeedback from measurement data are used
  to improve the model over lifetime of organization

Carnegie-Mellons Software Engineering Institute
(SEI)
19
Personal software process (PSP)

• Individual developers should
• measure the quality of output
• plan (estimate and schedule work)
• identify likely and actual errors
• use metrics to improve process
• Activities (1) planning, (2) high-level design,
  (3) high-level design review, (4) development,
  (5) postmortem
• Disciplined metrics-based approach to software
  engineering
• Requires significant training
• Improves productivity and quality, but resisted
  by many developers (culture shock)

SEIs Watts Humphreys
20
Team software process (TSP)

• Project team should
• be self-directed, able to plan and track their
  work, establish goals, and own their processes
  and plans
• have consistent understanding of its overall
  goals and objectives
• define roles and responsibilities
• track quantitative project data
• identify and implement an appropriate process for
  the project
• define local standards
• continually assess and respond to risks
• track, manage, and report project status
• Activities (1) launch, (2) high-level design,
  (3) implementation, (4) integration and test, (5)
  postmortem
• Rigorous approach that requires a full commitment
  from the team
• Requires thorough training
• Improves productivity and quality

SEIs Watts Humphreys