Метод разработки динамических систем ( DSDM ) — это гибкая структура поставки проектов, изначально использовавшаяся в качестве метода разработки программного обеспечения . [1] [2] Впервые выпущенный в 1994 году, DSDM изначально стремился обеспечить некоторую дисциплину для метода быстрой разработки приложений (RAD). [3] В более поздних версиях DSDM Agile Project Framework был пересмотрен и стал общим подходом к управлению проектами и поставке решений, а не был сосредоточен конкретно на разработке программного обеспечения и создании кода [ необходимо разъяснение ] [ необходима ссылка ] и мог использоваться для неИТ-проектов. [4] DSDM Agile Project Framework охватывает широкий спектр мероприятий на протяжении всего жизненного цикла проекта и включает в себя прочные основы и управление, которые отличают его от некоторых других Agile-методов. [5] DSDM Agile Project Framework — это итеративный и инкрементальный подход, который охватывает принципы Agile-разработки, включая постоянное вовлечение пользователей/клиентов.
DSDM фиксирует стоимость, качество и время на начальном этапе и использует приоритезацию MoSCoW по объему работ на «должен» , «следует» , «мог бы» и «не должен», чтобы скорректировать результаты проекта для соответствия установленным временным ограничениям. DSDM — один из множества гибких методов разработки программного обеспечения и неИТ-решений, являющийся частью Agile Alliance.
В 2014 году DSDM выпустила последнюю версию метода в «DSDM Agile Project Framework». В то же время новое руководство DSDM признало необходимость работы вместе с другими фреймворками для предоставления услуг (в частности, ITIL ), PRINCE2 , Managing Successful Programmes и PMI. [6] Предыдущая версия (DSDM 4.2) содержала только руководство по использованию DSDM с экстремальным программированием .
История
В начале 1990-х годов быстрая разработка приложений (RAD) распространялась по всей ИТ-индустрии. Пользовательские интерфейсы для программных приложений переходили от старых зеленых экранов к графическим пользовательским интерфейсам, которые используются сегодня. На рынке появлялись новые инструменты разработки приложений, такие как PowerBuilder . Они позволяли разработчикам гораздо легче делиться своими предлагаемыми решениями со своими клиентами — прототипирование стало реальностью, и разочарования классических последовательных ( водопадных ) методов разработки можно было оставить в стороне.
Однако движение RAD было очень неструктурированным: не было общепринятого определения подходящего процесса, и многие организации придумали свое собственное определение и подход. Многие крупные корпорации были очень заинтересованы в возможностях, но они также были обеспокоены тем, чтобы не потерять уровень качества в конечных результатах, которые могла бы дать разработка свободного потока
Консорциум DSDM был основан в 1994 году ассоциацией поставщиков и экспертов в области разработки программного обеспечения и был создан с целью «совместной разработки и продвижения независимой среды RAD» путем объединения их передового опыта. Истоки были заложены на мероприятии, организованном Butler Group в Лондоне. Все участники той встречи работали в таких авторитетных организациях, как British Airways, American Express, Oracle и Logica (другие компании, такие как Data Sciences и Allied Domecq, с тех пор были поглощены другими организациями).
В июле 2006 года DSDM Public Version 4.2 [7] стала доступна для просмотра и использования частными лицами; однако любой, кто перепродает DSDM, должен быть членом некоммерческого консорциума.
В 2014 году руководство DSDM стало доступно онлайн и публично. [8] Кроме того, можно загрузить шаблоны для DSDM. [9]
В октябре 2016 года консорциум DSDM был переименован в Agile Business Consortium (ABC). [10] Agile Business Consortium — это некоммерческая, независимая от поставщиков организация, которая владеет и администрирует фреймворк DSDM. [11]
Описание
DSDM — это независимый от поставщика подход, который признает, что больше проектов терпят неудачу из-за проблем с людьми, чем из-за технологий. DSDM фокусируется на том, чтобы помочь людям эффективно работать вместе для достижения бизнес-целей. DSDM также независим от инструментов и методов, что позволяет использовать его в любой деловой и технической среде без привязки бизнеса к конкретному поставщику. [8]
Принципы
В основе DSDM лежат восемь принципов. [12] Эти принципы направляют команду в отношении того, какое отношение она должна занять и какой образ мышления она должна принять для последовательного выполнения задач.
Сосредоточьтесь на потребностях бизнеса
Доставить вовремя
Сотрудничать
Никогда не идите на компромисс с качеством
Строить постепенно, на прочном фундаменте
Разрабатывать итеративно
Общайтесь непрерывно и четко
Демонстрировать контроль
Основные методы
Timeboxing : подход к поэтапному завершению проекта путем его разбиения на части, каждая из которых имеет фиксированный бюджет и дату поставки. Для каждой части ряд требований расставляются по приоритетам и выбираются. Поскольку время и бюджет фиксированы, единственными оставшимися переменными являются требования. Таким образом, если проект выходит за рамки времени или денег, требования с самым низким приоритетом исключаются. Это не означает, что поставляется незавершенный продукт, поскольку принцип Парето гласит, что 80% проекта исходит из 20% системных требований, поэтому, пока эти самые важные 20% требований реализованы в системе, система, следовательно, отвечает потребностям бизнеса, и ни одна система не создается идеально с первой попытки.
MoSCoW : это метод определения приоритетов рабочих элементов или требований. Это аббревиатура, которая означает:
Должен иметь
Должен был иметь
Мог бы иметь
Не будет иметь
Прототипирование: относится к созданию прототипов разрабатываемой системы на ранней стадии проекта. Это позволяет обнаружить недостатки в системе на ранней стадии и позволяет будущим пользователям провести «тест-драйв» системы. Таким образом, реализуется хорошее вовлечение пользователей, один из ключевых факторов успеха DSDM или любого проекта по разработке системы в этом отношении.
Тестирование: помогает обеспечить решение хорошего качества, DSDM рекомендует проводить тестирование на протяжении каждой итерации. Поскольку DSDM — это независимый от инструментов и методик метод, команда проекта может свободно выбирать собственный метод управления тестированием.
Семинар: объединяет заинтересованных лиц проекта для обсуждения требований, функциональности и взаимопонимания.
Моделирование : помогает визуализировать бизнес-область и улучшить понимание. Создает схематическое представление конкретных аспектов системы или бизнес-области, которая разрабатывается.
Управление конфигурацией : поскольку одновременно разрабатывается несколько продуктов, которые поставляются поэтапно в конце каждого временного интервала, необходимо обеспечить эффективное управление продуктами вплоть до их завершения.
Роли
В среде DSDM введены некоторые роли. Важно, чтобы участники проекта были назначены на разные роли до начала проекта. Каждая роль имеет свою собственную ответственность. Роли следующие:
Исполнительный спонсор : Так называемый чемпион проекта . Важная роль от организации-пользователя, которая имеет возможность и ответственность выделять соответствующие средства и ресурсы. Эта роль имеет окончательные полномочия для принятия решений.
Visionary : Тот, кто несет ответственность за инициализацию проекта, гарантируя, что основные требования будут найдены на ранней стадии. Visionary имеет наиболее точное представление о бизнес-целях системы и проекта. Другая задача — контролировать и поддерживать процесс разработки в правильном направлении.
Пользователь-амбассадор : привносит знания сообщества пользователей в проект, обеспечивает получение разработчиками достаточного количества отзывов пользователей в процессе разработки.
Пользователь-консультант : может быть любым пользователем, представляющим важную точку зрения и привносящим ежедневные знания о проекте.
Менеджером проекта может быть любой человек из сообщества пользователей или ИТ-персонала, который управляет проектом в целом.
Технический координатор : отвечает за проектирование архитектуры системы и контролирует техническое качество проекта.
Руководитель группы : руководит своей командой и обеспечивает эффективную работу команды как единого целого.
Разработчик решений : интерпретация системных требований и их моделирование, включая разработку поставляемых кодов и создание прототипов.
Тестер решения : проверяет правильность в технической части, выполняя некоторые тесты, выявляя дефекты, где это необходимо, и повторно тестируя после исправления. Тестер должен будет предоставить некоторые комментарии и документацию.
Писец : отвечает за сбор и запись требований, соглашений и решений, принятых на каждом семинаре.
Фасилитатор : отвечает за управление ходом семинаров, выступает в качестве мотиватора для подготовки и общения.
Специализированные роли : бизнес-архитектор, менеджер по качеству, системный интегратор и т. д.
Критические факторы успеха
В рамках DSDM определен ряд факторов, имеющих большое значение для обеспечения успешности проектов.
Фактор 1: Во-первых, это принятие DSDM высшим руководством и другими сотрудниками. Это гарантирует, что различные участники проекта мотивированы с самого начала и остаются вовлеченными в течение всего проекта.
Фактор 2: Непосредственно вытекает из фактора 1: Приверженность руководства обеспечению вовлеченности конечного пользователя. Подход к прототипированию требует сильного и преданного вовлечения конечных пользователей для тестирования и оценки функциональных прототипов.
Фактор 3: Команда проекта должна состоять из опытных участников, которые образуют стабильный союз. Важным вопросом является наделение команды проекта полномочиями. Это означает, что команда (или один или несколько ее участников) должны обладать полномочиями и возможностями принимать важные решения относительно проекта без необходимости писать формальные предложения высшему руководству, что может быть очень трудоемким. Для того чтобы команда проекта могла успешно запустить проект, ей также нужны соответствующие технологии для его выполнения. Это означает среду разработки, инструменты управления проектами и т. д.
Фактор 4: Наконец, DSDM также утверждает, что необходимы поддерживающие отношения между заказчиком и поставщиком. Это касается как проектов, реализуемых внутри компаний, так и внешних подрядчиков. Помощью в обеспечении поддерживающих отношений может стать ISPL .
Как и DSDM, они обладают следующими характеристиками:
Все они расставляют приоритеты в требованиях и работают над ними итеративно, создавая систему или продукт поэтапно.
Они являются инструментально-независимыми фреймворками. Это позволяет пользователям заполнять конкретные этапы процесса собственными методами [5] и программными средствами по выбору.
Переменными в разработке являются не время/ресурсы, а требования. Такой подход обеспечивает основные цели DSDM, а именно, соблюдение сроков и бюджета.
Сильный акцент на коммуникации и вовлечении всех заинтересованных сторон в систему. Хотя это рассматривается в других методах, DSDM твердо верит в приверженность проекту для обеспечения успешного результата.
^ Кит Ричардс, Agile project management: running PRINCE2 projects with DSDM Atern. OGC – Office of Government Commerce. The Stationery Office, 31 июля 2007 г.
^ Плонка, Лора и др. «UX-дизайн в Agile: исследование случая DSDM». Agile-процессы в программной инженерии и экстремальном программировании. Springer International Publishing, 2014. 1-15.
^ Абрахамссон, Пекка и др. «Новые направления в гибких методах: сравнительный анализ. Архивировано 24 октября 2018 г. в Wayback Machine ». Программная инженерия, 2003 г. Труды. 25-я международная конференция по. IEEE, 2003.
^ Стэплтон, Дженнифер (январь 2003 г.). Развитие, ориентированное на бизнес . Pearson Education. стр. 113. ISBN 9780321112248.
^ ab Moran, Alan (март 2015 г.). Managing Agile . Springer. стр. 21–24. ISBN9783319162614.
^ Руководство по фреймворку Agile Project Framework DSDM, 2014 г., стр. 4, 16.
^ (www.dsdm.org Архивировано 2016-10-02 на Wayback Machine )
^ ab "DSDM Agile Project Framework (2014 Onwards)". Agile Business Consortium . 4 февраля 2016 г.
^ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set .{{cite web}}: Отсутствует или пусто |title=( помощь )
^ "Консорциум Agile DSDM превращается в Agile Business Consortium". Press Dispensary .
^ "Условия и положения членства в сообществе" (PDF) . GLOBAL GAP
^ Agile Business Consortium. Руководство по фреймворку Agile Project Framework (начиная с 2014 г.) – Принципы.
Дальнейшее чтение
Коулман и Вербрюгген: Качественный процесс разработки программного обеспечения для быстрой разработки приложений , Журнал качества программного обеспечения 7, стр. 107-1222 (1998)
Бейнон-Дэвис и Уильямс: Распространение методов разработки информационных систем , Журнал стратегических информационных систем 12 стр. 29-46 (2003)
Sjaak Brinkkemper , Saeki и Harmsen: Методы сборки для проектирования методов , Advanced Information Systems Engineering, Труды CaiSE'98, Springer Verlag (1998)
Абрахамссон, Сало, Ронкайнен, Варста Методы гибкой разработки программного обеспечения: обзор и анализ , VTT Publications 478, стр. 61-68 (2002)
Таффс, Стэплтон, Уэст, Исон: Взаимодействие DSDM с Rational Unified Process , DSDM Consortium, выпуск 1, стр. 1-29 (1999)
Ритман: DSDM с высоты птичьего полета , Консорциум DSDM, стр. 3-8 (2001)
Крис Барри, Киран Конбой, Майкл Лэнг, Грегори Войтковски и Вита Войтковски: Разработка информационных систем: проблемы практики, теории и образования, том 1
Кит Ричардс: Agile Project Management: запуск проектов PRINCE2 с DSDM Atern, TSO (2007) Архивировано 23 января 2021 г. на Wayback Machine
