揪心!"狼爸"捉毒蛇让女儿把玩 零下30度徒步2小时
| Цикл розробки програмного забезпечення |
|---|
 |
| Д?яльн?сть ? кроки |
| Допом?жн? дисципл?ни |
| Практики |
| ?нструменти |
| Стандарти та галуз? знань |
Метод розробки динам?чних систем (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).
У 2007 роц? команда, створена Консорц?умом DSDM, досл?джувала суть методу ? вир?шила, що основн? механ?зми ? структура написан? добре, але терм?нолог?я ? увагу методу були повн?стю сфокусован? на галуз? ?нформац?йних технолог?й. Тому вони повинн? бути вдосконален?, щоб в?дпов?дати потребам про?кт?в у новому тисячол?тт? (частина методу була незм?нна з 1995 року). Нова верс?я була випущена 24 кв?тня 2007 року в Cafe Royale в Лондон?.
Як розширення концепц?? швидко? розробки додатк?в, 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, повинн? бути членами цього некомерц?йного консорц?уму.
На початку 1990-х в ?ндустр?? ?нформац?йних технолог?й став поширюватись новий терм?н — швидка розробка додатк?в (Rapid Application Development, RAD). ?нтерфейси прикладних програм еволюц?онували в?д старих зелених екран?в до граф?чних ?нтерфейс?в користувача, як? використовуються ? зараз. На ринок почали виходити нов? ?нструменти для створення додатк?в, наприклад PowerBuilder. Вони дозволили розробникам прост?ше д?литися планованими розробками з покупцями — з'явилося прототипування ? почалося руйнування класичних, посл?довних (каскадних) метод?в розробки.
Тим не менш, новий рух RAD було дуже неструктурованим: не ?снувало узгодженого опису цього методу ? у багатьох орган?зац?й були створен? власн? описи ? п?дходи до нього. Безл?ч великих корпорац?й були зац?кавлен? в перспективах, що надаються методом, але вони також були стурбован? тим, щоб не знизився р?вень якост? ?х продукц?? в к?нцевому результат?.
Консорц?ум DSDM був утворений в 1994 роц?, коли група людей зустр?лася на заход?, орган?зованому Butler Group в Лондон?. Вс?, хто прийшов на цей зах?д, працювали у великих орган?зац?ях, таких як British Airways, American Express, Oracle and Logica (так? компан?? як Data Sciences ? Allied Domecq в?дтод? були поглинен? ?ншими орган?зац?ями).
На цьому з?бранн? було вир?шено, що Дженн?фер Степлтон, тод? представляла компан?ю Logica, розробить арх?тектуру комлексного, ор??нтованого на користувача методу з хорошим контролем якост? для ?теративно? ? ?нкрементн?й розробки. П?дсумкова арх?тектура була спро?ктована так, щоб бути повн?стю сум?сна з? стандартом ISO 9000 ? PRINCE2. Коли арх?тектура була готова (через м?сяць п?сля збор?в), Консорц?ум сформував групи для ?? поширення у вс?х областях розробки програмного забезпечення, як? включали в себе: методи та засоби управл?ння про?ктом, контроль якост? та тестування, методи ? засоби розробки. Контрольна група, очолювана творцем арх?тектури ? склада?ться з глав цих груп, повинна була забезпечити розум?ння методу так, як в?н спочатку замислювався.
Незважаючи на те, що багато член?в Консорц?уму були прямими конкурентами, вони в?льно д?лилися тим, як вони вир?шують проблеми, що виникають. Практика показала, що найкращий результат може бути досягнутий т?льки працюючи як одне ц?ле. Консорц?ум зб?льшився за перший р?к в?д дек?лькох орган?зац?й до ш?стдесяти; опис методу ставало все повн?шим. Верс?я 1 була сформована в грудн? 1994 року ? опубл?кована в лютому 1995 року. Результатом став ун?версальний метод, що охоплю? людей, процеси та ?нструменти. В?н сформувався на основ? досв?ду орган?зац?й, р?зних за родом сво?? д?яльност? ? розм?рами.
?сну? 9 принцип?в, що складаються з 4 основних та 5 початкових точок.
- Активне залучення к?нцевих користувач?в — це основа ведення ефективного про?кту, де розробники д?лять з користувачами робочий прост?р ? тому прийнят? р?шення будуть б?льш точними.
- Уповноважена команда — команда ма? бути уповноважена приймати важлив? для про?кту р?шення без узгодження з кер?вництвом.
- Часта поставка та оновлення — якомога част?ша поставка дозволя? викрити вади та недол?ки на значно ран?шому етап?. В?дпов?дно до DSDM ?поставити щось хороше ран?ше — це завжди краще, н?ж поставити все ?деально зроблено в к?нц??. Анал?з поставок верс?й з попередньо? ?терац?? врахову?ться на наступн?й.
- Потреби б?знесу як головний руш?й розробки — мета поставки програмного забезпечення - якомога краще в?дпов?дати поточним потребам ринку. Але в той же час постачання продукту, який задовольня? потребам ринку, не менш важлива, н?ж вир?шення критичних проблем у функц?онал? продукту.
- ?теративна та ?нкрементна розробка — ?рунту?ться на отриманн? зворотного зв'язку в?д користувача, задля досягнення оптимально? з економ?чно? точки зору р?шення.
- Бути в?дкритими для будь-яких зм?н — п?д час розробки завжди передбачати м?сце для зм?н ? вважати зм?ни - новою характеристикою про?кту.
- Дотримання висого р?вня початкових вимог — вимоги встановлюються на високому р?вн? перш, н?ж почнеться про?кт. Рекоменту?ться формулювати ?х в максимально простому вигляд? без занурення в детал?.
- Ефективна ?нтеграц?я розробки ? тестування — житт?вий цикл розробки передбача? залучення тестувальник?в протягом всього циклу, а не лише в к?нцевих стад?ях. На практиц? це може означати, що тесту?ться результат попередньо? ?терац??, коли йде розробка поточно?
- Фокус на вза?мод?? ? сп?впрац? — команда ма? дотримуватися атмосфери дов?ри ? чесност? м?ж ус?ма учасниками для покращення ефективност? процесу.
Щоб усп?шно використовувати DSDM, необх?дно щоб був виконаний ряд передумов. По-перше, необх?дно орган?зувати вза?мод?ю м?ж про?ктною командою, майбутн?ми користувачами ? вищим кер?вництвом. По-друге, повинна бути можлив?сть под?лу про?кту на менш? частини, що дозволить використовувати ?теративний п?дх?д.
Два приклади про?кт?в, для яких DSDM не дуже п?дходить:
- про?кти, критичн? безпеки розширене тестування та затвердження в таких про?ктах конфл?ктують з метою методу DSDM укластися в терм?ни ? бюджет.
- про?кти, чия мета зробити компоненти багаторазового використання — вимоги в таких про?ктах занадто висок? ? не вкладаються в принцип 80 %/20%.
Фреймворк DSDM склада?ться з трьох посл?довних стад?й, як? називаються передпро?ктна стад?я, стад?я житт?вого циклу про?кту ? постпро?ктна стад?я. Стад?я житт?вого циклу про?кту — сама продумана ? детально розроблена з ус?х ?нших. Вона склада?ться з п'яти етап?в, як? формують ?теративний, ?нкрементний п?дх?д до розробки ?нформац?йних систем. Ц? три фази ? в?дпов?дн? етапи будуть б?льш детально описан? в наступних розд?лах. Для кожно? стад?? або етапи будуть розглянут? найважлив?ш? функц?? ? будуть представлен? результати.
- Стад?я 1 — Передпро?ктна
- На ц?й стад?? визначаються ймов?рн? про?кти, в?дбува?ться вид?лення кошт?в та визначення про?ктно? команди. Р?шення задач на ц?й стад?? допоможе уникнути проблем на б?льш п?зн?х стад?ях про?кту.
- Стад?я 2 — Житт?вий цикл про?кту
- На рисунку зображена дана стад?я. На ньому показано 5 етап?в, як? потр?бно пройти про?кту, щоб стати ?нформац?йною системою. Перш? два етапи, досл?дження реал?зованост? та досл?дження економ?чно? доц?льност?, йдуть посл?довно ? доповнюють один одного. П?сля завершення цих етап?в, в?дбува?ться ?теративна та ?нкрементна розробка системи в етапах: створення функц?онально? модел?, про?ктування ? розробка, етап реал?зац??. ?теративна та ?нкрементна природа DSDM буде описана дал?.
- Стад?я 3 — Постпро?ктна
- На ц?й стад?? забезпечу?ться ефективна робота системи. Це досяга?ться за рахунок п?дтримки про?кту, його покращення та виправлення помилок зг?дно з принципами DSDM. П?дтримка про?кту зд?йсню?ться продовженням розробки, засновано? на ?теративно? ? ?нкрементн?й природ? DSDM. Зам?сть того, щоб зак?нчити про?кт за один цикл, зазвичай повертаються до попередн?х стад?й або етап?в, щоб пол?пшити продукт.
Нижче на д?аграм? представлений весь житт?вий цикл про?кту. Ця д?аграма опису? итеративную розробку DSDM. Опис кожного етапу буде представлено нижче.
| Д?я | П?дд?я | Опис |
|---|---|---|
| Досл?дження | Досл?дження реал?зованост? | На цьому етап? визнача?ться — потрапля? про?кт п?д рамки DSDM. Розглядаючи тип про?кту, орган?зац?йн? ? кадров? питання, виноситься р?шення — використовувати метод DSDM чи н?. Таким чином буде отримано зв?т про застосовн?сть, допустимий прототип ? приблизний глобальний план про?кту, який включа? в себе план розробки ? протокол можливих ризик?в. |
| Досл?дження економ?чно? доц?льност? | На цьому етап? анал?зують основн? економ?чн? ? технолог?чн? характеристики. В?дбува?ться нараду експерт?в, на як?й обговорюються найважлив?ш? сторони системи ? прийма?ться р?шення про пр?оритети у розробц?. На цьому етап? розробляються список основних вимог, опис сфери комерц?йно? д?яльност?, опис арх?тектури системи ? приблизний план створення прототип?в. | |
| Створення функц?онально? модел? | Визначення функц?онального прототипу | Визначення функц?оналу, який буде закладено в прототип? на цьому етап?. На цьому п?детап? розробля?ться функц?ональна модель в?дпов?дно до результат?в, отриманих на стад?? досл?дження економ?чно? доц?льност?. |
| Узгодження план?в | В?дбува?ться узгодження як ? в як? терм?ни ма? бути розроблена функц?ональн?сть прототипу. | |
| Створення функц?онального прототипу | Розробка функц?онального прототипу, зг?дно з планами та функц?онально? модел?. | |
| Анал?з функц?онального прототипу | Перев?рка справност? розробленого прототипу. Це може бути досягнуто тестуванням прототипу к?нцевим користувачем ?/або переглядом документац??. Результат — документ, що м?стить огляд функц?онального прототипу. | |
| Про?ктування ? розробка | Визначення конструктивного прототипу | Визначення функц?ональних ? нефункц?ональних вимог системи. На основ? цих вимог повинна бути створена стратег?я реал?зац??. Якщо ?сну? запис про тестування з попередньо? ?терац??, тод? в?н теж буде використаний для створення стратег?? реал?зац??. |
| Узгодження план?в | В?дбува?ться узгодження як ? в як? терм?ни повинн? бути реал?зован? поставлен? вимоги. | |
| Створення конструктивного прототипу | Створення системи (конструктивного прототипу), яку можна в?ддати користувачам для тестування. | |
| Анал?з конструктивного прототипу | Перев?рити справн?сть спро?ктовано? системи. На цьому п?детап? застосову?ться тестування та перегляд результат?в. Створення користувальницько? документац?? та протоколу випробування. | |
| Реал?зац?я | Затвердження системи користувачем | К?нцев? користувач? стверджують протестовану систему для подальшо? реал?зац?? ? створення дов?дника користувача. |
| Навчання користувач?в | Навчання майбутнього користувача робот? з системою. Результат п?детапу — контингент п?дготовлених користувач?в. | |
| Реал?зац?я | Реал?зац?я протестовано? системи серед користувач?в. | |
| Анал?з ринку системи | Анал?з впливу випущено? системи на ринок. Головне питання — чи досягнута мета, поставлена при про?ктуванн? системи. ?рунтуючись на цьому, про?кт переходить на наступну стад?ю (постпро?ктную) або поверта?ться на попередню для доопрацювання. Анал?з буде представлений в документ? анал?зу про?кту. |
Протягом цього етапу, перев?ря?ться реал?зац?я про?кту в рамках DSDM. Передумови для використання DSDM перев?ряються в?дпов?ддю на питання: ?чи Може цей про?кт задовольнити необх?дним економ?чним вимогам??, ?Про?кт п?дходить для використання методу DSDM?? ? ?Як? ризики в цьому про?кт? найважлив?ш???. Найважлив?ший метод на цьому етап? — використання робочих груп.
П?дсумок цього етапу — зв?т про застосовн?сть ? допустимий прототип, в яких розглянута реал?зац?я про?кту, а також приблизний глобальний план про?кту та протокол можливих ризик?в, що опису? найважлив?ш? ризики про?кту.
Досл?дження економ?чно? доц?льност? розширю? ? доповню? етап досл?дження реал?зованост?. П?сля того, як про?кт був визнаний реал?зованим у рамках DSDM, на ц?й стад?? перев?ряються б?знес-процеси, в?дбува?ться залучення груп користувач?в ? анал?з ?х вимог ? побажань. ? знову ж самим затребуваним методом на цьому етап? ? використання робочих груп. В рамках робочих груп учасники про?кту збираються, щоб обговорити плановану систему. ?нформац?я отримана п?сля даних заход?в збира?ться у список вимог. Важлива властив?сть цього списку — розпод?л пр?оритет?в серед вимог. Ц? вимоги розпод?лен? зг?дно з методом MoSCoW. На основ? отримано? черговост? створю?ться план розробки, який буде ор??нтиром для всього про?кту.
Для створення цього плану застосову?ться дуже важлива для про?кту методика — тайм-боксинг. Ця методика ? обов'язковою для досягнення ц?лей 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, ? належне управл?ння вимогами ? конф?гурац??ю протягом всього про?кту. Це забезпечу? реал?зац?ю вс?х вимог, поставлених на ранн?х стад?ях про?кту.
В рамках DSDM ?снують так? фактори, як? впливають на усп?х про?кту.
- Перше — прийняття методики DSDM кер?вництвом та вс?ма прац?вниками. Це забезпечу? мотивац?ю вс?х учасник?в з моменту запуску про?кту та ?х подальшу залучен?сть.
- Другий фактор виплива? з першого — готовн?сть кер?вництва забезпечити залучення к?нцевих користувач?в в роботу над про?ктом. Процес прототипування вимага? велико? залученост? користувач?в тестування та оц?нювання функц?ональних прототип?в.
- Трет? — про?ктна команда. Вона повинна складатися з досв?дчених член?в ? в результат? стати пост?йним об'?днанням. Важлива проблема — дов?ра ? вза?морозум?ння в про?ктн?й команд?. Це означа?, що команда волод?? правом ? можлив?стю приймати важлив? р?шення про про?кт без формального узгодження з кер?вництвом, що могло б в?дняти багато часу. Щоб команда могла усп?шно працювати над про?ктом, ?й потр?бн? необх?дн? засоби — середовище розробки, ?нструменти для управл?ння про?ктом ? т. д.
- Четверте. DSDM виступа? за прихильн? стосунки м?ж розробником ? покупцем. Це стосу?ться про?кт?в, як? розробляються всередин? самих компан?й, а також з використанням сторонн?х п?дрядник?в.
Вже було розроблено ? застосовано у справ? безл?ч метод?в розробки ?нформац?йних систем. Наприклад, Structured Systems Analysis and Design Method (SSADM), методи швидко? розробки додатк?в RAD, методи ООП. Б?льш?сть цих метод?в схож? один на одного ? на DSDM.
Метод екстремального програмування також використову? ?теративний п?дх?д до розробки ?нформац?йних систем ?з залученням користувач?в.
Метод Rational Unified Process — найб?льш схожий на DSDM, також ? динам?чним методом розробки ?нформац?йних систем. ? знову ж у ньому застосову?ться ?теративний п?дх?д до розробки.
?снують ? ?нш? методи, як? можуть здатися схожими на DSDM, але ?сну? ряд в?дм?нностей. По-перше, в?н нада? необх?дн? ?нструменти ? способи розробки. Це дозволя? користувачам особливим чином доповнити процес розробки сво?ми власними методами ? допомогти у прийнятт? р?шень. Ще одна ун?кальна особлив?сть — можна зм?нювати не час або засоби розробки, а вимоги до про?кту. Такий п?дх?д забезпечу? досягнення основних ц?лей DSDM — вкластися в час? ? не вийти за рамки бюджету. ? останн? — вза?морозум?ння ? сп?лкування м?ж вс?ма учасниками ? ?х залучен?сть у про?кт.
- Бережлива розробка програмного забезпечення
- Гнучка методолог?я розробки
- Закон Парето
- ?теративна та ?нкрементна розробка
- Екстремальне програмування
- PRINCE2
- RAD (програмування)
- Rational Unified Process
- Scrum
- ↑ DSDM Atern Handbook (2008). 4 листопада 2015. Арх?в ориг?налу за 8 кв?тня 2016. Процитовано 28 вересня 2016. [Арх?вовано 2025-08-14 у Wayback Machine.]
- ↑ Home page. DSDM Consortium. Арх?в ориг?налу за 2 жовтня 2016. Процитовано 28 вересня 2016.