Transcript Document

The Software Process
ECE 417/617:
Elements of Software Engineering
Stan Birchfield
Clemson University
Life cycle phases
5 phases of every S/W life cycle:
1.
2.
3.
4.
5.
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
Waterfall model
Requirements
Analysis
System
Design
Object
Design
Coding
Testing
Installation
[adapted from Royce (1970)]
Maintenance
What is wrong with
waterfall?
Requirements
Analysis
Maintenance
System
Design
Installation
Object
Design
Testing
Coding
Interrelated  nonlinear, sequential
less detail
V-model
Requirements
Analysis
Acceptance
Testing
is validated by
System
Design
System
Testing
more detail
Object
Design
Unit
Testing
Coding
build system
validate system
features
Incremental model
increment #3
A
D
C
T
M
version
#2
M
version
#3
increment #2
A
D
C
T
increment #1
A
D
C
T
M
version
#1
time
Rapid application development
(RAD)
Team #1
Communication
Modeling
Construction
Planning
Team #N
Modeling
Construction
Developed by James Martin
at IBM in 1980s
60 – 90 days
RAD has largely been discredited because it has not proved successful
"RAD is back", says IBM, Information Age, Feb. 10, 2006
http://www.information-age.com/articles/296861/rad-is-back-says-ibm.thtml
Deployment
Prototyping
Communication
Feedback
Quick plan
Delivery
Quick modeling
Construct
Prototype
• Enables faster feedback
• Can be incorporated into other models
• But what is the danger?
Shark tooth model
[from Michael Black]
Spiral model
Deployment
Communication
start
Construction
Planning
Modeling
“Risk-driven approach”
[developed by Barry Boehm, 1988]
Concurrent
Each activity can be in a different state:
none
under development
awaiting changes
under review
under revision
done
baselined
Unified process
software
increment
Communication
inception
Planning
Deployment
elaboration
transition
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
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
...
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
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
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]
A simpler view of XP
spike solutions
(prototypes)
CRC cards
design
planning
coding
refactoring
test
S/W increment
unit test
acceptance test
continuous integration
XP principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
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?
Adaptive S/W development
(ASD)
• ASD focuses on human collaboration
and team self-organization
collaboration
speculation
learning
S/W increment
[Highsmith 2000]
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)
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.
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
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]
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]
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]