Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

274 Глава 6

Цель и объект проверки Участники и роли

Формальная инспекция

(Formal inspection)

Систематическая проверка продукта с целью выявле-

ния и идентификации проблем, включая дефекты, и от-

клонений от стандартов и спецификаций. Планируется (в

плане проекта, плане V&V). Дополнительные инспекции

могут проводиться по инициативе руководства проекта,

группы SQA или автора.

Проводится группой обученных лиц, владеющих ме-

тодом инспекции (в количестве 3-6 человек). Каждый

участник инспекции играет роль инспектора, независимо

от других его ролей. Роли могут совмещаться. Автор не

может быть координатором, референтом или секретарем.

Продукт исследуется с разных позиций (например,

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

требований и проекта, тестопригодности, безопасности и

др.). Координатор определяет, в каком контексте будет

исследоваться продукт каждым инспектором. В помощь

инспекторам разрабатываются вопросники.

Готовность инспекторов к совещанию проверяется

координатором.

Обязательный элемент инспекции - анализ проблем и

исправление выявленных дефектов. Рекомендуется сбор

статистических данных о проблемах, дефектах, трудо-

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

потраченных ресурсах и др. Эти данные используются

для совершенствования процессов разработки и повы-

шения эффективности инспекции.

Объекты инспекции – спецификация требований,

описание проекта, исходный код, тестовые документы,

пользовательская документация, руководство по сопро-

вождению, процедуры инсталляции и др. Объект ин-

спекции должен представлять собой завершенный про-

дукт, отвечающий требованиям стандартов к его форме

и содержанию.

Продукт изучается инспекторами на этапе подготов-

ки к совещанию. Перечень проблем передается коорди-

натору. На совещании референт делает подробный обзор

продукта. По ходу чтений инспекторы поднимают про-

блемы. Согласованные дефекты регистрируются, пере-

даются автору. Устанавливается срок переделки продук-

та. Исполнение проверяется.

Процессы ЖЦ: основные процессы, V&V, SQA

Роли:

- координатор ин-

спекции (обучен, гото-

вит совещание, отве-

чает за результаты),

- секретарь (фиксиру-

ет проблемы),

- референт (представ-

ляет продукт на сове-

щании),

- автор (на совещании

дает разъяснения, по-

сле совещания – уст-

раняет дефекты),

- инспектор (при под-

готовке к совещанию

ищет дефекты, актив-

но участвует в чтени-

ях и обсуждении про-

блем, может предла-

гать альтернативы)

Сквозной кон-

троль

Это планируемый систематический контроль хода

разработки продукта и оценка его состояния. Дополни-

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

руководства проекта, группы качества или автора.

Цели – поиск дефектов, улучшение продукта, обсуж-

дение альтернативных решений, оценка соответствия

стандартам и спецификациям.

Альтернативное на-

звание метода:

Сквозной просмотр

Глава 6 275

Цель и объект проверки Участники и роли

Сквозной контроль

(Walkthrough)

Дополнительные цели – обмен применяемыми техно-

логиями, приемами и стилями, обучение участников (в

количестве 2 – 7 человек).

Объекты контроля – те же, что и для инспекции.

Продукт изучается группой контроля на этапе подго-

товки к совещанию. Проблемы и вопросы, выносимые на

обсуждение, классифицируются как общие или частные

и передаются лидеру. На совещании автор делает общий

обзор продукта. По его окончании проводится обсужде-

ние продукта, в ходе которого контролеры поднимают

общие вопросы. Далее автор начинает детальный

(сквозной) просмотр продукта (порядок просмотра вы-

бирает автор или лидер), а контролеры задают свои ча-

стные вопросы только тогда, когда автор представляет

соответствующий фрагмент продукта.

По завершении обсуждения каждого фрагмента фик-

сируются решения и предложения по каждому из расс-

мотренных вопросов.

Процессы ЖЦ: основные процессы, V&V, SQA

Роли:

- лидер (определяет

цели обзора, ведет

совещание)

- секретарь (фиксиру-

ет все решения, а так-

же комментарии по

поводу дефектов, сти-

лей, улучшений и др.)

- автор (представляет

продукт (в целом и

детально) и отвечает

на вопросы)

- контролеры (готовят

общие вопросы к про-

дукту в целом и част-

ные вопросы к его

частям)

Аудиторская проверка (Audit) (альтернативные названия - ревизия, инспекция)

Независимая проверка продукта, процесса или множества

