Dynamic systems development method dsdm реферат

Обновлено: 05.07.2024

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) - это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений. DSDM - это итеративный и инкрементный подход, который придаёт особоезначение продолжительному участию в процессе пользователя/потребителя.

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

Самая последняя версия DSDMназывается DSDM Atern. Название Atern - это сокращение от Arctic Tern (пер. Полярная крачка). Полярная крачка - птица, которая может путешествовать на большие расстояния. Она символизирует множество аспектов метода, например определение приоритета или кооперирование, которые являются естественным способом ведения рабочего процесса.

Предыдущая версия DSDM (выпущенная в мае 2003 года), которая всё ещё действует ишироко используется, - это DSDM 4.2, являющаяся немного расширенной версией DSDM 4. Расширенная версия содержит руководство по тому, как использовать DSDM совместно с Экстремальным программированием (Extreme Programming).

Обзор DSDM Atern

В 2007 году команда, созданная Консорциумом DSDM, исследовала суть метода и решила, что основные механизмы и структура написаны хорошо, но терминологияи внимание метода были полностью сфокусированы на области информационных технологий. Поэтому они должны быть усовершенствованы, чтобы отвечать нуждам проектов в новом тысячелетии (часть метода была неизменна с 1995 года). Новая версия была выпущена 24 апреля 2007 года в Cafe Royale в Лондоне.

Обзор DSDM версии 4.2

Как расширение концепции быстрой разработки приложений, DSDM фокусируется напроектах информационных систем, характеризующихся сжатыми сроками и бюджетами.В DSDM присутствуют указания на типичные ошибки проектов информационных систем, таких как превышение бюджета, опоздание со сроками сдачи (исполнения), недостаточное вовлечение пользователей и топ-менеджеров в работу над проектом. DSDM состоит из:
трёх стадий: предпроектная, стадия жизненного цикла проекта и постпроектнаястадия
стадия жизни проекта состоит из 5 этапов: исследование реализуемости, исследование экономической целесообразности, создание функциональной модели, проектирование и разработка, этап реализации

При некоторых условиях существует возможность включения в DSDM частей других методик, таких как Rational Unified Process (RUP), Экстремальное программирование, PRINCE2. Другой гибкий метод похожий на DSDMпо процессу и концепции - Scrum.

Метод DSDM был разработан в Великобритании в 1990-х Консорциумом DSDM. Консорциум DSDM - это ассоциация разработчиков и экспертов в области программного обеспечения, созданная с целью "совместной разработки и продвижения независимого фреймворка RAD" комбинированием лучшего практического опыта участников ассоциации. Консорциумом DSDM - это некоммерческаяорганизация независимых разработчиков, которые владеют и управляют фреймворком DSDM. Первая версия фреймворка была завершена в январе 1995 года и опубликована в феврале 1995 года. В июле 2006 года была представлена открытая версия DSDM 4.2, которая стала доступна частным лицам для просмотра и использования. Тем не менее, все, кто распространяет DSDM должны быть членами этого некоммерческого консорциума.

DSDMи Консорциум DSDM - ранние дни

В начале 1990-х в индустрии информационных технологий стал распространятся новый термин - быстрая разработка приложений (Rapid Application Development, RAD). Пользовательские интерфейсы прикладных программ эволюционировали от старых зелёных экранов до графических интерфейсов пользователя, которые используются и сейчас. На рынок.

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

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

Можно привести примеры проектов, для которых использование DSDM не рекомендуется:

 проекты, критичные по безопасности (расширенное тестирование и утверждение в таких проектах конфликтуют с целью метода DSDM уложиться в сроки и в бюджет);

 проекты, чья цель – произвести компоненты многоразового использования (требования в таких проектах слишком высоки).

Жизненный цикл проекта

Согласно DSDM, жизненный цикл ИС состоит из трех последовательных стадий:

Предпроектная стадия

