Software Life Cycles ECE 417617 Elements of Software

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

Waterfall model Requirements Analysis System Design Object Design Coding Testing Installation [adapted from Royce (1970)] Maintenance

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 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 60 – 90 days 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 [Boehm]

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)

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

Extreme programming (XP) [Kent Beck 1999] [from extremeprogramming. org]

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?

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. 2. 3. 4. 5. Performed Ad hoc, relies on heroic efforts of individuals, life cycle is black box to client – no way to interact Repeatable Each project has well-defined model, able to predict similar future projects, but models differ among projects Defined All managerial and technical activities follow documented model, customized version of model produced at beginning of each project Quantitatively managed Uses quanitifiable metrics for measuring progress of activities and deliverables Optimized Feedback 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) highlevel 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]