Динамические системы метод разработки

редактировать
Модель метода управления проектами DSDM Atern.

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

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

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

Содержание

  • 1 История DSDM
  • 2 DSDM Atern
    • 2.1 Принципы
    • 2.2 Основные методы
    • 2.3 Роли
    • 2.4 Критические факторы успеха
  • 3 Сравнение с другими средами разработки
  • 4 См. Также
  • 5 Ссылки
  • 6 Дополнительная литература
  • 7 Внешние ссылки

История DSDM

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

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

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

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

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

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

DSDM Atern

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

Принципы

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

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

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

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

Роли

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

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

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

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

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

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

DSDM можно рассматривать как часть широкого спектра итеративных и инкрементных сред разработки, особенно тех, которые поддерживают Agile и объектно-ориентированные методы. К ним относятся (но не ограничиваются ими) Scrum, Extreme Programming (XP), Discipeled Agile Delivery (DAD) и Rational Unified Process ( RUP).

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

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

См. Также

Ссылки

Далее чтение

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

На Викискладе есть материалы, связанные с Методом разработки динамических систем.
Последняя правка сделана 2021-05-18 07:27:55
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте