DSDM

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) - это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). DSDM - это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.

Цель метода - сдать готовый проект вовремя и уложиться в бюджет, но в то же время регулируя изменения требований к проекту во время его разработки. DSDM входит в семейство гибкой методологии разработки программного обеспечения, а также разработок не входящих в сферу информационных технологий.

Самая последняя версия DSDM называется DSDM Atern. Название Atern - это сокращение от Arctic Tern (пер. Полярная крачка). Полярная крачка - птица, которая может путешествовать на большие расстояния. Она символизирует множество аспектов метода, например определение приоритета или кооперирование, которые являются естественным способом ведения рабочего процесса.

Предыдущая версия DSDM (выпущенная в мае 2003 года), которая всё ещё действует и широко используется, - это DSDM 4.2, являющаяся немного расширенной версией DSDM 4. Расширенная версия содержит руководство по тому, как использовать DSDM совместно с Экстремальным программированием (Extreme Programming).

В 2007 году команда, созданная Консорциумом DSDM, исследовала суть метода и решила, что основные механизмы и структура написаны хорошо, но терминология и внимание метода были полностью сфокусированы на области информационных технологий. Поэтому они должны быть усовершенствованы, чтобы отвечать нуждам проектов в новом тысячелетии (часть метода была неизменна с 1995 года). Новая версия была выпущена 24 апреля 2007 года в Cafe Royale в Лондоне.

Как расширение концепции быстрой разработки приложений, DSDM фокусируется на проектах информационных систем, характеризующихся сжатыми сроками и бюджетами. В DSDM присутствуют указания на типичные ошибки проектов информационных систем, таких как превышение бюджета, опоздание со сроками сдачи (исполнения), недостаточное вовлечение пользователей и топ-менеджеров в работу над проектом. DSDM состоит из:

• трёх стадий: предпроектная, стадия жизненного цикла проекта и постпроектная стадия
• стадия жизни проекта состоит из 5 этапов: исследование реализуемости, исследование экономической целесообразности, создание функциональной модели, проектирование и разработка, этап реализации

При некоторых условиях существует возможность включения в DSDM частей других методик, таких как Rational Unified Process (RUP), Экстремальное программирование, PRINCE2. Другой гибкий метод, похожий на DSDM по процессу и концепции - Scrum.

Метод DSDM был разработан в Великобритании в 1990-х Консорциумом DSDM. Консорциум DSDM - это ассоциация разработчиков и экспертов в области программного обеспечения, созданная с целью "совместной разработки и продвижения независимого фреймворка RAD" комбинированием лучшего практического опыта участников ассоциации. Консорциум DSDM - это некоммерческая организация независимых разработчиков, которые владеют и управляют фреймворком DSDM. Первая версия фреймворка была завершена в январе 1995 года и опубликована в феврале 1995 года. В июле 2006 года была представлена открытая версия DSDM 4.2, которая стала доступна частным лицам для просмотра и использования. Тем не менее, все, кто распространяет DSDM, должны быть членами этого некоммерческого консорциума.

В начале 1990-х в индустрии информационных технологий стал распространяться новый термин - быстрая разработка приложений (Rapid Application Development, RAD). Пользовательские интерфейсы прикладных программ эволюционировали от старых зелёных экранов до графических интерфейсов пользователя, которые используются и сейчас. На рынок начали выходить новые инструменты для создания приложений, например PowerBuilder. Они позволили разработчикам проще делиться планируемыми разработками с покупателями - появилось прототипирование и началось разрушение классических, последовательностных (каскадных) методов разработки.

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

Консорциум DSDM был образован в 1994 году, когда группа людей встретилась на мероприятии, организованном Butler Group в Лондоне. Все, кто пришёл на это мероприятие, работали в крупных организациях, таких как British Airways, American Express, Oracle and Logica (такие компании как Data Sciences и Allied Domecq с тех пор были поглощены другими организациями).

На этом собрании было решено, что Дженнифер Степлтон, тогда представлявшая компанию Logica, разработает архитектуру комплексного, ориентированного на пользователя метода с хорошим контролем качества для итеративной и инкрементной разработки. Итоговая архитектура была спроектирована так, чтобы быть полностью совместимой со стандартом ISO 9000 и PRINCE2. Когда архитектура была готова (через месяц после собрания), Консорциум сформировал группы для её распространения во всех областях разработки программного обеспечения, которые включали в себя: методы и средства управления проектом, контроль качества и тестирование, методы и средства разработки. Контрольная группа, возглавляемая создателем архитектуры и состоящая из глав этих групп, должна была обеспечить понимание метода так, как он первоначально задумывался.

Несмотря на то, что многие члены Консорциума были прямыми конкурентами, они свободно делились тем, как они решают возникающие проблемы. Практика показала, что наилучший результат может быть достигнут только работая как одно целое. Консорциум увеличился - за первый год от нескольких организаций до шестидесяти; описание метода становилось всё более и более полным. Версия 1 была сформирована в декабре 1994 года и опубликована в феврале 1995 года. Результатом стал универсальный метод, охватывающий людей, процессы и инструменты. Он сформировался на основе опыта организаций, различных по роду своей деятельности и размерам.

Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

• Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
• Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
• Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
• Главный критерий - как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
• Разработка - итеративная и инкрементальная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
• Любые изменения во время разработки - обратимы.
• Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
• Тестирование интегрировано в жизненный цикл разработки.
• Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

Чтобы успешно использовать DSDM, необходимо чтобы был выполнен ряд предпосылок. Во-первых, необходимо организовать взаимодействие между проектной командой, будущими пользователями и высшим руководством. Во-вторых, должна присутствовать возможность разбиения проекта на меньшие части, что позволит использовать итеративный подход.

Два примера проектов, для которых DSDM не очень подходит:

• проекты, критичные по безопасности - расширенное тестирование и утверждение в таких проектах конфликтуют с целью метода DSDM уложиться в сроки и в бюджет.
• проекты, чья цель произвести компоненты многоразового использования - требования в таких проектах слишком высоки и не укладываются в принцип 20/80.

Фреймворк DSDM состоит из трёх последовательных стадий, которые называются предпроектная стадия, стадия жизненного цикла проекта и постпроектная стадия. Стадия жизненного цикла проекта - самая продуманная и детально разработанная из всех остальных. Она состоит из пяти этапов, которые формируют итеративный, инкрементный подход к разработке информационных систем. Эти три фазы и соответствующие этапы будут более подробно описаны в последующих разделах. Для каждой стадии или этапа будут рассмотрены самые важные функции и будут представлены результаты.

Стадия 1 - Предпроектная

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

Стадия 2 - Жизненный цикл проекта

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

Стадия 3 - Постпроектная

На этой стадии обеспечивается эффективная работа системы. Это достигается за счёт поддержания проекта, его улучшения и исправления ошибок согласно принципам DSDM. Поддержка проекта осуществляется продолжением разработки, основанной на итеративной и инкрементной природе DSDM. Вместо того, чтобы закончить проект за один цикл, обычно возвращаются к предыдущим стадиям или этапам, чтобы улучшить продукт.

Ниже на диаграмме представлен весь жизненный цикл проекта. Эта диаграмма описывает итеративную разработку DSDM. Описание каждого этапа будет представлено ниже.

В течение этого этапа, проверяется реализуемость проекта в рамках DSDM. Предпосылки для использования DSDM проверяются ответом на вопросы: «Может ли данный проект удовлетворить необходимым экономическим требованиям?», «Проект подходит для использования метода DSDM?» и «Какие риски в этом проекте самые важные?». Наиболее важный метод на этом этапе - использование рабочих групп.

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

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

