Методологія інженерії

програмного забезпечення

Тема 4. Rational Unified Process & Agile Unified

Process
Rational Unified Process (RUP)
 одна з ітеративних та інкрементних методологій розробки програмного
забезпечення
 підтримується компанією Rational Software (підрозділ IBM), оновлення процесу
відбувається приблизно двічі на рік. В якості мови моделювання в загальній базі
знань використовується мова Unified Modelling Language (UML).
 ітераційна розробка програмного забезпечення в RUP передбачає поділ проекту на
кілька дрібних проектів, які виконуються послідовно. Кожна ітерація розробки
чітко визначена набором цілей, які повинні бути досягнуті в кінці ітерації. Кінцева
ітерація передбачає, що набір цілей ітерації повинен в точності збігатися з
набором цілей, зазначених замовником продукту, тобто всі вимоги повинні бути
виконані.

Слайд 2
Rational Unified Process (RUP)
 досить добре формалізований, і найбільша увага приділяється початковим стадіям
розробки проекту - аналізу і моделювання. Таким чином, ця методологія
спрямована на зниження комерційних ризиків (risk mitigating) за допомогою
виявлення помилок на ранніх стадіях розробки. Технічні ризики (assesses)
оцінюються і «розставляються» відповідно до пріоритетів на ранніх стадіях циклу
розробки, а потім переглядаються з плином часу і з розвитком проекту протягом
наступних ітерацій. Релізи версій розподіляються таким чином, що найбільш
пріоритетні ризики усуваються першими.
 Rational Unified Process підтримується інструментами (tools), які автоматизують
більшу частину процесу. Вони використовуються для створення і підтримки різних
артефактів-моделей, зокрема, процесу програмної інженерії: візуального
моделювання, програмування, тестування і т.д. Вони незамінні в підтримці
документообігу, управлінням змінами (change management), а також
використовуються для управління конфігурацією (configuration management), яка
супроводжує кожну ітерацію.
Слайд 3
Rational Unified Process (RUP)
 Rational Unified Process є процесом, що налаштовується (configurable process),
оскільки немає такого процесу, що підходив би для всіх проектів розробки ПЗ.
RUP підходить як для маленьких команд розробників, так і для великих
продуктових компаній.
 містить Development Kit, забезпечуючи підтримку для конфігурації процесу для
задоволення потреб конкретної організації.
 охоплює багато з практик (best practices) сучасної розробки програмного
забезпечення в такій формі, яка підходить для широкого спектру проектів і
організацій.

Слайд 4
Історія RUP
 У 1996р. Rational придбала Objectory Process, створений Іваром Джакобсоном (Ivar
Jacobson) і його компанією. У наступних версіях процес був доповнений і
перейменований в Rational Unified Process.
 З 1998 р включені основні практики сучасної програмної інженерії
 З 1999р. влючає project management
 У період з 2000 по 2003рр. включені:
 техніки XP, які згодом вилилися в окремий процес
 процес тестування
 У 2003р. IBM купує Rational Software
 У 2006р IBM створює продукт, «заточений» під Agile проекти - OpenUP, який потім
трансформується в Agile Unified Process

Слайд 5
Основні складові процесу розробки по RUP

Для успішного процесу розробки необхідні три складові:

 процес (process) - описує, що ми робимо, в якому порядку і яким чином
 нотація (notation) - засіб спілкування
 набір утиліт (tools) - допомагає автоматизувати процес і керувати ним

Слайд 6
 Цикл проекта по RUP (RUP Lifecycle)

Горизонтальний вимір представляє час, відбиває динамічні аспекти процесів і оперує такими
поняттями, як стадії, ітерації і контрольні точки. Вертикальний вимір відображає статичні аспекти
процесів і оперує такими поняттями, як види діяльності (технологічні операції), робочі продукти,
виконавці і дисципліни (технологічні процеси).

Слайд 7
Цикл проекта по RUP (RUP Lifecycle)

 Початкова фаза (Inception)

 Фаза розробки (Уточнення, Elaboration)
 Фаза конструювання (Construction)
 Фаза введення в дію (Розгортання, Transition)

Кожна стадія завершується в чітко визначеній контрольній точці (milestone). У цей

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

Слайд 8
Початок проекту по RUP (Project Inception) - 1