На этой стадии определяются риски проекта, происходит выделение средств и определение проектной команды. Решение задач на этой стадии поможет избежать проблем на более поздних стадиях проекта.

Стадия проекта

Это самая детально разработанная стадия DSDM. Она состоит из пяти этапов, которые формируют итеративный, инкрементный подход к разработке информационных систем:

1. Исследование реализуемости.

2. Исследование экономической целесообразности.

3. Создание функциональной модели.

4. Проектирование и разработка.

5. Этап реализации.

Первые два этапа выполняются последовательно и дополняют друг друга. После их завершения происходит итеративная и инкрементная разработка системы на основе этапов 3–5, выполняемых циклически, вплоть до выпуска готового продукта.

Постпроектная стадия

На этой стадии обеспечивается внедрение и эксплуатация системы. Это достигается за счет поддержания проекта, его улучшения и исправления ошибок согласно принципам DSDM. Поддержка проекта осуществляется как продолжение разработки, основанной на итеративной и инкрементной природе DSDM. Вместо того чтобы закончить проект за один цикл, обычно возвращаются к предыдущим стадиям или этапам, чтобы улучшить продукт.

Факторы, необходимые для успеха метода DSDM

В рамках DSDM существуют следующие факторы, которые влияют на успех проекта:

 принятие методики DSDM руководством проекта и всеми его участниками, что обеспечивает мотивацию членов команды с момента запуска проекта и до его окончания;

 готовность руководства обеспечить вовлеченность конечных пользователей в работу над проектом, включая тестирование и оценивание функциональных прототипов;

 проектная команда должна в итоге стать постоянной, что обеспечивает доверие и взаимопонимание внутри нее. Команда обладает правом и возможностью принимать важные решения о проекте без формального согласования с руководством, что могло бы отнять много времени;

В основе управления процессами в Scrum заложены три главных принципа: прозрачность, инспекция и адаптация. Прозрачность означает, что все значимые аспекты процесса должны быть доступны тем, кто за него отвечает. Прозрачность требует, чтобы эти аспекты определялись общими стандартами, а все члены команды должны пользоваться общими понятиями и терминологией. Инспекции проводятся достаточно часто для своевременного выявления нежелательных отклонений от установленных целей. Однако инспектирование не должно быть настолько частым, чтобы мешать работе. Если по результатам инспекции выявлены отклонения, то необходимо как можно быстрее внести коррекцию в продукт во избежание распространения проблемы на другие части системы.

Методология Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определен наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всем его протяжении. При этом строго фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость.

Спринт – это итерация, в ходе которой создается прирост функциональности программного обеспечения. Спринт жестко фиксирован по времени. Длительность одного спринта составляет от 2 до 6 недель. Считается, что чем короче спринт, тем более гибким является процесс разработки: версии выходят чаще, быстрее поступают отзывы от потребителя. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и др. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку. Предварительная оценка фиксируется в журнале проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенных в журнал спринта.

Журнал продукта

Журнал спринта

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

Диаграмма сгорания задач

Это диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно, с тем чтобы в простой форме показать подвижки в работе над спринтом.

Существуют разные виды диаграммы:  диаграмма сгорания работ для спринта – показывает, сколько задач уже сделано и сколько еще остается сделать в текущем спринте;  диаграмма сгорания работ для проекта – показывает, сколько задач уже сделано и сколько еще остается сделать до выпуска продукта.

Основные роли в методологии Scrum

Проект выполняется группой, в которую входят специалисты, выполняющие следующие роли:

 скрам-мастер (Scrum Master) – проводит совещания, следит за соблюдением всех принципов Scrum, разрешает противоречия и защищает команду от отвлекающих факторов;  владелец продукта (Product Owner)

– представляет интересы конечных пользователей и других заинтересованных в продукте сторон;  скрам-команда (Scrum Team)

– кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д; размер команды в идеале составляет от 5 до 9 человек.

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

