Дадим несколько определений, определяющих общую структуру процесса сертификации программного обеспечения:
Сертификация ПО – процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие Заявителя, Сертифицирующего органа и Наблюдательного органа
Заявитель - организация, подающая заявку в соответствующий Сертифицирующий орган на получения сертификата (соответствия, качества, годности и т.п.) изделия.
Сертифицирующий орган – организация, рассматривающая заявку Заявителя о проведении Сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производящая набор процедур направленных на проведение процесса Сертификации ПО Заявителя .
Наблюдательный орган – комиссия специалистов, наблюдающих за процессами разработки Заявителем сертифицируемой информационной системы и дающих заключение, о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в Сертифицирующий орган .
Сертификация может быть направлена на получение сертификата соответствия, либо сертификата качества.
В первом случае результатом сертификации является признание соответствия процессов разработки определенным критериям, а функциональности системы определенным требованиям. Примером таких требований могут служить руководящие документы Федеральной службы по техническому и экспортному контролю в области безопасности программных систем .
Во втором случае результатом является признание соответствия процессов разработки определенным критериям, гарантирующим соответствующий уровень качества выпускаемой продукции и его пригодности для эксплуатации в определенных условиях. Примером таких стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ Р ИСО 9000-2001) или авиационные стандарты DO-178B , AS9100 , AS9006 .
Тестирование сертифицируемого программного обеспечения имеет две взаимодополняющие цели:
· Первая цель - продемонстрировать, что программное обеспечение удовлетворяет требованиям на него.
· Вторая цель - продемонстрировать с высоким уровнем доверительности, что ошибки, которые могут привести к неприемлемым отказным ситуациям, как они определены процессом, оценки отказобезопасности системы, выявлены в процессе тестирования.
Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить целям тестирования программного обеспечения, необходимо следующее:
· Тесты, в первую очередь, должны основываться на требованиях к программному обеспечению;
· Тесты должны разрабатываться для проверки правильности функционирования и создания условий для выявления потенциальных ошибок.
· Анализ полноты тестов, основанных на требованиях на программное обеспечение, должен определить, какие требования не протестированы.
· Анализ полноты тестов, основанных на структуре программного кода, должен определить, какие структуры не исполнялись при тестировании.
Также в этом стандарте говорится о тестировании, основанном на требованиях. Установлено, что эта стратегия наиболее эффективна при выявлении ошибок. Руководящие указания для выбора тестовых примеров, основанных на требованиях, включают следующее:
· Для достижения целей тестирования программного обеспечения должны быть проведены две категории тестов: тесты для нормальных ситуаций и тесты для ненормальных (не отраженных в требованиях, робастных) ситуаций.
· Должны быть разработаны специальные тестовые примеры для требований на программное обеспечение и источников ошибок, присущих процессу разработки программного обеспечения.
Целью тестов для нормальных ситуаций является демонстрация способности программного обеспечения давать отклик на нормальные входы и условия в соответствии с требованиями.
Целью тестов для ненормальных ситуаций является демонстрация способности программного обеспечения адекватно реагировать на ненормальные входы и условия, иными словами, это не должно вызывать отказ системы.
Категории отказных ситуаций для системы устанавливаются путем определения опасности отказной ситуации для самолета и тех, кто в нем находится. Любая ошибка в программном обеспечении может вызвать отказ, который внесет свой вклад в отказную ситуацию. Таким образом, уровень целостности программного обеспечения, необходимый для безопасной эксплуатации, связан с отказными ситуациями для системы.
Существует 5 уровней отказных ситуаций от несущественной до критически опасной. Согласно этим уровням вводится понятие уровня критичности программного обеспечения. От уровня критичности зависит состав документации, предоставляемой в сертифицирующий орган, а значит и глубина процессов разработки и верификации системы. Например, количество типов документов и объем работ по разработке системы, необходимых для сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-два порядка от количества и объемов, необходимых для сертификации по самому высокому уровню. Конкретные требования определяет стандарт, по которому планируется вести сертификацию.
Верификация и валидация (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 программной спецификации. В реальных разработках формализация этих взаимосвязей является неплохой, и часть отношений уточняется в процессе разработок программ. Такие не полностью определённые недостаточны для доказательства корректности программ. Только при полной и точной формализации всех условий и связей между входными и результирующими данными появляется возможность их использования для автоматической верификации.
Метод индуктивных утверждений.
Для изучения этого метода программа снабжается утверждениями о свойствах её переменных в нкоторых точках:
a) Входные переменные не меняются в процессе исполнения программ;
b) Описываются состояния переменных в промежуточных точках;
c) Выходные переменные описываются с помощью отношениями между переменными после завершения программы.
Верификация состоит в последовательной демонстрации того, что из входных переменных и преобразований, выполненных на первом шаге следует истинность утверждения, сформированного в следующей промежуточной точке.
Для верификации программ необходимо три языка:
· Язык записи текстов программ;
· Язык формулировки условий верификации;
· Язык формирования и доказательства корректности.
Так как эти языки различаются в значительной степени, то это обстоятельство является одним из применения верификации.
Доказательство корректности имеет следующие преимущества:
1. Представляет собой чёткий формализованный процесс.
2. Требует анализа. Процесс доказательства корректностидает возможность рассматривать части программ, которое в противном случае анализируется лишь случайно.
3. проясняет промежуточные результаты вычислений. Выписывании выражений заставляет программиста четко сформировать свои предположения о результатах вычислений в выбранных точках программы.
4. Выявляет зависимости. В процессе доказательства программ начинает понимать какие предположения о входных данных не явно испытывается в различных частях программы.
Недостатки метода:
1. Сложность; даже для небольших простых программ выкладки очень сложны, что может привести к ошибкам.
2. Ошибки, Из-за сложности метода легко допустить ошибки и при формировании доказываемых утверждений и при доказательстве.
3. Трудности работы с массивами.
4. Отсутствие мощного математического аппарата.
5. Высокая трудоёмкость.Для проверки программы требуется затраты труда, чем для её написания (в 2 – 6 раз).
6. Отсутствие выразительности. Часто нелегко сформировать выгодно утверждение для того что интуитивно представляетсяочень простым вычислением:
7. Трудность понимания.
8. Необходимостьобучения. Для применении этого метода требуется длительное обучение и тренировка.
Санкт-Петербургский
Государственный Электротехнический Университет
Кафедра МОЭВМ
по дисциплине
“Процесс разработки программных изделий”
“Верификация ПО”
Санкт-Петербург
Цель верификации………………………………………………………………… стр. 3
Вводные замечания……………………………………………………………….. стр. 3
Специальные и общие целевые задачи………………………………………….. стр. 4
Ожидаемая практика по целевым задачам……………………………………… стр. 4
SG1 Подготовка к верификации………………………………………………..... стр. 4
SG2 Проведение экспертиз (экспертного оценивания)………………………… стр. 7
SG3 Осуществление верификации……………………………………………..... стр. 9
Приложение 1. Обзор средств автоматизации процесса верификации……….. стр. 11
Приложение 2. Основные современные подходы к верификации…………….. стр. 12
Список использованной литературы…………………………………………….. стр. 14
Интегрированнаяя модель совершенства и зрелости
Верификация (Уровень зрелости 3)
Цель
Цель верификации - обеспечение гарантий того, что отобранное промежуточное программное изделие или конечная продукция отвечает специфицированным требованиям.
Водные замечания
Верификация программных продуктов представляет собой проверку готового продукта или его промежуточных версий на соответствие исходным требованиям. При этом подразумевается не только тестирование самой программы, но и аудит проекта, пользовательской и технической документации и т.д.
Цель верификации программных систем - это определение и выдача отчетов об ошибках, которые могут быть допущены на этапах жизненного цикла. Основные задачи верификации:
определение соответствия высокоуровневых требований требованиям к системе;
учет высокоуровневых требований в архитектуре системы;
соблюдение архитектуры и требований к ней в исходном коде;
определение соответствия исполняемого кода требованиям к системе;
определение средств, используемых для решения вышеперечисленных задач, которые технически корректны и достаточно полны.
Верификация включает в себя верификацию готовой продукции и верификацию промежуточных продукций относительно всех отобранных требований, включающих в себя требования заказчика, требования к готовой продукции и требования к ее отдельным компонентам.
Верификация по своей сути является инкрементальным (нарастающим) процессом с момента своего возникновения на протяжении всей разработки продукции и проведения всех работ по продукции. Верификация начинается с верификации требований, затем следует верификация всех промежуточных продукций на различных стадиях их разработки и изготовления и заканчивается верификацией конечной продукции.
Верификация промежуточных продукций на каждой стадии их разработки и изготовления существенно повышает вероятность того, что конечная продукция будет удовлетворять требованиям заказчика, требованиям к готовой продукции и требованиям к ее отдельным компонентам.
Верификация и Валидация процессов есть суть родственные процессы, направленные, однако, на получение разного результата. Цель Валидации состоит в том, чтобы продемонстрировать, что готовая продукция действительно удовлетворяет своему исходному предназначению. Верификация же направлена на то, чтобы удостовериться в том, что продукция в точности соответствует определенным требованиям. Другими словами, Верификация гарантирует, что “вы делаете это правильно ”, а Валидация то, что “вы делаете правильную вещь ”.
Для оценки эффективности затрат и выполняемых работ верификация должна как можно раньше реализовываться в соответствующих процессах (таких как поставка, разработка, эксплуатация или сопровождение). Данный процесс может включать анализ, проверку и испытание (тестирование).
Данный процесс может выполняться с различными степенями независимости исполнителей. Степень независимости исполнителей может распределяться как между различными субъектами в самой организации, так и субъектами в другой организации, с различными степенями распределения обязанностей. Данный процесс называется процессом независимой верификации , если организация-исполнитель не зависит от поставщика, разработчика, оператора или персонала сопровождения.
Экспертные оценки (экспертизы ) являются важной составляющей верификации как хорошо зарекомендовавшее себя средство эффективного устранения дефектов. Важным выводом из этого является необходимость в развитии более глубокого понимания и осмысления рабочих версий продукта, а также используемых рабочих процессов для выявления возможных дефектов и создания в случае необходимости возможности для внесения улучшений.
Экспертизы включают в себя методическое исследование производимых работ экспертами, с целью выявить дефекты и другие требуемые изменения.
Основными методами экспертного оценивания являются:
осмотр
сквозной структурный контроль
Термины верификация и валидация связаны с проверкой качества программного обеспечения. Мы используем эти термины в своих статьях и докладах. Неоднократно мы слышали различные комментарии и рассуждения, следует ли относить статический анализ исходного кода программ к верификации и валидации и в чем различие этих понятий. В целом складывается такое впечатление, что каждый вкладывает в эти термины свои понятия, а это приводит к взаимному недопониманию.
Мы решили разобраться с терминологией, чтобы придерживаться наиболее правильного толкования этих понятий. В ходе исследования, мы нашли работу В.В. Кулямина "Методы верификации программного обеспечения" . В ней дается развернутое описание этих терминов, и мы приняли решение в дальнейшем опираться на определения, данные в этой работе. Приведем некоторые выдержки их этой работы, относящиеся к верификации и валидации.
Верификация и валидация являются видами деятельности, направленными на контроль качества программного обеспечения и обнаружение ошибок в нем. Имея общую цель, они отличаются источниками проверяемых в их ходе свойств, правил и ограничений, нарушение которых считается ошибкой.
Для дальнейшего изложения нам необходимо ввести термин "артефакт жизненного цикла ПО". Артефактами жизненного цикла ПО называются различные информационные сущности, документы и модели, создаваемые или используемые в ходе разработки и сопровождения ПО. Так, артефактами являются техническое задание, описание архитектуры, модель предметной области на каком-либо графическом языке, исходный код, пользовательская документация и т.д. Различные модели, используемые отдельными разработчиками при создании и анализе ПО, но не зафиксированные в виде доступных другим людям документов, не могут считаться артефактами.
Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. В частности, верификация проверяет соответствие между нормами стандартов, описанием требований (техническим заданием) к ПО, проектными решениями, исходным кодом, пользовательской документацией и функционированием самого ПО. Кроме того, проверяется, что требования, проектные решения, документация и код оформлены в соответствии с нормами и стандартами, принятыми в данной стране, отрасли и организации при разработке ПО, а также - что при их создании выполнялись все указанные в стандартах операции, в нужной последовательности. Обнаруживаемые при верификации ошибки и дефекты являются расхождениями или противоречиями между несколькими из перечисленных документов, между документами и реальной работой программы, между нормами стандартов и реальным процессами разработки и сопровождения ПО. При этом принятие решения о том, какой именно документ подлежит исправлению (может быть, и оба) является отдельной задачей.
Валидация проверяет соответствие любых создаваемых или используемых в ходе разработки и сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого ПО, с учетом законов предметной области и ограничений контекста использования ПО. Эти нужды и потребности чаще всего не зафиксированы документально - при фиксации они превращаются в описание требований, один из артефактов процесса разработки ПО. Поэтому валидация является менее формализованной деятельностью, чем верификация. Она всегда проводится с участием представителей заказчиков, пользователей, бизнес-аналитиков или экспертов в предметной области - тех, чье мнение можно считать достаточно хорошим выражением реальных нужд и потребностей пользователей, заказчиков и других заинтересованных лиц. Методы ее выполнения часто используют специфические техники выявления знаний и действительных потребностей участников.
Различие между верификацией и валидацией проиллюстрировано на рисунке 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.