1 / 25

SOFTWARE LIFE-CYCLES

SOFTWARE LIFE-CYCLES. Beyond the Waterfall. Milestones. The WATERFALL LIFE-CYCLE. Requirements. System Design. Standards. Detailed Design. Implementation. Installation & Testing. Documents. Maintenance. Problems with the Waterfall Model. sequentiality late testing paradigm

walkerv
Download Presentation

SOFTWARE LIFE-CYCLES

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. SOFTWARE LIFE-CYCLES Beyond the Waterfall

  2. Milestones The WATERFALL LIFE-CYCLE Requirements System Design Standards Detailed Design Implementation Installation & Testing Documents Maintenance

  3. Problems with the Waterfall Model • sequentiality • late testing paradigm • late feedback to customer and engineer • minimal risk management for customer and engineer

  4. The “V” LIFE-CYCLE Requirements Acceptance Test System Design Integration Test Detailed Design Module Test Implementation

  5. Analysis of the V-Shaped Life-Cycle • Improves the testing paradigm ==> Quality Assurance • Does NOT really improve: • sequentiality • feedback • risk management (during development)

  6. INCREMENTAL DEVELOPMENT Requirements Global System Design Detailed D. Detailed D. Detailed D. Implem. Implem. Implem. Testing Testing Testing Maintenance

  7. Analysis of Incremental Development • Assumes independent subsystems! • Improves (by delivering smaller units): • feedback: stepwise • testing • Avoids monolithic product • Does not really improve: • risk management during development • sequentiality: subsystems

  8. (Rapid) Prototyping • Goals: • break away from sequentiality • speed up feedback • minimize risks for customer and engineer • incomplete but executable • cheap and fast

  9. Prototyping • Definition (A. Davis): A prototype is a partial implementation of a system, constructed primarily to enable customer, user, or developer to learn about the problem or its solution. • Types: • evolutionary / throw-away • horizontal / vertical

  10. Horizontal Prototyping f1 fn user hardware

  11. Vertical Prototyping f1 fn user hardware

  12. Analysis of Pure Prototyping • Improvements: • breaks sequentiality • supports fast feedback • opportunity for risk management • Problems: • missing organisational structure ==> combine with a life-cycle

  13. The Spiral Model • Goals: • risk management • compatible mix between clear structure (life-cycle) & flexible prototyping • supports fast feedback & quality assurance

  14. evaluate alternatives, identify & resolve risks determine objectives, alternatives, constraints risk analysis p r o t o t y p e s principles req. plan require- system ments dev. detailed design design plan integ. plan implement plan the next phase test & install develop & verify product

  15. The Rational Unified Process (RUP) A modern generic process derived from the work on the UML and associated process. Brings together aspects of the 3 generic process models discussed previously. Normally described from 3 perspectives - A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. Credit: Sommerville 9th edition: Chapter 2 Software Processes 17

  16. Phases in the Rational Unified Process Credit: Sommerville 9th edition, Chapter 2 Software Processes 18

  17. RUP phases Inception - Establish the business case for the system. Elaboration - Develop an understanding of the problem domain and the system architecture. Construction - System design, programming and testing. Transition - Deploy the system in its operating environment. Credit: sommerville, 9th edition, Chapter 2 Software Processes 19

  18. RUP iterations • In-phase iteration - Each phase is iterative with results developed incrementally. • Cross-phase iteration - As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. Credit: Sommerville, 9th edition, Chapter 2 Software Processes 20

  19. Static workflows in the Rational Unified Process Credit: Sommerville, 9th edition, Chapter 2 Software Processes 21

  20. Static workflows in the Rational Unified Process Credit: Sommerville, 9th edition, Chapter 2 Software Processes 22

  21. RUP overview Credit: Ph, Krutchen,, RUP, Crosstalk, 9 (7) July 1996, pp.11-16.

  22. RUP good practices Develop software iteratively - Plan increments based on customer priorities and deliver highest priority increments first. Manage requirements - Explicitly document customer requirements and keep track of changes to these requirements. Use component-based architectures - Organize the system architecture as a set of reusable components. Credit: Sommerville, 9th edition, Chapter 2 Software Processes 24

  23. RUP good practices • Visually model software - Use graphical UML models to present static and dynamic views of the software. • Verify software quality - Ensure that the software meet’s organizational quality standards. • Control changes to software - Manage software changes using a change management system and configuration management tools. Credit: Sommerville, 9th edition, Chapter 2 Software Processes 25

  24. Key points Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole. The Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction and transition) but separates activities (requirements, analysis and design, etc.) from these phases. Credit: Sommerville, 9th edition, Chapter 2 Software Processes 26

  25. End of Section 1c coming up: methodologies for analysis & design

More Related