CS 458 - Week 3 Lecture 1 - 2016-09-06
* prototyping -
* one or more prototypes,
"quick n sleazy", NOT a final deliverable,
don't have to be completely operational,
may be a "facade" or even a "paper" prototype;
the user/client(s) try these out to help
to improve the quality of the requirements
(especially when they might be hard to
get "firm" enough otherwise)
* once all agree the requirements are clear
enough, proceed in a waterfall-like fashion
from that point
* potential advantages:
* better, more stable requirements might result
* experience of developing even these
quick'n'sleazy prototypes
can reduce the cost of the development
of the eventual deliverable version
* ...and might improve its quality as well
* reduces risk that final project won't
actually meet the client's needs
* potential disadvantages:
* there is a cost for these prototypes
(but hopefully you try to minimize this);
* you do have to have a cooperative client;
* still has some of the remaining issues
that Waterfall has -- still an all-or-nothing
single product delivery at the end
* iterative development -
TWO variations on this model are discussed
in Jalote Ch. 2:
* iterative enhancement
* iterative delivery
* in BOTH of these, software is developed
AND DELIVERED in *increments* --
each delivery is a working system
the client can use,
BUT each delivery adds some
functional capability
* see how this addresses the "all or
nothing" issue of Waterfall and
Prototyping?
* and it can also address the
requirements bloating potential
tendency of
Waterfall
* what, then, is the difference between
iterative enhancement
and
iterative delivery?
* iterative ENHANCEMENT
* 1st step: creating a simple initial
implementation for a SUBSET of the
overall problem;
this IS a deliverable, though
(unlike a prototype)
* subset needs to contain some
key aspects of the problem
that are easy to understand
and implement, and which form
a USEFUL and USABLE system
NOT a thowaway, though, note!
* create a PROJECT CONTROL LIST
that contains, in (currently-understood)
order, the tasks still needed to
be done for the final implementation
* can indicate how far along the
project is at a given time
* each step after that?
* remove the next task from the
list
* design the implementation
for the selected task (design phase)
* code and test the implementation
(implementation phase)
* perform an analysis of the partial
resulting system (analysis phase)
...and update the project control
list as a result;
* potential advantages:
* better allows for changing
requirements (reordering the
project control list is not as
big a deal as changing the
requirements would be in
Waterfall)
* don't have the all-or-nothing
risk
* potential disadvantages:
* since the requirements for future
iterations are not known yet,
will the design of the system
in progress be robust enough?
* what if changes have to be
made to the existing system
at some point to accommodate
future requirements?
...might require extra legwork,
discarding earlier work, etc.
* each iteration, being deliverable,
does have an expectation of being
well-designed, robust, usable
* how about iterative DELIVERY?
* let's DEVELOP iteratively...
* do the requirements and architecture
design in a standard waterfall
or prototyping aproach --
thus, if you will, finalizing the
requirements early in the software
life cycle --
* but then design and build and deliver the
planned software in iterations
* the building of the system --
one of the most time- and effort-consuming
tasks -- is done iteratively,
even though nost the requirements are
specified up-fron
* potential advantages:
* with requirements known up-front,
you can hopefully write robust
software for each iteration
(with less throwiing away of
work from previous iterations)
* but client doesn't have the worry
of an all-or-nothing single delivery
at the end -- and they get software
they can start using earlier
* (and if you are wrong about the
requirements being done, feedback
can be obtained letting you know
this earlier, and in a less costly
fashion, than would be possible
with waterfall or prototyping)
* potential disadvantages:
* trying to nail down the requirements
"too early" might blunt some of the
benefit of having multiple iterations
* Rational Unified Process (RUP)
* created in 1996
* supposed to be VERY flexible,
iterative, architecture-centric,
and use-case driven;
* each RUP deliverable is called a project
but let's PLEASE call this a CYCLE instead...
* each cycle is executed in
a sequence of four phases
* inception
* elaboration
* construction
* and transition
...each cycle ending in a deliverable