Основна мета на даному етапі полягає у визначенні обсягу проекту (project scope)
адекватно початкових витрат і бюджету. На цьому етапі складаються:
 бізнес-кейси (business cases), які включають бізнес-контекст (business
context), фактори успіху (success factors): очікуваний дохід, визнання ринку і
т.д .;
 фінансовий прогноз;
 базова модель варіантів використання (use cases);
 план проекту;
 первісна оцінка ризику;
 опис проекту (основні вимоги, обмеження і ключові особливості).

Слайд 9
Початок проекту по RUP (Project Inception) - 2
Після визначення всього перерахованого вище, проект перевіряється за
наступними критеріями:
 Узгодження з усіма зацікавленими сторонами (stakeholders) визначення змісту,
оцінок витрат і календарних оцінок.
 Розуміння вимог, як свідчення правильності початкових варіантів використання
(use cases) (ступінь готовності - 10-20%).
 Достовірність оцінок витрат і календарних оцінок, пріоритетів, ризиків і процесу
розробки.
 Глибина і масштаб будь-якого розробленого архітектурного прототипу.
 Визначення вихідних умов (baseline) для порівняння фактичних витрат і
планових витрат.
Якщо проект не проходить цю контрольну точку (віху, milestone), звану
цільовою контрольною точкою життєвого циклу, проект може бути або
скасований, або переглянутий після переробки з метою відповідності
перерахованим вище критеріям.

Слайд 10
Фаза розробки (Elaboration Phase) - 1
 Основна мета фази розробки полягає в тому, щоб пом'якшити ключові елементи
ризику, виявлення за допомогою аналізу до кінця цієї фази. На фазі розробки
проект починає набувати свій вигляд.
 На цьому етапі виявляються більш детальні вимоги до системи, виконується
високорівневий аналіз предметної області та проектування для побудови базової
архітектури системи, створюється план конструювання.

Слайд 11
Фаза розробки (Elaboration Phase) - 2
Результатами етапа розробки є:
 Модель сценаріїв використання (прецедентів), в якій сценарії використання (use
cases) і актори (actors) ідентифіковані і більшість описів прецедентів розроблені.
Модель сценаріїв використання повинна бути готова на ~ 80%.
 Перелік додаткових вимог, включаючи вимоги нефункціонального характеру і
вимоги, не пов'язані з конкретними варіантами використання.
Опис базової архітектури майбутньої системи.
Працюючий прототип(и), який реалізує архітектурно значущі прецеденти і
пом'якшує кожен ідентифікований технічний ризик.
Переглянуті бізнес-кейси і список ризиків.
План розробки всього проекту, що відображає ітерації і критерії оцінки для кожної
ітерації.
Попереднє керівництво користувача (опціонально).

Слайд 12
Фаза розробки (Elaboration Phase) - 3
 Фаза розробки займає близько п'ятої частини загальної тривалості проекту.
 Фаза розробки повинна завершуватися архітектурною контрольною точкою
проекту (lifecycle architecture milestone), критерії завершення якої полягають у
відповідях на наступні питання:
 Чи є бачення продукту (product vision) стабільним?
 Чи є архітектура стабільною?
 Чи розглянуті та вирішені основні елементи ризику?
 Чи є план фази конструювання досить докладним і точним?
 Чи згодні всі зацікавлені сторони, що поточне бачення може бути досягнуто за
допомогою поточного плану в контексті поточної архітектури?
 Чи є фактичні та / або плановані витрати ресурсів прийнятними?
 Якщо проект не може пройти цю контрольну точку, він все ще може бути
скасований або змінений. Проте, після виходу з цієї фази, проект переходить в
стан з високим ступенем ризику, де зміни внести набагато складніше.
 Ключовим об'єктом аналізу фази розробки є архітектура системи
Слайд 13
Фаза конструювання (Construction Phase) - 1
 Основна мета фази полягає в створенні програмного забезпечення системи. На
цьому етапі основна увага приділяється розробці компонентів і інших функцій
системи.
 Фаза конструювання розбита на ітерації, які є одночасно інкрементними і
повторюваними:
 ітерації є інкрементними відповідно до тієї функції, яку вони виконують. Кожна
