Лекция
Привет, Вы узнаете о том , что такое метод разработки динамических систем, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое метод разработки динамических систем, dynamic systems development method, dsdm , настоятельно рекомендую прочитать все из категории Проектирование веб сайта или программного обеспечения.
Метод разработки - динамическая система (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:
DSDM не зависит от поставщика, охватывает весь жизненный цикл проекта и предоставляет рекомендации по передовой практике для своевременной реализации проектов в рамках бюджета, с проверенной масштабируемостью для реализации проектов любого размера и для любого сектора бизнеса.
DSDM рекомендует использовать несколько проверенных практик, в том числе:
В 2007 году команда, созданная Консорциумом DSDM, исследовала суть метода и решила, что основные механизмы и структура написаны хорошо, но терминология и внимание метода были полностью сфокусированы на области информационных технологий. Поэтому они должны быть усовершенствованы, чтобы отвечать нуждам проектов в новом тысячелетии (часть метода была неизменна с 1995 года). Новая версия была выпущена 24 апреля 2007 года в Cafe Royale в Лондоне.
Как расширение концепции быстрой разработки приложений, DSDM фокусируется на проектах информационных систем, характеризующихся сжатыми сроками и бюджетами. В DSDM присутствуют указания на типичные ошибки проектов информационных систем, таких как превышение бюджета, опоздание со сроками сдачи (исполнения), недостаточное вовлечение пользователей и топ-менеджеров в работу над проектом. DSDM состоит из:
При некоторых условиях существует возможность включения в DSDM частей других методик, таких как Rational Unified Process (RUP), Экстремальное программирование, PRINCE2. Другой гибкий метод, похожий на DSDM по процессу и концепции - Scrum.
Метод DSDM был разработан в Великобритании в 1990-х Консорциумом DSDM. Консорциум DSDM - это ассоциация разработчиков и экспертов в области программного обеспечения, созданная с целью "совместной разработки и продвижения независимого фреймворка RAD" комбинированием лучшего практического опыта участников ассоциации. Консорциум DSDM - это некоммерческая организация независимых разработчиков, которые владеют и управляют фреймворком DSDM. Первая версия фреймворка была завершена в январе 1995 года и опубликована в феврале 1995 года. В июле 2006 года была представлена открытая версия DSDM 4.2, которая стала доступна частным лицам для просмотра и использования. Тем не менее, все, кто распространяет DSDM, должны быть членами этого некоммерческого консорциума.
В начале 1990-х в индустрии информационных технологий стал распространятся новый термин - быстрая разработка приложений (Rapid Application Development, RAD). Пользовательские интерфейсы прикладных программ эволюционировали от старых зеленых экранов до графических интерфейсов пользователя, которые используются и сейчас. На рынок начали выходить новые инструменты для создания приложений, например PowerBuilder. Они позволили разработчикам проще делиться планируемыми разработками с покупателями - появилось прототипирование и началось разрушение классических, последовательностных (каскадных) методов разработки.
Тем не менее, новое движение RAD было очень неструктурированным: не существовало согласованного описания этого метода и у многих организаций были созданы собственные описания и подходы к нему. Множество крупных корпораций были заинтересованы в перспективах, предоставляемых методом, но они также были обеспокоены тем, чтобы не понизился уровень качества их продукции в конечном результате.
Консорциум DSDM был образован в 1994 году, когда группа людей встретилась на мероприятии, организованном Butler Group в Лондоне. Все, кто пришел на это мероприятие, работали в крупных организациях, таких как British Airways, American Express, Oracle and Logica (такие компании как Data Sciences и Allied Domecq с тех пор были поглощены другими организациями).
На этом собрании было решено, что Дженнифер Степлтон, тогда представлявшая компанию Logica, разработает архитектуру комлексного, ориентированного на пользователя метода с хорошим контролем качества для итеративной и инкрементной разработки. Итоговая архитектура была спроектирована так, чтобы быть полностью совместимой со стандартом ISO 9000 и PRINCE2. Когда архитектура была готова (через месяц после собрания), Консорциум сформировал группы для ее распространения во всех областях разработки программного обеспечения, которые включали в себя: методы и средства управления проектом, контроль качества и тестирование, методы и средства разработки. Контрольная группа, возглавляемая создателем архитектуры и состоящая из глав этих групп, должна была обеспечить понимание метода так, как он первоначально задумывался.
Несмотря на то, что многие члены Консорциума были прямыми конкурентами, они свободно делились тем, как они решают возникающие проблемы. Практика показала, что наилучший результат может быть достигнут только работая как одно целое. Консорциум увеличился - за первый год от нескольких организаций до шестидесяти; описание метода становилось все более и более полным. Версия 1 была сформирована в декабре 1994 года и опубликована в феврале 1995 года. Результатом стал универсальный метод, охватывающий людей, процессы и инструменты. Он сформировался на основе опыта организаций, различных по роду своей деятельности и размерам.
Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.
Чтобы успешно использовать DSDM, необходимо чтобы был выполнен ряд предпосылок. Во-первых, необходимо организовать взаимодействие между проектной командой, будущими пользователями и высшим руководством. Во-вторых, должна присутствовать возможность разбиения проекта на меньшие части, что позволит использовать итеративный подход.
Два примера проектов, для которых DSDM не очень подходит:
Фреймворк DSDM состоит из трех последовательных стадий, которые называются предпроектная стадия, стадия жизненного цикла проекта и постпроектная стадия. Стадия жизненного цикла проекта - самая продуманная и детально разработанная из всех остальных. Она состоит из пяти этапов, которые формируют итеративный, инкрементный подход к разработке информационных систем. Эти три фазы и соответствующие этапы будут более подробно описаны в последующих разделах. Для каждой стадии или этапа будут рассмотрены самые важные функции и будут представлены результаты.
Стадия 1 - Предпроектная
На этой стадии определяются вероятные проекты, происходит выделение средств и определение проектной команды. Решение задач на этой стадии поможет избежать проблем на более поздних стадиях проекта.
Стадия 2 - Жизненный цикл проекта
На рисунке ниже изображена данная стадия. На нем показаны 5 этапов, которые нужно пройти проекту, чтобы стать информационной системой. Первые два этапа, исследование реализуемости и исследование экономической целесообразности, идут последовательно и дополняют друг друга. После завершения этих этапов, происходит итеративная и инкрементная разработка системы в этапах: создание функциональной модели, проектирование и разработка, этап реализации. Итеративная и инкрементная природа DSDM будет описана далее.
Стадия 3 - Постпроектная
На этой стадии обеспечивается эффективная работа системы. Это достигается за счет поддержания проекта, его улучшения и исправления ошибок согласно принципам DSDM. Поддержка проекта осуществляется продолжением разработки, основанной на итеративной и инкрементной природе DSDM. Вместо того, чтобы закончить проект за один цикл, обычно возвращаются к предыдущим стадиям или этапам, чтобы улучшить продукт.
Ниже на диаграмме представлен весь жизненный цикл проекта. Эта диаграмма описывает итеративную разработку DSDM. Описание каждого этапа будет представлено ниже.
| Действие | Поддействие | Описание |
|---|---|---|
| Исследование | Исследование реализуемости | На данном этапе определяется - попадает ли проект под рамки DSDM. Об этом говорит сайт https://intellect.icu . Рассматривая тип проекта, организационные и кадровые вопросы, выносится решение - использовать метод DSDM или нет. Таким образом будет получен отчет о применимости, допустимый прототип и примерный глобальный план проекта, который включает в себя план разработки и протокол возможных рисков. |
| Исследование экономической целесообразности | На данном этапе анализируются основные экономические и технологические характеристики. Происходит собрание экспертов, на котором обсуждаются наиболее важные стороны системы и принимается решение о приоритетах в разработке. На этом этапе разрабатываются список основных требований, описание сферы коммерческой деятельности, описание архитектуры системы и примерный план создания прототипов. | |
| Создание функциональной модели | Определение функционального прототипа | Определение функционала, который будет заложен в прототипе на данном этапе. На этом подэтапе разрабатывается функциональная модель согласно результатам, полученным на стадии исследования экономической целесообразности. |
| Согласование планов | Происходит согласование как и в какие сроки должен быть разработана функциональность прототипа. | |
| Создание функционального прототипа | Разработка функционального прототипа, согласно планам и функциональной модели. | |
| Анализ функционального прототипа | Проверка исправности разработанного прототипа. Это может быть достигнуто тестированием прототипа конечным пользователем и/или пересмотром документации. Результат - документ, содержащий обзор функционального прототипа. | |
| Проектирование и разработка | Определение конструктивного прототипа | Определение функциональных и нефункциональных требований системы. На основе этих требований должна быть создана стратегия реализации. Если существует запись о тестировании из предыдущей итерации, тогда она тоже будет использована для создания стратегии реализации. |
| Согласование планов | Происходит согласование как и в какие сроки должны быть реализованы поставленные требования. | |
| Создание конструктивного прототипа | Создание системы (конструктивного прототипа), которую можно отдать пользователям для тестирования. | |
| Анализ конструктивного прототипа | Проверить исправность спроектированной системы. На этом подэтапе применяется тестирование и пересмотр результатов. Создание пользовательской документации и протокола испытания. | |
| Реализация | Утверждение системы пользователем | Конечные пользователи утверждают протестированную систему для последующей реализации и создания руководства. |
| Обучение пользователей | Обучение будущего пользователя работе с системой. Результат подэтапа - контингент обученных пользователей. | |
| Реализация | Реализация протестированной системы среди пользователей. | |
| Анализ рынка системы | Анализ воздействия выпущенной системы на рынок. Главный вопрос - достигнута ли цель, поставленная при проектировании системы. Основываясь на этом проект переходит на следующую стадию (постпроектную) или возвращается на предыдущую для доработки. Анализ будет представлен в документе анализа проекта. |
В течение этого этапа, проверяется реализуемость проекта в рамках DSDM. Предпосылки для использования DSDM проверяются ответом на вопросы: «Может ли данный проект удовлетворить необходимым экономическим требованиям?», «Проект подходит для использования метода DSDM?» и «Какие риски в этом проекте самые важные?». Наиболее важный метод на этом этапе - использование рабочих групп.
Итог данного этапа - отчет о применимости и допустимый прототип, в которых рассмотрена реализуемость проекта, а также примерный глобальный план проекта и протокол возможных рисков, описывающий наиболее важные риски проекта.
Исследование экономической целесообразности расширяет и дополняет этап исследования реализуемости. После того как проект был признан реализуемым в рамках DSDM, на этой стадии проверяются бизнес-процессы, происходит вовлечение групп пользователей и анализ их требований и пожеланий. И опять же самым востребованным методом на данном этапе является использование рабочих групп. В рамках рабочих групп участники проекта собираются, чтобы обсудить планируемую систему. Информация полученная после данных мероприятий собирается в список требований. Важное свойство этого списка - распределение приоритетов среди требований. Эти требования распределены согласно методу MoSCoW. На основе полученной очередности создается план разработки, который будет ориентиром для всего проекта.
Для создания этого плана применяется очень важная для проекта методика - тайм-боксинг. Эта методика обязательна для достижения целей DSDM - уложится в сроки и в бюджет, и при этом сохранить необходимое качество продукта. Архитектура системы - еще одно подспорье в управлении разработкой информационной системы. Итогом данного этапа является описание сферы коммерческой деятельности, в котором содержится context of the project within the company, описание архитектуры системы, предоставляющее первоначальную глобальную архитектуру информационной системы, находящейся в разработке, и план разработки, котором обозначены наиболее важные шаги в процессе разработки. В основе этих двух документов лежит список требований. Протокол возможных рисков дополняется данными, полученными на этом этапе.
Требования, которые были определены на предыдущем этапе, превращаются в функциональную модель. Она состоит из действующего прототипа и моделей. Прототипирование - ключевая методика проекта на данном этапе, позволяющая организовать вовлечение пользователей в проект. Разработанный прототип анализируется различными группами пользователей. Чтобы достичь необходимого качества, на каждой итерации применяется тестирование. Самая важная часть тестирования представлена на данном этапе. Создание функциональной модели можно разделить на следующие подэтапы:
Итогом данного этапа являются функциональная модель и функциональный прототип, которые вместе представляют функциональность полученный на этой итерации, готовые для тестирования пользователями. Далее обновляется список требований - из него удаляются уже реализованные пункты и происходит повторное изменение очередности оставшихся пунктов. Протокол возможных рисков также обновляется, после анализа функционального прототипа.
Главная задача этой итерации - объединить функциональные компоненты из предыдущего этапа в единую систему, удовлетворяющую требованиям пользователей. Здесь также рассматриваются нефункциональные требования. И снова на данном этапе происходит тестирование. Проектирование и разработку можно разделить на следующие подэтапы:
Итог этапа - создание конструктивного прототипа для тестирования пользователями. Протестированная система переходит на следующий этап. На данном этапе внешний вид и функциональность системы в общем готовы. Еще один итог - создание пользовательской документации.
На этапе реализации протестированная система вместе с пользовательской документацией доставляется к будущим пользователям и происходит их обучение работы с системой. Система анализируется на соответствие требованиям, поставленных на ранних этапах проекта. Реализацию можно разделить на следующие подэтапы:
Итог этапа: законченная система, пригодная для использования конечными пользователями, контингент обученных пользователей и детальный документ анализа проекта.
Связи между понятиями на этапе создания функциональной модели показаны на модели на рисунке ниже.
| Понятие | Описание |
|---|---|
| Протокол возможных рисков | Протокол обнаруженных рисков. Важен для последующих стадий, содержит проблемы с которыми есть вероятность столкнуться. Должен постоянно обновляться. |
| Список требований по приоритетам | Список требований, распределенных по приоритету. Процесс распределения основан на методе MoSCoW, который определяет какие требования должны быть реализованы раньше (с экономической точки зрения) |
| Список нефункциональных требований | Список нефункциональных требований, с которыми придется иметь дело на следующем этапе. |
| Функциональное требование | Эта функция используется для построения модели и прототипирования согласно приоритетам. |
| Функциональная модель | Модель, построенная на основе функциональных требований. Она будет использована для разработки прототипа на следующем подэтапе. Эта модель будет использована для создания плана прототипирования. |
| Прототипирование | Процесс быстрого изготовления работающей модели (прототипа) для того, чтобы проверить дизайн, проиллюстрировать заложенные идеи и функции и по-раньше собрать отзывы пользователей. |
| Список интервалов времени | Список интервалов времени выполнения отдельных работ, необходим, чтобы уложится в график выполнения всего проекта. |
| План прототипирования | План процесса прототипирования, который будет выполнен во временные интервалы согласно графику. |
| График работ | Набор работ и времени проведения этих работ, согласованный разработчиками. Используется в реализации функционального прототипа. |
| Функциональный прототип | Прототип, позволяющий увидеть все функции системы и то, как система будет эти функции выполнять. |
| План реализации | Подготовка работ для реализации функционального прототипа согласно графику работ и списку требований. |
| Улучшенная функция | Функция прототипа, которая была улучшена и протестирована на данной итерации до объединения с другими частями прототипа. |
| Объединенная функция | Функция прототипа, которая была объединена с функциями предыдущих итераций. Новый объединенный функциональный прототип будет протестирован на следующем этапе. |
| Протокол испытания | Запись тестирования, состоящая из сценария тестирования, процедуры тестирования и результатов тестирования. |
| Документ анализа функционального прототипа | Состоит из комментариев пользователей о текущей версии, необходимых для работы над последующими итерациями. Этот документ используется для обновления протокола возможных рисков и списка требований. |
Работа по определению функционального прототипа заключается в определении функционала, который будет присутствовать в прототипе на данной итерации. Аналитика и программирование закончено; прототипы собраны; и опыт полученный от них использован для улучшения моделей анализа (а также основывается на обновленных списке требований и протоколе возможных рисков). Построенные прототипы не выбрасываются, а понемногу доводятся до необходимого качества, чтобы потом включить в готовую систему. Согласованный график работ необходим, чтобы определить когда и в какие сроки будет реализовано прототипирование; он расширяет расписание и план прототипирования. А тестирование, проводящееся в течение всего процесса, также является непременной частью этого этапа и включается в процесс анализа прототипа сразу после того, как прототип будет построен. Протокол испытания также будет использован для анализа прототипа и создания документа анализа. Ниже представлена диаграмма данного процесса.
| Действие | Поддействие | Описание |
|---|---|---|
| Определение функционального прототипа | Анализ требований | Требования к текущему прототипу анализируются согласно списку требований, созданному ранее (в предыдущей итерации и/или стадии). |
| Список требований на текущую итерацию | Выбор функциональных требований, которые будут реализованы в прототипе на текущей итерации, и создание списка функциональных требований. | |
| Список нефункциональных требований | Формирование списка нефункциональных требований к системе. | |
| Создание функциональной модели | Анализ кода модели и прототипа и создание функциональной модели. | |
| Согласование планов | Определение времени | Определение возможного расписания проведения работ по прототипированию согласно с планом и стратегией прототипирования. |
| Составить план разработки | Создание плана прототипирования, включающий все работы по прототипированию, которые будут выполнены во временные интервалы согласно графику. | |
| Согласование | Согласованный график того, как и в какие сроки будут выполнены все работы по прототипированию. | |
| Создание функционального прототипа | Исследование | Исследование требований; анализ функциональной модели и разработка плана реализации на основе проведенного анализа. Результаты будут использованы для построения прототипа в следующем поддействии. |
| Улучшение | Реализация функциональной модели и плана реализации для построения функционального прототипа. Затем этот прототип будет улучшен прежде, чем объединить его с другими функциями. Прототип доводится до необходимого качества, чтобы потом включить в готовую систему. | |
| Объединение | Объединение улучшенного функционального прототипа с прототипом, разработанным на предыдущей итерации. Полученный прототип будет протестирован в следующем действии. | |
| Анализ функционального прототипа | Тестирование прототипа | Непременная часть метода DSDM, которая должна присутствовать на протяжении всего процесса. Протокол испытаний совместно с комментариями пользователей будет использован для создания документа анализа прототипа на следующей стадии. |
| Анализ прототипа | Собираются комментарии пользователей и документация. Они будут играть важную роль при разработке документа анализа прототипа. На основе этого документа будет проведено обновление списка требований и протокол возможных рисков, а также будет принято решение проводить или нет еще одной итерации стадии создания функциональной модели. |
MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.
SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.
COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.
WON'T - МОЖНО ли отложить выполнение требования, если еще есть время.
Кроме тайм-боксинга и распределения требований по приоритетам метод DSDM также использует итеративный и инкрементный подход к созданию информационных систем.
Этап создания функциональной модели, этап проектирования и разработки и этап реализации могут проходить по своим подстадиям много раз прежде, чем двигаться дальше к следующей стадии. На каждой итерации рассматриваются новые функции и каждая текущая итерация основывается на предыдущей. И если потребуется, каждую итерацию можно оставить недоделанной.
Например, если много новых и полезных функций было открыто во время разработки, но они не могут быть реализованы, то можно начать проект заново составлением новых требований на стадии исследования экономической целесообразности. Или, наоборот, некоторые функции могут быть опущены из-за ограниченности бюджета или времени. Проект может перейти в постпроектную стадию только, когда выполнены все поставленные требования.
Благодаря итеративной природе DSDM, наличествует должное управления требованиями и конфигурацией на протяжении всего проекта. Это обеспечивает реализацию всех требований, поставленных на ранних стадиях проекта.
В рамках DSDM существуют следующие факторы, которые влияют на успех проекта.
Уже было разработано и применено в деле множество методов разработки информационных систем. Например, Structured Systems Analysis and Design Method (SSADM), методы быстрой разработки приложений RAD, методы ООП. Большинство этих методов похожи друг на друга и на DSDM.
Метод экстремального программирования также использует итеративный подход к разработке информационных систем с привлечением пользователей.
Метод Rational Unified Process - самый похожий на DSDM, также является динамическим методом разработки информационных систем. И опять же в нем применяется итеративный подход к разработке.
Существуют и другие методы, которые могут показаться похожими на DSDM, но существует ряд отличий. Во-первых, он предоставляет необходимые инструменты и способы разработки. Это позволяет пользователям особым образом дополнить процесс разработки своими собственными методами и помочь в принятии решений. Еще одна уникальная особенность - можно менять не время или средства разработки, а требования к проекту. Такой подход обеспечивает достижение основных целей DSDM - уложиться по времени и не выйти за рамки бюджета. И последнее - взаимопонимание и общение между всеми участниками и их вовлеченность в проект.
RAD ( программирование )
Rational Unified Process
Scrum
Выводы из данной статьи про метод разработки динамических систем указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое метод разработки динамических систем, dynamic systems development method, dsdm и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Проектирование веб сайта или программного обеспечения
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Проектирование веб сайта или программного обеспечения
Термины: Проектирование веб сайта или программного обеспечения