DSDM

Існує 9 принципів, що складаються з 4 основних та 5 початкових точок.

• Активне залучення кінцевих користувачів — це основа ведення ефективного проєкту, де розробники ділять з користувачами робочий простір і тому прийняті рішення будуть більш точними.
• Уповноважена команда — команда має бути уповноважена приймати важливі для проєкту рішення без узгодження з керівництвом.
• Часта поставка та оновлення — якомога частіша поставка дозволяє викрити вади та недоліки на значно ранішому етапі. Відповідно до DSDM «поставити щось хороше раніше — це завжди краще, ніж поставити все ідеально зроблено в кінці». Аналіз поставок версій з попередньої ітерації враховується на наступній.
• Потреби бізнесу як головний рушій розробки — мета поставки програмного забезпечення - якомога краще відповідати поточним потребам ринку. Але в той же час постачання продукту, який задовольняє потребам ринку, не менш важлива, ніж вирішення критичних проблем у функціоналі продукту.
• Ітеративна та інкрементна розробка — ґрунтується на отриманні зворотнього зв'язку від користувача, задля досягнення оптимальної з економічної точки зору рішення.
• Бути відкритими для будь-яких змін — під час розробки завжди передбачати місце для змін і вважати зміни - новою характеристикою проєкту.
• Дотримання висого рівня початкових вимог — вимоги встановлюються на високому рівні перш, ніж почнеться проєкт. Рекоментується формулювати їх в максимально простому вигляді без занурення в деталі.
• Ефективна інтеграція розробки і тестування — життєвий цикл розробки передбачає залучення тестувальників протягом всього циклу, а не лише в кінцевих стадіях. На практиці це може означати, що тестується результат попередньої ітерації, коли йде розробка поточної
• Фокус на взаємодії і співпраці — команда має дотримуватися атмосфери довіри і чесності між усіма учасниками для покращення ефективності процесу.

Щоб успішно використовувати DSDM, необхідно щоб був виконаний ряд передумов. По-перше, необхідно організувати взаємодію між проєктною командою, майбутніми користувачами і вищим керівництвом. По-друге, повинна бути можливість поділу проєкту на менші частини, що дозволить використовувати ітеративний підхід.

Два приклади проєктів, для яких DSDM не дуже підходить:

• проєкти, критичні безпеки розширене тестування та затвердження в таких проєктах конфліктують з метою методу DSDM укластися в терміни і бюджет.
• проєкти, чия мета зробити компоненти багаторазового використання — вимоги в таких проєктах занадто високі і не вкладаються в принцип 80 %/20%.

Фреймворк DSDM складається з трьох послідовних стадій, які називаються передпроєктна стадія, стадія життєвого циклу проєкту і постпроєктна стадія. Стадія життєвого циклу проєкту — сама продумана і детально розроблена з усіх інших. Вона складається з п'яти етапів, які формують ітеративний, інкрементний підхід до розробки інформаційних систем. Ці три фази і відповідні етапи будуть більш детально описані в наступних розділах. Для кожної стадії або етапи будуть розглянуті найважливіші функції і будуть представлені результати.

Стадія 1 — Передпроєктна

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

Стадія 2 — Життєвий цикл проєкту

На рисунку зображена дана стадія. На ньому показано 5 етапів, які потрібно пройти проєкту, щоб стати інформаційною системою. Перші два етапи, дослідження реалізованості та дослідження економічної доцільності, йдуть послідовно і доповнюють один одного. Після завершення цих етапів, відбувається ітеративна та інкрементна розробка системи в етапах: створення функціональної моделі, проєктування і розробка, етап реалізації. Ітеративна та інкрементна природа DSDM буде описана далі.

Стадія 3 — Постпроєктна

На цій стадії забезпечується ефективна робота системи. Це досягається за рахунок підтримки проєкту, його покращення та виправлення помилок згідно з принципами DSDM. Підтримка проєкту здійснюється продовженням розробки, заснованої на ітеративної і інкрементній природі DSDM. Замість того, щоб закінчити проєкт за один цикл, зазвичай повертаються до попередніх стадій або етапів, щоб поліпшити продукт.

