DSDM — Вікіпедія

Метод розробки динамічних систем (Dynamic Systems Development Method, DSDM) — це головним чином методика розробки програмного забезпечення, що базується на концепції швидкої розробки додатків (Rapid Application Development, RAD). У 2007 році DSDM став основним підходом до управління проєктом і розробки додатків. DSDM — це ітеративний і інкрементний підхід, який надає особливого значення тривалій участі в процесі користувача/споживача.^[1]^[2]

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

Остання версія 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). Інтерфейси прикладних програм еволюціонували від старих зелених екранів до графічних інтерфейсів користувача, які використовуються і зараз. На ринок почали виходити нові інструменти для створення додатків, наприклад PowerBuilder. Вони дозволили розробникам простіше ділитися планованими розробками з покупцями — з'явилося прототипування і почалося руйнування класичних, послідовних (каскадних) методів розробки.

Тим не менш, новий рух RAD було дуже неструктурованим: не існувало узгодженого опису цього методу і у багатьох організацій були створені власні описи і підходи до нього. Безліч великих корпорацій були зацікавлені в перспективах, що надаються методом, але вони також були стурбовані тим, щоб не знизився рівень якості їх продукції в кінцевому результаті.

Консорціум DSDM був утворений в 1994 році, коли група людей зустрілася на заході, організованому Butler Group в Лондоні. Всі, хто прийшов на цей захід, працювали у великих організаціях, таких як British Airways, American Express, Oracle and Logica (такі компанії як Data Sciences і Allied Domecq з тих пір були поглинені іншими організаціями).

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

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

Метод DSDM[ред. | ред. код]

Принципи[ред. | ред. код]

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

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

Передумови для використання DSDM[ред. | ред. код]

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

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

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

Життєвий цикл проєкту[ред. | ред. код]

Огляд: три стадії DSDM[ред. | ред. код]

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

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

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

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

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

Чотири етапи стадії життєвого циклу проєкту[ред. | ред. код]

Дія	Піддія	Опис
Дослідження	Дослідження реалізованості	На даному етапі визначається — потрапляє проєкт під рамки DSDM. Розглядаючи тип проєкту, організаційні і кадрові питання, виноситься рішення — використовувати метод DSDM чи ні. Таким чином буде отримано звіт про застосовність, допустимий прототип і приблизний глобальний план проєкту, який включає в себе план розробки і протокол можливих ризиків.
Дослідження	Дослідження економічної доцільності	На даному етапі аналізуються основні економічні і технологічні характеристики. Відбувається нараду експертів, на якій обговорюються найважливіші сторони системи і приймається рішення про пріоритети у розробці. На цьому етапі розробляються список основних вимог, опис сфери комерційної діяльності, опис архітектури системи і приблизний план створення прототипів.
Створення функціональної моделі	Визначення функціонального прототипу	Визначення функціоналу, який буде закладено в прототипі на даному етапі. На цьому підетапі розробляється функціональна модель відповідно до результатів, отриманих на стадії дослідження економічної доцільності.
	Узгодження планів	Відбувається узгодження як і в які терміни має бути розроблена функціональність прототипу.
	Створення функціонального прототипу	Розробка функціонального прототипу, згідно з планами та функціональної моделі.
	Аналіз функціонального прототипу	Перевірка справності розробленого прототипу. Це може бути досягнуто тестуванням прототипу кінцевим користувачем і/або переглядом документації. Результат — документ, що містить огляд функціонального прототипу.
Проєктування і розробка	Визначення конструктивного прототипу	Визначення функціональних і нефункціональних вимог системи. На основі цих вимог повинна бути створена стратегія реалізації. Якщо існує запис про тестування з попередньої ітерації, тоді він теж буде використаний для створення стратегії реалізації.
	Узгодження планів	Відбувається узгодження як і в які терміни повинні бути реалізовані поставлені вимоги.
	Створення конструктивного прототипу	Створення системи (конструктивного прототипу), яку можна віддати користувачам для тестування.
	Аналіз конструктивного прототипу	Перевірити справність спроєктованої системи. На цьому підетапі застосовується тестування та перегляд результатів. Створення користувальницької документації та протоколу випробування.
Реалізація	Затвердження системи користувачем	Кінцеві користувачі стверджують протестовану систему для подальшої реалізації і створення довідника користувача.
	Навчання користувачів	Навчання майбутнього користувача роботі з системою. Результат підетапу — контингент підготовлених користувачів.
	Реалізація	Реалізація протестованої системи серед користувачів.
	Аналіз ринку системи	Аналіз впливу випущеної системи на ринок. Головне питання — чи досягнута мета, поставлена при проєктуванні системи. Ґрунтуючись на цьому, проєкт переходить на наступну стадію (постпроєктную) або повертається на попередню для доопрацювання. Аналіз буде представлений в документі аналізу проєкту.

Чотири етапи життєвого циклу проєкту[ред. | ред. код]

Етап 1А: Дослідження реалізованості[ред. | ред. код]

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

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

Етап 1Б: Дослідження економічної доцільності[ред. | ред. код]

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

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

Етап 2: Створення функціональної моделі[ред. | ред. код]

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

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

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

Етап 3: Проєктування та розробка[ред. | ред. код]

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

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

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

Етап 4: Реалізація[ред. | ред. код]

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

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

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

Етап створення функціональної моделі DSDM[ред. | ред. код]

Модель мета-даних[ред. | ред. код]

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

Поняття	Опис
Протокол можливих ризиків	Протокол виявлених ризиків. Важливий для подальших стадій, містить проблеми з якими є ймовірність зіткнутися. Повинен постійно оновлюватися.
Список вимог за пріоритетами	Список вимог, розподілених по пріоритету. Процес розподілу заснований на методі MoSCoW, який визначає які вимоги повинні бути реалізовані раніше (з економічної точки зору)
Список функціональних вимог	Список нефункціональних вимог, з якими доведеться мати справу на наступному етапі.
Функціональне вимога	Ця функція використовується для побудови моделі та прототипування згідно пріоритетам.
Функціональна модель	Модель, побудована на основі функціональних вимог. Вона буде використана для розробки прототипу на наступному подэтапе. Ця модель буде використана для створення плану прототипування.
Прототипування	Процес швидкого виготовлення працюючої моделі (прототипу) для того, щоб перевірити дизайн, проілюструвати закладені ідеї та функції і раніше зібрати відгуки користувачів.
Список інтервалів часу	Список інтервалів часу виконання окремих робіт, необхідний, щоб вкластися у графік виконання всього проєкту.
План прототипування	План процесу прототипування, який буде виконаний у часові інтервали згідно з графіком.
Графік робіт	Набір робіт і часу проведення цих робіт, погоджений сторонами. Використовується в реалізації функціонального прототипу.
Функціональний прототип	Прототип, що дозволяє побачити всі функції системи і те, як система буде ці функції виконувати.
План реалізації	Підготовка робіт для реалізації функціонального прототипу згідно з графіком робіт та списку вимог.
Покращена функція	Функція прототипу, яка була покращена і протестована на даній ітерації до об'єднання з іншими частинами прототипу.
Об'єднана функція	Функція прототипу, яка була об'єднана з функціями попередніх ітерацій. Новий об'єднаний функціональний прототип буде протестований на наступному етапі.
Протокол випробування	Запис тестування, що складається з сценарію тестування, процедури тестування та результатів тестування.
Документ аналізу функціонального прототипу	Складається з коментарів користувачів про поточної версії, необхідних для роботи над наступними ітераціями. Цей документ використовується для оновлення протоколу можливих ризиків та списку вимог.

Модель розвитку процесу[ред. | ред. код]

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

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

Дія	Піддія	Опис
Визначення функціонального прототипу	Аналіз вимог	Вимоги до поточного прототипу аналізуються згідно зі списком вимог, створеному раніше (у попередній ітерації та/або стадії).
	Список вимог на поточну ітерацію	Вибір функціональних вимог, які будуть реалізовані в прототипі на поточній ітерації, і створення списку функціональних вимог.
	Список функціональних вимог	Формування списку нефункціональних вимог до системи.
	Створення функціональної моделі	Аналіз коду моделі і прототипу і створення функціональної моделі.
Узгодження планів	Визначення часу	Визначення можливого розкладу проведення робіт по прототипированию згідно з планом і стратегією прототипування.
	Скласти план розробки	Створення плану прототипування, що включає всі роботи по прототипированию, які будуть виконані у часові інтервали згідно з графіком.
	Узгодження	Узгоджений графік того, як і в які терміни будуть виконані всі роботи по прототипированию.
Створення функціонального прототипу	Дослідження	Дослідження вимог; аналіз функціональної моделі і розробка плану реалізації на основі проведеного аналізу. Результати будуть використані для побудови прототипу наступного поддействии.
	Поліпшення	Реалізація функціональної моделі й плану реалізації для побудови функціонального прототипу. Потім цей прототип буде покращено перш, ніж об'єднати його з іншими функціями. Прототип доводиться до необхідної якості, щоб потім включити в готову систему.
	Об'єднання	Об'єднання покращеного функціонального прототипу з прототипом, розробленим на попередній ітерації. Отриманий прототип буде протестований у наступному кроці.
Аналіз функціонального прототипу	Тестування прототипу	Неодмінна частина методу DSDM, яка повинна бути присутніми протягом всього процесу. Протокол випробувань спільно з коментарями користувачів буде використаний для створення документа аналізу прототипу на наступній стадії.
Аналіз функціонального прототипу	Аналіз прототипу	Збираються коментарі користувачів та документація. Вони будуть відігравати важливу роль при розробці документа аналізу прототипу. На основі цього документу буде проведено оновлення списку вимог і протокол можливих ризиків, а також буде прийнято рішення проводити чи немає ще однієї ітерації стадії створення функціональної моделі.

Ще про DSDM[ред. | ред. код]

Основні методики DSDM[ред. | ред. код]

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

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

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

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

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

Прототипування[ред. | ред. код]

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

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

Робоча група

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

Моделювання

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

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

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

Ролі у DSDM[ред. | ред. код]

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

Ітеративна та інкрементна природа DSDM[ред. | ред. код]

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

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

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

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

Фактори, необхідні для успіху методу DSDM[ред. | ред. код]

В рамках DSDM існують такі фактори, які впливають на успіх проєкту.

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

Порівняння з іншими методами розробки інформаційних систем[ред. | ред. код]

Вже було розроблено і застосовано у справі безліч методів розробки інформаційних систем. Наприклад, Structured Systems Analysis and Design Method (SSADM), методи швидкої розробки додатків RAD, методи ООП. Більшість цих методів схожі один на одного і на DSDM.

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

Метод Rational Unified Process — найбільш схожий на DSDM, також є динамічним методом розробки інформаційних систем. І знову ж у ньому застосовується ітеративний підхід до розробки.

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

Див. також[ред. | ред. код]

Посилання[ред. | ред. код]

Сайт консорціуму DSDM

Примітки[ред. | ред. код]

↑ DSDM Atern Handbook (2008). 4 листопада 2015. Архів оригіналу за 8 квітня 2016. Процитовано 28 вересня 2016.
↑ Home page. DSDM Consortium. Архів оригіналу за 2 жовтня 2016. Процитовано 28 вересня 2016.

[1] DSDM Atern Handbook (2008). 4 листопада 2015. Архів оригіналу за 8 квітня 2016. Процитовано 28 вересня 2016.

[2] Home page. DSDM Consortium. Архів оригіналу за 2 жовтня 2016. Процитовано 28 вересня 2016.

[1]

[2]