Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

21.04.2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Допоміжна	\|

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.