< Попередня  Змiст  Наступна >

2.2.2. IBM Rational Method Composer


Ключовими елементами RMC є:

1) засоби доставки методів (Method Delivery Tools):

— Webсайт RUP, на якому публікуються процеси, сконфігуровані для конкретного проекту і пристосовані під специфічні потреби. Опис процесів подається на HTMLсторінках, що динамічно генеруються (рис. 2.3);

 

— набір засобів навігації — апплети браузера надають динамічний доступ до Webсайта; 

Головне вікно IBM Rational Method Composer

2) засоби конфігурування методів (Method Configuration Tool) — на основі технології готових компонентів підтримуються приєднання та розширення методик, конфігурування процесів;

 

3) ринок розширень процесів — на сайті IBM у розділі developerWorks (http://www136.ibm.com/developerworks/rational/products/ rup/) інженеритехнологи обмінюються розширеннями методик у вигляді готових компонентів (плагінів);

4) засоби розробки методів (Method Authoring Tool) — розробка на основі форм і структур розбивки, перегляд вмісту, функції пошуку, імпорт та експорт змісту методик, а також швидке складання процесів на основі шаблонів та елементів методик, що можуть використовуватися повторно. Важливими є функції створення плагінів методик для змінення та спрощення наявного змісту методик, керування й підтримки процесів.

 

Таким чином, IBM Rational Method Composer замінює засоби побудови, налаштування та публікації процесів IBM Rational Process Workbench, RUP Organizer та RUP Builder.

 

Засоби, що входять до складу RMC, розроблено на основі Eclipse. Крім них, платформа включає бібліотеку змісту процесів, що містить усі наявні уніфіковані процеси Rational, плагіни RUP та вибране з бібліотеки Rational Summit Ascendant1, а також відомості з інших областей, зокрема щодо керування портфелем проектів, колективної розподіленої розробки та сервісноорієнтованих архітектур. RMC сумісний зі стандартом OMG SPEM, що включає поняття будівельних блоків для опису процесу, так званих шаблонів спроможностей (capability patterns2, див. далі), і є описами найкращих практик, практичних прийомів, технологій і стилів розробки для відповідних дисциплін. Ці блоки використовують для швидкого створення процесу розробки з урахуванням специфічних потреб проекту й організації.

 

Відмітними характеристиками платформи є такі:

 

— повністю перепроектований засіб авторизації, конфігурування , перегляду та публікації методик і процесів;

— забезпечення миттєвого генерування публікацій для попереднього перегляду з можливостями швидкого перемикання конфігурацій;

 

— керування змістом методик із використанням користувацького інтерфейсу, ґрунтованого на формах. Таким чином, знання UML не є неодмінною умовою роботи з системою; 

— інтуїтивно зрозумілі повнофункціональні редактори текстів для створення ілюстрованих описів змісту із використанням стилів, таблиць, гіперпосилань тощо;

 

— можливості створення процесів за допомогою редакторів структур розбивки та діаграм потоків. Зокрема, користувач працює у формах, що представляють розбивки робіт, використання робочих продуктів і розміщення команди. RMC автоматично синхронізує всі подання при змінах процесу;

 

— незалежність від RUP. Хоча остання версія RUP міститься

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

 

— поліпшені можливості повторного використання і розширення методик. Порівняно із попередніми версіями механізм плагінів доповнено підтримкою структур розбивки;

 

— підтримка шаблонів процесів із динамічними зв’язками, що втілюють найліпші практики і можуть повторно використовуватися для швидкого складання процесів шляхом «draganddrop» («перетягтикинути»);

 

— підготовлені процеси можуть експортуватися в систему

IBM Rational Portfolio Manager, що використовується для керу

вання ресурсами і календарем проектів. У такий спосіб керування процесами інтегрується з керуванням проектами.

Фундаментальним принципом Rational Method Composer є відокремлення змісту методик (Method content), що його можна повторно використовувати, від конкретних процесів розробки (Processes), в яких він використовується. Відповідно, визначено таку структуру бібліотеки методик (рис. 2.4):

 

1. плагіни методик (Method plugins):

1.1. зміст методик (Method Content) надає покрокові пояснення щодо досягнення специфічних цілей розробки незалежно від місця цих кроків у життєвому циклі:

 

1.1.1. пакети змісту (Content packages) складаються з елементів методик — завдань (Task), ролей (Role), робочих продуктів

(Work Product), керівництв (Guidance);

1.1.2. категорії змісту методик (Method Content Categories) —

стандартні та користувацькі; 1.2. процеси (Processes):

1.2.1. зразки спроможності (Capability patterns); 1.2.2. процеси розробки (Delivery processes);

 

2. конфігурації методик (Method configurations).

Елементи бібліотеки методик та зв’язки між ними

Розглянемо ці складові.

 

Завдання (Task) — одиниця роботи, що присвоюється для виконання специфічній ролі і зазвичай впливає на один чи невелику кількість робочих продуктів. Рівень деталізації завдання коливається від кількох годин до кількох днів. Завдання можна розбити на менші кроки, що передбачають обмірковування, виконання і перевірку виконавцем своєї роботи. Наприклад, завдання «Розробка моделі прецедентів» включає ідентифікацію і пойменування прецедентів та акторів, підготовку стислого опису, визначення зв’язків і створення діаграми, деталізований опис основного потоку подій, деталізований опис альтернативних потоків подій, перегляд і перевірку моделі.

 

Роль (Role) — це множина взаємопов’язаних вмінь, навичок та обов’язків особи або групи осіб.

Робочий продукт (продукт роботи, Work Product) — загальний термін для позначення входів та виходів завдань (див. приклади на рис. 2.5). Ці елементи застосовуються для визначення всього, що використовується, виробляється або модифікується завданням.

Основні робочі продукти розробки програмного забезпечення та зв’язки між ними

Визначено три типи робочих продуктів:

— артефакт — матеріальний робочий продукт. Артефакти можуть складатися з інших артефактів. Наприклад, артефакт «модель» може складатись з елементів моделі, що також є артефактами. Ролі використовують артефакти для виконання завдань і для вироблення інших артефактів. Кожен артефакт становить відповідальність певної ролі, що полегшує визначення та розуміння обов’язків. При цьому на практиці втілюється ідея про необхідність певної сукупності вмінь для розроблення кожної частки інформації за методикою;

 

— вихід (Outcome) — нематеріальний робочий продукт, результат або стан. Цей елемент також використовується для опису робочих продуктів, що не визначені формально;

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

 

Керівництво (Guidance) — загальний термін для позначення інформації, що додається до більшості елементів методик і процесів. Rational Method Composer містить такі типи керівництв:

— контрольний список (Checklist) — перелік позицій, що їх слід завершити або перевірити. Часто використовується під час перевірок;

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

 

— вказівки щодо оцінювання (Estimating Guideline) — міри або стандарти оцінювання трудомісткості робіт та інструкції щодо їх ефективного використання. Можуть включати огляд оцінювання та метрики;

 

— приклад (Example) — примірник завершеного готового робочого продукту, що його можна взяти за зразок;

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

 

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

 

— звіт (Report) — заздалегідь визначений шаблон, згенерований на основі інших робочих продуктів як результат застосування певного засобу автоматизації. Прикладом може бути огляд моделі прецедентів, що генерується через виокремлення інформації щодо діаграми з графічної моделі та текстової інформації з документів та об’єднує їх;

 

— актив для повторного використання (Reusable Asset) — розв’язок проблеми в заданому контексті. В активі може бути варіативна частина, що пристосовується користувачем чи обумовлюється значенням, що він його задає. Також для активу вказують правила його використання;

 

— допоміжні матеріали (Supporting Material) — позначення для всіх типів керівництв, які не було визначено, а також окремих елементів керівництв;

 

— шаблон (Template) — окремий тип керівництв, що містить для робочого продукту заздалегідь визначену таблицю змісту, розділи, модулі та/або заголовки, стандартизовані формати, а також описи шляхів їх використання та завершення. Шаблони можуть подаватись не лише для документів, а й для концептуальних моделей або фізичних структур даних;

 

— визначення терміна (Term Definition) — визначає концепції

і  використовується для побудови глосарію (Glossary). Визначення терміна не пов’язане напряму з елементами змісту елементу, але такий зв’язок випливає з використання терміна в тексті опису;

— настанова з використання засобу (Tool Mentor) — опис використання певного засобу для виконання деякої роботи в контексті або незалежно від завдання чи дії;

 

— біла книга (White Paper) — спеціальне концептуальне керівництво, що його було опубліковано або відрецензовано ззовні. Білу книгу можна прочитати і зрозуміти незалежно від інших елементів змісту та керівництв.

 

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

