Введение в программную инженерию и управление жизненным циклом ПО. Программная инженерия. Качество программного обеспечения

Программная инженерия. Качество программного обеспечения.

Copyright © Сергей Орлик, 2004-2005.

mailto:sorlik@borland.ru

https://sorlik.blogspot.com

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) инспекторов. Члены команды

инспектирования могут специализироваться в различных областями экспертизы (обладать

различными областями компетенции), например, предметной области, методах проектирования,

языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении

отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных

функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил,


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: