DSDM

Существует 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, наличествует должное управления требованиями и конфигурацией на протяжении всего проекта. Это обеспечивает реализацию всех требований, поставленных на ранних стадиях проекта.