И. Соммервилл - Инженерия программного обеспечения (1133538), страница 101
Текст из файла (страница 101)
В этой главе рассматривается инспектирование программ, т.е. исходный код проверяется на наличие ошибок. Однако метод инспектирования можно также испольэовать для верификации любых текстовых документов, созданных в процессе разработки ПО. Метод инспектирования можно применять к спецификации требований. для детализированного определения системной архитектуры, при разработке структур данных, планировании тестирования и в процессе создания системной документации. 19.2.1.
Инспектирование программ Инспектирование программ — это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки (инспекции) программ впервые сформулирована 1ВМ в 1970-х годах и описана в работах [111, 112]. В настоящее время данный метод верификации программ получил широкое применение. На базе исходного метода инспектирования разработано много других вариантов инспектирования программ [129]. Но все они основываются на базовой идее метода инспектирования, со.
гласно которому группа специалистов выполняет тщательный построчный просмотр и аназиз исходного кода программы. 19. Верификация и аттестация ПО 393 Таблица 19.1. Роли в процессе ииспектироваиия Описание Роль Программист или разработчик, который отвечает за создание про- граммы или документа, а также несет ответственность за неправ. ление дефектов, обнаруженных в процессе инспектирования Находит ошибки, упущения и противоречия в программах и доку- ментах; может также указать на более общие проблемы, находя- щиеся вне сферы действия инспекционной группы Излагает код или документ на собрании инспекционной группы Записывает результаты собрания инспекционной группы Управляет и организует процесс инспектирования.
Докладывает о результатах инспектирования руководству компании Занимается совершенствованием процесса инспектирования, об. новленилми технологических карт, разработкой стандартов и т.п. Автор или владелец Инспектор Рецензент Секретарь Председатель или координатор Руководитель группы Как показано в статье 11391, роль рецензента необязательна. В этом случае исходный процесс инспектирования, в котором реценэироваиие программы является важной со. ставляющей, соответственно изменяется. Такой же вывод содержится в работе [129~. Для начала процесса инспектирования программы необходимы следующие условия.
1. Наличие точной спецификации кода, предназначенного для инспектирования. Без полной спецификации невозможно обнаружить дефекты в проверяемом программном компоненте. 2. Члены инспекционной группы должны хорошо знать стандарты разработки. Я. В распоряжении группы должна была синтаксически корректная последняя версия программы. Нет никакого смысла рассматривать код, который "почти завершен", Основное отличие инспектирования от других видов оцениваиия качества программ состоит в том, что главная его цель- обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в программе, либо несоответствие программы организационным или проектным стандартам.
В противоположносп инспек. тированию другие методы анализа программ основное вннмание уделяют организационным вопросам, временному графику работ, затратам, сравнению с промежуточными контрольными элементами или оценке соответствия ПО определенным целям органиэации- разработчика. Процесс инспектирования — это формализованный процесс, выполняемый небольшой группой специалистов, состоящей не более чем из четырех человек. Члены группы системно анализируют программу и определяют возможные дефекты. Согласно исходной концепции метода инспектирования члены группы должны выполшпь следующие роли: автора, рецензента, инспектора и координатора. Рецензент "озвучивает" программный код, инспектор прове ряет код с помощью тестов, координатор отвечает за органиэацию процесса.
По мере накопления опыта инспектирования в организациях могут появляться другие предложения по распределению ролей в группе. В ходе обсулщения результатов использования инспектирования, внедренного в процесс разработки программ в компании Нем!есг-Рас1шгд, в статье 11331 предлагается шесть ролей (табл. 19.1). Одно лицо может исполюпь несколько ро.
лей, поэтому количество членов в группе инспектирования может варьироваться. $94 Часть 1Г. Верификация и атгестация На рис. 19.4 показан общий процесс инспектирования. Он адаптирован к требованиям организациИ, использующих инспектирование программ. Ркс. 19 4. Процесс инслскэсироваяил Координатор составляет план инспектирований, подбирает инспекционнукз группу. организует собрание и )беждается, что программа и сс спецификация закончены.
Программа, предназначенная для игсспсктироэання, передается на рассмотрение инспекционной группе, где автор программы описывает се назначение (этап предварителыюго просмотра). После это. го следует этап индивидуальной подготовки, па котором каждый член инспекционной группы изучает программу и сс спецификацию и вьшвляст дефекты в программном коде. Сам процесс инспектировании должен быть относительно коротким (не более двух часов) и сосредоточенным исключительно на выявлении дефектов, аномалий и несоответствий стандартам. Инспекционная группа не должна предлагать способы исправления обнаруженных дефектов или рекомепловать закис либо изменения в других программных компонентах.
После инспектирования автор изменяет программу, исправляя обнаруженные ошибки. Нэ этапе доработки координатор принимает решение о том. необходимо ли повторно проводить инспектирование. Если повтор1юго инспектирования не требуется, все обнаруженные дефекты документально фиксируются и документ с рсзультатаии инспектиро. ванна угверждастся председателем. Процесс инспектирования должен проводиться с учетом технологической карты, опи- сывающеИ возможные ошибки программирования.
Карта разрабатывается квалифицированнымн специалистами и ре~улярпо обновляется по мере накопления опыта в процессе инспектирования. Для разных языков программирования составляютсл разные техноло. гические карты. Технологические карты, составленные для разных языков программирования, различаются между собой, поскольку учитывают возможности проверки, которую обеспечивают компиляторы языков. Например, компилятор языка Ада проверяет количество параметров функций, а компилятор языка С вЂ” нет.
Ошибки, которые можно выявить в процессе инспектирования, перечислены в табл.19.2. Подчеркнем, что каждая организация должна разрабатывать собственные технологические карты для инспектирования, которые бы основывались на стандартах и опыте данной организации и обновлялись по мере обнаружения новых типов программных дефектов [129). В процессе инспслтирования организация накапливает определенный опыт, поэтому результаты инспектирования можно использовать для улучшения всего процесса разработки ПО.
В ходе инспектирования выполняется анализ обнаруженных дефектов. Группа инспектирования и авторы инспектируемого кода определяют причины возникновения дефектов. Чтобы подобные дефекты не возникали в будущих системах. необходимо по возможности устранить причины возникновения дефектов, что означает внесение изменений в процесс разработки программных систем. 19. Верификация и аттестация ПО 395 Таблица 19.2. Ошибки, выявляемые при инспектировании Вопросы, помогающие выявлять ошибки Класс ошибок Все ли переменные в программе инициализированы до начала использования их значений? Ошибки данных Все ли константы именованы? Равна ли верхняя граница массива его размеру или на единицу меньше этого размера? Какой разделитель используется для разделения символьных строк? Возможно ли переполнение буфера? Выполняются ли условия для каждого условного оператора? Все ли цикзы завершаются? Правильно ли в составных операторах расставлены скобки? Ошибки управления Все ли выборы выполняютсл в операторах выбора? Ошибки ввода-вывода Используются ли в программе входные переменные? Всем ли выходным переменным перед выводом присваиваютсл значенил? Могут ли какие-нибудь входные данные привести к нарушению системных данных? Все ли вызовы процедур и функций содержат правильное коли- чество параметров? Ошибки интерфейса Согласованы ли типы формальных и фактических параметров? В правильном ли порядке расположены параметры? Если компоненты обращаются к рэзделяелюй памяти, имеют ли они такую же модель структуры разделяемой памяти? Если связаннал структура данных изменяется, правильно лн пе- реопределяются все связи? Ошибки управления памятью Если используется динамичсскал память, правильно лн она рас- пределяется? Происходит ли перераспределение памяти после того, как она больше пе используется? Все лп возможные ошибки рассмотрены в условиях, определяю- щих исключительные ситуации? Ошибки управления исключениями Количество кода, проверяемого за определенное время, зависит от опыта группы инспектирования, языка программирования и предметной области приложения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
