Верификация и аттестация модуля

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

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

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

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

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

Инспектирование ПО

Спецификация требований

Высокоуровневая архитектура

Формальная спецификация

Детализированная архитектура

Программа

Прототип

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

Рис. 1.1. Статическая и динамическая верификация и аттестация

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

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

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

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

Назначение ПО. Уровень достоверности соответствия зависит от важности (критичности) разрабатываемого программного продукта по каким-либо критериям. Например, ПО для медицинской установки «Аппарат сердце-легкие» является суперкритичным, так как от качества работы системы зависит человеческая жизнь. Можно привести пример систем малой критичности. Это, в частности, опытные образцы программных систем, разрабатываемые для демонстрации некоторых новых идей.

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

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

Тема 5. Разработка и оформление программной документации

5.1. Разработка технического задания

Разработка технического задания (ТЗ) является важным предварительным этапом проекта, который выполняется или самим Заказчиком, или подрядной организацией.

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

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

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

Для распределения ответственности за ошибки стороны ссылаются на техническое задание. Грамотно разработанное ТЗ станет инструментом в руках Заказчика, на основании которого он сможет требовать от подрядчика соответствия выполненных работ всем условиям, оговорённым в ТЗ.

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

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

Группа AF окажет поддержку Заказчику при разработке ТЗ, учитывая цели и ресурсные ограничения Заказчика.
В результате Заказчик получит следующие преимущества:

§ Корректное оформление технических требований

§ Полная и максимально правильная постановка задач проекта

§ Обоснование необходимости решения задачи

§ Уточнение исходных данных

Не нашли, что искали? Воспользуйтесь поиском по сайту: