Slides chapter 3

409 views
377 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
409
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Moving up the abstraction tree What are we building rather then how Separation of concerns What-from-how
  • Slides chapter 3

    1. 1. Chapter 3 Prescriptive Process Models Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
    2. 2. Software process model <ul><li>Attempt to organize the software life cycle by </li></ul><ul><ul><ul><li>defining activities involved in software production </li></ul></ul></ul><ul><ul><ul><li>order of activities and their relationships </li></ul></ul></ul><ul><li>G oals of a software process </li></ul><ul><ul><li>standardization, predictability, productivity, high product quality, ability to plan time and budget requirements </li></ul></ul>
    3. 3. Code&Fix <ul><li>The earliest approach </li></ul><ul><li>Write code </li></ul><ul><li>Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features </li></ul><ul><li>Source of difficulties and deficiencies </li></ul><ul><ul><li>impossible to predict </li></ul></ul><ul><ul><li>impossible to manage </li></ul></ul>
    4. 4. Models are needed <ul><li>Symptoms of inadequacy: the software crisis </li></ul><ul><ul><li>scheduled time and cost exceeded </li></ul></ul><ul><ul><li>user expectations not met </li></ul></ul><ul><ul><li>poor quality </li></ul></ul><ul><li>The size and economic value of software applications required appropriate &quot;process models&quot; </li></ul>
    5. 5. Process model goals (B. Boehm 1988) &quot;determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?&quot;
    6. 6. Process as a &quot;black box&quot; Quality? Uncertain / Incomplete requirement In the beginning
    7. 7. Problems <ul><li>The assumption is that requirements can be fully understood prior to development </li></ul><ul><li>Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) </li></ul><ul><li>Unfortunately the assumption almost never holds </li></ul>
    8. 8. Process as a &quot;white box&quot;
    9. 9. Advantages <ul><li>Reduce risks by improving visibility </li></ul><ul><li>Allow project changes as the project progresses </li></ul><ul><ul><li>based on feedback from the customer </li></ul></ul>
    10. 10. The main activities of software production <ul><li>They must be performed independently of the model </li></ul><ul><li>The model simply affects the flow among activities </li></ul>
    11. 11. Prescriptive Models <ul><li>That leads to a few questions … </li></ul><ul><li>If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? </li></ul><ul><li>Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? </li></ul>Prescriptive process models advocate an orderly approach to software engineering
    12. 12. The Waterfall Model
    13. 13. Waterfall Model Assumptions <ul><li>1. The requirements are knowable in advance of implementation. </li></ul><ul><li>2. The requirements have no unresolved, high-risk implications </li></ul><ul><ul><li>e.g., risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, organizational impacts </li></ul></ul><ul><li>3. The nature of the requirements will not change very much </li></ul><ul><ul><li>During development; during evolution </li></ul></ul><ul><li>4. The requirements are compatible with all the key system stakeholders’ expectations </li></ul><ul><ul><li>e.g., users, customer, developers, maintainers, investors </li></ul></ul><ul><li>5. The right architecture for implementing the requirements is well understood. </li></ul><ul><li>6. There is enough calendar time to proceed sequentially. </li></ul>
    14. 14. Process for Offshore? Deploy Accept. test Analysis Design Construct System test
    15. 15. The V Model <ul><li>If we rely on testing alone, defects created first are detected last </li></ul>System Requirements Software Requirements Software Design Software Implementation Unit Testing Integration Testing Software Testing System Testing system test plan software test plan integration plan unit plan Product Release time User Need
    16. 16. Incremental Models: Incremental
    17. 17. Incremental Models: RAD Model
    18. 18. Evolutionary Models: Prototyping
    19. 19. Risk Exposure
    20. 20. Unified Process Model <ul><li>A software process that is: </li></ul><ul><ul><li>use-case driven </li></ul></ul><ul><ul><li>architecture-centric </li></ul></ul><ul><ul><li>iterative and incremental </li></ul></ul><ul><li>Closely aligned with the </li></ul><ul><li>Unified Modeling Language (UML) </li></ul>
    21. 21. The Unified Process (UP) inception
    22. 22. UP Work Products inception
    23. 23. Lifecycle for Enterprise Unified Process inception
    24. 24. Synchronize-and Stabilize Model <ul><li>Microsoft’s life-cycle model </li></ul><ul><li>Requirements analysis—interview potential customers </li></ul><ul><li>Draw up specifications </li></ul><ul><li>Divide project into 3 or 4 builds </li></ul><ul><li>Each build is carried out by small teams working in parallel </li></ul>
    25. 25. Synchronize-and Stabilize Model (contd) <ul><li>At the end of the day—synchronize (test and debug) </li></ul><ul><li>At the end of the build—stabilize (freeze build) </li></ul><ul><li>Components always work together </li></ul><ul><ul><li>Get early insights into operation of product </li></ul></ul>
    26. 26. Evolutionary Models: The Spiral
    27. 27. Spiral Mode l <ul><li>Simplified form </li></ul><ul><ul><li>Waterfall model plus risk analysis </li></ul></ul><ul><li>Precede each phase by </li></ul><ul><ul><li>Alternatives </li></ul></ul><ul><ul><li>Risk analysis </li></ul></ul><ul><li>Follow each phase by </li></ul><ul><ul><li>Evaluation </li></ul></ul><ul><ul><li>Planning of next phase </li></ul></ul>
    28. 28. Simplified Spiral Model <ul><li>If risks cannot be resolved, project is immediately terminated </li></ul>
    29. 29. Full Spiral Model <ul><li>Radial dimension: cumulative cost to date </li></ul><ul><li>Angular dimension: progress through the spiral </li></ul>
    30. 30. Full Spiral Model (contd)
    31. 31. Analysis of Spiral Model <ul><li>Strengths </li></ul><ul><ul><li>Easy to judge how much to test </li></ul></ul><ul><ul><li>No distinction between development, maintenance </li></ul></ul><ul><li>Weaknesses </li></ul><ul><ul><li>For large-scale software only </li></ul></ul><ul><ul><li>For internal (in-house) software only </li></ul></ul>
    32. 32. Object-Oriented Life-Cycle Models <ul><li>Need for iteration within and between phases </li></ul><ul><ul><li>Fountain model </li></ul></ul><ul><ul><li>Recursive/parallel life cycle </li></ul></ul><ul><ul><li>Round-trip gestalt </li></ul></ul><ul><ul><li>Unified software development process </li></ul></ul><ul><li>All incorporate some form of </li></ul><ul><ul><li>Iteration </li></ul></ul><ul><ul><li>Parallelism </li></ul></ul><ul><ul><li>Incremental development </li></ul></ul><ul><li>Danger </li></ul><ul><ul><li>CABTAB </li></ul></ul>
    33. 33. Fountain Model <ul><li>Features </li></ul><ul><li>Overlap (parallelism) </li></ul><ul><li>Arrows (iteration) </li></ul><ul><li>Smaller maintenance circle </li></ul>
    34. 34. Software Process Spectrum XP SCRUM DSDM FDD RUP dX ICONIX Crystal Clear Crystal Violet EUP OPEN lightweight heavyweight middleweight
    35. 35. Conclusions <ul><li>Different life-cycle models </li></ul><ul><li>Each with own strengths </li></ul><ul><li>Each with own weaknesses </li></ul><ul><li>Criteria for deciding on a model include </li></ul><ul><ul><li>The organization </li></ul></ul><ul><ul><li>Its management </li></ul></ul><ul><ul><li>Skills of the employees </li></ul></ul><ul><ul><li>The nature of the product </li></ul></ul><ul><li>Best suggestion </li></ul><ul><ul><li>“ Mix-and-match” life-cycle model </li></ul></ul>
    36. 36. Model Driven Architecture
    37. 37. What is MDA in essence? <ul><li>Automated approach to translate high level design to low level implementation by means of separation of concerns </li></ul><ul><li>From high-level model to running application </li></ul><ul><li>Risk proportional to expectations! </li></ul>
    38. 38. Finding the “right” language Assembler 3GL IDEs & 4GL Model Driven Architecture Computer Hardware Developer Automation Abstraction
    39. 39. “ You should use iterative development only on projects you want to succeed” Martin Fowler
    40. 40. Model Driven Architecture <ul><li>Can you actually have incremental MDA? </li></ul><ul><ul><li>Or is it automated waterfall? </li></ul></ul><ul><li>Need rigorous models </li></ul><ul><li>Need high quality requirements </li></ul><ul><ul><li>Capture requirements </li></ul></ul><ul><ul><li>Understand requirements </li></ul></ul>
    41. 41. MDA or Offshore? <ul><li>Automation versus reduce cost of labor </li></ul><ul><li>Objectives </li></ul><ul><ul><li>Reduce required intelligence </li></ul></ul><ul><ul><li>Increase repetition </li></ul></ul><ul><li>Goal </li></ul><ul><ul><li>Reduce costs of development </li></ul></ul>

    ×