Семинар 6-7. Формальные инспекции (1035845), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

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

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

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

1.2.5. Завершение

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

После собрания ведущий изменяет статус инспектируемых документов в базе данных проекта в соответствии с принятым решением – либо им присваивается статус «Принят», либо «Переработать».

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

1.3. Документирование процесса формальной инспекции

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

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

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

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

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

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

• прохождение фаз планирования, подготовки и обсуждения;

• необходимость переработки документа;

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

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

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

1.3.1. Бланк инспекции

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

Бланк инспекции состоит из трех основных частей:

• титульный лист;

• список контрольных вопросов;

• список несоответствий.

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

1.3.1.1. Титульный лист

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

• слова «формальная инспекция»;

• идентификатор проекта;

• идентификатор типа объекта инспекции, например, «Тест», «Стандарт проекта» и т.п.;

• идентификатор версии бланка инспекции;

• идентификатор конфигурационной базы данных;

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

• место для записи идентификаторов версий каждого из инспектируемых документов;

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

• место для записи идентификаторов версий каждого из исходных документов;

• место для записи даты начала инспекции;

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

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

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

• место для фиксации принятого решения.

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

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

• место для записи даты проведения повторной инспекции;

• место для записи идентификаторов версий каждого из повторно инспектируемых документов;

• место для записи фамилии ведущего повторной инспекции;

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

• место для фиксации принятого решения;

• место для подписи ведущего.

Все перечисленные элементы должны располагаться на одной странице.

1.3.1.2. Список контрольных вопросов

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

• порядковый номер;

• текст вопроса;

• место для положительного ответа («Yes» или «Да»);

• место для отрицательного ответа («No» или «Нет»);

• место для ответа «N/A» или «Неприменимо»;

• место для ссылки на несоответствие.

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

1.3.1.3. Список несоответствий

Список несоответствий должен быть оформлен в виде незаполненной таблицы с тремя колонками:

• для порядкового номера;

• для описания несоответствия;

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

1.3.1.4. Колонтитул

Колонтитул должен включать:

• идентификатор проекта;

• идентификатор версии бланка инспекции;

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

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

1.3.2. Жизненный цикл инспектируемого документа

В процессе формальной инспекции существует 2 типа документов:

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

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

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

В процессе формальной инспекции целевой документ последовательно сменяет несколько состояний. В процессе разработки (до начала формальной инспекции) документ имеет состояние Active (Активный). В этом состоянии автор может обращаться к документу как для чтения, так и для записи. После того, как автор посчитал, что закончил работу над документом, он переводит документ в состояние Ready (Готов). Это означает, что документ готов к формальной инспекции. В состоянии Ready автор еще может обращаться к документу как по чтению, так и по записи. Следующим состоянием документа является Review (формальная инспекция). В это состояние документ помещается на стадии инициализации формальной инспекции. Перевод документа в состояние Review осуществляет ведущий. В состоянии Review доступ к документу возможен только для чтения для всех участников формальной инспекции. Если документ прошел формальную инспекцию (не было обнаружено проблем), то он переходит в состояние Approved (Утвержден). Перевод документа в состояние Approved осуществляет ведущий. В этом состоянии документ доступен только для чтения для всех участников формальной инспекции, а также для остальных участников проекта. Если же после формальной инспекции в целевом документе требуются исправления, документ переводится в состояние Update (Переработка). В этом состоянии автор имеет доступ к документу как для чтения, так и для записи. После переработки документа автор присваивает документу состояние Ready и процесс перехода по состояниям повторяется до тех пор, пока документ не будет переведен в состояние Approved. Если в целевом документе не требуется значительных изменений то, после того как ведущий убедится в том, что необходимые исправления были сделаны, целевой документ может быть переведен в состояние Approved.

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

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

Рис XXX. Жизненный цикл целевого документа в процессе формальной инспекции

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

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

1.4.1. Особенности этапа просмотра инспектируемого кода

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

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

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

Характеристики

Список файлов лабораторной работы