Национальный исследовательский ядерный университет «МИФИ»
Опубликован: 28.11.2007 | Доступ: свободный | Студентов: 5123 / 786 | Оценка: 4.53 / 3.65 | Длительность: 22:18:00
ISBN: 978-5-94774-825-3
Специальности: Программист, Тестировщик
Лекция 10:

Формальные инспекции (окончание)

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

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

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

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

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

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

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

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

16.2.2. Особенности этапа проведения собрания

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

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

16.2.3. Особенности этапа завершения и повторной инспекции

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

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

16.3. Формальные инспекции проектной документации

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

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

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

  1. Является ли каждое требование совершенно недвусмысленным? (Если требование прочесть подряд несколько раз, делая ударение сначала на первом слове, потом - на втором, затем - на третьем и т.д., будет ли при этом меняться смысл этого требования?)
  2. Существует ли для каждого из установленных требований некоторый компетентный специалист, который сможет сказать после завершения разработки, выполнено ли данное требование или нет? Определен ли метод решения этой проблемы в документации по требованиям?
  3. Существует ли какие-либо не установленные или отсутствующие требования?
  4. Существуют ли среди заданных такие требования, которые не являются необходимыми?
  5. Если существуют какие-либо конфликтующие требования, известно ли понятное решающее правило, в каких ситуациях какому требованию следует отдавать предпочтение?

16.3.2. Особенности этапа завершения

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

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

Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

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

Александр Медов
Александр Медов

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