You get a bonus - 1 coin for daily activity. Now you have 1 coin

Dynamic Systems Development Method (DSDM)

Lecture



Dynamic Systems Development Method (DSDM) is mainly a software development methodology based on the Rapid Application Development (RAD) concept. In 2007, DSDM became the main approach to project management and application development [ source not specified 771 days ] . DSDM is an iterative and incremental approach that emphasizes continued participation in the user / consumer process.

The purpose of the method is to deliver the finished project on time and meet the budget, but at the same time adjusting the changes in the requirements for the project during its development. DSDM is part of a family of flexible software development methodologies, as well as developments outside the scope of information technology.

The latest version of DSDM is called DSDM Atern. The name Atern is an abbreviation of Arctic Tern (trans. Arctic tern). Arctic tern is a bird that can travel long distances. It symbolizes many aspects of a method, such as prioritization or co-operation, which are a natural way of doing work.

The previous version of DSDM (released in May 2003), which is still in operation and widely used, is DSDM 4.2, which is a slightly enhanced version of DSDM 4. The extended version provides guidance on how to use DSDM together with Extreme Programming.

Content

[remove]
  • 1 DSDM Atern Overview
  • 2 DSDM Revision 4.2
  • 3DSDM and the DSDM Consortium - early days
  • 4DSDM Method
    • 4.1 Principles
    • 4.2 Prerequisites for using DSDM
  • 5 Life Cycle Project
    • 5.1 Overview: Three DSDM Stages
    • 5.2 Four stages of the project life cycle stage
    • 5.3 Four stages of the project life cycle
      • 5.3.1 Stage 1A: Feasibility Study
      • 5.3.2 Stage 1B: Feasibility Study
      • 5.3.3 Step 2: Creating a functional model
      • 5.3.4 Stage 3: Design and Development
      • 5.3.5 Stage 4: Implementation
  • 6Stage of creating a functional DSDM model
    • 6.1 Meta-data model
    • 6.2 Process Development Model
  • 7More about DSDM
    • 7.1 Basic DSDM Techniques
    • 7.2 Roles in DSDM
    • 7.3Interactive and incremental nature of DSDM
  • 8 Factors necessary for the success of the DSDM method
  • 9Comparison with other methods of developing information systems
  • 10SM. also
  • 11Links

DSDM Atern Review

In 2007, the team created by the DSDM Consortium investigated the essence of the method and decided that the basic mechanisms and structure were well written, but the terminology and attention of the method were completely focused on the field of information technology. Therefore, they should be improved to meet the needs of projects in the new millennium (part of the method has been unchanged since 1995). The new version was released on April 24, 2007 at Cafe Royale in London.

DSDM version 4.2 review

As an extension of the concept of rapid application development, DSDM focuses on information system projects characterized by tight deadlines and budgets. In DSDM, there are indications of typical errors of information system projects, such as budget overruns, delay in delivery (performance), insufficient involvement of users and top managers in the work on the project. DSDM consists of:

  • three stages: pre-project, project life cycle stage and post-project stage
  • The project life stage consists of 5 stages: feasibility study, economic feasibility study, creation of a functional model, design and development, implementation stage

Under some conditions, it is possible to include parts of other techniques in DSDM, such as the Rational Unified Process (RUP), Extreme Programming, PRINCE2. Another flexible method similar to DSDM in process and concept is Scrum.

The DSDM method was developed in the UK in the 1990s by the DSDM Consortium. The DSDM Consortium is an association of software developers and experts created with the goal of "collaboratively developing and promoting an independent RAD framework" by combining the best practical experiences of association members. The DSDM Consortium is a non-profit organization of independent developers who own and operate the DSDM framework. The first version of the framework was completed in January 1995 and published in February 1995. In July 2006, an open version of DSDM 4.2 was introduced, which became available to individuals for viewing and use. However, everyone who distributes DSDM must be members of this non-profit consortium.

DSDM and the DSDM Consortium - early days