Нижче на діаграмі представлений весь життєвий цикл проєкту. Ця діаграма описує итеративную розробку DSDM. Опис кожного етапу буде представлено нижче.

Діаграма життєвого циклу проєкту

Протягом цього етапу, перевіряється реалізація проєкту в рамках DSDM. Передумови для використання DSDM перевіряються відповіддю на питання: «чи Може даний проєкт задовольнити необхідним економічним вимогам?», «Проєкт підходить для використання методу DSDM?» і «Які ризики в цьому проєкті найважливіші?». Найбільш важливий метод на цьому етапі — використання робочих груп.

Підсумок даного етапу — звіт про застосовність і допустимий прототип, в яких розглянута реалізація проєкту, а також приблизний глобальний план проєкту та протокол можливих ризиків, що описує найбільш важливі ризики проєкту.

Дослідження економічної доцільності розширює і доповнює етап дослідження реалізованості. Після того, як проєкт був визнаний реалізованим у рамках DSDM, на цій стадії перевіряються бізнес-процеси, відбувається залучення груп користувачів і аналіз їх вимог і побажань. І знову ж самим затребуваним методом на даному етапі є використання робочих груп. В рамках робочих груп учасники проєкту збираються, щоб обговорити плановану систему. Інформація отримана після даних заходів збирається у список вимог. Важлива властивість цього списку — розподіл пріоритетів серед вимог. Ці вимоги розподілені згідно з методом MoSCoW. На основі отриманої черговості створюється план розробки, який буде орієнтиром для всього проєкту.

Для створення цього плану застосовується дуже важлива для проєкту методика — тайм-боксинг. Ця методика є обов'язковою для досягнення цілей DSDM — вкладеться у терміни і в бюджет, і при цьому зберегти необхідну якість продукту. Архітектура системи — ще одне підмога в управлінні розробкою інформаційної системи. Підсумком даного етапу є опис сфери комерційної діяльності, в якому міститься контекст проєкту всередині компанії, опис архітектури системи, що надає первинну глобальну архітектуру інформаційної системи, що знаходиться в розробці, і план розробки, якому визначені найбільш важливі кроки в процесі розробки. В основі цих двох документів лежить список вимог. Протокол можливих ризиків доповнюється даними, отриманими на цьому етапі.

Вимоги, які були визначені на попередньому етапі, перетворюються на функціональну модель. Вона складається з діючого прототипу і моделей. Прототипування — ключова методика проєкту на даному етапі, що дозволяє організувати залучення користувачів до проєкту. Розроблений прототип аналізується різними групами користувачів. Щоб досягти необхідної якості, на кожній ітерації застосовується тестування. Найважливіша частина тестування представлена на даному етапі. Створення функціональної моделі можна розділити на наступні підетапи:

• Визначення функціонального прототипу: визначення функціоналу, який буде закладено в прототипі на даному етапі.
• Узгодження планів: відбувається узгодження як і в які терміни повинен бути розроблена функціональність прототипу.
• Створення функціонального прототипу: розробити прототип. Вивчити та доробити прототип на даній ітерації згідно функціонального прототипу, отриманого на попередніх ітераціях.
• Аналіз функціонального прототипу: перевірити справність спроєктованої системи. На цьому підетапі застосовується тестування та перегляд результатів.

Підсумком даного етапу є функціональна модель і функціональний прототип, які разом представляють функціональність, отриману на цій ітерації, готову для тестування користувачами. Далі оновлюється список вимог. З нього видаляються вже реалізовані пункти і відбувається повторна зміна черговості решти пунктів. Протокол можливих ризиків також оновлюється, після аналізу функціонального прототипу.

Головне завдання цієї ітерації — об'єднати функціональні компоненти з попереднього етапу в єдину систему, що задовольняє вимогам користувачів. Тут також розглядаються нефункціональні вимоги. І знову на даному етапі відбувається тестування. Проєктування та розробку можна розділити на наступні підетапи:

