6. Аудити і огляди програмного забезпечення

6.1. Ціль

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

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

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

6.2.1. Огляд специфікацій програмного забезпечення

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

6.2.2. Огляд архітектури проекту

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

6.2.3. Детальний огляд проекту

Не застосовується

6.2.4. Огляд плану верифікації

Не застосовується

6.2.5. Функціональний аудит

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

6.2.6. Фізичний аудит

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

6.2.7. Робочі перевірки

Робочі перевірки повинні проводитись кожного дня за 2 години перед завершенням робочого дня. Розробники повинні ознайомити відповідального за якість зі всіма змінами у коді.

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

Не застосовується

6.2.9. Огляд плану управління конфігураціями програмного забезпечення.

Не застосовується

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

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

6.3. Інші огляди та аудити

Не застосовується

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

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

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

8. Звіти про проблеми та діях по їх усуненню.

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

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

Інструменти, які використовуються для підтримки оглядів:

• Microsoft Word 2007

• Система електронної пошти

Microsoft Word використовується для написання звітів про огляди. Систему електронної пошти використовують для зв’язку відповідального за якість, розробників, тестерів, менеджера проекту та замовника.

10. Контроль носіїв інформації

Відповідальний за якість перевіряє, чи носії, які використовують розробники та інші члени проекту правильно встановлені і протестовані. Факт перевірки носіїв інформації засвідчується штампом на відповідному носії. Звіт про перевірку носіїв інформації надається менеджеру.

11. Контроль постачальників

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

12. Збір, підтримка і зберігання записів

Звіти про перевірку та затвердження тестів, аудити, огляди, контроль інформації, інші документи SQA повинні зберігатись на сервері системи. Тільки відповідальний за якість та менеджер проекту повинні мати право вносити поправки у звіти.

13. Навчання

Для учасників проекту повинен бути організований курс, який би розповідав їм про стандарти підтримки якості. Ці курси повинні обов’язково прослухати усі члени команди

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

Не застосовується

15. Словник термінів і акронімів.

Термін	Визначення
Відповідальний за якість	Особа, яка досконало знає стандарти якості і відповідає за якість програмного продукту.
SQA	Гарантія якості програмного забезпечення
SQAP	План гарантії якості ПЗ
Огляди	Перевірки, які поводяться задля підтримки якості системи
Записи	Звіти та інші документи SQA
Стандарт	Документ, розроблений на основі консенсусу та затверджений уповноваженим органом, який встановлює призначені для загального і багаторазового використання правила, інструкції або характеристики, які стосуються діяльності чи її результатів. Стандарт може містити вимоги до термінології, позначок чи маркування, які застосовуються до певного процесу.
Метрика	Показник вимірювання деяких частин програмного забезпечення, або його характеристик.