In the early 1990s, a new term began to spread in the information technology industry - Rapid Application Development (RAD). Application user interfaces have evolved from old green screens to graphical user interfaces that are still in use. New tools for creating applications started to enter the market, for example, PowerBuilder. They allowed developers to more easily share planned developments with customers - prototyping appeared and the destruction of classical, sequential (cascading) development methods began.

However, the new RAD movement was very unstructured: there was no consistent description of this method, and many organizations created their own descriptions and approaches to it. Many large corporations were interested in the prospects provided by the method, but they were also concerned that the quality level of their products would not fall as a result.

The DSDM consortium was formed in 1994 when a group of people met at an event organized by the Butler Group in London. Everyone who came to this event worked in large organizations such as British Airways, American Express, Oracle and Logica (companies such as Data Sciences and Allied Domecq have since been absorbed by other organizations).

At this meeting, it was decided that Jennifer Stapleton, then representing Logica, would develop an integrated, user-friendly method architecture with good quality control for iterative and incremental development. The resulting architecture was designed to be fully compatible with the ISO 9000 and PRINCE2 standards. When the architecture was ready (a month after the meeting), the Consortium formed groups for its distribution in all areas of software development, which included: project management methods and tools, quality control and testing, development methods and tools. The control group, headed by the creator of the architecture and consisting of the heads of these groups, should have provided an understanding of the method as it was originally intended.

Despite the fact that many members of the Consortium were direct competitors, they freely shared how they solve emerging problems. Practice has shown that the best result can be achieved only by working as one. The consortium has increased - in the first year from several organizations to sixty; The description of the method became more and more complete. Version 1 was formed in December 1994 and published in February 1995. The result was a universal method that covered people, processes, and tools. It was formed on the basis of the experience of organizations that are different in the nature of their activities and sizes.

DSDM method

Principles

There are 9 principles consisting of 4 basic and 5 starting points.

  • User engagement is the basis for an effective project, where developers share their workspace with users and therefore decisions will be more accurate.
  • The team should be authorized to make decisions important for the project without the consent of the supervisor.
  • Frequent delivery of result versions, taking into account such a rule that “to put something good in the past is always better than putting everything perfectly done at the end”. The analysis of deliveries of versions from the previous iteration is taken into account on the subsequent one.
  • The main criterion is the fastest possible delivery of software that meets current market needs. But at the same time, the delivery of a product that meets the needs of the market is less important than the solution of critical problems in the functionality of the product.
  • Development - iterative and incremental. It is based on user feedback in order to achieve an economically optimal solution.
  • Any changes during development are reversible.
  • Requirements are set at a high level before the project starts.
  • Testing is integrated into the development lifecycle.
  • Interaction and cooperation between all participants is necessary for its effectiveness.

Prerequisites for using DSDM

To successfully use DSDM, a number of prerequisites must be met. Firstly, it is necessary to organize interaction between the project team, future users and top management. Secondly, there should be the possibility of splitting the project into smaller parts, which will allow to use an iterative approach.

Two examples of projects for which DSDM is not very suitable:

  • security-critical projects — extended testing and approval in such projects conflict with the goal of the DSDM method to meet deadlines and budget.
  • projects whose goal is to produce reusable components - the requirements in such projects are too high and do not fit the 80% / 20% principle.

Project life cycle

Overview: Three DSDM Stages

The DSDM framework consists of three successive stages, which are called the pre-project stage, the project life cycle stage and the post-project stage. The stage of the project life cycle is the most thoughtful and elaborated of all the others. It consists of five stages, which form an iterative, incremental approach to the development of information systems. These three phases and the corresponding steps will be described in more detail in the following sections. For each stage or stage, the most important functions will be considered and the results will be presented.

Stage 1 - Pre-design

At this stage, probable projects are determined, funds are allocated and the project team is defined. Solving problems at this stage will help avoid problems in the later stages of the project.

Stage 2 - Project Life Cycle

The figure below shows this stage. It shows the 5 stages that need to go through the project to become an information system. The first two stages, the feasibility study and the study of economic feasibility, go consistently and complement each other. After the completion of these stages, an iterative and incremental development of the system takes place in stages: the creation of a functional model, design and development, the implementation phase. The iterative and incremental nature of DSDM will be described later.

Stage 3 - Post Project

At this stage, an effective system operation is ensured. This is achieved by maintaining the project, improving it, and correcting errors according to DSDM principles. The project is supported by continuing development based on the iterative and incremental nature of DSDM. Instead of completing a project in one cycle, they usually return to previous stages or stages to improve the product.

The diagram below shows the entire project life cycle. This diagram describes the iterative development of DSDM. A description of each stage will be presented below.

Dynamic Systems Development Method (DSDM)
Project Life Cycle Chart

Four stages of the project life cycle stage

Act Substance Description
Study Feasibility study At this stage, it is determined whether the project falls under the DSDM framework. Considering the type of project, organizational and personnel issues, it is decided whether to use the DSDM method or not. In this way, a report on applicability, a valid prototype and an approximate global project plan will be received, which includes a development plan and a protocol of possible risks.
Feasibility study At this stage, the main economic and technological characteristics are analyzed. A meeting of experts takes place, at which the most important aspects of the system are discussed and a decision is made on priorities in development. At this stage, a list of basic requirements, a description of the scope of commercial activity, a description of the system architecture and an approximate plan for creating prototypes are being developed.
Creating a functional model Defining a functional prototype The definition of the functional that will be incorporated in the prototype at this stage. In this sub-step, a functional model is developed according to the results obtained at the stage of economic feasibility study.
Coordination of plans There is an agreement on how and in what time frame the prototype functionality should be developed.
Creation of a functional prototype Development of a functional prototype, according to the plans and functional model.
Functional Prototype Analysis Check the health of the developed prototype. This can be achieved by testing the prototype by the end user and / or revising the documentation. The result is a document containing an overview of the functional prototype.
Design and Development Defining a constructive prototype Definition of functional and non-functional requirements of the system. Based on these requirements, an implementation strategy should be created. If there is a test record from the previous iteration, then it will also be used to create an implementation strategy.
Coordination of plans There is an agreement on how and in what time frame the stated requirements should be implemented.
Creating a constructive prototype Creating a system (constructive prototype) that can be given to users for testing.
Constructive prototype analysis Check the health of the designed system. This sub-step applies testing and revision of the results. Creation of user documentation and test protocol.
Implementation User approval End users approve a tested system for subsequent implementation and creation of a manual.
User training Training the future user to work with the system. The result of the sub-step is a contingent of trained users.
Implementation Implementation of the tested system among users.
System Market Analysis Analysis of the impact of the released system on the market. The main question is whether the goal set during the design of the system has been achieved. Based on this, the project moves to the next stage (post-project) or returns to the previous one for refinement. The analysis will be presented in the project analysis document.

Four stages of the project life cycle

Dynamic Systems Development Method (DSDM)
Software development model.

Stage 1A: Feasibility Study

During this phase, the feasibility of the project within the DSDM is checked. Prerequisites for using DSDM are checked by answering the questions: “Can this project meet the necessary economic requirements?”, “Is the project suitable for using the DSDM method?” And “What are the most important risks in this project?”. The most important method at this stage is the use of working groups.

The outcome of this phase is a report on applicability and a valid prototype, which examines the feasibility of the project, as well as a rough global project plan and a protocol of possible risks describing the most important risks of the project.

Stage 1B: Economic Feasibility Study

The study of economic feasibility extends and complements the feasibility study phase. After the project has been recognized as implemented within DSDM, at this stage business processes are checked, user groups are involved and their requirements and wishes are analyzed. And again, the most popular method at this stage is the use of working groups. Within the framework of working groups, project participants gather to discuss the planned system. Information obtained after these events is collected in the list of requirements. An important feature of this list is the prioritization among requirements. These requirements are distributed according to the MoSCoW method. On the basis of the obtained sequence, a development plan is created that will be a guideline for the entire project.

