Лабораторна робота

Засоби керування та відстеження вимог та їх можливості. Засоби, орієнтовані на життєвий цикл або розробку – Telelogic DOORS, Rational Requisuite Pro, Requirements Composer (для групи 307).

21.04.2012

Управління вимогами

1. Принципи і прийоми управління вимогами

   1. Базова версія вимог

   2. Процедури управління вимогами

   3. Контроль версій

   4. Атрибути вимог

   5. Контроль статусу вимог

   6. Вимірювання трудовитрат, необхідних для управління вимогами

2. Управління змінами

   1. Управління незапланованим ростом робіт

   2. Процес контролю змін

1. Принципи і прийоми управління вимогами

Пройшовши етапи виявлення, усестороннього аналізу, формалізації, специфікації, перевірки, вимоги набувають статус документу. Сторони ставлять на документі свої підписи. Тим самим, засвідчуючи, що саме цей (представлений в SRS) набір вимог представляє звід законів, за якими створюється система. Потому здійснюється проектування і реалізація системи. Готова система передається Замовнику, який разом з Розробником здійснює її прийом і введення в експлуатацію. Така схема закладена в підході, що відомий в літературі як «каскадний» («водоспадний»).

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

Угода за вимогами є сполучною ланкою між розробкою та управлінням вимогами. У членів команди повинен бути доступ до поточних вимог протягом всього проекту, можливо, через Web-рішення за допомогою інструментів управління вимогами.

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

До дій по управлінню вимогами відносять:

• Визначення основної версії вимог (моментальний зріз вимог для конкретної версії продукту);

• Перегляд пропонуємих змін вимог і оцінка ймовірності впливу кожної зміни до її прийняття;

• Включення схвалених змін вимог в проект встановленим способом;

• Погодження плану проекту з вимогами;

• Обговорення нових обов’язків, що базуються на оцінюванні впливу зміни вимог;

• Відслідковування окремих вимог до проектування, вихідного коду і варіантів тестування;

• Відслідковування статусу вимог і дій по зміні на протязі всього проекту.

Рис. Основні складові управління вимогами

Принципи і прийоми управління вимогами

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

- на короткий період часу вводиться режим понаднормової роботи, по можливості оплачуваної;

• у відповідності з новою функціональністю змінюється графік;

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

Базова версія вимог

Базова версія (baseline) – це набір функціональних і нефункціональних вимог, які розробники зобов’язалися реалізувати у визначеній версії (ітерації).

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

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

Процедури управління вимогами

Процедури управління вимогами базуються на:

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

• Правилах складання базової версії вимог;

• Статусах вимог, які будуть використовуватись, і категоріях осіб, які мають право змінювати їх;

• Процедурах контролю за статусом вимог;

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

• Методах аналізу впливу запропонованої зміни;

• Відслідковуванні зв’язків планів і обов’язків проекту зі змінами вимог.

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

Контроль версій

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

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

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

Спроба розрізняти версії документів за датою зміни часто призводить до помилок і плутанини, її не рекомендовано використовувати. Деякі команди доволі успішно застосовували таку угоду: перша версія будь-якого нового документа називається «Версія 1.0, начерк 1 ». Наступна називається «Версія 1.0, начерк 2 ». Автор послідовно збільшує номер начерку при кожній зміні і так до тих пір, поки документ не буде затверджена базова версія документа. Тоді назва змінюється на «Версія 1.0, затверджена». Наступні версії називаються «Версія 1.1, начерк 1» при невеликій зміні або «Версія 2.0, начерк 1» при значній зміні. При застосуванні цієї схеми ясно розрізняються начерки й версії базового документа, однак необхідно дотримуватися суворий порядок у веденні документації.

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

Для документування версій використовуються текстові процесори, електронні таблиці.

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

Атрибути вимог

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

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

В якості шаблону опису атрибутів вимог К. Вігерс пропонує наступний набір:

• Дата створення вимоги;

• Номер поточної версії;

• Автор вимоги;

