Dynamic Systems Development Method

Justin T. Bowers Department of Software Engineering University of Wisconsin – Platteville Platteville, WI 53818 [email protected]

Abstract

Development methods have come a considerable way since flowcharts were first used to plan projects. Presently, the software development world has a great number of method- ologies available for developing software. These methodologies provide a framework or structure to plan the software development process. This paper will focus on the DSDM, or the Dynamic System Development Methodology. This methodology focuses on incre- mental and iterative design, similar to the Rapid development method it is based on. This paper will go on to discuss how through the use of Timeboxing and fixed budgets, projects may be simplified so that the only remaining variables are the project's require- ments. By prioritizing these requirements to ensure that those most essential are complet- ed first, DSDM guarantees a finish project of the highest quality.

Introduction

History

In the 1990s, the term Rapid Application Development began coming into use in the software world. Many software companies hoped to utilize development methods that could be considered “rapid” and “agile”. The Dynamic Software Development Method is one such development method designed to “meet the needs of a fast business” [1].

In January 1994, sixteen individuals from the software development business met to form the DSDM Consortium. This group hoped to establish an independent RAD methodology. The basic concepts of DSDM were established by March, and the consortium now consisted of 36 members. The organization assigned various members to individual workgroups to design the methodology, and version 1.0 was completed by January of 1995. Since that time the method has undergone several revisions, and the current version of the system is DSDM Atern. It should be noted that the current version was introduced in May of 2003. This showcases that the DSDM approach to software development is mature, as it has not undergone any major revisions for several years.

Bowers 1 SE411 Organization

The DSDM consortium is based out of the United Kingdom, and the vast majority of their membership also resides there. It is a non-profit, vendor-independent organization led by a board of 11 directors, 10 of whom are elected from the membership. The organization does have membership fees, which are about $860 US dollars, although it costs several times that amount for businesses to become members.

When it comes to training in the use of DSDM, the consortium has taken an approach similar to that of standards such as ISO9000. They have established a number of accredited training organizations, which offer courses to become a practitioner in the use of DSDM. Becoming a practitioner involves paying $655 US dollars for the training, and eventually taking a one hour, 60-question test. Passing this test requires only half the questions be answered correctly.

In addition to becoming a certified practitioner of DSDM, one may also seek to become a Trainer, Coach, Examiner, or Consultant. These certifications require additional levels of training. Trainers are the individuals who may perform this training. Coaches are very similar to trainers, although they work in-house in a business setting to ensure that the DSDM approach is being followed correctly. Consultants are similar to Coaches; however their focus is on working with upper management in the use of DSDM. Examiners are individuals certified to test others to become practitioners of DSDM.

When to Use

DSDM is not suitable for all projects. In particular, systems that are real-time, safety critical, or have well defined requirements are not suited to the use of DSDM. One of the most important aspects of DSDM is that it relies on a fixed schedule with variable requirements. If the project does not require a fixed end date then it is likely the end date will be pushed back and the fundamentals of DSDM will be lost. Furthermore, this reliance on a fixed end date means DSDM is especially suited to projects with changing requirements. It is critical that these requirements be capable of being prioritized.

Other essential criteria for the use of DSDM include that the software being delivered should be interactive with users and have an interface that can be clearly demonstrated. The users of this software should also be a clearly defined group. Furthermore, the software should not be extremely large nor complex. It must be possible to break down aspects of the system into smaller components to produce manageable functional increments.

Principles

The entire approach of DSDM relies on nine principles [1], which are applied throughout the entire process. These principles are as follows:

1. Active user involvement

Bowers 2 SE411 2. Teams must be empowered to make their own decisions. 3. Frequent delivery of releases is more important than maximizing quality. 4. The primary criteria for deliverables is meeting the business needs. 5. Iterative development is essential to reach a correct solution. 6. Any change during development can be reversed. 7. The most high level requirements should be unchangeable. 8. Testing shall occur throughout the lifecycle of the project. 9. All stakeholders must cooperate and communicate.

Attaining Success

DSDM defines several critical factors to the success of its approach. First and foremost, the philosophy behind DSDM must be accepted by management. If the persons responsible for the project are not convinced DSDM is appropriate, then failure is assured from the start [1]. Furthermore, management must empower the project team to make decisions themselves. If the team cannot make decisions on the fly, then they will not be able to take advantage the prioritized variable requirements that DSDM relies on. If management does not wish to do this, they must participate regularly with the development team.

Project Lifecycle

Pre-Project

