The Software Process

ECE 417/617:Elements of Software Engineering

Stan BirchfieldClemson University

Life cycle phases

5 phases of every S/W life cycle:1. Communication – requirements gathering, project

initiation2. Planning – determine tasks, risks, resources, work

products, schedule; estimate, schedule, track3. Modeling – create models to facilitate more precise

communication and planning; includes analysis and design

4. Construction – code generation and testing5. Deployment – delivery, feedback, support

Two approaches: prescriptive and agile

Waterfall modelRequirements

Analysis

SystemDesign

ObjectDesign

Coding

Testing

Installation

Maintenance[adapted from Royce (1970)]

What is wrong with waterfall?

RequirementsAnalysis

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

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, 2006http://www.information-age.com/articles/296861/rad-is-back-says-ibm.thtml

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

[developed by Barry Boehm, 1988]“Risk-driven approach”

Concurrent

under development

awaiting changes

under revision

under review

baselined

done

none

Each activity can be in a different state:

Unified process

Communication

Planning

ModelingConstruction

Deployment

softwareincrement inception

elaborationtransition

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

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)

[from extremeprogramming.org][Kent Beck, Extreme Programming Explained, 1999]

Kent Beck became project leader of Chrysler’s payroll project in 1996Project canceled in 2000

A simpler view of XP

planning

design

coding

test

S/W increment

refactoring

unit testacceptance testcontinuous integration

CRC cardsspike solutions(prototypes)

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?

Adaptive S/W development (ASD)

• ASD focuses on human collaboration and team self-organization

speculation

collaboration

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]

Formal inspections• Developed by Michael Fagan at IBM, 1970s and 1980s• More effective than informal “walk-throughs”• Participants:

– Designer/Author – responsible for producing program design– Coder/Reader – paraphrases the design/code as if they will implement

it– Tester – views product from testing standpoint– Moderator – acts as “coach”; goal should be to invite “Phantom

Inspector”, the additional presence that seems to materialize from the synergy of the group

• If the coder and designer are the same person, then someone else fills the roll of coder

• Example inspection result:In module X, line Y: check is performed one less time than required – LO/W/MAJ (logic error, wrong, major)

• Maximum inspection rate: 125 Noncommentary source statements (NCSS) per hour (for systems programming)

• An inspection session should not exceed two hours to avoid diminishing ability to concentrate

Inspection process

Each step is essential:1. Overview – educate participants, assign roles2. Preparation – participants prepare for roles3. Inspection – find defects (do not find solutions)4. Rework – author fixes all defects5. Follow-Up – verification by moderator or team

to ensure that no secondary defects have been introduced (approximately 1 in 6 fixes are wrong)

Types of inspections

• IT1: finds voids and discrepancies in test plan

• IT2: finds errors in test cases• I0: inspects internal specifications• I1: inspects design complete spec• I2: inspects code

Note: It is 10 to 100 times less expensive to find/correct errors early in the process