The Software Process

1
The Software Process
ECE 417/617Elements 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
Requirements Analysis
System Design
Object Design
Coding
Testing
Installation
Maintenance
adapted from Royce (1970)
4
What is wrong with waterfall?
Requirements Analysis
System Design
Maintenance
Object Design
Installation
Coding
Testing
Interrelated ? nonlinear, sequential
5
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
6
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
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 http//www.informat
ion-age.com/articles/296861/rad-is-back-says-ibm.t
html
60 90 days
8
Prototyping
Communication
Quick plan
Feedback
Quick modeling
Delivery
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
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
software increment
inception
Communication
Planning
Deployment
elaboration
transition
Modeling
Construction
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 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
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
• 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 Chryslers
payroll project in 1996Project canceled in 2000
from extremeprogramming.org
Kent Beck, Extreme Programming Explained, 1999
17
A simpler view of XP
spike solutions(prototypes)
CRC cards
design
planning
coding
refactoring
test
unit test acceptance test continuous integration
S/W increment
18
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?
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)

SEIs 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

SEIs Watts Humphreys