Software engg. pressman_ch-3


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Moving up the abstraction tree
    What are we building rather then how
    Separation of concerns
  • Software engg. pressman_ch-3

    1. 1. 1
    2. 2. Software life cycle model  software life cycle series of identifiable stages that a software product undergoes during its lifetime software life cycle model It is a descriptive and diagrammatic representation of software life cycle 2
    3. 3. Why Software life cycle model? It encourages development of s/w in a systematic and discipline way It is necessary to have precise understanding among team members otherwise it will lead to chaos and project failure 3
    4. 4. PHASE ENTRY AND EXIT CRITERIA  Every software life cycle model normally define entry and exit criteria every phase  A phase can begin only when corresponding phase entry are satisfied 4
    5. 5. 99% complete syndrome  When there is no clear specification of the entry and exit criteria for every phase and if no life cycle model is followed  It becomes very difficult to chart the progress of the project 5
    6. 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. 7. 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. 8. Models are needed Symptoms of inadequacy: the 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. 9. The Waterfall Model 9
    10. 10. Waterfall Model Assumptions 1. The requirements are knowable in advance of 2. 3. 4. 5. implementation. The nature of the requirements will not change very much  During development; during evolution The requirements are compatible with all the key system stakeholders’ expectations  e.g., users, customer, developers, maintainers, investors The right architecture for implementing the requirements is well understood. There is enough calendar time to proceed sequentially. 10
    11. 11. Process for Offshore? Analysis Design Construct System test Accept. test Deploy 11
    12. 12. 12
    13. 13. Disadvantages of waterfall model  Real projects rarely follow sequential flow  Difficult for the customer to state all requirements  Customer to show patience. Working version of program will not be available until late in the project 13
    14. 14. Evolutionary Models: Prototyping 14
    15. 15. Prototyping model This begins with requirement gathering . Developer and customer meet and define overall objectives for the s/w Then quick design occurs which focus on representation of those aspects of the s/w that are visible to customer After the quick design prototype is build and then evaluated and feedback given 15
    16. 16. 16
    17. 17. Evolutionary process models All the linear sequential models are design for straight line development In waterfall model complete system will be delivered after linear sequence is completed The prototyping is designed to assist the customer in understanding requirements 17
    18. 18. Incremental Models: Incremental 18
    19. 19. Incremental model The incremental model combines elements of linear sequential model with iterative nature of prototyping For example: word processing s/w First increment product is core product which is used by customer in which modifications he can add The process is repeated until the complete product is produced 19
    20. 20. Usefulness of the model  When staffing unavailable for whole complete implementation by business deadline  Increments can be planned to manage technical risks  Best when: you encounter a difficult deadline that cant be changed 20
    21. 21. If we rely on testing alone, defects created first are detected last User Need system test plan System System Requirements Testing software test plan Software Software Requirements Testing integration plan Software Integration Design Testing unit plan Software Unit Implementation Testing time Product Release 21
    22. 22. Incremental Models: RAD Model 22
    23. 23. Risk Exposur e 23
    24. 24. Unified A software process that is: Process use-case driven Model architecture-centric    iterative and incremental Closely aligned with the Unified Modeling Language (UML) 24
    25. 25. The Unified Process (UP) inception 25
    26. 26. UP Work Products inception 26
    27. 27. Lifecycle for Enterprise Unified Process inception 27
    28. 28. 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 28
    29. 29. 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 29
    30. 30. Evolutionary Models: The Spiral 30
    31. 31. 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 31
    32. 32. Simplified Spiral Model If risks cannot be resolved, project is immediately terminated 32
    33. 33. Full Spiral Model Radial dimension: cumulative cost to date Angular dimension: progress through the spiral 33
    34. 34. Full Spiral Model (contd) 34
    35. 35. 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 35
    36. 36. Object-Oriented Life-Cycle Models Need for iteration within and between phases  Fountain model  Recursive/parallel life cycle  Round-trip gestalt  Unified software development process All incorporate some form of  Iteration  Parallelism  Incremental development Danger  CABTAB 36
    37. 37. Fountain Model Features Overlap (parallelism) Arrows (iteration) Smaller maintenance circle 37
    38. 38. Software Process Spectrum Crystal Clear XP DSDM SCRUM dX lightweight ICONIX FDD middleweight Crystal Violet OPEN EUP RUP heavyweight 38
    39. 39. 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 39
    40. 40. 40
    41. 41. What is MDA in essence? Automated approach to translate high level design to low level implementation by means of separation of concerns From high-level model to running application Risk proportional to expectations! 41
    42. 42. Finding the “right” language Developer IDEs & 4GL 3GL Automation Abstraction Model Driven Architecture Assembler Computer Hardware 42
    43. 43. Martin Fowler 43
    44. 44. Model Driven Architecture Can you actually have incremental MDA? Or is it automated waterfall? Need rigorous models Need high quality requirements Capture requirements Understand requirements 44
    45. 45. MDA or Offshore? Automation versus reduce cost of labor Objectives Reduce required intelligence Increase repetition Goal Reduce costs of development 45