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.
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.
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:
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.
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.
There are 9 principles consisting of 4 basic and 5 starting points.
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:
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.
| 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. |
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.
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.
Требования, которые были определены на предыдущем этапе, превращаются в функциональную модель. Она состоит из действующего прототипа и моделей. Прототипирование - ключевая методика проекта на данном этапе, позволяющая организовать вовлечение пользователей в проект. Разработанный прототип анализируется различными группами пользователей. Чтобы достичь необходимого качества, на каждой итерации применяется тестирование. Самая важная часть тестирования представлена на данном этапе. Создание функциональной модели можно разделить на следующие подэтапы:
Итогом данного этапа являются функциональная модель и функциональный прототип, которые вместе представляют функциональность полученный на этой итерации, готовые для тестирования пользователями. Далее обновляется список требований - из него удаляются уже реализованные пункты и происходит повторное изменение очерёдности оставшихся пунктов. Протокол возможных рисков также обновляется, после анализа функционального прототипа.
Главная задача этой итерации - объединить функциональные компоненты из предыдущего этапа в единую систему, удовлетворяющую требованиям пользователей. Здесь также рассматриваются нефункциональные требования. И снова на данном этапе происходит тестирование. Проектирование и разработку можно разделить на следующие подэтапы:
Итог этапа - создание конструктивного прототипа для тестирования пользователями. Протестированная система переходит на следующий этап. На данном этапе внешний вид и функциональность системы в общем готовы. Ещё один итог - создание пользовательской документации.
На этапе реализации протестированная система вместе с пользовательской документацией доставляется к будущим пользователям и происходит их обучение работы с системой. Система анализируется на соответствие требованиям, поставленных на ранних этапах проекта. Реализацию можно разделить на следующие подэтапы:
Итог этапа: законченная система, пригодная для использования конечными пользователями, контингент обученных пользователей и детальный документ анализа проекта.
Связи между понятиями на этапе создания функциональной модели показаны на модели на рисунке ниже.
| 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. |
Работа по определению функционального прототипа заключается в определении функционала, который будет присутствовать в прототипе на данной итерации. Аналитика и программирование закончено; прототипы собраны; и опыт полученный от них использован для улучшения моделей анализа (а также основывается на обновлённых списке требований и протоколе возможных рисков). Построенные прототипы не выбрасываются, а понемногу доводятся до необходимого качества, чтобы потом включить в готовую систему. Согласованный график работ необходим, чтобы определить когда и в какие сроки будет реализовано прототипирование; он расширяет расписание и план прототипирования. А тестирование, проводящееся в течение всего процесса, также является непременной частью этого этапа и включается в процесс анализа прототипа сразу после того, как прототип будет построен. Протокол испытания также будет использован для анализа прототипа и создания документа анализа. Ниже представлена диаграмма данного процесса.
| Act | Поддействие | Description |
|---|---|---|
| Определение функционального прототипа | Анализ требований | Требования к текущему прототипу анализируются согласно списку требований, созданному ранее (в предыдущей итерации и/или стадии). |
| Список требований на текущую итерацию | Выбор функциональных требований, которые будут реализованы в прототипе на текущей итерации, и создание списка функциональных требований. | |
| Список нефункциональных требований | Формирование списка нефункциональных требований к системе. | |
| Создание функциональной модели | Анализ кода модели и прототипа и создание функциональной модели. | |
| Согласование планов | Определение времени | Определение возможного расписания проведения работ по прототипированию согласно с планом и стратегией прототипирования. |
| Составить план разработки | Создание плана прототипирования, включающий все работы по прототипированию, которые будут выполнены во временные интервалы согласно графику. | |
| Matching | Согласованный график того, как и в какие сроки будут выполнены все работы по прототипированию. | |
| Создание функционального прототипа | Исследование | Исследование требований; анализ функциональной модели и разработка плана реализации на основе проведённого анализа. Результаты будут использованы для построения прототипа в следующем поддействии. |
| Improvement | Реализация функциональной модели и плана реализации для построения функционального прототипа. Затем этот прототип будет улучшен прежде, чем объединить его с другими функциями. Прототип доводится до необходимого качества, чтобы потом включить в готовую систему. | |
| Union | Объединение улучшенного функционального прототипа с прототипом, разработанным на предыдущей итерации. Полученный прототип будет протестирован в следующем действии. | |
| Анализ функционального прототипа | Тестирование прототипа | Непременная часть метода DSDM, которая должна присутствовать на протяжении всего процесса. Протокол испытаний совместно с комментариями пользователей будет использован для создания документа анализа прототипа на следующей стадии. |
| Анализ прототипа | Собираются комментарии пользователей и документация. Они будут играть важную роль при разработке документа анализа прототипа. На основе этого документа будет проведено обновление списка требований и протокол возможных рисков, а также будет принято решение проводить или нет ещё одной итерации стадии создания функциональной модели. |
MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.
SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.
COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.
WON'T - МОЖНО ли отложить выполнение требования, если ещё есть время.
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.
Within DSDM, there are the following factors that influence the success of a project.
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.
Comments
To leave a comment
Web site or software design
Terms: Web site or software design