2014-10-30
426
Программная инженерия. Качество программного обеспечения.
Copyright © Сергей Орлик, 2004-2005.
mailto:sorlik@borland.ru
https://sorlik.blogspot.com
17
направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и
точности результатов.
Другой тип тестирования, которое проводится под началом V&V-организации – тестирование
третьей стороной (third-party testing). Такая третья сторона сама не является разработчиком
продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона
является независимым источником оценки, обычно аккредитованным на предмет обладания
соответствующими полномочиями (например, организацией-разработчиком того или иного
стандарта, соответствие которому оценивается независимым экспертом и чьи действия
подтверждены создателем стандарта, прим. автора). Назначение такого рода тестирования
состоит в проверке продукта на соответствие определенному набору требований (например, по
информационной безопасности, прим. автора).
|
|
|
3.4 Количественная оценка качества программного обеспечения (Software Quality Measurement)
Модели качества программных продуктов часто включают метрики для определения уровня
каждой характеристики качества, присущей продукту.
Если характеристики качества выбраны правильно, такие измерения могут поддержать качество
(уровень качества) многими способами. Метрики могут помочь в управлении процессом принятия
решений. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах.
Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях,
определенных SQA, так и с точки зрения более долгосрочного процесса совершенствования
<достигаемого> качества.
С увеличением внутренней сложности, изощренности программного обеспечения, вопросы
качества выходят далеко за рамки констатации факта – работает или на работает программное
обеспечение. Вопрос ставится – насколько хорошо достигаются количественно оцениваемые цели
качества.
Существует еще несколько тем, предметом обсуждения которых являются метрики, напрямую
поддерживающие SQM. Они включают содействие в принятии решения о моменте прекращения
тестирования. В этом контексте представляются полезными модели надежности и сравнение с
образцами (эталонами, принятыми в качестве примеров определенного качества – benchmarks,
прим. автора).
Стоимость процесса SQM является одним из <проблемных> вопросов, который всегда всплывает
в процессе принятия решения о том, как будет организован проект (проектные работы, прим.
автора). Часто, используются общие (generic) модели стоимости, основанные на определении
|
|
|
того, когда именно дефект обнаружен и как много усилий необходимо затратить на его
исправление по сравнению с ситуацией, если бы дефект был найден на более ранних этапах
жизненного цикла. Проектные данные могут помочь в получении более четкой картины стоимости.
SWEBOK приводит источники, в которых эта тема обсуждается более подробно. Связанная
информация по этим вопросам может быть найдена в областях знаний “Процесс программной
инженерии” и “Управление программной инженерией”.
Наконец, сама по себе SQM-отчетность обладает полезной информацией не только о самих
процессах (подразумевая их текущее состояние, прим. автора), но и о том, как можно улучшить
все процессы жизненного цикла. Обсуждение этой темы, в частности, представлено в стандарте
IEEE 1012-98 “Software Verification and Validation”.
Хотя, как количественные оценки (в данном случае речь идет о результатах оценок, а не о
процессе измерений, прим. автора) характеристик качества могут полезны сами по себе
(например, число неудовлетворенных требований и пропорция таких требований), могут
<эффективно> применяться математические и графические техники, облегчающие интерпретацию
значений метрик. Такие техники вполне естественно классифицируются, например, следующим
образом:
• Основанные на статистических методах (например, анализ Pareto, нормальное
распределение и т.п.)
• Статистические тесты
