Alternative Software Life Cycle Models

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
• 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 users
  needs and expectations

4
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

5
Alternative Models

• Rapid, Throwaway Prototype
• Gomaa and Scott made it popular in 1981
• Focuses on ensuring product meets users 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

6
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

7
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

8
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

9
Alternative Models

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

10
Evaluation of Alternative Life Cycle Models

• Users 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

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

13
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

14
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

15
Evaluation of Alternative Life Cycle Models

• Reusable Software
• Potential to significantly decrease initial
  development time
• Only development time is different here

16
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
  re-synthesizing the entire system
• 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
• 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

18
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