1. Alternative Software Life Cycle Models By Edward R. Corner vol. 2, chapter 8, pp. 289-299 Presented by: Gleyner Garden EEL6883 Software Engineering II

2. Feel free to interrupt!

3. Introduction The classic waterfall model that we are familiar with was developed around 1970 by Dr. Winston Royce The classic waterfall model that we are familiar with was developed around 1970 by Dr. Winston Royce Many different models have been proposed since then Many different models have been proposed since then They all exist to help cope with the great complexity and expense of software products, and to help create a product that meets the user’s needs and expectations They all exist to help cope with the great complexity and expense of software products, and to help create a product that meets the user’s needs and expectations

4. Definition Not a definition of process followed by a software development organization Not a definition of process followed by a software development organization Not a methodology Not a methodology Is a reference model for a software development process that provides: Is a reference model for a software development process that provides: a common basis for standards, and where these standards belong with respect to the model a common basis for standards, and where these standards belong with respect to the model a description of major functions involved in software development a description of major functions involved in software development insight towards the important aspects or features necessary for common understanding and focus insight towards the important aspects or features necessary for common understanding and focus

5. Alternative Models Rapid, Throwaway Prototype: Rapid, Throwaway Prototype: Gomaa and Scott made it popular in 1981 Gomaa and Scott made it popular in 1981 Focuses on ensuring product meets user’s needs Focuses on ensuring product meets user’s needs Goal is to improve the quality of requirements specifications by providing a “quick and dirty” partial implementation during requirements phase Goal is to improve the quality of requirements specifications by providing a “quick and dirty” partial implementation during requirements phase Use of this implementation by the users can expose miscommunications in the requirement specifications Use of this implementation by the users can expose miscommunications in the requirement specifications

6. Alternative Models Incremental Development: Incremental Development: Constructing a partially implemented, yet useful build and then incrementally added functionality Constructing a partially implemented, yet useful build and then incrementally added functionality Requirements can be defined for each increment in advance, or during development between increments Requirements can be defined for each increment in advance, or during development between increments If done correctly, can increase reliability and decrease risk If done correctly, can increase reliability and decrease risk Requires a very flexible system architecture, and especially if the overall end-result is not fully planning for Requires a very flexible system architecture, and especially if the overall end-result is not fully planning for

7. Alternative Models Evolutionary Prototypes: Evolutionary Prototypes: Views the software life cycle as a set of prototypes that are evolved through iterative experimentation and refinement Views the software life cycle as a set of prototypes that are evolved through iterative experimentation and refinement Intended to addresses customer satisfaction Intended to addresses customer satisfaction Sort of a mixture of Rapid Prototyping and Incremental Development, without the need for a full understanding of requirements Sort of a mixture of Rapid Prototyping and Incremental Development, without the need for a full understanding of requirements Hard to scale up to large systems Hard to scale up to large systems Expensive to use for complex mission-critical applications Expensive to use for complex mission-critical applications

8. Alternative Models Reusable Software: Reusable Software: Reduce costs by incorporating existing designs, programs, modules, and data into new software products Reduce costs by incorporating existing designs, programs, modules, and data into new software products Compatible with all life cycle models Compatible with all life cycle models Avoid reinventing the wheel Avoid reinventing the wheel Less schedule needed, since code is already written, and less bugs to fix, since software has been “proven” Less schedule needed, since code is already written, and less bugs to fix, since software has been “proven”

9. Alternative Models Automated Software Synthesis: Automated Software Synthesis: Automated transformation of formal requirements into operational code Automated transformation of formal requirements into operational code Relies heavily on automated tools (very smart compilers) Relies heavily on automated tools (very smart compilers)

10. Evaluation of Alternative Life Cycle Models User’s needs are constantly evolving User’s needs are constantly evolving Creates new requirements which must be met to meet expectations Creates new requirements which must be met to meet expectations Project gets behind schedule Project gets behind schedule Waterfall example shows how development is affected Waterfall example shows how development is affected

11. Evaluation of Alternative Life Cycle Models Shortfall is a measure of how far the system at a given time t, is from meeting the actual requirements at time t Lateness is a measure of the time that elapses between the appearance of a new requirement and its satisfaction Adaptability is the rate at which the software solution can adapt to new requirements Longevity is the time a system solution is adaptable to change and remains viable Inappropriateness captures the behavior of the shortfall over time (area between needs and actual capabilities

12. Evaluation of Alternative Life Cycle Models Rapid Prototyping: Rapid Prototyping: Increases likelihood that customers and developers are on the same page at time t0 Increases likelihood that customers and developers are on the same page at time t0 At t1 the delivered function is higher for the rapid prototyping approach At t1 the delivered function is higher for the rapid prototyping approach Shows overall, that function is closer to needs than the waterfall model Shows overall, that function is closer to needs than the waterfall model

13. Evaluation of Alternative Life Cycle Models Incremental Development: Incremental Development: Deliberately built to satisfy fewer requirements initially, but facilitates incorporation of new requirements which increases adaptability Deliberately built to satisfy fewer requirements initially, but facilitates incorporation of new requirements which increases adaptability Initial development time is reduced because of limited functionality Initial development time is reduced because of limited functionality Software can be enhanced more easily for a longer period of time Software can be enhanced more easily for a longer period of time Stair steps show series of well- defined, planned, discrete builds of the system Stair steps show series of well- defined, planned, discrete builds of the system

14. Evaluation of Alternative Life Cycle Models Evolutionary Prototypes: Evolutionary Prototypes: Number and frequency of operational prototypes is increased Number and frequency of operational prototypes is increased Initial prototype emerges rapidly to provide a framework for the software Initial prototype emerges rapidly to provide a framework for the software Each prototype explores a new area of user need, while refining previous function Each prototype explores a new area of user need, while refining previous function More adaptable More adaptable Not stepped because we are introducing new functionality with more refined old functionality Not stepped because we are introducing new functionality with more refined old functionality

15. Evaluation of Alternative Life Cycle Models Reusable Software: Reusable Software: Potential to significantly decrease initial development time Potential to significantly decrease initial development time Only development time is different here Only development time is different here

16. Evaluation of Alternative Life Cycle Models Automated Software Synthesis: Automated Software Synthesis: Development time is greatly reduced Development time is greatly reduced Development costs are reduced so much that adapting old systems is not as good as re-synthesizing the entire system Development costs are reduced so much that adapting old systems is not as good as re-synthesizing the entire system Low longevity, but very low shortfall Low longevity, but very low shortfall

17. Defining, Selecting, or Adapting a Life Cycle Model Life cycle model evaluation provides insight as to how we might define, select, or adapt a life cycle model to improve our process Life cycle model evaluation provides insight as to how we might define, select, or adapt a life cycle model to improve our process Points that should affect selection: Points that should affect selection: Requirements volatility (likelihood that requirements will change Requirements volatility (likelihood that requirements will change The way that requirements change (big jumps, gradually) The way that requirements change (big jumps, gradually) The longevity of the application The longevity of the application The availability of resources to develop or effect changes; it may be easier to get resources up front than to devote significant resources for enhancements The availability of resources to develop or effect changes; it may be easier to get resources up front than to devote significant resources for enhancements

18. Conclusion It was a very good paper that describes and evaluates several different life cycle approaches It was a very good paper that describes and evaluates several different life cycle approaches I would have liked to know if he used any real data to get a general idea as to what the different evaluation plots looked like I would have liked to know if he used any real data to get a general idea as to what the different evaluation plots looked like