To create this plan, a very important method for the project is used - time-boxing. This technique is required to achieve the goals of DSDM - it will meet the deadlines and budget, and at the same time preserve the required quality of the product. The system architecture is another help in managing the development of an information system. The outcome of this phase is a description of the business scope, which contains the context of the project within the company, a description of the system architecture, providing the initial global architecture of the information system under development, and a development plan that identifies the most important steps in the development process. The basis of these two documents is a list of requirements. The protocol of possible risks is supplemented with data obtained at this stage.

Stage 2: Creating a Functional Model

Требования, которые были определены на предыдущем этапе, превращаются в функциональную модель. Она состоит из действующего прототипа и моделей. Прототипирование - ключевая методика проекта на данном этапе, позволяющая организовать вовлечение пользователей в проект. Разработанный прототип анализируется различными группами пользователей. Чтобы достичь необходимого качества, на каждой итерации применяется тестирование. Самая важная часть тестирования представлена на данном этапе. Создание функциональной модели можно разделить на следующие подэтапы:

  • Определение функционального прототипа: определение функционала, который будет заложен в прототипе на данном этапе.
  • Согласование планов: происходит согласование как и в какие сроки должен быть разработана функциональность прототипа.
  • Создание функционального прототипа: разработать прототип. Изучить и доработать прототип на данной итерации согласно функциональному прототипу, полученному на предыдущих итерациях.
  • Анализ функционального прототипа: проверить исправность спроектированной системы. На этом подэтапе применяется тестирование и пересмотр результатов.

Итогом данного этапа являются функциональная модель и функциональный прототип, которые вместе представляют функциональность полученный на этой итерации, готовые для тестирования пользователями. Далее обновляется список требований - из него удаляются уже реализованные пункты и происходит повторное изменение очерёдности оставшихся пунктов. Протокол возможных рисков также обновляется, после анализа функционального прототипа.

Этап 3: Проектирование и разработка

Главная задача этой итерации - объединить функциональные компоненты из предыдущего этапа в единую систему, удовлетворяющую требованиям пользователей. Здесь также рассматриваются нефункциональные требования. И снова на данном этапе происходит тестирование. Проектирование и разработку можно разделить на следующие подэтапы:

  • Определение конструктивного прототипа: определение функциональных и нефункциональных требований, которые должны быть в системе.
  • Согласование планов: происходит согласование как и в какие сроки должны быть реализованы поставленные требования.
  • Создание конструктивного прототипа: создание системы, которую можно отдать пользователям для повседневного использования. Изучить и доработать прототип на данной итерации.
  • Анализ конструктивного прототипа: проверить исправность спроектированной системы. На этом подэтапе применяется тестирование и пересмотр результатов. Для создания пользовательской документации используются протокол испытания и отзывы пользователей.

Итог этапа - создание конструктивного прототипа для тестирования пользователями. Протестированная система переходит на следующий этап. На данном этапе внешний вид и функциональность системы в общем готовы. Ещё один итог - создание пользовательской документации.

Этап 4: Реализация

На этапе реализации протестированная система вместе с пользовательской документацией доставляется к будущим пользователям и происходит их обучение работы с системой. Система анализируется на соответствие требованиям, поставленных на ранних этапах проекта. Реализацию можно разделить на следующие подэтапы:

  • Утверждение системы пользователем: конечные пользователи утверждают протестированную систему для последующей реализации и создания руководства.
  • Обучение пользователей: обучение будущего пользователя работе с системой. Результат подэтапа - контингент обученных пользователей.
  • Реализация: реализация протестированной системы среди пользователей.
  • Анализ рынка системы: анализ воздействия выпущенной системы на рынок. Главный вопрос - достигнута ли цель, поставленная при проектировании системы. Основываясь на этом проект переходит на следующую стадию (постпроектную) или возвращается на предыдущую для доработки.

Итог этапа: законченная система, пригодная для использования конечными пользователями, контингент обученных пользователей и детальный документ анализа проекта.

Этап создания функциональной модели DSDM

Модель мета-данных

Связи между понятиями на этапе создания функциональной модели показаны на модели на рисунке ниже.

Dynamic Systems Development Method (DSDM)
Модель мета-данных
Concept Description
Протокол возможных рисков Протокол обнаруженных рисков. Важен для последующих стадий, содержит проблемы с которыми есть вероятность столкнуться. Должен постоянно обновляться.
Список требований по приоритетам Список требований, распределённых по приоритету. Процесс распределения основан на методе MoSCoW, который определяет какие требования должны быть реализованы раньше (с экономической точки зрения)
Список нефункциональных требований Список нефункциональных требований, с которыми придётся иметь дело на следующем этапе.
Функциональное требование Эта функция используется для построения модели и прототипирования согласно приоритетам.
Функциональная модель Модель, построенная на основе функциональных требований. Она будет использована для разработки прототипа на следующем подэтапе. Эта модель будет использована для создания плана прототипирования.
Prototyping Процесс быстрого изготовления работающей модели (прототипа) для того, чтобы проверить дизайн, проиллюстрировать заложенные идеи и функции и по-раньше собрать отзывы пользователей.
Список интервалов времени Список интервалов времени выполнения отдельных работ, необходим, чтобы уложится в график выполнения всего проекта.
План прототипирования План процесса прототипирования, который будет выполнен во временные интервалы согласно графику.
График работ Набор работ и времени проведения этих работ, согласованный разработчиками. Используется в реализации функционального прототипа.
Функциональный прототип Прототип, позволяющий увидеть все функции системы и то, как система будет эти функции выполнять.
План реализации Подготовка работ для реализации функционального прототипа согласно графику работ и списку требований.
Улучшенная функция Функция прототипа, которая была улучшена и протестирована на данной итерации до объединения с другими частями прототипа.
Объединённая функция Функция прототипа, которая была объединена с функциями предыдущих итераций. Новый объединённый функциональный прототип будет протестирован на следующем этапе.
Протокол испытания Запись тестирования, состоящая из сценария тестирования, процедуры тестирования и результатов тестирования.
Документ анализа функционального прототипа Consists of user comments on the current version, required for work on subsequent iterations. This document is used to update the protocol of possible risks and the list of requirements.

Process development model

Работа по определению функционального прототипа заключается в определении функционала, который будет присутствовать в прототипе на данной итерации. Аналитика и программирование закончено; прототипы собраны; и опыт полученный от них использован для улучшения моделей анализа (а также основывается на обновлённых списке требований и протоколе возможных рисков). Построенные прототипы не выбрасываются, а понемногу доводятся до необходимого качества, чтобы потом включить в готовую систему. Согласованный график работ необходим, чтобы определить когда и в какие сроки будет реализовано прототипирование; он расширяет расписание и план прототипирования. А тестирование, проводящееся в течение всего процесса, также является непременной частью этого этапа и включается в процесс анализа прототипа сразу после того, как прототип будет построен. Протокол испытания также будет использован для анализа прототипа и создания документа анализа. Ниже представлена диаграмма данного процесса.

Dynamic Systems Development Method (DSDM)
Диаграмма создания функциональной модели.
Act Поддействие Description
Определение функционального прототипа Анализ требований Требования к текущему прототипу анализируются согласно списку требований, созданному ранее (в предыдущей итерации и/или стадии).
Список требований на текущую итерацию Выбор функциональных требований, которые будут реализованы в прототипе на текущей итерации, и создание списка функциональных требований.
Список нефункциональных требований Формирование списка нефункциональных требований к системе.
Создание функциональной модели Анализ кода модели и прототипа и создание функциональной модели.
Согласование планов Определение времени Определение возможного расписания проведения работ по прототипированию согласно с планом и стратегией прототипирования.
Составить план разработки Создание плана прототипирования, включающий все работы по прототипированию, которые будут выполнены во временные интервалы согласно графику.
Matching Согласованный график того, как и в какие сроки будут выполнены все работы по прототипированию.
Создание функционального прототипа Исследование Исследование требований; анализ функциональной модели и разработка плана реализации на основе проведённого анализа. Результаты будут использованы для построения прототипа в следующем поддействии.
Improvement Реализация функциональной модели и плана реализации для построения функционального прототипа. Затем этот прототип будет улучшен прежде, чем объединить его с другими функциями. Прототип доводится до необходимого качества, чтобы потом включить в готовую систему.
Union Объединение улучшенного функционального прототипа с прототипом, разработанным на предыдущей итерации. Полученный прототип будет протестирован в следующем действии.
Анализ функционального прототипа Тестирование прототипа Непременная часть метода DSDM, которая должна присутствовать на протяжении всего процесса. Протокол испытаний совместно с комментариями пользователей будет использован для создания документа анализа прототипа на следующей стадии.
Анализ прототипа Собираются комментарии пользователей и документация. Они будут играть важную роль при разработке документа анализа прототипа. На основе этого документа будет проведено обновление списка требований и протокол возможных рисков, а также будет принято решение проводить или нет ещё одной итерации стадии создания функциональной модели.

Ещё о DSDM

Основные методики DSDM

  • Тайм-боксинг
    Тайм-боксинг - одна из основных методик DSDM. Она используется, чтобы достичь главных целей DSDM - разработать информационную систему в сроки, уложиться в бюджет и при этом сохранить качество. Основная идея тайм-боксинга - разделить весь проект на части, каждая со своим бюджетом и сроками выполнения. Для каждой такой части выбираются требования, которые были распределены по принципу MoSCoW. Так как время и бюджет фиксированы, единственнное, что можно поменять, - это требования. Так, если проект выбивается из графика или выходит за рамки бюджета, требования с наименьшим приоритетом опускаются. Это не означает, что получится неготовый продукт. Исходя из принципа 20/80 80% проекта получается из 20% требований. Поэтому, как только эти самые важные 20% требований реализованы в системе, она удовлетворяет экономическими требованиям. Стоит заметить, что ни одна система не была идеально построена с первого раза.
  • MoSCoW
    Метод MoSCoW предоставляет путь распределения объектов по приоритетам. В контексте DSDM метод MoSCoW используется для распределения по приоритетам требования. Эта аббревиатура расшифровывается так:

MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.

SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.

COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.

WON'T - МОЖНО ли отложить выполнение требования, если ещё есть время.

  • Prototyping
    Эта методика относится к созданию прототипов системы во время разработки на ранних этапах. Она позволяет выявить недостатки в системе и позволяет будущим пользователям протестировать её. Таким образом реализовано вовлечение пользователя в работу - один из ключевых факторов успеха метода DSDM.
  • Testing
    Третья важная сторона достижения цели DSDM - создать информационную систему высокого качества. Чтобы этого добиться, метод DSDM настаивает на проведении тестирования на каждой итерации. Команда проекта вольна сама выбирать способ управления тестированием.
  • Working group
    Эта одна из методик DSDM, цель которой - собрать вместе различных участников проекта, чтобы обсудить требования, функциональность и наладить взаимопонимание. Участники каждой рабочей группы собираются вместе, чтобы обсудить проект.
  • Modeling
    Эта методика обязательна и используется с целью визуализировать в виде диаграмм отдельную сторону системы или сферы деятельности, над которыми идёт работа. Моделирование даёт лучшее понимание всей проектной команде сферы деловой активности проекта.
  • Управление конфигурацией
    Хорошая реализация методики управления конфигурацией важна из-за динамической природы DSDM. Так как во время процесса разработки системы происходит множество различных событий и продукты зачастую выпускаются довольно часто, продуктам требуется строгий контроль, чтобы они успешно производились.

