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

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

Реферат

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

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

Содержание

Введение

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

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

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

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

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

.        Верификация и аттестация критических систем

Заключение

Литература

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.2 Виды деятельности, осуществляемые при составлении плана испытаний

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Большинство компиляторов (например, GNU C Compiler) выводят на экран «предупреждения <http://ru.wikipedia.org/w/index.php?title=%D0%9F%D1%80%D0%B5%D0%B4%D1%83%D0%BF%D1%80%D0%B5%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%B0&action=edit&redlink=1>» (англ. warnings) - сообщения о том, что код, будучи синтаксически правильным, скорее всего, содержит ошибку. Это простейший статический анализ. У компилятора есть много других немаловажных характеристик - в первую очередь скорость работы и качество машинного кода, поэтому компиляторы проверяют код лишь на очевидные ошибки. Статические анализаторы предназначены для более детального исследования кода.