Главная страница
Навигация по странице:

  • Метод DSDM Принципы

  • Предпосылки для использования DSDM

  • Жизненный цикл проекта Три стадии DSDM

  • Стадия 1 - Предпроектная

  • Стадия 2 - Жизненный цикл проекта Четыре этапа стадии жизненного цикла проекта

  • Действие Поддействие Описание

  • Стадия 3 - Постпроектная

  • Основные методики DSDM Тайм-боксинг.

  • Управление конфигурацией.

  • Основные роли в DSDM Исполнительный спонсор о

  • Представительный пользователь

  • Пользователь-консультант

  • Менеджер проекта

  • Лидер команды

  • Тестировщик

  • Два примера проектов, для которых DSDM не очень подходит

  • Метод разработки динамических систем (DynamicSystemsDevelopmentMethod, dsdm)


    Скачать 35.18 Kb.
    НазваниеМетод разработки динамических систем (DynamicSystemsDevelopmentMethod, dsdm)
    Дата17.11.2022
    Размер35.18 Kb.
    Формат файлаdocx
    Имя файлаDSDM.docx
    ТипДокументы
    #793388

    DSDM

    Метод разработки динамических систем (DynamicSystemsDevelopmentMethod, DSDM) - это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (RapidApplicationDevelopment, RAD). DSDM - это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя.

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

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

    • DSDM и Консорциум DSDM

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

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

    Консорциум DSDM был образован в 1994 году, когда группа людей встретилась на мероприятии, организованном ButlerGroup в Лондоне. Все, кто пришёл на это мероприятие, работали в крупных организациях, таких как BritishAirways, AmericanExpress, OracleandLogica.

    На этом собрании было решено, что Дженнифер Степлтон, тогда представлявшая компанию Logica, разработает архитектуру комплексного, ориентированного на пользователя метода с хорошим контролем качества для итеративной и инкрементной разработки. Итоговая архитектура была спроектирована так, чтобы быть полностью совместимой со стандартом ISO 9000 и PRINCE2. Когда архитектура была готова (через месяц после собрания), Консорциум сформировал группы для её распространения во всех областях разработки программного обеспечения, которые включали в себя: методы и средства управления проектом, контроль качества и тестирование, методы и средства разработки. Контрольная группа, возглавляемая создателем архитектуры и состоящая из глав этих групп, должна была обеспечить понимание метода так, как он первоначально задумывался.

    Несмотря на то, что многие члены Консорциума были прямыми конкурентами, они свободно делились тем, как они решают возникающие проблемы. Практика показала, что наилучший результат, может быть, достигнут, только работая как одно целое. Консорциум увеличился - за первый год от нескольких организаций до шестидесяти; описание метода становилось всё более и более полным. Версия 1 была сформирована в декабре 1994 года и опубликована в феврале 1995 года. Результатом стал универсальный метод, охватывающий людей, процессы и инструменты. Он сформировался на основе опыта организаций, различных по роду своей деятельности и размерам.

    • Метод DSDM

    Принципы

    Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

    • Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.

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

    • Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается последующей.

    • Главный критерий - как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.

    • Разработка - итеративная и инкрементальная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.

    • Любые изменения во время разработки - обратимы.

    • Требования устанавливаются на высоком уровне прежде, чем начнётся проект.

    • Тестирование интегрировано в жизненный цикл разработки.

    • Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

    Предпосылки для использования DSDM

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

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

    Три стадии DSDM

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

    Стадия 1 - Предпроектная 

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

    Стадия 2 - Жизненный цикл проекта 

    Четыре этапа стадии жизненного цикла проекта

    Действие

    Поддействие

    Описание

    Исследование

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

    На данном этапе определяется - попадает ли проект под рамки DSDM. Предпосылки для использования DSDM проверяются ответом на вопросы: «Может ли данный проект удовлетворить необходимым экономическим требованиям?», «Проект подходит для использования метода DSDM?» и «Какие риски в этом проекте самые важные?». Рассматривая тип проекта, организационные и кадровые вопросы, выносится решение - использовать метод DSDM или нет. Таким образом, будет получен отчёт о применимости, допустимый прототип и примерный глобальный план проекта, который включает в себя план разработки и протокол возможных рисков.

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

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

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

    Определение функционального прототипа

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

    Согласование планов

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

    Создание функционального прототипа

    Разработка функционального прототипа, согласно планам и функциональной модели.

    Анализ функционального прототипа

    Проверка исправности разработанного прототипа. Это может быть достигнуто тестированием прототипа конечным пользователем и/или пересмотром документации. Результат - документ, содержащий обзор функционального прототипа.

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

    Определение конструктивного прототипа

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

    Согласование планов

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

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

    Создание системы (конструктивного прототипа), которую можно отдать пользователям для тестирования.

    Анализ конструктивного прототипа

    Проверить исправность спроектированной системы. На этом подэтапе применяется тестирование и пересмотр результатов. Создание пользовательской документации и протокола испытания.

    Реализация

    Утверждение системы пользователем

    Конечные пользователи утверждают протестированную систему для последующей реализации и создания руководства.

    Обучение пользователей

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

    Реализация

    Реализация протестированной системы среди пользователей.

    Анализ рынка системы

    Анализ воздействия выпущенной системы на рынок. Главный вопрос - достигнута ли цель, поставленная при проектировании системы. Основываясь на этом, проект переходит на следующую стадию (постпроектную) или возвращается на предыдущую для доработки. Анализ будет представлен в документе анализа проекта.

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

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


    • Основные методики DSDM

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

    Метод MoSCoW. Метод MoSCoW предоставляет путь распределения объектов по приоритетам. В контексте DSDM метод MoSCoW используется для распределения по приоритетам требования. Эта аббревиатура расшифровывается так:

    MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.

    SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.

    COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.

    WON'T - МОЖНО ли отложить выполнение требования, если ещё есть время.

    Прототипирование. Эта методика относится к созданию прототипов системы во время разработки на ранних этапах. Она позволяет выявить недостатки в системе и позволяет будущим пользователям протестировать её. Таким образом, реализовано вовлечение пользователя в работу - один из ключевых факторов успеха метода DSDM.

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

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

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

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


    • Основные роли в DSDM

    Исполнительный спонсор очень важная роль. У него есть возможность и обязанность распоряжаться фондами и ресурсами. У этой роли также есть полное право принимать решения.

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

    Пользователь-консультант – это может быть любой пользователь, который представляет важную точку зрения на проект и привносит в проект знание по некоторой стороне использования продукта.

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

    Технический координатор – это ответственный за разработку архитектуры системы и контролирует качество проекта.

    Лидер команды возглавляет команду разработки и обеспечивает её эффективную работу.

    Разработчик анализирует требования к системе и моделирует её. Это подразумевает написание кода и создание прототипов.

    Тестировщик проверяет исправность проекта с технической стороны, проводя тесты. Составляет комментарии и документацию.

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


    • Обзор DSDMAtern

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

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

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

    • трёх стадий: предпроектная, стадия жизненного цикла проекта и постпроектная стадия

    • стадия жизни проекта состоит из 5 этапов: исследование реализуемости, исследование экономической целесообразности, создание функциональной модели, проектирование и разработка, этап реализации

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

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

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

    1. Принятие методики DSDM руководством и всеми работниками. Это обеспечивает мотивацию всех участников с момента запуска проекта и их последующую вовлечённость.

    2. Второй фактор следует из первого - готовность руководства обеспечить вовлечённость конечных пользователей в работу над проектом. Процесс прототипирования требует большой вовлечённости пользователей в тестирование и оценивание функциональных прототипов.

    3. Проектная команда должна состоять из опытных членов и в итоге стать постоянным объединением. Важная проблема - доверие и взаимопонимание в проектной команде. Это означает, что команда обладает правом и возможностью принимать важные решения о проекте без формального согласования с руководством, что могло бы отнять много времени. Чтобы команда могла успешно работать над проектом, ей нужны необходимые средства - среда разработки, инструменты для управления проектом и т.д.

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

    Два примера проектов, для которых DSDM не очень подходит:

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

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


    написать администратору сайта