Перевірка правильності проекту

Основні методи контролю правильності проектування наступні: верифікація - формальні методи доказу коректності проекту; моделювання; тестування.

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

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

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

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