1. Грекул, В.И. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М. : Бином, 2010. – С. 300.

2. Коберн, А. Быстрая разработка программного обеспечения / А. Коберн. – М. : Лори, 2013. – С. 314.

3. Кон, М. Пользовательские истории. Гибкая разработка программного обеспечения / М. Кон. – М. : Вильямс, 2012. – С. 256.

4. Кон, М. Scrum: гибкая разработка ПО / М. Кон. – М. : Вильямс, 2011. – С. 576.

5. Ларман, К. Применение UML 2.0 и шаблонов проектирования / К. Ларман. – М. : Вильямс, 2013. – С. 736.

6. Фаулер, М. Рефакторинг. Улучшение существующего кода / М. Фаулер, К. Бек, Дж. Брант [и др.]. СПб. : Символ-Плюс, 2013 – С. 432.

8. Microsoft Corporation. Microsoft Solutions Framework: Гибкая методология разработки программного обеспечения. Справочное руководство. – М. : Русская редакция, 2010. – С. 127. Учебное электронное текстовое издание Солонин Евгений Борисович СОВРЕМЕННЫЕ МЕТОДИКИ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ Выпускающий редактор Н.В. Лутова Редактор А.В. Ерофеева Компьютерная верстка авторска

В первой части мы начали подбирать подходящий инструмент для разработки программного продукта в проекте под управлением PRINCE2® и даже сформулировали для этого высокоуровневые требования. DSDM Agile Project Framework выбран в качестве примера не зря. Во-первых, это детально проработанный подход с развитой ролевой моделью (чего явно не хватает в Scrum), а, во-вторых, в нём уделяется достаточное внимание взаимодействию между уровнями управления (что вообще редкость). То есть, половина наших требований с ходу выполняется, посмотрим, что там с остальными.

Подход Agile, как и любая другая методология разработки программного обеспечения, имеет более-менее формальные критерии применения, из которых особенно важны два:

Готовность заказчика эффективно взаимодействовать с разработчиком в ходе проекта.
Объективное наличие неопределенностей в требованиях к программному продукту на начальных этапах.

Да, именно в такой последовательности. Если заказчик НЕ ГОТОВ взаимодействовать, то об это разобьется agile любой твёрдости, несмотря на глубину проработки методики, квалификацию менеджеров, таланты разработчиков, удобство коворкинга и даже тимбилдинг на тропических островах. Примеров этому масса, некоторые широко известны, но не будем сейчас о грустном.

С требованиями всё еще проще, если разработчик в состоянии вытащить из заказчика все требования, формализовать их в виде технического задания и сдать готовый продукт, по утвержденной ПМИ (программа и методика испытаний), то нет вообще никакого смысла отступать от классической каскадной (Waterfall) модели, пусть даже реализованной в рамках устаревшего ГОСТ 19.301-79.

Если эти два критерия выполняются (быстрый старт и быстрые результаты – это бонусы, которых может и не быть), то можно начинать смотреть в сторону гибких подходов, среди которых DSDM не без оснований считается одним из наиболее глубоко проработанных. Кроме того, Agile Manifesto был подписан в 2001 году последователями следующих методов: Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming, то есть, авторы DSDM стояли у истоков базовых принципов гибкой разработки.

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Особенностью DSDM является итеративный и инкрементный подход, который предполагает активное и продолжительное участие в процессе будущих пользователей. Основная цель в данном случае – сдать готовый проект вовремя и уложиться в бюджет, постоянно управляя изменениями требований во время разработки. Отличие DSDM от традиционных моделей (Waterfall, V-model etc.) схематически показано на рисунке ниже.

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

Здесь и далее мы будем рассматривать текущую редакцию метода под названием The DSDM Agile Project Framework (2014 Onwards).

Управление ресурсами и рисками проекта на уровне команды

Для управления проектом на уровне команды DSDM Agile Project Framework предлагает следующие техники, позволяющие регулировать объём работ в проекте путем грамотного управления требованиями и их реализацией:

