Фаза впровадження (Transition)

Фаза конструювання (Construction)

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

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

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

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

Рисунок – Фази та дисципліни RUP

Шість інженерних дисциплін RUP

1 Дисципліни бізнес-моделювання

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

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

2 Дисципліни вимог

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

3 Дисципліна аналізу та проектування

Метою аналізу і проектування, є показати, яким чином система буде реалізована. Ціллю є створення системи, яка:

Виконує – в особливому середовищі реалізації – задачі та функції описані в описах прецедентів.

Виконує всі свої вимоги.

Легко змінити, коли змінюються функціональні вимоги.

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

4 Дисципліна реалізації

Метою реалізації є:

1) Визначити організацію коду з точки зору реалізації підсистем, які організовані в шари.

2) Реалізація класів та об'єктів у термінах компонентів (вихідних файлів, виконуваних файлів, та інших):

– для тестування розроблених компонент та модулів;

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

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

5 Дисципліна тестування

Цілі тестування:

1) Перевірити взаємодії між об'єктами.

2) Перевірити належну інтеграцію всіх компонентів програмного забезпечення.

3) Щоб переконатися, що всі вимоги були правильно виконані.

4) Щоб визначити та переконатись що дефекти будуть розглянуті до розгортання програмного забезпечення.

5) Переконатись, що всі дефекти виправлені, повторно перевірені та закриті.

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

6 Дисципліна розгортання

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

7 Три допоміжні дисципліни

7.1 Дисципліна середовища

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

7.2 Дисципліна конфігурації та управління змінами

7.3 Дисципліна управління проектами.

Шість кращих практик RUP

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

Дата добавления: 2014-01-11