Title: Software Life Cycles
1Software Life Cycles
ECE 417/617Elements of Software Engineering
Stan Birchfield Clemson University
2The 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)
3Waterfall model
Requirements Analysis
System Design
Object Design
Coding
Testing
Installation
Maintenance
adapted from Royce (1970)
4Life cycle phases
- 5 phases of every S/W life cycle
- Communication
- Planning
- Modeling
- Construction
- Deployment
5What is wrong with waterfall?
Requirements Analysis
System Design
Maintenance
Object Design
Installation
Coding
Testing
Interrelated ? nonlinear, sequential
6V-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
7Incremental 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
8Rapid application development (RAD)
Team 1
Modeling
Communication
Construction
Planning
Deployment
Team N
Modeling
Construction
60 90 days
9Prototyping
Communication
Quick plan
Feedback
Quick modeling
Delivery
Construct Prototype
- Enables faster feedback
- Can be incorporated into other models
- But what is the danger?
10Shark tooth model
from Michael Black
11Spiral model
Deployment
Communication
start
Construction
Planning
Modeling
12Unified 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)
13Unified 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 ...
14Extreme programming (XP)
Kent Beck 1999
from extremeprogramming.org
15XP principles
- Test-driven development
- The planning game
- On-site customer
- Pair programming
- Continuous integration
- Refactoring
- Small releases
- Simple design
- System metaphor
- Collective code ownership
- Coding standards
- 40-hour work week
Pros and cons?
16Model 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
17Synch-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
18Capability 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)
19Personal 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
20Team 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