CS 458 - Week 5 Lecture 2 - 2017-09-21
-------------------------------
Mythical Man-Month - Chapter 3
-------------------------------
* brute-force scale up (for programming really large systems)
tends to be:
* costly
* slow
* inefficient
* to produce systems that are not conceptually integrated
* Harlan Mill's suggestion: why not structure teams of
"surgical-style" teams, rather than designing teams
where all are "hacking away"?
...
-------------------------------
Jalote Chapter 2 - continued
-------------------------------
Iterative Development software development process
model, continued;
-------------------------------
* 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 most the requirements are
specified up-fron
* potential advantages:
* with requirements known up-front,
you can hopefully write robust
software for each iteration
(with less throwing 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
* (and there's the effort involved in
coming up with those complete requirements
up front...)
-------------------------------
Rational Unified Process (RUP)
-------------------------------
* created in 1996
* iterative, architecture-centric, use-case driven
* 6 best practices: (Wikipedia on RUP)
* develop software iteratively (risk-driven)
* manage requirements
* use component-based architecture
* visually model the software (often via UML)
* continuously verify software quality
* control changes to the software
* RUP is intended to be very FLEXIBLE,
a framework for your project that can result
in a process close to waterfall or close to
agile or many possibilities in between
* In RUP, a project is executed in a sequence
of four phases:
* we'll call this sequence of 4 phases a CYCLE
* 1. inception
2. elaboration
3. construction
4. transition
...ends in a defined milestone, that's a deliverable
product
* inception - launching the
current cycle
* elaboration - address the major
technical risks of the cycle
* construction - moving from
the executable architecture
from the elaboration phase
to a beta version ready for
evaluation
* transition - ends with the
cycle release milestone --
get it to the users,
ensure that it is working,
evaluate to prepare for the
next cycle
...release and evaluation;
* one point here is RUP is trying to separate these
phases from the TASKS traditionally performed
in developing software;
...you could have MULTIPLE of these traditional
tasks, in different levels of intensity,
in the different phases;
* that is, subprocesses of requirements,
design, coding, testing, etc.,
are considered as active throughout
the cycles of a project,
although the intensity of each
can vary from phase to phase
within different cycles
-------------------------------
Timeboxing
-------------------------------
* to speed up development, employ
parallelism between different iterations
* does this mean working on different
to-be-deliverable iterations at the SAME
time? YES
* really, uses the idea of PIPELINING
* ...carefully set up, for a project
suitable for such an approach!
* basic unit of development: a time box, of FIXED duration
* you decide what can be developed in this fixed duration,
NOT "given these desired features, how long do we need?"
* the time box is divided into a sequence of
EQUAL-LENGTH stages
* there is a dedicated team for each of those stages
* each STAGE performs a clearly-defined task
for the time box iteration,
and produces a clearly-defined output;
and, such that each stage is of the
same duration
(if 4 stages in a time box,
set up so each stage takes 1/4 of the time of
the time box;
if 3 stages in a time box,
set up so each stage takes 1/3 of the time
of the time box)
* and note: the people working on a stage
work on *that* stage for different
iterations of the time box,
over and over;
this does mean a BIGGER team of people,
(more people for getting releases/iterations
to the user more quickly)
* takes the same amount of time for
each iteration/deliverable,
BUT using more people working
in a pipelined-parallel fashion
to get more frequent releases
of those iterations to the users
...uses additional workforce to
reduce delivery time;
* (see the figures in Jalote Ch. 2 -- they illustrate
this approach nicely;)
* can be well-suited for projects with:
* a LARGE number of features
* needed in a SHORT time
* around a STABLE architecture
using STABLE technologies