• Визначення конструктивного прототипу: визначення функціональних та нефункціональних вимог, які повинні бути в системі.
• Узгодження планів: відбувається узгодження як і в які терміни повинні бути реалізовані поставлені вимоги.
• Створення конструктивного прототипу: створення системи, яку можна віддати користувачам для повсякденного використання. Вивчити та доробити прототип на даній ітерації.
• Аналіз конструктивного прототипу: перевірити справність спроєктованої системи. На цьому подэтапе застосовується тестування та перегляд результатів. Для створення користувальницької документації використовуються протокол випробування та відгуки користувачів.

Підсумок етапу — створення конструктивного прототипу для тестування користувачами. Протестована система переходить на наступний етап. На даному етапі зовнішній вигляд і функціональність системи загалом готові. Ще один підсумок — створення користувальницької документації.

На етапі реалізації протестована система разом з користувацької документацією доставляється до майбутнім користувачам і відбувається їх навчання роботи з системою. Система аналізується на відповідність вимогам, поставлених на ранніх етапах проєкту. Реалізацію можна розділити на наступні підетапи:

• Затвердження системи користувачем: кінцеві користувачі стверджують протестовану систему для подальшої реалізації і створення керівництва.
• Навчання користувачів: навчання майбутнього користувача роботі з системою. Результат підетапи — контингент підготовлених користувачів.
• Реалізація: реалізація протестованої системи серед користувачів.
• Аналіз ринку системи: аналіз впливу випущеної системи на ринок. Головне питання — чи досягнута мета, поставлена при проєктуванні системи. Ґрунтуючись на цьому, проєкт переходить на наступну стадію (постпроєктную) або повертається на попередню для доопрацювання.

Підсумок етапу: закінчена система, придатна для використання кінцевими користувачами, контингент підготовлених користувачів і детальний документ аналізу проєкту.

Зв'язки між поняттями на етапі створення функціональної моделі показано на моделі на малюнку нижче.

Модель мета-даних

Робота за визначенням функціонального прототипу полягає у визначенні функціоналу, який буде присутній в прототипі на даній ітерації. Аналітика та програмування закінчено; прототипи зібрані; і досвід отриманий від них використаний для поліпшення моделей аналізу (а також ґрунтується на оновлених списку вимог і протоколі можливих ризиків). Побудовані прототипи не викидаються, а потроху доводяться до необхідної якості, щоб потім включити в готову систему. Погоджений графік робіт необхідний, щоб визначити, коли і в які терміни буде реалізовано прототипування; він розширює розклад і план прототипування. А тестування, яке проводиться протягом всього процесу, також є неодмінною частиною цього етапу і включається в процес аналізу прототипу відразу після того, як прототип буде побудований. Протокол випробування також буде використано для аналізу прототипу та створення документа аналізу. Нижче представлена діаграма даного процесу.

Діаграма створення функціональної моделі.

• Тайм-боксинг — одна з основних методик DSDM. Вона використовується, щоб досягти головних цілей DSDM — розробити інформаційну систему у строки, укластися в бюджет і при цьому зберегти якість. Основна ідея тайм-боксингу — розділити весь проєкт на частини, кожна зі своїм бюджетом і термінами виконання. Для кожної такої частини вибираються вимоги, які були розподілені за принципом MoSCoW. Так як час і бюджет фіксовані, єдине, що можна поміняти, — це вимоги. Так, якщо проєкт вибивається з графіка або виходить за межі бюджету, вимоги з найменшим пріоритетом опускаються. Це не означає, що вийде неготовий продукт. Виходячи з принципу 20/80 80 % проєкту виходить з 20 % вимог. Тому, як тільки ці найважливіші 20 % вимог реалізовані в системі, вона задовольняє економічними вимогами. Варто зауважити, що жодна система не була ідеально побудована з першого разу.
• Метод MoSCoW надає шлях розподілу об'єктів за пріоритетами. У контексті DSDM метод MoSCoW використовується для розподілу пріоритетів вимоги. Щодо кожної вимоги задається питання: "Що станеться, якщо цю вимогу не виконати?". Відповідь віднесе її в одну з чотирьох категорій. Ця абревіатура розшифровується так:

