Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used as a software development method

Software development methodology

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.- History :...

. DSDM was originally based upon the rapid application development

Rapid application development

Rapid application development is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself...

 method. In 2007 DSDM became a generic approach to project management and solution delivery. DSDM is an iterative and incremental

Iterative and incremental development

Iterative and Incremental development is at the liver of a cyclic software development process developed in response to the weaknesses of the waterfall model...

 approach that embraces principles of Agile development, including continuous user/customer involvement.

DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and won't haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of Agile method

Agile software development

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...

s for developing software and non-IT solutions, and it forms a part of the Agile Alliance.

The most recent version of DSDM, launched in 2007, is called DSDM Atern. The name Atern is a shortening of Arctic Tern

Arctic Tern

The Arctic Tern is a seabird of the tern family Sternidae. This bird has a circumpolar breeding distribution covering the Arctic and sub-Arctic regions of Europe, Asia, and North America...

 - a collaborative bird that can travel vast distances and epitomises many facets of the method which are natural ways of working e.g. prioritisation and collaboration.

The previous version of DSDM (released in May 2003) which is still widely used and is still valid is DSDM 4.2 which is a slightly extended version of DSDM version 4. The extended version contains guidance on how to use DSDM with Extreme Programming

Extreme Programming

Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...

.

DSDM and the DSDM Consortium: origins

In the early 1990s, a new term (RAD) was spreading across the IT industry. The user interfaces for software applications were moving from the old green screens to the graphical user interfaces that are used today. New application development tools were coming on the market, such as PowerBuilder. These enabled developers to share their proposed solutions much more easily with their customers – prototyping became a reality and the frustrations of the classical, sequential (waterfall) development methods could be put to one side.

However, the RAD movement was very unstructured: there was no commonly agreed definition of a suitable process and many organisations came up with their own definition and approach. Many major corporations were very interested in the possibilities but they were also concerned that they did not lose the level of quality in the end deliverables that free-flow development could give rise to.

The DSDM Consortium was founded in 1994 by an association of vendors and experts in the field of software engineering

Software engineering

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...

 and was created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice

Best practice

A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark...

 experiences. The origins were an event organised by the Butler Group in London. People at that meeting all worked for blue-chip organisations such as British Airways, American Express, Oracle and Logica (other companies such as Data Sciences and Allied Domecq have since been absorbed by other organisations).

At the initial meeting it was decided that Jennifer Stapleton, then of Logica, would put together an architecture for an end-to-end, user-centric but quality-controlled method for iterative and incremental development. The resulting architecture was designed to be fully compatible with ISO 9000 and PRINCE2, which were two major concerns for the group. Once the architecture was in place (a month after the initial meeting), the Consortium formed various task groups to populate it with all aspects of software development, including project management tools and techniques, quality and testing, development tools and techniques, personnel and software procurement. An oversight group led by the architect and consisting of the chairs of the task groups ensured consistency of the approach as it was developed.

Although many of the Consortium members were direct business competitors, they shared freely how they had addressed the various aspects. Best practice was extracted and formed into a cohesive whole. As the Consortium grew in its first year from a handful of organisations to sixty, the content of the method became increasingly robust. Version 1 was baselined in December 1994 and published in February 1995. The result was a generic method covering people, process and tools that was formed from the experiences of organisations of all sectors and sizes.

The DSDM Consortium is a not-for-profit, vendor-independent organisation which owns and administers the DSDM framework.
DSDM Atern =
Atern is a vendor-independent approach that recognises that more projects fail because of people issues than technology. Atern’s focus is on helping people to work effectively together to achieve the business goals. Atern is also independent of tools and techniques enabling it to be used in any business and technical environment without tying the business to a particular vendor.

Overview of DSDM Atern

As an extension of rapid application development, DSDM focuses on information systems

Information systems

Information Systems is an academic/professional discipline bridging the business field and the well-defined computer science field that is evolving toward a new scientific area of study...

 projects that are characterised by tight schedules and budgets. DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment

In 2007 a team set up by the DSDM Consortium looked into the content of DSDM V4.2 and decided that the underlying mechanics and structure were completely sound but that the terminology and the focus purely on I.T. applications should be updated to meet the needs of projects in the new millennium. Some of the content of the method had been there since 1995. The new version was launched at the Cafe Royale in London on 24 April 2007. Some amendments were made in April 2008 (Atern V2) and incorporated in the latest version of the Atern Handbook.

Principles

There are eight principles underpinning DSDM Atern. These principles direct the team in the attitude they must take and the mindset they must adopt in order to deliver consistently.

1. Focus on the business need


The main criteria for acceptance of a "deliverable" is delivering a system that addresses the current business needs. Delivering a perfect system which addresses all possible business needs is less important than focusing on critical functionalities.

• Understand the true business priorities
• Establish a sound Business Case
• Seek continuous business sponsorship and commitment
• Guarantee the Minimum Usable Subset of features.

2. Deliver on time

• Timebox the work
• Focus on business priorities
• Always hit deadlines

3. Collaborate


User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace (either physical or via tools), so that the decisions can be made collaboratively and quickly.

• Involve the right stakeholders, at the right time, throughout the project
• Ensure that the members of the team are empowered to take decisions on behalf of those they represent without waiting for higher-level approval.
• Actively involve the business representatives
• Build a one-team culture

4.Never compromise quality

• Set the level of quality at the outset
• Ensure that quality does not become a variable
• Design, document and test appropriately
• Build in quality by constant review
• Test early and continuously. See test-driven development
  Test-driven development
  Test-driven development is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new...
  
   for comparison.

5. Build incrementally from firm foundations

• Strive for early delivery of business benefit where possible
• Continually confirm the correct solution is being built
• Formally re-assess priorities and ongoing project viability with each delivered increment

6. Develop iteratively


A focus on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" 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.

• Do enough design up front to create strong foundations
• Take an iterative approach to building all products
• Build customer feedback into each iteration to converge on an effective business solution
• Accept that most detail emerges later rather than sooner
• Embrace change – the right solution will not evolve without it
• Be creative, experiment, learn, evolve

7. Communicate continuously and clearly


Communication and cooperation among all project stakeholders is required to be efficient and effective.

• Run daily team stand-up sessions
• Use facilitated workshops
• Use rich communication techniques such as modelling and prototyping
• Present iterations of the evolving solution early and often
• Keep documentation lean and timely
• Manage stakeholder expectations throughout the project
• Encourage informal, face to face communication at all levels

8. Demonstrate control

• Use an appropriate level of formality for tracking and reporting
• Make plans and progress visible to all
• Measure progress through focus on delivery of products rather than completed activities
• Manage proactively
• Evaluate continuing project viability based on the business objectives

Prerequisites for using DSDM

In order for DSDM to be a success, there are 9 instrumental factors which need to be met. If these cannot be met, it presents a risk to the Atern approach which is not necessarily a show stopper but which does need to be managed. These risks are also highlighted by the Project Approach Questionnaire.

1. Acceptance of the Atern philosophy before starting work.
2. Appropriate empowerment of the Solution Development Team.
3. Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement.
4. Incremental delivery
5. Access by the Solution Development Team to business roles
6. Solution Development Team stability.
7. Solution Development Team skills.
8. Solution Development Team size.
9. A supportive commercial relationship.

Overview of DSDM version 4.2

As an extension of rapid application development, DSDM focuses on information systems projects that are characterised by tight schedules and budgets. DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment. By encouraging the use of RAD, however, careless adoption of DSDM may increase the risk of cutting too many corners. DSDM consists of

• Three phases: pre-project phase, project life-cycle phase, and post-project phase.
• A project life-cycle phase is subdivided into 5 stages: feasibility study, business study, functional model iteration, design and build iteration, and implementation.

In some circumstances, there are possibilities to integrate practices from other methodologies, such as Rational Unified Process (RUP), Extreme Programming (XP)

Extreme Programming

Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...

, and PRINCE2

PRINCE2

PRojects IN Controlled Environments 2 is a structured project management method endorsed by the UK government as the project management standard for public projects. The methodology encompasses the management, control and organisation of a project...

, as complements to DSDM. Another agile method that has some similarity in process and concept to DSDM is Scrum.

In July 2006, DSDM Public Version 4.2 was made available for individuals to view and use; however, anyone reselling DSDM must still be a member of the not-for-profit consortium.

Overview : three phases of DSDM V4.2

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 realised and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project like cows.

Phase 2 - The Project life-cycle : The process overview in the figure below 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 implemented system. 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.

Phase 3 - Post-project : The post-project phase ensures the system operates effectively and efficiently. This is realised 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.

Below is the process-data diagram of DSDM as a whole Project life-cycle with all of its four steps. 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.

The four steps of the DSDM V4.2 Project Life-cycle

Activity	Sub activity	Description
Study	Feasibility Study	Stage where the suitability of DSDM is assessed. Judging by the type of project, organisational and people issues, the decision is made, whether to use DSDM or not. Therefore it will generate a FEASIBILITY REPORT, a FEASIBILITY PROTOTYPE, and a GLOBAL OUTLINE PLAN which includes a DEVELOPMENT PLAN and a RISK LOG.
	Business Study	Stage where the essential characteristics of business and technology are analysed. Approach to organise 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. In this stage, a PRIORITISED REQUIREMENTS LIST, a BUSINESS AREA DEFINITION, a SYSTEM ARCHITECTURE DEFINITION, and an OUTLINE PROTOTYPING PLAN are developed.
Functional Model Iteration	Identify functional prototype	Determine the functionalities to be implemented in the prototype that results from this iteration. In this sub-stage, a FUNCTIONAL MODEL is developed according to the deliverables result of business study stage.
	Agree schedule	Agree on how and when to develop these functionalities.
	Create functional prototype	Develop the FUNCTIONAL PROTOTYPE, according to the agreed schedule and FUNCTIONAL MODEL.
	Review functional prototype	Check correctness of the developed prototype. This can be done via testing by end-user and/or reviewing documentation. The deliverable is a FUNCTIONAL PROTOTYPING REVIEW DOCUMENT.
Design and Build Iteration	Identify design prototype	Identify functional and non-functional requirements that need to be in the tested system. And based on these identifications, an IMPLEMENTATION STRATEGY is involved. If there is a TEST RECORD from the previous iteration, then it will be also used to determine the IMPLEMENTATION STRATEGY.
	Agree schedule	Agree on how and when to realise these requirements.
	Create design prototype	Create a system (DESIGN PROTOTYPE) that can safely be handed to end-users for daily use, also for testing purposes.
	Review design prototype	Check the correctness of the designed system. Again testing and reviewing are the main techniques used. An USER DOCUMENTATION and a TEST RECORD will be developed.
Implementation	User approval and guidelines	End users approve the tested system (APPROVAL) 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. TRAINED USER POPULATION is the deliverable of this sub-stage.
	Implement	Implement the tested system at the location of the end users, called as DELIVERED SYSTEM.
	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 stage, the post-project or loops back to one of the preceding stages for further development. This review is will be documented in a PROJECT REVIEW DOCUMENT.

Four stages of the DSDM V4.2 Project life-cycle

Stage 1A: 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 1B: The Business Study

The business study extends the feasibility study

Feasibility study

Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest...

. 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 are 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

Requirements analysis

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...

 list. An important property of the requirements list is the fact that the requirements are (can be) prioritised. These requirements are prioritised using the MoSCoW approach. Based on this prioritisation, 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 realising the goals of DSDM, namely being on time and on budget, guaranteeing the desired quality. A system architecture

Software architecture

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both...

 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 prioritised requirements list. This list states all the requirements for the system, organised 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 2: 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 realise 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 realised 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 realised in this iteration, ready for testing by users. Next to this, the Requirements List is updated, deleting the items that have been realised and rethinking the prioritisation of the remaining requirements. The Risk Log is also updated by having risk analysis of further development after reviewing the prototyping document.

Stage 3: 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 realise these requirements.
• Create Design Prototype: Create a system that can safely be handed to end-users for daily use. They 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 4: Implementation

In the Implementation stage, the tested system including user documentation is delivered to the users and training of future users is realised. 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

Meta-data model

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

Process-data model

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 prioritised 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
Identify functional prototype	Analyse the requirements	The requirements of current prototype are analysed according to the prioritised requirements list that is previously developed (in previous iteration and/or in previous phase which is business study phase).
	List requirements of current iteration	Select the functional requirements that would be implemented in the current iteration’s prototype, and list them in the FUNCTIONAL REQUIREMENT.
	List non-functional requirements	List the non-functional requirements of the system that is being developed in NON-FUNCTIONAL REQUIREMENTS LIST.
	Create functional model	Analysis model and prototype codes are included in this sub-activity to develop the FUNCTIONAL MODEL.
Agree schedule	Determine time	Identify possible timetable (TIME SLOT) to perform the prototyping activities according to the prototyping plan and prototyping strategy.
	Design development	The PROTOTYPING PLAN, including all prototyping activities that will be performed on available TIME SLOT.
	Agreement	The agreement SCHEDULE of when and how the prototyping activities should be performed.
Create functional prototype	Investigate	Investigate the requirements; analyse the FUNCTIONAL MODEL that has been built in earlier activity, and set the IMPLEMENTATION PLAN according to the analysis model, and will be used to build the prototype in the next sub-activity.
	Refine	Implement the FUNCTIONAL MODEL and IMPLEMENTATION PLAN to build a FUNCTIONAL PROTOTYPE. This prototype will be then refined before it is combined to the other functions. This prototype will be gradually steered towards such quality that it can be included in the final system (through refining process).
	Consolidate	Consolidate the refined FUNCTIONAL PROTOTYPE with the other prototype of previous iteration. The new combination FUNCTIONAL PROTOTYPE will be tested in the next activity.
Review prototype	Test prototype	The essential part of DSDM that needs to be included throughout the whole process of DSDM. The TEST RECORD 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 report. Based on this FUNCTIONAL PROTOTYPING REVIEW DOCUMENT, the prioritised 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.