Стандартні категорії слугують засобом категоризації базової складової методик на рівні з найкращими практиками для структуризації методик. Залежно від типу їх пов’язують лише з елементами певного змісту:

 

— дисципліни (Disciplines) — сукупність завдань, що стосуються певної частини ITсередовища. Наприклад, під час розроблення програмного забезпечення загальною практикою є виконання певних завдань з формування вимог у тісному взаємозв’язку із завданнями аналізу та проектування . Відокремлення цих завдань на окремі дисципліни полегшує їх розуміння . Своєю чергою, дисципліни об’єднуються в групи (Discipline Groupings);

 

— домени (Domains) — деталізована логічна ієрархія робочих продуктів, об’єднаних на основі синхронності виконання, ресурсів чи взаємозв’язків. У той час, коли домен вміщує багато робочих продуктів, кожен з них належить лише до одного домену. Домени можуть поділятися на піддомени;

 

— типи робочих продуктів (Work Product Kinds) — ще одна категорія для групування робочих продуктів: оцінки, концепції, специфікації, плани, моделі, елементи моделей, проектні дані, рішення тощо;

 

— набори ролей (Role Sets) — сукупності ролей зі спільними рисами. Наприклад, множина ролей «Аналітик» може об’єднувати ролі «Аналітик бізнеспроцесів», «Системний аналітик», «Специфікатор вимог», кожна з яких працює зі схожими засобами і передбачає вміння, що перетинаються, але є відповідальною за виконання конкретних завдань і створення певних робочих продуктів. Набори ролей також можуть згруповуватись (Role Set Groupings);

 

— засоби (Tools) — вмістилище настанов з використання засобів, що також надають загальний опис засобу та його загальні можливості.

 

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

Стандартизований підхід до створення методик у Rational Method Composer передбачає визначення набору ролей, відповідальних за певні типи робочих продуктів. Для створення або змінення робочих продуктів ролям присвоюються задачі, що на вході і виході мають певні типи робочих продуктів. Інженер процесу створює ці елементи, визначає зв’язки між ними і категоризує їх. Зміст методики надає докладне покрокове пояснення, як певні цілі розробки досягаються незалежно від місця відповідних кроків у життєвому циклі системи. Своєю чергою, процес вилаштовує елементи методик у напівупорядковані послідовності, налаштовані для специфічних типів проектів.

 

Ключовою концепцією відокремлення методик і процесів є дескриптор (Descriptor) — елемент процесу, що подає використання елемента змісту методики (ролі, завдання або робочого продукту) в дії (Activity) так, як показано на рис. 2.6. Дескриптор можна розглядати як об’єктпосилання на конкретний елемент методики, у якого є власні взаємозв’язки і властивості. Під час створення дескриптор наслідує ці взаємозв’язки і властивості, але їх можна перевизначити для конкретної процесної ситуації, для якої створено дескриптор.

Використання дескрипторів для визначення процесів на основі змісту методик

Дія (Activity) як об’ єднання завдань з відповідними ролями і робочими продуктами є основним модулем процесів. Дії можуть вкладатися одна в одну для подання декомпозиції робіт (work breakdown structure, див. рис. 2.7) та мати зв’язки між собою для визначення потоку робіт (workflow, див . рис. 2.8). З дій складаються шаблони спроможності та процеси доставки, що є двома типами процесів у RMC.

Структура декомпозиції робіт з аналізу та проектування

Шаблон спроможності (шаблон дій, процес ключової ділянки розробки, Capability Pattern) — це специфічний процес, комплекс повторюваних дій, виокремлений із загального процесу. Шаблони спроможності виражають знання з певної ділянки розробки, зокрема дисципліни або найкращої практики (best practice), їх можна безпосередньо використати для керівництва відповідною роботою. Прикладом таких процесів може бути керування вимогами на основі прецедентів, юніттестування. Як правило, хоча й не обов’язково, шаблон спроможності охоплює одну дисципліну, включно з розбивкою робіт, їх зв’язками з ролями та робочими продуктами, що використовуються або виробляються. Шаблон спроможності не співвідноситься з конкретною фазою або ітерацією життєвого циклу. Наприклад, проект розробки нової ІС може містити завдання «Проектування прецедентів» так само, як і проект розширення наявної ІС. Водночас у цих двох проектах дане завдання виконується в різні моменти часу і з певними відмінностями. Потоки робіт в шаблонах спроможності подаються, як правило, з використанням нотації діаграм діяльності UML Activity Diagram (див. рис. 2.8).

 

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

