1. Software Life Cycles ECE 417/617: Elements 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 [adapted from Royce (1970)] 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
Maintenance
System
Design
Installation
Object
Design
Testing
Coding
Interrelated  nonlinear, sequential

6. V-model is validated by less detail more detail build system
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 features time increment #3 version #3 increment #2#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 Enables faster feedback
Communication
Feedback
Quick plan
Delivery
Quick modeling
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 Construction Planning Modeling
start
Construction
Planning
Modeling

12. Unified process inception elaboration transition construction
software
increment
inception
Communication
Deployment
Planning
transition
elaboration
Construction
Modeling
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
analysis 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 Pros and cons? 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?

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:
Performed Ad hoc, relies on heroic efforts of individuals, life cycle is black box to client – no way to interact
Repeatable Each project has well-defined model, able to predict similar future projects, but models differ among projects
Defined All managerial and technical activities follow documented model, customized version of model produced at beginning of each project
Quantitatively managed Uses quanitifiable metrics for measuring progress of activities and deliverables
Optimized Feedback from measurement data are used to improve the model over lifetime of organization
[Carnegie-Mellon’s 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)
[SEI’s 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
[SEI’s Watts Humphreys]