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

Реферат

по дисциплине «Технологии разработки программного обеспечения»

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

Содержание Введение

1. Общие сведения о верификации и аттестации

2. Планирование верификации и аттестации

3. Инспектирование программных систем

4. Автоматический статический анализ программ

5. Метод «чистая комната»

6. Верификация и аттестация критических систем Заключение Литература

Введение

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

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

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

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

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

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

Аттестация программной системы — более общий процесс, целью которого является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, аттестация — это проверка соответствия системы ожиданиям заказчика, поэтому она проводится после верификации. Если посмотреть на эти процессы с точки зрения вопроса, на который они дают ответ, верификация отвечает на вопрос — «Выполнено ли программное обеспечение правильно?» или «Соответствует ли разработанная система требованиям?», а аттестация — «Правильно ли работает система?» или «Соответствует ли разработанная система ожиданиям заказчика?».

Поскольку основной задачей верификации, как и аттестации, является контроль качества программного обеспечения, необходимо обратиться к этому понятию. Стандарт ISO 9126 [21−24] предлагает учитывать три разных точки зрения при рассмотрении качества ПО: точку зрения разработчиков, которые воспринимают внутреннее качество ПО, точку зрения руководства и аттестации ПО на соответствие сформулированным к нему требованиям, в ходе которой определяется внешнее качество ПО, и точку зрения пользователей, ощущающих качество ПО при использовании. Во всех трех случаях для описания качества используется предложенная МакКолом многоуровневая модель, состоящая из целей или факторов, атрибутов или критериев и метрик качества. Цели (факторы) позволяют на верхнем уровне определять основные характеристики, которые ПО должно иметь или уже имеет. Каждый фактор состоит из набора атрибутов (критериев), позволяющих качественно описать желаемые или полученные характеристики более детально. Каждый атрибут поддерживается набором метрик, которые позволяют количественно оценивать наличие соответствующей характеристики. Для двух точек зрения — внешнего качества и внутреннего качества — в рамках ISO 9126 предложена модель качества, схематически представленная на Рис. 1

Рисунок 1. Факторы и атрибуты внешнего и внутреннего качества ПО по ISO 9126

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

Тестирование (testing)—это процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки. Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки. Отладка — сложный процесс и это обусловлено следующими причинами: от программиста требуются глубокие знания специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики различных ошибок, методик отладки и соответствующих программных средств, так же сложность отладки может быть обусловлена взаимовлиянием ошибок в разных частях программы. Найденная программистом ошибка исправляется, после чего проводится повторное тестирование, так как в процессе исправления не исключается возможность появления новых ошибок. Полное повторное тестирование занимает много времени и как следствие является дорогостоящим, поэтому система разбивается на отдельные части и повторно тестируется только та часть, а так же связанные с нею другие части, где обнаружена ошибка.

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

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

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

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

Ш участника группы заранее выдается листинг программы и спецификация на нее;

Ш программист рассказывает о логике работы программы и отвечает на вопросы инспекторов;

Ш программа анализируется про списку вопросов для выявления исторически сложившихся ошибок программирования.

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

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

1. Контроль обращений к данным

* Все ли переменные инициализированы?

* Не превышены ли максимальные (или реальные) размеры массивов и строк?

* Не перепутаны ли строки со столбцами при работе с матрицами?

* Присутствуют ли переменные со сходными именами?

* Используются ли файлы? Если да, то при вводе из файла проверяется ли завершение файла?

* Соответствуют ли типы записываемых и читаемых значений?

* Использованы ли нетипизированные переменные, открытые массивы, динамическая память? Если да, то соответствуют ли типы переменных при «наложении» формата? Не выходят ли индексы за границы массивов?

2. Контроль вычислений

* Правильно ли записаны выражения (порядок следования операторов)?

* Корректно ли выполнены вычисления над неарифметическими переменными?

* Корректно ли выполнены вычисления с переменными различных типов (в том числе с использованием целочисленной арифметики)?

* Возможно ли переполнение разрядной сетки или ситуация машинного нуля?

* Соответствуют ли вычисления заданным требованиям точности?

* Присутствуют ли сравнения переменных различных типов?

3. Контроль передачи управления

* Будут ли корректно завершены циклы?

* Будет ли завершена программа?

* Существуют ли циклы, которые не будут выполняться из-за нарушения условия входа? Корректно ли продолжатся вычисления?

* Существуют ли поисковые циклы? Корректно ли отрабатываются ситуации «элемент найден» и «элемент не найден»?

4. Контроль межмодульных интерфейсов

* Соответствуют ли списки параметров и аргументов по порядку, типу, единицам измерения?

* Не изменяет ли подпрограмма аргументов, которые не должны изменяться?

* Не происходит ли нарушения области действия глобальных и локальных переменных с одинаковыми именами?

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