Діаграма робіт з аналізу і проектування за RUP для великих проектів

Процес доставки (процес отримання, процес розробки, Delivery Process) — модель повного життєвого циклу проекту від початку до завершення із визначеними фазами, ітераціями та діями. Він може бути використаний як шаблон для планування і виконання проекту певного типу.

 

Названі елементи супроводжуються керівництвами з процесу (Process Guidance), що містять додаткову інформацію про них, наприклад маршрутну карту.

 

Вміст бібліотеки методик можна відфільтрувати за допомогою конфігурацій методик, що визначають робочий набір зі змісту методик і процесів для специфічного контексту, визначеного кінцевим користувачем. Наприклад, якщо процес доставки передбачає розроблення моделей даних з орієнтацією і на реляційну, і на об’єктноорієнтовану СКБД, то при реалізації такого процесу користувач обирає тип СКБД і добирає потрібну частину вмісту бібліотеки за допомогою відповідної конфігурації. Елементи згідно з обраною конфігурацією виводяться у поданні Configuration View. Конфігурації використовуються для створення і публікації процесів. Відповідно, кожна конфігурація складається з трьох частин — опису конфігурації, вибірки плагінів і пакетів та вибірки подань для публікації на Webсайті. Конфігурація позначається іменем і зберігається для використання у майбутньому.

Rational Method Composer можна використовувати у двох режимах:

 

— режим розробки (Authoring perspective) пропонує функції і подання для навігації за змістом методик і процесів, а також їх змінення. У цьому режимі користувач одержує два подання — бібліотеки (Library View) і конфігурації (Configuration View). Перше показує фізичні папки з плагінами і конфігураціями з бібліотеки методик і використовується для створення, модифікації та перегляду елементів всіх типів. Подання конфігурації показує вибрану добірку бібліотеки у вигляді стандартних категорій, процесів, користувацьких категорій і керівництв;

 

— режим перегляду (Browsing perspective) містить лише подання конфігурації.

Результатом роботи в Rational Method Composer є статичний Webсайт із множиною HTMLсторінок і множиною гіперпосилань, що документують процеси розробки. Цей сайт може бути розгорнутий на будьякому сервері, надаючи оперативний доступ до актуальної інформації. Дані також можуть бути експортовані в систему керування проектом, зокрема Microsoft Project, і використовуватись як основа для планування проекту.

 

Наостанок слід сказати кілька слів про ще один проект, що розвивається паралельно із платформою Rational Method Composer. Частину технології RUP корпорація IBM передала організації Eclipse Foundation, що розробляє інструментальні засоби з відкритим кодом (Open Source). Таким чином IBM стала спонсором проекту Eclipse Process Framework — створення інструментальної платформи керування процесом і концептуальної структури для створення, адаптації, розгортання розроблених процесів. Відповідний інструмент має назву Eclipse Process Framework Composer (EPFC). Він охоплює близько 15 % вмісту RUP, а саме — базове керівництво з розробки програмного забезпечення та інструментальні засоби для налаштування конфігурації процесів і систем розробки, а також метамодель для опису ресурсів, виконавців і заходів, що здійснюються під час розроблення. Також розроблено плагіни EPFC з OpenUP (гнучкий варіант Rational Unified Process, див. рис. 2.9), практики EPF, методології гнучкої розробки Scrum, екстремального програмування (Extreme Programming, XP), методу розробки динамічних систем (Dynamic Systems Development Method, DSDM) та розробки гнучких бізнесправил (Agile Business Rule Development, ABRD). Крім власне бібліотек можна завантажити готові для публікації версії усіх цих процесів.

Типовий процес OpenUP у вікні EPFC

Просування EPFC, як і RMC, має на меті вдосконалення процесів розробки ІС, автоматизації процедур керування ними, обмін передовим досвідом та його поширення на якомога більшу кількість проектів.

 


< Попередня  Змiст  Наступна >
Iншi роздiли:
2.4. АВТОМАТИЗОВАНА ПІДТРИМКА МЕТОДОЛОГІЇ DATARUN
Терміни та поняття
Тема 3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ВИМОГАМИ
3.2. АВТОМАТИЗОВАНА РОЗРОБКА ВИМОГ
3.3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ЗМІНАМИ ВИМОГ
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki