1. • Управління якістю

2. • Управління ресурсами

3. • Розвиток системи управління

4. • Дослідження ринку

5. • Проектування продуктів

6. • Придбання

7. • Виробництво

8. • Надання послуг

9. • Захист продуктів

10. • Оцінка потреб замовників

11. • Підтримка комунікацій із замовниками

12. • Підтримка внутрішніх комунікацій

13. • Управління документацією

14. • Ведення записів про діяльність

15. • Планування

16. • Навчання персоналу

17. • Внутрішні аудити

18. • Оцінки управління

19. • Моніторинг і вимірювання

20. • Управління невідповідностями

21. • Постійне вдосконалення

22. • Управління і розвиток системи в цілому

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

• Проектування процесу

• Документування процесу

• Реалізація процесу

• Підтримка процесу

• Моніторинг процесу

• Управління процесом

• Удосконалення процесу

25. Окрім підтримки і розвитку системи процесів, націлених на задоволення потреб замовників і користувачів, ISO 9001 вимагає

• Визначити, документувати і розвивати власну систему якості на основі вимірних показників.

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

• Забезпечити використання якісних ресурсів, якісного (компетентного, професійного) персоналу, якісної інфраструктури і якісного оточення.

• Постійно контролювати дотримання вимог до якості на практиці, у всіх процесах проектування, виробництва, надання послуг і при придбаннях.

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

26. Стандарти ISO 9002:1994, що раніше використалися, Quality systems — Model for quality assurance in production, installation and servicing і ISO 9003:1994 Quality systems — Model for quality assurance in final inspection and test в 2000 році були замінені відповідними їм частями ISO 9001.

27. • ISO 9004:2000 Quality management systems — Guidelines for performance improvements [7]. Системи управління якістю. Керівництво по поліпшенню діяльності. (Аналог ГОСТ Р-2001).

28. • ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software [8]. Керівні положення по застосуванню стандарту ISO 9001 при розробці, постачанні і обслуговуванні програмного забезпечення. Цей стандарт конкретизує положення ISO 9001 для розробки програмних систем, з упором на забезпечення якості при процесі проектування. Він також визначає деякий набір техніки і процедур, які рекомендується застосовувати для контролю і забезпечення якості програм, що розробляються.

30. Стандарт ISO 9126 [1-4] пропонує використовувати для опису внутрішню і зовнішню якості ПО багаторівневу модель. На верхньому рівні виділено 6 основних характеристик якості ПО. Кожна характеристика описується за допомогою декількох вхідних в неї атрибутів. Для кожного атрибуту визначається набір метрик, що дозволяють оцінити цей атрибут. Набір характеристик і атрибутів якості згідно ISO 9126 показаний на Рис.14. 2.

Рис. 14.14

Функціональність

Здатність ПО в певних умовах вирішувати завдання, потрібні користувачам. Визначає, що саме робить ПО, які завдання воно вирішує.

Функціональна придатність (suitability). Здатність вирішувати потрібний набір завдань.

Точність (accuracy). Здатність видавати потрібні результати.

Здібність до взаємодії (interoperability). Здатність взаємодіяти з потрібним набором інших систем.

Відповідність стандартам і правилам (compliance). Відповідність ПО наявних індустріальних стандартах, нормативних і законодавчих актах, інших регулюючих нормах.

Захищеність (security). Здатність запобігати неавторизований, тобто без вказівки особи, що намагається його здійснити, і не дозволений доступ до даним і програмам.

Надійність (reliability)

Здатність ПО підтримувати певну працездатність в заданих умовах.

Зрілість, завершеність (maturity). Величина, зворотна до частоти відмов ПО.

Стійкість до відмов (fault tolerance). Здатність підтримувати заданий рівень працездатності при відмовах і порушеннях правил взаємодії з оточенням.

Здатність до відновлення (recoverability). Здатність відновлювати певний рівень працездатності і цілісність даних після відмови, необхідні для цього час і ресурси.

Відповідність стандартам надійності (reliability compliance). Цей атрибут доданий в 2001 році.

Зручність використання (usability) або практичність. Здатність ПО бути зручним в навчанні і використанні, а також привабливим для користувачів.

Понятность (understandability). Показатель, обратный к усилиям, затрачиваемым пользователями, чтобы воспринять набор понятий, на которых основано ПО, и их применимость для решения своих задач.

Зручність навчання (learnability). Показник, зворотний до зусиль, що витрачаються користувачами щоб навчитися роботі з ПО.

Зручність роботи (operability). Показник, зворотний до зусиль, що робляться користувачами, щоб вирішувати свої завдання з допомогою ПО.

