Dynamic Systems Development Method

DSDM is a a framework based originally around Rapid Application Development (RAD),

supported by its continuous user involvement in an iterative development and incremental
approach which is responsive to changing requirements, in order to develop a system that
meets the business needs on time and on budget. It is one of a number of Agile methods for
developing software and forms part of the Agile Alliance.

DSDM was developed in the United Kingdom in the 1990s by a consortium of vendors and
experts in the field of Information System (IS) development, the DSDM Consortium,
combining their best-practice experiences. The DSDM Consortium is a non-profit and vendor
independent organisation which owns and administers the framework. The first version was
completed in January 1995 and published in February 1995. The current version in use at this
point in time (April 2006) is Version 4.2: Framework for Business Centered Development
released in May 2003.

DSDM Public Version 4.2 (www.dsdm.org) was made available for individuals to view and use
in July 2006. However, anyone reselling DSDM must still be a member of the not for profit
Consortium.

As an extension of rapid application development, DSDM focuses on Information System

projects that are characterized by tight timescales and budgets. DSDM addresses the problems
that frequently occur in the development of Information Systems with regards to going over
time and budget and other common reason for project failure such as lack of user involvement
and top management commitment.

DSDM consists of 3 phases: pre-project phase, project life-cycle phase, and post project phase.
The project life-cycle phase is subdivided into 5 stages: feasibility study, business study,
functional model iteration, design and build iteration, and implementation.

DSDM recognizes that projects are limited by time and resources, and plans accordingly to
meet the business needs. In order to achieve these goals, DSDM encourages the use of RAD
with the consequent danger that too many corners are cut. DSDM applies some principles,
roles, and techniques.

In some circumstances, there are possibilities to integrate other methods’ content, such as
Rational Unified Process (RUP), Extreme Programming (XP), and PRINCE2, to complement
DSDM in realizing a project. Another agile method that has similarities process and concept
with DSDM is Scrum.

Principles of DSDM
There are 9 underlying principles of DSDM consisting of four foundations and five starting-
points for the structure of the method. These principles form the cornerstones of development
using DSDM.
 • User involvement is the main key in running an efficient and effective project, where
both users and developers share a workplace, so that the decisions can be made
accurately.
• The project team must be empowered to make decisions that are important to the
progress of the project, without waiting for higher-level approval.
• DSDM focuses on frequent delivery of products, with assumption that to deliver
something earlier is always better than to deliver everything in the end. By delivering
product frequently from an early stage of the project, the product can be tested and
reviewed where the test record and review document can be taken into account at the
next iteration or phase.
• The main criteria for acceptance of deliverable in DSDM is on delivering a system
that addresses the current business needs. It is not so much directed at delivering a
perfect system addressing all possible business needs, but focuses its efforts on those
functionalities critical in achieving the stated project/business goals.
• Development is iterative and incremental, driven by users’ feedback to converge on
an accurate business solution.
• All changes during the development are reversible.
• The high level scope and requirements should be base-lined before the project starts.
• Testing is carried out throughout the project life-cycle. This has to be done in order
to avoid an expensive extra cost in fixing and maintaining the system before delivery.
• Communication and cooperation between all project stakeholders is an important
prerequisite for running an efficient and effective project.

DSDM is also supported by some other principles (or so called assumptions).

• No system is built perfectly in the first try (the pareto principle-80/20 rule). In the
process of developing an IS, 80% of the business benefit comes from 20% of the
system requirements, therefore DSDM starts implementing this first 20% of system
requirements to meet 80% of the business needs, which is good enough as long as the
users are intimately involved in the development process and in a position to ensure
that the missing 20% would not cause any serious business consequences.
Implementing the entire requirements often causes the project to go over deadlines and
budgets, therefore it is most times unnecessary to construct the perfect solution.
• Project delivery should be on time, on budget and with good quality.
• DSDM only requires each step of the development to be completed far enough for
the next step to begin. This way a new iteration of the project can commence without
having to wait for the previous to be completed entirely. And with every iteration the
system is improved incrementally. Recall that the business requirements are changing
over time at any rate.
• Both Project Management and Development techniques are incorporated in
DSDM.
• Next to developing new IS, DSDM can also be used in projects expanding current
system or even non IT-related business change projects.
• Risk assessment should focus on business function being delivered, not on the
construction process.
• Management rewards product delivery rather than task completion.
• Estimation should be based on business functionality instead of lines of code.
Prerequisites for using DSDM
In order for DSDM to be a success, a number of prerequisites need to be realized. First, there
needs to be interactivity between the project team, future end users and higher management.
This addresses well known failures of IS development projects due to lack of top management
motivation and/or user involvement.

