DSDM(Dynamic Systems Development Method)

DSDM

In this section we examine an example of how a 'design method‘ that is based around an RAD strategy is structured. The method that we will examine is the Dynamic Systems Development Method, generally known as DSDM. This originated in 1994, and is managed by the 'not-for-profit‘

UK-based DSDM Consortium (the associated trademark has a reversed second ‗D‘ character), which is mainly made up of representatives from the business community. At the time of writing, following a typical process of evolution, the

‗current‘ version of the DSDM method is DSDM is quite unlike any of the other design methods that we examine in this book. It is almost entirely concerned with managing and controlling the RAD process, and makes no assumptions about design strategy, notations or any of the other classical

‗method features‘. This is not to say that these issues are ignored in the DSDM design process, simply that DSDM makes no assumptions about their particular form. Indeed, throughout the DSDM lifecycle, there are two distinctive elements that emerge very strongly:

The roles, responsibilities and activities that people undertake and perform;

The effect of business needs upon design decisions. As much as such things can be placed in neat compartments, these factors mean that DSDM as a method can be considered as belonging in what we sometimes term the Information Systems category. This is not to say that it would never be used by (say) software engineers but, in terms of emphasis, it is far more concerned with business issues than with technological ones. In the rest of this section we seek to examine DSDM from two aspects. The first of these concerns the set of principles that underpin DSDM, since these principles provide the rationale for its particular structure and practices.

The second aspect that we examine is the DSDM development cycle, which is where these principles are interpreted to create its particular approach to systems development. We should also note that the DSDM practices are concerned with the complete development life-cycle, from establishing requirements through to planning maintenance although, as usual in this book, we will chiefly concern ourselves with those elements that are concerned with the roles generally described under the headings of ‗analysis and design‘.

The DSDM principles

DSDM is based around nine principles, which are invoked as necessary in order to decide on the way that the development process should be structured. In brief, these are as follows.

1. Active user involvement is imperative. As mentioned above, DSDM has a very strong ‗people‘ element and users are seen as being active participants in the development process. Two examples of very specific user roles encouraged in DSDM are the ambassador, who ‗guides the developers in their activities to ensure that the solution being developed will accurately meet the needs of the business‘; and the advisor, who is tasked with representing a particular user view (which might stem from marketing issues, the IT operational support, etc.).

2.  DSDM teams must be empowered to make decisions. This can be seen as being partially a corollary of the previous principle. For active user involvement to work effectively, it is essential to avoid the need for frequent consultation with higher-level management.

The focus is on frequent delivery of products. The DSDM process is based upon favouring a product-focused view over an activity-focused one. There is also an emphasis upon allocating short periods of time for performing various activities. (We should also note that the resulting products can be interim design documents, as well as prototypes or executable code.)

4. Fitness for business purpose is the essential criterion for acceptance of deliverables. DSDM places the main emphasis upon ‗delivering the necessary functionality at the required time‘. In that sense, it again takes a very different approach to those employed in the methods discussed in the following chapters, where issues of structure are also considered as important criteria. The DSDM view is that, once the functionality has been established, the solution can be re-engineered as necessary.

5. Iterative and incremental development is necessary to converge on an accurate business solution. While iteration is a normal element in any development process, it is not always easy to incorporate this into an organization‘s procurement procedures. DSDM, however, explicitly makes this an expectation, with the aim of

achieving continuous improvement in the system through its use.

6. All changes during development are reversible. Basically this means that configuration control is an essential and all-pervasive element of the DSDM development context. As and when necessary, it should always be possible to backtrack to reuse an earlier version as the basis for the next incremental step in development.

7.  Requirements are baseline at a high level. In contrast to ‗traditional‘ approaches, where the documentation of system requirements may occupy several volumes of very detailed specification, the DSDM approach is to freeze the requirements at a high level, but allow more detailed aspects to evolve as necessary.

8.  Testing is integrated throughout the lifecycle. Rather than being a separate 'end of project‘

activity (as implied in the waterfall model) user acceptance testing of only partially-complete software proceeds throughout the development process.

9. A collaborative and co-operative approach between all stakeholders is essential. The main concern here is to involve stakeholders, implying that change control procedures should be kept as

‗light‘ as possible, so that short-term redirection of a project can be achieved through a shared understanding, rather than as the outcome

of an adversarial conflict between developers and users. Enumerating these principles does reinforce the earlier point that the focus of attention in DSDM is really upon business aims and people. Before going on to see how the principles are embodied in the process, we need to examine two other aspects of the ‗DSDM philosophy‘, both of which form important concepts for the method.