10-software_engineering_quality (Основы программной инженерии (по SWEBOOK)), страница 6

3.3.2) или “индивидуальному” анализу (см. 3.3.3), вне зависимости отстепени использования средств автоматизации.3.3.2 Техники коллективной оценки (People-intensive techniques)Действительно, SWEBOK использует термин “people-intensive”, точный перевод содержаниякоторого, по мнению автора перевода, достаточно пространен: “Техники, требующие интенсивногоиспользования человеческих ресурсов”. По-сути, их можно было бы назвать и техниками “очныхоценок”, так как их идея заключается именно в форме прямого - “очного” взаимодействияспециалистов. Однако, такое краткое название не подчеркивало бы фактора вовлеченностимножества специалистов, который имеет важное значение для принятия решения о выборе иприменении таких техник в полном объеме. Именно поэтому, данные техники в переводе названы“техниками коллективной оценки”. Все же посмотрим, как именно SWEBOK описывает данныетехники.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru14Основы программной инженерии (по SWEBOK)Программная инженерия.

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

Данные техники рассматриваются, например, встандарте 12207 при обсуждении оценки (<joint> review) и аудита (audit). SWEBOK приводит идругие полезные источники, в которых можно найти дополнительную информацию пообсуждаемому вопросу.3.3.3 Аналитические техники (Analytical techniques)Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитическиетехники.Если в данном случае создатели SWEBOK предполагали смысловую нагрузку “generally” вотношении применения аналитических техник именно подразумевая “как правило”, а не“достаточно широко”, то, по мнению автора перевода, такого рода суждение является крайнеконсервативным и ограниченным. Особенно это заметно в контексте широкого (и достаточноуспешного) применения Agile-методик и подходов, в которых individuals and interactions (см.первоеположение The Agile Manifesto) предполагает <непосредственное> общение и постоянноевзаимодействие членов команды (включая представителей заказчика – см.

третье положение AgileManifesto - customer collaboration). В частности, Agile-взгляд на SQM, вероятно, требуетрасширения вариантов форм оценки дополнительными категориями.Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частейпродукта. Некоторые техники базируются на специфике применяемых инструментальных средств,другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, ночаще всего они используются для поддержки других техник (например, статической). Ряд техниктакже включает различного рода экспертизу (assessment) как составной элемент общего анализакачества.

Примеры таких техник - анализ сложности (complexity analysis), анализ управляющейлогики (или анализ контроля потоков управления - control flow analysis) и алгоритмический анализ(algorithmic analysis).Каждый тип анализа обладает конкретным назначением и не все типы применимы к любомупроекту. Примером техники поддержки является анализ сложности, который полезен дляопределения фрагментов дизайна системы, обладающих слишком высокой сложностью длякорректной реализации, тестирования или сопровождения. Результат анализа сложности можеттакже применяться для разработки тестовых сценариев (test cases).

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

SWEBOK указывает ряд источников,касающийся детального обсуждения выбора и самого списка аналитических техник.Другие, более формальные типы аналитических техник известны как формальные методы. Ониприменяются для проверки требований и дизайна (надо признать, лишь иногда, в реальнойсегодняшней практике промышленной разработки программного обеспечения; см. обсуждениеформальных методов в области знаний SWEBOK “Инструменты и методы программнойинженерии”). Проверка корректности применяется к критическим фрагментам программногообеспечения (что, вообще говоря, мало связано с формальными методами – это естественныйпуть достижения приемлемого качества при минимизации затрат). Чаще всего они используютсядля верификации особо важных частей критически-важных систем, например, конкректныхтребований <информационной> безопасности и надежности.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru15Основы программной инженерии (по 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/IEC14102 “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 StandardIDO/IEC12119:1994(E), Information Technology – Software Packages - Quality Requirementsand Testing)Иногда, независимые V&V-организации могут требовать возможности мониторинга процессатестирования и, в определенных случаях, заверять (или, чаще, документировать/фиксировать)реальное выполнение <тестов> на предмет их проведения в соответствии с заданнымипроцедурами.

С другой стороны, может быть сделано обращение к V&V может быть направленона оценку и самого тестирования: достаточности планов и процедур, соответствия и точностирезультатов.Другой тип тестирования, которое проводится под началом V&V-организации – тестированиетретьей стороной (third-party testing). Такая третья сторона сама не является разработчикомпродукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторонаCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru16Основы программной инженерии (по SWEBOK)Программная инженерия.

Качество программного обеспечения.является независимым источником оценки, обычно аккредитованным на предмет обладаниясоответствующими полномочиями (например, организацией-разработчиком того или иногостандарта, соответствие которому оценивается независимым экспертом и чьи действияподтверждены создателем стандарта). Назначение такого рода тестирования состоит в проверкепродукта на соответствие определенному набору требований (например, по информационнойбезопасности).3.4 Количественная оценка качества программного обеспечения (Software Quality Measurement)Модели качества программных продуктов часто включают метрики для определения уровнякаждой характеристики качества, присущей продукту.Если характеристики качества выбраны правильно, такие измерения могут поддержать качество(уровень качества) многими способами.

Метрики могут помочь в управлении процессом принятиярешений. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах.Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях,определенных SQA, так и с точки зрения более долгосрочного процесса совершенствования<достигаемого> качества.С увеличением внутренней сложности, изощренности программного обеспечения, вопросыкачества выходят далеко за рамки констатации факта – работает или на работает программноеобеспечение. Вопрос ставится – насколько хорошо достигаются количественно оцениваемые целикачества.Существует еще несколько тем, предметом обсуждения которых являются метрики, напрямуюподдерживающие SQM. Они включают содействие в принятии решения о моменте прекращениятестирования.