Привабливість (attractiveness). Здатність ПО бути привабливим для користувачів. Цей атрибут доданий в 2001.

Відповідність стандартам зручності використання (usability compliance). Цей атрибут доданий в 2001.

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

Тимчасова ефективність (time behaviour). Здатність ПО видавати очікувані результати, а також забезпечувати передачу необхідного об'єму даних за відведений час.

Ефективність використання ресурсів (resource utilisation). Здатність вирішувати потрібні завдання з використанням певних об'ємів ресурсів певних видів. Маються на увазі такі ресурси, як оперативна і довготривала пам'ять, мережеві з'єднання, пристрої введення і виводу, і ін.

Відповідність стандартам продуктивності (efficiency compliance). Цей атрибут доданий в 2001.

Зручність супроводу (maintainability)

1. Зручність проведення всіх видів діяльності, пов'язаних з супровід програм.

Аналізіруємость (analyzability) або зручність проведення аналізу. Зручність проведення аналізу помилок, дефектів і недоліків, а також зручність аналізу на предмет необхідних змін і їх можливих ефектів.

Зручність внесення змін (changeability). Показник, зворотний до трудовитрат на проведення необхідних змін.

Стабільність (stability). Показник, зворотний до ризику виникнення несподіваних ефектів при внесенні необхідних змін.

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

Відповідність стандартам зручності супроводу (maintainability compliance). Цей атрибут доданий в 2001.

Переносимість (portability). Здатність ПО зберігати працездатність при перенесенні з одного оточення в інше, включаючи організаційні, апаратні і програмні аспекти оточення. Іноді ця характеристика називається в російськомовній літературі мобільністю. Проте термін «мобільність» варто зарезервувати для перекладу «mobility» — здібності ПО і комп'ютерної системи в цілому зберігати працездатність при її фізичному переміщенні в просторі.

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

Удобство установки (installability). Способность ПО быть установленным или развернутым в определенном окружении.

Здібність до співіснування (coexistence). Здатність ПО співіснувати з іншими програмами в загальному оточенні, ділячи з ним ресурси.

Зручність заміни (replaceability) іншого ПО даним. Здатність ПО використовуватися замість іншого ПО для вирішення тих же самих завдань в заданому оточенні.

Відповідність стандартам переносимості (portability compliance). Цей атрибут доданий в 2001.

Для опису якості ПО при використанні стандарт ISO 9126-4 пропонує наступний набір характеристик.

1. • Ефективність (effectiveness). Це здатність ПО надавати користувачам можливість вирішувати їх завдання з необхідною точністю при використанні в заданому контексті.

2. • Продуктивність (productivity). Здатність ПО надавати користувачам певні результати в рамках очікуваних витрат ресурсів.

3. • Безпека (safety). Здатність ПО забезпечувати необхідно низький рівень риски нанесення збитку життя і здоров'ю людей, бізнесу, власності або навколишньому середовищу.

4. • Задоволеність (satisfaction). Здатність ПО приносити задоволення користувачам при використанні в заданому контексті.

Окрім перерахованих характеристик і атрибутів якості стандарт ISO 9126:2001 визначає набори метрик для оцінки кожного атрибуту. Приведемо наступні приклади таких метрик.

1. • Повнота реалізації функцій — відсоток реалізованих функцій по відношенню до перерахованих у вимогах. Використовується для вимірювання функціональної придатності.

2. • Коректність реалізації функцій — правильність їх реалізації по відношенню до вимог. Використовується для вимірювання функціональної придатності.

3. • Відношення числа виявлених дефектів до прогнозованого. Використовується для визначення зрілості.

4. • Відношення числа проведених тестів до загального їх числа. Використовується для визначення зрілості.

5. • Відношення числа доступних проектних документів до вказаного в їх списку. Використовується для вимірювання зручності проведення аналізу.

6. • Наочність і повнота документації. Використовується для оцінки зрозумілості.

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

1. • Що ПО повинно робити, наприклад: Дозволяти клієнтові оформити замовлення і забезпечити їх доставку; Забезпечувати контроль якості будівництва і відстежувати проблемні місця; Підтримувати потрібні характеристики автоматизованого процесу виробництва, запобігаючи аваріям і оптимальним чином використовуючи наявні ресурси.

2. • Наскільки воно повинне бути надійне, наприклад: Працювати 7 днів в тиждень і 24 години в добу; Допускається непрацездатність в течію не більше 3 годин в рік. Ніякі введені користувачами дані при відмові не повинні втрачатися.

