20Стан вимог. Основні принципи контролю змін в пз. Шаблон опису контролю змін
20.1 Стан вимог
Нижче перераховано кілька можливих станів вимог17:
Запропоновано (Proposed) вимоги запитані авторизованим джерелом
Одобрено (Approved) ключові зацікавлені в проекті особи погодилися з цією вимогою, а розробники ПЗ зобов'язалися реалізувати його.
Реалізовано (Implemented) код, який реалізує вимога, розроблений, написаний і протестований.
Перевірено (Verified) коректне функціонування реалізованого вимоги підтверджено у відповідному продукті.
Видалено (Deleted) затверджена вимога видалено з базової версії.
Розроблено (Designed) якщо елементи дизайну, в яких відображені функціональні вимоги,
створені і перевірені.
Відхилено (Rejected) дозволяє залишити запропоновані вимоги доступними для майбутнього використання, не створюючи безладу в наборі затверджених вимог для певного випуску.
Випущено (Delivered) ПЗ віддано в руки користувачів, як для бета-тестування.
На рис 1.18 показаний контроль стану вимог для циклу розробки проекту в 10-ти місячний термін.
Рис 1.
20.2 Основні принципи контролю змін в пз.
Керівництво має ясно довести до відома співробітників принципи контролю змін, в яких описується очікування того, як учасники проекту повинні обробляти запропоновані зміни до вимог. Можуть бути корисними наступні принципи контролю змін:
Не можна займатися дизайном або реалізувати незміцненої зміни, крім перевірки їх здійсненності;
Сам по собі запит на зміну не гарантує виконання цієї зміни. Рада з управління змінами проекту (change control board, CCB) вирішує, які зміни слід реалізувати.
Вміст бази даних змін має бути видимим для всіх зацікавлених у проекті осіб;
Первинний текст запиту на зміну не повинен змінюватися або видалятися;
Аналіз впливу зміни необхідно виконувати для кожної зміни;
Кожна зміна вимоги має відстежуватися аж до затвердження запиту на цю зміну;
20.3 Шаблон опису контролю змін.
На Рис 219. показаний шаблон опису процесу контролю змін для обробки модифікацій вимог та інших змін проекту, та наведені 4 компоненти які входять в усі процедури та описи процесу:
вхідний критерій - умови, які повинні бути задоволені до виконання процесу або процедури;
різні завдання, задіяні е процесі або процедурі, учасник проекту, який відповідає за виконання кожного завдання, і інші особи, які беруть участь у виконанні завдання;
послідовні дії для підтвердження того, що завдання були виконані правильно;
вихідний критерій - умови, які вказують, коли процес або процедура вважаються успішно завершеними.
Рис 2.
21Елементи запиту на зміни в ПЗ
22Ролі і відповідальності учасників проекту ПЗ. Склад ради по управлінню змінами в ПЗ
23Трасування вимог. Переваги реалізації трасування вимог. Джерела інформації про зв’язки трасування
24Інструментальні засоби управління вимогами. Огляд та переваги їх використання
24.1 Інструментільні засоби управління вимогами.
Специфікація вимог до ПЗ на природній мові має обмеження:
трудність оновлення та синхронізації документів;
всім членам команди, яким це необхідно, передачу змін доводиться здійснювати вручну;
трудність зберігання додаткової інформації (атрибутів) для кожної вимоги;
труднощі визначення взаємозв'язків між функціональними вимогами та іншими елементами системи;
трасування статусу вимог являє собою важкий і незручний процес;
одночасне керування наборами вимог;
трудність модифікації вимог кількома учасниками проекту;20
відсутність зручного місця зберігання вимог.21
Засіб керування вимогами, що зберігає інформацію в багатокористувацької базі даних, дозволяє зняти ці обмеження.