Планування проекту

13.12.2012

06.12.2012

29.11.2012

24.01.2013

27.12.2012

Процедура внесення змін у вимоги

Правила політики контролю змін

1) Всі зміни вимог повинні вноситись відповідно з процесами

2) не можна займатись проектуванням або реалізовувати незатверджені зміни,окрім перевірки їх реалізовуваності.

3) Запит на зміну ще не гарантує її виконання. Рішення по реалізації змін приймає група по управлінню змінами(ССВ).

4) Вміст репозиторію змін має бути досягнутим для всіх зацікавлених осіб, які мають на це право.

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

6) Кожна затверджена зміна повинна прослідковуватись до її реалізації.

7) Обґрунтування кожного схваленого або відхиленого запиту на зміну необхідно документувати.

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

1) Вхідний критерій.

2) Задачі задіяні в процесі

3) Учасники,які відповідають за вирішення задачі.

4) Вихідний критерій

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

1.Вступ

1.1. Призначення

1.2.Межі/границі

1.3. Визначення

2. Ролі і відповідальності

v Керівник групи по внесенню змін

v Члени групи по управлінню змінами

v Член групи по оцінюванні змін

v Член групи, що вносить зміни

v Особа,яка ініціює запит на зміну

v Особа,яка верифікує зміну

Ініціатор

Подає запит на зміну

Відправлено(подано)

Аналіз впливу змін

Оцінка виконана

Відхилено  

Визначається версія і

відповідальний за зміну

Схвалено

вніс зміну і запросив

Відмінення

перевірку

Зміну внесено

Перевірено

Завершено

3. Стани та запити (Діаграма)

4. Вхідні критерії

5. Задачі

5.1. Оцінка запиту

5.2. Прийняття рішення

5.3. Внесення зміни

5.4. Повідомлення усіх зацікавлених осіб

6.Перевірка

6.1.Перевірка зміни

6.2.Встановлення(продукту)

7.Вихідний критерій

7.1. Стан запиту(відхилено,закрито,відмінено)

7.2. Всі зміни записано у відповідні розділи

7.3.Ініцатор змін і всі зацікавлені повідомлення

7.4.Матриця зв’язків вимог оновлення.

Елементи(атрибути)внесених змін

Елементи	Опис
Ідентифікатор на зміну	Порядковий номер
Джерело зміни	Хто пропонує зміну? (Маркетологи)
Тип зміни	Зміна вимог, пропоноване покращення (Task,Story)
Дата подачі
Дата оновлення
Опис	Текстовий опис у вільній формі
Пріоритет реалізації	Важливість внесення змін
Особа,яка вносить зміну	Людина відповідальна за зміну
Планована версія	Версія, в якій зроблена зміна
Стан	Поточний стан запиту за зміну
Назва
???????	Особа,яка перевіряє коректність зміни

В групу внесення змін входить

v менеджер проекту,

v менеджер продукту,

v аналітик вимог,

v спеціалісти з тестування (спеціалісти відповідають за технічну користувацьку документацію)

v спеціалісти служби підтримки

Вимірювання активності змін – це спосіб оцінки стабільності вимог.

Враховують:

o кількість отриманих запитів на зміни,включаючи відкриті/закриті.

o кількість запитів,включаючи відмінені,

o кількість запитів, на зміни з різних джерел.

o кількість змін, запропонований на кожну вимогу, після створення базової версії.

Аналіз впливу змін

· Визначення можливих наслідків змін

· Визначення файли, моделі, документи, які можливо доведеться змінити

· Визначити задачі необхідні для реалізації змін і оцінити зусилля для виконання задач

Список можливих наслідків пропонованих змін:

· Чи конфліктують якісь із вимог з базовою версією

· Які можуть бути технічні або бізнес наслідки, якщо зміни не будуть внесені

· Які можуть бути наслідки, якщо не внести змін

· Чи вплине негативно зміна вимог і атрибути якості

· Чи необхідно створення прототипів для перевірки змін

· Скільки затрат буде втрачено якщо прийняти зміну;

Потреби замовника

Трасування вимог (т. в.)

Основні робочі продукти

Вимоги

В напрямку до вимог

Можливі зв’язки трасованості вимог

взаємозалежність

пермодж.

зміна

перевірка

реалізація

перевірка

перевірка

від. до ств

вплив

зміна

зміна

зміна

Бізнес - вимоги

Запити на зміни

Основи системних вимог В. в., вимоги до зовнішніх інтерфейсів Атрибути якості  

Бізнес правила

Функціональні вимоги

Користувацькі інтерфейс Функціональний дизайн

Тестування системи

Задачі клонування проекту

Тестувальні цілісності

Код

Тестування елементів

Переваги реалізації трасування вимог:

· Сертифікація

· Підтримка

· Аналіз впливу змін

· Зниження ризиків

· Тестування

Спосіб представлення трасованості:

· Матриця відслідковуваності вимог

Для реалізації трасованості:

· Відношення зв’язків

· Тип матриці трасованості вимог

· Визначення частини продукту для яких буде підтрим. Інформація т. продукту

· Узгодження іменування, яке використовують для унікальної ідентифікації всіх елементів системи

Пріорітезація – це спосіб вирішення конфліктів між вимогами за обмежені ресурси.

Вирішення: прибрати вимоги з меншим пріоритетом. Кожну вимогу можна вважати важливою/не важливою і терміновою/не терміновою.

	Важливі	Не важливі
Термінові	Високий пріоритет	Можна відкинути
Не термінові	Середній пріорітет	Низький пріоритет

Табл. Пріоритезації Конвоя

- QFM

- TQM

Методи визначення пріоритетів на основі цінності, вартості, ризиків:

Валові коеф.
Характер.	Користь	Відносн. збиток	Цінність	Відн. цінність	Вартість	%	Ризик	%	Пріоритет
Роздрук списку
Запит
Створ. звіту

25=9*2+7*1

Всього

Пріорітет

Затвердження вимог

Кодування

Користувацькі вимоги

Функціональні вимоги

Проектування архітектури

Дизайн проектування ф-цій

Приймання тестування

Системне тестування

Інтеграція тестування(перевірка цілісності)

Модульне тестування

Планування модульного тестування  

Затвердження вимог дозволяє переконатися, що:

¾ Очікування можливості і характеристики проекту

¾ Вимоги точно відображають системні вимоги бізнес-правил

¾ Вимоги повні і якісні

¾ Вимоги узгоджені між собою

¾ Вимоги створюють якісну основу для подальшої імплементації продукту

Рев’ю(інспектування)

Формальне Неформальне

-walk throw(наскрізний контроль) -Desktop checking

-fagan inspection(формальне інспектування) -колективна перевірка

Учасники формального інспектування:

¾ автор, колеги автора;

¾ автор попереднього продукту або специфікації для елемента, який необхідно перевіряти;

¾ люди, які будуть виконувати роботу: розробники, тестувальники;

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

Макс 6 чоловік

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

¾ автор;

¾ аналітик;

¾ координатор(модератор) – планує експертизу, узгоджує особливості, розподіляє матеріал, управляє нарадою, інформування про результати;

¾ читач (reader);

¾ writer, scriber (секретар).

Вхідні критерії:

¾ документ відповідає шаблону;

¾ виконана перевірка граматики;

¾ підготовлені всі супровідні документи або посилання;

¾ невирішені питання ТВД;

¾ координатор не виявляє більше 3-ьох істотних дефектів протягом 10 хвилин.

Етапи формального тестування:

Початковий продукт

e [3201]" strokecolor="#c0504d [3205]" strokeweight="2pt">

Планування

Оглядова зустріч

Інспекційна нарада

Підготовка

Переробка

Заключний етап

Заключний продукт

Планування – автор і координатор, дата експертизи, об’єм пакету. Оптимально розглядати 2-4 сторінки на год.

Оглядова зустріч – автор описує матеріал.

Підготовка(експертиза) – 75% дефектів

Інспекційна нарада – не довше 2 год.

Вихідні критерії

1) Вирішено всі питання

2) Всі зміни внесені в документ чи інші відповідні продукти були внесені коректно.

3) Всі проблеми, помічені ТВД – вирішені, при цьому фіксувались дата,автор.

4) Документ був звірений з допомогою системного управління конфігурацією

5) Контрольний список дефектів.

Контрольний список дефектів, з допомогою варіантів використання

1) Чи є варіант використання автономною і окремою задачею

2) Чи чітко сформулювала мета для конкретного варіанту використання.

3) Чи зрозуміло, хто отримує переваги від цього варіанту використання.

4) Чи сформульований варіанту використання на базовому рівні

5) Чи всі альтернативні напрямки варіанту використання задокументовані

6) Чи задокументовані відомі умови виключення

7) Чи належним чином варіанту використання структурує вхідні і вихідні мови

8) Чи реалізований і піддається перевірці кожен визначений напрямок варіанту використання

Контрольний список дефектів для специфікації вимог

1) Організація і завершеність

ü Чи написані всі вимоги на одному і тому ж рівні деталізації

ü Чи конкретні всі внутрішні перехресні посилання

ü Чи забезпечують вимоги адекватну основу для проектування

ü Чи вказаний пріоритет реалізації кожної вимоги

ü Чи включені всі відомі потреби клієнта(системи)

ü Чи визначені всі зовнішні інтерфейси обладнання програмних продуктів і їх взаємодії

ü Чи задокументована очікувана поведінка системи для імовірних подій

2) Конкретність

ü Чи конфліктують певні вимоги між собою, або повторність їх

ü Чи написана кожна вимога зрозумілою точною і недвозначною мовою

ü Чи не виходять вимоги за границю проекту

ü Чи можна реалізувати всі вимоги,не виходячи за рамки обмежень

ü Чи можна перевірити кожну вимогу з допомогою тестування,огляду аналізів

ü Чи немає граматичних помилок

ü Чи всі повідомлення про помилки унікальні і зрозумілі

3) Атрибути якості

ü Чи всі завдання пов’язані з продуктивністю сформульовані належним чином

ü Чи всі задачі явно заду коментовані і оцінені з врахуванням прийнятих компромісів

ü Чи всі завдання, що стосуються безпеки сформульовані належним чином

4) Послідковуваність вимог

ü Чи кожна умова ідентифікована унікально і коректно

ü Чи послід кована кожна функціональна вимога до більш високого рівня

5) Особливі проблеми

ü Чи всі вимоги можна віднести власне до вимог,а не реалізації

ü Чи ідентифіковані всі функції, шо залежать від часу,чи визначені їх критерії

ü Чи були розглянуті належним чином потреби, пов’язані з інтернаціоналізацією

Проблеми:

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

*виділити обсяг підвищеного ризику та мало пріоритетності

2) Велика команда експертів

*переконатись, що кожен учасник знає свою область роботи

Взаємозв’язок вимог з іншими етапами проекту

Основна версія вимог

Планування проекту

Проектування і кодування

Тестування

1) Використання вимог для оцінки масштабу проекту

2) Оновлення планів при зміні вимог

3) Врахування пріоритетів вимог, при плануванні ітерації

Проектування і кодування

1) Врахування атрибутів якості при проектуванню архітектури

2) Розподіл вимог за компонентами

3) Відслідковування вимог до дизайну і коду

Дата добавления: 2015-05-24