Планирование качества программного обеспечения включает:
(1) Определение требуемого продукта в терминах характеристик качества (см., например, область знаний “Управление программной инженерией”).
(2) Планирование процессов для получения требуемого продукта (см., например, области знаний “Проектирование” и “Конструирование”).
Эти процессы отличаются от процессов SQM, как таковых, которые, в свою очередь, направлены на оценку планируемых характеристик качества, а не на реальную реализацию этих планов. Процессы управления качеством должны адресоваться вопросам, насколько хорошо продукт будет удовлетворять потребностям заказчика и требованиям заинтересованных лиц, обладать ценностью для заказчика и заинтересованных лиц и качеством, необходимым для соответствия сформулированным требованиям к программному обеспечению.
SQM может использоваться для оценки и конечных и промежуточных продуктов.
Некоторые из специализированных процессов SQM определены в стандарте 12207:
• Процесс обеспечения качества (quality assurance process)
• Процесс верификации (verification process)
• Процесс аттестации (validation process)
• Процесс совместного анализа (joint review process)
• Процесс аудита (audit process)
Все эти процессы поддерживают стремление к достижению качества и, кроме того, помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем концентрируют внимание.
Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в данном проекте. Они предоставляют менеджерам основную информацию по каждому продукту и, кроме того, включают параметры качества всего процесса программной инженерии. Области знаний SWEBOK “Процесс программной инженерии” и “Управление программной инженерией” обсуждают программы качества для организаций, занимающихся разработкой программного обеспечения. SQM может предоставить соответствующую обратную связь для этих областей.
Процессы SQM состоят из задач и техник, предназначенных для оценки того, как начинают реализовываться планы по созданию программного обеспечения и насколько хорошо промежуточные и конечные продукты соответствуют заданным требованиям. Результаты выполнения этих задач представляются в виде отчетов для менеджеров перед тем, как будут предприняты соответствующие корректирующие действия. Управление SQM-процессом ведется исходя из уверенности, что данные отчетов точны.
Как описано в данной области знаний, процессы SQM тесно связаны между собой. Они могут перекрываться, а иногда даже и совмещаться. Они кажутся реактивными по своей природе, в силу того, что они рассматривают процессы в контексте полученной практики и уже произведенные продукты. Однако, они играют главную роль на стадии планирования, являясь проактивными как процессы и процедуры, необходимые для достижения характеристик и уровня качества, востребованных заинтересованными лицами <проекта> программного обеспечения.
Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале - disciplined) анализа рисков и <соответствующих> техник управления <рисками> в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”.
2.1 Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)
Процессы SQA обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла проекта соответствуют заданным требованиям. Такое подтверждение проводится на основе планирования (planning), постановки <работ> (enacting) и исполнения (performing) набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения (см. выше определения качества). Такой взгляд подразумевает ясное и точное формулирование проблемы, а также то, что определены и четко выражены (полны и однозначно интерпретируемы) требования к соответствующему <программному> решению. SQA добивается обеспечения качества в процессе разработки и сопровождения за счет выполнения различных действий на всех этапах <жизненного цикла>, что позволяет идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны в любой сложной деятельности.
Такая идентификация возможна во многих случаях (если даже не в большинстве ситуаций), когда проблема еще является риском и возможно ее предотвращение. Это - задача управления рисками, которое вполне можно было бы вынести в качестве самостоятельной области знаний
SWEBOK, в силу уже достаточно большого совокупного опыта не только индустрии ИТ или дисциплины управления проектами. Так или иначе, можно сказать, что уже было подчеркнуто при обсуждении SQM, управление рисками (Risk Management) является серьезным дополнительным инструментом для обеспечения качества программного обеспечения. Однако, ограничиваться упоминанием управления рисками только в контексте SQM было бы неправильно, так как сегодняшнее понимание Risk Management включает в себя не только вопросы предупреждения рисков, но и управление процессом разрешения проблем.
SQA, как это сформулировано SWEBOK, концентрируется на процессах. Роль SQA состоит в том, чтобы обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов с передачей результатов измерений заинтересованным сторонам (организационными структурам и лицам).
SQA-план определяет средства, которые будут использоваться для обеспечения соответствия разрабатываемого продукта заданным пользовательским требованиям с максимальным уровнем качества, возможным при заданных ограничениях проекта (т.е., в предлагаемой в данном переводе терминологии - приемлемым уровнем качества). Для того, чтобы этого добиться, в первую очередь необходимо, чтобы цели качества были четко определены и понимаемы (а также, однозначно интерпретируемы, что является обязательным условием любых целей и соответствующих требований). Это, в обязательном порядке, должно быть отражено в соответствующих планах управления <проектом>, разработки и сопровождения. Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software Quality Assurance Plans”.
Конкретные работы и задачи по обеспечению качества структурируются с детализацией требований по их стоимости и ассоциированным ресурсам, целям с точки зрения управления и соответствующим расписанием в контексте целей, заданных планами управления, разработки и сопровождения. SQA-план должен согласовываться с планом конфигурационного управления (см. область знаний “Software Configuration Management”). План SQA идентифицирует документы, стандарты, практики и соглашения, применяемые при контроле проекта, а также то, как эти аспекты будут проверяться и отслеживаться для обеспечения достаточности и соответствия заданному плану. Также, SQA-план идентифицирует метрики, статистические техники, процедуры формирования сообщений о проблемах и проведения корректирующих действий, такие средства (в оригинале SWEBOK используется термин resources), как инструменты, техники и методологии, вопросы безопасности физических носителей (это, скорее, вопрос базовой инфраструктуры проектов, а не SQA-плана), тренинги, а также формирование отчетности и документации, относящиеся к вопросам SQA. Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам деятельности, описанным в <различных> планах по созданию программного обеспечения, к которым также относятся поставка, установка, обслуживание (поддержка и сопровождение) заказных и/или тиражируемых/готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта программного обеспечения. Наконец, SQA-план может содержать необходимые для обеспечения качества критерии приемки программного обеспечения и действия по формированию отчетности и управлению <и контролю над> работами.
2.2 Проверка (верификация) и аттестация (Verification and Validation, V&V)
С целью краткости <изложения> (что, не мешало их детализировать достаточным образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как, будучи тесно связанными и взаимодополняющими, проверка и аттестация все же обладают и самостоятельным содержанием), проверка (верификация) и аттестация - Validation and Verification (V&V) - рассмотрены в SWEBOK в рамках единой темы. В свою очередь, они являются самостоятельными темами, например, в стандарте жизненного цикла программного обеспечения 12207. Стандарт IEEE 1059-93 “IEEE Guide for Software Verification and Validation Plans” дает такое определение V&V*: “Проверка и аттестация программного обеспечения - упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований” (здесь и далее, как и при обсуждении SQA, пользовательские требования, скорее, не user requirements в понимании управления требованиями, а потребности пользователей, ради удовлетворения которых создается программное обеспечение).
* здесь и далее в переводе намеренно используется обозначение V&V, как общепринятое в индустрии программного обеспечения
V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих> процессов жизненного цикла.
Процесс V&V определяет в какой степени продукт (результат) тех или иных работ по разработке и сопровождению соответствует требованиям, сформулированным в рамках этих работ, а конечный продукт удовлетворяет заданным целям и пользовательским требованиям (корректнее было бы говорить не только и, может быть, не столько о “требованиях”, то есть потребностях, сколько об ожиданиях). Верификация - попытка обеспечить правильную разработку продукта (продукт построен правильным образом; обычно, для промежуточных, иногда, для конечного продукта), в том значении, что получаемый в рамках соответствующей деятельности продукт соответствует спецификациям, заданным в процессе предыдущей деятельности. Аттестация - попытка обеспечить создание правильного продукта (построен правильный продукт; обычно, в контексте конечного продукта), с точки зрения достижения поставленной цели. Оба процесса - верификация и аттестация - начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций.
Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план V&V документирует и <детально> описывает различные ресурсы, роли и действия, а также используемые техники и инструменты. Понимание различных целей каждого действия в рамках V&V может помочь в точном планировании техник и ресурсов (включая, финансовые), необходимых для достижения заданных целей. Стандарты IEEE 1012-98 “Software Verification and Validation” и 1059-93 “IEEE Guide for Software Verification and Validation Plans” (Appendix A) определяют типичное содержание плана проверки и аттестации.
План также касается аспектов управления, коммуникаций (взаимодействия), политик и процедур в отношении действий по верификации и аттестации и их взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования отчетности по дефектам и документирования требований (конечно, с точки зрения выполнения задач по проверке и аттестации продуктов).
2.3 Оценка (обзор) и аудит (Review and Audits)
В целях краткости изложения, оценка (review) и аудит объединены в SWEBOK в одну тему (в данном случае, такое объединение выглядит более обоснованным, чем в случае V&V, где частью процесса аттестации могут быть, например, приемо-сдаточные испытания, наверняка отсутствующие при верификации; оценка же и аудит, на практике, часто отличаются лишь степенью детализации, акцентам в отношении исследуемых аспектов, лицом/органом, выполняющим соответствующие работы, а также степенью формализации процесса). В стандарте жизненного цикла 12207 эти работы разделены на самостоятельные темы. Более детально они описаны в стандарте IEEE 1028-97 “IEEE Standard for Software Reviews”, в котором представлено пять типов оценок и аудитов (обратите внимание, что классификация рассматривает аудит лишь как один из типов оценки):
• Управленческие оценки (management reviews)
• Технические оценки (technical reviews)
• Инспекции (inspections)
• “Прогонки” (walk-throughs)
• Аудиты (audtis)
2.3.1 Управленческие оценки (Management Reviews)
“Назначение управленческих оценок состоит в отслеживании развития <проекта/продукта>, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов - управления рисками, проекта/проектного управления, конфигурационного управления, безопасности <использования> программного обеспечения (safety), оценки рисков и т.п. Информация, связанная с данными вопросами, также представлена в областях знаний “Управление программной инженерией” и “Конфигурационное управление”.
2.3.2 Технические оценки (Technical Reviews)
“Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами.” - IEEE 1028-97 “IEEE Standard for Software Reviews”.
Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в обязательном порядке, наличия следующих входных данных:
• Формулировки целей
• Конкретного программного продукта (подвергаемого оценке)
• Заданного плана проекта (плана управления проектом)
• Списка проблем (вопросов), ассоциированных с продуктом
• Процедуры технической оценки
Команда ^технической оценки> следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта (представляя команду разработки). Исследование <продукта> проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто провидит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта.
2.3.3 Инспекции (Inspections)
“Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Существует два серьезных отличия инспекций от оценок (управленческой и технической):
1.Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях.
2.Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования.
Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы - группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества). Каждый член команды должен исследовать программный
продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники (описанные ниже в подтеме 3.3.3) в небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией <инспекции> и проверяет, что все <члены команды> подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами <программного продукта>, вызывающими интерес. Результирующий лист часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for the Classification of Software Anomalies”) и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:
1. Принятие <продукта> с отсутствием либо малой необходимостью переработки
2. Принятие <продукта> с проверкой переработанных фрагментов
3. Необходимость повторной инспекции
Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита, предполагающих, в большинстве случаев, больший объем работ и, соответственно, длящиеся дольше.
2.3.4 Прогонки (Walk-throughs)
“Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью ознакомления (обучения) аудитории с программным продуктом.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Главные цели прогонки состоят (по IEEE 1028) в:
• Поиске аномалий
• Улучшении продукта
• Обсуждении альтернативных путей реализации
• Оценке соответствия стандартам и спецификациям
Прогонка похожа на инспекцию, однако, обычно проводится менее формальным образом. В основном, прогонка организуется инженерами для других членов команды с целью получения отклика от них на свою работу, как одного из элементов (техник) обеспечения качества.
2.3.5 Аудиты (Audits)
“Назначением аудита программного обеспечения является независимая оценка программных продуктов и процессов на предмет их соответствия применимым регулирующим документам, стандартам, руководящим указаниям, планам и процедурам.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде <разработки> для принятия корректирующих действий.
При том, что существуют различные формальные названия (и классификации) оценок и аудита (например, как мы видели в стандарте IEEE 1028-97), важно отметить, что такого рода действия могут проводиться почти для любого продукта на любой стадии процесса разработки или сопровождения.
3.1 Требования к качеству программного обеспечения (Software Quality Requirements)
3.1.1 Факторы влияния (Influence factors)
На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:
• Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности <людей>), критичное для бизнеса и т.п.)
• Системные и программные требования
• Какие компоненты используются в системе - коммерческие (внешние) или стандартные (внутренние)
• Какие стандарты программной инженерии применимы в заданном контексте
• Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов)
• Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов
• Кто целевые пользователи и каково назначение системы
• Уровень целостности системы
Информация об этих факторах влияет на то, как именно будут организованы и документированы процессы SQM, какие SQM-работы будут отобраны (стандартизированы в рамках проекта, команды, организационной единицы, организации), какие необходимы ресурсы и каковы ограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.
3.1.2 Гарантоспособность (Dependability)
(Гарантоспособость - гарантия <высокой> надежности, защищенности от сбоев)
В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности <системы>. Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety - безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п. ), информационная безопасность или защищенность (security - защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности (см. стандарт ISO/IEC 9126-1:2001 “Software Engineering - Product Quality, Part 1: Quality Model”).
В обсуждении данного вопроса существенную роль играет обширная литература по системам повышенной надежности. При этом, применяется терминология, пришедшая из области традиционных механических и электрических систем (в т.ч. не включающих программное обеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п. SWEBOK приводит ряд источников, где подробно обсуждаются эти вопросы.
3.1.3 Уровни целостности программного обеспечения (Integrity levels of software)
Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и <всесторонней> оценки качества программного обеспечения. Уровни целостности (например, градации целостности) предлагаются, в частности, стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”.
При более детальном рассмотрении целостности программного обеспечения в контексте конкретных проектов, необходимо уделять специальное внимание (выделяя соответствующие ресурсы и проводя необходимые работы) не только SQM-процессам (особенно, формальным, включая аудит и аттестацию), но и аспектам управления требованиями (в части критериев целостности), управления рисками (включая планирование рисков как на этапе разработки, так и на этапе эксплуатации и сопровождения системы), проектирования (которое, для повышения гарантоспособности, в обязательном порядке предполагает глубокий анализ и проверку планируемых к применению архитектурных и технологических решений, часто, посредством создания пилотных проектов, демонстрационных стендов и т.п.) и тестирования (для обеспечения всестороннего исследования поведенческих характеристик системы, в том числе с эмуляцией рабочего окружения/конфигурации, в которых система должна использоваться в процессе эксплуатации).
SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов играет основную роль в понимании продукта, облегчает корректировку процесса или продукта, а также информирует менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта. Существуют множество таксономий (классификации и методов структурирования) дефектов (сбоев). На сегодняшний день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые источники, освещающие его более подробно, упоминая, в частности, стандарт IEEE 1044-93 “IEEE Standard for the Classification of Software Anomalies”. Характеристика дефектов (аномалий) также используется в аудите и оценках, когда лидер оценки часто представляет для обсуждения на соответствующих встречах список аномалий, сформированный членами оценочной команды.
На фоне эволюции (и появления новых) методов проектирования и языков, наравне с новыми программными технологиями, появляются и новые классы дефектов. Это требует огромных усилий по интерпретации (и корректировке) ранее определенных классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не только их количеством, но и типом. Данный аспект (а именно, распределение дефектов по типам) особенно важен для определения наиболее слабых элементов системы, с точки зрения используемых технологий и архитектурных решений, что приводит к необходимости их углубленного изучения, создания специализированных пилотных проектов, дополнительной проверки концепции (proof of concept, POC - часто применяемый подход при использовании новых технологий), привлечения сторонних экспертов и т.п. SWEBOK отмечает, что сама по себе информация, без классификации, часто бывает просто бесполезна для обнаружения причин сбоев, так как для определения путей решения проблем необходима их группировка по соответствующим типам. Вопрос состоит в определении такой таксономии дефектов, которая будет значима для инженеров и организации, в целом.
SQM обеспечивает сбор информации на всех стадиях разработки и сопровождения программного обеспечения. Обычно, когда мы говорим “дефект”, мы подразумеваем “сбой”, в соответствии с определением, представленным ниже. Однако, различные культуры и стандарты могут предполагать различное смысловое наполнение этих терминов. Частичные определения понятий такого рода (из стандарта IEEE 610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) выглядят следующим образом:
• Ошибка (error): “Отличие ... между корректным результатом и вычисленным результатом < полученным с использованием программного обеспечения>”
• Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”
• Сбой (failure): “<Некорректный> результат, полученный в результате недостатка”
• Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”
Данные понятия достаточно детально рассматриваются в области знаний SWEBOK “Тестирование программного обеспечения”.
При обсуждении данной темы, под дефектом (defect) понимается результат сбоя программного обеспечения. Модели надежности строятся на основании данных о сбоях, собранных в процессе тестирования программного обеспечения или его использования. Такие модели могут быть
использованы для предсказания будущих сбоев и помогают в принятии решения о прекращении тестирования.
По результатам SQM-работ, направленных на обнаружение дефектов, выполняются действия по удалению дефектов из исследуемого продукта. Однако, этим дело не ограничивается. Есть и другие возможные действия, позволяющие получить полную отдачу от результатов выполнения соответствующих SQM-работ. Среди них - анализ и подведение итогов (резюмирование) <по обнаруженным несоответствиям/дефектам>, использование техник количественной оценки (получение метрик) для улучшения продукта и процесса, отслеживание дефектов и удаления их из системы (с управленческим и техническим контролем проведения необходимых корректирующих действий). Улучшение процесса рассматривается более детально в области знаний SWEBOK “Процесс программной инженерии”. В свою очередь источником информации для улучшения процесса, в частности, является SQM-процесс.
