Створення вимог в RequisitePro з моделі прецедентів Rose, Комерція, Різне, статті


Мета


У документі коротко описаний процес формування функціональних вимог в Rational RequisitePro з моделі прецедентів Rational Rose. Описаний процес не є єдино можливим. Як відомо, кошти Rational можуть бути використані в більшості софтверних проектів в компаніях з власними стандартами та підходами до створення програмного забезпечення.


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


Інтегроване використання Rose і RequisitePro дозволяє вирішити 2 дуже важливі завдання:



Створення початкового списку функціональних вимог з моделі прецедентів розбивається на наступні підзадачі:



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


При складанні даного документа був використаний Rational Suite AnalystStudio 2002. Загальні принципи роботи з Rational RequisitePro викладені в “Основи використання Rational RequisitePro”.


Створення необхідних типів вимог і типів документів


Насамперед у проекті RequisitePro необхідно створити тип вимог, який буде об’єднувати прецеденти, експортовані з моделі прецедентів Rose. Переваги додаткового зберігання цих прецедентів у вигляді вимог RequisitePro:



Для створення зазначеного типу вимог на дереві вузлів відкритого проекту RequisitePro необхідно активізувати самий верхній вузол і в його контекстному меню вибрати пункт “Properties” (рис. 1).

Рис. 1

У вікні “Project Properties” слід активізувати сторінку “Requirement Types”. Вона дозволяє додати в проект нові типи вимог. Після додавання типів вимог “Прецеденти” і “Функціональні вимоги “вікно” Project Properties “набуде вигляду згідно рис. 2.

Рис. 2

На сторінці “Attributes” вікна “Project Properties” слід визначити необхідні атрибути для сформованих типів вимог. Хоча, звичайно ж, можна використовувати і ті атрибути, які створюються за замовчуванням для нових типів вимог.

У нашому випадку для кожного створеного типу вимог видаляємо існуючі атрибути та створюємо такі:


Спільне використання Rose і RequisitePro дозволяє пов’язувати документи проекту RequisitePro з будь-якими прецедентами моделі Rose. Процес інтеграції моделі Rose з проектом RequisitePro вимагає попереднього створення хоча б одного типу документа, який буде пов’язаний з вимогами типу “Прецеденти”. Сформуємо деякий узагальнений тип документів “Загальні документи” (рис. 3).

Рис. 3


Інтеграція моделі Rose та проекту RequisitePro


Для використання Rose спільно з RequisitePro необхідно, щоб в першому був активізований відповідний “Add-In”. Для цього необхідно вибрати пункт меню “Add-Ins/Add-In Manager …”. Це призводить до появи вікна “Add-In Manager”. Тут слід проконтролювати, щоб був активний пункт “RequisitePro” (рис. 4).


Рис. 4

В результаті з’являються додаткові пункти головного і різних контекстних меню, що дозволяють працювати з RequisitePro з Rose.

Тепер слід зв’язати поточний файл моделі Rose з проектом RequisitePro. Для цього потрібно вибрати пункт меню “Tools / Rational RequisitePro / Associate Model To Project”. У вікні “Associate Model To RequisitePro Project “слід вказати проект RequisitePro, в який будуть експортовані прецеденти (Мал. 5). Крім того, необхідно вказати тип вимог і тип документів за замовчуванням, з якими автоматично будуть пов’язані експортовані прецеденти. У подальшому вказані типи можуть бути замінені на будь-які інші за допомогою цього ж вікна.

Рис. 5

Натискання кнопки призведе до інтеграції моделі Rose та проекту RequisitePro.


Експорт прецедентів з Rose в RequisitePro


Розглянемо експорт прецеденту на простому прикладі. Нехай є деяка модель прецедентів (рис. 6).

  

Рис. 6

Для експорту прецедентів слід для кожного з них вибрати пункт контекстного меню “Requirement Properties / New …”. При цьому з’являється форма додавання вимог “Requirement Properties …” з RequisitePro (Рис. 7).

Рис. 7

