software life cycles ece 417/617: elements of software engineering stan birchfield clemson...

20
Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Upload: thomas-benson

Post on 17-Dec-2015

221 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Software Life Cycles

ECE 417/617:Elements of Software Engineering

Stan BirchfieldClemson University

Page 2: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson 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)]

Page 3: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Waterfall modelRequirements

Analysis

SystemDesign

ObjectDesign

Coding

Testing

Installation

Maintenance[adapted from Royce (1970)]

Page 4: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Life cycle phases

5 phases of every S/W life cycle:

1. Communication

2. Planning

3. Modeling

4. Construction

5. Deployment

Page 5: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

What is wrong with waterfall?Requirements

Analysis

SystemDesign

ObjectDesign

CodingTesting

Installation

Maintenance

Interrelated nonlinear, sequential

Page 6: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

V-modelRequirements

Analysis

SystemDesign

ObjectDesign

Coding

UnitTesting

SystemTesting

AcceptanceTesting

less

det

ail

mor

e de

tail

build system validate system

is validated by

Page 7: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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

Page 8: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Rapid application development (RAD)

Communication

Planning

Modeling

Construction

DeploymentTeam #N

Modeling

Construction

Team #1

60 – 90 days

Page 9: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Prototyping

Communication

Quick plan

Quick modeling

ConstructPrototype

Delivery

Feedback

• Enables faster feedback• Can be incorporated into other models• But what is the danger?

Page 10: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Shark tooth model

[from Michael Black]

Page 11: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Spiral model

Planning

Modeling

Construction

Deployment Communication

start

Page 12: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Unified process

Communication

Planning

ModelingConstruction

Deployment

softwareincrement inception

elaborationtransition

construction

• Incremental, iterative• “Unified” same originators as UML• Also called Rational Unified Process (RUP)

Page 13: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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

Page 14: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

Extreme programming (XP)

[from extremeprogramming.org]

[Kent Beck 1999]

Page 15: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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?

Page 16: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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

Page 17: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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]

Page 18: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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)]

Page 19: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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]

Page 20: Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University

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]