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

В стандартежизненного цикла 12207 эти работы разделены на самостоятельные темы. Более детально ониописаны в стандарте IEEE 1028-97 “IEEE Standard for Software Reviews”, в котором представленопять типов оценок и аудитов (обратите внимание, что классификация рассматривает аудит лишькак один из типов оценки): Управленческие оценки (management reviews) Технические оценки (technical reviews) Инспекции (inspections) “Прогонки” (walk-throughs) Аудиты (audtis)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия.

Качество программного обеспечения.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) инспекторов.

Члены команды инспектированиямогут специализироваться в различных областями экспертизы (обладать различными областямикомпетенции), например, предметной области, методах проектирования, языке и т.п. В заданныймомент (промежуток) времени инспекции проводятся в отношении отдельного небольшогофрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных илидругих характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональныхтребований или атрибутов качества). Каждый член команды должен исследовать программныйCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия. Качество программного обеспечения.продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, теили иные аналитические техники (описанные ниже в подтеме 3.3.3) в небольшим фрагментампродукта или к продукту, в целом, рассматривая в последнем случае только один его аспект,например, интерфейсы.

Любая найденная аномалия должна документироваться, а информацияпередаваться лидеру инспекции. В процессе инспекции лидер руководит сессией <инспекции> ипроверяет, что все <члены команды> подготовились к инспектированию. Общим инструментом,используемым при инспектировании, является проверочный лист (checklist), содержащийаномалии и вопросы, связанные с аспектами <программного продукта>, вызывающими интерес.Результирующий лист часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standardfor the Classification of Software Anomalies”) и оценивается командой с точки зрения егозавершенности и точности. Решение о завершении инспекции принимается в соответствии содним (любым) из трех критериев:1.

Принятие <продукта> с отсутствием либо малой необходимостью переработки2. Принятие <продукта> с проверкой переработанных фрагментов3. Необходимость повторной инспекцииИнспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки иаудита, предполагающих, в большинстве случаев, больший объем работ и, соответственно,длящиеся дольше.2.3.4 Прогонки (Walk-throughs)“Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться сцелью ознакомления (обучения) аудитории с программным продуктом.” - IEEE 1028-97 “IEEEStandard for Software Reviews”.

Главные цели прогонки состоят (по IEEE 1028) в: Поиске аномалий Улучшении продукта Обсуждении альтернативных путей реализации Оценке соответствия стандартам и спецификациямПрогонка похожа на инспекцию, однако, обычно проводится менее формальным образом. Восновном, прогонка организуется инженерами для других членов команды с целью полученияотклика от них на свою работу, как одного из элементов (техник) обеспечения качества.2.3.5 Аудиты (Audits)“Назначением аудита программного обеспечения является независимая оценка программныхпродуктов и процессов на предмет их соответствия применимым регулирующим документам,стандартам, руководящим указаниям, планам и процедурам.” - IEEE 1028-97 “IEEE Standard forSoftware Reviews”.

Аудит является формально организованной деятельностью, участники которойвыполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (anotherauditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представительоцениваемой организации/организационной единицы. В результате аудита идентифицируютсяслучаи несоответствия и формируется отчет, необходимый команде <разработки> для принятиякорректирующих действий.При том, что существуют различные формальные названия (и классификации) оценок и аудита(например, как мы видели в стандарте IEEE 1028-97), важно отметить, что такого рода действиямогут проводиться почти для любого продукта на любой стадии процесса разработки илисопровождения.3.

Практические соображения (Practical Considerations)3.1 Требования к качеству программного обеспечения (Software Quality Requirements)3.1.1 Факторы влияния (Influence factors)На планирование, управление и выбор SQM-действий и техник оказывают влияние различныефакторы, среди которых: Область применения системы, в которой будет работать программное обеспечение(критичное для безопасности <людей>), критичное для бизнеса и т.п.) Системные и программные требованияCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия.

Качество программного обеспечения.Какие компоненты используются в системе – коммерческие (внешние) или стандартные(внутренние)Какие стандарты программной инженерии применимы в заданном контекстеКаковы методы и программные инструменты, применяемые для разработки исопровождения, а также для обеспечения качества и совершенствования (продукта ипроцессов)Бюджет, персонал, организация проектной деятельности, планы и расписания для всехпроцессовКто целевые пользователи и каково назначение системыУровень целостности системыИнформация об этих факторах влияет на то, как именно будут организованы и документированыпроцессы SQM, какие SQM-работы будут отобраны (стандартизированы в рамках проекта,команды, организационной единицы, организации), какие необходимы ресурсы и каковыограничения, накладываемые в отношении усилий, направляемых на обеспечение качества.3.1.2 Гарантоспособность (Dependability)(Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев)В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системыиногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русскомязыке к ним иногда применяют название “системы повышенной надежности”, “высокойдоступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратнойчасти, программного обеспечения и человека) является главным и приоритетным требованиемкачества, по отношению к основной функциональности <системы>.