1. The Software Process ECE 417/617: Elements of Software Engineering
Stan Birchfield
Clemson University

2. Life cycle phases 5 phases of every S/W life cycle:
Communication – requirements gathering, project initiation
Planning – determine tasks, risks, resources, work products, schedule; estimate, schedule, track
Modeling – create models to facilitate more precise communication and planning; includes analysis and design
Construction – code generation and testing
Deployment – delivery, feedback, support
Two approaches: prescriptive and agile

3. Waterfall model [adapted from Royce (1970)] Requirements Analysis
System
Design
Object
Design
Coding
Testing
Installation
Maintenance
[adapted from Royce (1970)]

4. What is wrong with waterfall?
Requirements
Analysis
Maintenance
System
Design
Installation
Object
Design
Testing
Coding
Interrelated  nonlinear, sequential

5. 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

6. Incremental model features time increment #3 version #3 increment #2#1 A D C T M
time

7. Rapid application development (RAD)
Team #1
Modeling
Communication
Construction
Planning
Deployment
Team #N
Modeling
Construction
Developed by James Martin at IBM in 1980s
RAD has largely been discredited because it has not proved successful
"RAD is back", says IBM, Information Age, Feb. 10, 2006
60 – 90 days

8. 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?

9. Shark tooth model
[from Michael Black]

10. Spiral model “Risk-driven approach” Deployment Communication
start
Construction
Planning
Modeling
“Risk-driven approach”
[developed by Barry Boehm, 1988]

11. Concurrent Each activity can be in a different state: none
under development
awaiting changes
under review
under revision
baselined
done

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)
Based on spiral model, developed at Rational Software, a division of IBM since 2003

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. Agile development S/W development is unpredictable
requirements will change (which ones?)
design and construction are interleaved (how much design is needed?)
analysis and testing, too
Solution: Use an adaptable process
incremental development strategy

15. Agile principles Agile Manifesto (2001) values Agile principles:
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
Agile principles:
satisfy customer (highest priority)
early and frequent S/W delivery
welcome changing requirements
work daily with business people and developers
build projects around motivated individuals
simplicity: maximize the amount of work NOT done
self-organizing teams
regular reflection to adjust behavior to improve effectiveness

16. Extreme programming (XP)
Kent Beck became project leader of Chrysler’s payroll project in 1996 Project canceled in 2000
[Kent Beck, Extreme Programming Explained, 1999]
[from extremeprogramming.org]

17. A simpler view of XP design planning coding test
spike solutions (prototypes)
CRC cards
design
planning
coding
refactoring
test
unit test
acceptance test
continuous integration
S/W increment

18. 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?

19. Adaptive S/W development (ASD)
ASD focuses on human collaboration and team self-organization
collaboration
speculation
learning
S/W increment
[Highsmith 2000]

20. Scrum Backlog – prioritized list of project requirements or features
Sprints – work units required to achieve a requirement
deliver within fixed time (30 days)
no changes to requirement allowed during that time
Daily meetings (15 min.)
What did you do?
What obstacles are you encountering?
What is your plan?
Demos – S/W increments delivered to customer (can ship final product upon demand)

21. BDUF controversy BDUF – Big design up front
Proponents claim that planning up front saves lots of time in the end
Much faster to fix a bug in the spec than in the code
An ounce of prevention is worth a pound of cure
Who is right? Both. Strive for balance.

22. 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

23. 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]

24. 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]

25. 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]