Метод разработки динамических систем

Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) В этой статье слишком много ссылок на первоисточники . Пожалуйста, улучшите это, добавив вторичные или третичные источники . ( Март 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Метод разработки динамических систем»  -  новости  · газеты  · книги  · ученый  · JSTOR ( октябрь 2008 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

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

Dsdm фиксирует стоимость, качество и время в начале и использует МОСКВУ приоритизацию из сферы в сусле , долженствований , Coulds и не будет имущим регулировать поставки проекта для удовлетворения заявленного ограничения времени. 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 году ассоциацией производителей и специалистов в области программной инженерии и была создана с целью «совместной разработки и продвижения независимой базы РАУ» путем объединения их передового опыта опытом. Истоки были мероприятием, организованным 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. Продемонстрировать контроль

Основные методы [ править ]

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

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

Роли [ править ]

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

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

Критические факторы успеха [ править ]

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

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

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

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

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

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

См. Также [ править ]

• Бережливая разработка программного обеспечения
• Гибкая разработка программного обеспечения

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Коулман и Вербругген: качественный программный процесс для быстрой разработки приложений , Software Quality Journal 7, p. 107-1222 (1998)
• Бейнон-Дэвис и Уильямс: распространение методов разработки информационных систем , Журнал стратегических информационных систем 12 стр. 29–46 (2003)
• Sjaak Brinkkemper , Saeki и Harmsen: методы сборки для разработки методов , Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
• Абрахамссон, Сало, Ронкайнен, Гибкие методы разработки программного обеспечения Warsta : обзор и анализ , Публикации VTT 478, стр. 61–68 (2002)
• Таффс, Стэплтон, Уэст, Исон: Взаимодействие DSDM с Rational Unified Process , Консорциум DSDM, Выпуск 1, стр. 1-29 (1999)
• Ритманн: DSDM с высоты птичьего полета , Консорциум DSDM, стр. 3-8 (2001)
• Крис Барри, Киран Конбой, Майкл Лэнг, Грегори Войтковски и Вита Войтковски: Разработка информационных систем: проблемы на практике, теория и образование, Том 1
• Кейт Ричардс: Гибкое управление проектами: выполнение проектов PRINCE2 с DSDM Atern, TSO (2007)
• Справочник DSDM Atern (2008)
• Справочник по DSDM Agile Project Framework (2014)
• DSDM Agile Project Management Framework (v6, 2014) интерактивная интеллектуальная карта

Внешние ссылки [ править ]

Викискладе есть медиафайлы по теме метода разработки динамических систем .

• Консорциум Agile Business (ранее Консорциум DSDM)
• Вики по AgilePM