DSDM

= = =Dynamic Systems Development Method= toc

What is it?
DSDM is a framework that specializes in delivering business solutions using organized common sense based methods of system design. It makes sure the system is feasible, stresses collaboration and makes heavy use of prototyping to ensure a fully functional system is developed (Clifton, M. & Dunlap, J. 2003).



Phase 1: The Pre-Project
This phase ensures the right projects are chosen, set up correctly and that there is enough funding. Initial feasibility planning is done. (DSDM Consortium 2006).

Phase 2: The Project life-cycle
This phase consists of the five stages to be used when creating an information system.

Stage 1: Feasibility Study
This stage determines whether or not DSDM is the right approach to use to design the system. The feasibility study is generally short, lasting only a few weeks, and consists of just enough information to cover all its bases (DSDM Consortium 2006). It consists of a feasibility report, an outline plan and a feasibility prototype. The report provides a definition of the problem, the costs involved and the viability of using a computer system to solve the problem. The outline supports the report in ensuring the solution is attainable. The prototype demonstrates how this solution is attainable and may come in the form of software or in a document (DSDM Consortium 1997).

Stage 2: Business Study
This stage lays out the groundwork for the rest of the project and focuses on understanding the business requirements and identifying technical constraints. Also relatively short, it relies heavily on collaboration in the form of facilitated workshops which aim to pool knowledge and determine what the main priorities should be in development. This information is called a Business Area Definition and provides insight into the company’s business processes as well as the users who will be affected by the implementation of this system. Each requirement is prioritized leaving the least important aspects to be developed and implemented later if still necessary. A Systems Architecture Definition is also produced which explains the development and operational platforms and architecture of the software which is to be developed based on its major components and their interfaces. The outline made in the feasibility study is then used to create the Outline Prototyping Plan which illustrates how the Functional Model Iteration and the Design and Build Iteration will be carried out as well as how the product is to be checked and controlled (DSDM Consortium 1997).

Stage 3: Functional Model Iteration
This stage is concerned with refining the business-based aspects of the system through the creation of standard analysis models and software. This is done through a cycle of four steps and is also found in the Design and Build Iteration. These steps include identifying what is to be produced, how and when to produce it, creating it, and checking that it has been produced correctly. The standard analysis models and software are built through these cycles to contain major functionality and some non-functional requirements. They are then tested through technical unit testing and mini-acceptance tests to verify what the components do and if they function properly. Non-functional requirements are tested in the Design and Build Iteration but it may be necessary to combine them when attending to an area in detail (DSDM Consortium 2006).

Stage 4: Design and Build Iteration
This stage is where the system is actually created to the point where it is properly usable for its intended users. In order for this stage to commence, a functional model is to be created which is another reason for combining both the functional model iteration and design and build iteration. The result of this phase is the Tested System. It includes all the core requirements, which are called the minimum usable subset, and whatever else could be included under the time constraints. Throughout this entire phase testing and documentation is continually conducted, especially at the end of each development increment (DSDM Consortium 1997).

Stage 5: Implementation
This stage involves transforming the system from a development environment into an operational environment. It includes training those not part of the project team and implementing the system in phases if necessary. The result of this phase is the Delivered System and the completion of its user documentation. A Project Review document is also created upon completion of the system which summarizes what the system has achieved. It outlines the requirements and is evaluated based on four outcomes on how close the system is to the requirements. The outcomes include: All requirements have been satisfied, a major area of functionality was discovered during development and had to be ignored, lower priority functionality had to be left out because of time constraints, and an area of lesser technical concern was omitted. These areas are to be immediately addressed if they have not all the requirements have been satisfied (DSDM Consortium 1997).

Phase 3: Post-project
This phase ensures the system continues operating properly. Being an iterative project, maintenance is seen as continuing development on the system (Clifton, M. & Dunlap, J. 2003). Anything needed to be addressed should follow the DSDM method to guarantee proper collaboration and development.

= = =References=


 * Content**

Clifton, M., & Dunlap, J. (2003). //What is DSDM?//. Retrieved November 20, 2006, from http://www.codeproject.com/gen/design/dsdm.asp

DSDM Consortium. (2006). //DSDM Lifecycle//. Retrieved November 20, 2006, from [| http://na.dsdm.org/en/about/lifecycle.asp]

DSDM Consortium. (1997). The Process. DSDM Manual Version 3. Retrieved Novmeber 20, 2006 from [|http://htsa.ie.hva.nl/~helpdesk/DSDMManual/p1ovproc/3proc01.htm]


 * Image**

LShift Ltd: Agile Approach. (2006). DSDM. Retrieved November 20, 2006, from http://www.lshift.net/dsdm