The second important prerequisite for DSDM projects is the decomposability of the project.
The possibility of decomposition into smaller parts enables the iterative approach, and
activities, that are hard to prioritize, often causes delays. And that is exactly the effect that
DSDM was developed to avoid. Another group of projects for which DSDM is not well-suited
are safety-critical ones. The extensive testing and validation found in these kinds of projects
collide with DSDM goals of being on time and on budget. Finally, projects that aim at re-
usable components might not be well-suited for development using DSDM, because the
demands on perfection are too high and collide with the 80%/20% principle described earlier.

Process-Data Diagram of DSDM Project Life-cycle

Below is the process-data diagram of DSDM as a whole with all of its 5 stages. This diagram
depicts the DSDM iterative development, started on functional model iteration, design and
build iteration, and implementation phase. The description of each stage will be explained later
in this entry.

Activity Sub activity Description

Stage where the suitability of DSDM is assessed. Judging by
the type of project, organizational and people issues, the
Feasibility decision is made, whether to use DSDM or not. Therefore it
Study will generate a FEASIBILITY REPORT, a FEASIBILITY
PROTOTYPE, and a GLOBAL OUTLINE PLAN which
includes a DEVELOPMENT PLAN and a RISK LOG.
Stage where the essential characteristics of business and
Study technology are analyzed. Approach to organize workshops,
where a sufficient number of the customer’s experts are
gathered to be able to consider all relevant facets of the
Business
system, and to be able to agree on development priorities. In
Study
this stage, a PRIORITIZED REQUIREMENTS LIST, a
BUSINESS AREA DEFINITION, a SYSTEM
ARCHITECTURE DEFINITION, and an OUTLINE
PROTOTYPING PLAN are developed.
 Determine the functionalities to be implemented in the
Identify
prototype that results from this iteration. In this sub-stage, a
functional
FUNCTIONAL MODEL is developed according to the
prototype
deliverables result of business study stage.
Agree
Agree on how and when to develop these functionalities.
schedule
Functional
Model Iteration Create
Develop the FUNCTIONAL PROTOTYPE, according to the
functional
agreed schedule and FUNCTIONAL MODEL.
prototype
Check correctness of the developed prototype. This can be
Review
done via testing by end-user and/or reviewing documentation.
functional
The deliverable is a FUNCTIONAL PROTOTYPING
prototype
REVIEW DOCUMENT.
Identify functional and non-functional requirements that need
Identify to be in the tested system. And based on these identifications,
design an IMPLEMENTATION STRATEGY is involved. If there is
prototype a TEST RECORD from the previous iteration, then it will be
also used to determine the IMPLEMENTATION STRATEGY.
Agree
Agree on how and when to realize these requirements.
Design and Build schedule
Iteration Create
Create a system (DESIGN PROTOTYPE) that can safely be
design
handed to end-users for daily use, also for testing purposes.
prototype
Check the correctness of the designed system. Again testing
Review
and reviewing are the main techniques used. An USER
design
DOCUMENTATION and a TEST RECORD will be
prototype
developed.
 User End users approve the tested system (APPROVAL) for
approval and implementation and guidelines with respect to the
guidelines implementation and use of the system are created.
Train future end user in the use of the system. TRAINED
Train users
USER POPULATION is the deliverable of this sub-stage.
Implement the tested system at the location of the end users,
Implement
Implementation called as DELIVERED SYSTEM.
Review the impact of the implemented system on the
business, a central issue will be whether the system meets the
goals set at the beginning of the project. Depending on this
Review
the project goes to the next stage, the post-project or loops
business
back to one of the preceding stages for further development.
This review is will be documented in a PROJECT REVIEW
DOCUMENT.

