Верификация и аттестация программного обеспечения

Министерствообразования Российской Федерации
ГОУ ВПО УральскийГосударственный Технический Университет – УПИ
Кафедравычислительной техники
Верификация и аттестация программного обеспечения
Реферат по курсу
«Введениев специальность»
                                                                                               Выполнил студент гр. X-XXX
IntegratoRR
Преподаватель:
Проф., д.т.н.
С.Л. Гольдштейн
                                                 Екатеринбург,2002
 TOC o h z «Заголовок 3;3» Введение. PAGEREF _Toc29023689 h 3
1. Общиесведения о верификации и аттестации ПО.PAGEREF _Toc29023690 h 4
1.1.Введение в верификацию и аттестацию… PAGEREF _Toc29023691 h 4
2.Верификация и аттестация ПО… PAGEREF _Toc29023692 h 7
2.1.Планирование верификации и аттестации. PAGEREF _Toc29023693 h 7
2.2.Инспектирование программных систем… PAGEREF _Toc29023694 h 8
2.3.Инспектирование программ… PAGEREF_Toc29023695 h 10
2.4.Автоматический статический анализ программ… PAGEREF _Toc29023696 h 11
2.5Метод «чистая комната».PAGEREF_Toc29023697 h 13
3.Тестирование программного обеспечения. PAGEREF _Toc29023698 h 14
3.1.Планирование тестирования. PAGEREF_Toc29023699 h 14
3.2.Тестирование дефектов. PAGEREF _Toc29023700 h 14
3.3.Тестирование сборки. PAGEREF _Toc29023701 h 16
3.4.Инструментальные средства тестирования. PAGEREF _Toc29023702 h 18
4.Аттестация критических систем. PAGEREF _Toc29023703 h 19
4.1.Аттестация безотказности. PAGEREF_Toc29023704 h 19
4.2.Гарантии безопасности. PAGEREF _Toc29023705 h 20
4.3.Верификация и аттестация. PAGEREF_Toc29023706 h 20
Заключение. PAGEREF _Toc29023707 h 22
Литература.PAGEREF _Toc29023708 h 23Введение
Программные системы внастоящее время присутствуют повсеместно: практически любые электронныеустройства содержат программное обеспечение (ПО) того или иного вида. Безсоответствующего программного обеспечения в современном мире невозможнопредставить индустриальное производство, школы и университеты, системуздравоохранения, финансовые и правительственные учреждения. Многие пользователиприменяют ПО для самообразования, для развлечений и т.д. Создание спецификациитребований, разработка, модификация и сопровождение таких систем ПО составляетсуть технической дисциплины инженерия программного обеспечения (softwareengineering, SE).
Даже простые системы ПОобладают высокой степенью сложности, поэтому при их разработке приходитсяприменять весь арсенал технических и инженерных методов. Следовательно, инженерияпрограммного обеспечения – это инженерная дисциплина, где специалистыиспользуют теорию и методы компьютерных наук для успешного решения разного роданестандартных задач. Но, конечно, не каждый проект ПО завершается успешно всилу различных причин. Прогресс заметен: за последние 30 лет ПО очень сильноусложнилось, появились программы, предлагающие пользователям очень большиесервисные возможности для работы с ними.
Следует отметить, чтоинженерия программного обеспечения развивается в основном в соответствии спостановкой новых задач построения больших пользовательских систем ПО дляпромышленности, правительства и оборонного ведомства. С другой стороны, внастоящее время сфера программного обеспечения очень широка: от игр наспециализированных игровых консолях, а также программных продуктов дляперсональных компьютеров до очень больших масштабируемых распределенных систем.
При создании программногопродукта перед инженером встает множество вопросов различного рода, таких как,например, требования к ПО, модели систем, спецификации ПО, надежностьсоздаваемого продукта, и т.д. В данной работе рассматриваются одни из самыхсложных шагов в создании любого программного продукта – верификация иаттестация. В работе дается общее представление о верификации и аттестациипрограммного обеспечения, читатель знакомится с методами статическойверификации, динамической верификации, методами аттестации критических систем. 1. Общие сведения о верификации и аттестации ПО.1.1. Введение в верификацию и аттестацию
Верификацией и аттестацией называются процессыпроверки и анализа, в ходе которых проверяется соответствие программногообеспечения своей спецификации и требованиям заказчиков. Верификация иаттестация охватывают весь цикл жизни ПО – они начинаются на этапе анализатребований и завершаются проверкой программного кода на этапе тестированияпрограммной системы.
Верификация и аттестация –абсолютно разные понятия, однако часто их путают. Для того, чтобы различать их,выведем главное различие между этими терминами. Верификация отвечает на вопрос,правильно ли создана система, а аттестация отвечает на вопрос, правильноли работает система. Из этого следует, что верификация проверяетсоответствие ПО системной спецификации, в частности функциональным и нефункциональнымтребованиям. Аттестация – это более общий процесс. Во время аттестации цельинженера – доказать заказчику, что продукт оправдывает ожидания последнего.Аттестация проводится после верификации.
На ранних этапах разработкиПО очень важна аттестация системных требований. В требованиях очень частовстречаются ошибки, недочеты, упущения, что может привести к несоответствиюпродукта замыслу заказчика. Инженер должен справляться с этой проблемой.Однако, как известно, сложно искоренить все погрешности в требованиях.Отдельные ошибки могут обнаружиться лишь тогда, когда программный продуктреализован.
В процессах верификации иаттестации используются две основные методики проверки и анализа систем:инспектирование ПО и тестирование ПО. Инспектирование ПО подразумевает анализ ипроверку различных представлений системы, например, документации.Инспектирование происходит на всех этапах разработки программной системы.Параллельно с инспектированием может проводиться автоматический анализисходного кода программ и соответствующих документов. Инспектирование иавтоматический анализ – это статические методы верификации и аттестации,поскольку им не требуется исполняемая система. Тестирование ПО есть анализвыходных данных и рабочих характеристик программного продукта для проверкиправильности работы системы. Тестирование – динамический метод верификации иаттестации, так как применяется к исполняемой системе.
На рис. 1.1 показано местоинспектирования и тестирования в процессе разработки ПО. Стрелки указывают на теэтапы процесса разработки, на которых можно применять данные методы.

