software life cycles ece 417/617: elements of software engineering stan birchfield clemson...
TRANSCRIPT
Software Life Cycles
ECE 417/617:Elements of Software Engineering
Stan BirchfieldClemson University
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)]
Waterfall modelRequirements
Analysis
SystemDesign
ObjectDesign
Coding
Testing
Installation
Maintenance[adapted from Royce (1970)]
Life cycle phases
5 phases of every S/W life cycle:
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
What is wrong with waterfall?Requirements
Analysis
SystemDesign
ObjectDesign
CodingTesting
Installation
Maintenance
Interrelated nonlinear, sequential
V-modelRequirements
Analysis
SystemDesign
ObjectDesign
Coding
UnitTesting
SystemTesting
AcceptanceTesting
less
det
ail
mor
e de
tail
build system validate system
is validated by
Incremental model
A D C T M
increment #1version
#1
A D C T M
increment #2version
#2
A D C T M
increment #3version
#3
time
feat
ure
s
Rapid application development (RAD)
Communication
Planning
Modeling
Construction
DeploymentTeam #N
Modeling
Construction
Team #1
60 – 90 days
Prototyping
Communication
Quick plan
Quick modeling
ConstructPrototype
Delivery
Feedback
• Enables faster feedback• Can be incorporated into other models• But what is the danger?
Shark tooth model
[from Michael Black]
Spiral model
Planning
Modeling
Construction
Deployment Communication
start
Unified process
Communication
Planning
ModelingConstruction
Deployment
softwareincrement inception
elaborationtransition
construction
• Incremental, iterative• “Unified” same originators as UML• Also called Rational Unified Process (RUP)
Unified process work products
Inception phasevision documentinitial use-case modelinitial business caseinitial risk listproject planprototype(s)...
Elaboration phaseuse-case modelrequirementsanalysis modelpreliminary modelrevised risk listpreliminary manual...
Construction phasedesign modelSW componentstest plantest proceduretest casesuser manualinstallation manual...
Transition phaseSW incrementbeta test reportsuser feedback...
Extreme programming (XP)
[from extremeprogramming.org]
[Kent Beck 1999]
XP principles
1. Test-driven development2. The planning game3. On-site customer4. Pair programming5. Continuous integration6. Refactoring7. Small releases8. Simple design9. System metaphor10. Collective code ownership11. Coding standards12. 40-hour work week
Pros and cons?
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]
Capability maturity model (CMM)
Five levels of CMM:1. Performed
Ad hoc, relies on heroic efforts of individuals, life cycle is black box to client – no way to interact
2. RepeatableEach project has well-defined model, able to predict similar future projects, but models differ among projects
3. DefinedAll managerial and technical activities follow documented model, customized version of model produced at beginning of each project
4. Quantitatively managedUses quanitifiable metrics for measuring progress of activities and deliverables
5. OptimizedFeedback from measurement data are used to improve the model over lifetime of organization
[Carnegie-Mellon’s Software Engineering Institute (SEI)]
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]