процессов с целью оценивания соответствия стандартам, руково-

дствам, планам, процедурам, условиям договора и другим крите-

риям. Планируется (в планах проекта). Проводится группой ауди-

торов (1-5 человек).

Ответственность за принятие решений относительно необхо-

димости аудита, организации-аудитора, целей, критериев, сферы,

объектов аудита, несет инициатор. Он может быть руководителем

проверяемой организации, представителем заказчиков, пользова-

телей или третьей стороны. Ответственность за достижение целей

аудита и его беспристрастное проведение в установленном по-

рядке несет ведущий аудитор.

Объекты проверки – все виды планов, тексты договоров, рек-

ламации заказчиков и пользователей, руководства пользователя,

отчеты и статистические данные процессов проверки, программ-

ный продукт на всех стадиях ЖЦ, применяемые стандарты, нор-

мы, руководства, процедуры и др.

Перед началом аудиторской проверки инициатор (как прави-

ло) уведомляет о ней организацию-разработчика программного

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

диту людей и проверяемых материалов. Далее ведущий аудитор

готовит план аудита и получает его одобрение инициатором.

В ходе подготовки к аудиторской проверке аудиторы изучают

план аудита, информацию о проверяемой организации и продук-

тах, применимые при проверке и оценке стандарты, нормативы и

руководства, критерии оценивания. Этап проверки открывается

общим собранием группы аудиторов и проверяемой организации

с целью обзора целей, сферы, процедур и графика аудиторской

проверки.

Роли:

- ведущий аудитор

(готовит план аудита,

подбирает группу и

руководит ее работой,

готовит отчет),

- секретарь (фиксиру-

ет дефекты, решения,

рекомендации группы

аудита),

- аудиторы (работают

по плану аудита, не

имеют личной заинте-

ресованности, фикси-

руют замечания и ре-

комендации),

- инициатор (иниции-

рует процесс аудитор-

ской проверки, утвер-

ждает ее план и ре-

зультаты, распростра-

няет отчет),

- проверяемая органи-

зация (способствует

аудиту - предоставля-

ет документы и интер-

вьируемых сотрудни-

ков, устраняет замеча-

ния аудиторов)

276 Глава 6

Цель и объект проверки Участники и роли

Проверка состоит в сборе (путем опроса сотрудников, изуче-

ния документов) и анализе объективных данных о состоянии дел

в проверяемой организации. Наблюдения обсуждаются и под-

тверждаются сотрудниками организации до проведения заключи-

тельного общего собрания. По завершении проверки готовится

отчет. Ответственность за его объективность несет ведущий ауди-

тор. Отчет утверждается инициатором проверки и направляется

всем заинтересованным лицам проверяемой организации для уст-

ранения замечаний аудиторов. Процессы ЖЦ: аудит

Методы неформальной проверки представляют собой вариации формальных

проверок, адаптированные к целям и условиям проектов, в рамках которых разра-

батываются программные продукты, и с учетом критичности этих продуктов.

Порядок решения проблем, обнаруженных при проверке, регулируется про-

цедурами регистрации проблем (разногласий) и процедурами внесения изменений в

рабочие продукты. Если рабочий продукт находится в сфере управления конфигу-

рацией, нужно руководствоваться стандартом ISO/IEC

12207 (процессы управле-

ния конфигурацией и решения проблем), в противном случае - можно использовать

рекомендации применяемого метода проверки. Типовая форма отчета о проблеме,

обнаруженной при проверке, представлена на рисунке 6.3.

Сообщение о проблеме в рабочем продукте

Наименование проекта:____________________________

Наименование рабочего продукта (части) ___________

Идентификатор проблемы:_____________

Подробное описание проблемы:_____________________

_____________________

Серьезность проблемы:

очень важная (возможен существенный дефект, повторить процедуру проверки),

умеренно важная (возможен умеренный дефект, устранение проконтролировать),

не важная (несущественный технический дефект, контроль необязателен)

Критичность проблемы для проекта:

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

устранимая (локальные ресурсоемкие переделки (время)),

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

Потенциальный ущерб: оценка ущерба на каждой из последующих стадий ЖЦ в случае

не решения проблемы

Приоритет устранения: немедленно, к определенному сроку, в следующей версии

Состояние проблемы: предполагаемая, открытая, закрытая, закрытая с замечаниями,

повторно возникшая

Хронология разрешения проблемы:

4 важные даты, связанные со сменами состояний

проблемы

