CSCI 5828: Foundations ofSoftware EngineeringLecture 5 and 6: Modeling the Process and Life CycleSlides created by Pfleeger and Atlee for the SE textbookSome modifications to the original slides have been madeby Ken Anderson for clarity of presentation01/29/2008 — 01/31/2008ISBN 0-13-146913-4Prentice-Hall, 2006Chapter 2Modeling theProcess and LifeCycleCopyright 2006 Pearson/Prentice Hall. All rights reserved.Pfleeger and Atlee, Software Engineering: Theory and Practice Page 2.3© 2006 Pearson/Prentice HallContents2.1 The Meaning of Process2.2 Software Process Models2.3 Tools and Techniques for Process Modeling2.4 Practical Process Modeling2.5 Information System Example2.6 Real Time Example2.7 What this Chapter Means for YouPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.4© 2006 Pearson/Prentice HallChapter 2 Objectives• Discuss the definition of “process” or “life cycle”• Discuss standard terminology:– Software dev. products, processes, and resources• Present several software life cycles• Cover tools and techniques for process modelingPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.5© 2006 Pearson/Prentice Hall2.1 The Meaning of Process• process:– a series of steps involving activities, constrains, andresources that produce an intended ouput of some kind• A process involves a set of tools and techniquesPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.6© 2006 Pearson/Prentice Hall2.1 The Meaning of ProcessProcess Characteristics• Prescribes all major process activities• Uses resources, subject to set of constraints– (such as a schedule or a budget)– Constraints may apply to an activity, resource or product• Produces intermediate and final products• May be composed of subprocesses with hierarchy or links• Each process activity has entry and exit criteria• Activities are organized in sequence, so timing is clear• Each process has guiding principles, including the goalsof each activityPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.7© 2006 Pearson/Prentice Hall2.1 The Meaning of ProcessThe Importance of Processes• Impose consistency and structure on a set ofactivities– especially across projects in a single organization– or two or more projects performed by the same team• Aids engineers in understanding, controlling, andimproving the activities within the process• Allows engineers to capture/measure ourexperiences and use them to improve futureperformancePfleeger and Atlee, Software Engineering: Theory and Practice Page 2.8© 2006 Pearson/Prentice Hall2.2 Software Process ModelsReasons for Modeling a Process• To form a common understanding across differentstakeholders• To find inconsistencies, redundancies, omissions• To find and evaluate appropriate activities forreaching process goals• To tailor a general process for a particularsituation in which it will be usedPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.9© 2006 Pearson/Prentice Hall2.2 Software Process ModelsSoftware Life Cycle• When a process involves building software, theprocess may be referred to as software life cycle– Requirements analysis and definition– System (architecture) design– Program (detailed/procedural) design– Writing programs (coding/implementation)– Testing: unit, integration, system– System delivery (deployment)– MaintenancePfleeger and Atlee, Software Engineering: Theory and Practice Page 2.10© 2006 Pearson/Prentice Hall2.2 Software Process ModelsSoftware Development Process Models• Waterfall model• V model• Prototyping model• Operational specification• Transformational model• Phased development: increments and iterations• Spiral model• Agile methodsPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.11© 2006 Pearson/Prentice Hall2.2 Software Process ModelsWaterfall Model• One of the first process development modelsproposed (circa 1970)• Works for well understood problems with minimalor no changes in the requirements• Simple and easy to explain to customers• It presents– a very high-level view of the development process– a sequence of process activities• Each major phase is marked by milestones anddeliverables (artifacts)Pfleeger and Atlee, Software Engineering: Theory and Practice Page 2.12© 2006 Pearson/Prentice Hall2.2 Software Process ModelsWaterfall Model (continued)Pfleeger and Atlee, Software Engineering: Theory and Practice Page 2.13© 2006 Pearson/Prentice Hall2.2 Software Process ModelsWaterfall Model (continued)• There is no iteration in the original waterfall model• Most software projects apply a great manyiterationsPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.14© 2006 Pearson/Prentice Hall2.2 Software Process ModelsSidebar 2.1 Drawbacks of The Waterfall Model• Provides no guidance on how to handle changesto products and activities during development(assumes requirements can be frozen)• Views software development as a manufacturingprocess rather than as a creative process• There is no iterative activities that lead to creatinga final product• From customer perspective, there can be a longwait before a final product is deliveredPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.15© 2006 Pearson/Prentice Hall2.2 Software Process ModelsWaterfall Model with Prototype• A prototype is a partially developed product• Prototyping helps– developers assess alternative design strategies (designprototype)– users understand what the system will be like (userinterface prototype)• Protopyping is useful for verification and validation– validation: have all requirements been implemented?– verification: have all requirements been implementedcorrectly and with high quality?Pfleeger and Atlee, Software Engineering: Theory and Practice Page 2.16© 2006 Pearson/Prentice Hall2.2 Software Process ModelsWaterfall Model with Prototype (continued)• Waterfall model with prototypingPfleeger and Atlee, Software Engineering: Theory and Practice Page 2.17© 2006 Pearson/Prentice Hall2.2 Software Process ModelsV Model• A (slight) variation of the waterfall model• Uses unit testing to verify program design• Uses integration testing to verify architectural design• Uses acceptance testing to validate the requirements• If problems are found during verification and validation,the “left side” of
View Full Document