Обычно, если предприятие ведет несколько проектов по разработке программных систем, процедура формальной инспекции регламентируется в виде стандарта предприятия. Это позволяет сотрудникам, участвующим в формальных инспекциях, легко адаптироваться при переходе из проекта в проект.
Однако каждый проект может иметь свою специфику. В силу этого рекомендуется разрабатывать для каждого проекта свою процедуру формальной инспекции. Процедура формальной инспекции проекта должна уточнять и дополнять настоящий стандарт с учетом специфики данного проекта и не должна противоречить требованиям настоящего стандарта.
Процедура формальной инспекции проекта должна точно описывать порядок проведения формальных инспекций в данном проекте.
В процедуре формальной инспекции проекта не рекомендуется дублировать общие положения настоящего стандарта, за исключением отдельных, особо важных моментов, таких, например, как изменение статуса инспектируемых документов.
В процедуре формальной инспекции проекта должны быть названы все идентификаторы состояний инспектируемых документов в базе данных проекта, с которыми приходится иметь дело участникам формальной инспекции. Как минимум, должны быть названы идентификаторы состояний, обозначающих:
Процедура формальной инспекции проекта должна регламентировать минимальное количество инспекторов для каждого типа объектов инспекции, если в проекте инспектируются документы различного уровня сложности, требующие участия различного количества инспекторов.
Процедура формальной инспекции проекта должна регламентировать возможные формы проведения повторной инспекции в зависимости от объема и характера изменений, внесенных в объект инспекции. Как правило, допускается упрощение процесса повторной инспекции (выполнение инспекции одним инспектором, отсутствие фазы обсуждения) при внесении в объект инспекции незначительных изменений. Процедура формальной инспекции проекта может предусматривать использование бланка от предыдущей инспекции, если проводится повторная инспекция в сокращенной форме. Процедура формальной инспекции проекта может разрешать ведущему самостоятельно инициировать процесс повторной инспекции (в том же составе участников), даже когда он проводится в полной форме, если это диктуется спецификой проекта.
Бланк инспекции - основной документ, который заполняется в ходе проведения инспекций. Обычно он разрабатывается в ходе разработки стандартов проекта. Для каждого типа объектов инспекции в проекте должен быть разработан свой бланк инспекции.
Бланк инспекции состоит из трех основных частей:
Кроме того, рекомендуется на всех страницах бланка, кроме первой, помещать колонтитул, включающий в себя как минимум номер бланка инспекции.
Титульный лист предназначен для идентификации формальной инспекции и записи решения и обычно включает, как минимум, следующие элементы:
Идентификатор документа состоит из имени файла в базе данных проекта и полного пути к нему. Общие для разных документов элементы идентификации, такие, как путь или имя базы, могут быть вынесены в отдельные поля бланка.
Если процедурой формальной инспекции проекта предусмотрена возможность проведения повторной инспекции с использованием бланка от предыдущей инспекции, то титульный лист также должен включать следующие поля:
Все перечисленные элементы должны располагаться на одной странице.
Список контрольных вопросов должен быть оформлен в виде таблицы, состоящей из следующих колонок:
Контрольные вопросы должны быть сформулированы таким образом, чтобы положительный ответ означал отсутствие несоответствий. Формулировки должны быть понятными, четкими и однозначными.
Список несоответствий должен быть оформлен в виде незаполненной таблицы с тремя колонками:
Колонтитул должен включать:
В процессе формальной инспекции существует 2 типа документов:
Вспомогательные документы возникают в процессе инспекции и могут изменяться в течение процесса инспекции. Титульный лист создается на стадии инициализации. Список обнаруженных проблем создается на стадии подготовки. Список контрольных вопросов заполняется на стадии обсуждения. После завершения процесса инспекции вспомогательные документы помещаются в архив и более не подлежат изменению. Вспомогательные документы хранятся в соответствии с установленными для них сроками.
В процессе формальной инспекции инспектируемый документ последовательно сменяет несколько состояний. В процессе разработки (до начала формальной инспекции) документ имеет состояние Active (Активный). В этом состоянии автор может обращаться к документу как для чтения, так и для записи. После того, как автор посчитал, что закончил работу над документом, он переводит документ в состояние Ready (Готов). Это означает, что документ готов к формальной инспекции. В состоянии Ready автор уже не может изменять документ. Следующим состоянием документа является Review (формальная инспекция). В это состояние документ помещается на стадии инициализации формальной инспекции. Перевод документа в состояние Review осуществляет ведущий. В состоянии Review доступ к документу возможен только для чтения для всех участников формальной инспекции. Если документ прошел формальную инспекцию (не было обнаружено проблем),
то он переходит в состояние Approved (Утвержден). Перевод документа в состояние Approved осуществляет ведущий. В этом состоянии документ доступен только для чтения для всех участников формальной инспекции, а также для остальных участников проекта. Если же после формальной инспекции в целевом документе требуются исправления, документ переводится в состояние Update (Переработка). В этом состоянии автор имеет доступ к документу как для чтения, так и для записи. После переработки документа автор присваивает документу состояние Ready, и процесс перехода по состояниям повторяется до тех пор, пока документ не будет переведен в состояние Approved. Если в инспектируемый документ не требуется вносить значительных изменений, то после того, как ведущий убедится в том, что необходимые исправления были сделаны, целевой документ может быть переведен в состояние Approved.
Инспектируемый документ подлежит исправлению после завершения процесса инспекции. После исправления целевой документ может пройти повторную инспекцию. Таким образом, целевой документ может пройти несколько последовательных инспекций (совершить несколько витков жизненного цикла документов в процессе формальной инспекции). Общий жизненный цикл инспектируемого документа может изображен на Рис 16.1.
(рис 16.1) Жизненный цикл инспектируемого документа в процессе формальной инспекции
Процесс формальной инспекции программного кода подчиняется всем правилам, определенным для абстрактной формальной инспекции, однако, имеет некоторые особенности, связанные, в первую очередь, со структурой инспектируемого программного кода, а также с тем, что обычно инспектируются участки кода, которые невозможно проверить при помощи автоматизированного тестирования, основанного на тестовых примерах.
Выделение ключевых точек и построение или использование таблиц трассировки. Перед началом просмотра исходного кода рекомендуется отметить пункты требований, на соответствие которым проверяется исходный код, а также записать обоснования того, почему эти требования не могут быть проверены в автоматическом режиме. После этого можно переходить к просмотру собственно исходного кода. Все пометки, которые придется вносить в ходе инспектирования в исходный код, необходимо делать не в файле, хранящемся в базе данных проекта, а в его копии, которая потом будет подшита к материалам инспекции. Копия может существовать в том же формате, что и исходный файл, либо может быть распечатана на бумаге или выведена в формат DOC, PDF или аналогичный, допускающий комментирование.
При помощи трассировочных таблиц в исходном коде определяются инспектируемые функции или методы, соответствующие необходимым требованиям. Участки кода выделяются и отмечаются меткой или номером соответствующего требования. Если участок кода соответствует требованиям, то необходимо отметить этот факт либо цветом выделения, либо соответствующим текстовым примечанием. Если участок кода имеет проблемы, этот факт должен быть отражен либо цветом выделения, либо ссылкой на соответствующий пункт списка замечаний в бланке инспекции.
В случае отсутствия трассировочных таблиц требований на исходный код рекомендуется делать пометки, поясняющие, почему именно данный участок кода реализует указанные требования. Такие пометки помогут на этапе обсуждения документа.
Проверка стиля кодирования. Отдельным объектом проверки при формальной инспекции программного кода является стиль кодирования. В большинстве проектов существуют стандарты, описывающие правила оформления исходных текстов программ и файлов данных. Неверный стиль кодирования не влияет на работоспособность программы в целом, но значительно затрудняет сопровождение и поддержку изменений в ходе дальнейшего развития системы. Поэтому отклонения от стиля кодирования в инспектируемых участках кода также должны отмечаться в тексте и в списке замечаний. В некоторых случаях проводят инспекции, целиком направленные на проверку стиля кодирования.
Проверка надежности кода. Иногда рекомендуется проверять наличие участков, гарантирующих робастность, даже если требования прямо не определяют необходимости обработки недопустимых значений. В случае, если потенциально возможна некорректная работа программы из-за отсутствия обработчиков неверных значений, рекомендуется отметить это в списке замечаний.
Распределение ролей. В составе инспекторов желательно иметь хотя бы одного специалиста, представляющего себе особенности выполнения инспектируемого кода в реальной установке системы. Это особенно важно при тестировании встроенных систем, которое проводится на эмуляторах. Во время собрания такой специалист может помогать ведущему определять последовательность рассмотрения замечаний в случае их большого количества.
Управление собранием. При проведении собрания нецелесообразно зачитывать текст инспектируемого файла, как это обычно рекомендуется. Вместо этого ведущему лучше ограничиться перечислением имен функций или методов либо, в случае, если в ходе инспекции проверяется соответствие исходного кода требованиям - перечислением номеров или идентификаторов требований. Инспектора при наличии замечаний по функции или требованию поднимают руку и зачитывают замечания.
Документирование собрания. Для облегчения труда автора инспектируемого документа по исправлению замечаний каждое замечание, признанное на собрании существенным, рекомендуется точно трассировать на строки исходного кода и требований.
Контроль за внесением изменений. При повторной инспекции исходных текстов рекомендуется использовать специализированные инструментальные средства для сравнения файлов. Изменения по итогам инспекции должны вноситься только в те участки, к которым были высказаны замечания. В случае наличия других изменений ведущий вправе назначить новую инспекцию в полной форме.
Процесс формальной инспекции проектной документации подчиняется всем правилам, определенным для абстрактной формальной инспекции, однако, имеет некоторые особенности, связанные, в первую очередь, с тем, что у проектной документации проверяется ее непротиворечивость и полнота. Точное определение этих терминов в рассматриваемом контексте затруднительно, поэтому под непротиворечивостью будем понимать отсутствие в проектной документации требований с противоположным смыслом, согласно которым возможно несколько совершенно различных вариантов реализации программной системы. Под полнотой будем понимать достаточность требований для однозначной реализации поведения системы.
При инспектировании требований к системе, как правило, рассматривается как "внешняя", так и "внутренняя" информация, касающаяся данного документа. Под внешней информацией понимается, в первую очередь, суть технических решений, принятых при разработке системы, те принципы, которые отличают ее от других систем. При этом проверяется согласованность требований с этими принципами. Под внутренней информацией понимается прежде всего внутренняя целостность и непротиворечивость документа - свойства, которые позволяют разрабатывать программный код, лишенный двусмысленностей и нестабильных участков. Главный вопрос, на который должен ответить инспектор при проверке внутренних свойств документа: "Определены ли требования так, чтобы коллектив разработчиков смог работать с ним?" или, иначе, "Эти требования недвусмысленны, полны и авторитетно выражены?". Процесс инспекции может помочь ответить на эти вопросы, а список контрольных вопросов, представленный ниже, может быть использован при проведении инспекций.
Влияние несогласованности документации на процесс разработки. Трассировка изменений на программный код. Первичная инспекция проектной документации, как правило, проводится тогда, когда сама программная система еще не написана. Однако при проведении инспекции изменений в требованиях к уже работающей системе (например, при обновлении ее версии) может потребоваться комплексная одновременная инспекция документации и созданного на ее основе программного кода. При этом может возникнуть ситуация, когда изменения, которые требуется внести в документацию по результатам инспекции, требуют соответствующего изменения в программном коде. Решение этой проблемы достигается использованием трассировочных таблиц.
Несколько иная ситуация возникает в случае, когда комплексная инспекция проводится не после изменения требований, а после завершения всей цепочки изменений - после изменения функциональных требований, архитектуры, низкоуровневых требований и программного кода. В этом случае при обнаружении противоречивых требований необходимо выявить все части программной системы, которые реализуют эти требования. В случае, если разработка этих частей выполнялась разными людьми, могла различаться и трактовка противоречивых требований. В этом случае ликвидация противоречивости может повлечь за собой "волну изменений" в проектной документации и исходных текстах системы. Для того, чтобы избежать "волн изменений" по завершению инспекций, рекомендуется проводить ее поэтапно до начала следующего этапа жизненного цикла или до разработки документов следующего уровня детализации.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.