Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Характеристики правильно складеної SRS



Читайте также:
  1. E) Нет правильного ответа
  2. I. Схема характеристики.
  3. III. Экономические и эксплуатационные характеристики
  4. V - образные характеристики
  5. А правильно ли...?
  6. Анализ энергетического баланса электромагнита и вывод общей формулы для расчёта тяговой характеристики электромагнита.
  7. Асимптотические характеристики

SRS – специфікація для конкретного (визначеного) ПЗ, програми чи набору програм, які виконують визначені функції в конкретному середовищі.

SRS можуть бути складені одним або декількома представниками постачальника, одним або декількома представниками клієнта, або обома.

Характеристика правильно складеної SRS:

· Коректність

· Однозначність

· Повнота

· Несуперечливість

· Упорядкованість за значністю

· Перевіряємість

· Модифікуємість

· Відслідковуваність

 

 

  1. Проблемні ситуації процесу формування і оцінки вимог

Проблемні ситуації:

1. Двозначність. Ситуація, коли одну вимогу можна інтерпретувати більше ніж в одному значенні.

2. «Золочення» продукту – такі ситуації, коли розробники додають функції, яких немає в специфікації, але їм здається, що це сподобається користувачам. Але замовнику може це не сподобатись.

3. Мінімальна специфікація – представлення вимог на 2-3 сторінках (у невеликих проектах). Мінімальне спека доречна, якщо має місце наявність одночасно трьох обставин:

a. Ціна контракту і розміри проекту настільки малі, що розробляти повну спеку є дорогим задоволенням.

b. Колектив розробника володіє достатнім ступенем досвіду виконання проектів у суміжних областях

c. Між замовником та розробником існують конструктивні відносини і обидві сторони розуміють і приймають ризики міні-специфікації.

 

  1. Методи і засоби перевірки вимог

Методи і засоби перевірки вимог розрізняють за параметрами:

1. За широтою аналізу – перегляд (вибіркова перевірка)

2. За ступенем формалізації – неофіційні процедури, процедури, що проводяться за формальними правилами (інспекції, експертизи).

3. За складом групи перевірки – з (без) участю автора, з (без) участі менеджера проекту, з (без) участю представників зовнішніх організацій.

4. За використовуваними засобами – тексти вимог, тестові сценарії, критерії прийнятності, прототип.

 

Неофіційні перегляди вимог:

1. Перегляди «за столом» (коли перевірку робить колега по роботі)

2. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

3. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

У третьому випадку автор здійснює презентацію розроблених ним вимог на параді з подальшим обговоренням.

 

Офіційна перевірка вимог:

На відміну від неофіційних переглядів, офіційна перевірка представляє собою суворо регламентований процес. По його завершенню формується звіт, в якому вказуються матеріали, рецензенти (ті, хто буде оцінювати продукт – експерт) і думка команди рецензентів про прийнятність продукту.

Головний результат – сукупність усіх знайдених дефектів і піднятих питань.

 

Експертиза як метод перевірки вимог (інспекція):

Експертиза проводиться командою кваліфікованих спеціалістів, які ретельно перевіряють продукт на наявність дефектів і вивчають можливості покращення продукту (специфікація).

Учасники:

1. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

2. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

3. Люди, що виконують роботу, що базуються на перевіряємому елементі.

4. Люди, що відповідають за роботу продуктів, що взаємодіють з перевіряємим елементом. Вони виявляють проблеми з вимогами до зовнішнього інтерфейсу. Також модуть виявити вимоги, зміна яких в перевіряє мій спеці впливає на інші системи.

 

  1. Неофіційні перегляди вимог. Інспекції

Неофіційні перегляди вимог:

4. Перегляди «за столом» (коли перевірку робить колега по роботі)

5. Колективна перевірка (коли запрошується декілька колег для паралельної перевірки продукту)

6. Критичний аналіз (автор описує створюваний продукт і просить його прокоментувати).

У третьому випадку автор здійснює презентацію розроблених ним вимог на параді з подальшим обговоренням.

Експертиза як метод перевірки вимог (інспекція):

Експертиза проводиться командою кваліфікованих спеціалістів, які ретельно перевіряють продукт на наявність дефектів і вивчають можливості покращення продукту (специфікація).

Учасники:

5. Автор продукту і можливо колеги автора (аналітик, що склав документацію вимог)

6. Автор будь-якого попереднього продукту для елемента, який варто перевірити.

7. Люди, що виконують роботу, що базуються на перевіряємому елементі.

8. Люди, що відповідають за роботу продуктів, що взаємодіють з перевіряємим елементом. Вони виявляють проблеми з вимогами до зовнішнього інтерфейсу. Також модуть виявити вимоги, зміна яких в перевіряє мій спеці впливає на інші системи.

 

Проблеми перевірки:

1. Великий об’єм документації

2. Велика команда експертів (бажано не більше шести)

3. Географічній роздій інспекторів (доводиться зв’язуватись по відео або пошті)

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

 

Ролі експертів:

1. Автор. Створює та підтримує продукт, що перевіряється. Тобто аналітик, що розробляв спеку.

2. Координатор – керівник перевірки, планує експертизу сумісно з автором, погоджує особливості і організовує нараду.

3. Читач. Один із перевіряючих виступає в ролі читача. На нараді він перефразовує положення спеки – по одній вимозі за раз.

4. Секретар – використовує стандарті форми для документування питань та дефектів, що були виявлені в ході наради. Секретар має в голос прочитати всі свої записи, щоб упевнитися в їх точності. Інші учасники інстпетування повинні допомогти йому зафіксувати суть кожної проблеми.

 

Рішення про завершення експертизи приймається відповідно до одного (будь-якого) з трьох критеріїв:

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

2. Прийняття з перевіркою перероблених фрагментів.

3. Необхідність повторної експертизи.

 

  1. Визначення критеріїв прийнятності

 

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

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

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

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

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

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

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

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

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

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


Дата добавления: 2015-07-11; просмотров: 213 | Нарушение авторских прав






mybiblioteka.su - 2015-2024 год. (0.009 сек.)