5. Стандарти, практики, домовленості і метрики.

   1. Мета:

В проекті Остання фантазія використовується найсучасніші стандарти, практики і метрики.

2. Зміст.

Стандарти:

Для ведення документації використовуються стандарти IEEE з відповідними модифікаціями.

Практики.

1. Оскільки відкладати забезпечення якості накладно, компанія GCI по-заохочувати своїх інженерів застосовувати процедури забезпечення якості не-посередньо під час роботи, а не відкладати на потім.

2. Компанія GCI вважає, що ніякий засіб забезпечення якості, зовнішнє по відношенню до конкретного розробника, не може саме по собі забезпечити більш високу якість, ніж це може зробити сам разрабник. Контроль якості в GCI розглядається насамперед як навчання, а не як система нагляду або покарань. Інженерам, які ще не мають досвіду застосування такої системи, рекомендується увійти в контакт з наставником за якістю.

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

4. Для всіх процесів має бути проведений огляд можливості поліпшення хоча б раз, і результати цього огляду в письмовій формі повинні бути направлені в лабораторію технології програмування (розділ 6.2.10).

Угоди.

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

Метрики.

Для кожного процесу і кожного документа повинні вимірюватися принаймні три показники.

1. Час, витрачений співробітником, на виконання кожної підзадачі.

2. Самооцінка якості за шкалою від 1 до 10; ці дані не можуть бути використуватися керівництвом для оцінки персоналу, проте їх відсутність може бути прийнято до уваги.

3. Кількість дефектів на одиницю об'єму (наприклад, на тисячу рядків коду).

Компанія GСI ставить перед собою мету досягти наступних показників якості своїх продуктів.

Обмеження на число дефектів, що виявляються протягом двох місяців після поставки.

♦ Вимоги: не більше одного незначного дефекту на сто детальних вимог.

♦ Проектування: не більше одного незначного дефекту на п'ять діаграм.

+ Псевдокод: не більше двох незначних дефектів на тисячу рядків.

♦ Код: не більше двох незначних дефектів на тисячу рядків коду, не враховуючи коментарів.

Фактичні дані по проекту повинні бути представлені в додатку 1 до цього документа.

6. Огляди та аудити

6.1. Мета

Мета оглядів та аудитів полягає в тому, щоб привернути увагу розробників до якості додатка в ході розробки. Огляди проводяться на плановій регулярній основі. Об'єкти аудиту вибираються випадковим чином.

6.2. Мінімальні вимоги

IПрімечаніе для студентів. У великих проектах потрібен повний список оглядів та аудитів, наведений тут. Студентська команда як мінімум повинна провести огляди та інспектування вимог і проектування, а також заключний огляд після закінчення проекту. «Огляд» має на увазі обговорення пропонованого артефакту. «Інспектування» застосовується до закінченого артефакту.!

План проведення оглядів описаний в SPMP. Суть оглядів вказана нижче. 6.2.1. Огляд вимог до програмного забезпечення

Даний огляд проводиться по всьому документу з вимогами в присутності всієї команди. Огляд веде лідер проекту. Передбачається, що вимоги не були інспектувати Дода огляду. Даний огляд не підміняє інспектування вимог. Відповідальний за вимоги зобов'язаний простежити, щоб інспектування вимог відбулося (див. SPMP).

6.2.1 А. Інспектування вимог до програмного забезпечення

Всі вимоги повинні бути інспектувати відповідно до Посібника з проведення інспектування компанії GCI, документ 345678.

6.2.2. Попередній огляд проектних рішень

Даний огляд альтернативних архітектурних рішень виконується всією командою. Огляд проводиться лідером проекту або його заступником. Мається на увазі, що команда дасть пропозиції, які будуть враховані в остаточному варіанті проекту. Альтернативні архітектури не повинні інспектуватися до даного огляду. Відповідальний за проектування зобов'язаний простежити, щоб даний огляд відбувся (див. SPMP).

6.2.3. Критичний огляд проектних рішень

Це інспектування запропонованої архітектури в присутності всієї команди. Відповідальний за проектування зобов'язаний простежити, щоб це інспектування відбулося. Архітектура не повинна інспектуватися до даного огляду. Якщо це можливо, архітектура повинні бути розкладена на складові частини і по кожній з них повинен бути проведений критичний огляд проектних рішень.

6.2.4. Огляд SWP

Оскільки верифікація і валідація мають виконуватися незалежною командою, в даному плані не передбачається огляд SVVP.

6.2.5. Аудит функціональності

Лідер проекту перед поставкою продукту зобов'язаний організувати перевірку того, що продукт відповідає SRS. Якщо необхідно зробити якісь винятки, лідер проекту зобов'язаний отримати попередній дозвіл на поставку від свого керівника. Дані винятки мають бути доведені до відома замовника за допомогою відповідних засобів, в тому числі файлу README і супровідного листа.

6.2.6. Аудит фізичних компонентів

До поставки відповідальний за якість зобов'язаний організувати перевірку того, що програмне забезпечення та документація, призначені для поставки, фізично включені в пакет поставки.

6.2.7. Аудити процесу

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

Оскільки організація рухається в бік СММ рівня 5, всі робочі матеріали повинні бути вільно доступні аудиторам і команді в будь-який час. Робота повинна бути чітко організована, так щоб аудити можна було проводити і без попередження.

6.2.8. Огляд управління

Найвище керівництво повинне проводити огляд проекту Final Fantasy в перший тиждень кожного місяця. Лідер проекту відповідальний за організацію таких оглядів.

6.2.9. Огляд SCMP

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

6.2.10. Заключний огляд

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

6.3. Інспектування

Всі артефакти проекту Final Fantasy повинні інспектуватися.