ітерація додає чергові конструкції до варіантів використання, реалізованих під
час попередніх ітерацій;
 ітерації є повторюваними по відношенню до розроблюваного коду. На кожній
ітерації деяка частина існуючого коду переписується з метою зробити його
більш гнучким.
 У великих проектах, фаза конструювання може бути розбита на кілька ітерацій
шляхом розбиття сценаріїв використання на керовані сегменти.

Слайд 14
Фаза конструювання (Construction Phase) - 2
 Результатом стадії конструювання є продукт, готовий до передачі кінцевим
користувачам. Як мінімум, він містить наступне:
 ПЗ, інтегроване на необхідних платформах;
   керівництва користувача;
   опис поточної реалізації.
 Завершення фази конструювання відзначено контрольної точкою початку
експлуатації ПЗ (initial operational capability milestone).

Слайд 15
Фаза введення в дію (Розгортання, Transition Phase)
 Основна мета фази полягає в «транзиті» системи від стадії розробки до стадії
виробництва (production), що робить її доступною кінцевому користувачеві.
 Види діяльності (activities) цієї фази включають :
 навчання кінцевих користувачів і систему підтримки;
 бета-тестування системи з метою її валідації очікуванням кінцевих користувачів;
 паралельне функціонування з існуючою (legacy) системою, яка підлягає поступової
заміни;
 конвертація баз даних;
 оптимізацію продуктивності.
 Крім того, система проходить етап оцінювання (evaluation), тобто будь-який розробник,
який не виробляє необхідний обсяг робіт повинен бути замінений або видалений з
проекту.
 Продукт перевіряється на відповідність рівню якості, встановленого на початковій фазі.
 Якщо всі цілі досягнуті, цикл розробки завершується контрольною точкою релізу
продукту.

Слайд 16
Статичний аспект RUP
Статичний аспект RUP представлений
чотирма основними елементами:
 ролі (roles, workers) – ‘who’;
 види діяльності (activities) – ‘how’;
 робочі продукти (артефакти, artefacts)
– ‘what’;
 дисципліни (disciplines, workflows) –
‘when’.

Слайд 17
Поняття ролі в RUP

Поняття "роль" (role) визначає поведінку і відповідальність особистості або групи

особистостей, складових проектну команду. Одна людина може грати в проекті
багато різних ролей.

Слайд 18
Види діяльності і артефакти в RUP
 Вид діяльності (activity) - одиниця виконуваної роботи будь-яким виконавцем;
відповідає поняттю технологічної операції. Він має чітко визначену мету, зазвичай
виражається в термінах одержання або модифікації деяких робочих продуктів
(artifacts), таких, як модель, елемент моделі, документ, вихідний код або план.
 Кожен вид діяльності пов'язаний з конкретною роллю.
 Тривалість виду діяльності становить від декількох годин до декількох днів, він
зазвичай виконується одним виконавцем і породжує тільки один або дуже
невелику кількість робочих продуктів. Будь-який вид діяльності повинен бути
елементом процесу планування.
Приклади: планування ітерації, визначення варіантів використання і дійових осіб,
виконання тесту на продуктивність.
 Кожен вид діяльності супроводжується набором посібників (guidelines), що
представляють собою методики виконання технологічних операцій.

Слайд 19
Дисципліни в RUP
Дисципліна (discipline, workflow) відповідає поняттю технологічного процесу і
являє собою послідовність дій, що приводить до отримання відчутного результату.
В рамках RUP визначені шість основних дисциплін:
 побудова бізнес-моделей;
 визначення вимог;
 аналіз і проектування;
 реалізація;
 тестування;
 розгортання;
и три допоміжних:
 управління конфігурацією і змінами;
 управління проектом;
 створення інфраструктури.

Слайд 20
Основні дисципліни RUP (disciplines, workflows) - 1
 Business modeling (побудова бізнес-моделей) - передбачає аналіз вимог на даній
ітерації життєвого циклу, визначення бажаних параметрів системи і потреб
користувачів;
 Requirements (визначення вимог) - формалізація образу системи. Передбачає
збір вимог і управління вимогами, переклад вимог до функціональних
специфікації. Тут починається аналіз і побудова варіантів використання.
Результатом є документи рівня менеджменту;
 Analysis and design (аналіз і проектування) - передбачає переклад зібраних
