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 розвиває положення про систему якості організації, формуючи критерії її досконалості – п'ять рівнів технологічної зрілості, які в принципі можуть бути досягнуті організацією-розробником. На кожному рівні встановлюються вимоги, при виконанні яких досягається стабілізація найбільш істотних показників процесів. Вихід на кожен рівень технологічної зрілості є результатом появи певної кількості компонентів у процесах створення ПЗ, що в свою чергу призводить до підвищення їх продуктивності та якості.


Рис. 1.


1.Начальний рівень – це основний стандарт. До даного рівню, як правило,


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


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


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


4. Керований рівень. На цьому рівні додаються такі процеси:



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


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



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


З градації рівнів видно, що технологічні вимоги зберігаються тільки до третього рівня, далі ж у основному йдуть вимоги до адміністративного управління. Тобто рівні 4 та 5 здебільшого управлінські і для їх досягнення важливо не тільки випустити програмний продукт, а й проаналізувати хід проекту, а також побудувати плани на майбутній проект, грунтуючись на поточних шаблонах. Застосування даних підходів має забезпечити планомірно-плавне поліпшення використовуваних процесів. Застосування RUP і робочих інструментів IBM Rational гарантує отримання як мінімум третього рівня CMM. Основними принципами методології RUP є:



  1. Ітераційний і інкрементний (нарощуваний) підхід до створення ПЗ.

  2. Планування і управління проектом на основі функціональних вимог до системи – варіантів використання.

  3. Побудова системи на базі архітектури ПЗ.

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


Ітераційний цикл грунтується на постійному розширенні та доповненні системи в процесі декількох ітерацій з періодичною зворотним зв'язком і адаптацією додаються модулів до існуючого ядра системи. Система постійно розростається крок за кроком, тому такий підхід називають ітераційним і інкрементний. Такий підхід виключає і занадто швидке написання коду (без детального опрацювання) і надмірно тривалий етап детального проектування та побудови моделей без зворотного зв'язку.


Рис. 2. Загальне уявлення RUP.


На малюнку показано загальне уявлення RUP у двох вимірах:



Ітераційний (ітеративний) і інкрементний (нарощуваний) підхід до створення ПЗ


Більшість команд, що розробляють програмне забезпечення, до цих пір використовує у своїх проектах каскадну розробку (waterfall process), при фази виконуються в чіткій послідовності: спочатку вимоги, потім аналіз і проектування, потім реалізація / інтеграція і потім тестування. Або, що більш зазвичай, модифіковану каскадну розробку з додаванням до вищеописаного ходу дій циклів зворотного зв'язку. Такий підхід змушує ключових членів групи простоювати досить тривалий час, а тестування відкладається на самий кінець життєвого циклу проекту, коли проблеми, як правило, є серйозними, виправляти їх дорого і це ставить під загрозу терміни виходу кінцевого продукту.


На противагу цьому RUP використовує ітеративних підхід (ітерація = повторення), тобто послідовність наростаючих кроків або ітерацій. Кожна ітерація включає в себе деякі або більшу частину дисциплін розробки (виявлення вимог, аналіз, проектування, реалізація тощо). У кожної ітерації є чітко визначений набір цілей, і вона створює частково працюючу реалізацію кінцевої системи. Кожна наступна ітерація будується на результатах попередніх, розвиває та вдосконалює систему до тих пір, поки не буде створено кінцевий продукт. Більш ранні ітерації більше концентруються на вимогах, аналізі і проектуванні, більш пізні – на реалізації і тестуванні.


Рис. 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>

*

*