1.1.3.1. Етапи

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

• Вимоги – збір бізнес-, технічних і прикладних вимог до проекту.

• Аналіз – бізнес- і прикладне моделювання на основі зібраних вимог.

• Проектування – створення архітектури на основі об’єктно-ориентированного підходу.

• Реалізація – розробка спроектованого додатка (на ранніх стадіях – розробка прототипів).

• Тестування – перевірка зробленої роботи.

Нижче опишемо основні етапи універсального процесу трохи докладніше.

Вимоги

Основне завдання етапу «Вимоги» – направити ітерацію на розробку додатка відповідно до вимог замовника й користувачів. Для цього необхідно описати додаток з тим ступенем деталізації, що достатня для досягнення згоди між замовником, користувачами й проектною групою щодо того, що додаток повинне робити й чого воно робити не повинне. Інформація на цій стадії збирається з безлічі джерел: від учасників проекту, з існуючих систем і документів, підготовлених замовником. У міру збору інформації проектна група створює попередній список вимог. Вимоги зручно структурувати, постачивши кожне з них короткою назвою й описом, статусом (пропозиція, прийнято, включено в остаточний список і т.п.), оцінкою вартості реалізації й описом ризиків, сполучених з виконанням цієї вимоги. До компетенції цього етапу ставиться й контекст, у якому буде працювати додаток. Автори універсального процесу рекомендують описувати контекст за допомогою бізнес-моделей або моделювання предметної області. Функціональні вимоги, що описують взаємодію додатка із суб'єктами й об'єктами контексту, описуються схемами використання. У процесі збору вимог необхідно проаналізувати й нефункціональні вимоги, наприклад, продуктивність, розширюваність і надійність. Вони можуть бути пов'язані з конкретними схемами використання або додані до моделі схем використання як нефункціональні вимоги до системи. Схеми використання повинні бути зрозумілі замовникові й користувачеві. Крім списку вимог, проектна група може створити набір проектів користувальницького інтерфейсу або прототипи, що описують взаємодію різних типів користувачів додатка.

Результати роботи етапу «Вимоги»:

• бізнес-модель (або модель предметної області), що задає контекст проектованої системи;

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

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

• список додаткових вимог, що не ставляться до конкретних схем використання.

Аналіз

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

Характеристики етапу «Аналіз» і його результати:

• уточнення вимог, сформульованих на попередньому етапі, включаючи уточнення моделі сценаріїв використання;

• аналітична модель формулюється мовою розробників, і тому на етапі «Аналіз» з'являється формалізм, що дозволяє судити про внутрішню структуру системи:

• аналітична модель структурує вимоги таким чином, що вони стають більш зрозумілими, тим самим підготовляючи їх до перетворення в проектні концепції;

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

Основний результат етапу «Аналіз» – архітектурне подання аналітичної моделі. Це подання включає наступне:

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

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

• Пакетування – організація класів і реалізацій схем використання у функціональні вимоги, що випливають зі схем використання. Пакет ґрунтується на схемі використання, що підтримує певний бізнес-процес, і конкретної користувальницької ролі або на групі схем використання, що допускають узагальнення або зв'язаних якими-небудь відносинами.

Проектування

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

На етапі проектування виконуються наступні роботи:

• визначаються структури підсистем (проектна модель);

• підсистеми розподіляються між рівнями (проектна модель);

• визначаються інтерфейси класів і об'єктів (проектна модель);

• активні класи зв'язуються з вузлами розгортання (модель розгортання).

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

Реалізація

Універсальний процес створювався на основі принципів спіральної моделі, тому припускає інкрементальний підхід до створення прототипів і розробці. Цей процес циклічно триває доти, поки всі необхідні функції не реалізовані, а проектна група повністю не задоволена реалізацією. Етап «Реалізація» являє собою практичне втілення етапу «Проектування»; зокрема, повинне існувати однозначна відповідність між проектними класами й кодом, створеним на етапі розробки. Кожний із класів може являти собою окремий модуль, що виконується, або, навпроти, один модуль здатний поєднувати кілька класів – спосіб визначається обраною мовою програмування й проектом пакетування додатка.

Етап «Реалізація» складається з:

• реалізації прототипу архітектури;

• реалізації компонентів (класів і об'єктів);

• тестування компонентів;

• інтеграції компонентів;

• складання додатка:

• створення тестів на основі схем використання;

• перевірки архітектури;

• планування наступного складання;

• переходу до наступної ітерації.

Тестування

Ціль цього етапу – звірення досягнутих результатів з очікуваними. Тестування починається по закінченні етапу «Реалізація» незалежно від того, випуском якого типу – внутрішнім, проміжним або зовнішнім завершується цей етап. На кожній ітерації тестова модель уточнюється: з неї вилучаються тести, що втратили актуальність, створюються схеми регресійного тестування й додаються тести для майбутніх складань. Кожний тест реалізує конкретний метод перевірки певних функцій додатка й включає умови тестування, необхідні вхідні дані й очікувані результати. Тести створюються на основі схем використання. Крім тестування додатка, необхідно передбачити тести процедури установки й коректності конфігурації додатка на кожній використовуваній платформі. Крім того, часто виявляється корисно створити компоненти, що автоматизують процес тестування.