Для создания этого плана применяется очень важная для проекта методика - тайм-боксинг. Эта методика обязательна для достижения целей DSDM - уложится в сроки и в бюджет, и при этом сохранить необходимое качество продукта. Архитектура системы - ещё одно подспорье в управлении разработкой информационной системы. Итогом данного этапа является описание сферы коммерческой деятельности, в котором содержится context of the project within the company, описание архитектуры системы, предоставляющее первоначальную глобальную архитектуру информационной системы, находящейся в разработке, и план разработки, котором обозначены наиболее важные шаги в процессе разработки. В основе этих двух документов лежит список требований. Протокол возможных рисков дополняется данными, полученными на этом этапе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Исполнительный спонсор/продюсер или по-другому Чемпион проекта. Очень важная роль. У него есть возможность и обязанность распоряжаться фондами и ресурсами. У этой роли также есть полное право принимать решения.
• Провидец Это тот, кто запускает проект в работу и находит первые основные требования. У провидца самое точное понимание коммерческих целей системы и проекта.
• Представительный пользователь Представляет пользователей в проекте. Отвечает за то, чтобы разработчики получали достаточное число отзывов пользователей во время процесса разработки.
• Пользователь-консультант Может быть любой пользователь, который представляет важную точку зрения на проект и привносит в проект знание по некоторой стороне использования продукта.
• Менеджер проекта Может быть из сообщества пользователей или из области информационных технологий. Обеспечивает общее руководство проектом.
• Технический координатор Ответственный за разработку архитектуры системы и контролирует качество проекта.
• Лидер команды Возглавляет команду разработки и обеспечивает её эффективную работу.
• Разработчик Анализирует требования к системе и моделирует её. Это подразумевает написание кода и создание прототипов..
• Тестировщик Проверяет исправность проекта с технической стороны, проводя тесты. Составляет комментарии и документацию.
• Секретарь Отвечает за сбор и запись требований, соглашений и решений, принятых в каждой рабочей группе.
• Посредник Управляет рабочими группами.
• Другие роли Бизнес-архитектор, менеджер по качеству, специалист по системной интеграции и т.д.

Кроме тайм-боксинга и распределения требований по приоритетам метод DSDM также использует итеративный и инкрементный подход к созданию информационных систем.

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

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

Благодаря итеративной природе DSDM, наличествует должное управления требованиями и конфигурацией на протяжении всего проекта. Это обеспечивает реализацию всех требований, поставленных на ранних стадиях проекта.

В рамках DSDM существуют следующие факторы, которые влияют на успех проекта.

• Первое - принятие методики DSDM руководством и всеми работниками. Это обеспечивает мотивацию всех участников с момента запуска проекта и их последующую вовлечённость.
• Второй фактор следует из первого - готовность руководства обеспечить вовлечённость конечных пользователей в работу над проектом. Процесс прототипирования требует большой вовлечённости пользователей в тестирование и оценивание функциональных прототипов.
• Третье - проектная команда. Она должна состоять из опытных членов и в итоге стать постоянным объединением. Важная проблема - доверие и взаимопонимание в проектной команде. Это означает, что команда обладает правом и возможностью принимать важные решения о проекте без формального согласования с руководством, что могло бы отнять много времени. Чтобы команда могла успешно работать над проектом, ей нужны необходимые средства - среда разработки, инструменты для управления проектом и т.д.
• Четвёртое. DSDM выступает за благосклонные отношения между разработчиком и покупателем. Это касается проектов, которые разрабатываются внутри самих компаний, а также с использованием сторонних подрядчиков.

Уже было разработано и применено в деле множество методов разработки информационных систем. Например, Structured Systems Analysis and Design Method (SSADM), методы быстрой разработки приложений RAD, методы ООП. Большинство этих методов похожи друг на друга и на DSDM.

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

Метод Rational Unified Process - самый похожий на DSDM, также является динамическим методом разработки информационных систем. И опять же в нём применяется итеративный подход к разработке.

Существуют и другие методы, которые могут показаться похожими на DSDM, но имеющие ряд отличий. Во-первых, он предоставляет необходимые инструменты и способы разработки. Это позволяет пользователям особым образом дополнить процесс разработки своими собственными методами и помочь в принятии решений. Ещё одна уникальная особенность - можно менять не время или средства разработки, а требования к проекту. Такой подход обеспечивает достижение основных целей DSDM - уложиться по времени и не выйти за рамки бюджета. И последнее - взаимопонимание и общение между всеми участниками и их вовлечённость в проект.

• Бережливая разработка программного обеспечения
• Гибкая методология разработки
• Закон Парето
• Итеративная разработка
• Экстремальное программирование
• PRINCE2
• RAD (программирование)
• Rational Unified Process
• Scrum

• Сайт консорциума DSDM