|
Читайте также: |
SRS – специфікація для конкретного (визначеного) ПЗ, програми чи набору програм, які виконують визначені функції в конкретному середовищі.
SRS можуть бути складені одним або декількома представниками постачальника, одним або декількома представниками клієнта, або обома.
Характеристика правильно складеної SRS:
· Коректність
· Однозначність
· Повнота
· Несуперечливість
· Упорядкованість за значністю
· Перевіряємість
· Модифікуємість
· Відслідковуваність
Проблемні ситуації:
1. Двозначність. Ситуація, коли одну вимогу можна інтерпретувати більше ніж в одному значенні.
2. «Золочення» продукту – такі ситуації, коли розробники додають функції, яких немає в специфікації, але їм здається, що це сподобається користувачам. Але замовнику може це не сподобатись.
3. Мінімальна специфікація – представлення вимог на 2-3 сторінках (у невеликих проектах). Мінімальне спека доречна, якщо має місце наявність одночасно трьох обставин:
a. Ціна контракту і розміри проекту настільки малі, що розробляти повну спеку є дорогим задоволенням.
b. Колектив розробника володіє достатнім ступенем досвіду виконання проектів у суміжних областях
c. Між замовником та розробником існують конструктивні відносини і обидві сторони розуміють і приймають ризики міні-специфікації.
Методи і засоби перевірки вимог розрізняють за параметрами:
1. За широтою аналізу – перегляд (вибіркова перевірка)
2. За ступенем формалізації – неофіційні процедури, процедури, що проводяться за формальними правилами (інспекції, експертизи).
3. За складом групи перевірки – з (без) участю автора, з (без) участі менеджера проекту, з (без) участю представників зовнішніх організацій.
4. За використовуваними засобами – тексти вимог, тестові сценарії, критерії прийнятності, прототип.
Неофіційні перегляди вимог:
1. Перегляди «за столом» (коли перевірку робить колега по роботі)
2. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)
3. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).
У третьому випадку автор здійснює презентацію розроблених ним вимог на параді з подальшим обговоренням.
Офіційна перевірка вимог:
На відміну від неофіційних переглядів, офіційна перевірка представляє собою суворо регламентований процес. По його завершенню формується звіт, в якому вказуються матеріали, рецензенти (ті, хто буде оцінювати продукт – експерт) і думка команди рецензентів про прийнятність продукту.
Головний результат – сукупність усіх знайдених дефектів і піднятих питань.
Експертиза як метод перевірки вимог (інспекція):
Експертиза проводиться командою кваліфікованих спеціалістів, які ретельно перевіряють продукт на наявність дефектів і вивчають можливості покращення продукту (специфікація).
Учасники:
1. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)
2. Автор будь-якого попереднього продукту для елемента, який варто перевірити.
3. Люди, що виконують роботу, що базуються на перевіряємому елементі.
4. Люди, що відповідають за роботу продуктів, що взаємодіють з перевіряємим елементом. Вони виявляють проблеми з вимогами до зовнішнього інтерфейсу. Також модуть виявити вимоги, зміна яких в перевіряє мій спеці впливає на інші системи.
Неофіційні перегляди вимог:
4. Перегляди «за столом» (коли перевірку робить колега по роботі)
5. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)
6. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).
У третьому випадку автор здійснює презентацію розроблених ним вимог на параді з подальшим обговоренням.
Експертиза як метод перевірки вимог (інспекція):
Експертиза проводиться командою кваліфікованих спеціалістів, які ретельно перевіряють продукт на наявність дефектів і вивчають можливості покращення продукту (специфікація).
Учасники:
5. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)
6. Автор будь-якого попереднього продукту для елемента, який варто перевірити.
7. Люди, що виконують роботу, що базуються на перевіряємому елементі.
8. Люди, що відповідають за роботу продуктів, що взаємодіють з перевіряємим елементом. Вони виявляють проблеми з вимогами до зовнішнього інтерфейсу. Також модуть виявити вимоги, зміна яких в перевіряє мій спеці впливає на інші системи.
Проблеми перевірки:
1. Великий об’єм документації
2. Велика команда експертів (бажано не більше шести)
3. Географічній роздій інспекторів (доводиться зв’язуватись по відео або пошті)
Перегляд електронного файлу, що розміщується в загальній мережевій папці – метод, альтернативний традиційним нарадам експертів. В цьому випадку рецензенти використовують функції текстового редактору, щоб ввести свої коментарі в перевіряє мий документ. Кожний документ помічається ініціалами експерта – таким чином будь-хто може познайомитись з думкою інших експертів.
Ролі експертів:
1. Автор. Створює та підтримує продукт, що перевіряється. Тобто аналітик, що розробляв спеку.
2. Координатор – керівник перевірки, планує експертизу сумісно з автором, погоджує особливості і організовує нараду.
3. Читач. Один із перевіряючих виступає в ролі читача. На нараді він перефразовує положення спеки – по одній вимозі за раз.
4. Секретар – використовує стандарті форми для документування питань та дефектів, що були виявлені в ході наради. Секретар має в голос прочитати всі свої записи, щоб упевнитися в їх точності. Інші учасники інстпетування повинні допомогти йому зафіксувати суть кожної проблеми.
Рішення про завершення експертизи приймається відповідно до одного (будь-якого) з трьох критеріїв:
1. Прийняття з відсутністю або малою необхідністю переробки
2. Прийняття з перевіркою перероблених фрагментів.
3. Необхідність повторної експертизи.
Під управлінням вимогами мають на увазі всі дії, що підтримують цілісність, точність і своєчасність відновлення угоди про вимоги в ході проекту.
До дій по управлінню вимогами відносять:
- Визначення основної версії вимог (моментальний зріз вимог для конкретної версії продукту);
- Перегляд пропонуємих змін вимог і оцінка ймовірності впливу кожної зміни до її прийняття;
- Включення схвалених змін вимог в проект встановленим способом;
- Погодження плану проекту з вимогами;
- Обговорення нових обов’язків, що базуються на оцінюванні впливу зміни вимог;
- Відслідковування окремих вимог до проектування, вихідного коду і варіантів тестування;
- Відслідковування статусу вимог і дій по зміні на протязі всього проекту.
Дата добавления: 2015-07-11; просмотров: 213 | Нарушение авторских прав