DSDM

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
ТРПЗ
Цикл розробки програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги • Специфікація • Архітектура • Дизайн • Реалізація • Тестування • Розгортання (Реліз) • Супровід
Методології • Процес
Гнучка • Чистого приміщення • DSDM • Ітеративна • RAD • RUP • Спіраль • Водоспад • XP • Scrum • Lean • V-Model • FDD • TDD • BDD
Допоміжні дисципліни
Керування конфігурацією • Документування • Якість ПЗ • Управління проектами • Досвід користування
Інструменти
Компілятор • Зневаджувач • Профілювальник • GUI designer • IDE

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

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

Остання версія DSDM називається DSDM Atern. Назва Atern — це скорочення від Arctic Tern (пер. Полярна крачка). Полярна крачка — птиця, яка може подорожувати на великі відстані. Вона символізує безліч аспектів методу, наприклад визначення пріоритету або кооперування, які є природним способом ведення робочого процесу.

Попередня версія DSDM (випущена в травні 2003 року), яка все ще діє і широко використовується, — це DSDM 4.2, є дещо розширеною версією DSDM 4. Розширена версія містить настанови щодо того, як використовувати DSDM спільно з Екстремальним програмуванням (Extreme Programming).

Огляд DSDM Atern[ред.ред. код]

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

Огляд DSDM версії 4.2[ред.ред. код]

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

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

При деяких умовах існує можливість включення в DSDM частин інших методик, таких як Rational Unified Process (RUP), Екстремальне програмування, PRINCE2. Інший гнучкий метод, схожий на DSDM по процесу і концепції — Scrum.

Метод DSDM був розроблений у Великій Британії в 1990-х Консорціумом DSDM. Консорціум DSDM — це асоціація розробників та експертів в області програмного забезпечення, створена з метою «спільної розробки і просування незалежного фреймворку RAD» комбінуванням кращого практичного досвіду учасників асоціації. Консорціум DSDM — це некомерційна організація незалежних розробників, які володіють та управляють фреймворком DSDM. Перша версія фреймворку була завершена в січні 1995 року і опублікована в лютому 1995 року. У липні 2006 року була представлена відкрита версія DSDM 4.2, яка стала доступна приватним особам для перегляду і використання. Тим не менш, всі, хто поширює DSDM, повинні бути членами цього некомерційного консорціуму.

DSDM і Консорціум DSDM — ранні дні[ред.ред. код]

На початку 1990-х в індустрії інформаційних технологій став поширюватись новий термін — швидка розробка додатків (Rapid Application Development, RAD). Інтерфейси прикладних програм еволюціонували від старих зелених екранів до графічних інтерфейсів користувача, які використовуються і зараз. На ринок почали виходити нові інструменти для створення додатків, наприклад 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 укластися в терміни і бюджет.
  • проекти, чия мета зробити компоненти багаторазового використання — вимоги в таких проектах занадто високі і не вкладаються в принцип 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 — вкластися в часі і не вийти за рамки бюджету. І останнє — взаєморозуміння і спілкування між всіма учасниками і їх залученість у проект.

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

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

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

  1. DSDM Atern Handbook (2008). 2015-11-04. Процитовано 2016-09-28. 
  2. Home page. DSDM Consortium. Процитовано 2016-09-28.