Dynamic Systems Development Method

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Model of the DSDM software development process.
Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Models
Agile · Cleanroom · DSDM
Iterative · RAD  · RUP  · Spiral
Waterfall · XP · Scrum  · V-Model
FDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design
Tools
Compiler  · Debugger  · Profiler
GUI designer
Integrated development environment
This box: view • talk

Dynamic Systems Development Method (DSDM) is a software development methodology originally based upon the Rapid Application Development methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement.

Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

Contents

[edit] Overview

As an extension of rapid application development, DSDM focuses on Information Systems projects that are characterized 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 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), and PRINCE2, as complements to DSDM. Another agile method that has some similarity in process and concept to DSDM is Scrum.

DSDM was developed in the United Kingdom in the 1990s by the DSDM Consortium, an association of vendors and experts in the field of software engineering created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice experiences. The DSDM Consortium is a not-for-profit, vendor-independent organisation which owns and administers the DSDM framework. The first version was completed in January 1995 and was published in February 1995. The current version in use (as of April 2006) is Version 4.2: Framework for Business Centered Development, and was released in May 2003. In July 2006, DSDM Public Version 4.2[1] was made available for individuals to view and use; however, anyone reselling DSDM must still be a member of the not-for-profit consortium.

[edit] The DSDM approach

[edit]

Principles

There are 9 underlying principles consisting of four foundations and five starting-points.

  • 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.
  • 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.
  • 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.
  • Development is iterative and incremental and driven by users’ feedback to converge on an effective 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. (See Test-driven development for comparison).
  • Communication and cooperation among all project stakeholders is required to be efficient and effective.

[edit] Additional assumptions

  • No system is built perfectly in the first try (see the pareto principle or 80/20 rule). In short, 80% of the business benefit comes from 20% of the design requirements, therefore DSDM starts by implementing this critical 20% first; this may produce a system that provides enough functionality to satisfy the end-users and the remaining 80% can be added in later iterations. This mitigates risk of the project going over deadline and over budget.
  • Project delivery should be on time, on budget and with good quality.
  • Each step of the development only need to be completed far enough for the next step to begin. This allows a new iteration of the project to commence without unnecessary delay. Changes in design can coincide with the changes in demand from the end-users since every iteration of the system is improved incrementally.
  • Both Project Management and Development techniques are incorporated.
  • DSDM can be applied in new projects and for expanding current systems.
  • Risk assessment should focus on the business functionality being delivered, not on the development process nor its artifacts (such as requirements and design documents).
  • Management rewards product delivery rather than task completion.
  • Estimation should be based on business functionality instead of lines of code.

[edit]

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 prerequisite for DSDM projects is that the project can be decomposed in to smaller parts enabling the use of an iterative approach.

Two examples of types of projects for which DSDM is not considered well-suited are:

  • Safety-critical projects - the extensive testing and validation found in safety-critical projects conflict with DSDM goals of being on time and on budget.
  • Projects that aim to produce re-usable components - the demands on perfection are often too high and conflict with the 80%/20% principle described earlier.

[edit] DSDM Project Life-cycle

[edit] Overview : three 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.
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.

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 process-data diagram of DSDM Project Life-cycle

[edit] The four steps of the DSDM Project Life-cycle

Activity Sub activity Description
Study Feasibility Study Stage where the suitability of DSDM is assessed. Judging by the type of project, organizational 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 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 system, and to be able to agree on development priorities. In this stage, a PRIORITIZED 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 realize 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.

[edit] Four stages of the The Project life-cycle

Model of the DSDM software development process.

[edit] 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.

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

[edit] 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 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.

[edit] 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 realize 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.

[edit] Stage 4: 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.

[edit] DSDM Functional Model Iteration

[edit] 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.

Meta-data model of Functional Model Iteration
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)
PRIORITIZED REQUIREMENTS LIST List of requirements based on its prioritization. The prioritization 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 prioritized 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 PRIORITIZED 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 PRIORITIZED REQUIREMENTS LIST.

[edit] 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 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.

Model of the Functional Model Iteration.
Activity Sub activity Description
Identify functional prototype Analyze the requirements The requirements of current prototype are analyzed according to the prioritized 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; analyze 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 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.

[edit] Further DSDM topics

[edit]

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 rely 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.
  • Modeling
    This technique 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.

[edit]

Roles in 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.

[edit]

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 can go over their sub stages several times before entering the next stage. Each iteration addresses a set of new functionalities, and every iteration builds on a working predecessor. Each iteration can be undone if needed.

The Process Overview figure also shows arrows going back to previous stages. For example, there is an arrow 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. Similarly, there is an arrow from Implementation to the Functional Model Iteration. Functionality might be omitted during a previous Functional Model Iteration because of time or budget constraints. The project should proceed into the post-project phase only when it meets all the requirements defined by the project and business goals.

Because of the iterative nature of DSDM, it is essential to maintain good requirements management and configuration management throughout the entire project. This ensures that the project does implement the requirements that were decided in the early phases of the project.

[edit] 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.

[edit] Critical Success Factors of DSDM

Within DSDM a number of factors are identified as being of great importance to ensure successful projects.

  • Factor 1: 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.
  • Factor 2: 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.
  • Factor 3: 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 its members) has to possess 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.
  • Factor 4: 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.

[edit] 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.

[edit] See also

[edit] References

  1. ^ (www.dsdm.org)
 This article needs additional citations for verification. Please help improve this article by adding reliable references (ideally, using inline citations). Unsourced material may be challenged and removed. (October 2008)

[edit] Further reading

  • Coleman and Verbruggen: A quality software process for rapid application development, Software Quality Journal 7, p. 107-1222 (1998)
  • Beynon-Davies and Williams: The diffusion of information systems development methods, Journal of Strategic Information Systems 12 p. 29-46 (2003)
  • Brinkkemper, Saeki and Harmsen: Assembly Techniques for Method Engineering, Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
  • Abrahamsson, Salo, Ronkainen, Warsta Agile Software Development Methods: Review and Analysis, VTT Publications 478, p. 61-68 (2002)
  • Tuffs, Stapleton, West, Eason: Inter-operability of DSDM with the Rational Unified Process, DSDM Consortium, Issue 1, p. 1-29 (1999)
  • Rietmann: DSDM in a bird’s eye view, DSDM Consortium, p. 3-8 (2001)
  • iSDLC[dead link] integrated Systems Development Life Cycle

[edit] External links

Sister project Wikimedia Commons has media related to: Dynamic Systems Development Method
v • d • e
Software engineering
Fields
Concepts
Orientations
Models
Development models: Agile • Iterative model • RUP • Scrum • Spiral model • Waterfall model • XP • V-Model
Other models: CMMI • Data model • Function model • IDEF • Information model • Metamodeling • Object model • View model • UML
Software
engineers
Related fields
Retrieved from "http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method"
Personal tools