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 welldefined, 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 re-synthesizing
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