The Phases of DSDM

The DSDM framework consists of three sequential phases, namely the pre-project, project life-
cycle and post-project phases. The project phase of DSDM is the most elaborate of the three
phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step
approach in developing an IS. The three phases and corresponding stages are explained
extensively in the subsequent sections. For each stage/phase, the most important activities are
addressed and the deliverables are mentioned.

Phase 1: The Pre-Project

In the pre-project phase candidate projects are identified, project funding is realized and project
commitment is ensured. Handling these issues at an early stage avoids problems at later stages
of the project.

Phase 2: The Project life-cycle

The process overview in the figure above shows the project life-cycle of this phase of DSDM.
It depicts the 5 stages a project will have to go through to create an IS. The first two stages, the
Feasibility Study and Business Study are sequential phases that complement to each other.
After these phases have been concluded, the system is developed iteratively and incrementally
in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The
iterative and incremental nature of DSDM will be addressed further in a later section.

Stage 1: The Feasibility Study

During this stage of the project, the feasibility of the project for the use of DSDM is examined.
Prerequisites for the use of DSDM are addressed by answering questions like; ‘Can this project
meet the required business needs?’, ‘Is this project suited for the use of DSDM?’ and ‘What are
the most important risks involved?’. The most important techniques used in this phase are the
Workshops The deliverables for this stage are the Feasibility Report and the Feasibility
Prototype that address the feasibility of the project at hand. It is extended with a global Outline
Plan for the rest of the project and a Risk Log that identifies the most important risks for the
project.

Stage 2: The Business Study

The business study extends the feasibility study. After the project has been deemed feasible for
the use of DSDM, this stage examines the influenced business processes, user groups involved
and their respective needs and wishes. Again the workshops is one of the most valuable
techniques, workshops in which the different stakeholders come together to discuss the
proposed system. The information from these sessions is combined into a requirements list. An
important property of the requirements list is the fact that the requirements are (can be)
prioritized. These requirements are prioritized using the MoSCoW approach. Based on this
prioritization, a development plan is constructed as a guideline for the rest of the project. An
important project technique used in the development of this plan is timeboxing. This technique
is essential in realizing the goals of DSDM, namely being on time and on budget, guaranteeing
the desired quality. A system architecture is another aid to guide the development of the IS.

The deliverables for this stage are a business area definition that describes the context of the
project within the company, a system architecture definition that provides an initial global
architecture of the IS under development together with a development plan that outlines the
most important steps in the development process. At the base of these last two documents there
is the prioritized requirements list. This list states all the requirements for the system, organized
according to the MoSCoW principle. And last the Risk Log is updated with the facts that have
been identified during this phase of DSDM.

Stage 3: Functional Model Iteration

The requirements that have been identified in the previous stages are converted to a functional
model. This model consists of both a functioning prototype and models. Prototyping is one of
the key project techniques within this stage that helps to realize good user involvement
throughout the project. The developed prototype is reviewed by different user groups. In order
to assure quality, testing is implemented throughout every iteration of DSDM. An important
part of testing is realized in the Functional Model Iteration. The Functional Model can be
subdivided into four sub-stages:

• Identify Functional Prototype: Determine the functionalities to be implemented in the

prototype that results from this iteration.
• Agree Schedule: Agree on how and when to develop these functionalities.
• Create Functional Prototype: Develop the prototype. Investigate, refine, and consolidate
it with the combined Functional prototype of previous iterations.
• Review Prototype: Check the correctness of the developed prototype. This can be done
via testing by end-user, then use the test records and user’s feedbacks to generate the
functional prototyping review document.
The deliverables for this stage are a Functional Model and a Functional Prototype that together
represent the functionalities that could be realized in this iteration, ready for testing by users.
Next to this, the Requirements List is updated, deleting the items that have been realized and
rethinking the prioritization of the remaining requirements. The Risk Log is also updated by
having risk analysis of further development after reviewing the prototyping document.

Meta-data Model of Functional Model Iteration

The associations between concepts of deliverables in Functional Model Iteration stage are
depicted in the meta-data model below. This meta-data model will be combined with the meta-
process diagram of Functional Model Iteration phase in the next part.

