Dynamic systems development method

Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In 2007 DSDM became a generic approach to project management and solution delivery. DSDM is an iterative and incrementalapproach 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 methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance.

In 2007, DSDM was rebranded 'DSDM Atern'. The name Atern was a shortening of Arctic Tern - a collaborative bird^{[ citation needed ]} that can travel vast distances and epitomises many facets of the method which are natural ways of working e.g. prioritisation and collaboration.

In 2014, DSDM dropped the branding 'Atern' and reverted to its original name in the latest version of the method in the 'DSDM Agile Project Framework' positioned as "an ideal wrapper for more limited Agile frameworks... DSDM is often used to provide the full 'project' focus to compliment Scrum's team focussed product development process.". 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-BOK.^[1] The previous version (DSDM 4.2) had only contained guidance on how to use DSDM with Extreme Programming.

DSDM and the DSDM Consortium: origins[edit]

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 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 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 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.^[2]

DSDM Atern[edit]

Atern is a vendor-independent approach that recognises that more projects fail because of people problems 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.^{[ citation needed ]}

Overview of DSDM Atern[edit]

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

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.^{[ citation needed ]}

The DSDM Atern approach[edit]

Principles[edit]

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.

· Clearly define the scope of the system

· 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 meet 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 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 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[edit]

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.

DSDM 4.2[edit]

This section is empty. You can help by adding to it. (February 2014)

Overview of DSDM version 4.2[edit]

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), and PRINCE2, 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^[3] was made available for individuals to view and use; however, anyone reselling DSDM must still be a member of the not-for-profit consortium.

DSDM V4.2 Project Life-cycle[edit]

Overview: three phases of DSDM V4.2[edit]

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.

Дата добавления: 2015-08-27