Дата обнаружения:____________________

Кто обнаружил проблему:______________________________

Кому направляется: __________________

Ответственный за устранение:__________

Составитель (подпись):__________

Дата составления:_______________

Рис. 6.3. Типовая форма отчета о проблеме

Глава 6 277

Рекомендации по классификации проблем содержатся в стандарте IEEE Std.

1044 [9] и руководстве по его применению – IEEE Std.1044.1 [10].

6.3. Формальные инспекции

6.3.1. Элементы процесса инспекции

В программной инженерии термин «инспекция» определяет два понятия [14]:

– инспекция – это методология статического анализа, основанная на нефор-

мальной визуальной проверке выборочных продуктов разработки с целью обнару-

жения отклонений от стандартов разработки и других проблем. Инициируется из-

вне проекта (например, руководством, заказчиком и др.) и выполняется группой, не

включающей членов группы проекта. Может применяться в процессе аудита;

– инспекция – это процесс формальной проверки рабочего продукта вла-

дельцем этого рабочего продукта и группой его коллег по проекту с целью обнару-

жения ошибок, упущений, несогласованностей и проблематичных областей в рабо-

чем продукте.

Именно это, второе определение понятия инспекции и используется далее.

Формальная инспекция – это инспекция, обладающая следующими отличи-

тельными особенностями:

• автор рабочего продукта – обязательный участник процесса инспекции;

• инспекция выполняется в установленном порядке в соответствии с утвер-

жденными процедурами и графиками и с целью обнаружить все существенные де-

фекты и проверить их устранение автором;

• информация, извлекаемая при инспекции, собирается и используется для

управления проектом, оценивания качества и улучшения процесса разработки;

• при проведении инспекции всегда используются контрольные вопросники,

что облегчает поиск дефектов и помогает правильно их классифицировать;

• члены группы инспекции прошли обучение процессу инспекции;

• каждая инспекция соответствует определенному типу инспекций и прово-

дится в соответствии с требованиями, предъявляемыми к инспекциям соответст-

вующего типа.

Тип формальной инспекции определяется видом (типом) анализируемого ра-

бочего продукта, стадией ЖЦ, на которой она проводится, содержательной направ-

ленностью контрольного вопросника, критерием начала проведения инспекции и

критерием завершения инспекции.

Первое опубликованное описание процесса инспекции появилось в 1976 г в

статье автора этого метода М.Фагана [15]. С тех пор, как отмечает А.Аккермен, ин-

спекции неоднократно доказывали свое преимущество перед другими видами про-

верок, в частности, техническими обзорами и сквозным контролем, и, безусловно,

способствовали улучшению качества ПС, повышению производительности труда

разработчиков и совершенствованию управляемости процесса разработки [16].

Основные элементы процесса формальных инспекций таковы:

• семь четко определенных этапов (шагов) процесса инспекции, выполняе-

мых в установленной последовательности (рисунок 6.4);

• пять строго установленных ролей участников инспекции: координатор

(председатель, арбитр), референт (комментатор, чтец), секретарь (регистратор), ин-

спектор, автор продукта (разработчик);

278 Глава 6

Этап

планирования

Этап обзора

Этап

подготовки

Инспекционное

совещание

Этап переделки

Этап проверки

исправлений

Рабочий

продукт

Проверенный

рабочий

продукт

Рис. 6.4. Этапы процесса формальной инспекции

• четко определенная процедура сбора и классификации данных о рабочем

продукте и процессе;

• инспектируемый рабочий продукт;

• инфраструктура для поддержки процесса инспекции.

Ключевые факторы успеха процесса инспекций - обучение участников и

строгое соблюдение всех шагов и применяемых процедур. Очевидно, что эффек-

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

разработчиках, занимающих 2-й и выше уровень зрелости по модели СММ, по-

скольку на этих уровнях институциализированы такие направления деятельности,

как обучение, планирование, контроль исполнения и др. [17].

Инспекции проводятся небольшой группой специалистов - от 4 до 7 чело-

век

, представляющих разные области знаний в программной инженерии. Усилен-

ный состав может созываться при рассмотрении рабочих продуктов самого высоко-

го уровня (концепции или требований). Дополнительные участники могут привле-

каться в той степени, в которой необходимо знать их точку зрения о рабочем про-

дукте. Поскольку цель инспекции – обнаружить и зафиксировать дефекты, роль

инспекторов исполняют фактически все члены группы инспекции независимо от