Concept Definition
Log of identified risk. Important since the next stage onward,
RISK LOG encountered problem will be more difficult to address. This risk
log will need to be updated continuously. (VTT Publication 478)
List of requirements based on its prioritization. The prioritization
PRIORITIZED process is based on MoSCoW technique, to determine which
REQUIREMENTS LIST requirements must be implemented first into the system (the ones
that meet the business needs), and so on.
NON-FUNCTIONAL List of non-functional requirements is mainly to be dealt in the
REQUIREMENTS LIST next stage. (VTT Publication 478)
FUNCTIONAL Function that is used to build the model and prototyping
REQUIREMENT according to its priority.
Model that is built according to the functional requirements. It
will be used in order to develop the functional prototype in the
FUNCTIONAL MODEL
next sub-stage. This concept will be used to develop a
PROTOTYPING PLAN.
The process of quickly putting together a working model (a
PROTOTYPING prototype) in order to test various aspects of the design, illustrate
ideas or features and gather early user feedback.
The list of available times to do certain activities in order to
TIME SLOT
perform the plan according to the schedule.
Activities plan within prototyping process that will be performed
PROTOTYPING PLAN
in available time slots according to the schedule.
A set of activities plan with the related time agreed by the
SCHEDULE developers. This concept will be used to support the
implementation of FUNCTIONAL PROTOTYPE.
FUNCTIONAL A prototype of the functions the system should perform and how
PROTOTYPE it should perform them.
A preparation of activities to implement the functional
IMPLEMENTATION PLAN prototyping according to the schedule and the prioritized
requirements list.
Function of prototype that is being refined within current
REFINED FUNCTION
iteration before it is combined to the others and tested.
Function of prototyped that is combined with the other functional
COMBINED FUNCTION prototypes of previous iteration. The new combination functional
prototype will be tested in the next stage.
Record set of testing where the test script, test procedure, and
test result are included. This test record is used to develop the
TEST RECORD FUNCTIONAL PROTOTYPING REVIEW DOCUMENT, and
is also used indirectly to update the PRIORITIZED
REQUIREMENTS LIST.
It collects the users’ comments about the current increment,
FUNCTIONAL
working as input for subsequent iterations (VTT Publication
PROTOTYPING REVIEW
478). This review document will be used to update the RISK
DOCUMENT
LOG and PRIORITIZED REQUIREMENTS LIST.

Process-data Diagram of Functional Model Iteration

Identify functional prototype activity is to identify the functionalities that would be in the
prototype of current iteration. Recall that both, analysis and coding are done; prototypes are
built, and the experiences gained from them are used in improving the analysis models (based
also on updated prioritized requirements list and updated risk log). The built prototypes are not
to be entirely discarded, but gradually steered towards such quality that they can be included in
the final system. Agree schedule is to determine when and how the prototyping will be
implemented; it extends the scope to the available timetable and prototyping plan. And since
testing is implemented throughout the whole process, it’s also an essential part of this phase,
and therefore it is included in the Review Prototype activity right after the functional prototype
is built and the test record will eventually be used in the review prototype process and
generates the review document. Below is the process-data diagram of Functional Model
Iteration stage.

Activity Sub activity Description

 The requirements of current prototype are analyzed according
