Лекція 22. Ibm rational Unified Process (rup) icon

Лекція 22. Ibm rational Unified Process (rup)




Скачати 131.35 Kb.
НазваЛекція 22. Ibm rational Unified Process (rup)
Дата26.10.2012
Розмір131.35 Kb.
ТипЛекція

Лекція 22. IBM Rational Unified Process (RUP)

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

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

Багато компаній-розроблювачів вже усвідомили, що успіх програмних проектів залежить від однозначного визначення й грамотного документування процесу. Корпорація Rational Software ведучий виробник інструментарію для створення складних програмних систем, формалізувала технологічний процес розробки ПЗ й випустила на ринок структуровану базу знань під назвою Rational Unified Process (RUP), у яку ввійшли методичні рекомендації провідних розроблювачів по ефективному створенню додатків і систем. При цьому RUP не є щось застигле. База знань регулярно оновлюється й удосконалюється з урахуванням передового досвіду.

RUP створений у вигляді сторінок формату HTML, що мають велику систему гіперпосилань, графічну навігацію, докладний зміст і вбудований пошуковий механізм. База розповсюджується на компакт-дисках і за допомогою мережі Інтернет. Остання версія продукту завжди доступна на сайті виробника. Там же можна безкоштовно ознайомитися з повнофункціональною тридцятиденою пробною версією для ухвалення рішення про її використання й переглянути деморолик. Разом із самою базою надається книга Ф. Крачтена (Ph. Kruchten) "Rational Unified Process - an Introduction", що полегшує занурення в RUP.

RUP підтримує технологію розробки програмних продуктів для різних платформ, надає детальні рекомендації команді програмістів як по переходу до розробки на платформі Microsoft .NET, так і по самій цій розробці. Також підтримується плагін Windna для тих, хто не збирається переходити на платформу .NET.

Можлива й розробка ПЗ для платформи Java 2 Enterprise Edition (J2EE). Доступні плагіни для використання платформ IBM Websphere, BEA Weblogic і HP Bluestone Total e-server. Останній був включений у версію RUP 2002 і в поточному вигляді не був доступний у попередніх версіях продукту.

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

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

CMM - модель зрілості процесів створення ПЗ, або модель розвитку здатності компанії розробляти якісне програмне забезпечення. Це описова модель у тому розумінні, що вона описує істотні (або ключові) атрибути, які визначають, на якому рівні технологічної зрілості перебуває організація. Модель CMM розвиває положення про систему якості організації, формуючи критерії її досконалості - п'ять рівнів технологічної зрілості, які в принципі можуть бути досягнуті організацією-розроблювачем. На кожному рівні встановлюються вимоги, при виконанні яких досягається стабілізація найбільш істотних показників процесів. Вихід на кожний рівень технологічної зрілості є результатом появи певної кількості компонентів у процесах створення ПЗ, що у свою чергу приводить до підвищення їх продуктивності і якості. Застосування RUP і робочих інструментів IBM Rational гарантує одержання як мінімум третього рівня CMM.

Основними принципами методології RUP є:

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

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

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

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

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



Рис. 22.1. Загальне представлення RUP


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

  • горизонтальний вимір представляє час, відбиває динамічні аспекти процесів і оперує такими поняттями, як стадії, ітерації й контрольні точки;

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

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

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

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



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


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

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

  • ^ Своєчасна інтеграція. Залишити інтеграцію на самий кінець означає одержати переробки з більшими витратами часу - іноді до 40% усього обсягу проекту. Щоб уникнути цього, ітеративний підхід розбиває проект на невеликі ітерації, кожна з яких закінчується інтеграцією, при якій будівельні блоки поступово й безупинно інтегруються, що зводить до мінімуму пізнішу переробку.

  • ^ Ризики виявляються й усуваються на ранніх ітераціях. Ітеративний підхід RUP мінімізує ризик на ранніх ітераціях, коли тестуються всі компоненти. Оскільки кожна ітерація задіє багато аспектів проекту, такі як інструменти, готове програмне забезпечення й навички членів групи, можна швидко виявити, чи є передбачуваний ризик реальним, а також виявити нові, несподівані ризики в той час, коли їх легше й не так дорого зняти.

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

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

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

  • ^ Краще використання персоналу в проекті. Багато організацій сполучають використання каскадного підходу з організацією по типу конвеєра: аналітики посилають готові вимоги проектувальникам, які відсилають свій продукт програмістам, які посилають компоненти фахівцям з інтеграції, які відсилають систему тестувальникам. Такі численні переходи є джерелами помилок і недорозуміння й змушують людей менше почувати відповідальність за кінцевий продукт. Ітеративний процес розширює області компетенції членів групи, дозволяючи їм виконувати багато ролей, дозволяючи менеджерові проекту краще використовувати наявний персонал, і одночасно усуває шкідливі передачі.

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

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

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

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

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

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

  • початкова стадія (inception)

  • стадія розробки (elaboration)

  • стадія конструювання (construction)

  • стадія запровадження в дію (transition)

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

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

  • загальний опис системи: основні вимоги до проекту, його характеристики й обмеження

  • початкова модель варіантів використання (ступінь готовності 10-20%)

  • початковий проектний глосарій (словник термінів)

  • початковий бізнес-план

  • план проекту, що відображає стадії й ітерації

  • один або більше прототипів

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

  • модель варіантів використання (завершена принаймні на 80%), що визначає функціональні вимоги до системи

  • перелік додаткових вимог, включаючи вимоги нефункціонального характеру й вимоги, не пов'язані з конкретними варіантами використання

  • опис базової архітектури майбутньої системи

  • працюючий прототип

  • уточнений бізнес-план

  • план розробки всього проекту, що відображає ітерації й критерії оцінки для кожної ітерації

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

  • розроблювачі в стані оцінити з досить високою точністю, скільки часу буде потрібно на реалізацію кожного варіанта використання

  • ідентифіковані усі найбільш серйозні ризики, і ступінь розуміння найбільш важливих з них така, що відомо, як упоратися з ними.

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

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

  • ПЗ, інтегроване на необхідних платформах

  • посібник користувача

  • опис поточної реалізації

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

  • бета-тестування, що дозволяє переконатися, що нова система відповідає очікуванням користувачів

  • паралельне функціонування з існуючою системою, яка підлягає поступовій заміні

  • конвертування баз даних

  • оптимізацію продуктивності

  • навчання користувачів і фахівців служби супроводу

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

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

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

  • ролі

  • види діяльності

  • робочі продукти

  • дисципліни

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

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

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

  • побудова бізнес - моделей

  • визначення вимог

  • аналіз і проектування

  • реалізація

  • тестування

  • розгортання

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

  • керування конфігурацією й змінами

  • керування проектом

  • створення інфраструктури.

