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

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

284 Глава 6

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

ветствие рабочего продукта тем продуктам предыдущих этапов разработки, кото-

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

любыми аналитическими методами, рассмотренными в разделе 6.2.

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

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

налы представляются координатору до начала инспекционного совещания.

Известно, что именно на шаге подготовки инспекции выявляется до 90% де-

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

должно быть не меньше длительности инспекционного совещания, а для очень

сложных и критических систем может увеличиваться в несколько раз [20].

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

оказывает опыт членов группы в проведении инспекций. Поэтому вопросам обуче-

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

Качество подготовки инспекции зависит также от личного опыта членов

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

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

Цели, действия и роли на этапе подготовки подытожены в таблице 6.7.

Таблица 6.7. Этап подготовки

Цель Достичь понимания продукта и идентифицировать потенциальные проблемы

Вход

• Комплект рабочих материалов для инспекции (заметки, вопросники,

журналы)

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

• Материалы обзора

Задачи

• Изучить рабочий продукт

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

контрольный вопросник (либо типовой вопросник в приложении 5)

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

• Сформировать перечень обнаруженных проблем

Измере-

ния

• Продолжительность подготовки

• Количество проблем

Выход

• Сформированный сводный перечень проблем в журналах регистрации

проблем

• Зафиксированное время подготовки

Роли Инспектор:

• Изучает рабочий продукт

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

• Фиксирует время подготовки

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

• Решает все задачи, связанные с подготовкой инспекции

• Устраняет следующие проблемы самой инспекции:

- инспектор не может участвовать в инспекции

- существенное отклонение рабочего продукта от требований

Референт:

• Решает все задачи, связанные с подготовкой к обсуждению продукта

• Решает, как лучше представить рабочий продукт

Глава 6 285

6.3.5. Инспекционное совещание

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

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

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

Созывает совещание и далее координирует его работу координатор. В начале

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

уточняет неясности. Если группа новая (или включает новых членов), координатор

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

вторно объясняя цель инспекции и назначение продукта.

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

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

Совещание строится таким образом, что любой инспектор может прервать рефе-

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

точки зрения, дефект. Чтение материала приостанавливается для краткого обсуж-

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

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

чтение возобновляется.

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

множество описаний дефектов.

Каждое описание дефекта можно считать логическим продолжением описа-

ния соответствующей проблемы, обнаруженной инспектором (или несколькими

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

не замеченного при подготовке.

Описание дефекта должно включать:

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

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

знанной дефектом),

• категория (подкатегория) дефекта и номер вопроса (по вопроснику), по-

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

• характер дефекта (упущение автора, ошибочное решение, ошибка верх-

него уровня);

• уровень серьезности дефекта (существенный, умеренный, несуществен-

ный)

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

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

дефектом;

• ориентировочное время на устранение дефекта;

• идентификация лица (группы), которому (которой) продукт направляется

на переделку;

• тип повторной проверки продукта (С – совещание автора с координато-

ром, R – совещание автора с координатором и инспекторами);

• отметка об устранении дефекта. Дата подтверждения устранения де-

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

этапе 7).

Уровень серьезности дефекта устанавливается для определения приоритета

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

286 Глава 6

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

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

тические ошибки, небольшие отклонения от стандартов - как несущественные. С

уровнем серьезности дефекта связан и тип повторной проверки на этапе проверки.

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

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

проблему нерешенной и продолжает совещание. Секретарь отмечает в соответст-

вующем журнале нерешенную проблему как открытую для переноса ее обсужде-

ния на дополнительное время (так называемый «третий час»).

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

дый предполагаемый дефект действительно дефектом. Иногда то, что считается

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

не пониманием того, что имел в виду автор. Вопрос может быть решен изучением

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

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

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

следующего этапа инспекции – «третьего часа».

Если лимит времени совещания (2 часа) исчерпан, а чтение (разбор продукта)

не закончено, назначается дата повторного совещания.

Если чтение завершено, но остались открытые проблемы, - принимается ре-

шение о переносе их обсуждения на «третий час».

После совещания автор и координатор должны определить сроки и тип про-

верки внесенных исправлений в продукт (этап 7). Автор получает копию списка

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

при переработке продукта, а также служит отправной точкой на последующих эта-

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

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

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

(Ebenau) предлагает следующую категоризацию состояний рабочего продукта [21]:

• продукт категории А (от accept). Рабочий продукт принимается в полном

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

свободен от дефектов, однако в нем не найдено существенных дефектов, а также

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

клонения от спецификаций;

• продукт категории С (от conditional). Рабочий продукт принят условно с

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

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

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

менений логики (концепции) рабочего продукта;

• продукт категории R (от Reinspect). Рабочий продукт подлежит повтор-

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

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

координатора, автора и, по крайней мере, одного инспектора. Это означает, что в

продукте обнаружено значительное количество существенных дефектов или пере-

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

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

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

Глава 6 287

Результаты совещания фиксируются в отчете об инспекции, который составляется

по завершении обсуждения продукта.

Отчет об инспекции. Должен включать:

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

тип проведенного совещания;

• состояние продукта. Один из возможных вариантов текста:

– «Чтение завершено. Продукту присвоена категория (A/C/R)»,

– «Чтение не завершено. Будет продолжено на совещании <указание

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

продолжено чтение>. Категория не присвоена»;

• дата проверки исправлений и тип повторной проверки (если продукту

присвоена категория C или R);

• список дефектов (набор описаний дефектов);

• итоговая информация:

– число рассмотренных проблем,

– число зарегистрированных дефектов,

– число открытых проблем, перенесенных на «третий час»,

– число закрытых проблем <число проблем, закрытых на «третьем ча-

се»>, из них установлено дефектов <число> (заполняется по завершении

«третьего часа»);

• комментарии. Информация о необходимости рассмотрения новых доку-

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

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

суждении (экспертов, разработчиков продуктов предыдущих уровней) и др.;

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

подпись.

Если в «третьем часе» нет необходимости, отчет об инспекции передается

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

и выделить ресурсы для его переделки.

Если обзор продукта не был доведен до конца (чтение прервано), - инспекто-

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

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

которого будет продолжено обсуждение.

В таблице 6.8 подытожены цели, процедуры и роли на этапе совещания.

Таблица 6.8. Этап инспекционного совещания

Цели Обсудить рабочий продукт. Достичь консенсуса и зафиксировать дефекты

Вход

• Полный список предполагаемых проблем (в журналах)

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

Задачи

• Введение в материал

• «Чтения» рабочего продукта

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

• Подведение итогов по дефектам (обзор дефектов)

• Определение категории состояния рабочего продукта (А/C/R)

A: Принят – отмечено несколько несущественных дефектов; устра-

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

C: Принят условно – автор должен отчитаться за переделку перед

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

288 Глава 6

R: Отложен на повторную инспекцию – подлежит повторной ин-

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

спектора

Измерения

• Данные о производительности (количество рассмотренных проблем,

закрытых, открытых)

• Данные о дефектах (количество, серьезность, количество дефектов,

допущенных на предыдущем уровне разработки)

Выход

• Категория состояния продукта

• Сформированный полный список дефектов

• Сформированные заметки инспекционного совещания о нерешенных

проблемах

• Частично сформированный отчет об инспекции

Роли Автор:

• Сохраняет объективность, внимательно слушает, делает заметки

• Ничего не опасается

Инспекторы:

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

нием к автору

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

• Заботятся не о форме, а о содержательной стороне высказываемых за-

мечаний

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

• Вовремя начинает и заканчивает совещание

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

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

фектах

Референт:

• Выбирает наиболее эффективную последовательность представления

рабочего продукта

• Отвечает на вопросы, возникающие у членов группы

Секретарь:

• Знаком с классификационной схемой дефектов

• Фиксирует все данные в общем списке дефектов

• Готовит сводную информацию о дефектах для Итогового отчета об

инспекции

6.3.6. Этап дополнительного обсуждения - «третий час»

«Третий час» – это условное название дополнительного периода времени вне

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

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

ем дефектов.

«Третий час» может проходить в форме дополнительного совещания или ин-

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

ного совещания и не ограничен одним часом.

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

основном инспекционном совещании. Это могут быть инспекторы (необязательно

все), а также менеджеры, внешние технические эксперты и т.п. В ходе «третьего

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

ному внесению изменений в продукт, например, справки о существе дефектов, об-

Глава 6 289

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

ственный продукт, не дожидаясь устранения дефектов в исходных продуктах. В

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

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

Если «третий час» проводится в форме индивидуальной работы, он использу-

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

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

занных с существенными дефектами, обнаруженными в документах более высоко-

го уровня, находящимися под управлением конфигурацией.

Итоговая информация о результатах «третьего часа» вносится в отчет об ин-

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

6.3.7. Этап переделки рабочего продукта

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

спекции. До начала этапа автор должен быть обеспечен всей необходимой инфор-

мацией и реальными временными ресурсами. Нужно учитывать, что дефекты в ра-

бочем продукте могут быть вызваны ошибками, допущенными другими лицами на

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

без исправления ошибок, с которыми они связаны. Автор не должен брать на себя

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

ние), даже в том случае, если виновники ошибок далеко (или вообще больше не

работают по данному проекту).

Автор несет ответственность за исправление всех дефектов, содержащихся в

списке дефектов инспекции, - и существенных, и несущественных.

Существенные дефекты он обязан устранить в установленные сроки и отчи-

таться за их устранение перед координатором или группой инспекции. При нали-

чии времени, в эти же сроки он может устранить и несущественные дефекты, в

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

редачи его другому процессу).

Решение о любых корректировках рабочего продукта из-за существенных

дефектов должно приниматься менеджером проекта. Каждое исправление должно

быть зафиксировано в системе контроля за изменениями в проекте и прослеживать-

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

(визирование) рабочего продукта. В таблице 6.9 подытожены цели, процедуры и

роли на этапе переделки рабочего продукта.

Таблица 6.9. Этап переделки

Цель Устранить дефекты в рабочем продукте

Задачи Автор устраняет все дефекты

Автор уведомляет координатора о завершении переделок

Автор сообщает о не устраненных дефектах менеджеру проекта

Измерения Количество дефектов

Трудоемкость переделки каждого дефекта

Выход Измененный рабочий продукт, не содержащий зафиксированных ранее

существенных дефектов

Роли Автор:

• Устраняет дефекты

• Сообщает о не устраненных дефектах менеджеру проекта

• Уведомляет координатора о завершении переделок

290 Глава 6

6.3.8. Проверка внесенных изменений или повторная инспекция

На этом этапе проверяются все изменения, сделанные автором в рабочем

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

переделать продукт он мог внести новые дефекты.

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

на инспекционном совещании, координатор может:

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

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

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

взаимозависимостях.

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

наличии большого числа дефектов или если устранение некоторых дефектов требо-

вало больших и взаимосвязанных исправлений.

Если все существенные дефекты устранены, все открытые проблемы разре-

шены и рабочий продукт удовлетворяет инспекторов, координатор «сдает» про-

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

В противном случае в ранее составленном отчете об инспекции проставляет-

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

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

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

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

Итоговый отчет об инспекции. В этом отчете помимо информации, отра-

жаемой в отчетах об инспекции, составляемых (обновляемых) после каждого ин-

спекционного совещания (вид продукта, его объем и прочее), содержатся:

• сводные данные обо всех этапах инспекции рабочего продукта - количест-

во циклов инспекции (повторных инспекционных совещаний, повторных инспек-

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

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

• сводные данные о проблемах - общее количество рассмотренных проблем,

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

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

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

ности инспекторов и эффективности их работы);

• сводный список дефектов. Этот список строится на основе списка дефек-

тов, который изначально был составлен на первом инспекционном совещании, и

уточнялся по мере выявления новых и устранения найденных дефектов. Поскольку

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

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

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

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

ные, не существенные), а в рамках каждой категории – в разрезе характера дефек-

тов (рисунок 6.6).

При желании, информационные разрезы можно выбрать и иначе (например,

по категориям (подкатегориям) вопросов в вопроснике);

• подписи.

Глава 6 291

Уровень серьезности дефектов

Существенных Умеренных Не существенных

Номер де-

фекта в спи-

ске дефектов

Категория

дефекта

упущений

ошибок

верхнего

уровня

упущений

ошибок

верхнего

уровня

упущений

ошибок

верхнего

уровня

…

Итого

Рис. 6.6. Пример сводного списка дефектов

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

6.10.

Таблица 6.10. Этап проверки исправлений

Цель Завершить инспекцию и утвердить ее результаты

Вход Измененный рабочий продукт, если он имел категорию C или R

Рабочий продукт, если он имел категорию A

Все формы для инспекции

Задачи Координатор проверяет рабочий продукт:

Если продукт имеет категорию R, перейти на этап планирования

Если продукт имеет категорию C, проверить переделки. Если не все зафик-

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

Если продукт имеет категорию A, утвердить решение инспекции

Сформировать Итоговый отчет об инспекции

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

Направить копию Итогового отчета группе программной инженерии

Изме-

рения

Трудоемкость проверки

Трудоемкость составления Итогового отчета об инспекции

Выход Проверенный рабочий продукт

Утвержденные результаты инспекции

Составленный Итоговый отчет об инспекции

Роли Автор:

• Готовится к повторной инспекции, если продукт имеет категорию R

• Выполняет и переделывает то, на что указал координатор

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

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

• Проверяет переделки с автором, если продукт имеет категорию C

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

• Оформляет Итоговый отчет об инспекции

• Направляет копию Итогового отчета группе программной инженерии

6.3.9. Повышение эффективности процесса инспекции

Процесс формальной инспекции доказал свою эффективность как механизм

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

организациях-разработчиках ПС. Он широко используется и пристально изучается

(подтверждения этому можно найти, например, на сайте: www2.ics.hawaii.edu/

292 Глава 6

~johnson/FTR/Bib/bib-master.html).

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

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

условиям его применения и постоянно улучшаться.

Главными элементами, которые должны «настраиваться» от инспекции к ин-

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

совещание) и вопросники [20].

Если на инспекционное совещание выносится слишком большой рабочий

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

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

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

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

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

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

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

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

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

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

не только инспектируемому виду рабочих продуктов, но и классу ПС (например,

встроенному ПО реального времени в бортовых компьютерах, системам с базами

данных и др.). Настройка вопросников сделает более эффективным этап подготов-

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

Однако, перегруженные информацией вопросники могут снизить эффективность

инспекций, отвлекая внимание от существенных вопросов. Оптимальный объем

вопросов, выносимых на одну инспекцию, ограничивается одним листом [20].

Для оценки эффективности базового процесса инспекции и установления

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

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

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

каждой инспекции, типах дефектов и стадиях ЖЦ, на которых они обнаружены.

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

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

измерений этого процесса и разработан план измерений

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

подхода и включать в нее следующие положения:

• определение целей инспекции;

• определение и разработка множества метрик;

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

• проверка и утверждение метрик;

• анализ метрик;

• обобщение данных и определение тенденций процесса;

Программа измерений может внедряться не только для повышения эффективности

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

контроля.

Глава 6 293

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

инспекции;

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

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

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

• переподготовка инспекторов.

Метрики процесса инспекции. Метрики для включения в план измерений

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

мера» (глава 4).

Проверяемые цели инспекции таковы:

G1: планировать действия по инспекции рабочего продукта ПС в качестве

заключительного этапа работ на той стадии ЖЦ, на которой он разработан.

G2: идентифицировать и устранять дефекты в рабочих продуктах, начиная

с самых ранних стадий ЖЦ.

Вопросы, связанные с целью G1:

Q1: Сколько времени необходимо для подготовки и проведения инспекции?

Q2: Достаточны ли ресурсы (время и персонал), выделенные для проведения

инспекции?

Q3: Завершена ли запланированная инспекция?

Q4: Эффективен ли процесс инспекции для устранения дефектов?

Вопросы, связанные с целью G2:

Q5: Какие данные нужно собирать в ходе инспекции?

Q6: Как трассируется распространение дефекта?

Q7: Чем измеряется эффективность инспекции?

Q8: Какова оптимальная интенсивность (скорость) инспекции?

Q9: Как сопоставляются разные методы устранения дефектов?

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

6.11.

Таблица 6.11. Собираемые данные и метрики процесса инспекции

Вопрос Метрика Код Описание

Q1 Время под-

готовки

Тпо Суммарное время подготовки всех инспекторов. Время

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

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

Q1, Q5 Время про-

ведения

Тпр Время, потраченное группой инспекции на проведение

инспекции.

Q3 Число ин-

спекций,

запланиро-

ванных в

проекте

Ипл Общее количество инспекций рабочих продуктов, за-

планированное в плане проекта. Эти данные могут ис-

пользоваться для сравнения с реальным числом ин-

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

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

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

Q3 Число про-

веденных

инспекций

Ипр Общее количество инспекций, проведенных на опреде-

ленную дату по текущему плану проекта. Эти данные

могут быть получены из отчетов об инспекциях.

Q2 Размер

группы

Ргр Количество членов группы инспекции, включая коор-

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

быть получены из отчетов об инспекциях.