1 / 46

Chapter 3 Process Models

Chapter 3 Process Models. Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman. Outline. Introduction The Waterfall Model Incremental Process Models Evolutionary Process Models Specialized Process Models The Unified Process. Introduction.

rosiem
Download Presentation

Chapter 3 Process Models

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. Chapter 3Process Models Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman

  2. Outline • Introduction • The Waterfall Model • Incremental Process Models • Evolutionary Process Models • Specialized Process Models • The Unified Process

  3. Introduction What is process model?

  4. 解决问题的基本过程 • 看清事实，弄清楚真正的问题在哪里？ • 分析事实，清楚地找出造成问题的基本原因是什么？ • 给出解决方案，这些问题可能有哪些解决办法？ • 作出决定，建议用哪种解决方案？ • 立即行动，实施方案。 • 《人性的优点》（美）卡耐基

  5. 软件是如何开发出了的？ • 技术活动：沟通、计划、建模、构建、部署； • 管理活动：项目跟踪和控制、风险管理、软件质量保证、正式的技术评审、度量、软件配置管理、可重用性管理、工作产品的准备和生产； • 软件开发过程：需求分析；软件设计；软件实现；软件测试；软件运行和维护； 过程比结果重要，没有过程，就没有结果！

  6. Software process model • Attempt to organize the software life cycle by • defining activities involved in software production • order of activities and their relationships • Goals of a software process • Standardization • Predictability • Productivity • high product quality • ability to plan time and budget requirements

  7. How to develop software? Code & Fix The earliest approach • Write code • Fix it to • eliminate any errors that have been detected, • to enhance existing functionality, or • to add new features • Source of difficulties and deficiencies • impossible to predict • impossible to manage

  8. Models are needed • Software crisis • scheduled time and cost exceeded • user expectations not met • poor quality • The size and economic value of software applications required appropriate "process models"

  9. What is Process model? • Determine the order of stages involved in software development and evolution; • Establish the transition criteria for progressing from one stage to the next; • Addresses the following software project questions: • What shall we do next? • How long shall we continue to do it?" (B. Boehm 1988)

  10. Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

  11. Problems • The assumption is that requirements can be fully understood prior to development • Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds!

  12. Process as a "white box"

  13. Advantages • Reduce risks by improving visibility • Allow project changes as the project progresses • The changes based on feedback from the customer

  14. The main activities of software production • They must be performed of the model independently • The model simply affects the flow among activities

  15. The Waterfall Model Classic Life Cycle Model

  16. The Waterfall Model

  17. Assumptions 1. The requirements are knowable in advance of implementation. 2. The requirements have no unresolved, high-risk implications • e.g., risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, organizational impacts 3. The nature of the requirements will not change very much • During development; during evolution 4. The requirements are compatible with all the key system stakeholders’ expectations • e.g., users, customer, developers, maintainers, investors 5. The right architecture for implementing the requirements is well understood. 6. There is enough calendar time to proceed sequentially.

  18. Why does it fail sometimes? • Real projects rarely follow the sequential flow that the model proposes; • It is often difficult for the customer to state all requirements explicitly; • The customer must have patience.

  19. Analysis Design Construct System test Process for Offshore? Accept. test Deploy

  20. If we rely on testing alone, defects created first are detected last User Need Product Release system test plan System Requirements System Testing software test plan Software Requirements Software Testing integration plan Software Design Integration Testing unit plan Software Implementation Unit Testing time The V Model

  21. Incremental Process Models

  22. Incremental model

  23. RAD Model

  24. Evolutionary Process Models

  25. Prototyping

  26. Risk Exposure

  27. The Spiral Model(Risk-driven process model)

  28. Distinguishing Features • A cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk; • A set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

  29. Spiral Model • Simplified form • Waterfall model plus risk analysis • Precede each phase by • Alternatives • Risk analysis • Follow each phase by • Evaluation • Planning of next phase

  30. Simplified Spiral Model • If risks cannot be resolved, project is immediately terminated

  31. Full Spiral Model (contd)

  32. Analysis of Spiral Model • Strengths • Easy to judge how much to test • No distinction between development, maintenance • Weaknesses • For large-scale software only • For internal (in-house) software only

  33. The Concurrent（协同） Process Model

  34. Concerns（担忧） of Evolutionary Software Process • Prototyping poses a problem to project planning because of the uncertain number of cycles required to construct the product; • Evolutionary software processes do not establish the maximum speed of the evolution; • Software processes should be focused on flexibility and extensibility rather than on high quality;

  35. Specialized Process Models

  36. Component-Based Development • The Component-Based Development Software Reuse（软件重用）!

  37. Formal Methods Model（形式化方法） • Emphasizes the mathematical specification of requirements • Rigorous mathematical notation used to specify, design, and verify computer-based systems

  38. Why are they not widely used? • The development of formal models is time-consuming and expensive; • Extensive developers training is required; • It is difficult to use the models as a communication mechanism for customers;

  39. Unified Process Model

  40. Unified Process Model A software process that is: • use-case driven • architecture-centric • iterative and incremental Closely aligned with the Unified Modeling Language (UML)

  41. The Unified Process (UP) inception

  42. UP Work Products inception

  43. Lifecycle for Enterprise Unified Process inception

  44. Synchronize-and Stabilize Model • Microsoft’s life-cycle model • Requirements analysis—interview potential customers • Draw up specifications • Divide project into 3 or 4 builds • Each build is carried out by small teams working in parallel

  45. Synchronize-and Stabilize Model (contd) • At the end of the day—synchronize (test and debug) • At the end of the build—stabilize (freeze build) • Components always work together • Get early insights into operation of product

  46. Conclusions • Different life-cycle models • Each with own strengths • Each with own weaknesses • Criteria for deciding on a model include • The organization • Its management • Skills of the employees • The nature of the product • Best suggestion • “Mix-and-match” life-cycle model

More Related