IBM Rational Unified Process (RUP), Різне, Програмування, статті

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

На сьогоднішній день практично всі провідні компанії – розробники технологій і програмних продуктів (IBM, Microsoft, Oracle, Computer Associates, Sybase та ін) розташовують розвиненими технологіями створення ПО, які створювалися як власними силами, так і за рахунок придбання продуктів і технологій, створених невеликими спеціалізованими компаніями.


Rational Unified Process-Це одна з найбільш досконалих технологій, що претендують на роль світового корпоративного стандарту. RUP являє собою програмний продукт, розроблений компанією IBM Rational Software. RUP є результатом об’єднання підходів Rational Approach і Objectory Process, Що відбувся після злиття в 1995 році компаній Rational Software і Objectory AB (Створеної Іваром Якобсоном).


RUP в значній мірі відповідає стандартам і нормативним документам, пов’язаним з процесами життєвого циклу ПЗ і оцінкою технологічної зрілості організацій-розробників (ISO 12207, ISO 9000, CMM та ін.)


ISO – це стандарт якості будь-яких процесів, будь то випуск морозива або розробка програмного забезпечення, а CMM – Модель якості, спеціально співвіднесення з процесом розробки ПЗ. CMM – Великий багатоступінчастий стандарт якості, що охоплює весь цикл розробки програмного забезпечення: від проектування і до впровадження. Він годиться і для оптимізації і для поліпшення якості випускається ПО.


CMM – Модель зрілості процесів створення ПО, або модель розвитку здатності компанії розробляти якісне програмне забезпечення. Це описова модель в тому сенсі, що вона описує суттєві (Або ключові) атрибути, які визначають, на якому рівні технологічної зрілості знаходитися організація. CMM не є приписом, вона не наказує організації, яким чином розвиватися. CMM описує характеристики організації для кожного з рівнів технологічної зрілості, не даючи жодних інструкцій як переходити з рівня на рівень. Організації може знадобитися кілька років для переходу з першого рівня на другий і зовсім не мало часу для переходу з рівня на рівень далі.


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


Рис. 3. Ітеративна розробка в RUP.


Ітеративний підхід довів свої переваги в порівнянні з каскадним по багатьом пунктам.



Структура процесів в RUP


На рис.2 показана загальна архітектура Rational Unified Process. У процесу є два аспекти, або, якщо завгодно, два виміри:


Динамічне вимір


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



Кожна стадія завершується в чітко визначеній контрольній точці (milestone). В цей момент часу повинні досягатися важливі результати і приймаються критично важливі рішення про подальшу розробку.


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



На стадії розробки виконуються більш детальні вимоги до системи, виконується високорівнева аналіз предметної області та проектування для побудови базової архітектури системи, створюється план конструювання і усуваються найбільш ризиковані елементи проекту. Результатами стадії розробки є:



Стадія розробки займає близько п’ятої частини загальної тривалості проекту. Основними ознаками завершення стадії розробки є дві події:



RUP являє собою ітераційний і покроковий процес розробки, в якому програмне забезпечення розробляється і реалізується вроздріб. На стадії конструювання побудова системи виконується шляхом серії ітерацій. Кожна ітерація є свого роду міні-проектом. На кожній ітерації для конкретних варіантів використання виконуються аналіз, проектування, кодування, тестування та інтеграція. Ітерація завершується демонстрацією результатів користувачам і виконанням системних тестів з метою контролю коректності реалізації варіантів використання. Призначенням цього процесу є зниження ступеня ризику. Причиною появи ризику часто є відкладання вирішення складних проблем на самий кінець проекту. Тестування та інтеграція – це достатньо великі завдання, вони завжди займають більше часу, ніж очікується. Чим пізніше виконувати тестування та інтеграцію, тим більше важкими завданнями вони стають і тим більше здатні дезорганізувати весь проект.


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



Призначенням стадії введення в дію є передача готового продукту в розпорядження користувачів. Дана стадія включає:



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


Статичний вимір


Статичний аспект RUP представлений чотирма основними елементами:



Поняття «роль»(Role) визначає поведінку і відповідальність особистості або групи особистостей, що складають проектну команду. Одна особистість може грати в проекті багато різних ролей.


Під видом діяльності конкретного виконавця розуміється одиниця виконуваної ним роботи. Вид діяльності (Activity) відповідає поняттю технологічної операції. Він має чітко визначену мету, зазвичай виражається в термінах отримання або модифікації деяких робочих продуктів (Artifacts), таких, як модель, елемент моделі, документ, вихідний код або план. Кожен вид діяльності пов’язаний з конкретною роллю. Тривалість виду діяльності становить від декількох годин до декількох днів, він зазвичай виконується одним виконавцем і породжує тільки один або дуже невелика кількість робочих продуктів. Будь-який вид діяльності повинен бути елементом процесу планування. Прикладами видів діяльності можуть бути планування ітерації, визначення варіантів використання і діючих осіб, виконання тесту на продуктивність. Кожен вид діяльності супроводжується набором керівництв (Guidelines), що представляють собою методики виконання технологічних операцій.


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



і три допоміжних:



Тепер, коли ми розглянули основу структури Rational Unified Process, Можна перейти до безпосередньої розробки в RUP. Значна частина RUP пов’язана з розробкою та експлуатацією моделей розроблюваної системи. Моделі допомагають розуміти і окреслювати як проблему, так і її рішення. Модель – це спрощення дійсності, допомагає охопити велику, складну систему, не піддається розумінню в усі своїй повноті.


Уніфікований мова моделювання UML (Unified Modeling Language) – Це графічна мова візуалізації специфікації та документування артефактів переважно програмної системи. Мова UML являє собою стандартний засіб створення креслярської системи, а також конкретні поняття, такі як класи, написані на певних мовах програмування, схеми баз даних і програмні компоненти з можливістю повторного використання.


UML – Це стандартна мова зображення різних моделей; він не може підказати, як розробляти програмне забезпечення. Ця мова надає словник, але не пояснює, як написати книгу. Тому поряд з мовою UML корпорація IBM Rational Software розробила взаємодоповнюючий продукт – Rational Unified Process. RUP– Це консультант з питань ефективного використання мови UML в моделюванні. Він розповідає, які моделі необхідні, чому вони необхідні і як їх створювати.


При застосуванні та впровадженні RUP команди можуть допустити поширені помилки. Грунтуючись на досвіді фахівців з експлуатації з компанії Rational, придбаному при роботі з тисячами замовників протягом багатьох років підведемо підсумки. RUP – Це методологія, що дозволяє в широкому діапазоні вибирати ступінь формалізації і ітеративності процесу розробки в залежності від особливостей проектів і розробляє організації. За рахунок правильного вибору показників можливе істотне зниження вартості та / або термінів розробки при гарантії необхідної якості ПЗ. З іншого боку, RUP дозволяє легко підняти ступінь формалізму розробки, якщо це потрібно, наприклад, для виконання додаткових вимог замовника або для успішної сертифікації на досить високий рівень CMM. Добре освоєний RUP є універсальним процесом, який можна успішно використовувати в різних проектах. Для організації досить освоїти RUP і способи його налаштування, щоб мати в запасі кілька варіантів процесу розробки для різних типів проектів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*