Rational Unified Process

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Цикл розробки
програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація
Архітектура ·  Дизайн
Реалізація ·  Тестування
Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення
DSDM ·  Iterative ·  RAD ·  RUP
Spiral ·  Водоспад ·  XP ·  Scrum
Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування
Документування
Якість ПЗ
Управління проектами
Досвід користування
Інструменти
Компілятор ·  Зневаджувач
Профілювальник
GUI designer ·  IDE
Див. також
Стадії розробки програмного забезпечення


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. Поєднання баз досвіду цих компаній привело до вироблення семи «найкращих практик» сучасної програмної інженерії:

  1. Розробляти ітеративно, керуючись ризиками.
  2. Управляти вимогами
  3. Використовувати компонентну архітектуру
  4. Моделювати програмне забезпечення візуально
  5. Постійно перевіряти якість
  6. Контролювати зміни
  7. Підлаштовуватись

Ці найкращі практики рухали розробку продуктів Rational, та використовувались польовими командами Rational, щоб допомогти клієнтам вдосконалити якість, та передбачуваність їх розробницьких зусиль. Щоб зробити ці знання доступнішими, Філіпу Крачтену, було поставлено завдання збирати явні фреймворки сучасної розробки програмного забезпечення. Ці зусилля використовував заснований на HTML механізм доставки процесів розроблений Objectory. У результаті «Раціональний уніфікований процес» (RUP) завершив стратегічну опору для Rational:

  • Адаптовний процес що направляє розробку
  • Інструменти, що автоматизують використання цього процесу
  • Сервіси, що прискорюють впровадження і процесу, і інструментів.

Теми Раціонального Уніфікованого Процесу[ред.ред. код]

Будівельні блоки RUP[ред.ред. код]

RUP заснований на наборі будівельних блоків, чи містить елементи, що описують те, що повинно бути зробленим, необхідні навички, та покрокове пояснення того, як досягаються конкретні цілі розробки. Основними будівельними блоками, чи елементами вмісту, є наступні:

  • Ролі (хто). Роль визначає набір навичок, компетенції та відповідальності.
  • Робочі продукти (що). Робочий продукт являє собою щось отримане з завдання, в тому числі всі документи і моделі, випущені під час роботи впродовж процесу.
  • Завдання (як). Завдання описує одиницю роботи, яка доручена ролі, яка забезпечує значущий результат.

У кожній ітерації, завдання діляться на дев'ять дисциплін: шість «інженерних дисциплін» (бізнес-моделювання, вимоги, аналіз і проектування, реалізація, тестування, розгортання) і трьох допоміжних дисциплін (конфігурація і керування змінами, управління проектами, середовища).

Чотири фази життєвого циклу проекту[ред.ред. код]

Фази та дисципліни RUP

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

Початкова фаза[ред.ред. код]

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

  • Зацікавленими сторонами досягають згоди з визначення масштабів і оцінкою вартості/термінів.
  • Розуміння вимог як свідчення якості первинних прецедентів.
  • Достовірність оцінок вартості/термінів, приорітетів, ризиків, та процесу розробки
  • Глибина і ширина будь-якого архітектурного прототипу, який був розроблений.
  • Встановлення базової лінії за допомогою якої можна порівняти фактичні витрати в порівнянні із запланованим витратам.

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

Фаза уточнення[ред.ред. код]

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

Ця фаза має пройти віху життєвого циклу архітектури (LCA), задовольняючи такі критерії:

  • Модель прецедентів, в якій ідентифікуються прецеденти та актори, та розробляється більшість описів прецедентів. Модель прецедентів повинна бути завершена на 80%.
  • Опис архітектури програмного забезпечення в процесі розробки програмної системи.
  • Виконувана архітектура, яка реалізує архітектурно значимі прецеденти.
  • Бізнес — випадки та список ризиків переглядаються.
  • План розвитку проекту в цілому.
  • Прототипи, що явно зменшили кожен виявлений технічний ризик.

Якщо проект не може переступити цю віху, ще є час для того, щоб він був скасований або змінений. Тим не менше, після закінчення цього етапу, проект переходить в операцію з високим ступенем ризику, де зміни набагато складніші та згубні, при здійсненні.

Системна архітектура є ключовим елементом розробки, що отримується з аналізу предметної області.

Фаза конструювання[ред.ред. код]

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

Цей етап дає створює перший реліз програмного забезпечення. Його завершення позначає віха початкової боєготовності.

Фаза впровадження[ред.ред. код]

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

Якщо всі вимоги задоволені, досягається віха релізу продукту, і цикл розробки завершується.

Шість інженерних дисциплін[ред.ред. код]

Дисципліни бізнес-моделювання
Бізнес-моделювання пояснює, як описати бачення організації, в якій буде розгортатись система і як використати це бачення для виділення процесу, ролей та обов'язків.
Організації стають все залежнішими від ІТ систем, що вимагає від інженерів інформаційних систем знання того, як застосунок що вони розробляють вписується в організацію. Підприємства інвестують в ІТ, коли вони розуміють, конкурентні переваги і вартість що додає технологія. Метою бізнес-моделювання є по-перше встановити глибше розуміння та комунікаційний канал між бізнес інженерією та програмною інженерією. Розуміння бізнесу означає, що програмісти повинні розуміти структуру і динаміку цільової організації (клієнта), нинішні проблеми в організації, а також можливі удосконалення. Вони повинні також забезпечити загальне розуміння цільової організації між клієнтами, кінцевими користувачами та розробниками.
Дисципліни вимог

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