DSDM contains definitions for a pre-project stage, which is executed prior to beginning of project development. At this point a project does not exist, although it is likely management has possible candidate projects in mind. This stage of development is when management identifies a project to pursue. It is important to note that the DSDM consortium has stated that the “evaluation and prioritization of projects ... is beyond the scope of DSDM” [1]. At this point the scope of the Feasibility Study to come will need to be outlined, with budget and resources allocated to the task. To truly begin a project in full, three things are necessary: the identified project, the funding, and commitment from management.

Project

This is when all the actual phases of the DSDM occur. There are five phases in this stage: the feasibility study, the business study, functional mode iteration, design and build iteration, and implementation.

Bowers 3 SE411 Figure 1: DSDM Project Lifecycle[1]

Figure 1 showcases each of the five stages in an overview of the project lifecycle. Of the five stages, two are paired: the feasibility study and the business study. The business study is an immediate continuation of the feasibility study. Once those two stages have been completed, it is time to begin the iterative development process, which pans through functional model iteration, design and build iteration, and the implementation. Once the implementation of the current functional model has been completely designed and reviewed, it is time to continue the process anew with an updated functional model.

Post-Project

In addition to the pre-project phase, DSDM also contains a post-project stage. This stage occurs when the project's team has been disbanded and the only activities remaining are maintenance, support, and review. This consists of keeping the system operational for its necessary lifetime in an effective manner. It is also possible for enhancements to be added. It is possible to view this stage as “continuing development based on the iterative and incremental nature of DSDM” [4].

Process Overview

Feasibility Study

Bowers 4 SE411 Once a project has been approved, including a budget and resources, it is time to begin scoping out the project. A feasibility study will investigate the options available to complete the project, while providing a very vague cost estimate and identifying the major milestones the project will need to reach. More exact identifications of the costs, requirements, risks, and plans will occur later. The feasibility study is primarily to investigate the potential scope of the project. The DSDM consortium recommends that projects begin “with a kick-off Facilitated Workshop to ensure that key stakeholders buy in to the project” [1]. The feasibility study produces up to four items: a feasibility report, a feasibility prototype, a plan outline, and a risk log. The feasibility report should answer several questions:

Is the problem definition in line with the needs of senior business management? Is the scope of the project sufficiently clear for it to be refined within the Business Study? Are the business objectives to be met by the development clearly defined? Is the solution to the problem, as laid out in the major products to be delivered and in the objectives of the project, feasible in both technical and business terms? Is the case for the project approach sound, i.e. are the risks acceptable after checking the Suitability/Risk List? Does management accept what has been included and excluded from the scope? Are all associated systems and their interfaces identified? Is any impact on those systems acceptable? Is the Business Case for the project to proceed valid? [1]

The optional feasibility prototype is a proof-of-concept prototype to help assess the technical risks of taking on the project. This phase also produces an outline plan to cover major project milestones, a risk log to detail what could go wrong in the project, and counter-measures to overcome these risks. These need not be very exact, as the purpose of this stage is to gauge the feasibility of the project. These items are all refined in the Business Study phase. The risk log in particular will continue to be refined until a functional model is developed.

Business Study

Should a project be deemed feasible, it is time to begin the Business Study phase. The purpose of this phase is to refine the plans of the previous phase and develop detailed requirements. This phase will produce a definition of the business area the project is aimed at, a requirements list prioritized according to the MoSCoW method, a development plan, a definition of the system architecture, and an updated risk log.

The business area definition is the “processes, people and information to be supported by the proposed solution” [1]. The requirements list created at this phase in the project will mostly include higher level requirements, with greater detail added as the project continues. Non-functional requirements in particular are not necessary until the Functional Model phase. In the DSDM these requirements are to be prioritized according to the MoSCoW system.

Bowers 5 SE411 Functional Model Iteration

This phase involves the conversion of the previously established requirements into a prototype and functional models. Prototypes created during this phase are key, as they can be shown to users and reviewed. An important aspect of this phase is that testing may now begin. When the stage completes, a functional model and a functional prototype will have been generated. Note that small projects may simply consider this phase and the Design and Build phase to be one and the same. This may also be true if the technology exists to generate quality code from the models. Moreover, even if the project is neither small nor being developed with code generating technology, it is possible to overlap with the Design and Build stage as some parts of the project may be further ahead than others.

With this phase underway, the first step is to identify the requirements that will be implemented in this iteration. A schedule for this phase will need to be developed. By the end of the phase, one or more prototypes should be developed for the system. Any previous iterations of the development process will be used to get things started. Once all is said and done, the prototype is reviewed by user testing to develop a review document.

