20Стан вимог. Основні принципи контролю змін в пз. Шаблон опису контролю змін

20.1 Стан вимог

Нижче перераховано кілька можливих станів вимог²⁰:

• Запропоновано (Proposed) вимоги запитані авторизованим джерелом

• Одобрено (Approved) ключові зацікавлені в проекті особи погодилися з цією вимогою, а розробники ПЗ зобов'язалися реалізувати його.

• Реалізовано (Implemented) код, який реалізує вимога, розроблений, написаний і протестований.

• Перевірено (Verified) коректне функціонування реалізованого вимоги підтверджено у відповідному продукті.

• Видалено (Deleted) затверджена вимога видалено з базової версії.

• Розроблено (Designed) якщо елементи дизайну, в яких відображені функціональні вимоги,

створені і перевірені.

• Відхилено (Rejected) дозволяє залишити запропоновані вимоги доступними для майбутнього використання, не створюючи безладу в наборі затверджених вимог для певного випуску.

• Випущено (Delivered) ПЗ віддано в руки користувачів, як для бета-тестування.

На рис 1.²¹ показаний контроль стану вимог для циклу розробки проекту в 10-ти місячний термін.

Рис 1.

20.2 Основні принципи контролю змін в пз.

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

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

• Сам по собі запит на зміну не гарантує виконання цієї зміни. Рада з управління змінами проекту (change control board, CCB) вирішує, які зміни слід реалізувати.

• Вміст бази даних змін має бути видимим для всіх зацікавлених у проекті осіб;

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

• Аналіз впливу зміни необхідно виконувати для кожної зміни;

• Кожна зміна вимоги має відстежуватися аж до затвердження запиту на цю зміну;

20.3 Шаблон опису контролю змін.

На Рис 2²². показаний шаблон опису процесу контролю змін для обробки модифікацій вимог та інших змін проекту, та наведені 4 компоненти які входять в усі процедури та описи процесу:

• вхідний критерій - умови, які повинні бути задоволені до виконання процесу або процедури;

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

• послідовні дії для підтвердження того, що завдання були виконані правильно;

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

Рис 2.

21Елементи запиту на зміни в пз Всі перераховані далі вихідні критерії повинні бути задоволені, щоб належним чином завершити процес управлінь змінами:

- стан запиту: Rejected (Відхилено), Closed (Зачинено) або Canceled (Скасовано);

- всі зміни записані у відповідних розділах;

- ініціатор запиту, голова ради по управлінню змінами, менеджер проекту та інші значущі учасники проекту оповіщені про деталі зміни та поточний стан запиту на

зміна;

-матриця зв'язків вимог оновлена. (В главі 20 про трассируемого вимог розказано більш докладно.)

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

Таблиця Пропоновані єлементи даних запиту на зміну²³

Єлемент	Опис
Походження зміни	Функціональна область, що запросила це зміна; це можуть бути маркетологи, менеджери, клієнти інженери з програмного забезпечення, фахівці з обладнання та тестувальники.
Ідентифікатор запиту на зміну	Ідентифікатор або порядковий номер, призначений запитом.
Тип зміни	Тип запиту на зміну, наприклад зміна вимоги, запропоноване поліпшення або звіт про помилку.
Дата подачі	Дата, коли ініціатор запиту відправив запит на зміну.
Дата поновлення	Дата останньої зміни запиту.
Опис	Текстовий опис у вільній формі запитаного зміни.
Пріоритет при реалізації	Відносна важливість внесення зміни, певна радою по управлінню змінами - низька, середня або висока.
Особа, яка вносить зміни	Ім'я людини, що відповідає за внесення зміни.
Ініціатор запиту	Ім'я людини, яка подала запит на зміну; можливо, вам слід включити контактну інформацію про нього.
Пріоритет ініціатора запиту	Відносна важливість зміни з точки зору ініціатора запиту - низька, середня або висока.
Планований випуск	Версія продукту або номер зборки, на яку заплановано схвалене зміна.
Проект	Назва проекту, для якого пропонується зміна.
Відповідь	Відповідь у вільній текстовій формі на запит про зміну; згодом їх може бути декілька; не змінюйте існуючі відповіді при введенні нового.
Стан	Поточний статус запиту на зміну, вибране з можливих на рис. 19-2.
Назва	Короткий (одна строчка) опис запропонованого зміна.
Особа, що перевіряє зміна	Ім'я людини, що відповідає за коректність зміни.

22Ролі і відповідальності учасників проекту ПЗ. Склад ради по управлінню змінами в ПЗ

23Трасування вимог. Переваги реалізації трасування вимог. Джерела інформації про зв’язки трасування

24Інструментальні засоби управління вимогами. Огляд та переваги їх використання

24.1 Інструментільні засоби управління вимогами.

Специфікація вимог до ПЗ на природній мові має обмеження:

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

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

• трудність зберігання додаткової інформації (атрибутів) для кожної вимоги;

• труднощі визначення взаємозв'язків між функціональними вимогами та іншими елементами системи;

• трасування статусу вимог являє собою важкий і незручний процес;

• одночасне керування наборами вимог;

• трудність модифікації вимог кількома учасниками проекту;²⁴

• відсутність зручного місця зберігання вимог.²⁵

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