других исполняемых ими ролей.

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

ется критерий начала инспекции, а для подведения результатов инспекции – кри-

терий завершения инспекции.

Критерий начала инспекции устанавливается с учетом типа рабочего продук-

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

достаточной степени готов к использованию по назначению после устранения в

нем дефектов, обнаруженных при инспекции. То есть, инспекции подлежат закон-

ченные («почти готовые») рабочие продукты. Для инспекции кода программ, на-

пример, критерий ее начала – логическая завершенность и отсутствие по крайней

мере синтаксических ошибок, а для инспекции документа – соответствие общим

требованиям к документам подобного типа.

Критерий завершения инспекции – наличие отметки о завершении действий,

Нами описана классическая схема инспекции. В настоящее время проводятся ис-

следования эффективности процесса инспекции, выполняемого только двумя инспекторами

(например, [18]).

Глава 6 279

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

спекции [14]. Критерий завершения используется главным образом для того, чтобы

гарантировать, что дефекты, обнаруженные при инспекции и классифицированные

инспекторами как существенные, устранены. Устранение умеренных или не суще-

ственных дефектов, которые не оказывают значительного влияния на применение

рабочих продуктов по назначению, может не включаться в критерий завершения.

Все работы по представляемому на рассмотрение рабочему продукту должны

быть «заморожены» до завершения инспекции, в противном случае она теряет вся-

кий смысл. В связи с этим, инспекция должна заранее планироваться в рамках сро-

ков разработки рабочих продуктов.

По завершении каждой инспекции о ней составляется подробный отчет. Кро-

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

отчете об инспекциях.

6.3.2. Этап планирования

Планирование инспекции выполняется координатором, который устанавли-

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

ствующего типа, подбирает квалифицированную инспекционную группу и распре-

деляет роли, устанавливает место и время встречи группы для совместной работы,

обеспечивает участников необходимыми инспекционными материалами.

Используя критерий начала инспекции, координатор, прежде всего, отсеивает

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

определяет, имеют ли они приемлемый объем, позволяющий завершить обсужде-

ние в рамках одного заседания группы. Если объем проверяемого материала слиш-

ком большой, координатор делит его на части.

Затем координатор подбирает членов инспекционной группы, обладающих

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

верку рабочих продуктов соответствующего типа (не по форме, а по содержанию) и

сформировать о них компетентное мнение.

Каждому участнику инспекции поручается определенная роль.

Координатор (председатель) руководит группой инспекторов и несет ответ-

ственность за результативность ее работы. Это самая активная роль на всех этапах

инспекции (кроме устранения дефектов). Основная функция координатора – обес-

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

спекционное совещание не превратится в поиск причин ошибок, а обсуждение не

увязнет в мелких проблемах, упуская существенные.

Координатор отвечает за сбор объективных данных в ходе инспекции, со-

ставление документов инспекции и осуществление обратной связи с менеджером

проекта, а также с группой программной инженерии, которая может использовать

результаты инспекции для принятия решений о совершенствовании процессов.

Ввиду важности данной роли для инспекции, координатор должен иметь спе-

циальную подготовку (пройти обучение).

Референт (комментатор). Несет ответственность за эффективность работы

группы при рассмотрении рабочего продукта (далее просто продукта) в ходе ин-

280 Глава 6

спекционного совещания, зачитывая текст документа и комментируя его

. Лучшим

кандидатом на эту роль может быть разработчик, непосредственно участвующий в

работах на следующей стадии ЖЦ и заинтересованный в качестве продукта, яв-

ляющегося для него исходным.

Секретарь (регистратор). Несет ответственность за регистрацию дефектов,

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

жения информации о каждом обнаруженном дефекте. Секретарь должен также ре-

гистрировать информацию о каждой поднятой, но не решенной проблеме, а также

обо всех дефектах, обнаруженных в документах вышестоящего уровня.

Автор. Это разработчик инспектируемого продукта. Его основная обязан-

ность – предоставить всю необходимую информацию о продукте, а также отвечать

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

толкования) не приняты ими за дефекты. Во время совещания он вместе со всеми

ищет недостатки в своей работе.

Автор несет ответственность за устранение как существенных, так и не суще-

ственных дефектов, однако устраняет последние не к очередной встрече с инспек-

торами, а когда для этого появятся необходимые ресурсы.

Инспекторы. Независимо от исполняемой специальной роли в инспекции

(координатор, референт, автор или секретарь) все члены группы считаются инспек-

торами и несут ответственность за обнаружение дефектов на этапе подготовки и во

время инспекционного совещания.

Группа инспекторов формируется из разработчиков программного обеспече-

ния. Исключение из этого правила составляют программисты, выполняющие коди-

рование отдельных фрагментов программного продукта, которые не должны при-

влекаться для разработки тестовых процедур для своего кода.

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

групп проекта системы, организации-разработчика или организации-заказчика, как-

то группа системной инженерии, группа тестирования, группа качества, админист-

раторы системы и пользователи. «Внешние» инспекторы могут использоваться в

качестве экспертов для повышения эффективности процесса инспекции.

Сформировав группу инспекции, координатор раздает ее участникам пакет

материалов инспекции, в состав которого входит:

1. Заметки для инспекционного совещания. Этот вид документа предназначен

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

спекции.

Заметки должны иметь определенную структуру и содержать следующую

информацию, подготовленную координатором:

• титульная часть. Включает административную информацию – название

проекта, дату рассмотрения продукта, стадию проекта, идентификацию компонента

проекта, частью которого является рабочий продукт, название и версию инспекти-

руемого рабочего продукта, сведения о координаторе;

• тип совещания. Тип совещания отвечает его цели – новая инспекция (пер-

вое чтение) или повторная инспекция (проверка и обсуждение исправлений);

• вид инспекции. Указывается вид инспектируемого рабочего продукта (тре-

При инспекции кода референт описывает структуру программы и комментирует

программные конструкции, давая им собственные оценки.

Глава 6 281

бования, проект и др.);

• расписание инспекции. Указывается дата, время, продолжительность со-

вещания, время, отведенное на подготовку к совещанию, и размер продукта;

• состав группы инспекции. Указывается ФИО каждого участника, сфера

компетенции применительно к категории дефектов, отведенная роль в инспекции;

• комментарии. Ссылки на документы предыдущего уровня разработки

проекта, которые могут содержать информацию, полезную для понимания сущест-

ва продукта и проблем с ним.

2. Рабочий продукт на носителе. Это, скорее всего, твердая копия продукта

(документа), хотя нельзя исключить возможность визуального анализа экранных

объектов (форм, отчетов, диаграмм, фрагментов кода и др.) или использования все-

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

создана соответствующая среда;

Контрольные вопросники. Это списки вопросов, каждый из которых каса-

ется определенной технической проблемы, которая может быть выявлена в резуль-

тате поиска ответа на вопрос (приложение 5). Вопросники составляются для всех

возможных типов рабочих продуктов (например, для описания требований к систе-

ме, описания проекта, описания набора тестов и др.). Вопросы классифицируются

по категориям возможных дефектов в рабочем продукте соответствующего типа и,

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

на определенные области возможных проблем. Каждому вопросу присваивается

составной порядковый номер, отражающий номер категории, номер подкатегории

и номер самого вопроса (рисунок 6.5);

Обозначе-

ние вида

продукта

Наименование вида (типа) рабочих продуктов

Номер категории

(подкатегории)

Наименование категории (подкатегории) дефек-

тов

Номер

вопроса

Формулировка вопроса для выявле-

ния дефекта определенной категории

Рис.6.5. Структура контрольного вопросника

4. Бланки форм (или журналы) регистрации проблем. В журнале инспекторы

будут описывать суть проблемы и связанную с ней информацию. Форма журнала

может быть выбрана координатором произвольно, однако в нем должно найти от-

ражение следующее:

• идентификация инспектора (код инспектора

, его ФИО и координаты,

сфера компетенции (применительно к виду продуктов и категориям дефектов));

• дата выполнения подготовки;

• время, отведенное на подготовку, и время, реально потраченное инспекто-

Всевозможные «коды» и «номера» в документах инспекции могут сослужить свою

службу, если координатор (или группа SEPG) попытается автоматизировать процесс и соз-

даст базу документов инспекции. Это было бы очень полезно для статистичеcкой обработки

данных инспекций, изучения эффективности процесса инспекции и др.

282 Глава 6

ром на подготовку к совещанию;

• объем продукта, охваченный проверкой;

• описание каждой обнаруженной проблемы, а именно:

– - присваиваемый ей порядковый номер,

– - местонахождение в продукте (номер страницы, раздела, параграфа,

абзаца, предложения),

– - описание сути проблемы,

– - категория предполагаемого дефекта и номер вопроса, поиск ответа

на который послужил толчком к обнаружению проблемы;

• количество обнаруженных проблем за время подготовки.

Нужно заметить, что в пакет материалов инспекции входят и другие доку-

менты, однако они не раздаются инспекторам на этапе планирования и поэтому

рассматриваются дальше.

Формируя группу инспекции, координатор должен установить степень зна-

комства каждого инспектора с материалом и определить необходимость проведе-

ния краткого обзора. Если члены группы инспекторов выбраны из состава разра-

ботчиков проекта, тестировщиков, или инженеров по качеству, хорошо знакомых с

проектом, этап обзора не требуется. Если нет – координатор планирует краткий об-

зор продукта его автором.

Для того чтобы инспекции были максимально эффективны, Д. Франкович

предлагает руководствоваться следующими общими рекомендациями [19]:

• продолжительность планируемого совещания – не более 2 часов;

• периоды и продолжительность проведения инспекции должны быть согла-

сованы с менеджером проекта и предусмотрены в плане проекта;

• обязательно должен быть подготовлен контрольный вопросник, отвечаю-

щий потребностям инспекции определенного вида рабочих продуктов;

• нужно предусматривать при планировании инспекции не менее двух дней

на подготовку (продолжительность может колебаться в зависимости от размера и

сложности рабочего продукта);

• объем рассматриваемого рабочего продукта не должен превышать 20

страниц;

• автор не должен исполнять роль координатора, референта или секретаря;

• группа инспекции должна сосредоточиться на обнаружении дефектов, а не

на проблемах их устранения.

Цели, задачи и роли при планировании инспекции подытожены в таблице 6.5.

Таблица 6.5. Этап планирования

Цель Организовать инспекцию и спланировать ресурсы для ее проведения

Вход

• Завершенный вариант рабочего продукта

• Сопровождающие материалы

• Критерий начала инспекции (наличие продукта, отвечающего мини-

мальным требованиям к оформлению и содержанию)

• Исторические данные инспекции (при наличии)

Задачи

• Проверить критерий входа

• Подобрать группу инспекции

• Определить, нужен ли обзор

• Составить план-график (расписание) инспекции(й)

• Сформировать и распространить пакет материалов инспекции

Глава 6 283

Измерения

(меры)

• Трудоемкость планирования

• Размер рабочего продукта

Выход

• Комплект материалов для инспекции сформирован и вручен

• Запланирован обзор (при необходимости)

Роли Координатор:

• Проверяет, отвечает ли рабочий продукт критерию входа

• Подбирает членов группы инспекции и автора (разработчика)

• Принимает решение о том, нужен ли обзор

• Планирует совещание(я) и комплектует материалы совещания

Автор:

• Рассматривает рабочий продукт совместно с координатором

• Предлагает кандидатов в группу инспекции

• Дает рекомендации о том, нужен ли обзор продукта

6.3.3. Этап обзора

Краткое обзорное совещание планируется в том случае, если инспекционная

группа не знакома с материалом. Группа должна иметь представление об истоках

рабочего продукта (знать содержание документов, на основе которых он был раз-

работан). Для исходного кода, например, это должны быть документы описания

требований и проекта (в части, касающейся этого кода).

В ходе обзора автор дает характеристику рабочего продукта и разъясняет его

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

полагаемое использование. Обзор планируется в следующих обстоятельствах:

– инспекционная группа не знакома с классом программных систем, кото-

рый представляет данный рабочий продукт;

– рабочий продукт новый или рассматривается впервые;

– инспекция нового проекта;

– при разработке рабочего продукта использованы новые методы.

Цели, действия и роли в обзорном совещании подытожены в таблице 6.6.

Таблица 6.6. Этап обзора

Цель Ознакомление

Вход Инспектируемый рабочий продукт

Обзорный материал, подготовленный автором

Задачи Координатор проводит обзорное совещание

Автор представляет рабочий продукт

Измере-

ния

Время автора на подготовку

Продолжительность обзорного совещания

Выход Возросший уровень понимания рабочего продукта

Распределение обязанностей (при необходимости)

Комплект рабочих материалов инспекции

Материалы обзорного совещания

6.3.4. Этап подготовки

Это ключевой этап процесса инспекции, в ходе которого инспекторы гото-

вятся к исполнению своих ролей в инспекционном совещании. Каждый инспектор

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

тех аспектах проверки, которые входят в его компетенцию. Он выявляет проблемы,

используя для этого контрольные вопросники, ориентированные на обнаружение