The Software Process ECE 417617 Elements of Software

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 increment #2 A D increment #1 A D C T M version #3 version #1 time

Rapid application development (RAD) Team #1 Communication Modeling Construction Planning Team #N Modeling Construction Developed by James Martin at IBM in 1980 s 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 CRC cards design planning spike solutions (prototypes) 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]

Formal inspections • • • Developed by Michael Fagan at IBM, 1970 s and 1980 s 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 roles 2. Preparation – participants prepare for roles 3. Inspection – find defects (do not find solutions) 4. Rework – author fixes all defects 5. 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 • IT 1: finds voids and discrepancies in test plan • IT 2: finds errors in test cases • I 0: inspects internal specifications • I 1: inspects design complete spec • I 2: inspects code Note: It is 10 to 100 times less expensive to find/correct errors early in the process