Методы контроля качества

Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании?

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

• Верификация — проверка того, что продукт делался правильно, т.е. проверка того, что он разрабатывался в соответствии со всеми требованиями по отношению к процессу и этапам разработки.

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

Эффективность верификации и валидации, как и эффективность разработки ПО зависит от точности и корректности формулировки требований к программному продукту.

Выделяют следующие методы обеспечения качества ПО.

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

  • Функциональное (оно же черного ящика) — это тестирование проверяет соответствие системы требованиям, пользуясь при этом, как для создания тестов, так и для оценки степени соответствия только самими требованиями.

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

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

    • Нагрузочное тестирование. Это особый вид тестирования производительности, целью которого является определение характеристик производительности системы при большой нагрузке на нее (большом количестве пользователей, интенсивном обмене данными с другими системами, большим объемом передавемых/используемых данных, и пр.)

  • Тестирование на отказ (smoke testing) имеет целью обнаружение ситуаций, в которых система выходит из строя, хотя не должна делать этого.

  • Тестирование удобства использования проверяет насколько система удобна в использовании. Делается это на основе измерения времени, необходимого на обучение работе с системой, и производительности труда при работе с системой различных групп пользователей (уже знакомых с ней, незнакомых, опытных в данной предметной области, новичков и пр.).

  • Тестирование преносимости проверяет работоспособность системы в разных окружениях.

  • Тестирование на соответствие проверяет строгое соответствие требованиям любого рода, зафиксированным в достаточно строгом и полном виде (спецификациям, стандартам, корпоративной политике, и пр.).

  • Модульное, интеграционное и системное тестирование — различаются масштабом целей. Модульное тестирование предназначено для проверки правильности работы отдельных модулей, вне зависимости от окружения, интеграционное — для проверки того, что модули корректно работают вместе (используют друг друга, не нарушая взаимных ограничений на такое использование), системное — для проверки правильности работы системы в целом и ее способности решать заявленные задачи в различных ситуациях.

• Инспектирование, т.е. целенаправленное изучение кода и документов на предмет поиска ошибок определенного вида (по заранее определенному набору шаблонов), двусмысленностей, расхождений со стандартами оформления, нессоответствий между отдельными документами или частями одного документа

• Формальный анализ: формальное доказательство свойств ПО и формальный анализ эффективности алгоритмов

• Неформальный анализ: анализ статической семантики языков программирования, автоматизированный анализ кода на предмет обнаружения сомнительных мест, анализ свойств ПО и архитектуры человеком

• Измерения: определение метрик ПО, проекта, документации, измерения производительности, измерения трудоемкости работы с ПО, скорости обучения, профилирование (измерение времени работы отдельных элементов кода в рамках реалистичных сеансов работы, измерение затрат памяти на отдельные виды объектов, отдельными процедурами)

• Использование моделей различного рода — каждый вид моделей моделирует ПО, соответствуя ему в каких-то свойствах и пренебрегая другими, не значимыми для целей моделирования. Применяются

  • Модели использования (какие операции использует пользователь, насколько часто, как долго он работает с отдельными экранами и диалогами) для анализа удобства использования ПО

  • Модели использования и надежности для анализа надежности и производительности

  • Модели функционирования для анализа свойств и их проверки на моделях. Обычно к проверке свойств на моделях (model checking) прибегают для того, чтобы проверить работоспособность каких-то отдельных архитектурных или алгоритмических решений, которые планируется использоват при построении сложных систем, их способность соответствовать требованиям. В качестве проверяемых свойств часто выступают

    • Отсутствие взаимных блокировок процессов (deadlocks) — ситуаций, при которых несколько параллельных процессов ждут освобождения ресурсов друг другом и не могут продолжать работу из-за этого.

    • Завершаемость отдельных циклов — то, что выполнение цикла завершится после конечного числа шагов.

    • Завершаемость циклов обмена сообщениями между процессами — отсутствие livelocks, т.е. ситуаций, при которой параллельные процессы бесконечно обмениваются сообщениями и не способны выполнить какую-либо другую работу.

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

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

  • Прототипирование — построение прототипов системы для оценки достижимости тех или иных целей и получения отзывов от заинтересованных лиц

Использование различных методов обеспечения качества регламентируемтся следующими стандартами — их довольно много.

• IEEE 730-2002 Standard for Software Quality Assurance Plans. Описывает структуру планирования обеспечения качества.

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

• IEEE 982.1-1988 Standard Dictionary of Measures to Produce Reliable Software

• IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing

• IEEE 1012-1998 Standard for Software Verification and Validation

• IEEE 1028-1997 (R2002) Standard for Software Reviews

• IEEE 1044-1993 (R2002) Standard Classification for Anomalies

• IEEE 1061-1998 (R2004) Standard for Software Quality Metrics Methodology

• IEEE 1228-1994 (R2002) Standard for Software Safety Plans

• IEEE 1465-1998 [Adoption of ISO/IEC 12119: 1994(E)], Standard Adoption of International Standard ISO/IEC 12119: 1994(E) Information Technology — Software packages. Quality requirements and testing

• ISO/IEC 12119:1994 (AS/NZS 4366:1996) Software packages — Quality requirements and testing

• ISO 10005:1995 — Административное управление качеством. Руководящие указания по программам качества.

• ISO 10006:1997 — Руководство по качеству при управлении проектом.

• ISO 10007:1995 — Административное управление качеством. Руководящие указания при управлении конфигурацией.

• ISO 10013: 1995 — Руководящие указания по разработке руководств по качеству.

• ISO 10011-1-3:1990. Руководящие положения по проверке систем качества. Ч. 1. Проверка. Ч. 2. Квалификационные критерии для инспекторов-аудиторов систем качества. Ч. 3. Управление программами проверок.

• ISO 14598-1-6: 1998-2000. Оценивание программного продукта. Ч. 1. Общий обзор. Ч. 2. Планирование и управление. Ч. 3. Процессы для разработчиков. Ч. 4. Процессы для покупателей. Ч. 5. Процессы для оценщиков. Ч. 6. Документирование и оценивание модулей.

• ISO 9126-1-4. (проекты). ИТ. Качество программных средств: Ч. 1. Модель качества. Ч. 2. Внешние метрики. Ч. 3. Внутренние метрики. Ч. 4. Метрики качества в использовании.

• ISO 14756: 1999. ИТ. Измерение и оценивание производительности программных средств компьютерных вычислительных систем.

• ISO 12119: 1994. (ГОСТ Р-2000). ИТ. Требования к качеству и тестирование.

• ISO 15408-1-3: 1999. (ГОСТ Р-2002). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Ч. 1. Введение и общая модель. Ч. 2. Защита функциональных требований. Ч. 3. Защита требований к качеству.

• ISO 13335-1-5: 1996-1998. ИТ. ТО. Руководство по управлению безопасностью. Ч. 1. Концепция и модели обеспечения безопасности информационных технологий. Ч. 2. Планирование и управление безопасностью информационных технологий. Ч. 3. Техника управления безопасностью ИТ. Ч. 4. Селекция (выбор) средств обеспечения безопасности. Ч. 5. Безопасность внешних связей.

• ISO 10181: 1-7. ВОС. 1996-1998. Структура работ по безопасности в открытых системах. Ч. 1. Обзор. Ч. 2. Структура работ по аутентификации. Ч. 3. Структура работ по управлению доступом. Ч. 4. Структура работ по безотказности. Ч. 5. Структура работ по конфиденциальности. 4. 6. Структура работ по обеспечению целостности. Ч. 7. Структура работ по проведению аудита на безопасность.