Верификация (подтверждение правильности) – состоит в проверке и доказательстве корректности разработанной программы по отношению к совокупности формальных утверждений, представленных в спецификации и полностью определяющей связь между входными и выходными данными этой программы. При этом отношения между переменными н входе и выходе программы анализируется не в виде значений, как при тестировании, а в виде описаний их свойств, проявляющихся при любых процессах обработок этих переменных контролируемой в программе.
Верификация программы в принципе исключает необходимость её тестирования и отладки, так как при этом на более высоком уровне понятий и описаний всех переменных, устанавливается корректность процессов, их обработка и преобразования.
Сущность каждой программы можно представить описаниями отношений между входными и выходными данными. Эти отношения формализуются 1 программной спецификации. В реальных разработках формализация этих взаимосвязей является неплохой, и часть отношений уточняется в процессе разработок программ. Такие не полностью определённые недостаточны для доказательства корректности программ. Только при полной и точной формализации всех условий и связей между входными и результирующими данными появляется возможность их использования для автоматической верификации.
Метод индуктивных утверждений.
Для изучения этого метода программа снабжается утверждениями о свойствах её переменных в нкоторых точках:
a) Входные переменные не меняются в процессе исполнения программ;
b) Описываются состояния переменных в промежуточных точках;
c) Выходные переменные описываются с помощью отношениями между переменными после завершения программы.
Верификация состоит в последовательной демонстрации того, что из входных переменных и преобразований, выполненных на первом шаге следует истинность утверждения, сформированного в следующей промежуточной точке.
Для верификации программ необходимо три языка:
· Язык записи текстов программ;
· Язык формулировки условий верификации;
· Язык формирования и доказательства корректности.
Так как эти языки различаются в значительной степени, то это обстоятельство является одним из применения верификации.
Доказательство корректности имеет следующие преимущества:
1. Представляет собой чёткий формализованный процесс.
2. Требует анализа. Процесс доказательства корректностидает возможность рассматривать части программ, которое в противном случае анализируется лишь случайно.
3. проясняет промежуточные результаты вычислений. Выписывании выражений заставляет программиста четко сформировать свои предположения о результатах вычислений в выбранных точках программы.
4. Выявляет зависимости. В процессе доказательства программ начинает понимать какие предположения о входных данных не явно испытывается в различных частях программы.
Недостатки метода:
1. Сложность; даже для небольших простых программ выкладки очень сложны, что может привести к ошибкам.
2. Ошибки, Из-за сложности метода легко допустить ошибки и при формировании доказываемых утверждений и при доказательстве.
3. Трудности работы с массивами.
4. Отсутствие мощного математического аппарата.
5. Высокая трудоёмкость.Для проверки программы требуется затраты труда, чем для её написания (в 2 – 6 раз).
6. Отсутствие выразительности. Часто нелегко сформировать выгодно утверждение для того что интуитивно представляетсяочень простым вычислением:
7. Трудность понимания.
8. Необходимостьобучения. Для применении этого метода требуется длительное обучение и тренировка.
Как известно, универсальные вычислительные машины могут быть запрограммированы для решения самых разнородных задач - в этом заключается одна из основных их особенностей, имеющая огромную практическую ценность. Один и тот же компьютер, в зависимости от того, какая программа находится у него в памяти, способен осуществлять арифметические вычисления, доказывать теоремы и редактировать тексты, управлять ходом эксперимента и создавать проект автомобиля будущего, играть в шахматы и обучать иностранному языку. Однако успешное решение всех этих и многих других задач возможно лишь при том условии, что компьютерные программы не содержат ошибок, которые способны привести к неверным результатам.
Можно сказать, что требование отсутствия ошибок в программном обеспечении совершенно естественно и не нуждается в обосновании. Но как убедиться в том, что ошибки, в самом деле, отсутствуют? Вопрос не так прост, как может показаться на первый взгляд.
К неформальным методам доказательства правильности программ относят отладку и тестирование , которые являются необходимой составляющей на всех этапах процесса программирования, хотя и не решают полностью проблемы правильности. Существенные ошибки легко найти, если использовать соответствующие приемы отладки (контрольные распечатки, трассировки).
Тестирование – процесс выполнения программы с намерением найти ошибку, а не подтвердить правильность программы. Суть его сводится к следующему. Подлежащую проверке программу неоднократно запускают с теми входными данными, относительно которых результат известен заранее. Затем сравнивают полученный машиной результат с ожидаемым. Если во всех случаях тестирования налицо совпадение этих результатов, появляется некоторая уверенность в том, что и последующие вычисления не приведут к ошибочному итогу, т.е. что исходная программа работает правильно.
Мы уже обсуждали понятие правильности программы с точки зрения отсутствия в ней ошибок. С интуитивной точки зрения программа будет правильной, если в результате ее выполнения будет достигнут результат, с целью получения которого и была написана программа. Сам по себе факт безаварийного завершения программы еще ни о чем не говорит: вполне возможно, что программа в действительности делает совсем не то, что было задумано. Ошибки такого рода могут возникать по различным причинам.
В дальнейшем мы будем предполагать, что обсуждаемые программы не содержат синтаксических ошибок, поэтому при обосновании их правильности внимание будет обращаться только на содержательную сторону дела, связанную с вопросом о том, достигается ли при помощи данной программы данная конкретная цель. Целью можно считать поиск решения поставленной задачи, а программу рассматривать как способ ее решения. Программа будет правильной , если она решит сформулированную задачу.
Метод установления правильности программ при помощи строгих средств известен как верификация программ.
В отличие от тестирования программ, где анализируются свойства отдельных процессов выполнения программы, верификация имеет дело со свойствами программ.
В основе метода верификации лежит предположение о том, что существует программная документация, соответствие которой требуется доказать. Документация должна содержать:
спецификацию ввода-вывода (описание данных, не зависящих от процесса обработки);
свойства отношений между элементами векторов состояний в выбранных точках программы;
спецификации и свойства структурных подкомпонентов программы;
спецификацию структур данных, зависящих от процесса обработки.
К такому методу доказательства правильности программ относится метод индуктивных утверждений , независимо сформулированный К. Флойдом и П. Науром.
Суть этого метода состоит в следующем:
1) формулируются входное и выходное утверждения: входное утверждение описывает все необходимые входные условия для программы (или программного фрагмента), выходное утверждение описывает ожидаемый результат;
2) предполагая истинным входное утверждение, строится промежуточное утверждение, которое выводится на основании семантики операторов, расположенных между входом и выходом (входным и выходным утверждениями); такое утверждение называется выведенным утверждением;
3) формулируется теорема (условия верификации):
из выведенного утверждения следует выходное утверждение;
4) доказывается теорема; доказательство свидетельствует о правильности программы (программного фрагмента).
Доказательство проводится при помощи хорошо разработанных математических методов, использующих исчисление предикатов первого порядка.
Условия верификации можно построить и в обратном направлении, т.е., считая истинным выходное утверждение, получить входное утверждение и доказывать теорему:
из входного утверждения следует выведенное утверждение.
Такой метод построения условий верификации моделирует выполнение программы в обратном направлении. Другими словами, условия верификации должны отвечать на такой вопрос: если некоторое утверждение истинно после выполнения оператора программы, то, какое утверждение должно быть истинным перед оператором?
Построение индуктивных утверждений помогает формализовать интуитивные представления о логике программы. Оно и является самым сложным в процессе доказательства правильности программы. Это объясняется, во-первых, тем, что необходимо описать все содержательные условия, и, во-вторых, тем, что необходимо аксиоматическое описание семантики языка программирования.
Важным шагом в процессе доказательства является доказательство завершения выполнения программы, для чего бывает достаточно неформальных рассуждений.
Таким образом, алгоритм доказательства правильности программы методом индуктивных утверждений представляется в следующем виде:
1) Построить структуру программы.
2) Выписать входное и выходное утверждения.
3) Сформулировать для всех циклов индуктивные утверждения.
4) Составить список выделенных путей.
5) Построить условия верификации.
6) Доказать условие верификации.
7) Доказать, что выполнение программы закончится.
Этот метод сравним с обычным процессом чтения текста программы (метод сквозного контроля). Различие заключается в степени формализации.
Преимущество верификации состоит в том, что процесс доказательства настолько формализуем, что он может выполняться на вычислительной машине. В этом направлении в восьмидесятые годы проводились исследования, даже создавались автоматизированные диалоговые системы, но они не нашли практического применения.
Для автоматизированной диалоговой системы программист должен задать индуктивные утверждения на языке исчисления предикатов. Синтаксис и семантика языка программирования должны храниться в системе в виде аксиом на языке исчисления предикатов. Система должна определять пути в программе и строить условия верификации.
Основной компонент доказывающей системы - это построитель условий верификации, содержащий операции манипулирования предикатами, алгоритмы интерпретации операторов программы. Вторым компонентом системы является подсистема доказательства теорем.
Отметим трудности, связанные с методом индуктивных утверждений. Трудно построить «множество основных аксиом, достаточно ограниченное для того, чтобы избежать противоречий, но достаточно богатое для того, чтобы служить отправной точкой для доказательства утверждений о программах» (Э. Дейкстра). Вторая трудность - семантическая, заключающаяся в формировании самих утверждений, подлежащих доказательству. Если задача, для которой пишется программа, не имеет строгого математического описания, то для нее сложнее сформулировать условия верификации.
Перечисленные методы имеют одно общее свойство: они рассматривают программу как уже существующий объект и затем доказывают ее правильность.
Метод, который сформулировали К. Хоар и Э. Дейкстра основан на формальном выводе программ из математической постановки задачи.
Верификацией и аттестацией называют процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы.
Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом:
Верификация отвечает на вопрос, правильно ли создана система;
Аттестация отвечает на вопрос, правильно ли работает система.
Согласно этим определениям, верификация проверяет соответствие ПО системной спецификации, в частности функциональным и нефункциональным требованиям. Аттестация– более общий процесс. Во время аттестации необходимо убедиться, что программный продукт соответствует ожиданиям заказчика. Аттестация проводится после верификации, для того чтобы определить, насколько система соответствует не только спецификации, но и ожиданиям заказчика.
Как уже отмечалось ранее, на ранних этапах разработки ПО очень важна аттестация системных требований. В требованиях часто встречаются ошибки и упущения; в таких случаях конечный продукт, вероятно, не будет соответствовать ожиданиям заказчика. Но, конечно, аттестация требований не может выявить все проблемы в спецификации требований. Иногда недоработки и ошибки в требованиях обнаруживаются только после завершения реализации системы.
В процессах верификации и аттестации используются две основные методики проверки и анализа систем.
1. Инспектирование ПО. Анализ и проверка различных представлений системы, например документации спецификации требований, архитектурных схем или исходного кода программ. Инспектирование выполняется на всех этапах процесса разработки программной системы. Параллельно с инспектированием может выполняться автоматический анализ исходного кода программ и соответствующих документов. Инспектирование и автоматический анализ – это статические методы верификации и аттестации, поскольку им не требуется исполняемая система.
2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.
На рис. 20.1 показано место инспектирования и тестирования в процессе разработки ПО. Стрелки указывают на те этапы процесса разработки, на которых можно применять данные методы. Согласно этой схеме, инспектирование можно выполнять на всех этапах процесса разработки системы, а тестирование – в тех случаях, когда создан прототип или исполняемая программа.
К методам инспектирования относятся: инспектирование программ, автоматический анализ исходного кода и формальная верификация. Но статические методы могут проверить только соответствие программ спецификации, с их помощью невозможно проверить правильность функционирования системы. Кроме того, статическими методами нельзя проверить такие нефункциональные характеристики, как производительность и надежность. Поэтому для оценивания нефункциональных характеристик проводится тестирование системы.
Рис. 20.1. Статическая и динамическая верификация и аттестация
Несмотря на широкое применение инспектирования ПО, преобладающим методом верификации и аттестации все еще остается тестирование. Тестирование – это проверка работы программ с данными, подобными реальным, которые будут обрабатываться в процессе эксплуатации системы. Наличие в программе дефектов и несоответствий требованиям обнаруживается путем исследования выходных данных и выявления среди них аномальных. Тестирование выполняется на этапе реализации системы (для проверки соответствия системы ожиданиям разработчиков) и после завершения ее реализации.
На разных этапах процесса разработки ПО применяют различные виды тестирования.
1. Тестирование дефектов проводится для обнаружения несоответствий между программой и ее спецификацией, которые обусловлены ошибками или дефектами в программах. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы.
2. Статистическое тестирование оценивает производительность и надежность программ, а также работу системы в различных режимах эксплуатации. Тесты разрабатываются так, чтобы имитировать реальную работу системы с реальными входными данными. Надежность функционирования системы оценивается по количеству сбоев, отмеченных в работе программ. Производительность оценивается по результатам измерения полного времени выполнения операций и времени отклика системы при обработке тестовых данных.
Главная цель верификации и аттестации – удостовериться в том, что система "соответствует своему назначению". Соответствие программной системы своему назначению отнюдь не предполагает, что в ней совершенно не должно быть ошибок. Скорее, система должна достаточно хорошо соответствовать тем целям, для которых планировалась. Уровень необходимой достоверности соответствия зависит от назначения системы, ожиданий пользователей и условий на рынке программных продуктов.
1. Назначение ПО. Уровень достоверности соответствия зависит от того, насколько критическим является разрабатываемое программное обеспечение по тем или иным критериям. Например, уровень достоверности для систем, критическим по обеспечению безопасности, должен быть значительно выше аналогичного уровня достоверности для опытных образцов программных систем, разрабатываемых для демонстрации некоторых новых идей.
2. Ожидания пользователей. Следует с грустью отметить, что в настоящее время у большинства пользователей невысокие требования к программному обеспечению. Пользователи настолько привыкли к отказам, происходящим во время работы программ, что не удивляются этому. Они согласны терпеть сбои в работе системы, если преимущества ее использования компенсируют недостатки. Вместе с тем с начала 1990-х годов терпимость пользователей к отказам в работе программных систем постепенно снижается. В последнее время создание ненадежных систем стало практически неприемлемым, поэтому компаниям, занимающимся разработкой программных продуктов, необходимо все больше внимания уделять верификации и аттестации программного обеспечения.
3. Условия рынка программных продуктов. При оценке программной системы продавец должен знать конкурирующие системы, цену, которую покупатель согласен заплатить за систему, и назначенный срок выхода этой системы на рынок. Если у компании-разработчика несколько конкурентов, необходимо определить дату выхода системы на рынок до окончания полного тестирования и отладки, иначе первыми на рынке могут оказаться конкуренты. Если покупатели не желают приобретать ПО по высокой цене, возможно, они согласны терпеть большее количество отказов в работе системы. При определении расходов на процесс верификации и аттестации необходимо учитывать все эти факторы.
Как правило, в ходе верификации и аттестации в системе обнаруживаются ошибки. Для исправления ошибок в систему вносятся изменения. Этот процесс отладки обычно интегрирован с другими процессами верификации и аттестации. Вместе с тем тестирование (или более обобщенно – верификация и аттестация) и отладка являются разными процессами, которые имеют различные цели.
1. Верификация и аттестация – процесс обнаружения дефектов в программной системе.
2. Отладка – процесс локализации дефектов (ошибок) и их исправления (рис. 20.2).
Рис. 20.2. Процесс отладки
Простых методов отладки программ не существует. Опытные отладчики обнаруживают ошибки путем сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок, шаблонах выходных данных, языке программирования и процессе программирования. Очень важны знания о процессе разработке ПО. Отладчикам известны наиболее распространенные ошибки программистов (например, связанные с пошаговым увеличением значения счетчика). Также учитываются ошибки, типичные для определенных языков программирования, например связанные с использованием указателей в языке С.
Определение местонахождения ошибок в программном коде не всегда простой процесс, поскольку ошибка необязательно находится возле того места в коде программы, где произошел сбой. Чтобы локализовать ошибки, программист-отладчик разрабатывает дополнительные программные тесты, которые помогают выявить источник ошибки в программе. Может возникнуть необходимость в ручной трассировке выполнения программы.
Интерактивные средства отладки являются частью набора средств поддержки языка, интегрированных с системой компиляции программного кода. Они обеспечивают специальную среду выполнения программ, посредством которой можно получить доступ к таблице идентификаторов, а оттуда к значениям переменных. Пользователи часто контролируют выполнение программы пошаговым способом, последовательно переходя от оператора к оператору. После выполнения каждого оператора проверяются значения переменных и выявляются возможные ошибки.
Обнаруженная в программе ошибка исправляется, после чего необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить предыдущее тестирование. Повторное тестирование используется для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых ошибок, поскольку на практике высокий процент "исправления ошибок" либо не завершается полностью, либо вносит новые ошибки в программу.
В принципе во время повторного тестирования после каждого исправления необходимо еще раз запускать все тесты, однако на практике такой подход оказывается слишком дорогостоящим. Поэтому при планировании процесса тестирования определяются зависимости между частями системы и назначаются тесты для каждой части. Тогда можно трассировать программные элементы с помощью специальных контрольных примеров (контрольных данных), подобранных для этих элементов. Если результаты трассировки задокументированы, то для проверки измененного программного элемента и зависимых от него компонентов можно использовать только некоторое подмножество всего множества тестовых данных.
Планирование верификации и аттестации
Верификация и аттестация – дорогостоящий процесс. Для больших систем, например систем реального времени со сложными нефункциональными ограничениями, половина бюджета, выделенного на разработку системы, тратится на процесс верификации и аттестации. Поэтому очевидна необходимость тщательного планирования данного процесса.
Планирование верификации и аттестации, как один из этапов разработки программных систем, должно начинаться как можно раньше. На рис. 20.3 показана модель разработки ПО, учитывающая процесс планирования испытаний. Здесь планирование начинается еще на этапах создания спецификации и проектирования системы. Данную модель иногда называют V-моделью (чтобы увидеть букву V, необходимо повернуть рис. 20.3 на 90°). На этой схеме также показано разделение процесса верификации и аттестации на несколько этапов, причем на каждом этапе выполняются соответствующие тесты.
Рис. 20.3. Планирование испытаний в процессе разработки и тестирования
В процессе планирования верификации и аттестации необходимо определить соотношение между статическими и динамическими методами проверки системы, определить стандарты и процедуры инспектирования и тестирования ПО, утвердить технологическую карту проверок программ (см. раздел 19.2) и составить план тестирования программ. Чему уделить больше внимания – инспектированию или тестированию, зависит от типа разрабатываемой системы и опыта организации. Чем более критична система, тем больше внимания необходимо уделить статическим методам верификации.
В плане верификации и аттестации основное внимание уделяется стандартам процесса тестирования, а не описанию конкретных тестов. Этот план предназначен не только для руководства, он в основном предназначен специалистам, занимающимся разработкой и тестированием систем. План дает возможность техническому персоналу получить полную картину испытаний системы и в этом контексте спланировать свою работу. Кроме того, план предоставляет информацию менеджерам, отвечающим за то, чтобы у группы тестирования были все необходимые аппаратные и программные средства.
План испытаний не является неизменным документом. Его следует регулярно пересматривать, так как тестирование зависит от процесса реализации системы. Например, если реализация какой-либо части системы не завершена, то невозможно провести тестирование сборки системы. Поэтому план необходимо периодически пересматривать, чтобы сотрудников, занятых тестированием, можно было использовать на других работах.
Верификация и валидация (verification and validation - V& V) предназначены для анализа, проверки правильности выполнения и соответствия ПО спецификациям и требованиям заказчика. Данные методы проверки правильности программ и систем соответственно означают:
- верификация - это проверка правильности создания системы в соответствии с ее спецификацией;
- валидация - это проверка правильности выполнения заданных требований к системе.
Верификация помогает сделать заключение о корректности созданной системы после завершения ее проектирования и разработки. Валидация позволяет установить выполнимость заданных требований и включает в себя ряд действий для получения правильных программ и систем, а именно:
- планирование процедур проверки и контроля проектных решений и требований;
- обеспечение уровня автоматизации проектирования программ CASE- средствами;
- проверка правильности функционирования программ методами тестирования на наборах целевых тестов;
- адаптация продукта к операционной среде и др.
Валидация выполняет эти действия путем просмотра и инспекции спецификаций и результатов проектирования на этапах ЖЦ для подтверждения того, что имеется корректная реализация начальных требований и выполнены заданные условия и ограничения. В задачи верификации и валидации входят проверки полноты, непротиворечивости и однозначности спецификации требований и правильности выполнения функций системы.
Верификации и валидации подвергаются:
- основные компоненты системы;
- интерфейсы компонентов (программные, технические и информационные) и взаимодействия объектов (протоколы и сообщения), обеспечивающие выполнение системы в распределенных средах;
- средства доступа к БД и файлам (транзакции и сообщения) и проверка средств защиты от несанкционированного доступа к данным разных пользователей;
- документация к ПО и к системе в целом;
- тесты, тестовые процедуры и входные данные.
Иными словами, основными систематическими методами правильности программ являются:
- верификация компонентов ПС и валидация спецификации требований;
- инспектирование ПС для установления соответствия программы заданным спецификациями;
- тестирование выходного кода ПС на тестовых данных в конкретной операционной среде для выявления ошибок и дефектов, вызванных разными недоработками, аномальными ситуациями, сбоями оборудования или аварийным прекращением работы системы (см. гл. 9).
Стандарты ISO/IEC 3918-99 и 12207 включают в себя процессы верификации и валидации. Для них определены цели, задачи и действия по проверке правильности создаваемого продукта (включая рабочие, промежуточные продукты) на этапах ЖЦ и соответствия его требованиям.
Основная задача процессов верификации и валидации состоит в том, чтобы проверить и подтвердить , что конечный ПП отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы позволяют выявить ошибки в рабочих продуктах этапов ЖЦ, без выяснения причин их появления, а также установить правильность ПП относительно его спецификации.
Эти процессы взаимосвязанные и определяются одним термином - «верификация и валидация» (V&V 7).
При верификации осуществляется:
- проверка правильности перевода отдельных компонентов в выходной код, а также описаний интерфейсов путем трассировки взаимосвязей компонентов в соответствии с заданными требованиями заказчика;
- анализ правильности доступа к файлам или БД с учетом принятых в используемых системных средствах процедур манипулирования данными и передачи результатов;
- проверка средств защиты компонентов на соответствие требованиям заказчика и проведение их трассировки.
После проверки отдельных компонентов системы проводятся их интеграция, а также верификация и валидация интегрированной системы. Систему тестируют на множестве наборов тестов для определения адекватности и достаточности этих наборов для завершения тестирования и установления правильности системы.
Идея создания международного проекта по формальной верификации была предложена Т. Хоаром, она обсуждалась на симпозиуме по верифицированному ПО в феврале 2005 г. в Калифорнии. Затем в октябре этого же года на конференции IFIP в Цюрихе был принят международный проект сроком на 15 лег но разработке «целостного автоматизированного набора инструментов для проверки корректности ПС».
В нем сформулированы следующие основные задачи:
- разработка единой теории построения и анализа программ;
- построение всеобъемлющего интегрированного набора инструментов верификации для всех производственных этапов, включая разработку спецификаций и их проверку, генерацию тестовых примеров, уточнение, анализ и верификацию программ;
- создание репозитария формальных спецификаций и верифицированных программных объектов разных видов и типов.
В данном проекте предполагается, что верификация будет охватывать все аспекты создания и проверки правильности ПО и станет панацеей от всех бед, связанных с постоянным возникновением ошибок в создаваемых программах.
Многие формальные методы доказательства и верификации специфицированных программ прошли практическую апробацию. Проделана большая работа международного комитета ISO/IEC в рамках стандарта ISO/ IEC 12207:2002 по стандартизации процессов верификации и валидации ПО. Проверка корректности формальными методами разных объектов программирования является перспективной.
Репозитарий является хранилищем программ, спецификаций и инструментов, применяемых при разработках и испытаниях, оценках готовых компонентов, инструментов и заготовок методов. На него возлагаются следующие общие задачи:
- накопление верифицированных спецификаций, методов доказательства, программных объектов и реализаций кодов для сложных применений;
- накопление всевозможных методов верификации, их оформление в виде, пригодном для поиска и выбора реализованной теоретической идеи для дальнейшего применения;
- разработка стандартных форм для задания и обмена формальными спецификациями разных объектов программирования, а также инструментов и готовых систем;
- разработка механизмов интероперабельности и взаимодействия для переноса готовых верифицированных продуктов из репозитария в новые распределенные и сетевые среды для создания новых ПС.
Данный проект предполагается развивать в течение 50 лет. Более ранние проекты ставили подобные цели: улучшение качества ПО, формализация сервисных моделей, снижение сложности за счет использования ПИК, создание отладочного инструментария для визуальной диагностики ошибок и их устранения и др. Однако коренного изменения в программировании не произошло ни в смысле визуальной отладки, ни в достижении высокого качества ПО. Процесс развития продолжается.
Новый международный проект по верификации ПО требует от его участников не только знаний теоретических аспектов спецификации программ, но и высокой квалификации программистов для его реализации в ближайшие годы.
Термины верификация и валидация связаны с проверкой качества программного обеспечения. Мы используем эти термины в своих статьях и докладах. Неоднократно мы слышали различные комментарии и рассуждения, следует ли относить статический анализ исходного кода программ к верификации и валидации и в чем различие этих понятий. В целом складывается такое впечатление, что каждый вкладывает в эти термины свои понятия, а это приводит к взаимному недопониманию.
Мы решили разобраться с терминологией, чтобы придерживаться наиболее правильного толкования этих понятий. В ходе исследования, мы нашли работу В.В. Кулямина "Методы верификации программного обеспечения" . В ней дается развернутое описание этих терминов, и мы приняли решение в дальнейшем опираться на определения, данные в этой работе. Приведем некоторые выдержки их этой работы, относящиеся к верификации и валидации.
Верификация и валидация являются видами деятельности, направленными на контроль качества программного обеспечения и обнаружение ошибок в нем. Имея общую цель, они отличаются источниками проверяемых в их ходе свойств, правил и ограничений, нарушение которых считается ошибкой.
Для дальнейшего изложения нам необходимо ввести термин "артефакт жизненного цикла ПО". Артефактами жизненного цикла ПО называются различные информационные сущности, документы и модели, создаваемые или используемые в ходе разработки и сопровождения ПО. Так, артефактами являются техническое задание, описание архитектуры, модель предметной области на каком-либо графическом языке, исходный код, пользовательская документация и т.д. Различные модели, используемые отдельными разработчиками при создании и анализе ПО, но не зафиксированные в виде доступных другим людям документов, не могут считаться артефактами.
Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. В частности, верификация проверяет соответствие между нормами стандартов, описанием требований (техническим заданием) к ПО, проектными решениями, исходным кодом, пользовательской документацией и функционированием самого ПО. Кроме того, проверяется, что требования, проектные решения, документация и код оформлены в соответствии с нормами и стандартами, принятыми в данной стране, отрасли и организации при разработке ПО, а также - что при их создании выполнялись все указанные в стандартах операции, в нужной последовательности. Обнаруживаемые при верификации ошибки и дефекты являются расхождениями или противоречиями между несколькими из перечисленных документов, между документами и реальной работой программы, между нормами стандартов и реальным процессами разработки и сопровождения ПО. При этом принятие решения о том, какой именно документ подлежит исправлению (может быть, и оба) является отдельной задачей.
Валидация проверяет соответствие любых создаваемых или используемых в ходе разработки и сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого ПО, с учетом законов предметной области и ограничений контекста использования ПО. Эти нужды и потребности чаще всего не зафиксированы документально - при фиксации они превращаются в описание требований, один из артефактов процесса разработки ПО. Поэтому валидация является менее формализованной деятельностью, чем верификация. Она всегда проводится с участием представителей заказчиков, пользователей, бизнес-аналитиков или экспертов в предметной области - тех, чье мнение можно считать достаточно хорошим выражением реальных нужд и потребностей пользователей, заказчиков и других заинтересованных лиц. Методы ее выполнения часто используют специфические техники выявления знаний и действительных потребностей участников.
Различие между верификацией и валидацией проиллюстрировано на рисунке 1.
Приведенные определения получены некоторым расширением определений из стандарта IEEE 1012 на процессы верификации и валидации . В стандартном словаре терминов программной инженерии IEEE 610.12 1990 года определение верификации по смыслу примерно то же, а определение валидации несколько другое - там говорится, что валидация должна проверять соответствие полученного в результате разработки ПО исходным требованиям к нему. В этом случае валидация являлась бы частным случаем верификации, что нигде в литературе по программной инженерии не отмечается, поэтому, а также потому, что оно поправлено в IEEE 1012 2004 года, это определение следует считать неточным. Частое использование фразы B. Boehm"а :
Верификация отвечает на вопрос "Делаем ли мы продукт правильно?", а валидация- на вопрос "Делаем ли мы правильный продукт?"
также добавляет путаницы, поскольку афористичность этого высказывания, к сожалению, сочетается с двусмысленностью. Однако многочисленные труды его автора позволяют считать, что он подразумевал под верификацией и валидацией примерно те же понятия, которые определены выше. Указанные разночтения можно проследить и в содержании стандартов программной инженерии. Так, стандарт ISO 12207 считает тестирование разновидностью валидации, но не верификации, что, по-видимому, является следствием использования неточного определения из стандартного словаря .
В заключении хочется заметить, что согласно приведенным определениям статический анализ исходного кода программ соответствует верификации программного обеспечения, как проверка соответствия программного кода различным стандартам кодирования. Статический анализ проверяет соответствие результатов этапа конструирования программной системы требованиям и ограничениям, сформулированным ранее.
Библиографический список
- В.В. Кулямин "Методы верификации программного обеспечения". Институт системного программирования РАН 109004, г. Москва, ул. Б. Коммунистическая, д. 25.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
- IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
- B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. In R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA:MIT Press, 1979.
- ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.