Техники управления качеством программного обеспечения (Software Quality Management Techniques)

Техники SQM могут быть распределены по нескольким категориям:

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

3.3.1 Статические техники (Static techniques)

Статические техники предполагают <детальное> исследование (examination) проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения. Эти техники могут включать другие, рассматриваемые ниже, действия по “коллективной” оценке (см. 3.3.2) или “индивидуальному” анализу (см. 3.3.3), вне зависимости от степени использования средств автоматизации.

3.3.2 Техники коллективной оценки (People-intensive techniques)

Действительно, SWEBOK использует термин “people-intensive”, точный перевод содержания которого, по мнению автора перевода, достаточно пространен: “Техники, требующие интенсивного использования человеческих ресурсов”. По-сути, их можно было бы назвать и техниками “очных оценок”, так как их идея заключается именно в форме прямого - “очного” взаимодействия специалистов. Однако, такое краткое название не подчеркивало бы фактора вовлеченности множества специалистов, который имеет важное значение для принятия решения о выборе и применении таких техник в полном объеме. Именно поэтому, данные техники в переводе названы “техниками коллективной оценки”. Все же посмотрим, как именно SWEBOK описывает данные техники.

Форма такого рода техник, включая оценку и аудит, может варьироваться от формальных собраний до неформальных встреч или обсуждения продукта даже без обращения к его коду. Обычно, такого рода техники предполагают очного взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При этом, такие встречи могут требовать предварительной подготовки (практически всегда касающейся определения содержания встреч, то есть перечня выносимых на обсуждение вопросов). К ресурсам, используемым в таких техниках, наравне с исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут относится различного рода листы проверки (checklists) и результаты аналитических техник (рассматриваются ниже) и работ по тестированию. Данные техники рассматриваются, например, в стандарте 12207 при обсуждении оценки (<joint> review) и аудита (audit). SWEBOK приводит и другие полезные источники, в которых можно найти дополнительную информацию по обсуждаемому вопросу.

3.3.3 Аналитические техники (Analytical techniques)

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

Если в данном случае создатели SWEBOK предполагали смысловую нагрузку “generally” в отношении применения аналитических техник именно подразумевая “как правило”, а не “достаточно широко”, то, по мнению автора перевода, такого рода суждение является крайне консервативным и ограниченным. Особенно это заметно в контексте широкого (и достаточно успешного) применения Agile-методик и подходов, в которых individuals and interactions (см.первое положение The Agile Manifesto) предполагает <непосредственное> общение и постоянное взаимодействие членов команды (включая представителей заказчика – см. третье положение Agile Manifesto - customer collaboration). В частности, Agile-взгляд на SQM, вероятно, требует расширения вариантов форм оценки дополнительными категориями.

Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, но чаще всего они используются для поддержки других техник (например, статической). Ряд техник также включает различного рода экспертизу (assessment) как составной элемент общего анализа качества. Примеры таких техник - анализ сложности (complexity analysis), анализ управляющей логики (или анализ контроля потоков управления - control flow analysis) и алгоритмический анализ (algorithmic analysis).

Каждый тип анализа обладает конкретным назначением и не все типы применимы к любому проекту. Примером техники поддержки является анализ сложности, который полезен для определения фрагментов дизайна системы, обладающих слишком высокой сложностью для корректной реализации, тестирования или сопровождения. Результат анализа сложности может также применяться для разработки тестовых сценариев (test cases). Такие техники поиска дефектов, как анализ управляющей логики, может также использоваться и в других случаях. Для программного обеспечения с обширной алгоритмической логикой крайне важно применять алгоритмические техники, особенно в тех случаях, когда некорректный алгоритм (не его реализация, а именно логика) может привести к катастрофическим результатам (например, программное обеспечение авионики, для которой вопросы безопасности использования – safety играют решающую роль). Существует обширный спектр аналитических техник, поэтому приведение их списка здесь выглядит нецелесообразным. SWEBOK указывает ряд источников, касающийся детального обсуждения выбора и самого списка аналитических техник.

Другие, более формальные типы аналитических техник известны как формальные методы. Они применяются для проверки требований и дизайна (надо признать, лишь иногда, в реальной сегодняшней практике промышленной разработки программного обеспечения; см. обсуждение формальных методов в области знаний SWEBOK “Инструменты и методы программной инженерии”). Проверка корректности применяется к критическим фрагментам программного обеспечения (что, вообще говоря, мало связано с формальными методами – это естественный путь достижения приемлемого качества при минимизации затрат). Чаще всего они используются для верификации особо важных частей критически-важных систем, например, конкректных требований <информационной> безопасности и надежности.

3.3.4 Динамические техники (Dynamic techniques)

В процессе разработки и сопровождения программного обеспечения приходится обращаться к различным видам динамических техник. В основном, это техники тестирования. Однако, в качестве динамических техник могут рассматриваться техники симуляции, проверки моделей и “символического” исполнения (symbolic execution, часто предполагает использование модулей-“пустышек” с точки зрения выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего сценария поведения многомодульных систем; иногда под этим термином понимаются и другие техники, в зависимости, от выбранного первоисточника). Просмотр (чтение) кода обычно рассматривается как статическая техника, но опытный инженер может исполнять код непосредственно “в процессе” его чтения (например, используя диалоговые средства пошаговой отладки для ознакомления или оценки чужого кода). Таким образом, данная техника вполне может обсуждаться и как динамическая. Такие расхождения в классификации техник ясно показывают, что в зависимости от роли человека в организации, он может принимать и применять одни и те же техники по-разному.

В зависимости от организации <ведения> проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах. В силу того, что план SQM адресуется вопросам тестирования, данная тема включает некоторые комментарии по тестированию. В свою очередь, область знаний SWEBOK “Тестирование” детально обсуждает и дает ссылки (за исключением стандартов, представленных в переводе, полный список ссылок присутствует только в оригинальном издании SWEBOK на английском языке, как и для других областей знаний) по теории, техникам и вопросам автоматизации работ по тестированию.

3.3.5 Тестирование (Testing)

Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и оценивают любой выходной продукт (включая промежуточный и конечный), связанный со спецификацией требований к программному обеспечению, на предмет трассируемости (traceability), согласованности (consistency), полноты/завершенности (completeness), корректности (correctness) и непосредственно выполнения <требований> (performance). Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. SQA-деятельность обеспечивает гарантию того, что соответствующие (необходимые в заданном контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – разработку планов тестов, стратегий, сценариев и процедур <тестирования>.

Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них ложится ответственность за качество данных, используемых в проекте:

• Оценка и тестирование инструментов, используемых в проекте (IEEE 1462-98, ISO/IEC 14102 “Information Technology - Guideline for the Evaluation and Selection of CASE Tools.”)
• Тестирование на соответствие (или оценка тестов на соответствие) компонент и COTS-продуктов (COTS - commercial of-the-shelf, готовый к использованию продукт) для использования в создаваемом продукте; на это существует соответствующий стандарт (IEEE Std 1465-1998//ISO/IEC12119:1994, IEEE Standard Adoption of International Standard IDO/IEC12119:1994(E), Information Technology – Software Packages - Quality Requirements and Testing)

Иногда, независимые V&V-организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, документировать/фиксировать) реальное выполнение <тестов> на предмет их проведения в соответствии с заданными процедурами. С другой стороны, может быть сделано обращение к V&V может быть направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и точности результатов.

Другой тип тестирования, которое проводится под началом V&V-организации – тестирование третьей стороной (third-party testing). Такая третья сторона сама не является разработчиком продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона является независимым источником оценки, обычно аккредитованным на предмет обладания соответствующими полномочиями (например, организацией-разработчиком того или иного стандарта, соответствие которому оценивается независимым экспертом и чьи действия подтверждены создателем стандарта). Назначение такого рода тестирования состоит в проверке продукта на соответствие определенному набору требований (например, по информационной безопасности).

Дата добавления: 2014-10-22