“Назначение управленческих оценок состоит в отслеживании развития <проекта/продукта>, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов – управления рисками, проекта/проектного управления, конфигурационного управления, безопасности <использования> программного обеспечения (safety), оценки рисков и т.п. Информация, связанная с данными вопросами, также представлена в областях знаний “Управление программной инженерией” и “Конфигурационное управление”.

Технические оценки (Technical Reviews)

“Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами.” - IEEE 1028-97 “IEEE Standard for Software Reviews”.

Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в обязательном порядке, наличия следующих входных данных:

· Формулировки целей.

· Конкретного программного продукта (подвергаемого оценке).

· Заданного плана проекта (плана управления проектом).

· Списка проблем (вопросов), ассоциированных с продуктом.

· Процедуры технической оценки.

Команда технической оценки следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта. Исследование продукта проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто провидит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта.

Инспекции (Inspections)

“Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Существует два серьезных отличия инспекций от оценок (управленческой и технической):

1. Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях.

2. Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования.

Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Команда инспектирования (как временная организационная единица) включает лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники к небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией инспекции и проверяет, что все члены команды подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами программного продукта, вызывающими интерес. Результирующий лист часто классифицирует аномалии и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:

1. Принятие <продукта> с отсутствием либо малой необходимостью переработки.

2. Принятие <продукта> с проверкой переработанных фрагментов.

3. Необходимость повторной инспекции.

Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита, предполагающих, в большинстве случаев, больший объем работ и, соответственно, длящиеся дольше.

Прогонки (Walk-throughs)

“Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью ознакомления (обучения) аудитории с программным продуктом.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Главные цели прогонки состоят (по IEEE 1028) в:

Поиске аномалий

Улучшении продукта

Обсуждении альтернативных путей реализации

Оценке соответствия стандартам и спецификациям

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

Аудиты (Audits)

“Назначением аудита программного обеспечения является независимая оценка программных продуктов и процессов на предмет их соответствия применяемым регулирующим документам, стандартам, руководящим указаниям, планам и процедурам.” – IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде разработки для принятия корректирующих действий.

При том, что существуют различные формальные названия (и классификации) оценок и аудита (например, как мы видели в стандарте IEEE 1028-97), важно отметить, что такого рода действия могут проводиться почти для любого продукта на любой стадии процесса разработки или сопровождения.

10.3 Практические соображения (Practical Considerations)

10.3.1 Требования к качеству программного обеспечения
(Software Quality Requirements)