Инспектирование ПО
Спецификация требований
Высокоуровневая архитектура
Формальная спецификация
Детализированная архитектура
Программа
Прототип
Тестирование программ

Рис. 1.1. Статическаяи динамическая верификация и аттестация
         Согласноэтой схеме, инспектирование можно выполнять на всех этапах разработки системы,а тестирование – в тех случаях, когда создан прототип или исполняемаяпрограмма.  К методам инспектированияотносятся: инспектирование программ, автоматический анализ исходного кода иформальная верификация. Однако статическими методами возможно осуществитьпроверку только на соответствие программ спецификации, с их помощью невозможновыяснить правильность функционирования системы. Кроме того, статическимиметодами нельзя проверить  такиенефункциональные характеристики, как производительность и надежность.Следовательно, для анализа нефункциональных характеристик следует проводитьтестирование системы. В настоящее время, несмотря на  широкое применение инспектирования ПО,преобладающим методом верификации и аттестации все еще остается тестирование.Тестирование – это проверка работы программ с данными, подобными реальным,которые будут обрабатываться в процессе эксплуатации системы.  Неполадки в работе ПО обнаруживаются прианализе выходных данных, среди которых выделяются и исследуются аномальные.
         На разныхэтапах процесса разработки ПО применяют различные виды тестирования. Тестированиедефектов проводится для выявления несоответствий между программнымпродуктом и его спецификацией, которые обусловлены ошибками в программном коде.Такие тесты разрабатываются для выявления ошибок в системе, а не для имитацииее работы. Статистическое тестирование оценивает производительность инадежность программ, а также работу программы при использовании различныхрежимов ее эксплуатации. Тесты разрабатываются с целью имитирования, причемимитируется реальная работа системы с реальными выходными данными. Надежностьфункционирования системы определяется по количеству сбоев, отмеченных в работепрограмм. Производительность оценивается по результатам измерений полного временивыполнения операций и времени отклика системы при обработке тестовых данных.
         Конечно,между этими двумя методами тестирования нет четких границ. Во времятестирования испытатель может получить интуитивное представление о надежностиПО, а во время статистического тестирования есть возможность выявленияпрограммных дефектов.
         Главнаяцель верификации и аттестации  — удостовериться в том, что система «соответствует своему назначению».Соответствие программной системы своему назначению отнюдь не предполагает, чтов ней совершенно не должно быть ошибок. Скорее, система должна хорошосоответствовать тем целям, для которых она планировалась. Уровень необходимой достоверностисоответствия зависит от назначения системы, ожиданий пользователей иусловий на рынке программных  продуктов.
         НазначениеПО. Уровень достоверности соответствия зависит от важности (критичности)разрабатываемого программного продукта по каким-либо критериям. Например, ПОдля медицинской установки «Аппарат сердце-легкие» является суперкритичным, таккак от качества работы системы зависит человеческая жизнь. Можно привестипример систем малой критичности. Это, в частности, опытные образцы программныхсистем, разрабатываемые для демонстрации некоторых новых идей.
         Ожиданияпользователей. Здесь следует отметить, что у большинства пользователей внастоящее время очень низкие требования к программному обеспечению. Это связанос тем, что пользователи привыкли к разнообразным сбоям, которые происходят приработе с ПО, а значит, они не удивляются этому. Они согласны терпеть сбои вработе ПО, если выгода от использования ПО перекрывает недостатки. Однако, всеже, в последнее время терпимость пользователей по отношению к ПО снижается.Создание недоброкачественного ПО становится недопустимым. Теперь фирмы,изготовляющие программные продукты, стремятся уделять больше вниманияверификации и аттестации ПО. Еще один важный момент: условия рынкапрограммных продуктов. При оценке программной системы разработчик должензнать конкурирующие системы, цену, которую покупатель согласен заплатить запродукт и назначенный срок выхода этой системы на рынок. Цель разработчика – недопустить выхода конкурирующей системы на рынок раньше. Если покупатели нежелают приобретать ПО по высокой цене, они, возможно, согласны терпеть большееколичество дефектов таких систем. При определении расходов на верификацию иаттестацию все эти факторы должны учитываться.
         Припроведении верификации и аттестации в системе, как правило, обнаруживаютсяошибки, которые должны исправляться. После исправления ошибок необходимо сновапроверить программу. Для этого можно еще раз выполнить инспектированиепрограммы или повторить тестирование. Разработчик должен знать, что простыхметодов исправления ошибок в программах не существует. Повторное тестированиенеобходимо проводить для того, чтобы убедиться, что сделанные в программеизменения не внесли в систему новых ошибок, поскольку на практике высокийпроцент «исправления ошибок» либо не завершается полностью, либо вносит новыеошибки в программу. При разработке крупных систем каждое повторное тестированиевсей системы обходится очень дорого; при этом для экономии средств определяютсвязи и зависимости между частями системы и проводят тестирование именно этихотдельных частей. 2. Верификация и аттестация ПО2.1. Планирование верификации и аттестации
         Верификацияи аттестация – дорогостоящие процессы. Для сложных систем, например, характернотакое соотношение: половина всего бюджета, выделенного на реализацию системы,тратится на верификацию и аттестацию. Поэтому очевидна необходимостьтщательного планирования верификации и аттестации.
         Планированиеверификации и аттестации должно начинаться как можно раньше. На рисунке 2.1показана модель разработки ПО, учитывающая процесс планирования испытаний.


Рис. 2.1. Планированиеиспытаний в процессе разработки и тестирования,
где
Requirements specification –спецификациятребований
System specification – системнаяспецификация
Systemdesign– проектирование системы
DetailedDesign– детальное проектирование
Acceptancetestplan–планирование приемочных испытаний
Systemintegrationtestplan–планирование тестирования системной сборки
Sub-systemintegrationtestplan– планирование тестирования сборки подсистемы
Moduleandunitcodeandtess–кодирование и тестирование модулей и компонентов
Sub-system integration test– тестированиесборкиподсистем
System integration test – тестированиесистемнойсборки
Acceptance test – приемочныеиспытания
Service– программный продукт.
Изрисунка видно, что процесс верификации и аттестации разделяется на несколькоэтапов, причем на каждом этапе проводится определенный тест.
         В процессе планирования верификации иаттестации необходимо определить соотношение между статическими и динамическимиметодами проверки системы, определить стандарты и процедуры инспектирования,составить план тестирования программ. От типа разрабатываемой системы зависитто, чему следует уделить больше внимания – инспектированию или тестированию.Чем более критична система, тем больше внимания следует уделять статическимметодам верификации.
         Планиспытаний ПО обязательно должен включать в себя: описание основных этаповпроцесса тестирования, возможность отслеживания требований (тестированиеследует спланировать так, чтобы протестировать все требования в отдельности),тестируемые элементы (следует определить все «выходные» продукты процессаразработки ПО, которые необходимо тестировать), график тестирования(составляется временной график тестирования и распределение ресурсов проводитсясогласно этому графику, причем график тестирования привязан к более общемуграфику разработки проекта), процедуры записи тестов (для проверки правильностивыполнения тестов), аппаратные и программные требования, ограничения(попытаться предвидеть все неблагоприятные факторы, влияющие на процессытестирования, например, нехватку средств, персонала…).
         Подобнодругим планам, план испытаний не является неизменным документом. Его следуетрегулярно пересматривать, так как тестирование зависит от процесса реализациисистемы. Например, если реализация какой-либо части систем не завершена, тоневозможно провести тестирование сборки системы. Пересмотр плана позволяетиспользовать сотрудников (не занятых в данный момент) на других работах. 2.2. Инспектирование программных систем
         Системноетестирование программ требует разработки огромного количества тестов, ихвыполнения и проверки. Это значит, что данный процесс достаточно трудоемкий идорогостоящий. Каждый тест способен обнаружить в программе одну, реже несколькоошибок. Причина такого положения заключается в том, что сбои в работе,происходящие из-за ошибок в системе, часто приводят к разрушению данных.Поэтому сложно сказать, какое количество ошибок «ответственно» за сбой всистеме.
         Инспектированиепрограмм не требует от последних быть завершенными, поэтому инспектироватьможно даже на начальных стадиях разработки. Во время инспектированияпроверяется исходное представление системы. Это может быть модель системы,спецификация или программа, написанная на языке высокого уровня. Обнаружениеошибок достигается путем использования знаний рассматриваемой системы исемантики ее исходного представления. Каждую ошибку можно рассмотреть отдельно,не обращая внимания на то, как она влияет на поведение системы.
         Доказано,что инспектирование является эффективным методом обнаружения ошибок, причем онозначительно дешевле экстенсивного тестирования. Инспектированием можнообнаружить более 60% всех ошибок, а при более формальном подходе (используяматематические методы) – более 90%. Процесс инспектирования также может оценитьдругие качественные характеристики систем: соответствие стандартам,переносимость и удобства сопровождения.
         Всистемных компонентах выявление ошибок путем инспектирования более эффективно,чем путем тестирования. Во-первых, за один сеанс инспектирования можнообнаружить очень многие дефекты программного кода; при применении тестированияза один сеанс обнаруживается обычно лишь одна ошибка, поскольку ошибки могутпривести к полному останову (отказу) системы, а эффекты ошибок могутнакладываться друг на друга. Во-вторых, инспектирование использует знание опредметной области и языке программирования. Специалист, проводящийинспектирование, должен знать типы ошибок, что дает возможность сосредоточитьсяна конкретных видах дефектов.
         Понятно,что инспектирование не может заменить тестирование. Инспектирование лучшеприменять на начальных стадиях для выявления наибольшего количества ошибок.Инспектированием проверяют соответствие ПО его спецификации, но таким способом,например, невозможно оценить динамическое поведение системы. Более того,нерационально инспектировать законченные системы, собранные из несколькихподсистем. На этом уровне возможно только тестирование.
         Ошибочнополагать, что тестирование и инспектирование являются конкурирующими методамиверификации и аттестации. У каждого из них есть свои преимущества и недостатки.Следовательно, в процессе верификации и аттестации инспектирование итестирование следует использовать совместно.
         Иногдапри инспектировании в организации возникают трудности. Эксперты, имеющиебольшой опыт в тестировании программ, неохотно соглашаются с тем, чтоинспектирование является более эффективным методом устранения дефектов системы,чем тестирование. Менеджеры относятся к этим технологиям с недоверием, потомучто внедрение инспектирования требует дополнительных расходов. Конечнаяэкономия средств при применении инспектирования достигается только благодаряопыту проводящих его специалистов. 2.3. Инспектирование программ
         Инспектированиепрограмм – это просмотр и проверка программ с целью обнаружения в них ошибок.Идея формализованного процесса проверки программ была сформулированакорпорацией IBMв 1970-х годах. В настоящее время данный методверификации получил широкое распространение. На его базе разработано множестводругих методов, но все они основываются на базовой идее метода инспектирования,согласно которому группа специалистов выполняет тщательный построчный просмотри анализ исходного кода программы. Главное отличие инспектирования от другихметодов оценивания качества программ состоит в том, что его цель – обнаружениедефектов, а не исследование общих проблем проекта. Дефектами являются либоошибки в исходном коде, либо несоответствия программы стандартам.
         Процессинспектирования – формализованный. В нем принимает участие небольшая группалюдей (обычно не более, чем четыре человека). У каждого в группе есть свояроль. Обязательно должны присутствовать: автор, рецензент, инспектор,координатор. Рецензент «озвучивает» программный код, инспектор проверяет его,координатор отвечает за организацию процесса. По мере накопления опытаинспектирования в организациях могут появляться другие предложения пораспределению ролей в группе (например, одно лицо может исполнять несколькоролей, поэтому количество членов в группе инспектирования может варьироваться).
         Дляначала процесса инспектирования программы необходимы следующие условия: наличиеточной спецификации кода (без полной спецификации невозможно обнаружить дефектыв проверяемом программном компоненте); члены инспекционной группы должны хорошознать стандарты разработки; в распоряжении группы должна быть синтаксическикорректная последняя версия программы (нет смысла рассматривать код, который«почти завершен»).

Планирование
Предварит.
просмотр
Индивидуальн.
подготовка
Собрание инспекционн.
группы
Исправление ошибок
Доработка

Рис. 2.2. Процессинспектирования
На рис. 2.2 показан общий процесс инспектирования. Онадаптирован к требованиям организаций, использующих инспектированиепрограмм. 
         Сампроцесс инспектирования должен быть относительно коротким (не более двух часов)и сосредоточенным только на выявлении дефектов, аномалий и несоответствийстандартам. Инспекционная группа не должна предлагать способы исправлениядефектов или рекомендовать какие-либо изменения в других программныхкомпонентах.
         Послеинспектирования автор изменяет программу, исправляя обнаруженные ошибки. Наэтапе доработки координатор принимает решение о том, необходимо ли повторноеинспектирование. Если повторное инспектирование не требуется, все обнаруженныедефекты фиксируются документально.
         Впроцессе инспектирования организация накапливает определенный опыт, поэтомурезультаты инспектирования можно использовать для улучшения всего процессаразработки ПО. В ходе инспектирования выполняется анализ обнаруженных дефектов.Группа инспектирования и авторы инспектируемого кода определяют причинывозникновения дефектов. Чтобы подобные дефекты не возникали в будущих системах,необходимо по возможности устранить причины возникновения дефектов, чтоозначает  внесение изменений в процессразработки программных систем.
         Обеспечениеинспектирования ПО требует квалифицированного управления и правильногоотношения к результатам его проведения. Инспектирование – открытый процессобнаружения ошибок, когда ошибки, допущенные отдельным программистом,становятся известны всей группе программистов. Менеджеры должны четкоразграничивать инспектирование программного кода и оценку кадров. При оценкепрофессиональных качеств ни в коем случае нельзя учитывать ошибки, обнаруженныев процессе инспектирования. Руководителям инспекционных групп необходимо пройтитщательную подготовку, чтобы грамотно управлять процессом и совершенствоватькультуру отношений, которая гарантировала бы поддержку в процессе обнаруженияошибок и отсутствие каких-либо обвинений в связи с этими ошибками. 2.4. Автоматический статический анализ программ
         Статические анализаторыпрограмм – это инструментальные программные средства, которые сканируютисходный текст программы и выявляют возможные ошибки и противоречия. Дляанализаторов не требуется исполняемая программа. Они выполняют синтаксическийразбор текста программы, распознают различные типы операторов. С помощьюанализаторов можно проверить, правильно ли составлены операторы, сделать выводыотносительно потока управления в программе и во многих случаях вычислитьмножество значений данных, используемых программой. Анализаторы дополняютсредства обнаружения ошибок, предоставляемые компилятором языка.
         Цельавтоматического статического анализа – привлечь внимание проверяющего каномалиям в программе, например, к переменным, которые используются безинициализации или инициализированы, но в программе не использовались.
         Статическийанализ состоит из нескольких этапов.
1.     Анализ потока управления.Идентификация и выделениециклов, их точек входа и выхода, выявление неиспользуемого кода.
2.     Анализ использования данных.Проверка переменных впрограмме. На этом этапе также можно выявить условные операторы с избыточнымиусловиями.
3.     Анализ интерфейса.Проверкасогласованности различных частей программы, правильности объявления процедур иих использования. Данный этап оказывается лишним, если используется язык сострогим контролем типов.
4.     Анализ потоков данных.Определяютсязависимости между входными и выходными переменными. Хотя этот анализ невыявляет конкретных ошибок, он дает полный список значений, используемых впрограмме. Следовательно, легко обнаруживается ошибочный вывод данных.
5.     Анализ ветвей программы.На этом этапесемантического анализа определяются все ветви программы и выделяются операторы,исполняемые в каждой ветви. Анализ ветвей программы существенно помогаетразобраться в управлении программой и позволяет проанализировать каждую ветвьотдельно.
Следует отметить, чтоанализ потока данных и анализ ветвей программы генерируют огромное количествоинформации. Эта информация не выявляет конкретных ошибок, а представляетпрограмму в разных аспектах. Из-за огромного количества генерируемой информацииэти этапы иногда исключают из процесса анализа и используют только на раннихстадиях для обнаружения аномалий в разрабатываемой программе. Статическиеанализаторы особенно полезны в тех случаях, когда используются языкипрограммирования, подобные С. В языке С нет строгого контроля типов, и потомупроверка, осуществляемая компилятором языка С, ограничена. В этом случаесредствами статического анализа выявляется широкий спектр ошибок, что особенноважно при разработке критических систем.
     Анализ с помощью инструментальных средств не может заменитьинспектирования, так как существуют такие типы ошибок, которые невозможновыявить с помощью статического анализа. Например, анализаторы способныобнаружить необъявленные переменные, однако они не смогут обнаружитьнеправильного присвоения. Конечно, для таких языков, как С, статический анализявляется эффективным методом обнаружения ошибок. Но в современных языках (типа Java)удалены конструкции, способствующие появлению многих ошибок. Все переменныедолжны быть объявлены, отсутствуют операторы безусловного перехода, вследствиечего маловероятно случайное создание неиспользуемого кода, и осуществляетсяавтоматическое управление памятью. 2.5 Метод «чистая комната».
     При разработке ПО методом «чистая комната» для устранения дефектовиспользуется процесс строгого инспектирования. Цель данного метода – созданиеПО без дефектов. Название «чистая комната» взято по аналогии с производствомкристаллов полупроводников, где выращивание кристаллов без дефектов происходитв сверхчистой атмосфере (чистых комнатах).
     В разработке ПО методом «чистая комната» выделяют пять ключевыхмоментов:
1.              Формальная спецификация. Разрабатывается формальная спецификация. Длязаписи спецификации используется модель состояний, в которой отображены откликисистемы.
2.              Пошаговая разработка. Разработка ПО разбивается на несколько этапов,которые проверяются методом «чистая комната» независимо друг от друга.
3.              Структурное программирование. Используется ограниченное количество управляющихконструкций. Процесс разработки программы – это процедура поэтапной детализацииспецификации.
4.              Статическая верификация. Проверка статическим методом строгогоинспектирования ПО. Для отдельных элементов тестирование кода не проводится.
5.              Статическое тестирование системы. На каждом шаге проводится тестированиестатическими методами, позволяющими оценить надежность программной системы.
На первых этапах разработки ПО методом «чистаякомната» реализуются наиболее критичные для заказчика системные функции. Менееважные системные функции добавляются на последующих этапах. Таким образом, узаказчика есть возможность испытать систему до полной ее реализации.
  Процесс разработки ПО методом «чистая комната» планируется такимобразом, чтобы обеспечить строгое инспектирование программ, котороесопровождается строгими математическими доказательствами согласованности икорректности преобразований.
Обычно разработкой большихсистем методом «чистая комната» занимаются три группы разработ