Dynamic Systems Development Model

The dynamic systems development model (DSDM) is based on RAD (Rapid Application Development). It focuses on early development of key features
constant end user review to make sure the features being developed are the ones needed
cutting scope to ensure that the project is as small as possible and gets out on time and to budget.

The model is a very well documented system and comprises a lot of detail. The key to it, however, is not the detail but the principles and practices which underlie that detail:-

End user involvement

Users’ feedback is used at each iteration to converge on an effective business solution.

Users and developers must share a workplace because user involvement is key in developing an efficient and effective project.

Feature scope control

The requirement to deliver a project on time and to budget, with good quality overrides the inclusion of all but the most important features.

Current business needs are rated much more highly than possible future needs. Future needs will be much better served by a future development where end users can better judge their worth.

It is a key assumption of DSDM that 80% of the business benefit comes from 20% of the design requirements. Thus the feature set must be cut to the bare bones - there must be a clear need for a feature before it is included. A small feature set simultaneously increases the chance of project success and reduces the potential cost of project failure.

The development team must be allowed to make decisions that are important to the progress of the project. What this really means is that the team should include people competent to make those decisions.

Mechanics

Frequent delivery of products. Delivering something which is barely credible - but on time - is better than mere progress towards a 'perfect' result. This allows testing and stakeholder review which is much better than ticking of 'work'.

All changes during the development are reversible. Projects do not want to be stuck with the large negative consequences of a decision which turns out to be wrong. This means course control methods and practices must be carefully designed and policed.

Unit and regression testing is carried out throughout the project life-cycle and made as efficient as possible, preferably using automated testing.

Development of one component should only proceeded as far as necessary for user review or a dependant component to be developed. This cuts out time wasted perfecting a component which turns out to be changed later or cut from the project entirely.