1.5. Абревіатури

CI - Configuration Item. Елемент конфігурації.

СММ - Capability Maturity Model. Модель зрілості можливостей. IEEE - Institute of Electrical and Electronics Engineers. Інститут інженерів з електротехніки та радіоелектроніки.

QA - Quality Assurance. Контроль якості.

SEI - Software Engineering Institute. Інститут технологій розробки программного забезпечення.

SCMP - Software Configuration Management Plan. План управління конфігураціямі програмного забезпечення.

SPMP - Software Project Management Plan. План управління програмним проектом (даний документ).

SRS - Software Requirements Specification. Специфікація вимог до про програмного забезпечення.

SDD - Software Design Document. Проектна документація програмного забезпечення.

STP - Software Test Plan. План тестування програмного забезпечення.

2. Організація проекту

2.1. Модель процесу

Перші дві версії цього проекту будуть виконані з використанням спіральн го процесу розробки, по одній ітерації на версію. Ітерації проводяться в совідності з USDP. Згідно USDP, ітерації класифікуються на початкові ітерації, ітерації проектування, конструювання та переходу. Перша Ітерація буде складатися тільки з аналізу і планування вимог, друга ітерація буде першою в серії ітерацій проектування. Це складе версію 1 гри Final Fantasy. Кількість подальших ітерацій і склад версії 2 будуть визначено після того, як замовник ознайомиться з версією 1.

2.2. Організаційна структура

Організація проекту Final Fantasy в рамках корпорації Gaming Industries Consolidated представлена ​​на рис. 2.15. Проект організований як команда рівних з призначенням ролей. Ролі наступні: лідер команди, відповідальний за конфігурацію, відповіє за якість, відповідальний за вимоги, відповідальний за проектування і відповідальний за реалізацію. Крім того, є роль відповідального за зв'язки з відділом маркетингу і з лабораторією технології програмування. Всі ці ролі показані на рис. 2.1. У проекті Final Fantasy буде проводитися інспекціювання всієї роботи, як це визначено в SQAP. Кожен учасник команди буде проводити інспектування роботи інших учасників (див. рис. 2.1.2). Інспектування буде відбуватися або групове, або, якщо не буде вистачати часу, індивідуальне автором і тим, хто його заміщає.

2.3. Організаційні рамки і взаємозв'язку

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

2.4. Відповідальність за проект

Відповідальність учасників проекту показана в табл. 2.20. Відповідальність за документ має на увазі наступне:

♦ документ повинен бути створений вчасно;

♦ лідер команди визначає, хто пише документ;

♦ документ підтримується в актуальному стані.

3. Керуючий процес

3.1. Цілі та пріоритети

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

3.2. Допущення, залежності і обмеження

Ні.

3.3 Управління ризиками

Форма для ідентифікації та обробки ризиків показана в табл. 2.21. Кожен за проектом повинно включати до порядку денного пункт «мозковий штурм з метою виявлення ризиків». Ризик № 1 «Накладення зображень» звязаним з можливостями маніпулювання зображеннями на мові С++. Представивши, що ніхто в команді не пробував накладати зображення. Накладати зображення необхідно, оскільки зображення персонажів повинні рухатися на тлі зображення зони. Ніхто в команді не пробував накладати зображення так, щоб не було видно прямокутного кордону накладуємому образу. Ми не знаємо, чи легко це зробити, важко або взагалі неможливо.

Ризик № 2, «недостатні навички програмування на С++», відображає той факт, що 40% команди не мають достатнього досвіду програмування на С++ для того, щоб реалізувати рух і взаємодію зображень персонажів. Ми припускаємо, що знадобиться масштабувати ігровий простір, і в цьому також немає досвіду. Ми не знаємо, чи зможемо ми реалізувати на С++ ті можливості, які має на увазі замовник, а якщо зможемо, то скільки це буде потребувати часу. Ця обставина може серйозно пошкодити проекту.