Method Overview
What is in DSDM
Introduction
The Dynamic
Systems Development Method (DSDM) is a framework
of controls for the development of IT systems to
tight timescales. It is independent of any
particular set of tools and techniques and can be
used with object-oriented and structured analysis
and design approaches in environments ranging
from the individual PC to global distributed
systems. DSDM has been used successfully by
organisations in both the public and private
sectors.
The lifecycle
which DSDM uses is iterative and incremental.
This move away from the traditional, waterfall
approach is possible because of the new
technologies which enable visualisation of the
interim products of system development. Indeed
the move is essential if IT solution providers,
whether internal IT departments or external
suppliers, are to deliver working systems in the
ever decreasing timescales demanded by businesses
today. While the waterfall approach is necessary
for many system developments, where a system is
suitable for RAD and is required in a short
timescale, the waterfall lifecycle is
inappropriate. In waterfall projects, advantage
can be gained from using components of the DSDM
approach to reduce the time to delivery and to
ensure that the right requirements are addressed.
When to use DSDM
DSDM is
particularly well-suited to business applications
but has been used with considerable success in
engineering system development. There are key
criteria which a system should demonstrate for
DSDM to be applied easily. The application should
have the functionality reasonably visible through
the user interface (screens, reports, etc.) to
enable prototyping to be used to maximum benefit.
The project should be able to identify all the
classes of users who will use the end result so
that knowledgeable representatives can
participate throughout the life of the project
and provide coverage of the views of all the user
classes. DSDM calls these representatives
"Ambassador Users" as they operate in
much the same way as diplomatic ambassadors by
providing a two-way communication channel between
the business community and the IT community. If
the system is large, it should be able to be
broken down into smaller components either for
incremental delivery or for development by
parallel teams. There are other more detailed
selection criteria contained in the DSDM
Suitability Filter.
Care should be
taken that the right sort of projects are
selected. Given that the emphasis of controls are
very different for rapid development, if problems
arise, disaster can ensue if DSDM is chosen for
the wrong reason, i.e. "we want the system
now and we don’t care about the rest of the
selection criteria". The converse is also
true. If traditional controls are applied to RAD,
the project will probably not succeed in
delivering quality software to the business when
it wants it. Comparing the waterfall lifecycle
with that of DSDM, some controls increase in
criticality whereas others have less importance.
The focus of controls is on ensuring that
iterative development will lead safely to the
right business solution.
DSDM provides a
generic process which must be tailored for use in
a particular organisation dependent on the
business and technical constraints. DSDM outlines
a five phase process as shown in the diagram:
- feasibility
study
- business
study
- functional
model iteration
- design and
build iteration
- implementation
Each phase of the
process has a minimum set of products emanating
from it. Each of the products has a defined
purpose and a set of quality criteria by which
achievement of that purpose can be assessed. How
the products will be produced and what they will
contain is left to the individual organisation or
project to decide. The set of products covers not
only technical products (e.g. the functional
model) but management products (e.g. an outline
prototyping plan) and quality products (e.g. test
documents). The set of products is the minimum
that the consortium considers safe for RAD. Local
practices and procedures can add to the set of
products, but any project which decides that a
DSDM product is unnecessary is in danger of being
out of control.
To ensure
controlled transition between phases,
preconditions for entry into each phase are
defined. The preconditions are both
management-based and product-related.
Feasibility
Study
The feasibility
study assesses the suitability of the application
for a RAD approach and checks that certain
technical and managerial conditions are likely to
be met. The feasibility study typically lasts a
matter of weeks (rather than months)
Business Study
The business study
scopes the overall activity of the project and
provides a sound business and technical basis for
all future work. The high-level functional and
non-functional requirements are baselined, a
high-level model of the business functionality
and information requirements is produced, the
system architecture is outlined and the
maintainability objectives are agreed. There are
three possible levels of maintainability and the
one to be achieved on the project must be agreed
at this time as it will drive the quality control
activities for the rest of the project. The three
levels are:
- the system
must be maintainable from its first
delivery into the operational
environment;
- initially,
maintainability is not guaranteed, but
will be addressed after delivery;
- the system is
a short-term fix and therefore will not
be maintainable and the developers
reserve the right to remove the system
from production once it has served its
immediate purpose.
If the third level
is the one chosen, it is essential that the
system is removed at the time agreed. There are
too many systems in operation which were built
quickly and which remain in place causing
problems to IT departments.
Like the
feasibility study, the business study is a short
phase, of no more than a month.
Functional
Model Iteration
The bulk of
development work is in the two iteration phases
where prototypes are incrementally built towards
the tested system which is placed in the user
environment during the implementation phase. All
prototypes in DSDM are intended to evolve into
the final system and are therefore built to be
robust enough for operational use and to satisfy
any relevant non-functional requirements, such as
performance.
The prime focus of
the functional model iteration is on prototyping
to elicit requirements (i.e. analysis through
demonstration and feedback). Each iteration may
be navigated a number of times, usually no more
than three for an area of the system. The
completed functional model will consist of all
necessary high level analysis models and
documentation supported by functional prototypes
which address detailed process and usability.
Design and
Build Iteration
During the design
and build iteration, the focus is on ensuring
that the prototypes are sufficiently well
engineered for use in the operational
environment. The preconditions for moving from
functional modelling to the design and build
iteration include agreement of a part of the
functional model which may or may not be fully
automated (depending on the application and on
the development environment). It should be noted
that the dividing line between functional
modelling and design and build is not as clear
cut as the diagram suggests. Some components of a
system may well pass from the functional model
iteration to the design and build iteration while
other components are still very sketchy or even
non-existent.
This means that
system design and build activities may happen
concurrently with the functional modelling
activities. Similarly in a large DSDM development
the implementation may be phased, so system
design may be concurrent with some
implementation.
Implementation
Implementation
consists of putting the latest increment into the
operational environment and training the users.
The final step in implementation is a review of
what has been achieved. There are four possible
outcomes, three of which are shown by dotted
arrows in the diagram.
- Everything
was delivered and there is no need for
further development (hence no arrow!)
- A new
functional area was discovered during
development and development returns to
the business study phase and the whole
process is worked through.
- A less
essential part of the functionality was
missed out due to time constraints.
Development returns to the start of the
functional model iteration and adds the
functionality to the delivered system.
- Some
non-functional requirement has not been
satisfied as it well as it would have
been, given more time. Development
returns to the design and build iteration
to rectify this.
Why DSDM is different
Traditional
approaches fix requirements (and deliver
software which satisfies all of them) while
allowing time and resources to vary during
development. In DSDM, the exact opposite is true,
time is fixed for the life of a project, resources
are fixed as far as possible. This means that the
requirements that will be satisfied are
allowed to change. Hence an important product of
the business study, is a clear prioritisation of
the high-level functional and non-functional
requirements. More detailed requirements are
collected during the later stages of development
and are also prioritised. DSDM projects guarantee
to satisfy at least the minimum usable subset of
requirements.
The flexibility of
requirements to be satisfied has significant
impact on the development processes and controls,
and on acceptance of the system. Indeed, a
fundamental assumption of DSDM is that nothing is
built perfectly first time, but that a usable and
useful 80% of the proposed system can be produced
in 20% of the time it would take to produce the
total system. One of the nine underlying
principles of DSDM is that fitness for business
purpose is the essential criterion for the
acceptance of deliverables. This moves away from
the approach of satisfying all the "bells
and whistles" in a requirements
specification and tracing the contents of the
entire requirements specification through
subsequent, dependent deliverables to final
delivery. The latter approach can lose sight of
the fact that the requirements may be inaccurate.
Timeboxes
The mechanism for
handling flexibility of requirements in DSDM is
the timebox. In any RAD project, there is a fixed
completion date which provides an overall timebox
for the work to be carried out. DSDM refines the
concept of timeboxing by nesting shorter
timeboxes of two to six weeks within the overall
time frame. It is these nested timeboxes that are
the focus for monitoring and control activities.
Each timebox has an immovable end date and a
prioritised set of requirements assigned to it.
Some of these are mandatory and some of a lesser
priority. The mix is essential, since if all the
requirements that are to be satisfied in a
timebox are mandatory, there will be no room for
manoeuvre when things don’t go perfectly to
plan or when new requirements surface that relate
to the work being addressed at the time.
A timebox will
produce something visible in order for progress
and quality to be assessed. This could be an
analysis model (partial or complete) or a system
component. Each timebox is subdivided into three
parts: investigation ( a quick pass to see
whether the team is taking the right direction), refinement
(to build on the comments resulting from the
review at the end of investigation) and finally consolidation
to tie up any loose ends. Hence all necessary
reviews and tests are contained within the
timebox. Otherwise it will very difficult to fit
rework and change into subsequent activities
which are also timeboxed in the project plan.
Communication and
documentation
DSDM achieves
delivery to tight timescales through shortening
communication lines between users and IT staff,
between analysts and designers, between and
across team members, and between differing levels
of management. The mechanisms by which these
communication lines are shortened differ from one
to another. For instance, the communication
between developers and users is eased through
having Ambassador Users as part of the
development team and by the use of prototypes
rather than lengthy documents to demonstrate
developers’ ideas.
DSDM defines a
strategy for defining what the necessary
documentation set will be for a given project.
Much of the documentation that is traditionally
produced is for the transfer of ideas from one
developer to another or from the developers to
the users. By keeping mixed user/developer teams
small and constant throughout development, DSDM
renders such documents largely unnecessary. For
the management documentation, local practices
should be followed but perhaps trimmed to
minimise unnecessary barriers to rapid movement
through the project. On the technical side, DSDM
provides guidance on how to decide what sort of
documentation it is necessary to control and why.
Keeping control
In line with its
philosophy of ensuring a controlled approach to
RAD, DSDM describes how configuration management
should be carried out. The iterative and
incremental nature of DSDM renders good
configuration management essential. In a
development project using DSDM, there are more
things happening at once and products are
delivered at a faster rate per week than would
occur during traditional development of a system
of a similar size. Therefore it is imperative
that strict control is kept on the products as
they achieve completion (whether partial or
otherwise). Every attempt should be made to keep
all deliverables in line at all times.
Deliverables include software components,
analysis models, design documentation, test data
and test results. This is one area where DSDM
imposes a heavier control load on developers than
in slower development.
|
DSDM