• Особа, що відповідає за задоволення вимоги;

• Відповідальний за вимогу або список зацікавлених осіб (щоб прийняти рішення про запропоновані зміни);

• Стан вимоги;

• Походження або джерело вимоги;

• Логічне обґрунтування вимоги;

• Підсистема (або підсистеми), для яких призначена вимога;

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

• Метод перевірки, що використовується або критерії тестування прийнятності;

• Пріоритет реалізації;

• Стабільність вимоги.

Контроль статусу вимог

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

Стан	Визначення
Proposed (запропоновано)	Вимога, що запитана авторизованим джерелом
Approved (схвалено)	Вимога проаналізована, її вплив на проект прораховано, і вона була розміщена в базовій версії визначеної версії. Ключові зацікавлені в проекті особи погодились з цією вимогою, а розробники ПЗ зобов’язались реалізувати її
Implemented (реалізовано)	Код, що реалізує вимогу, розроблений, написаний і протестований. Вимогу відслідковано до відповідних елементів дизайну і коду
Verified (перевірено)	Коректне функціонування реалізованої вимоги підтверджено у відповідному продукті. Вимогу відслідковано до відповідних варіантів тестування. Тепер вимога вважається закінченою.
Deleted (видалено)	Затверджену вимогу видалено із базової версії. Необхідно зазначити причини видалення і назвати того, хто прийняв таке рішення.
Rejected (відхилено)	Вимога запропонована, але не запланована для реалізації ні в одній із майбутніх версій. Необхідно описати причини відхилення вимог і назвати того, хто прийняв таке рішення.

Вимірювання трудовитрат, необхідних для управління вимогами

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

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

• Пропозиція зміни вимог та нових вимог;

• Оцінка запропонованих змін, включаючи оцінку впливу змін;

• Зміна роботи;

• Оновлення документації вимог або бази даних;

• Повідомлення про зміни вимог зацікавленим групам і окремим особам;

• Контроль і звіт про стан вимог;

• Збір інформації про трасуємість вимог.

Управління змінами

Більшість розробників стикалися з простими на перший погляд змінами, які виявлялися більш складними, ніж вони очікували. Розробники іноді не виконують - або не можуть виконати - реалістичні розрахунки витрат та інших наслідків запропонованого зміни ПЗ. І коли розробник, який хоче бути люб'язним, погоджується додати поліпшення, запитуване користувачем, вимоги змінюються через «чорний хід», а не затверджуються зацікавленими особами, які мають на це право. Tакі неконтрольовані зміни - повсюдний джерело хаосу в проекті, порушення графіка і проблем з якістю, особливо якщо робота ведеться на декількох ділянках або проект виконує стороння організація. Організація, серйозно відноситься до управління своїми проектами з розробки ПЗ, повинна переконатися, що:

• запропоновані зміни вимог ретельно оцінені до їх у введення у справу;

• відповідні особи приймають (беруть) бізнес-рішення, будучи добре інформованими про запитані зміни;

• схвалені зміни доведені до відома всім учасникам проекту;

• зміни вимог, внесені в проект, узгоджені один з іншим.

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

Управління незапланованим ростом об’єму

Незапланований ріст об’єму ставить під загрозу:

• 80% проектів по розробці систем управління інформацією:

• 70% проектів по розробці військових систем ПЗ;

• 45% проектів по створенню ПЗ, що виконуються за контрактом.

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

Вимоги до системи управління інформацією, як правило, збільшуються на 1% на місяць (Jones, 1996b). Темп приросту може складати до 3,5% у місяць для комерційного ПЗ, при цьому темпи зростання інших типів проектів входять у цей показник.

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

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

Інша стратегія – це уміння говорити «Ні». психологія більшості людей побудована таким чином. Що їм важко відмовляти, і в даному випадку може виникнути стан постійного пресингу. К Вігерс пропонує пом’якшити цей підхід, замінивши «Ні» на «Не зараз» (вимога обов’язково буде виконана, але не в поточній версії).

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