4.5 Джерело помилок.

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

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

Причиною появи помилок часто є: нерозуміння вимог замовника; неточна специфікація вимог в документах проекту та ін. Це призводить до того, що реалізуються деякі функції системи, які працюватимуть не так, як пропонує замовник. У зв'язку з цим проводиться спільне обговорення деяких деталей вимог для їх уточнення замовником і розробником.

Команда розробників системи може також змінити синтаксис і семантику опису системи. Проте деякі помилки можуть бути не виявлені (наприклад, неправильно задані індекси або значення змінних цих операторів).

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

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

Фірма IВМ розробила підхід до класифікації помилок, званий ортогональною класифікацією дефектів [23]. Підхід передбачає розбиття помилок по категоріях з відповідальністю розробників за них.

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

Таблиця 4.2 - Ортогональна класифікація дефектів IBM

Контекст помилки	Класифікація дефектів
Функція	Помилки інтерфейсів кінцевих користувачів ПП, викликані апаратурою або пов'язані з глобальними структурами даних
Інтерфейс	Помилки у взаємодії з іншими компонентами, у викликах, макросах, управляючих блоках, або в списку параметрів
Логіка	Помилки в програмній логіці, неохоплені валідаційою, а також у використанні значень змінних
Привласнення	Помилки в структурі даних або в ініціалізації змінних окремих частин програми
Зациклення	Помилки, викликані ресурсом часу, реальним часом або розподілом часу
Середовище	Помилки в репозиторії, в управлінні змінними або в контрольних версіях проекту
Алгоритм	Помилки, пов'язані із забезпеченням ефективності, коректності алгоритмів або структур даних системи
Документація	Помилки в записах документів супроводу або в публікаціях

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

Фірма Hewlett - Packard використовувала класифікацію Золи, встановивши процентне співвідношення помилок, що виявляються в ПП на різних стадіях розробки (рис. 4.4)

Рис. 4.4 - Процентне співвідношення помилок при розробці ПП