Роли в DSDM

  • Исполнительный спонсор/продюсер или по-другому Чемпион проекта. Очень важная роль. У него есть возможность и обязанность распоряжаться фондами и ресурсами. У этой роли также есть полное право принимать решения.
  • Провидец Это тот, кто запускает проект в работу и находит первые основные требования. У провидца самое точное понимание коммерческих целей системы и проекта.
  • Представительный пользователь Представляет пользователей в проекте. Отвечает за то, чтобы разработчики получали достаточное число отзывов пользователей во время процесса разработки.
  • Пользователь-консультант Может быть любой пользователь, который представляет важную точку зрения на проект и привносит в проект знание по некоторой стороне использования продукта.
  • Менеджер проекта Может быть из сообщества пользователей или из области информационных технологий. Обеспечивает общее руководство проектом.
  • Технический координатор Ответственный за разработку архитектуры системы и контролирует качество проекта.
  • Team Leader Leads the development team and ensures its efficient operation.
  • Developer Analyzes system requirements and models it. This involves writing code and prototyping ..
  • Tester Verifies the health of the project from the technical side, conducting tests. Makes comments and documentation.
  • Secretary Responsible for collecting and recording requirements, agreements and decisions made in each working group.
  • Broker Manages Workgroups.
  • Other roles: Business Architect, Quality Manager, System Integration Specialist, etc.

Iterative and incremental nature of DSDM

In addition to time-boxing and prioritizing requirements, DSDM also uses an iterative and incremental approach to building information systems.

The stage of creating a functional model, the stage of design and development, and the stage of implementation can go through their sub-stages many times before moving on to the next stage. At each iteration, new functions are considered and each current iteration is based on the previous one. And if required, each iteration can be left unfinished.

For example, if many new and useful functions were discovered during development, but they cannot be implemented, then you can start a project by re-drafting new requirements at the stage of economic feasibility study. Or, on the contrary, some functions may be omitted due to limited budget or time. The project can enter the post-project stage only when all the requirements have been met.

Due to the iterative nature of DSDM, there is a proper management of requirements and configuration throughout the entire project. This ensures the implementation of all requirements set in the early stages of the project.

Factors necessary for the success of the DSDM method

Within DSDM, there are the following factors that influence the success of a project.

  • The first is the adoption of the DSDM methodology by management and all employees. This ensures the motivation of all participants since the launch of the project and their subsequent involvement.
  • The second factor follows from the first - the readiness of the management to ensure the involvement of the end users in the work on the project. The prototyping process requires a lot of user involvement in testing and evaluating functional prototypes.
  • The third is the project team. It should consist of experienced members and eventually become a permanent association. An important problem is trust and mutual understanding in the project team. This means that the team has the right and the ability to make important decisions about the project without formal agreement with the management, which could take a lot of time. In order for the team to work successfully on the project, it needs the necessary means - development environment, tools for project management, etc.
  • Fourth. DSDM favors a supportive relationship between the developer and the buyer. This applies to projects that are developed within the companies themselves, as well as using third-party contractors.

Comparison with other methods of developing information systems

Already, many methods of developing information systems have been developed and applied. For example, Structured Systems Analysis and Design Method (SSADM), RAD rapid application development methods, OOP methods. Most of these methods are similar to each other and DSDM.

The extremal programming method also uses an iterative approach to the development of information systems involving users.

The Rational Unified Process method — the most similar to DSDM — is also a dynamic method for developing information systems. And again, it takes an iterative approach to development.

There are other methods that may seem similar to DSDM, but there are a number of differences. First, it provides the necessary tools and development methods. This allows users in a special way to complement the development process with their own methods and help in making decisions. Another unique feature - you can not change the time or development tools, and the requirements for the project. This approach ensures the achievement of the main goals of DSDM - to meet the time and not to go beyond the budget. And the last is mutual understanding and communication between all participants and their involvement in the project.

see also

  • Lean software development
  • Flexible development methodology
  • Pareto's Law
  • Iterative development
  • Extreme Programming
  • PRINCE2
  • RAD (programming)
  • Rational Unified Process
  • Scrum

Links

  • DSDM Consortium Website

Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Web site or software design

Terms: Web site or software design