3. • Наскільки їм повинно бути зручно користуватися, наприклад: Покупець повинен легко знаходити потрібний йому товар; Інженер за фахом «будівництво мостів» повинен протягом одного дня розібратися в 80% функцій системи.

4. • Наскільки воно повинне бути ефективне, наприклад: Підтримувати обслуговування до 10000 запитів в секунду; Час відгуку на запит при максимальному завантаженні не повинен перевищувати 3 з; Час реакції на зміну параметрів процесу виробництва не повинен перевищувати 0.1 з; На обробку одного запиту не повинно витрачатися більше 1 MB оперативної пам'яті.

5. • Наскільки зручно повинен бути його супровід, наприклад: Додавання в систему нового вигляду запитів не повинне вимагати більше 3 людино-дня; Додавання підтримки нового процесу виробництва не повинне займати більше 24 человеко-месяцев.

6. • Наскільки воно повинне бути переносимий і замінювано, наприклад: ПО повинно працювати на операційних системах Linux, Windows XP і MACOS X; ПО повинно працювати з документами у форматах MS Word 97 і HTML; ПО повинно зберігати файли звітів у форматах MS Word 2000, MS Excel 2000, HTML, RTF і у вигляді звичайного тексту. ПО повинно сполучатися з існуючою системою запису даних про замовлення.

Приведені атрибути якості закріплені в стандартах, але це не означає, що вони повністю вичерпують поняття якості ПО. Так, в стандарті ISO 9126 повністю відсутні характеристики, пов'язані з мобільністю ПО (mobility), тобто здатністю програми працювати при фізичних переміщеннях машини, на якій вона працює. Замість надійності багато дослідників вважають за краще розглядати більш загальне поняття добротності (dependability), що описує здатність ПО підтримувати певні показники якості по основних характеристиках (функціональності, продуктивності, зручності використання) із заданою вірогідністю виходу за їх рамки і заданими ризиками можливих порушень. Крім того, активно досліджуються поняття зручності використання, безпеці і захищеності ПО — вони здаються більшості фахівців набагато складнішими, ніж це описується даним стандартом.

Методи контролю якості

Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на этот вопрос можно получить с помощью процессов верификации и валидации.

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

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

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

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

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

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

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

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

4. Методы и техники, связанные с обычным или формализованным анализом проектной документации и исходного кода для выявления их свойств. К этой группе относятся многочисленные методы анализа архитектуры ПО, о которых пойдет речь в следующей лекции, методы формального доказательства свойств ПО и формального анализа эффективности применяемых алгоритмов.

Тестування

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

Тестування — кінцева процедура. Набір ситуацій, в яких перевірятиметься тестоване ПО завжди кінцевий. Більш того, він повинен бути настільки малий, щоб тестування можна було провести в рамках проекту розробки ПО, не дуже збільшуючи його бюджет і терміни. Це означає, що при тестуванні завжди перевіряється дуже невелика частка всіх можливих ситуацій. Із цього приводу Дейкстра (Dijkstra) сказав, що тестування дозволяє точно визначити, що помилка є в програмі, але ніколи не дозволяє стверджувати, що там немає помилок.

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

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

Рис. 14.15 – Схема процесу тестування

Тестування — найбільш широко вживаний метод контролю якості. Для оцінки багатьох атрибутів якості не існує інших ефективних способів, окрім тестування.

Організація тестування ПО регулюється наступними стандартами.

• IEEE 829-1998 Standard for Software Test Documentation. Описує види документів, що служать для підготовки тестів.

• IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing. Описує організацію модульного тестування.

• ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 і ГОСТ Р-2000, також прийнятий IEEE під номером IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing.

Тестувати можна дотримання будь-яких вимог, відповідність яким виявляється під час роботи ПО. З характеристик якості по ISO 9126 цією властивістю не володіють тільки атрибути зручності супроводу. Тому виділяють види тестування, пов'язані з перевіркою певних характеристик і атрибутів якості, — тестування функціональності, надійності, зручності використання, переносимості і продуктивності, а також тестування захищеності, функціональній придатності і ін. Крім того, особливо виділяють тестування навантаження або стресового, перевіряюче працездатність ПО і показники його продуктивності в умовах підвищених навантажень, — великій кількості користувачів, інтенсивному обміні даними з іншими системами, великим об'ємом передаваних або використовуваних даних, і ін.

На основі початкових даних, використовуваних для побудови тестів, тестування ділять на наступні види.

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

2. Структурне тестування, воно ж тестування білого ящика — тести створюються на основі знань про структуру самої системи і про те, як вона працює. Критерії повноти засновані на відсотку елементів коду, які відпрацювали в ході виконання тестів. Для оцінки ступеня відповідності вимогам можуть притягуватися додаткові знання про дослідження вимог в певні обмеження на значення внутрішніх даних системи (наприклад, на значення параметрів викликів, результатів і локальних змінних).

3. Тестирование, нацеленное на определенные ошибки. Тесты для такого тестирования строятся так, чтобы гарантированно выявлять определенные виды ошибок. Полнота тестирования определяется на основе количества проверенных ситуаций по отношению к общему числу ситуаций, которые мы пытались достичь. К этому виду относится, например, тестирование на отказ (smoke testing), в ходе которого просто пытаются вывести систему из строя, давая ей на вход как обычные данные, так и некорректные, с нарочно внесенными ошибками. Другим примером служит метод оценки полноты тестирования при помощи набора мутантов — программ, совпадающих с тестируемой всюду, кроме нескольких мест, где специально внесены некоторые ошибки. Чем больше мутантов тесты находят, тем полнее проводимое с их помощью тестирование.

Ще одна класифікація видів тестування заснована на тому рівні, на який воно націлене. Ці ж різновиди тестування можна пов'язати з фазою життєвого циклу, на якій вони виконуються.

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

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

3. Системне тестування (system testing) призначене для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами завдання в різних ситуаціях. Системне тестування тісно пов'язане з тестуванням призначеного для користувача інтерфейсу (або через призначений для користувача інтерфейс), що проводиться за допомогою імітації дій користувачів над елементами цього інтерфейсу. Окремими випадками цього виду тестування є тестування графічного призначеного для користувача інтерфейсу (Graphical User Interface, GUI) і призначеного для користувача інтерфейсу Інтернет-додатків (Web UI). Якщо інтеграційне і модульне тестування найчастіше проводять, впливаючи на компоненти системи за допомогою операцій що надається ними програмного інтерфейсу (Application Programming Interface, API), то на системному рівні без використання призначеного для користувача інтерфейсу не обійтися, хоча тестування через API в цьому випадку також часто можливо.

4. Проверка свойств на моделях (model checking) [10] — проверка соответствия ПО требованиям при помощи формализации проверяемых свойств, построения формальных моделей проверяемого ПО (чаще всего в виде автоматов различных видов) и автоматической проверки выполнения этих свойств на построенных моделях. Проверка свойств на моделях позволяет проверять достаточно сложные свойства автоматически, при минимальном участии человека. Однако она оставляет открытым вопрос о том, насколько выявленные свойства модели можно переносить на само ПО.

Рис. 14.16 – Схема процесу перевірки властивостей ПО на моделях

Зазвичай за допомогою перевірки властивостей на моделях аналізують два види властивостей використаних при побудові ПО алгоритмів. Властивості безпеки (safety properties) стверджують, що щось небажане ніколи не трапиться в ході роботи ПО. Властивості живучості (liveness properties) затверджують, навпаки, що щось бажане при будь-якому розвитку подій відбудеться в ході його роботи.

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

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

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

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

Основная проблема этого подхода — огромное количество состояний в моделях, достаточно хорошо отражающих поведение реальных программ. Для борьбы с комбинаторным взрывом состояний используются многочисленные методы оптимизации представления автомата и оптимизации выделения и поиска существенных для выполнения проверяемого свойства состояний.

Помилки в ПЗ

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

У англомовній літературі використовується декілька термінів, що часто однаково переводяться як «помилка» на російську мову.

• defect — найзагальніше порушення яких-небудь вимог або очікувань, що не обов'язково виявляється зовні (до дефектів відносяться і порушення стандартів кодування, недостатня гнучкість системи і ін.).

• failure — спостережуване порушення вимог, що виявляється при якомусь реальному сценарії роботи ПО. Це можна назвати проявом помилки.

• fault — помилка в коді програми, що викликає порушення вимог при роботі (failures), те місце, яке треба виправити. Хоча це поняття використовується досить часто, воно, взагалі кажучи, не цілком чітке, оскільки для усунення порушення можна виправити програму в декількох місцях. Що саме треба виправляти, залежить від додаткових умов, виконання яких ми хочемо при цьому забезпечити, хоча в деяких ситуаціях накладення додаткових обмежень не усуває неоднозначність.

• error — використовується в двох сенсах. Перший — це помилка в ментальній моделі програміста, помилка в його міркуваннях про програму, яка примушує його робити помилки в коді (faults). Це, власне, помилка, яку зробила людина в своєму розумінні властивостей програми. Другий сенс — це некоректні значення даних (вихідних або внутрішніх), які виникають при помилках в роботі програми.