Rational Unified Process
| Цикл розробки програмного забезпечення |
|---|
Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
| Стандарти та галузі знань |
Rational Unified Process (RUP) є ітеративним процесом розробки програмного забезпечення створеним Rational Software — підрозділом IBM з 2003. RUP не є єдиним, конкретним розпорядчим процесом, а скоріше фреймворком процесу, що має бути адаптованим організаціями які займаються розробкою та командами розробників які оберуть елементи процесу, які підходять під їх потреби.
Rational Unified Process (RUP) являє собою продукт, спочатку розроблений Rational Software, яка була придбана компанією IBM в лютому 2003 року. Продукт містить у собі базу знань з гіперпосиланнями, та прикладами артефактів і докладні описи для різних видів діяльності. RUP входить в продукт IBM Rational Method Composer (RMC), який дозволяє налаштування процесу.
До 1997 року, Rational придбав Verdix, Objectory, Requisite, SQA, Performance Awareness, та Pure-Atria. Поєднання баз досвіду цих компаній привело до вироблення семи «найкращих практик» сучасної програмної інженерії:
- Розробляти ітеративно, керуючись ризиками.
- Управляти вимогами
- Використовувати компонентну архітектуру
- Моделювати програмне забезпечення візуально
- Постійно перевіряти якість
- Контролювати зміни
- Підлаштовуватись
Ці найкращі практики рухали розробку продуктів Rational, та використовувались польовими командами Rational, щоб допомогти клієнтам вдосконалити якість, та передбачуваність їх розробницьких зусиль. Щоб зробити ці знання доступнішими, Філіпу Крачтену, було поставлено завдання збирати явні фреймворки сучасної розробки програмного забезпечення. Ці зусилля використовував заснований на HTML механізм доставки процесів розроблений Objectory. У результаті «Раціональний уніфікований процес» (RUP) завершив стратегічну опору для Rational:
- Адаптовний процес що направляє розробку
- Інструменти, що автоматизують використання цього процесу
- Сервіси, що прискорюють впровадження і процесу, і інструментів.
RUP заснований на наборі будівельних блоків, чи містить елементи, що описують те, що повинно бути зробленим, необхідні навички, та покрокове пояснення того, як досягаються конкретні цілі розробки. Основними будівельними блоками, чи елементами вмісту, є наступні:
- Ролі (хто). Роль визначає набір навичок, компетенції та відповідальності.
- Робочі продукти (що). Робочий продукт являє собою щось отримане з завдання, в тому числі всі документи і моделі, випущені під час роботи впродовж процесу.
- Завдання (як). Завдання описує одиницю роботи, яка доручена ролі, яка забезпечує значущий результат.
У кожній ітерації, завдання діляться на дев'ять дисциплін: шість «інженерних дисциплін» (бізнес-моделювання, вимоги, аналіз і проєктування, реалізація, тестування, розгортання) і трьох допоміжних дисциплін (конфігурація і керування змінами, управління проєктами, середовища).
RUP визначає життєвий цикл проєкту, що складається з чотирьох фаз. Ці фази дозволяють процесу, бути представленим на високому рівні, подібно до того як представляються проєкти у «водоспадному» стилі, хоча, по суті, ключем до процесу є ітерації розробки, які простягаються вздовж всіх фаз. Крім того, кожен етап має одну ключову ціль, та віху в кінці, яка позначає досягнення цілі.
Первинною ціллю є адекватна оцінка системи, як база для обчислення початкових розцінок та бюджету. На цьому етапі встановлюються бізнес випадки, які включають бізнес-контекст, фактори успіху (очікувані доходи, визнання на ринку, і т.д.), а також фінансовий прогноз. На додаток до бізнес випадку генерується базова модель прецедентів, план проєкту, попередня оцінка ризику і опис проєкту (основні вимоги до проєкту, обмеження та основні характеристики). Після їх завершення проєкт перевіряється на відповідність наступним критеріям:
- Зацікавлені сторони досягають згоди з визначення масштабів і оцінки вартості/термінів.
- Розуміння вимог як свідчення якості первинних прецедентів.
- Достовірність оцінок вартості/термінів, пріоритетів, ризиків, та процесу розробки.
- Глибина і ширина будь-якого архітектурного прототипу, який був розроблений.
- Встановлення базової лінії за допомогою якої можна порівняти фактичні витрати із запланованими витратами.
Якщо проєкт не пройде цей етап, що називається віхою життєвого циклу, він може бути як скасований так і повторений після переконструювання з метою кращого задоволення критеріїв.
Основна мета полягає в пом'якшенні ключових ризиків, виявлених на основі аналізу до кінця цієї фази. Фаза уточнення — фаза де проєкт починає набувати форми. На цьому етапі робиться аналіз предметної області, і архітектура проєкту отримує свою базову форму.
Ця фаза має пройти віху життєвого циклу архітектури (LCA), задовольняючи такі критерії:
- Модель прецедентів, в якій ідентифікуються прецеденти та актори, та розробляється більшість описів прецедентів. Модель прецедентів повинна бути завершена на 80%.
- Опис архітектури програмного забезпечення в процесі розробки програмної системи.
- Виконувана архітектура, яка реалізує архітектурно значимі прецеденти.
- Бізнес — випадки та список ризиків переглядаються.
- План розвитку проєкту в цілому.
- Прототипи, що явно зменшили кожен виявлений технічний ризик.
Якщо проєкт не може переступити цю віху, ще є час для того, щоб він був скасований або змінений. Тим не менше, після закінчення цього етапу, проєкт переходить в операцію з високим ступенем ризику, де зміни набагато складніші та згубні, при здійсненні.
Системна архітектура є ключовим елементом розробки, що отримується з аналізу предметної області.
Основна мета полягає в створенні програмної системи. На цьому етапі основна увага приділяється розробці компонентів та інших характеристик системи. Це етап, коли відбувається основна частина кодування. У більших проєктах може бути кілька фаз конструювання, в спробі поділити прецеденти на керовані сегменти, які можуть утворити презентабельні прототипи.
Цей етап створює перший реліз програмного забезпечення. Його завершення позначає віха початкової боєготовності.
Основна мета полягає в переведенні системи з розробки у продукт, зробивши її доступною та зрозумілою для кінцевого споживача. Діяльність у рамках цієї фази включає навчання кінцевих користувачів та обслуговчого персоналу, бета-тестування системи для перевірки її на відповідність очікуванням користувачів. Продукт також перевіряється на відповідність рівню якості, встановленого в початковій фазі.
Якщо всі вимоги задоволені, досягається віха релізу продукту, і цикл розробки завершується.
- Дисципліни бізнес-моделювання
- Бізнес-моделювання пояснює, як описати бачення організації, в якій буде розгортатись система і як використати це бачення для виділення процесу, ролей та обов'язків.
- Організації стають все залежнішими від ІТ систем, що вимагає від інженерів інформаційних систем знання того, як застосунок що вони розробляють вписується в організацію. Підприємства інвестують в ІТ, коли вони розуміють, конкурентні переваги і вартість що додає технологія. Метою бізнес-моделювання є по-перше встановити глибше розуміння та комунікаційний канал між бізнес інженерією та програмною інженерією. Розуміння бізнесу означає, що програмісти повинні розуміти структуру і динаміку цільової організації (клієнта), нинішні проблеми в організації, а також можливі удосконалення. Вони повинні також забезпечити загальне розуміння цільової організації між клієнтами, кінцевими користувачами та розробниками.
- Дисципліни вимог
Вимоги пояснюють, як виявити запити зацікавлених осіб і перетворити їх в набір вимог, робочих продуктів, що осягають створювану систему й надають детальні вимоги до того, що система повинна робити.
- Дисципліна аналізу та проєктування
- Метою аналізу і проєктування, є показати, яким чином система буде реалізована. Ціллю є створення системи, яка:
- Виконує — в особливому середовищі реалізації — задачі та функції описані в описах прецедентів.
- Виконує всі свої вимоги.
- Легко змінити, коли змінюються функціональні вимоги.
- Проєктування дає в результаті модель проєктування, а аналіз відповідно модель аналізу. Модель дизайну служить абстракцією вихідного коду; тобто модель дизайну працює «синькою», розміткою того як буде структурований та написаний вихідний код. Дизайн моделі складається проєктування класів структурованих в пакети і підсистеми з чітко визначеними інтерфейсами, які представляють, що стане компонентами у реалізації. Він також містить опис того, як об'єкти цих сконструйованих класів співпрацюють для виконання прецедентів.
- Дисципліна реалізації
- Метою реалізації є:
- Визначити організацію коду з точки зору реалізації підсистем, які організовані в шари.
- Реалізація класів та об'єктів у термінах компонентів (вихідних файлів, виконуваних файлів, та інших).
- * Для тестування розроблених компонент та модулів.
- * Для інтеграції результатів, отриманих окремими виконавцями (чи групами) у виконувану систему.
- Системи реалізуються через реалізацію компонентів. Процес описує як повторно використати існуючі компоненти, чи реалізувати нові компонетни з чітко визначеними відповідальностями, роблячи систему легше підтримуваною і збільшуючи можливості для повторного використання.
- Дисципліна тестування
- Цілі тестування:
- * Перевірити взаємодії між об'єктами.
- * Перевірити належну інтеграцію всіх компонентів програмного забезпечення.
- * Щоб переконатися, що всі вимоги були правильно виконані.
- * Щоб визначити та переконатись що дефекти будуть розглянуті до розгортання програмного забезпечення.
- * Переконатись, що всі дефекти виправлені, повторно перевірені та закриті.
- Раціональний уніфікований процес пропонує ітеративний підхід, а це означає, що тестування відбувається протягом всього проєкту. Це дозволяє виявляти дефекти якомога раніше, що радикально знижує вартість виправлення дефекту. Тести проводяться за чотирма вимірами якості:надійності, функціональності, продуктивності додатків і продуктивності системи. Для кожного з цих вимірів критеріїв якості, процес описує як пройти життєвий цикл планування, проєктування, виконання і оцінки тесту.
- Дисципліна розгортання
- Метою розгортання є успішно робити релізи продукту, та постачати програмне забезпечення для кінцевих користувачів. Вона охоплює широке коло заходів, у тому числі виробництво зовнішніх версій програмного забезпечення, запаковування програмного забезпечення та бізнес-додатків, розповсюдження програмного забезпечення, встановлення програмного забезпечення та надання допомоги і підтримки для користувачів. Хоча діяльність по впровадженню в основному зосереджена на перехідному етапі, багато які з цих заходів повинні бути включені в більш ранні етапи, щоб підготуватись до розгортання в кінці фази конструювання. Процеси Розгортування та середовищаіз RUP містять менше деталей, ніж інші робочі процеси.
- Дисципліна середовища
- Дисципліна середовища зосереджується на діяльності необхідній для налаштування процесу під проєкт. Вона описує Цей розділ потребує доповнення. (квітень 2010)
- Дисципліна конфігурації та управління змінами
- Цей розділ потребує доповнення. (квітень 2010)
- Дисципліна управління проєктами.
- Дисципліна управління проєктами та планування проєктів в RUP відбувається на двох рівнях Цей розділ потребує доповнення. (квітень 2010)
Шість найкращих практик як описані в RUP є парадигмою програмної інженерії, яка перечислює шість ідей яким варто слідувати при конструюванні будь-якого проєкту щоб мінімізувати провали, та збільшити продуктивність. Цими практиками є:[1][2]
- Ітеративна розробка
- Найкраще було б знати всі вимоги наперед; тим не менш, часто це не той випадок. Існує кілька процесів розробки програмного забезпечення, які мають справу з рішеннями які дозволяють зменшувати вартість в термінах фаз розробки.
- Управління вимогами
- Завжди пам'ятати вимоги встановлені користувачами.
- Використання компонент
- Розбиття складного проєкту не тільки пропонується, а є фактично неминучим. Це дає можливість тестувати окремі компоненти до того, як вони будуть інтегровані в більшу систему. Також, повторне використання коду є великим плюсом та може бути здійснене легше через використання ООП.
- Візуальне моделювання
- Використовуйте діаграми щоб представити всі основні компоненти, користувачів, та їх взаємодії. «UML», скорочено від Unified Modeling Language, є інструментом що може зробити це завдання більш здійсненним.
- Перевірка якості
- Завжди робіть тестування більшої частини проєкту в будь-який момент часу. Тестування стає важчим з розростанням проєкту, та воно має бути постійним фактором в будь-якому створенні програмного продукту.
- Контроль змін
- Багато проєктів створюються багатьма командами, іноді з різним місцезнаходженням, використовуючи різні платформи, і т.п. Як результат є важливим переконатись, що зміни які вносяться в систему синхронізуються та перевіряються постійно. (Див. Неперервна інтеграція).
Згадані нижче методики та / чи фреймворки не обов'язково конкурують з RUP на всіх фронтах, але роблять це різною мірою
- Cleanroom Software Engineering
- Dynamic Systems Development Method (DSDM)
- ICONIX Process легка, гнучка підмножина практик RUP
- Extreme Programming — корисний для маленьких проєктів з малими ризиками
- Microsoft Solutions Framework (MSF)
- Oracle Unified Method (OUM)
- OpenUP легка OpenSource гнучка версія RUP що підтримується IBM Rational, Number Six Software та іншими
- Personal Software Process (PSP) не є процесом розробки, а є процесом персонального менеджменту
- Scrum легка, гнучка підмножина практик RUP
- ↑ Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.
- ↑ Rational Unified Process white paper. Архів оригіналу за 1 травня 2009. Процитовано 22 квітня 2010.
| Це незавершена стаття про програмування. Ви можете допомогти проєкту, виправивши або дописавши її. |