Основними поняттями RUP є артефакт (artifact) і прецедент (precedent). Артефакти - це деякі продукти проекту, породжувані або використовувані в ньому при роботі над остаточним продуктом. Прецеденти - це послідовності дій, виконуваних системою для одержання спостережуваного результату.

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

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

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

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

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

Усі завдання, описані в RUP, підтримуються засобами розробки від Rational Software. В RUP включений розділ Tool Mentors, у якому докладно описується використання Rational Rose для створення UML-моделей, Rational Requisitepro, Rational Clear Quest, Rational Clear Case для аналізу вимог, запитів на вимірювання й виправлення дефектів і для підтримки процесу уніфікованого керування змінами (UCM). У цьому ж розділі описуються методи застосування Rational Purify, Rational Purecoverage, Rational Quantify, Rational Robot для автоматизації процесу тестування й пошуку дефектів програмного забезпечення, а Rational Soda - для автоматизації процесу документування. Крім того, Tool Mentors містить докладні рекомендації з використання цих і інших засобів компанії Rational для створення конкретних артефактів розроблювальної системи.

Резюме

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

Питання для самоперевірки

  1. Що представляє собою Rational Unified Process?

  2. Що таке модель зрілості процесів створення ПЗ (СММ)?

  3. Наведіть основні принципи методології RUP

  4. В чому полягає ітераційний та інкрементний підхід до створення ПЗ?

  5. Наведіть структуру процесів в RUP

  6. Для чого призначена Уніфікована мова моделювання (UML)?

Схожі:

Лекція 22. Ibm rational Unified Process (rup) iconЛекція 23. Rup. Моделювання програмних систем І даних uml діаграми в Rational Rose
Одним з достоїнств цього програмного продукту є можливість використання діаграм мовою uml. Можна сказати, що Rational Rose є графічним...
Лекція 22. Ibm rational Unified Process (rup) iconЛекція 18. Cadm. Моделювання ділових процесів. Process Modeller Що представляє собою Process Modeller
Ці процеси охоплюють множину обов'язкових дій у певній діловій сфері (далі по тексту у бізнесі), спрямованих на створення або збільшення...
Лекція 22. Ibm rational Unified Process (rup) iconPress-release The VII international Scientific Conference «O. S. Puskin and the process of world literature»
«O. S. Puskin and the process of world literature» on the 19th of October at 10: 00
Лекція 22. Ibm rational Unified Process (rup) iconДокументи
1. /Аппаратные средства IBM PC.djvu
Лекція 22. Ibm rational Unified Process (rup) iconСхема аналізу лекції
Тип лекції (вступна; інформаційна (тематична); заключна (підсумкова); оглядова; нетрадиційна (наприклад, лекція-брифінг, лекція-конференція,...
Лекція 22. Ibm rational Unified Process (rup) iconПравила выполнения вакуумных схем unified system for design documentation. Rules for presentation of vacuum schemes гост 797-81 (ст сэв 2517-80)
Постановлением Государственного комитета СССР по стандартам от 30 октября 1981 г. №4826 срок введения установлен
Лекція 22. Ibm rational Unified Process (rup) iconGraf navchal process 13-14

Лекція 22. Ibm rational Unified Process (rup) iconProcess management in logistic activities of enterprises

Лекція 22. Ibm rational Unified Process (rup) iconIn frames of Bologna process Information about applicant

Лекція 22. Ibm rational Unified Process (rup) iconThe Optical Method of the Investigation of the Peritonitis Progressing Process

Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©zavantag.com 2000-2013
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи