Аудити і огляди програмного забезпечення
6.1. Ціль
Ціль оглядів і аудитів полягає в тому, щоб привернути увагу розробників до якості продукту в ході розробки. Огляди проводяться на плановій регулярній основі. Об'єкти аудиту вибираються випадковим чином.
6.2 Мінімальні вимоги
Як мінімум, слід виконати наступні огляди програмного забезпечення.
6.2.1. Огляд специфікацій програмного забезпечення
SSR проводиться для забезпечення адекватності вимог.
6.2.2. Огляд архітектури проекту
ADR проводиться, щоб оцінити технічну адекватність проекту (відомого також як top-level design) програмного забезпечення, описаного в описі проекту програмного забезпечення.
6.2.3. Детальний огляд проекту
DDR проводиться, щоб визначити адекватність детального проекту програмного забезпечення, який знаходиться в описі детального проекту програмного забезпечення, в частині задоволення вимог SRD.
6.2.4. Огляд плану верифікації
Огляд плану верифікації здійснюється, щоб оцінити адекватність і повноту методик верифікації.
6.2.5. Функціональний аудит
Цей аудит проводиться перед постачанням програмного забезпечення, щоб переконатися, що всі вимоги виконані.
6.2.6. Фізичний аудит
Цей аудит здійснюється, щоб перевірити внутрішню узгодженість програмного забезпечення і його документації, а також їх готовність до випуску.
6.2.7. Робочі перевірки
Робочі перевірки фрагментів проекту проводять, аби перевірити узгодженість проекту, в тому числі:
- узгодженість коду та проектної документації.
- узгодженість специфікації.
- відповідність реалізації проекту функціональним вимогам.
- узгодженість функціональних вимог і описів тестів.
6.2.8. Огляди управління
Огляди управління проводяться періодично, щоб перевірити можливість доступу до всіх матеріалів, перелічених в SQAP. Огляди управління проводяться зазвичай керівним персоналом.
6.2.9. Огляд плану управління конфігураціями програмного забезпечення
Відповідальний за якість повинен проводити огляд стану управління конфігураціями не менше ніж раз на місяць незалежно від процедур, встановлених у плані керування конфігураціями
6.2.10. Заключний огляд
У заключний огляд включаються огляд закінченої фази і огляд самого процесу контролю якості. Відповідальний за якість зобов'язаний скласти звіт про поліпшення процесу на кожній фазі.
6.3. Інші огляди та аудити
Інші огляди та аудити можуть включати в себе огляд користувацької документації (user documentation review, UDR). Цей огляд проводиться, щоб оцінити адекватність користувацької документації.
Тестування
Секція описує, як проводиться контроль за перевіркою і затвердженням перевірки тестів.
Звіти про проблеми та дії по їх усуненню.
В цьому розділі описується, як описуються та усуваються дефекти
Інструменти, технології та методології
Цей розділ повинен перерахувати програмні інструменти, технології та методики, що використовуються для підтримки процесів SQA.
Контроль носіїв інформації
Цей розділ повинен встановити методи та засоби, які використовуються для:
- визначення носіїв інформації для зберігання комп'ютерного продукту.
- захисту фізичного носія комп'ютерної програми від неавторизованого доступу або ненавмисного пошкодження.
Контроль постачальників
Дії, які застосовуються до зовнішніх організацій або осіб. Зовнішні постачальники ПЗ повинні керуватися визначеними стандартами.
Збір, підтримка і зберігання записів
Цей розділ повинен визначати, яку документацію SQA слід зберігати, а також встановити методику та засоби для збору, об'єднання, забезпечення безпеки і підтримки цієї документації.
Навчання
В цьому розділі повинні бути перераховані всі базові навчальні курси на SQA - тематику, що проводяться для членів проекту.
Управління ризиками
Цей розділ повинен визначати методики, які використовуються для визначення, доступу та управління ризиків, що виникають на протязі розробки програмного забезпечення.
Словник термінів і акронімів.
Цей розділ повинен містити словник термінів, які використовувалися в SQAP.
Процедури зміни SQAP
Цей розділ повинен містити процедури модифікації SQAP та підтримки історії змін. Він повинен також містити методи контролю за змінами.
Приклад реалізації
Архітектурна / проектна документація
Проаналізуємо, на яких основах проектувалася база даних системи.
Програма повинна працювати автономно, не маючи доступу до бази товарів, які знаходяться на віддаленому сервері. В такому випадку база товарів повинна створюватися на тому самому комп’ютері, що і програма. Виходячи з цього можна обійтися без використання баз даних типу SQL або Oracle, які дозволяють мережеве використання бази даних. У нашому випадку рахунки зберігаються в файлах виду “{0:X2}_N*_????????.bill”, які в програмному коді перетворюються на об’єкти типу DataTable. DataTable є реляційна, схожа на базу даних таблиця в пам'яті.
Часова діаграма
виконання проекту
Рис. 1. Часова діаграма виконання проекту.
Технічна документація
Технічну документацію було згенеровано програмою NDoc, яка використала xml-файл, згенерований автоматично Visual Studio при компіляції проекту. У вихідному хелп-файлі можна знайти список усіх класів,їх властивостей та методів, які були використані у проекті.
Користувацька документація
Інструкція Користувача Версія 1
Зміст
І. Інсталяція
ІІ. Вікно реєстрації
ІІІ. Вікно Сервісного Обслуговування
ІV. Вікно Касира