Analyze the to the prioritized requirements list that is previously developed
requirements (in previous iteration and/or in previous phase which is
business study phase).
List Select the functional requirements that would be implemented
Identify requirements of in the current iteration’s prototype, and list them in the
functional current iteration FUNCTIONAL REQUIREMENT.
prototype List non-
List the non-functional requirements of the system that is being
functional
developed in NON-FUNCTIONAL REQUIREMENTS LIST.
requirements
Create
Analysis model and prototype codes are included in this sub-
functional
activity to develop the FUNCTIONAL MODEL.
model
Identify possible timetable (TIME SLOT) to perform the
Determine time prototyping activities according to the prototyping plan and
prototyping strategy.
Agree
Design The PROTOTYPING PLAN, including all prototyping
schedule
development activities that will be performed on available TIME SLOT.
The agreement SCHEDULE of when and how the prototyping
Agreement
activities should be performed.
Investigate the requirements; analyze the FUNCTIONAL
MODEL that has been built in earlier activity, and set the
Investigate
IMPLEMENTATION PLAN according to the analysis model,
and will be used to build the prototype in the next sub-activity.
Implement the FUNCTIONAL MODEL and
IMPLEMENTATION PLAN to build a FUNCTIONAL
Create
PROTOTYPE. This prototype will be then refined before it is
functional Refine
combined to the other functions. This prototype will be
prototype
gradually steered towards such quality that it can be included in
the final system (through refining process).
Consolidate the refined FUNCTIONAL PROTOTYPE with the
other prototype of previous iteration. The new combination
Consolidate
FUNCTIONAL PROTOTYPE will be tested in the next
activity.
 The essential part of DSDM that needs to be included
throughout the whole process of DSDM. The TEST RECORD
Test prototype will be used together with users’ comments to develop the
PROTOTYPING REVIEW DOCUMENT in the next activity
of FMI phase.
Review
prototype Collects the user comments and documentation. The test
records will play an important role to develop this review
Review report. Based on this FUNCTIONAL PROTOTYPING
prototype REVIEW DOCUMENT, the prioritized requirements list and
risk log will be updated, and decide to set the next course
whether or not to do another iteration of FMI phase.

Stage 4: Design and Build Iteration

The main focus of this DSDM iteration is to integrate the functional components from the
previous phase into one system that satisfies user needs. It also addresses the non-functional
requirements that have been set for the IS. Again testing is an important ongoing activity in this
stage. The Design and Build Iteration can be subdivided into four sub-stages:

• Identify Design Prototype: Identify functional and non-functional requirements that

need to be in the tested system.
• Agree Schedule: Agree on how and when to realize these requirements.
• Create Design Prototype: Create a system that can safely be handed to end-users for
daily use. The investigate, refine, and consolidate the prototype of current iteration
within prototyping process are also important in this sub-stage.
• Review Design Prototype: Check the correctness of the designed system. Again testing
and reviewing are the main techniques used, since the test records and user’s feedbacks
are important to generate the user documentation.

The deliverables for this stage are a Design Prototype during the phase that end users get to test
and at the end of the Design and Build Iteration the Tested System is handed over to the next
phase. In this stage, the system is mainly built where the design and functions are consolidated
and integrated in a prototype. Another deliverable for this stage is a User Documentation.

Stage 5: Implementation

In the Implementation stage, the tested system including user documentation is delivered to the
users and training of future users is realized. The system to be delivered has been reviewed to
include the requirements that have been set in the beginning stages of the project. The
Implementation stage can be subdivided into four sub-stages:

• User Approval and Guidelines: End users approve the tested system for implementation
and guidelines with respect to the implementation and use of the system are created.
• Train Users: Train future end user in the use of the system.
• Implement: Implement the tested system at the location of the end users.
 • Review Business: Review the impact of the implemented system on the business, a
central issue will be whether the system meets the goals set at the beginning of the
project. Depending on this the project goes to the next phase, the post-project or loops
back to one of the preceding phases for further development.

The deliverables for this stage are a Delivered System on location, ready for use by the end
users, Trained Users and detailed Project Review Document of the system.

Phase 3:

Post-project

The post-project phase ensures the system operating effectively and efficiently. This is realized
by maintenance, enhancements and fixes according to DSDM principles. The maintenance can
be viewed as continuing development based on the iterative and incremental nature of DSDM.
Instead of finishing the project in one cycle usually the project can return to the previous
phases or stages so that the previous step and the deliverable products can be refined.

Core Techniques of DSDM

• Timeboxing

Timeboxing is one of the project techniques of DSDM. It is used to support the main
goals of DSDM to realize the development of an IS on time, within budget and with the
desired quality. The main idea behind timeboxing is to split up the project in portions,
each with a fixed budget and a delivery date. For each portion a number of
requirements are selected that are prioritized according to the MoSCoW principle.
Because time and budget are fixed, the only remaining variables are the requirements.
So if a project is running out of time or money the requirements with the lowest priority
are omitted. This does not mean that an unfinished product is delivered, because of the
pareto principle that 80% of the project comes from 20% of the system requirements, so
as long as those most important 20% of requirements are implemented into the system,
the system therefore meets the business needs and that no system is built perfectly in
the first try.

