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

Обновлено: 05.07.2024

Файл "Семинар 6-7. Формальные инспекции" внутри архива находится в следующих папках: Лабораторная работа 7, документация по тестированию, проработка, 06sem-giveaway. Документ из архива "Лабораторная работа 7", который расположен в категории " ". Всё это находится в предмете "технология проектирования" из раздела "", которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "лабораторные работы", в предмете "технология проектирования" в общих файлах.

Онлайн просмотр документа "Семинар 6-7. Формальные инспекции"

Текст из документа "Семинар 6-7. Формальные инспекции"

1.1. Задачи и цели проведения формальных инспекций

Такие экспертные исследования обычно называют инспекциями или просмотрами. Существует два типа инспекций – неформальные и формальные.

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

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

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

1.2. Этапы формальной инспекции и роли ее участников

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

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

1.2.1. Инициализация

Руководитель проекта или его заместитель запрашивает из базы, хранящей все данные проекта (например, из системы конфигурационного управления, см. раздел XXX), список объектов, готовых к инспекции, выбирает объект инспекции, затем назначает участников формальной инспекции: автора, ведущего и одного или нескольких инспекторов. Ведущий также обычно выполняет роль инспектора; остальные участники выполняют только одну роль. На роль ведущего или инспектора не допускается назначать сотрудников, участвовавших в разработке объекта инспекции.

Обычно в роли автора выступает один из разработчиков объекта инспекции, но возможны ситуации, когда разработчик недоступен – например, переведен в другой проект или находится в отпуске. Тогда на роль автора назначается сотрудник, который будет исправлять обнаруженные несоответствия в инспектируемых документах. При инспектировании документов, разработанных Заказчиком, автор может не назначаться.

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

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

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

1.2.2. Планирование

Как только процесс формальной инспекции был инициирован, ведущий проверяет, что инспектируемые документы размещены в базе данных проекта, а их статус соответствует готовности к формальной инспекции. Если это не так, инспекция откладывается.

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

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

Ведущий должен оценить время, необходимое инспекторам для подготовки, и продолжительность обсуждения. Время, отводимое на этап подготовки, не может быть менее одного часа. Также ведущий должен определить дату, время и место обсуждения, если оно будет проходить в форме собрания. При этом может потребоваться согласование с другими участниками инспекции. Если оценка продолжительности обсуждения в форме собрания превышает 2 часа, то необходимо запланировать несколько собраний, каждое из которых будет длиться не более двух часов.

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

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

1.2.3. Подготовка

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

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

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

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

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

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

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

Если мнения участников по высказанному замечанию расходятся, то ведущий управляет дискуссией, последовательно предоставляя слово всем желающим высказаться, причем автор пользуется правом внеочередного предоставления слова. Если в результате дискуссии изменилась формулировка замечания, то ведущий записывает эту новую формулировку, затем зачитывает ее и, если все участники с ней согласны, продолжает продвижение по документу.

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

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

Все участники обязаны уважительно относиться к оппонентам, не перебивать говорящего и высказываться тогда, когда ведущий предоставит им слово. Не допускаются параллельные обсуждения узким составом – каждый участник обязан адресовать свои высказывания всему собранию, а не соседу.

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

1.14.1. Задачи и цели проведения формальных инспекций

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

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

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

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

Рис. 1.16 Место формальной инспекции в проекте по разработке программной системы

1.14.2. Этапы формальной инспекции и роли ее участников

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

Руководитель проекта или его заместитель запрашивает из базы, хранящей все данные проекта (например, из системы конфигурационного управления, см. тему 11) список объектов, готовых к инспекции, выбирает объект инспекции, затем назначает участников формальной инспекции: автора, ведущего и одного или нескольких инспекторов. Ведущий также может выполнять роль инспектора; остальные участники выполняют только одну роль. На роль ведущего или инспектора не допускается назначать сотрудников, участвовавших в разработке объекта инспекции.

Обычно в роли автора выступает один из разработчиков объекта инспекции, но возможны ситуации, когда разработчик недоступен – например, переведен в другой проект или находится в отпуске. Тогда на роль автора назначается сотрудник, который будет исправлять обнаруженные несоответствия в инспектируемых документах. При инспектировании документов, разработанных заказчиком, автор может не назначаться.

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

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

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

Этапы формальной инспекции и роли ее участников

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

Обычно в роли автора выступает один из разработчиков объекта инспекции, но возможны ситуации, когда разработчик недоступен – например, переведен в другой проект или находится в отпуске. Тогда на роль автора назначается сотрудник, который будет исправлять обнаруженные несоответствия в инспектируемых документах. При инспектировании документов, разработанных заказчиком, автор может не назначаться.

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

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

Улучшается архитектура приложения за счет того, что каждую часть системы продумали как минимум 2 человека.
Программист изначально мотивируется писать более качественный код, зная, что его будут просматривать.
Распространяются знания о проекте среди команды.
Происходит обмен программистским опытом.
Вырабатывается единый стиль кодирования в команде.

Можно выделить следующие виды обзоров кода:

Формальная инспекция кода.
Неформальная инспекция кода (другое название – анализ кода).
Чтение кода.
Парное программирование.

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

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

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

Более подробный пример формальной инспекции можно найти здесь.

Достоинства:

Очень высокая эффективность.
Благодаря составляемому списку ошибок легко проверить их устранение.
Инспекционные отчеты можно использовать в дальнейшем, например, для анализа характерных проблем.

Недостатки:

Сложная формальная процедура, требующая времени.
Отвлечение как минимум 3-х человек (координатор, автор кода и инспектор) от их основной работы.
Большое психологическое давление на автора кода.

Неформальная инспекция кода

Неформальная инспекция в отличие от формальной не имеет четких правил. Например, это может происходить так: автор кода, перед его публикацией, подзывает первого попавшегося разработчика за свой компьютер, где показывает и рассказывает то, что написал. Проверяющий пытается вникнуть в написанное, задает вопросы и высказывает свои соображения. Безусловно, при таком способе эффективность будет не сильно высокая, зато такая инспекция отнимает мало времени.

Достоинства:

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

Недостатки:

Невысокая эффективность за счет поверхностного знакомства проверяющего с кодом.
Для проверки приходится отвлекать кого-нибудь от основной работы, что может сильно раздражать.
Критика кода может плохо восприниматься автором, причем как обоснованно (например, из-за незначащих придирок проверяющего), так и необоснованно (например, автору трудно признавать свои ошибки).

Чтение кода

Чтение кода – это самостоятельное изучение разработчиком чужого кода без присутствия автора. Данная практика является самой простой и распространенной из описанных здесь – думаю, любому разработчику так или иначе приходило читать чужой код. Не говоря уж про мир Open Source, где это зачастую единственный доступный метод обзора кода.

Достоинства:

Простота.
Высокая доступность – не требуется синхронизация во времени и пространстве.

Недостатки:

Парное программирование

Парное программирование является экстремальным методом обзора кода – обзор, осуществляемый постоянно: два разработчика за одним компьютером, за одним комплектом мыши и клавиатуры, вместе решают одну задачу. Широкое распространение парное программирование получило после появления методологии экстремального программирования, хотя активно использовалось и до этого. Часто парное программирование используется спонтанно: думаю, многим приходилось подходить к другому разработчику за компьютер, чтобы помочь решить сложную задачу.

Достоинства:

Высокая эффективность, особенно в плане обмена опыта и распространения знания о проекте.
Высокая концентрация на работе – работая в паре, разработчики гораздо меньше отвлекаются на посторонние вещи.
Естественное ограничение количества одновременно разрабатываемых командой задач – сконцентрированность на меньшем количестве задаче обеспечивает более качественную и быструю их реализацию, что позволяет непрерывно поставлять новые версии продукта.
Нет психологических вопросов присущих инспекциям – оба авторы кода, и оба одновременно его же инспекторы, предложения по улучшению воспринимаются именно как предложения, а не критика.
Повышение командного духа – успехи, достигнутые в паре, больше объединяют людей, чем индивидуальные достижения.
Отлично подходит для обучения новичков.

Недостатки:

Что выбрать?

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

Читайте также: