Главная | Обратная связь | Поможем написать вашу работу!

Инспектирование программ

Инспектирование программ – это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки (инспекции) программ впервые сформулирована IBM в 1970-х годах и описана в работах [111, 112]. В настоящее время данный метод верификации программ получил широкое применение. На базе исходного метода инспектирования разработано много других вариантов инспектирования программ [129]. Но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы.

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

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

По мере накопления опыта инспектирования в организациях могут появляться другие предложения по распределению ролей в группе. В ходе обсуждения результатов использования инспектирования, внедренного в процесс разработки программ в компании Hewlett-Packard, в статье [136] предлагается шесть ролей (табл. 19.1). Одно лицо может исполнять несколько ролей, поэтому количество членов в группе инспектирования может варьироваться.

Таблица 19.1. Роли в процессе инспектирования

Роль	Описание
Автор или владелец	Программист или разработчик, который отвечает за создание программы или документа, а также несет ответственность за исправление дефектов, обнаруженных в процессе инспектирования
Инспектор	Находит ошибки, упущения и противоречия в программах и документах; может также указать на более общие проблемы, находящиеся вне сферы действия инспекционной группы
Рецензент	Излагает код или документ на собрании инспекционной группы
Секретарь	Записывает результаты собрания инспекционной группы
Председатель или координатор Руководитель группы	Управляет и организует процесс инспектирования. Докладывает о результатах инспектирования руководству компании Занимается совершенствованием процесса инспектирования, обновлениями технологических карт, разработкой стандартов и т.п.

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

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

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

2. Члены инспекционной группы должны хорошо знать стандарты разработки.

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

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

Рис. 19.4. Процесс инспектирования

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

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

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

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

Технологические карты, составленные для разных языков программирования, различаются между собой, поскольку учитывают возможности проверки, которую обеспечивают компиляторы языков. Например, компилятор языка Ada проверяет количество параметров функций, а компилятор языка С – нет. Ошибки, которые можно выявить в процессе инспектирования, перечислены в табл. 19.2. Подчеркнем, что каждая организация должна разрабатывать собственные технологические карты для инспектирования, которые бы основывались на стандартах и опыте данной организации и обновлялись по мере обнаружения новых типов программных дефектов [129].

Таблица 19.2. Ошибки, выявляемые при инспектировании

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

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

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

1. На этапе предварительного просмотра за один час можно просмотреть приблизительно 500 операторов исходного кода.

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

3. На собрании за один час можно проверить от 90 до 125 операторов.

Эти цифры также подтверждаются данными, полученными во время проведения инспектирования компании AT&T [22].

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

Если команда инспектирования состоит из четырех человек, на проверку 100 строк кода требуется примерно один человеко-день. Считается, что сам процесс инспектирования занимает около часа, плюс каждый член команды тратит 1-2 часа на подготовку к инспектированию. Расходы на тестирование также существенно зависят от количества ошибок в программе. Но, с другой стороны, на инспектирование программы требуется вполовину меньше затрат, чем на эквивалентное тестирование программ.

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

⇐ Предыдущая 130 131 132 133 134135136 137 138 139 Следующая ⇒