• MoSCoW

MoSCoW represents a way of prioritizing items. In the context of DSDM the MoSCoW
technique is used to prioritize requirements. It is an acronym that stands for:

MUST have this requirement to meet the business needs.

SHOULD have this requirement if at all possible, but the project success does not relay
on this.
COULD have this requirement if it does not affect the fitness of business needs of the
project.
 WOULD have this requirement at later date if there is some time left (or in the future
development of the system).

• Prototyping

This technique refers to the creation of prototypes of the system under development at
an early stage of the project. It enables the early discovery of shortcomings in the
system and allows future users to ‘test-drive’ the system. This way good user
involvement is realized, one of the key success factors of DSDM, or any System
Development project for that matter.

• Testing

A third important aspect of the goal of DSDM is the creation of an IS with good quality.
In order to realize a solution of good quality, DSDM advocates testing throughout each
iteration. Since DSDM is a tool and technique independent method, the project team is
free to choose its own test management method, for example TMap.

• Workshop

One of DSDM’s project techniques that aims at bringing the different stakeholders of
the project together to discuss requirements, functionalities and mutual understanding.
In a workshop the stakeholders come together and discuss the project.

• Modelling

This techique is essential and purposely used to visualise the diagrammatic

representation of a specific aspect of the system or business area that is being
developed. Modelling gives a better understanding for DSDM project team over a
business domain.

• Configuration Management

A good implementation of this configuration management technique is important for

the dynamic nature of DSDM. Since there is more than one thing being handled at once
during the development process of the system, and the products are being delivered
frequently at a very fast rate, the products therefore need to be controlled strictly as
they achieve (partial) completion.

Roles of DSDM
There are some roles introduced within DSDM environment. It is important that the project
members need to be appointed to different roles before they start to run the project. Each role
has its own responsibility. The roles are:
 • Executive Sponsor So called the “Project Champion”. An important role from the user
organization who has the ability and responsibility to commit appropriate funds and
resources. This role has an ultimate power to make decisions.
• Visionary The one who has the responsibility to initialize the project by ensuring that
essential requirements are found early on. Visionary has the most accurate perception of
the business objectives of the system and the project. Another task is to supervise and
keep the development process in the right track.
• Ambassador User Brings the knowledge of user community into the project, ensures
that the developers receive enough amount of user’s feedbacks during the development
process.
• Advisor User Can be any user that represents an important viewpoint and brings the
daily knowledge of the project.
• Project Manager Can be anyone from user community or IT staff who manages the
project in general.
• Technical Co-ordinator Responsible in designing the system architecture and control
the technical quality in the project.
• Team Leader Leads his team and ensures that the team works effectively as a whole.
• Developer Interprete the system requirements and model it including developing the
deliverablecodes and build the prototypes.
• Tester Checks the correctness in a technical extents by performing some testings.
Tester will have to give some comments and documentation.
• Scribe Responsible to gather and record the requirements, agreements, and decisions
made in every workshop.
• Facilitator Responsible in managing the workshops progress, acts as a motor for
preparation and communication.
• Specialist Roles Business Architect, Quality Manager, System Integrator, etc.

Iterative and Incremental Nature

Next to timeboxing and prioritizing of requirements, the DSDM also provides an iterative and
incremental approach to IS development. This can be seen in the figure depicting the Process
Overview above. The Functional Model Iteration, Design & Build Iteration and
Implementation stages are all depicted in an iterative manner that shows that each of these
stages can go over the different sub stages several times before entering the next stage. Every
iteration addressing a set of new functionalities. Thanks to the incremental development
approach every iteration is build on a functioning predecessor. And each increment can be
turned back when/if needed. Next to this property, the figure also shows arrows going back to
previous stages. For example, there is an arrow going back from Implementation to the
Business Study. If a big functionality has been discovered during development that couldn’t be
implemented, it might be possible to start all over by defining new requirements in a Business
Study. Another example of stepping back to a previous stage is the arrow from Implementation
to the Functional Model Iteration. This could be the case when functionality had to be omitted
during the previous Functional Model Iteration, because of time and/or budget constraints.
Only when all the requirements, needed to realize the set project and business goals, are met
will the project proceed into the post-project phase. Because of the iterative nature of DSDM, it
is essential to maintain good requirements management and configuration management in
place throughout the entire project. This ensures that the project does implement the desired
requirements in the desired fashion as was decided in the early phases of the project.