Design and Build Iteration

Once a functional model is developed the design and build stage may begin at anytime, even before the previous stage is fully complete. Testing is still very important, and the goal is to integrate the components being worked on into one system that users may test. The goal of this phase is to have a full design prototype developed for users to test. This is also the time to create user documentation.

The individual stages of this phase are very similar to the Functional Model phase, in that a prototype is to be identified, created, and reviewed while a schedule is created as soon as the prototype has been identified.

Implementation

In the final phase, the implementation phase, the tested system may be delivered to the end user. End users may approve the tested system and begin training new users. The system may be implemented in its final location. Once again, review is very important as it will lead back into the functional model stage if the project is not yet fully realized. Eventually the project should be fully realized, and the final system should be delivered to end users, ready to use.

Techniques

Bowers 6 SE411 There are several techniques that DSDM recommends be used when creating projects. Of these techniques, prototyping, testing, and modeling are all inherent in the design process. Workshops are also highly recommended to generate requirements for the system. Configuration management is a technique virtually any software project should be making use of, regardless of the methodology. This leaves Timeboxing and MoSCoW as the two major techniques of DSDM that are unique. These two techniques form a large part of what DSDM seeks to accomplish.

MoSCoW

The MoSCoW system is a method of prioritizing items. DSDM utilizes it as a system for prioritizing requirements. This acronym stands for Must, Should, Could, and Would. These are the four types of priorities that requirements may have. Must priorities are those that are absolutely required in order to meet the business needs of the end users. Should priorities are those that the system should have if even remotely possible, but the system will not fail outright if the requirement is not met. Could priorities are those that it would be nice for the system to have, but the quality of the final system will not be affected if these priorities are not met. Lastly, the Would priorities are requirements that could be added at a later time if it is feasible to do so, such as during post-project development.

Timeboxing

Timeboxing is an incredibly important part of DSDM. The goal of this technique is to support the realization of keeping the project within a fixed timeline and budget. Timeboxing is an attempt to split the project up as much as possible, with each part of the project having the aforementioned fixed deadline and costs. With requirements the only remaining variable in the equation, the developers may omit the least necessary requirements as defined by the MoSCoW system. The idea behind this is that DSDM is making use of the Pareto principle, which states that 80% of a project comes from 20% of the system requirements [4].

Roles

DSDM also defines a number of roles that may be useful to assign individuals to throughout the project. In particular, there are three roles that are essential at the upper levels of the project according to DSDM.

The first of these is the Executive Sponsor. This is the individual with the authority to commit funding and resources to the project. Ultimately, this user has the final say in any decision making process. The next of these roles is the project Visionary. The visionary is the individual working on the project that has the greatest knowledge and view of where

Bowers 7 SE411 the project is headed, and what the objectives of the project development actually are. This role has an important job in supervising the project in order to ensure everything is going according to plan. Lastly, there is the Ambassador User. This role is vital in order to bring actual user experience and knowledge of the community to the project, in order to guarantee that the developers are actually designing a system that users will need or want.

Several other roles are defined as well, and while they may be essential to every project these should all be fairly clear in their purpose. These roles include the project manager, technical coordinator, team leader, developer, tester, scribe (documents the project development), and facilitator (responsible for managing communication and workshops.

Conclusion

Looking now at the DSDM approach in its entirety, it is clear it is designed to take advantage of an incremental and iterative approach as much as possible. It is a highly useful method for use in projects where prioritizable, variable requirements would be advantageous. As the consortium states, their methodology is not just a fad. It is a “tried and tested” method “based firmly on common sense and industry best practice” [1].

References

[1] DSDM Public Version 4.2 Manual. (n.d.). DSDM Consortium - Enabling Business Agility. Retrieved March 24, 2010, from http://www.dsdm.org/version4/2/public/default.asp

[2] What Is DSDM? - CodeProject. (n.d.). Your Development Resource - CodeProject. Retrieved March 24, 2010, from http://www.codeproject.com/KB/

[3] Davies, R. (2004, September 21). DSDN Explained. Agile eXperience. Retrieved March 24, 2010, from www.agilexp.com/presentations/DSDMexplained.pdf

[4] Dynamic Systems Development Method - Wikipedia, the free encyclopedia. (n.d.). Wikipedia, the free encyclopedia. Retrieved March 29, 2010, from http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method

Bowers 8 SE411