4. Автоматический статический анализ программ Для сканирования исходного текста программы и выявления в нем возможных ошибок и противоречий используются такие инструментальные программные средства как статические анализаторы программ. Целью автоматического статического анализа является привлечение внимания проверяющего к аномалиям в программе, например к переменным, которые используются без инициализации или совсем не используются, или к данным, значения которых превышают заданное, и т. п. Статический анализ кода (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ. В большинстве случаев анализ производится над какой-либо версией исходного кода, хотя иногда анализу подвергается какой-нибудь вид объектного кода. При статическом анализе осуществляется проверка синтаксиса, статической семантики и стиля кодирования программ, а также некоторые другие сопутствующие анализу действия. В зависимости от используемого инструмента глубина анализа может варьироваться от определения поведения отдельных операторов до анализа, включающего весь имеющийся исходный код. Способы использования полученной в ходе анализа информации также различны — от выявления мест, возможно содержащих ошибки (утилиты типа lint), до формальных методов, позволяющих математически доказать какие-либо свойства программы (например, соответствие поведения спецификации).

Принципы статического анализа.

Большинство компиляторов (например, GNU C Compiler) выводят на экран «предупреждения» (англ. warnings) — сообщения о том, что код, будучи синтаксически правильным, скорее всего, содержит ошибку. Это простейший статический анализ. У компилятора есть много других немаловажных характеристик — в первую очередь скорость работы и качество машинного кода, поэтому компиляторы проверяют код лишь на очевидные ошибки. Статические анализаторы предназначены для более детального исследования кода.

Типы ошибок, обнаруживаемых статическими анализаторами.

· Неопределенное поведение — неинициализированные переменные, обращение к NULL-указателям. О простейших случаях сигнализируют и компиляторы.

· Нарушение алгоритма пользования библиотекой. Например, для каждого fopen нужен fclose. И если файловая переменная теряется раньше, чем файл закрывается, анализатор может сообщить об ошибке.

· Типичные сценарии, приводящие к недокументированному поведению. Стандартная библиотека Си известна большим количеством неудачных технических решений. Некоторые функции, например, gets, в принципе небезопасны.

· Переполнение буфера — когда компьютерная программа записывает данные за пределами выделенного в памяти буфера.

· Ошибки в повторяющемся коде. Многие программы исполняют несколько раз одно и то же с разными аргументами. Обычно повторяющиеся фрагменты не пишут с нуля, а размножают и исправляют.

· Ошибки форматных строк — в функциях наподобие printf могут быть ошибки с несоответствием форматной строки реальному типу параметров.

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

Статический анализ состоит из нескольких этапов.

1. Анализ потока управления. Идентификация и выделение циклов, их точек входа и выхода, выявление неиспользуемого кода.

2. Анализ использования данных. Проверка переменных в программе. На этом этапе также можно выявить условные операторы с избыточными условиями.

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

4. Анализ потоков данных. Определяются зависимости между входными и выходными переменными. Такой анализ не позволяет выявить конкретных ошибок, он дает полный список значений, используемых в программе. Следовательно, легко обнаруживается ошибочный вывод данных.

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

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

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

5. Метод «чистая комната»

Cleanroom Software Engineering (методология «чистой комнаты») — процесс разработки программного обеспечения, предназначенный для создания программного обеспечения с сертифицируемым уровнем надёжности. Основной принцип cleanroom состоит в том, что предупреждение дефектов лучше, чем их устранение. Название Cleanroom («чистая комната») взято из электронной промышленности — так называются помещения с высокой степенью защиты от загрязнений, позволяющие предотвратить появление дефектов в процессе производства полупроводников. Впервые процесс был применён в середине-конце 80-х годов.

Основные принципы метода.

· Разработка программного обеспечения основывается на формальных методах

· Инкрементальная реализации в рамках статистического контроля качества

· Статистическое тестирование

· Формальная верификация Наиболее важные для заказчика системные функции проверяются наибольшее количество раз. Метод «чистой комнаты» позволяет выявить дефекты еще до исполнения программы. Эти дефекты исправляются в процессе разработки ПО. Такой метод наиболее эффективен при разработке систем с наивысшим уровнем надежности.

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

При создании КС, важен всесторонний анализ разрабатываемой системы. Имеется пять типов анализа системы, обязательных для КС:

1. Анализ правильности функционирования системы

2. Анализ возможности изменения и понятности системной архитектуры

3. Анализ соответствия алгоритма обработки и структуры данных определенному в спецификации поведению системы

4. Анализ согласованности программного кода, алгоритмов и структур данных.

5. Анализ адекватности тестовых сценариев системным требованиям.

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

Заключение

В этой работе были рассмотрены вопросы верификации и аттестации ПО. Было выявлено, что это очень сложные шаги в разработке любого продукта, требующие от инженеров внимания, высочайшей квалификации, терпения, а от организации — больших вложений средств. Однако какими бы дорогостоящими не были эти процессы, экономическая выгода от их использования очевидна, ведь система без сбоев не наносит убытков. Следует помнить, что аварийные ситуации — редкие события (особенно в КС), поэтому практически невозможно смоделировать их во время тестирования системы. Было установлено, что требования безопасности никогда не исключают ненадежного поведения системы. Посредством тестирования и других процессов аттестации невозможно полностью доказать соответствие системы требованиям безопасности. Верификация и аттестация должны стать обязательными шагами в разработке ПО, пусть даже самого простого. Каждая компания, производящая ПО, должна создать штат сотрудников, которые будут заниматься только верификацией и аттестацией: это инженеры-тестеры, инженеры-испекторы и др. Организации должны учитывать экономическую обстановку на рынке ПО, желания пользователей (уже было отмечено, что требовательность пользователей к ПО растет). Если соблюдать все эти требования, то, скорее всего, наступит день, когда нас будут окружать системы, работающие без сбоев.

верификация аттестация программный

1. Соммервилл И. Инженерия программного обеспечения, 6-е издание.:

Пер. с англ. — М.: Издат. Дом. «Вильямс», 2002. — 624 с.: ил.

2. МЕТОДЫ ВЕРИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, В. В. Кулямин, Институт системного программирования Российской академии наук.

3. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения: Курс лекций.

4. Роберт Капбертсон, Крис Браун, Гэри Кобб. БЫСТРОЕ ТЕСТИРОВАНИЕ, Издательский дом «Вильямс»

5. Компьютерные технологии в мащиностроении. http://www.arctic-cooler.com/

6. Материалы с сайта ru.wikipedia.org