Dynamic Systems Development Method

From Amachu
Jump to: navigation, search

Since its origin in 1994, DSDM, the Dynamic Systems Development Method, has gradually become the number one framework for rapid application development (RAD) in the UK. DSDM is a non-profit and non-proprietary framework for RAD development, maintained by the DSDM Consortium. The developers of the method maintain that in addition to serving as a method in the generally accepted sense DSDM also provides a framework of controls for RAD, supplemented with guidance on how to efficiently use those controls.

The fundamental idea behind DSDM is that instead of fixing the amount of functionality in a product, and then adjusting time and resources to reach that functionality, it is preferred to fix time and resources, and then adjust the amount of functionality accordingly.

Process

DSDM consists of five phases: feasibility study, business study, functional model iteration, design and build iteration, and implementation. The first two phases are sequential, and done only once. The last three phases, during which the actual development work is done, are iterative and incremental. DSDM approaches iterations as timeboxes. A timebox lasts for a predefined period of time, and the iteration has to end within the timebox. The time allowed for each iteration to take is planned beforehand, along with the results the iteration is guaranteed to produce. In DSDM, a typical timebox duration is from a few days to a few weeks.

DSDM Process diagram

In the following, the phases are introduced, with their essential output documents.

The feasibility study phase is where the suitability of DSDM for the given project is assessed. Judging by the type of project and, most of all, organizational and people issues, the decision is made, whether to use DSDM or not. In addition, the feasibility study phase is concerned with the technical possibilities of going through with the project, and the risks therein. Two work products are prepared – a feasibility report, and an outline plan for development. Optionally, a fast prototype can also be made if the business or technology are not known well enough to be able to decide whether to proceed to the next phase or not. The feasibility study phase is not expected to take more than a few weeks.

The business study is a phase where the essential characteristics of the business and technology are analyzed. The recommended approach is to organize workshops, where a sufficient number of the customer’s experts are gathered to be able to consider all relevant facets of the system, and to be able to agree on development priorities. The affected business processes and user classes are described in a Business Area Definition. The identification of the affected user classes helps involving the customer, as the key people in the customer’s organization can be recognized and involved at an early stage. High level descriptions of the processes are presented in the Business Area Definition, in a suitable format (ER diagrams, business object models, etc.).

Another two outputs are done in the business study phase. One is a System Architecture Definition, and the other an Outline Prototyping Plan. The architecture definition is the first system architecture sketch, and it is allowed to change during the course of the DSDM project. The prototyping plan should state the prototyping strategy for the following stages, and a plan for configuration management.

The functional model iteration phase is the first iterative and incremental phase. In every iteration, the contents and approach for the iteration are planned, the iteration gone through, and the results analyzed for further iterations. Both analysis and coding are done; prototypes are built, and the experiences gained from them are used in improving the analysis models. The prototypes are not to be entirely discarded, but gradually steered towards such quality that they can be included in the final system. A Functional Model is produced as an output, containing the prototype code and the analysis models. Testing is also a continuing, essential part of this phase.

There are four further outputs in the phase (at different stages in the phase). Prioritized functions is a prioritized list of the functions that are delivered at the end of the iteration. Functional prototyping review documents collect the users’ comments about the current increment, working as input for subsequent iterations. Non-functional requirements are listed, mainly to be dealt with in the next phase. Risk analysis of further development is an important document in the functional model iteration phase, because from the next phase (design and build iteration) onwards, encountered problems will be more difficult to address.

The design and build iteration is where the system is mainly built. The output is a Tested System that fulfils at least the minimum agreed set of requirements. Design and build are iterative, and the design and functional prototypes are reviewed by the users, and further development is based on the users’ comments.

The final implementation phase is where the system is transferred from the development environment into the actual production environment. Training is given to users, and the system handed over to them. If the roll-out concerns a wide number of users, and done over a period of time, the implementation phase may also be iterated. Apart from the delivered system, the output of the implementation phase also includes a User Manual, and a Project Review Report. The latter summarizes the outcome of the project, and based on the results, the course of further development is set. DSDM defines four possible courses of development. If the system fulfils all requirements, no further work is needed. On the other hand, if a substantial amount of requirements have to be left aside (for example, if they were not discovered until the system was in development), the process may be run through again, from start to finish. If some less-critical functionality has to be omitted, the process may be run again from the functional model iteration phase onwards. Lastly, if some technical issues can not be addressed due to time constraints, they may be now done by iterating again, starting from the design and build iteration phase.

Roles and responsibilities

DSDM defines 15 roles for users and developers. The most dominant ones, as described in are listed in the following.

Developers and senior developers are the only development roles. Seniority is based on experience in the tasks the developer performs. The senior developer title also indicates a level of leadership in the team. The developer and senior developer roles cover all development staff, be it analysts, designers, programmers or testers.

A Technical coordinator defines the system architecture and is responsible for technical quality in the project. He is also responsible for technical project control, such as the use of software configuration management.

Of the user roles, the most important one is the Ambassador User. The respective duties are to bring the knowledge of the user community into the project, and to disseminate information about the progress of the project to other users. This ensures that an adequate amount of user feedback is received. The ambassador user has to come from the user community that will eventually use the system. Since the ambassador user is unlikely to represent all the required user viewpoints, however, an additional role of Adviser User is defined. Adviser users can be any users who represent an important viewpoint from the point of view of the project. Adviser users can be, e.g. IT staff, or financial auditors.

A Visionary is the user participant who has the most accurate perception of the business objectives of the system and the project. The Visionary is probably also the one with the initial the idea of building the system. The task of the visionary is to ensure that essential requirements are found early on, and that the project keeps going in the right direction from the viewpoint of those requirements.

An Executive Sponsor is the person from the user organization who has the related financial authority and responsibility. The Executive Sponsor therefore has ultimate power in making decisions.

Practices

Nine practices define the ideology and the basis for all activity in DSDM. The practices, called principles in DSDM, are listed in Table.

DSDM practices
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox
Print/export