Дана форма дозволяє встановити значення додаткових атрибутів прецедентів (сторінка “Attributes”), створити зв’язку з існуючими вимогами будь-яких типів (“Traceability”) і сформувати ієрархію прецедентів (“Hierarchy”). Натискання призведе до фізичного створенню вимоги типу “Прецеденти” в базі RequisitePro.

Таким чином експортуємо все прецеденти в проект RequisitePro. Створені вимоги в RequisitePro слід перенести в папку, призначену для їх зберігання. Після цього потрібно створити матрицю атрибутів (Attribute Matrix) для роботи з ними (рис. 8).

Рис. 8


Створення функціональних вимог


Функціональні вимоги створюються аналітиком на основі аналізу сценаріїв прецедентів в моделі Rose. Як і раніше, розглянемо цей процес на короткому прикладі. Нехай спрощений сценарій прецеденту “Замовити товар “виглядає наступним чином:


1. Резюме


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


2. Мета


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


3. Головний сценарій
3.1. Передумови:



3.2. Тригер:



3.3. Післяумови:



3.4. Дії:



  1. система відображає список категорій товарів;
  2. покупець вибирає необхідну категорію товарів;
  3. система відображає список товарів обраної категорії;
  4. покупець виділяє необхідні товари в цій категорії;
  5. покупець вказує необхідну кількість кожного з обраних товарів;
  6. покупець активізує елемент інтерфейсу “Покласти в кошик” для додавання обраних товарів в свою особисту кошик;
  7. система додає вибрані товари в кошик покупця;
  8. система відображає загальну суму товарів в кошику. ”

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


Для додавання функціональних вимог створимо матрицю атрибутів (Attribute Matrix) “Функціональні вимоги”. Після уважного опрацювання зазначеного сценарію прецеденту сформуємо список функціональних вимог, використовуючи цю матрицю (рис. 9). При виявленні функціональних вимог слід особливо акцентувати на розділах “Передумови” і “постусловіем” головного сценарію [3].

Рис. 9

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

Нами визначені наступні вимоги для прецеденту “Реалізувати прецедент” Замовити товар “”:



Створення трасування матриці і відстеження змін в моделі прецедентів


Далі слід подбати про зручність відстеження змін у функціональних вимогах після виникнення змін в моделі прецедентів. Для цього в папці “трассіровочние матриці” створимо трассіровочние матрицю (Traceability Matrix) “Функціональні-прецеденти”. За допомогою неї буде легко визначити, які функціональні вимоги необхідно переглянути на предмет можливих змін, якщо змінилися будь прецеденти моделі прецедентів (рис. 10).

Рис. 10


Тепер змінимо в моделі Rose прецедент “Продати товар” на “Доставити товар”, що передбачає реалізацію в рамках одного прецеденту функціональності продажу товару і його доставки покупцеві. Для синхронізації з прецедентом в RequisitePro виберемо в моделі Rose пункт контекстного меню зміненого прецеденту “Requirement Properties / Open …” (Рис. 11).

Рис. 11

Після підтвердження відкрився діалогу “Requirement Properties: USC1 Доставити товар” в проекті RequisitePro одна з вимог групи “Прецеденти” буде також змінено (рис. 12).

Рис. 12

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

Крім того, зміна сценарію прецеденту може привести до зміни дочірніх вимог для “Реалізувати прецедент” Доставити товар “”. Для цього необхідно знову проаналізувати сценарій прецеденту і узгодити з ним список функціональних вимог.

Після внесення змін у функціональні вимоги потрібно вручну прибрати значок перекреслення за допомогою вибору відповідного пункту контекстного меню “Clear Suspect” на перекреслено поле (рис. 13).

Рис. 13


Висновок

Спільне використання Rose і RequisitePro дає велику перевагу в підтримці моделі прецедентів та списку функціональних вимог в актуальному стані. Будь-які зміни в моделі прецедентів достатньо легко відображаються на функціональних вимогах проекту RequisitePro.

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

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


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

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

Ваш отзыв

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

*

*