![]() |
Development Lifecycle »
Design and Architecture »
Methodologies
Beginner
What Is DSDM?By Marc Clifton, J. DunlapA concise summary of the Dynamic Systems Development Method, one of the "Agile Methods" |
C++/CLI, Windows, .NET, Visual-Studio, Dev
|
|
Advanced Search Add to IE Search |
|
|
|
||||||||||||||||

Figure 1
Whereas in traditional development
methodologies, functionality is fixed, and time and resources are variable, in
DSDM, time is fixed, and functionality are variable.
Dynamic Systems Development Method (DSDM) is an organized, common-sense process focused on delivering business solutions quickly and efficiently. It is similar in many ways to SCRUM and XP, but it has its best uses where the time requirement is fixed.
DSDM focuses on delivery of the business solution, rather than just team activity. It makes steps to ensure the feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.
Many systems fall short of meeting the needs of the users and purpose they were designed for, causing the system to either be abandoned or overhauled. There are a number of ways this may happen:
The following bullet list describes the core concepts of DSDM.
The people who will be using the product must be actively involved in its development. This important in order for the product to end up being useful to the people who will be using it.
The team should be able to make rapid and informed decisions, without having to cut through red tape to get those decisions approved.
DSDM focuses on frequent releases. Frequent releases allow for user input at crucial stages in the product's development. They also ensure that the product is able to be released quickly at all times.
The development is the system is done in iterations, which allows for frequent user feedback, and a partial but prompt solution to immediate needs, with more functionality being added in later iterations.
All products should be in a fully known state at all times. This allows for backtracking if a certain change does not work out well.
High-level requirements are worked out at the beginning of the project, before any coding, leaving the details to be worked out during the course of the development.
Meeting the business need is more important than technical perfection.
Testing is done at every step of the way, to ensure that the product being developed is technically sound and does not develop any technical flaws, and that maximum use is made of user feedback.
Collaboration and cooperation between all interested parties are essential for the success of the project. All involved parties (not just the core team) must strive together to meet the business objective.
DSDM assumes that 80% of the solution can be developed in 20% of the time that it would take to produce the total solution. DSDM focuses on this 80%, leaving another 20% for later revisions. DSDM assumes that not all of the requirements for the final solution are known to begin with, so it is likely that the final 20% of non-essential features are likely to be flawed anyway. (See MoSCoW Prioritization.)
The DSDM development process consists of 7 phases. The first one is before
the project has officially started. Then there are the project studies, which in
this document are considered to be one phase. Then there are three more phases
that consist of iterative cycles, which are repeated as necessary to complete
the project. Then there is the post-project phase, where the project is
maintained. The project flow may move between the different phases in the
directions indicated by the arrows above.
The dark blue arrows in the
diagram indicate the normal forward direction of project flow.
The green
arrows indicate directions that may be taken as necessary under normal
circumstances. For example, if the team has finished a "Design and Build"
iteration, but the system cannot be released until another area's functionality
has been defined and it has been built, the project flow may go back to the
"Functional Model" iteration to complete that area.
The light red arrow
represents a direction that is only taken if the project has been found to not
meet the required functionality.
The pre-project phase is not strictly defined. It occurs before the project officially begins. In this stage, the project is conceptualized, and the decision is made to start the project.

In this phase, the team researches the question: Can it be done within the constraints of time and resources? This phase is done as quickly as possible, because DSDM is best used where time is short, and therefore the product needs to be delivered quickly.
In this phase, the team researches the business aspects of the project.
- Build it
- Test it
- Deploy it
- Support it?
The model is also worked out in this phase.

In this stage, functional prototypes of the system are made and reviewed. A functional prototype is a prototype of the functions the system should perform and how it should perform them.
Prototyping follows these steps:
Prototypes cover many different aspects of the system:

In this stage, the product is designed and developed in iterations. In each iteration a design model is made of the area being developed, and then that area is coded and reviewed.

In the last phase, the product is wrapped up, documentation is written, and a review document is drawn up, comparing the requirements with their fulfillments in the product. The users are trained in how to use the system, and the users give approval to the system.
After the product is created, maintenance will inevitably need to be performed. This maintenance is generally done in a cycle similar to the one used to develop the product.
No. Even diehard proponents of DSDM agree that DSDM will not work for all projects. (But of course, nor will other methodologies.) More often than not, if full-on DSDM doesn't work, you'll end up using some DSDM concepts and principles, but not others. It is important to analyze the nature of the project at hand, and decide which concepts and principles will help you out, and which will not.
To use DSDM, there must be full management commitment, the team must be able to meet together easily, and the team must be able to work together easily.
1 out of 5 developers in the UK use DSDM, and more than 500 major companies have adopted it.
DSDM defines several key roles that should be filled by members of the team:
There are also other roles that are defined by DSDM:
Functionality is categorized according to its importance:
Prioritization is important because there is not enough time to do everything, and those things that are essential must be put before things that are not.
Prototypes are used heavily in DSDM. They ensure that all interested parties have a clear picture of the various aspects of the system.
Facilitated workshops allow for these benefits:
Fixed time periods ensure that:
DSDM Consortium - The official consortium for DSDM. Has a large number of articles and white papers on DSDM, plus DSDM certification, discussion groups, etc.
Agile Alliance DSDM Articles - Articles about DSDM on Agile Alliance's website. Especially focuses on intermixing DSDM and other Agile methodologies.
DSDM Manual - A DSDM manual, with poor layout, but some good insights.
Introducing DSDM into an Organization
DSDM Overview - A PowerPoint presentation outlining DSDM.
General
News
Question
Answer
Joke
Rant
Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads.
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 29 Sep 2003 Editor: Marc Clifton |
Copyright 2003 by Marc Clifton, J. Dunlap Everything else Copyright © CodeProject, 1999-2010 Web21 | Advertise on the Code Project |