Дисципліна аналізу та проектування
Метою аналізу і проектування, є показати, яким чином система буде реалізована. Ціллю є створення системи, яка:
  • Виконує — в особливому середовищі реалізації — задачі та функції описані в описах прецедентів.
  • Виконує всі свої вимоги.
  • Легко змінити, коли змінюються функціональні вимоги.
Проектування дає в результаті модель проектування, а аналіз відповідно модель аналізу. Модель дизайну служить абстракцією вихідного коду; тобто модель дизайну працює «синькою», розміткою того як буде структурований та написаний вихідний код. Дизайн моделі складається проектування класів структурованих в пакети і підсистеми з чітко визначеними інтерфейсами, які представляють, що стане компонентами у реалізації. Він також містить опис того, як об'єкти цих сконструйованих класів співпрацюють для виконання прецедентів.
Дисципліна реалізації
Метою реалізації є:
  • Визначити організацію коду з точки зору реалізації підсистем, які організовані в шари.
  • Реалізація класів та об'єктів у термінах компонентів (вихідних файлів, виконуваних файлів, та інших).
* Для тестування розроблених компонент та модулів.
* Для інтеграції результатів, отриманих окремими виконавцями (чи групами) у виконувану систему.
Системи реалізуються через реалізацію компонентів. Процес описує як повторно використати існуючі компоненти, чи реалізувати нові компонетни з чітко визначеними відповідальностями, роблячи систему легше підтримуваною і збільшуючи можливості для повторного використання.
Дисципліна тестування
Цілі тестування:
* Перевірити взаємодії між об'єктами.
* Перевірити належну інтеграцію всіх компонентів програмного забезпечення.
* Щоб переконатися, що всі вимоги були правильно виконані.
* Щоб визначити та переконатись що дефекти будуть розглянуті до розгортання програмного забезпечення.
* Переконатись, що всі дефекти виправлені, повторно перевірені та закриті.
Раціональний уніфікований процес пропонує ітеративний підхід, а це означає, що тестування відбувається протягом всього проекту. Це дозволяє виявляти дефекти якомога раніше, що радикально знижує вартість виправлення дефекту. Тести проводяться за чотирма вимірами якості:надійності, функціональності, продуктивності додатків і продуктивності системи. Для кожного з цих вимірів критеріїв якості, процес описує як пройти життєвий цикл планування, проектування, виконання і оцінки тесту.
Дисципліна розгортання
Метою розгортання є успішно робити релізи продукту, та постачати програмне забезпечення для кінцевих користувачів. Вона охоплює широке коло заходів, у тому числі виробництво зовнішніх версій програмного забезпечення, запаковування програмного забезпечення та бізнес-додатків, розповсюдження програмного забезпечення, встановлення програмного забезпечення та надання допомоги і підтримки для користувачів. Хоча діяльність по впровадженню в основному зосереджена на перехідному етапі, багато які з цих заходів повинні бути включені в більш ранні етапи, щоб підготуватись до розгортання в кінці фази конструювання. Процеси Розгортування та середовищаіз RUP містять менше деталей, ніж інші робочі процеси.

Три допоміжні дисципліни[ред.ред. код]

Дисципліна середовища
Дисципліна середовища зосереджується на діяльності необхідній для налаштування процесу під проект. Вона описує
Дисципліна конфігурації та управління змінами
Дисципліна управління проектами.
Дисципліна управління проектами та планування проектів в RUP відбувається на двох рівнях

Шість найкращих практик[ред.ред. код]

Шість найкращих практик як описані в RUP є парадигмою програмної інженерії, яка перечислює шість ідей яким варто слідувати при конструюванні будь-якого проекту щоб мінімізувати провали, та збільшити продуктивність. Цими практиками є:[1][2]

Ітеративна розробка 
Найкраще було б знати всі вимоги наперед; тим не менш, часто це не той випадок. Існує кілька процесів розробки програмного забезпечення, які мають справу з рішеннями які дозволяють зменшувати вартість в термінах фаз розробки.
Управління вимогами 
Завжди пам'ятати вимоги встановлені користувачами.
Використання компонент 
Розбиття складного проекту не тільки пропонується, а є фактично неминучим. Це дає можливість тестувати окремі компоненти до того, як вони будуть інтегровані в більшу систему. Також, повторне використання коду є великим плюсом та може бути здійснене легше через використання ООП.
Візуальне моделювання 
Використовуйте діаграми щоб представити всі основні компоненти, користувачів, та їх взаємодії. «UML», скорочено від Unified Modeling Language, є інструментом що може зробити це завдання більш здійсненним.
Перевірка якості 
Завжди робіть тестування більшої частини проекту в будь-який момент часу. Тестування стає важчим з розростанням проекту, та воно має бути постійним фактором в будь-якому створенні програмного продукту.
Контроль змін 
Багато проектів створюються багатьма командами, іноді з різним місцезнаходженням, використовуючи різні платформи, і т.п. Як результат є важливим переконатись, що зміни які вносяться в систему синхронізуються та перевіряються постійно. (Див. Неперервна інтеграція).

Конкуруючі фреймворки та технології[ред.ред. код]

Згадані нижче методики та / чи фреймворки не обов'язково конкурують з RUP на всіх фронтах, але роблять це різною мірою

Виноски[ред.ред. код]

  1. Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.
  2. Rational Unified Process white paper