MUST — ТРЕБА виконати цю вимогу, адже вона ключова для успіху проєкту, і без неї проєкт буде скасовано.

SHOULD — СЛІД виконувати цю вимогу, адже вона важлива для проєкту, але не критична.

COULD — МОЖНА виконати цю вимогу, адже вона має цінність, але не важлива для проєкту.

WON'T — НЕ ПОТРІБНО цього разу, адже вона не дає суттєвої цінності.

• Ця методика належить до створення прототипів системи під час розробки на ранніх етапах. Вона дозволяє виявити недоліки в системі і дозволяє майбутнім користувачам протестувати її. Таким чином реалізовано залучення користувача в роботу — один з ключових факторів успіху методу DSDM.
• Тестування

Третя важлива сторона досягнення мети DSDM — створити інформаційну систему високої якості. Щоб цього домогтися, метод DSDM наполягає на проведенні тестування на кожній ітерації. Команда проєкту вільна сама вибирати спосіб управління тестуванням.

• Робоча група

Ця одна з методик DSDM, мета якої — зібрати разом різних учасників проєкту, щоб обговорити вимоги, функціональність і налагодити взаєморозуміння. Учасники кожної групи збираються разом, щоб обговорити проєкт.

• Моделювання

Ця методика є обов'язковою і використовується з метою візуалізувати у вигляді діаграм окрему сторону системи або сфери діяльності, над якими йде робота. Моделювання дає краще розуміння всієї проєктної команди сфери ділової активності проєкту.

• Управління конфігурацією

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

• Виконавчий спонсор продюсер або по-іншому Чемпіон проєкту. Дуже важлива роль. У нього є можливість і обов'язок розпоряджатися фондами та ресурсами. У цій ролі також є повне право приймати рішення.
• Провидець Це той, хто запускає проєкт в роботу і знаходить перші основні вимоги. У провидця саме точне розуміння комерційних цілей системи і проєкту.
• Представницький користувач Являє користувачів у проєкті. Відповідає за те, щоб розробники отримували достатню кількість відгуків користувачів під час процесу розробки.
• Користувач-консультант Може бути будь-який користувач, який представляє важливу точку зору на проєкт і привносить в проєкт знання за деякою стороні використання продукту.
• Менеджер проєкту Може бути спільноти користувачів або з області інформаційних технологій. Забезпечує загальне керівництво проєктом.
• Технічний координатор Відповідальний за розроблення архітектури системи і контролює якість проєкту.
• Лідер команди Очолює команду розробки і забезпечує її ефективну роботу.
• Розробник Аналізує вимоги до системи та моделює її. Це передбачає написання коду і створення прототипів..
• Тестувальник Перевіряє справність проєкту з технічної сторони, проводячи тести. Складає коментарі і документацію.
• Секретар Відповідає за збір і запис вимог, угод і рішень, прийнятих у кожній робочій групі.
• Посередник Управляє робочими групами.
• Інші ролі Бізнес-архітектор, менеджер з якості, фахівець з системної інтеграції і т. д.

Крім тайм-боксингу і розподілу вимог щодо пріоритетів метод DSDM також використовує ітераційні і інкрементний підхід до створення інформаційних систем.

Етап створення функціональної моделі, етап проєктування і розробки етап реалізації можуть проходити за своїм подстадиям багато разів перш, ніж рухатися далі до наступної стадії. На кожній ітерації розглядаються нові функції і кожна поточна ітерація ґрунтується на попередній. І якщо буде потрібно, кожну ітерацію можна залишити недоробленою.

Наприклад, якщо багато нових і корисних функцій було відкрито під час розробки, але вони не можуть бути реалізовані, то можна почати проєкт заново складанням нових вимог на стадії дослідження економічної доцільності. Або, навпаки, деякі функції можуть бути пропущені через обмеженість бюджету або часу. Проєкт може перейти в постпроєктную стадію тільки, коли виконані всі поставлені вимоги.

Завдяки ітеративної природі DSDM, є належне управління вимогами і конфігурацією протягом всього проєкту. Це забезпечує реалізацію всіх вимог, поставлених на ранніх стадіях проєкту.