MoSCoW приоритизация;
Timeboxing;
Рабочие совещания (Facilitated workshops);
Моделирование;
Прототипирование.

Наибольшую важность представляют первые две, поэтому остановимся именно на них. В проекте под управлением DSDM, где сроки жёстко зафиксированы, необходимо быстро и правильно оценивать приоритет (относительную важность) работ. А поскольку подход итеративный, такая оценка должна выполняться регулярно, по мере продвижения проекта и внесения в него изменений. MoSCoW – это инструмент для понимания важности и эффективного управления требованиями, а буквы означают следующее:

Must Have (должно быть обязательно), критичное требование;
Should Have (должно быть), приоритетное требование;
Could Have (могло бы быть), желательное требование;
Won’t Have this time (будет не в этот раз), перспективное требование.

Требования Must строго обязательны для продукта или его очередного инкремента. Требования Should также критичны, но они могут быть исключены из текущего инкремента продукта по объективным причинам. Требования Could не считаются критичными, но могут увеличить пользовательскую удовлетворенность. Требования Won’t наименее критичны для продукта, они могут считаться интересными и перспективными для будущих инкрементов. Объектами приоритизации также могут быть задачи, продукты (артефакты), критерии приемки и тесты, но чаще всего это требования и пользовательские истории (User Stories).

Конечно, приоритизация требований не выглядит чем-то уникальным, но в DSDM решения по отказу от реализации требований, имеющих критичность, отличную от Must, принимает команда разработчиков. Это достигается за счёт проработанной ролевой модели и эффективного разделения уровней управления проектом, которые свойственны и DSDM, и PRINCE2®.

Название второй важнейшей техники DSDM – Timeboxing – адекватно перевести на русский язык невозможно (дословно это означает упаковку определенных временных интервалов в коробки), поэтому попробуем понять общий смысл. DSDM определяет Timebox как фиксированный временной интервал, в конце которого достигается определенная цель (Objective). Эта техника даёт возможность команде разработчиков сконцентрировать усилия на достижении чего-то законченного и значимого, а не просто сильно напрячься и устать в процессе работы.

Поскольку в каждый Timebox включаются требования, ранее приоритизированные с помощью техники MoSCoW, в ходе его реализации команда создает очередной инкремент продукта, имеющий заранее определенную и легко измеримую ценность для заказчика. Часто такой инкремент называется прототипом. DSDM также даёт конкретные рекомендации относительно доли требований каждого приоритета в рамках Timebox. Например, доля требований Must не должна превышать 60% от объёма работ, что даёт возможность команде управлять охватом проекта, не ставя под угрозу сроки и бюджет.

[1] Так в DSDM называют ситуации, когда в попытке уменьшить давление бюрократии путем непродуманного внедрения гибких подходов, организации переходят в другую крайность, которая характеризуется плохой дисциплиной, малым количеством документации и общим ощущением хаоса.

Это метод создания и выпуска проектов по Agile. DSDM создали, чтобы облегчить разработку программного обеспечения и создание кода.

Как работает DSDM?

DSDM говорит о том, что при работе над проектом фиксируется его стоимость, качество и время. Функционал проекта может быть гибким и зависит от полезного действия продукта.

Для каких проектов подходит метод DSDM?

Для проектов, в которых заказчик готов активно участвовать в процессе разработки и реализации проекта. При этом в проекте должно быть много неизвестных, результат не должен быть четко и строго описан в техническом задании.

DSDM Принципы

DSDM или метод динамической разработки систем — это метод реализации проектов по Agile. DSDM создали, чтобы облегчить разработку программного обеспечения и создание кода. Со временем метод пересмотрели и сделали универсальным: его можно использовать для разных проектов, не только для IT.

Как работает DSDM

DSDM Agile Project Framework прописывает весь жизненный цикл проекта: с чего начинать, как управлять, какие принципы взять за основу, как вовлекать в работу над проектом пользователей или клиентов.

DSDM говорит о том, что при работе над проектом фиксируется его стоимость, качество и время. Функционал проекта может быть гибким и зависит от полезного действия.

Пример. Нужно запустить сайт для обучающих курсов по дизайну. Задача сайта — чтобы люди оставили свои контакты и так начали свой путь в воронке продаж. На них настроят рекламу, пришлют на емейл письма с советами по дизайну, менеджер позвонит и предложит скидку и так далее. В процессе работы стало понятно, что команда не успевает закончить проект в срок. Временем жертвовать нельзя, качеством тоже, да и стоимость проекта зафиксирована в договоре. Что делать? Выпускать сайт с ограниченным функционалом, чтобы он выполнял полезное действие по сбору контактов. Получить обратную связь по сайту, и остальные функции перенести на следующую итерацию или убрать совсем.

Чем DSDM отличается от традиционного подхода, например, Waterfall

Без чего не работает DSDM

Метод DSDM не работает если:

заказчик не готов активно участвовать в проекте, взаимодействовать с разработчиком;
известны все требования к проекту, понятно, каким должен быть результат.

Для DSDM одинаково важны оба пункта. Заказчик не готов участвовать в проекте, значит, метод нельзя использовать, он не сработает. К проекту есть четкие требование и понятное техническое задание — используйте каскадную модель разработки, зачем усложнять.

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

Принципы DSDM

Пользователи или заказчик (или и те, и другие) участвуют в процесс разработки.
Команда может самостоятельно принимать решения по проекту.
Работа делится на спринты, после каждого спринта команда показывает результат или кусок готового продукта.
Результат всегда должен быть в мире клиента или пользователя, он полезен бизнесу.
Используют итеративный и инкрементный подход к разработке.
Любые действия можно отменить, откатиться назад.
Продукт постоянно и непрерывно тестируют, обратную связь используют для улучшения.

Роли в DSDM

В классическом методе DSDM прописано, кто в команде за что отвечает.

Менеджер проекта руководит командой разработки, общается с заказчиком.

Провидец следит, чтобы задачи соответствовали целям бизнеса, исходили из полезного действия.

Чемпион распоряжается ресурсами проекта.

Лидер команды руководит разработчиками.

Технический координатор отвечает за архитектуру проекта.

Разработчик пишет код.

Тестировщик проверяет продукт на ошибки, баги и логику.

Кейс DSDM

Заказчик. На встрече с заказчиком согласовывают управление проектом, направление и общие сроки. Заказчик выделяет начальный бюджет для этапа исследования и определения. Дополнительное финансирование резервируют и для стадии разработки. Заказчик согласился уделить проекту значительное время, его количество согласовали. Также договорились, что встречи, семинары и пользовательские сессии будут внесены в календарь ответственных и будут неприкосновенны.

Команда. Для членов команды разработали техническое задание, чтобы каждый четко понимал степень своих полномочий. Согласовали, как должны вести себя сотрудники при появлении серьезных проблем у проекта. Договорились, что команда разработчиков будет состоять из 6 человек, что они будут выделены на весь срок проекта. Также признали, что некоторые разработчики–специалисты будут разрабатывать модули в соответствии с определенными спецификациями, вне модели DSDM. Это не является стандартом DSDM, но этого требовала формальная структура организации.

Инкрементная поставка. Согласовали с заказчиком, что будет поставлен только один инкремент. Решили использовать итеративную разработку с интегрированным тестированием, чтобы уложиться в сжатые сроки.

Прозрачность. Ввели ежедневные командные советы, регулярные показы и ретроспективы.

Фокус на потребностях бизнеса. Сразу договорились, что не обязательно выполнять все требования, но команда расставит приоритеты, что должно быть сделано. В итоге заказчик получит рабочее решение, которое отвечает всем его требованиям.

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

Читайте также: