Dynamic Systems Development Method
The Dynamic Systems Development Method (DSDM) was developed in the UK in the mid to late 1990s by folks with a businessnot a technicalperspective. The process is now managed by the DSDM Consortium and is probably the most popular Agile methodology in practice in the UK. DSDM is technically considered to be a framework, and the framework is versionedand releases are managedby the Consortium.
DSDM is one of the heavier Agile approaches available. It was originally developed as an extension to Rapid Application Development (RAD), incorporating best practices from the business-oriented founders.
DSDM projects consist of three phases (see also Figure 3):
- Pre Project: Things that need to occur before the project begins.
- Project Lifecycle: The actual project occurs. This phase is broken into five stages:
- Feasibility Study
- Business Study
- Functional Model Iteration
- Design and Build Iteration
- Post Project Phase: Things that need to occur after the project has been completed.
|Figure 3. DSDM Lifecycle. The three phases of a DSDM project involve a lot of steps.|
DSDM is founded on nine principles. These principles are:
- Active user involvement is imperative.
- The team must be empowered to deliver.
- Frequent delivery is key.
- The primary criterion for acceptance is the delivery of functionality that meets the current business needs.
- Iterative and incremental delivery is essential.
- All changes during the project lifecycle are reversible.
- Requirements are baselined at a high level.
- Integrated testing during the entire project lifecycle is expected.
- Collaboration and cooperation between all stakeholders is essential.
Given the business roots of DSDM, it should not surprise you that DSDM has a focus on delivering functionality on time and on budget. To accomplish this, it is understood that each project will be split into chunks, with each chunk having a specific number of features, budget, and time. If a project is running out of time or budget (since they are both fixed), the least important features are dropped and considered for future projects. Features (requirements) are prioritized using the following rules:
- MUST have this requirement.
- SHOULD have this requirement if at all possible.
- COULD have this requirement if it can be delivered without major impact.
- WOULD like to have these requirements if there is enough time remaining.
The MUST, SHOULD, COULD, and WOULD are commonly represented with the MoSCoW acronym.
DSDM purports that user feedback on requirements is crucial, and it places a lot of weight on prototypes created early in the project phase. These are used to refine requirements and clarify expectations of all stakeholders.
DSDM does not dictate the testing approach a project team should use, but does mandate that testing be performed throughout the project lifecycle phase. Testers must be involved in all aspects of the lifecycle phase to make sure all testing opportunities are maximized.
Workshops are used to provide a forum for all stakeholders to discuss the project requirements and functionality. They can be held as often as needed. Modeling is similar to Workshops, but held by the technical team members to create and communicate the technical aspects of the system, as well as other aspects of the system that can benefit from visual models, such as the business domain.
Due to the fixed controls of DSDM, a configuration management system that controls various aspects of a project is a requirement.
DSDM appears to set the upper boundary of project size to six teams of six people for each team. There may be instances of larger team sizes, but we were unable to find documentation supporting them. Because DSDM was founded on business best practices, you should be aware that DSDM also recommends it not be used for safety critical systems. This would include systems such as life support, toxic waste management, nuclear reactors, etc.