Метод разработки динамических систем - Dynamic systems development method

Модель метода управления проектами DSDM Atern.
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Метод разработки динамических систем (DSDM) является проворный рамки реализации проекта, первоначально использовавшиеся как метод разработки программного обеспечения.[1][2] Впервые выпущенный в 1994 году, DSDM изначально стремился обеспечить некоторую дисциплину для быстрая разработка приложений (RAD) метод.[3] В более поздних версиях DSDM Agile Project Framework была пересмотрена и стала универсальным подходом к управлению проектами и предоставлением решений, а не была сосредоточена конкретно на разработке программного обеспечения и создании кода.[требуется разъяснение ][нужна цитата ] и может использоваться для проектов, не связанных с ИТ.[4] DSDM Agile Project Framework охватывает широкий спектр действий на протяжении всего жизненного цикла проекта и включает прочную основу и управление, которые отличают ее от некоторых других Agile-методов.[5] DSDM Agile Project Framework - это итеративный и инкрементный подход, который включает принципы гибкой разработки, включая постоянное участие пользователей / клиентов.

DSDM с самого начала фиксирует стоимость, качество и время и использует Приоритезация MoSCoW объема в обязан, должен, мог и не будет для корректировки результатов проекта в соответствии с указанными временными ограничениями. DSDM является одним из множества Гибкие методы для разработки программного обеспечения и решений, не связанных с ИТ, и является частью Agile Alliance.

В 2014 году DSDM выпустила последнюю версию метода в «DSDM Agile Project Framework». В то же время новое руководство по DSDM признало необходимость работать вместе с другими структурами для предоставления услуг (особенно. ITIL ) PRINCE2, Управление успешными программами и PMI.[6] Предыдущая версия (DSDM 4.2) содержала только руководство по использованию DSDM с Экстремальное программирование.

История DSDM

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

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

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

В июле 2006 г. появилась общедоступная версия DSDM 4.2.[7] был доступен для просмотра и использования отдельными лицами; однако любой, кто занимается перепродажей DSDM, должен по-прежнему быть членом некоммерческого консорциума.

В 2014 году справочник DSDM стал доступен в Интернете и стал общедоступным.[8] Дополнительно можно скачать шаблоны для DSDM.[9]

В октябре 2016 года консорциум DSDM был переименован в Agile Business Consortium.[10] Консорциум Agile Business Consortium - это некоммерческая организация, не зависящая от поставщика, которая владеет и администрирует структуру DSDM.[11]

DSDM Atern

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

Принципы

В основе DSDM Atern восемь принципов.[12] Эти принципы направляют команду на то отношение, которое они должны занять, и образ мышления, которого они должны придерживаться для последовательной работы.

  1. Сосредоточьтесь на потребностях бизнеса
  2. Доставить вовремя
  3. Сотрудничать
  4. Никогда не идите на компромисс с качеством
  5. Постройте постепенно на прочном фундаменте
  6. Развивайте итеративно
  7. Общайтесь постоянно и четко
  8. Продемонстрировать контроль

Основные методы

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

Роли

В среду DSDM введены некоторые роли. Важно, чтобы участники проекта были назначены на разные роли до того, как они приступят к проекту. Каждая роль несет свою ответственность. Роли:

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

Критические факторы успеха

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

  • Фактор 1: Во-первых, это принятие DSDM высшим руководством и другими сотрудниками. Это гарантирует, что различные участники проекта будут мотивированы с самого начала и останутся вовлеченными на протяжении всего проекта.
  • Фактор 2: напрямую вытекает из фактора 1: приверженность руководства обеспечению участия конечного пользователя. Подход к созданию прототипов требует активного и целенаправленного участия конечных пользователей для тестирования и оценки функциональных прототипов.
  • Фактор 3: Команда проекта должна состоять из опытных членов, которые образуют стабильный союз. Важным вопросом является расширение прав и возможностей команды проекта. Это означает, что команда (или один или несколько ее членов) должны обладать властью и возможностью принимать важные решения относительно проекта без необходимости писать официальные предложения вышестоящему руководству, что может занять очень много времени. Для того, чтобы команда проекта могла запустить успешный проект, им также необходима соответствующая технология для его реализации. Это означает среду разработки, инструменты управления проектами и т. Д.
  • Фактор 4: Наконец, DSDM также заявляет, что необходимы поддерживающие отношения между заказчиком и поставщиком. Это касается как проектов, которые реализуются внутри компаний, так и внешними подрядчиками. Помощь в обеспечении поддерживающих отношений может быть ISPL.

Сравнение с другими средами разработки

DSDM можно рассматривать как часть широкого спектра итеративных и инкрементальных сред разработки, особенно тех, которые поддерживают проворный и объектно-ориентированный методы. К ним относятся (но не ограничиваются ими) Scrum, Экстремальное программирование (XP), Дисциплинированная гибкая доставка (DAD), и Рациональный унифицированный процесс (RUP).

Как и DSDM, они имеют следующие характеристики:

  • Все они определяют приоритеты требований и работают над ними итеративно, постепенно создавая систему или продукт.
  • Они не зависят от инструментов. Это позволяет пользователям заполнять определенные этапы процесса своими собственными методами.[5] и программные средства выбора.
  • Переменными в разработке являются не время / ресурсы, а требования. Такой подход обеспечивает достижение основных целей DSDM, а именно соблюдение установленных сроков и бюджета.
  • Сильный акцент на коммуникации и вовлечении всех заинтересованных сторон в систему. Хотя это решается другими методами, DSDM твердо верит в приверженность проекту, чтобы обеспечить успешный результат.

Смотрите также

использованная литература

  1. ^ Кейт Ричардс, Гибкое управление проектами: запуск проектов PRINCE2 с помощью DSDM Atern. OGC - Управление государственной торговли. Канцелярия, 31 июл. 2007 г.
  2. ^ Плонка, Лаура и др. «UX-дизайн в Agile: пример использования DSDM». Гибкие процессы в разработке программного обеспечения и экстремальном программировании. Springer International Publishing, 2014. 1-15.
  3. ^ Абрахамссон, Пекка и др. "Новые направления гибких методов: сравнительный анализ. »Программная инженерия, 2003. Труды. 25-я Международная конференция по. ИЭЭЭ, 2003.
  4. ^ Стэплтон, Дженнифер (январь 2003 г.). Бизнес-ориентированное развитие. Pearson Education. п. 113. ISBN  9780321112248.
  5. ^ а б Моран, Алан (март 2015 г.). Управление Agile. Springer. С. 21–24. ISBN  9783319162614.
  6. ^ Руководство DSDM Agile Project Framework, 2014, страницы 4, 16
  7. ^ (www.dsdm.org В архиве 2016-10-02 в Wayback Machine )
  8. ^ а б «Структура проекта DSDM Agile (с 2014 г.)». Консорциум Agile Business. 4 февраля 2016 г.
  9. ^ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set. Отсутствует или пусто | название = (Помогите)
  10. ^ «Консорциум Agile DSDM превращается в Консорциум Agile Business». Пресс-диспансер.
  11. ^ «Условия членства в сообществе» (PDF). Консорциум DSDM. Получено 7 марта 2013.
  12. ^ Консорциум Agile Business. Справочник по структуре проекта DSDM Agile (2014 г. и далее) - Принципы.

дальнейшее чтение

внешние ссылки