Any development process has to cope with ambiguity and change in the requirements.
The requirements are rarely clear at the start of a development, despite
the best efforts of the analysts; the installation of a system or new features
inevitably changes the users' working practices, and thereby their requirements;
and in any case, the world changes and the consequently so do the requirements.
For this reason, all modern development processes are incremental.
They all focus on a short loop between the end users and the developers.
Users (or at worst, analysts representing them) should be part of the development
process. The sooner we can put something before them and get their feedback,
the sooner we can get a clearer picture of what they really need, and work
on that.
This fundamental motivation has been the driving force behind the recent move towards agile methods. In their wake have come a range of agile technologies, from testing tools to online project managers.
Feedback from working software
Where possible, we show the users actual working software at an early stage,
and then improve on it using their feedback.. Tactics for minimising the
loop time include:
-
Component based development, in which
each usable software product is built from ready-made components plus a
variable amount of 'glue'.
-
Minimise the amount of 'ceremony': analysis, documentation, and bureaucracy.
Don't reduce QA, but integrate it intimately into the design process. These
are among the practices of eXtreme Programming.
-
Deliver a 'vertical slice' first, chosen to get the maximum useful feedback
from the users (by giving them functionality that they can minimally but
realistically try out; or giving them something that enables them to experiment
in the fuzzier areas). One of the benefits of object
oriented programming is that it makes it easy to extend or restructure
the slice later.
Feedback from model-building
It isn't always possible to build enough software early enough to get effective
feedback. There may be no components available; the minimal useful slice
may still require a great deal of programming and risk not giving an overall
picture. (These conditions often apply when venturing into a new field;
by contrast, where there are many similar programs available, the components
and the understanding of what's required are all there.) In this situation,
we need to build models, simulations and scenarios, and take the users
through the requirements on paper or as a slide show. Using coherent
modeling techniques like those of Catalysis™,
we can generate many questions to the users that would not otherwise have
been thought of.
Models and higher ceremony are also important in designing reusable
components, since we don't know what other components any one othem
will be coupled to in a working product.
Incremental development
Whether or not the earlier cycles involve building models or software,
the idea of incremental development is that something tangible is produced
every cycle. A cycle may be from three to six weeks; it's always the same
within a particular project. A regular visible delivery is good for morale:
it makes everyone --- developers, users, management --- feel that we're
definitely getting somewhere, and gives a clear idea of how the project
is progressing.
Cycle
deadlines are never slipped in incremental development; neither is quality
reduced. Instead, goals for a cycle are dropped if necessary. This technique
is called 'timeboxing'.
In order to achieve this, each cycle has a prioritised list of goals.
The list must be a mixture of 'Must haves', 'Should haves', 'Could haves',
and 'Would like to, but probably never will haves'. Because there are always
lower-priority goals in every cycle, it is possible to drop goals without
compromising the main track of development.
Iterative working
The premise of iterative working is that you don't know enough initially
to be able to plan the whole job in fine detail: part of the job is itself
to discover that information. All design work, like scientific discovery,
has something of this nature. Contrast it with steel manufacture or bread-making,
in which the timings and detailed tasks of each stage in the process are
known exactly in advance. Management techniques applicable to predictable
processes are therefore not so successful with discovery processes. Software
is usually somewhere along the spectrum from pure discovery to utter predictability.
The idea of iterative working is to manage the risks, and timeboxing
is one of several risk management techniques.
DSDM
highlights four major activities. However, each of them may occupy several
iterations. Each iteration begins with a choice of task: it may be the
definition of an interface, the design of a feature of the system, or perhaps
a mock-up demo for the users. A strong criterion for the choice of task
in any iterative method is that it should give you useful feedback that
will shed light on the plan for the future: so anything that clarifies
or confirms the requirements is good to do early; so is anything that will
help the designers understand any new technology. The last part of each
cycle is occupied with extracting this information and using it to refine
the plans for later cycles.
(All the points made in this article apply to all iterative methods,
including the named ones used for illustration here, such as DSDM, XP,
RUP, Catalysis.)
DSDM progresses from an initial business study through functional modeling
(= requirements analysis and architecture), design and build (= design
and coding), and implementation (=deployment, user training). The
whole process is itself iterative: earlier stages will be revisited and
reworked. No task is signed off as set in concrete before we move on to
the next. The assumption is that some reworking will be necessary, so we
plan for it.
The RUP phase
diagram illustrates how activities and phases are different. A phase is
a period of elapsed time: within it, we may be executing different tasks.
Microprocess: techniques for modeling and design
This article summarises the overall running of an incremental development
project, which is the day-to-day layer of process. At the more hourly scale
of what you do to create a model and render it into design, see the articles
on requirements, modeling,
architecture, object
oriented design, patterns, and testing.
Macroprocess: Reuse and Component based development
These basic processes are adapted where the aim is to work from components
or other reusable assets. See the articles on reuse
and components.
complete solutions for development process adoption
(consultancy, courses, workshops, mentoring, seminars, development)
