Dynamic systems development method

Last updated December 11, 2021

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method.^[1]^[2] First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method.^[3] In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation^{[ clarification needed ]}^{[ citation needed ]} and could be used for non-IT projects.^[4] The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods.^[5] The DSDM Agile Project Framework is an iterative and incremental 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 will not haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance.

In 2014, DSDM released the latest version of the method in the 'DSDM Agile Project Framework'. At the same time the new DSDM manual recognised the need to operate alongside other frameworks for service delivery (esp. ITIL) PRINCE2, Managing Successful Programmes, and PMI.^[6] The previous version (DSDM 4.2) had only contained guidance on how to use DSDM with extreme programming.

History of DSDM

In the early 1990s, rapid application development (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 organizations 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 and was created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice experiences. The origins were an event organized by the Butler Group in London. People at that meeting all worked for blue-chip organizations such as British Airways, American Express, Oracle, and Logica (other companies such as Data Sciences and Allied Domecq have since been absorbed by other organizations).

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

In 2014, the DSDM handbook was made available online and public.^[8] Additionally, templates for DSDM can be downloaded.^[9]

In October 2016 the DSDM Consortium rebranded as the Agile Business Consortium (ABC).^[10] The Agile Business Consortium is a not-for-profit, vendor-independent organisation which owns and administers the DSDM framework.^[11]

DSDM

DSDM is a vendor-independent approach that recognises that more projects fail because of people problems than technology. DSDM’s focus is on helping people to work effectively together to achieve the business goals. DSDM 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.^[8]

Principles

There are eight principles underpinning DSDM.^[12] These principles direct the team in the attitude they must take and the mindset they must adopt to deliver consistently.

Focus on the business need
Deliver on time
Collaborate
Never compromise quality
Build incrementally from firm foundations
Develop iteratively
Communicate continuously and clearly
Demonstrate control

Core techniques

Timeboxing: is the approach for completing the project incrementally by breaking it down into splitting the project in portions, each with a fixed budget and a delivery date. For each portion a number of requirements are prioritised and selected. 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: is a technique for prioritising work items or requirements. It is an acronym that stands for:
- Must have
- Shoud have
- Could have
- Won't have

Prototyping: 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 realised, one of the key success factors of DSDM, or any system development project for that matter.
Testing: helps ensure 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.
Workshop: brings project stakeholders together to discuss requirements, functionalities and mutual understanding.
Modeling: helps visualise a business domain and improve understanding. Produces a diagrammatic representation of specific aspects of the system or business area that is being developed.
Configuration management: with multiple deliverables under development at the same time and being delivered incrementally at the end of each time-box, the deliverables need to be well managed towards completion.

Roles

There are some roles introduced within DSDM environment. It is important that the project members need to be appointed to different roles before they commence the project. Each role has its own responsibility. The roles are:

Executive sponsor: So called the project champion. An important role from the user organisation 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 initialise 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 the user community into the project, ensures that the developers receive enough user feedback during the development process.
Advisor user: Can be any user that represents an important viewpoint and brings daily knowledge of the project.
Project manager: Can be anyone from the 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 of the project.
Team leader: Leads their team and ensures that the team works effectively as a whole.
Solution developer: Interpret the system requirements and model it including developing the deliverable codes and build the prototypes.
Solution tester: Checks the correctness in a technical extent by performing some testing, raise defects where necessary and retest once fixed. Tester will have to provide some comment and documentation.
Scribe: Responsible for gathering and recording the requirements, agreements, and decisions made in every workshop.
Facilitator: Responsible for managing the workshops' progress, acts as a motivator for preparation and communication.
Specialist roles: Business architect, quality manager, system integrator, etc.

Critical success factors

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: Directly derived from factor 1: The commitment of the management to ensure end-user involvement. The prototyping approach requires a strong and dedicated involvement by end users to test and judge the functional prototypes.
Factor 3: The project 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 to enable the project team to run a successful project, they also need the appropriate 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 realised internally within companies or by external contractors. An aid in ensuring a supporting relationship could be ISPL.

Comparison to other development frameworks

DSDM can be considered as part of a broad range of iterative and incremental development frameworks, especially those supporting agile and object-oriented methods. These include (but are not limited to) scrum, extreme programming (XP), disciplined agile delivery (DAD), and Rational Unified Process (RUP).

Like DSDM, these share the following characteristics:

They all prioritise requirements and work though them iteratively, building a system or product in increments.
They are tool-independent frameworks. This allows users to fill in the specific steps of the process with their own techniques^[5] and software aids of choice.
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.
A 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.

Related Research Articles

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

Iterative and incremental development is any combination of both iterative design or iterative method and incremental build model for development.

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

In Agile principles, timeboxing allocates a fixed and maximum unit of time to an activity, called a timeboxing, within which planned activity takes place. It is used by Agile principles-based project management approaches and for personal time management.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

Cowboy coding is software development where programmers have autonomy over the development process. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style.

Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology.

Adaptive software development (ASD) is a software development process that grew out of the work by Jim Highsmith and Sam Bayer on rapid application development (RAD). It embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.

Within project management, scrum is a framework for developing, delivering, and sustaining products in a complex environment, with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members, who break their work into goals that can be completed within time-boxed iterations, called sprints, no longer than one month and most commonly two weeks. The scrum team assess progress in time-boxed daily meetings of 15 minutes or less, called daily scrums. At the end of the sprint, the team holds two further meetings: the sprint review which demonstrates the work done to stakeholders to elicit feedback, and sprint retrospective which enables the team to reflect and improve.

Unified Process Object oriented software development process framework

The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process.

A glossary of terms relating to project management and consulting.

In software engineering, a software development process is the process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Small-scale project management is the specific type of project management of small-scale projects. These projects are characterised by factors such as short duration; low person hours; small team; size of the budget and the balance between the time committed to delivering the project itself and the time committed to managing the project. They are otherwise unique, time delineated and require the delivery of a final output in the same way as large-scale projects.

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

Agile Business Intelligence (BI) refers to the use of Agile software development for BI projects to reduce the time it takes for traditional BI to show value to the organization, and to help in quickly adapting to changing business needs. Agile BI enables the BI team and managers to make better business decisions, and to start doing this more quickly.

References

↑ Keith Richards, Agile project management: running PRINCE2 projects with DSDM Atern. OGC – Office of Government Commerce. The Stationery Office, 31 jul. 2007.
↑ Plonka, Laura, et al. "UX Design in Agile: A DSDM Case Study." Agile Processes in Software Engineering and Extreme Programming. Springer International Publishing, 2014. 1-15.
↑ Abrahamsson, Pekka, et al. "New directions on agile methods: a comparative analysis." Software Engineering, 2003. Proceedings. 25th International Conference on. Ieee, 2003.
↑ Stapleton, Jennifer (January 2003). Business Focused Development. Pearson Education. p. 113. ISBN 9780321112248.
1 2 Moran, Alan (March 2015). Managing Agile. Springer. pp. 21–24. ISBN 9783319162614.
↑ The DSDM Agile Project Framework manual, 2014 pages 4, 16
↑ (www.dsdm.org Archived 2016-10-02 at the Wayback Machine )
1 2 "The DSDM Agile Project Framework (2014 Onwards)". Agile Business Consortium. February 4, 2016.
↑ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set .Missing or empty |title= (help)
↑ "Agile's DSDM Consortium evolves into Agile Business Consortium". Press Dispensary.
↑ "Terms and Conditions of Community Membership" (PDF). DSDM Consortium. Retrieved 7 March 2013.
↑ Agile Business Consortium. The DSDM Agile Project Framework (2014 Onwards) Handbook - Principles.

External links

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] Keith Richards, Agile project management: running PRINCE2 projects with DSDM Atern. OGC – Office of Government Commerce. The Stationery Office, 31 jul. 2007.

[2] Plonka, Laura, et al. "UX Design in Agile: A DSDM Case Study." Agile Processes in Software Engineering and Extreme Programming. Springer International Publishing, 2014. 1-15.

[3] Abrahamsson, Pekka, et al. "New directions on agile methods: a comparative analysis." Software Engineering, 2003. Proceedings. 25th International Conference on. Ieee, 2003.

[4] Stapleton, Jennifer (January 2003). Business Focused Development. Pearson Education. p. 113. ISBN 9780321112248.

[Moran2015-5] 1 2 Moran, Alan (March 2015). Managing Agile. Springer. pp. 21–24. ISBN 9783319162614.

[6] The DSDM Agile Project Framework manual, 2014 pages 4, 16

[7] (www.dsdm.org Archived 2016-10-02 at the Wayback Machine )

[auto-8] 1 2 "The DSDM Agile Project Framework (2014 Onwards)". Agile Business Consortium. February 4, 2016.

[9] www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set .Missing or empty |title= (help)

[10] "Agile's DSDM Consortium evolves into Agile Business Consortium". Press Dispensary.

[11] "Terms and Conditions of Community Membership" (PDF). DSDM Consortium. Retrieved 7 March 2013.

[12] Agile Business Consortium. The DSDM Agile Project Framework (2014 Onwards) Handbook - Principles.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]