вимог в формалізовану програмну модель. Результатом є опис системи на фазі
реалізації (технічний проект)-документи рівня розробників системи. Мова
формалізації -UML.

Слайд 21
Основні дисципліни RUP (disciplines, workflows) - 2
 Implementation (Реалізація, кодування) - передбачає власне написання коду.
Елементи коду в RUP вже створені на етапі аналізу і дизайну, оскільки засіб
реалізації UML - Rational Rose - дозволяє створювати елементи коду на декількох
мовах програмування.
 Test (тестування) - передбачає тестування продукту на даній ітерації. Regression
testing (регресійне тестування) в даному випадку має містити всі актуальні тести
від попередньої ітерації та проектні тести від попередньої transition-фази;
 Deployment (розгортання) - передбачає установку продукту на стороні
замовника, підготовку персоналу, запуск системи, приймально-здавальні
випробування, підготовка стандартів упаковки і поширення продукту, передача
матеріалів відділу продажів (дії опційні в залежності від специфіки продукту).

Слайд 22
Дисципліни підтримки RUP (supporting workflows)
 Configuration management (управління конфігурацією і змінами) - потужний
шар адміністративних дій, спрямованих на управління версіями продукту, що
передбачає контроль вихідного коду (моделей, виконуваних модулів, тестів,
документації), контроль версій продукту, наявність корпоративних стандартів
розробки коду і документації, відстеження змін і помилок (bug tracking); тісно
пов'язаний з тестуванням і підтримкою користувачів (customers support);
 Management (управління проектом) - передбачає набір адміністративних дій
управління проектом відповідно до ідеології RUP, використовуються засоби
управління проектом;
 Environment (створення інфраструктури) - передбачає створення і підтримку
засобів аналізу, проектування, розробки, тестування (як програмне, так і апаратне
забезпечення).

Слайд 23
RUP best practices

 Ітеративна розробка (Develop iteratively)

RUP підтримує ітеративний підхід розробки, враховує найвищі елементи ризику на
кожному етапі життєвого циклу. Ризики можна знизити шляхом демонcтрації прогресу,
працездатних релізів, які залучають кінцевого користувача, і зворотного зв'язку.
 Управління вимогами (Manage requirements)
RUP описує, як виявити, систематизувати і задокументувати необхідну функціональність
і обмеження; відслідковувати і документувати компроміси і рішення; і проводити
комунікацію по бізнес-вимогам.
Поняття прецедентів і сценаріїв, описаних в процесі, вже показали свої переваги при
створенні функціональних вимог, які переростають в архітектуру, реалізацію та
тестування програмного забезпечення. Це підвищує ймовірність того, що остаточна
система задовольняє потреби кінцевих користувачів. Вони забезпечують комунікацію
між розробкою і системою, що поставляється.

Слайд 24
RUP best practices - 2
 Використання модульних архітектур (Use components)
Процес фокусується на ранній розробці та затвердження виконуваної архітектури до виділення
ресурсів для повномасштабної розробки. Він описує, як розробити гнучку, інтуїтивно зрозумілу
архітектуру, що пристосовуються до змін, а також сприяє більш ефективному повторному
використанню ПЗ.
RUP підтримує розробку ПЗ на основі компонентів (component-based software development),
якими є нетривіальні модулі, підсистеми, що виконують чітку функцію. Компоненти можуть
бути побудовані або в спеціальній архітектурі, або в інфраструктурі компонентів (наприклад,
CORBA і COM та ін.)
 Візуальне моделювання (Model visually)
Процес показує, як візуально змоделювати ПЗ, щоб відобразити структуру і поведінку
архітектури і компонентів. Це дозволяє приховати деталі і писати код, використовуючи
"графічні будівельні блоки" (graphical building blocks). Візуальні абстракції допоможуть зв'язати
різні аспекти програмного забезпечення; побачити, як елементи системи узгоджуються один з
одним; переконатися, що будівельні блоки відповідають вашому коду; підтримувати
узгодженість між дизайном і його реалізацією; а також забезпечувати однозначну зв'язок між
ними.
Індустріальний стандарт Unified Modeling Language (UML), створений Rational Software, є
основою для успішного візуального моделювання.
Слайд 25
RUP best practices - 2

 Верифікація якості (Verify quality)

RUP за допомогою представлених інструментів (напр. Rational TestManager) дозволяє
підтримувати систему верифікації якості розроблюваного ПЗ.

 Відстеження змін (Control changes)

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

Слайд 26
Продукти, що підтримують RUP (Rational Suite)
 Rational Rose - CASE-засіб візуального моделювання інформаційних систем, що має
можливості генерування елементів коду. Спеціальна редакція продукту - Rational Rose
RealTime - дозволяє на виході отримати виконуваний модуль;
 Rational Requisite Pro - засіб управління вимогами, що дозволяє створювати,
структурувати, встановлювати пріоритети, відстежувати, контролювати зміни вимог, що
виникають на будь-якому етапі розробки компонентів додатку;
 Rational ClearQuest - продукт для управління змінами та відстеження дефектів в
проекті (bug tracking), тісно інтегрується із засобами тестування і управління вимогами і
представляє собою єдине середовище для зв'язування всіх помилок і документів між
собою;
 Rational SoDA - продукт для автоматичного генерації проектної документації, що
дозволяє встановити корпоративний стандарт на внутрішньофірмові документи. Можливо
приведення документації до існуючих стандартів (ISO, CMM);
 Rational Purify - вельми потужний засіб пошуку помилок в run-time для розробників
додатків і компонентів, що програмують на C / C ++;
 Rational Visual Quantify - засіб вимірювання характеристик для розробників додатків і
компонентів, що програмують на C / C ++, Visual Basic і Java; допомагає визначати і
усувати вузькі місця в продуктивності ПО;
Слайд 27
 Продукти, що підтримують RUP - 2
 Rational Visual PureCoverage - автоматично визначає області коду, зміст яких не
підлягає тестуванню;
 Rational ClearCase - продукт для управління конфігурацією програм (Rational's Software
Configuration Management, SCM), що дозволяє проводити версійний контроль всіх
документів проекту. З його допомогою можна підтримувати кілька версій проектів
одночасно, швидко переключаючись між ними. Rational Requisite Pro підтримує
оновлення та відстежує зміни у вимогах для групи розробників;
 SQA TeamTest - засіб автоматизації тестування;
 Rational TestManager - система управління тестуванням, яка об'єднує всі пов'язані з
тестуванням інструментальні засоби, артефакти, сценарії і дані;
 Rational Robot - інструмент для створення, модифікації та автоматичного запуску
тестів;
 SiteLoad, SiteCheck - кошти тестування Web-сайтів на продуктивність і наявність
непрацюючих посилань;
 Rational PerformanceStudio - вимір і передбачення характеристик продуктивності
систем.

Слайд 28
Rational Rose
 Відмінності RUP та процесів Agile
 RUP використовує визначені фази. Життєвий цикл проекту ділиться на чотири
фази: початкова, фази розробки, конструювання і розгортання. Кожна з фаз
складається з ітерацій, які роблять більший акцент на артефакти, що відносяться до
конкретної фази. Наприклад, ітерації в початковій фазі роблять більший акцент на
баченні продукту / проекту, в той час як ітерації на етапі розробки роблять більший
акцент на архітектурно-релевантних компонентах системи, що розробляється.
 Виконання робіт початкової фази і фази розробки без мінімального кодування.
Хоча команді рекомендується виконувати хоча б мінімальну розробку програмного
забезпечення на цих фазах, на практиці більшість команд використовують ці фази для
формалізації специфікацій. Після того, як ці фази будуть завершені, очікується, що
команди попередньо розподіляють більшу частину роботи на ітерації фази розробки. У
деякому роді команди можуть відчути, що після цих фаз укладено контракт, що
підриває Agile-цінності «співпраця з клієнтами більш пріоритетна, ніж переговори за
контрактом» і «реагування на зміни більше пріоритетні, ніж відповідність плану».

Слайд 30
 Відмінності RUP та процесів Agile
 RUP визначає більше ролей. У той час як підходи Agile воліють враховувати всю
команду, RUP пропонує велику кількість ролей.

 RUP пропонує більше артефактів. RUP використовує прецеденти і містить

