1 / 28

The Software Process

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: Communication – requirements gathering, project initiation

eramon
Download Presentation

The Software Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Software Process ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. Life cycle phases 5 phases of every S/W life cycle: • 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

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

  4. What is wrong with waterfall? Requirements Analysis Maintenance System Design Installation Object Design Testing Coding Interrelated  nonlinear, sequential

  5. V-model Requirements Analysis Acceptance Testing is validated by less detail System Design System Testing Object Design Unit Testing more detail Coding build system validate system

  6. Incremental model increment #3 features version #3 A D C T M increment #2 version #2 A D C T M increment #1 version #1 A D C T M time

  7. Rapid application development (RAD) Team #1 Modeling Communication Construction Planning Deployment Team #N Modeling Construction 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, 2006 http://www.information-age.com/articles/296861/rad-is-back-says-ibm.thtml 60 – 90 days

  8. Prototyping Communication • Enables faster feedback • Can be incorporated into other models • But what is the danger? Feedback Quick plan Delivery Quick modeling Construct Prototype

  9. Shark tooth model [from Michael Black]

  10. Spiral model Deployment Communication start Construction Planning Modeling “Risk-driven approach” [developed by Barry Boehm, 1988]

  11. Concurrent Each activity can be in a different state: none under development awaiting changes under review under revision baselined done

  12. Unified process software increment inception Communication • 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 Planning Deployment elaboration transition Modeling Construction construction

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

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

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

  16. Extreme programming (XP) Kent Beck became project leader of Chrysler’s payroll project in 1996Project canceled in 2000 [from extremeprogramming.org] [Kent Beck, Extreme Programming Explained,1999]

  17. A simpler view of XP spike solutions(prototypes) CRC cards design planning coding refactoring test unit test acceptance test continuous integration S/W increment

  18. XP principles • 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?

  19. Adaptive S/W development (ASD) • ASD focuses on human collaboration and team self-organization collaboration speculation learning S/W increment [Highsmith 2000]

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

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

  22. 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 Model summary

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

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

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

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

  27. Inspection process Each step is essential: • Overview – educate participants, assign roles • Preparation – participants prepare for roles • Inspection – find defects (do not find solutions) • Rework – author fixes all defects • Follow-Up – verification by moderator or team to ensure that no secondary defects have been introduced (approximately 1 in 6 fixes are wrong)

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

More Related