08. Topic No 04 Object-Oriented Lifecycle Models.pptx

Slides are here

1. Object-Oriented Lifecycle Models

2. Object-Oriented Lifecycle Models Object-oriented lifecycle models appreciate the need for iteration within and between phases. There are a number of these models. All of these models incorporate some form of iteration, parallelism, and incremental development.

3. eXtreme Programming Model It is a somewhat controversial new approach. In this approach user requirements are captured through stories which are the scenarios presenting the features needed by the client? Estimate for duration and cost of each story is then carried out. Stories for the next build are selected.

4. eXtreme Programming Model Then each build is divided into tasks. Test cases for task are drawn up first before and development and continuous testing is performed throughout the development process.

5. eXtreme Programming Model Diagram

6. eXtreme Programming Diagram Explanation One very important feature of eXtreme programming is the concept of pair programming. In this, a team of two developers develop the software, working in team as a pair to the extent that they even share a single computer. In eXtereme Programming model, computers are put in center of large room lined with cubicles and client representative is always present.

7. eXtreme Programming Model Diagram Explanation One very important restriction imposed in the model is that no team is allowed to work overtime for 2 successive weeks. XP has had some successes. It is good when requirements are vague or changing and the overall scope of the project is limited. It is however too soon to evaluate XP.

8. Fountain Model Fountain model is another object-oriented lifecycle model . In this model the circles representing the various phases overlap, explicitly representing an overlap between activities.

9. Fountain Model The arrows within a phase represent iteration within the phase. The maintenance cycle is smaller, to symbolize reduced maintenance effort when the object oriented paradigm is used.

10. Fountain Model Diagram

11. Rational Unified Process Model (RUP ) Rational Unified Process is very closely associated with UML and Krutchen’s architectural model. In this model a software product is designed and built in a succession of incremental iterations. It incorporates early testing and validation of design ideas and early risk mitigation.

12. Rational Unified Process Model (RUP ) The horizontal dimension represents the dynamic aspect of the process. This includes cycles, phases, iterations, and milestones. The vertical dimension represents the static aspect of the process described in terms of process components which include activities, disciplines, artifacts, and roles. The process emphasizes that during development, all activities are performed in parallel, however, and at a given time one activity may have more emphasis than the other.

13. Figure depicting RUP is taken from Krutchen’s paper

14. Comparison of Lifecycle Models

15. Comparison of Lifecycle Models The criteria to be used for deciding on a model include the organization, its management, skills of the employees, and the nature of the product. No single model may fulfill the needs in a given situation. It may therefore be best to devise a lifecycle model tuned to your own needs by creating a “Mix-and-match” life-cycle model.

16. Quality Assurance and Documentation It may be noted that there is no separate QA or documentation phase. QA is an activity performed throughout software production. It involves verification and validation. Verification is performed at the end of each phase Whereas validation is performed before delivering the product to the client.

17. Quality Assurance and Documentation Similarly, every phase must be fully documented before starting the next phase. It is important to note that postponed documentation may never be completed as the responsible individual may leave.

18. Quality Assurance and Documentation Documentation is important as the product is constantly changing—we need the documentation to do this. The design (for example) will be modified during development, but the original designers may not be available to document it.

19. Table shows the QA and documentation activities associated with each stage