рекомендації і шаблони для великої кількості документів. Наприклад, структура RUP
вимагає формального документа з архітектури програмного забезпечення (SAD) і аналізу
використання (реалізації). У зв'язку з цим можна сказати, що цінності Agile в «RUP»
можуть бути схильні до ризику: «Робоче програмне забезпечення понад повну
документацію» і «Особистість і взаємодія понад процесів та інструментів».

 RUP є use-case driven, model-heavy. У RUP передбачається, що вимоги описані як

варіанти використання і що моделі UML використовуються протягом усього процесу. Хоча
в Agile більшість команд використовують історії користувачів, це не обов'язково.

Слайд 31
 Agile Unified Process
 Agile Unified Process (AUP) - спрощена версія Rational Unified Process (RUP),
розроблена Скоттом Амблером. Методологія описує простий і зрозумілий підхід до
розробки прикладного ПЗ для бізнесу з використанням гнучких методів і концепцій, які
все ще залишаються вірними принципам RUP. AUP застосовує гнучкі методи, включаючи
розробку через тестування (TDD), гнучке моделювання (AM), гнучке управління змінами
і рефакторинг для підвищення продуктивності.

Слайд 32
Agile Unified Process - дисципліни

Слайд 33
 Agile Unified Process - дисципліни
 Моделювання. Зрозуміти бізнес організації, проблемну область проекту і визначити
життєздатне рішення для вирішення проблемної області.
 Реалізація. Перетворення моделі в виконуваний код і виконання базового рівня
тестування, зокрема модульного тестування.
 Тестування. Оцінювання якості продукту (пошук дефектів, підтвердження того, що
система працює відповідно до архітектури і верифікація відповідності вимогам)
 Розгортання. Планування поставки системи і виконання плану, щоб зробити систему
доступною для кінцевих користувачів.
 Управління конфігурацією. Управління доступом до артефактів проекту (відстеження
версій артефакту, контроль і управління змінами в них).
 Управління проектом: управління ризиками, управління людьми (призначення
завдань, відстеження прогресу і т. д.) і координація з людьми і системами за рамками
проекту.
 Середовище. Підтримка інших зусиль, гарантія того, що необхідний персонал,
керівництво (стандарти і рекомендації) і інструменти (обладнання, програмне
забезпечення і т. д.), що доступні команді в міру необхідності.

Слайд 34
Agile Unified Process - релізи
Agile Unified Process розрізняє два типи ітерацій:
 Development release iteration призводить до розгортання в середовищі
забезпечення якості та / або демонстрації.
 Production Release iteration призводить до розгортання у виробничому
середовищі.

Слайд 35
Agile Unified Process - філософія
 Ваші співробітники знають, що вони роблять. Люди не збираються читати
детальну документацію по процесам, але вони час від часу будуть потребувати
високорівневих інструкцій і / або навчання.
 Простота. Все описано коротко, використовуючи кілька сторінок, а не тисячі з
них.
 Гнучкість. Agile UP відповідає цінностям і принципам гнучкої розробки
програмного забезпечення і Agile Alliance.
 Зосередьтеся на цінних видах діяльності (high-value activites).
 Незалежність від інструменту (tool independence). Ви можете
використовувати будь-який набір інструментів для підтримки Agile UP.
 Ви можете захотіти адаптувати AUP для задоволення ваших власних
потреб.

Слайд 36
Disciplined agile delivery (DAD)
 У 2012 році AUP був замінений дисциплінованою гнучкою доставкою (DAD).
 Disciplined Agile Delivery (Дисциплінована гнучка розробка) - підхід до
гнучкої розробки IT-рішень, який орієнтований на навчання і, в першу чергу,
враховує людський фактор. Підхід допускає масштабування і може
застосовуватися в масштабах підприємств, а не тільки невеликих команд.
Життєвий цикл підходу побудований на принципах «ризик - цінність» і
орієнтований на раннє досягнення поставлених цілей.
 Фреймворк є гібридний підходом, який доповнює Scrum "перевіреними"
стратегіями з різних областей: гнучкого моделювання, екстремального
програмування, канбана, ощадної розробки програмного забезпечення, Unified
Process (UP) та інших.
 DAD розроблений в компанії IBM.

Слайд 37
Disciplined agile delivery (DAD)
 Метою фреймворка стало розширення Scrum таким чином, щоб повністю описати
життєвий цикл розробки програмного забезпечення, починаючи з моменту
ініціації проекту, закінчуючи запуском продукту і його використанням кінцевими
користувачами.
 На відміну від прескриптивного підходу, використовуваного в Scrum і Extreme
Programming, Disciplined Agile Delivery використовує підхід, заснований на цілях.
В тому числі, DAD надає можливість вибору між декількома альтернативами, що
дозволяє модифікувати фреймворк у відповідність з кожної конкретної ситуації, і
підібрати стратегії, які підходять конкретним користувачам фреймворка.

Слайд 38
Disciplined agile delivery (DAD) - цілі
Початкова фаза Фаза конструювання Фаза розгортання

•Сформувати команду •Виробити потенційне споживче

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

Довгострокові цілі

•Виконання проектної місії

•Зростання членів команди
•Дозвіл ризиків
•Поліпшення командного процесу і середовища розробки
•Використання / розширення існуючої інфраструктури

Слайд 39
Disciplined agile delivery (DAD) - принципи
 People-first. На відміну від Scrum і Extreme Programming, Disciplined Agile
Delivery використовує підхід, заснований на цілях. В тому числі, DAD надає
можливість вибору між декількома альтернативами, що дозволяє модифікувати
фреймворк у відповідність кожної конкретної ситуації, і підібрати стратегії, які
підходять конкретним користувачам фреймворка.
DAD визначає надійний набір первинних і вторинних ролей.
 Learning-oriented (Орієнтований на навчання). Члени команди повинні тісно
співпрацювати і вчитися один у одного, команда повинна інвестувати зусилля,
щоб вчитися на своєму досвіді
 Гібридний. DAD використовує і адаптує перевірені стратегії з існуючих методів,
таких як Scrum, XP, гнучке моделювання, Unified Process (UP), Kanban, зовнішня
розробка програмного забезпечення і Agile Data (AD). Замість того, щоб витрачати
час на адаптацію однією з цих існуючих структур, з DAD всіх зусиль по
об'єднанню відповідних частин кожної техніки вже були виконані.

Слайд 40
Disciplined agile delivery (DAD) – принципи 2
 Повний життєвий цикл поставки. Життєвий цикл DAD підтримує весь проект з
моменту його початку аж до поставки і підтримки.
 Process goal driven. У порівнянні з Scrum, в якому пропонується, що вся робота
управляється через проектний беклог, DAD пропонує вибрати стратегію
приоритизации роботи, засновану на будь-які чинники, які найбільш важливі для
зацікавлених сторін проекту.
У підходах DAD стратегії можуть бути обумовлені кількома чинниками: вартістю
бізнесу, ризиками, термінами виконання, залежностями або будь-якої їх комбінації.
DAD описує компроміси, пов'язані з кожною стратегією, і обговорює їх життєздатність.
 Фокус на рішення. Гнучкі методології розробки фокусуються на просте виробництво
ПЗ для надання споживчих рішень, які забезпечують реальну цінність для
зацікавлених сторін. Хоча ПЗ, безумовно, є важливою частиною поставленї завдачі,
будучи орієнтованим на рішення, має на увазі цілісний погляд на загальну проблему.
Це може привести до пропонованих оновлень в апаратних засобах, бізнес /
організаційних процесах і загальних організаційних структурах.

Слайд 41
Disciplined agile delivery (DAD) – принципи 3
 Життєвий цикл. Життєвий цикл DAD орієнтований на ризики і продукт. Він
розширює життєвий цикл Scrum, який створює потенційно працююче ПЗ для
кожного спринту, так що він явно включає в себе легкі віхи, такі як:
забезпечення консенсусу зацікавлених сторін щодо обсягу проекту на ранньому
етапі життєвого циклу, затвердження архітектури з робочим кодом на ранньому
етапі життєвого циклу, забезпечення достатньої функціональності до фази
розгортання і забезпечення готовності production-середовища до фактичного
релізу рішення.
 Знання організації. Команди DAD працюють в корпоративній екосистемі
організації, як і будь-яка інша команда. В ідеалі команда DAD буде
використовувати наявні ресурси для скорочення загального часу постачання і
вартості і може працювати паралельно з іншими командами в організації.

Слайд 42