Alternative Software Life Cycle Models By Edward R. Corner vol. 2,

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

Feel free to interrupt!

Introduction 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 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

Definition Not a definition of process followed by a software development organization Not a methodology 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 description of major functions involved in software development insight towards the important aspects or features necessary for common understanding and focus

Alternative Models Rapid, Throwaway Prototype: Gomaa and Scott made it popular in 1981 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 Use of this implementation by the users can expose miscommunications in the requirement specifications

Alternative Models Incremental Development: 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 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

Alternative Models Evolutionary Prototypes: Views the software life cycle as a set of prototypes that are evolved through iterative experimentation and refinement Intended to addresses customer satisfaction 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 Expensive to use for complex mission-critical applications

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

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

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

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

Evaluation of Alternative Life Cycle Models Rapid Prototyping: 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 Shows overall, that function is closer to needs than the waterfall model

Evaluation of Alternative Life Cycle Models Incremental Development: 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 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

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

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

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

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 Points that should affect selection: Requirements volatility (likelihood that requirements will change The way that requirements change (big jumps, gradually) 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

Conclusion 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