3.4. Механізми моніторингу та контролю

Вся команда буде зустрічатися на нараді на початку кожної фази (визначенні вимог, проектування, реалізація) кожної ітерації. Повинні проводитися щотижневі наради за проектом по вівторках з десятої ранку до полудня. Слід вжити всіх заходів до того, щоб на цих нарадах розглядалися відразу всі загальні для команди справи. Учасники команди повинні зарезервувати час по п'ятницях з 9 до 11 для проведення додаткових нарад, якщо знадобиться. Лідер команди повинен попередити учасників про проведення додаткового наради не пізніше 16:30 в четвер.

3.5. План розстановки кадрів

Призначення ролей зазначено в табл. 2.23. Кожен учасник команди має додаткові обов'язки щодо резервування та інспектування (див. рис. 2.16).

Таблиця 2.23. Розстановка учасників проекту Final Fantasy

Ім’я	Лідер команди	Відповідальний за конфігурацію	Відповідальний за якість		Відповідальний за вимоги	Відповідальний за проектвання	Відповідальний за реалізацію
Тичина Владислав	X						X
Горецький Олександр.		X
Сташкевич Богдан.				X
Буковчик Юра					X
Присяжнюк Дмитро						X

Таблица 2.23. Розстановка участників проекта Final Fantasy.

4. Технічний процес

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

4.1. Методи, інструменти та технології

У проекті Final Fantasy реалізація ведеться на мові С++. У всіх випадках використовується об'єктно-орієнтованийний підхід. Для документування використовується С++doc настільки широко, наскільки це можливо (докладніше див SRS). Використовувана модель процесу описана в розділі 2.1.

4.2. Документація програмного забезпечення

Див SQAP, розділ 4.2.

4.3. Функції супроводу проекту

На весь час проведення проекту буде залучена на півставки технічний фахівець з підтримки інструментів.

5. Розподіл робіт, план-графік і бюджет

5.1. Залежності

Друга ітерація залежить від результатів першої. Інженер Тичина зайнятий в проекті Game 123, і з імовірністю 50% він буде недоступний в перший місяць проекту.

5.2. Потреби в ресурсах

У проекті будуть зайняті сім інженерів, один секретар на півставки і один технічний фахівець на півставки.

Апаратні ресурси складуть вісім комп'ютерів intel Core i5 1.2 Ггц з операційною системою Windows 7 і системою програмування Borland Builder 6.0. Кожен комп'ютер повинен мати не менше 1 Гбайт RAM і не менше 6 Гбайт простору на жорсткому диску.

5.3. Виділення бюджету і ресурсів

Оцінка до початку аналізу вимог. Дана оцінка проведена трьома різними методами.

1. З використанням неформальної оцінки зверху вниз на основі попереднього досвіду команди по аналогічним проектам.

2. З використанням оцінки зверху вниз на основі даних по галузі.

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

Результати наведені в табл. 2.23 (всі величини дані в тисячах рядків вихідного коду на мові С++).

Таблиця 2.24. Попередня оцінка розміру додатка до аналізу вимог

Метод	Мінімум	Максимум	Комментарій
1	7,5	170
2	4,2	300
3	11,4	46	1,9-2,3 для двох функцій,помножені на 6-20 по числу функцій всього додатка
Наибільш консервативна оцінка	11.4	300	Максимум мінімумів і максимум
			Максимумів
Найменьш консервативна оцінка	4,2	46	Мінімум мінімумів і мінімум
			максимумів
Найбільш широкий діапазон	4,2	300	Мінімум мінімумів і максимум
			Максимумів
Найменьш широкий діапазон	11,4	46	Максимум мінімумів і мінімум
			Максимумів

Найбільш широкий діапазон використовується тому, що оцінки були отриманІ за умови недостатньої взаємодії з замовником.

♦ Оцінка з використанням вимог замовника до початку збору детальних вимог. Повинна бути представлена​​.

♦ Оцінка з використанням детальних вимог до початку проектуванняня архітектури.

Повинна бути представлена​​.

♦ Оцінка з використанням архітектури до початку детального проектування. Повинна бути представлена​​.

♦ Оцінка з використанням результатів детального проектування до почала реалізації.

Повинна бути представлена​​.

♦ Оцінка в кінці ітерації 1 до початку ітерації 2. Повинна бути представлена​​.

♦ Оцінка в кінці ітерації 2 до початку ітерації 3. Повинна бути представлена​​.

6. Доповнення

6.1. Покажчик

Повинен бути представлений.

6.2. Додатки

Повинен бути представлений.

Приклад 2. План контролю якості (SQAP), частина 2

Першу частину SQAP див. приклад 2 глави 1.

7. Тестування

На перших трьох ітераціях всі функції з контролю якості виконує відповідальний за якість. На наступних ітераціях відділ контролю якості повинен виділити команду з контролю якості та передати їй ці функції. Опис команди з контролю якості буде представлено. Команда проекту FinalFantasy несе відповідальність за тестування окремих методів і комбінацій методів в класі (модульне тестування). Відповідальний за якість (в подальшому - команда з контролю якості) відповідальний за всі інші види тестування (глави 8 і 9 даної книги). Подальші деталі тестування викладені в STD проекту Final Fantasy