Методологія розробки ІВ
Уніфікований процес був розроблений Філіпом Крачтеном (Philippe Kruchten), Іваром Якобсоном (Ivar Jacobson) та іншими співробітниками компанії “Rational Software” як доповнення до мови моделювання UML. RUP є каркас для процесів, і таким
чином, включає в себе величезну кількість. Основною ідеєю уніфікованого процесу є розбиття процесу розробки на короткі ітерації фіксованої тривалості, а також забезпечення її адаптивності та еволюційності. До інших важливих принципів і концепцій уніфікованого процесу відносять такі.
Оцінка ризиків та ключових моментів проекту на ранніх ітераціях.
Постійний відгук користувачів, зворотний зв'язок та модифікація вимог.
Побудова загальної базової архітектури на ранніх ітераціях.
Постійний контроль якості, раннє та часте тестування в реальних умовах.
Візуалізація програмної моделі.
Уважне керування вимогами.
Обробка запитів на внесення змін та керування конфігурацією.
Як зазначалося, RUP використовує ітеративну модель розробки. В кінці кожної ітерації (в ідеалі триває від 2 до 6 тижнів) проектна команда повинна досягти запланованих на дану ітерацію цілей, створити або доопрацювати проектні артефакти і отримати проміжну, але функціональну версію кінцевого продукту. Повний життєвий цикл розробки продукту складається з чотирьох фаз, кожна з яких включає одну або кілька ітерацій:
Початок (Inception)
формуються бачення та межі проекту; створюється економічне обґрунтування (business case);
визначаються основні вимоги, обмеження таключова
функціональність продукту; створюється базова версія моделі прецедентів;
Проектування (Elaboration; Уточнення, Розвиток)
документування вимог (включаючи детальний опис для
більшості прецедентів); проектування, реалізацію та тестування виконуваної
архітектури; оновлення економічного обґрунтування та більш точні оцінки
термінів і вартості; зниження основних ризиків (за рахунок, наприклад, створення найбільш
Конструювання (Construction)
Впровадження (Transition)
Уніфікований процес передбачає виконання різних видів діяльності у межах певних дисциплін.
Дисципліна (discipline) - це набір видів діяльності (і пов'язаних з ним артефактів) в рамках одного етапу, наприклад, в рамках аналізу вимог. У контексті уніфікованого процесу артефактом (artifact) називається будь-який результат роботи: код, графічне зображення для Інтернету, схема бази даних, текстові документи, діаграми, моделі тощо. У рамках уніфікованого процесу існує кілька дисциплін. У цьому курсі увага буде зосереджена на деяких артефактах наступних чотирьох дисциплін.
Бізнес-моделювання (Business Modeling). Ця дисципліна передбачає розробку моделі предметної області, яка є візуальним уявленням найважливіших сутностей предметної області та його взаємозв'язків.
Вимоги (Requirements). У рамках цієї дисципліни створюється модель прецедентів та додаткова специфікація. У цих двох артефактах відображаються функціональні та нефункціональні вимоги.
Проектування (Design). Сюди належить модель проектування, що відбиває програмні об'єкти.
Мова UML. Методи використання UML.Model Driven Architecture. Executable
UML. Діаграми UML.
UML (Unified Modeling Language):
- універсальна мова візуального моделювання систем
- візуальна мова для визначення, конструювання та документування артефактів систем.
Підтримується OMG (Object Management Group)
- для створення проектної документації
- як мова програмування
Model Driven Architecture
Model Driven Architecture (MDA) – архітектура, керована моделлю.
- діаграми структури (structure diagrams)
o класів (Class)
o складових структур (Composite structure) (декомпозиція класу під час виконання)
o компонентів (Component)
o розгортання (Deployment)
o об'єктів (Object)
o пакетів (Package)
- діаграми поведінки (Behavior)
o діяльності (Activity)
o станів (State Machine)
o прецедентів (Use Case)
o взаємодії (Interaction)
§ огляду взаємодій (Interaction Overview)
11. Аналіз вимог. Модель вимог FURPS+. Функціональні та