Critical Success Factors of DSDM

Within DSDM a number of factors are identified as being of great importance to ensure
successful projects. First there is the acceptance of DSDM by senior management and other
employees. This ensures that the different actors of the project are motivated from the start and
remain involved throughout the project. The second factor follows directly from this and that is
the commitment of management to ensure end-user involvement. The prototyping approach
requires a strong and dedicated involvement by end user to test and judge the functional
prototypes. Then there is the project team. This team has to be composed of skillful members
that form a stable union. An important issue is the empowerment of the project team. This
means that the team (or one or more of his members) has to posses the power and possibility to
make important decisions regarding the project without having to write formal proposals to
higher management, which can be very time-consuming. In order for the project team to be
able to run a successful project, they also need the right technology to conduct the project. This
means a development environment, project management tools, etc. Finally DSDM also states
that a supportive relationship between customer and vendor is required. This goes for both
projects that are realized internally within companies or by outside contractors. An aid in
ensuring a supporting relationship could be ISPL.

Meta-model (Meta-Modeling)
As explained in the Wikipedia item, Meta-Modeling takes a higher level look at methods and
techniques. In doing so it offers possibilities for comparing similar methods and techniques and
engineering new methods from existing ones.

The Meta data model, depicted below, identifies the concepts and associations between these
concepts within DSDM. As can be seen from the figure, two main concepts can be identified,
namely the Phase and the Flow concept. Each Flow originates from a Phase within DSDM.
Flows can be divided up in the sub concepts Data and Product. This subdivision is denoted
with a C, which means that the subdivision is disjoint and complete. In other words, a Flow is
always either a Data Flow or a Product Flow, but never both. In the situation of DSDM a Data
Flow can be an arc returning to one of the preceding phases. Product Flows are tangible goods
that result from one of the Phases and are the input of the next Phase, for example reports and
prototypes.

Then there is the second concept Phase that is also be divided two sub concepts with a
complete and disjoint ordering. These sub concepts are the Sequential and the Iterative Phases.
As was explained in an earlier section, DSDM starts with two sequential phases, The
Feasibility and Business Study. Next a number of Iterative phases follow, i.e. Functional
Model, Design & Build and Implementation phases. The picture also mentions a number of
rules and issues that are not included in the model, but that are important for this meta-model.
First there are the rules that concerns the behavior of the ‘’Flows’’. These rules restrict the
freedom of the flows so that they correspond to the ‘’Phase’’ transitions within DSDM. Next to
the rules a number of important issues are addressed that ensure that the DSDM project life-
cycle is guaranteed.

Comparison to other IS Development Methods

Over the years a great number of Information System Development methods have been
developed and applied, divided in Structured Methods, RAD methods and Object-Oriented
Methods. Many of these methods show similarities to each other and also to DSDM. For
example eXtreme Programming, XP also has an iterative approach to IS development with
extensive user involvement.

The Rational Unified Process is a method that probably has the most in common with DSDM
in that it is also a dynamic form of Information System Development. Again the iterative
approach is used in this development method.

Like XP and RUP there are many other development methods that show similarities to DSDM,
but DSDM does distinguish itself from these methods in a number of ways. First there is the
fact that it provides a tool and technique independent framework. This allows users to fill in the
specific steps of the process with their own techniques and software aids of choice. Another
unique feature is the fact that the variables in the development are not time/resources, but the
requirements. This approach ensures the main goals of DSDM, namely to stay within the
deadline and the budget. And last there is the strong focus on communication between and the
involvement of all the stakeholders in the system. Although this is addressed in other methods,
DSDM strongly believes in commitment to the project to ensure a successful outcome.