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

На точность моделирования влияют следующие особенности:

■ упрощение модели;

■ ошибки при построении модели;

■ использование элементов с низкой точностью, с линейной аппроксимацией;

■ наличие в модели вырожденных конечных элементов;

■ некорректные связи;

■ некорректные параметры моделей;

■ некорректные свойства элементов;

■ некорректные начальные и граничные условия;

■ погрешности метода расчетов.

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

Верификация модели (model verification) – проверка ее истинности, адекватности. Дословный перевод с английского: verification – это: 1) контроль, проверка; Sync: check, examination; 2) удостоверение, подтверждение (предсказания, сомнения) (а); подтверждение под присягой (б); 3) засвидетельствование. В отношении к дескриптивным моделям верификация модели сводится к сопоставлению результатов расчетов по модели с соответствующими данными действительности – фактами и закономерностями экономического развития. В отношении нормативных (в том числе оптимизационных) моделей положение сложнее: в условиях действующего экономического механизма моделируемый объект подвергается различным управляющим воздействиям, не предусмотренным моделью; надо ставить специальный экономический эксперимент с учетом требований чистоты, т.е. устранения влияния этих воздействий, что представляет собой трудную, во многом еще не решенную задачу.

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

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

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

Валидация – подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены. Образно говоря, валидация – это процедура сопоставления того, что задумано сделать (или еще пока делается), с тем, что необходимо потребителю для конкретного применения, т.е. сопоставление планируемого или промежуточного результата деятельности с текущими выходными требованиями – "взгляд вперед". Дословный перевод с английского: validation – это: 1) ратификация, утверждение, Sync: ratification; 2) легализация, признание законной силы, придание юридической силы.

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

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

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

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

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

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

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

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

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

■ пригодность. Выполняет ли приложение предназначенную ему задачу? Может быть верифицировано путем моделирования правильного сопутствующего окружения (подход, аналогичный тестированию);

■ точность. Насколько точны результаты работы приложения? Трудно реализуется при модельном подходе; логическая верификация в данном случае будет более эффективна;

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

■ соответствие. Соответствует ли реализованная функция данному стандарту? Стандарт используется как спецификация (источник требований), реализация функции моделируется;

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

Множество атрибутов надежности характеризует способность программного обеспечения поддерживать определенный уровень предоставляемых услуг при данных условиях и в течение заданного промежутка времени:

■ завершенность. Является ли изначально предоставляемый уровень услуг достаточным? Все ли было реализовано? Это свойство по определению не может быть проверено формальным тестированием: на каждую ожидаемую функцию формулируется требование (или множество требований), которое проверяется на модели;

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

■ устойчивость к окружению (прочность ). Может ли приложение работать нормально в нестандартном или неустойчивом окружении? Применение модельного подхода в данном случае возможно только при наличии возможности моделирования окружения. Однако корректное моделирование стресс-ситуации – весьма нетривиальная задача;

■ восстанавливаемость. Может ли приложение продолжать работу после сбоя? Как правило, это свойство явно прописывается в программе и нуждается только в проверке. Может быть проверено как модельной верификацией, так и тестированием.

Множество атрибутов по удобству пользования характеризует трудности при использовании программного обеспечения и их субъективную оценку тем или иным множеством пользователей:

■ понятность. Насколько интуитивно ясен пользовательский интерфейс приложения? Не поддается научной формализации. Несмотря на то что менее формальные правила существуют уже давно, модельная верификация невозможна;

■ обучаемость. Приспосабливается ли приложение к специфике пользователя? Используются алгоритмы искусственного интеллекта, которые могут быть верифицированы, соответственно может быть верифицирован и признак;

■ управляемость. Легко ли управлять работой приложения? Эта область, традиционная для бета-тестирования, в последнее время переходит в руки специалистов по пользовательским интерфейсам.

Множество атрибутов производительности выявляет связь уровня предоставляемых приложением услуг с объемом используемых при этом ресурсов:

■ поведение во времени. Адекватен ли временной график использования ресурсов? В данном случае нужно тестировать реальную систему, а не ее модель (например, для нахождения утечки памяти). Абсолютно не подходит для модельной верификации;

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

■ алгоритмизация. Насколько оптимальны использованные алгоритмы? Классический анализ алгоритмов вместе с формальной их верификацией дает быстрые и точные результаты.

Множество атрибутов поддержки связано с усилиями по внесению определенных изменений в работающее приложение:

■ анализируемость. Насколько легко определить части, нуждающиеся в изменении? Не поддается формализации;

■ изменяемость. Какие усилия требуются для внесения изменений? Не поддается формализации, уровень может быть установлен априори;

■ настраиваемостъ. Можно ли достичь желаемого эффекта без изменения самой программы, изменяя только настройки? Задача решается тестированием в реальных условиях;

■ стабильность. Как ведет себя программа при внесении изменений на лету? Эффективно решается модельной верификацией с помощью недетерминированных параллельных процессов;

■ тестируемость. Насколько легко проверяется работа изменившегося контура? Решается параллельно с тестированием или превентивно явным образом и к верификации отношения практически не имеет.

Множество атрибутов переместимости характеризует способность программного обеспечения быть перенесенным из одного окружения в другое:

■ приспособляемость. Может ли приложение изменяться в соответствии с изменениями окружения? Взаимодействующие недетерминированные последовательные процессы дают хороший результат, в том числе и в модельном подходе;

■ устанавливаемость. Может ли приложение устанавливаться на разные платформы или в разные конфигурации? Как правило, явно задается в спецификации и явно реализуется и в проверке не нуждается;

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

■ заменяемость. Может ли приложение быть использовано так же, как его эквивалент от другого производителя? Зависит ли от списка опций соответствующих приложений, которые могли бы быть или должны были быть реализованы?

Это относится к фазе формулирования требований, поэтому в верификации не участвует.

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

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

Видео по теме

Совет 2: Что это за профессия "специалист отдела верификации" в банке?

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

Что такое верификация

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

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

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

Чем занимается специалист по верификации в банке

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

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

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

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

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

Санкт-Петербургский

Государственный Электротехнический Университет

Кафедра МОЭВМ

по дисциплине

“Процесс разработки программных изделий”

“Верификация ПО”

Санкт-Петербург

Цель верификации………………………………………………………………… стр. 3

Вводные замечания……………………………………………………………….. стр. 3

Специальные и общие целевые задачи………………………………………….. стр. 4

Ожидаемая практика по целевым задачам……………………………………… стр. 4

SG1 Подготовка к верификации………………………………………………..... стр. 4

SG2 Проведение экспертиз (экспертного оценивания)………………………… стр. 7

SG3 Осуществление верификации……………………………………………..... стр. 9

Приложение 1. Обзор средств автоматизации процесса верификации……….. стр. 11

Приложение 2. Основные современные подходы к верификации…………….. стр. 12

Список использованной литературы…………………………………………….. стр. 14

Интегрированнаяя модель совершенства и зрелости

ВЕРИФИКАЦИЯ

(Уровень зрелости 3)

Цель

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

Водные замечания

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

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

определение соответствия высокоуровневых требований требованиям к системе;

учет высокоуровневых требований в архитектуре системы;

соблюдение архитектуры и требований к ней в исходном коде;

определение соответствия исполняемого кода требованиям к системе;

определение средств, используемых для решения вышеперечисленных задач, которые технически корректны и достаточно полны.

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

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

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

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

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

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

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

Экспертизы включают в себя методическое исследование производимых работ экспертами, с целью выявить дефекты и другие требуемые изменения.

Основными методами экспертного оценивания являются:

осмотр

сквозной структурный контроль

3. Специальные и общие целевые задачи

3.1 Специальные целевые задачи :

SG 1 Готовьтесь к верификации

SG 2

SG 3

3.2 Общие целевые задачи :

GG 1 Достигайте специальных целей

GG 2 Поставьте управляемый про цесс

GG 3 Поставьте определенный процесс

GG 4 Поставьте количественно определенный процесс

GG 5 Поставьте оптимизационный процесс

4. Ожидаемая практика по целевым задачам

SG 1 Готовьтесь к верификации

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

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

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

В целом, на данном этапе можно выделить следующий круг основных задач:

Должны быть определены необходимость наличия в проекте работ по верификации и степень организационной независимости при проведении данных работ. Проектные требования должны быть проанализированы на критичность. Критичность может быть оценена с точки зрения:

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

совершенства используемой технологии программирования и рисков, связанных с ее применением;

доступности фондов и ресурсов.

Если проект предусматривает работы по верификации, должен быть установлен процесс верификации для проверки программного продукта.

Если проект предусматривает работы по независимой верификации, должна быть выбрана квалифицированная организация, ответственная за проведение верификации. Данной организации должны быть гарантированы независимость и полномочия при проведении работ по верификации.

SP 1.1-1 Устанавливайте верификационную стратегию

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

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

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

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

Для разработки программного обеспечения

Верификационные методы могут включать в себя следующие:

Тестирование зоны обслуживания

Эксплуатационное тестирование и тестирование в предельных режимах

Тестирование, основанное на таблице решений

Тестирование, основанное на функциональной декомпозиции

Тестирование случаев повторного использования

Альфа и Бета тестирование

Тестирование оперативного (рабочего) сценария

Приемочные тесты

Для интегрированной продукции технологического процесса

Верификационная стратегия должна развиваться параллельно и итеративно с процессом разработки продукции и ее компонент.

SP 1.1-2 Устанавливайте среду верификации

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

Тип требуемой среды верификации будет определяться верификационными критериями и используемыми верификационными методами.

Основная (типичная) продукция работ:

Оборудование верификации

Среда верификации

Вспомогательные работы:

1. Идентифицируйте требования к среде верификации

2 .Идентифицируйте доступные для повторного использования или модификации ресурсы на верификацию

3. Идентифицируйте оборудование и инструменты верификации

4. Приобретайте оборудование и программное обеспечение, используемые в обеспечение работ по верификации

SP 1.1-3 Определяйте детализированные верификационные планы

На данном этапе необходимо выполнение следующих работ:

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

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

Должен быть реализован план проведения верификации. Проблемы и несоответствия, обнаруженные при проведении верификации, должны быть введены в процесс решения проблем (подраздел 6.8). Все возникшие проблемы должны быть решены, а обнаруженные несоответствия устранены. Результаты работ по верификации должны быть доступны заказчику и другим органи­зациям, участвующим в договоре.

Вспомогательные работы:

1. Планируйте множество всесторонних, интегрированных верификационных работ

2 . Развивайте и повышайте по необходимости качества верификационных критериев

3. Для верификации каждой работы определяйте методы верификации

4. Определяйте ожидаемый результат

SG 2 Проводите экспертное оценивание

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

Экспертное оценивание преимущественно применяется для выходной продукции работ по проектам, однако также может быть использовано и для таких работ как документация и т.п.

SP 2.1-1 Готовьтесь к экспертному оцениванию

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

Основная продукция работ:

График экспертного оценивания

Контрольная таблица экспертного оценивания

Входные и выходные критерии для продукции работ

Критерии для перепроверки

Тренировочный материал для экспертного оценивания

Отобранная продукция работ, подлежащая экспертному оцениванию

Вспомогательные работы:

1. Определяйте, какой тип экспертного оценивания будет проводиться

Примеры возможных типов:

• сквозной структурный контроль

2 . Определяйте требования к собираемой информации в течении экспертного оценивания

3. Устанавливайте и поддерживайте входные и выходные критерии для отобранной продукции работ

4. Устанавливайте и поддерживайте критерии для перепроверки отобранной продукции работ

5. Устанавливайте и поддерживайте контрольную таблицу для гарантии того, что отобранной продукции работ осматривается единообразно

6. Убедитесь, что продукция работ удовлетворяет входным критериям экспертизы до того, как эти работы будут направлены на экспертизу.

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

8. Распределяйте роли для экспертизы.

Варианты ролей:

лидер (глава экспертизы)

читатель

протоколист

SP 2.2-1 Управляйте экспертным оцениванием

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

Экспертизы осуществляются по ключевым работам фаз спецификации, разработки, тестирования, составления сопроводительной документации, а также планирования (например, планирования развития софта, планирования управления рисками или планирование тестов).

Основное внимание экспертизы должно быть уделено продукции работ, подлежащей осмотру, а не лицу, которое реализовало эту продукцию.

Результаты и заключения экспертизы должны сообщаться главному разработчику данной продукции работ для возможной его коррекции.

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

Основная продукция работ:

Результаты экспертизы

Заключения экспертизы

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

Вспомогательные работы:

1. Осуществляйте в ходе экспертизы назначенные роли

2 . Устанавливайте и документируйте дефекты и другие результаты в продукции работ

3. Фиксируйте результаты экспертизы и документируйте производимые действия

4. Собирайте информацию (данные) в ходе проведения экспертизы

5. Сообщайте решения экспертиз организаторам совместного дела (ведущим разработчикам продукции работ)

6. Планируйте повторные экспертизы, в случае удовлетворения продукции их критериям

7. Убеждайтесь, что удовлетворяются выходные критерии экспертизы

8. Распределяйте роли для экспертизы.

Варианты ролей:

лидер (глава экспертизы)

читатель

протоколист

SP 2.3-2 Анализируйте полученную информацию

SG 3 Верифицируйте отобранные работы

SP 3.1-1 Осуществляйте верификацию

Типичная продукция работ:

Результаты верификации

Отчеты по верификации

Демонстрации

Вспомогательные работы:

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

2 . Осуществляйте верификацию продукции в соответствии с выбранной верификационной стратегией и процедурами

3. Фиксируйте результаты верификационных работ

Критерии верификации :

В целом можно выделить следующие критерии верификационного процесса на различных его стадиях:

Верификация процесса

Процесс должен быть верифицирован по следующим критериям:

соответствие и своевременность установления проектных требований к планированию;

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

применимость стандартов, процедур и условий к процессам проектирования;

укомплектованность и обученность персонала в соответствии с условиями договора.

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

Требования должны быть верифицированы по следующим критериям:

• непротиворечивость, выполнимость и тестируемость требований к системе;

  распределение требований к системе между объектами технических и программных средств и ручных операций в соответствии с проектом;

  непротиворечивость, выполнимость, тестируемость и точность отражения требований к системе в требованиях к программным средствам;

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

Верификация проекта

Проект должен быть верифицирован по следующим критериям:

правильность проекта, его соответствие установленным требованиям и учет этих требова­ний в проекте;

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

возможность выбора проекта, исходя из установленных требований;

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

Верификация программы

Программа должна быть верифицирована по следующим критериям:

учет в программе условий проекта и установленных требований; ее тестируемость, правиль­ность и соответствие установленным требованиям и стандартам программирования;

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

возможность выбора программы, исходя из проекта или установленных требований;

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

Верификация сборки

Сборка должна быть верифицирована по следующим критериям:

полнота и правильность сборки программных компонентов и модулей каждого программ­ного объекта в соответствующий программный объект;

полнота и правильность сборки технических и программных объектов и ручных операций в систему;

выполнение задач сборки в соответствии с планом сборки.

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

Документация должна быть верифицирована по следующим критериям:

соответствие, полнота и непротиворечивость документации;

своевременность подготовки документации;

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

SP 3.2-2 Анализируйте результаты верификации и определяйте корректирующие действия

Для определения степени приемлемости действительные результаты должны быть подвержены сравнению с установленными верификационными критериями.

Результаты анализа фиксируются как свидетельство того, что верификация была управляема.

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

Основная продукция работ:

Аналитический отчет (статистика, анализ несоответсвий, сравнение поведения реальной продукции и ее модели, отклонения и т.д.)

Набор корректирующих мер по исправлению выявленных недостатков

SP 3.3-1 Осуществляйте ре-Верификацию (повторную верификацию)

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

Повторная верификация, как правило, детально фокусируется на тех частях продукций работ, в которых были обнаружены те или иные дефекты.

Приложение 1. Обзор средств автоматизации процесса верификации

На рынке существует множество продуктов, позволяющих автоматизировать процесс верификации. Среди них Purify, TestCenter, Logiscope и др. Пакет Logiscope компании Verilog - это семейство инструментальных программ (TestChecker, CodeChecker, RuleChecker, ImpactChecker и Viewer), объединенных общей целью: помочь пользователям улучшить качество и провести всестороннее тестирование создаваемого ПО. В основе продукта лежит идея анализа исходного кода . Его последняя версия способна обрабатывать тексты программ, написанные более чем на 80 языках, включая C, C++, Pascal, Cobol, Fortran, PL1, ADA и даже языки ассемблера Intel и Motorola. Результаты анализа представляются в виде числовых показателей (метрик, которых существует более 50 типов), позволяющих судить о качестве исходного кода программ. Компонент TestChecker наблюдает за поведением тестируемой программы в ходе ее исполнения и в процессе своей работы строит деревья вызовов, профили выполнения, отмечает невызываемые функции и неисполняемые процедуры. Logiscope поддерживает функцию обратного проектирования, c помощью которой можно восстановить структуру программы по объектному коду, что полезно для понимания логики ее работы и характера используемых данных.

Специально для профессиональных программистов на языках C и С++ предназначена программа TestCenter компании CenterLine. Из статистических данных следует, что при обычном тестировании проверяется "исполнимость" только 40 - 50% общего кода программ. Объясняется это тем, что при традиционном, "ручном", тестировании невозможно проверить работу программы со всеми возможными комбинациями исходных данных или смоделировать редко встречающиеся ошибки типа нехватки памяти (out of memory). При таких процедурах тестирования трудно говорить о высоком качестве готовых программ. Пакет TestCenter позволяет организовать глобальное тестирование ПО на промышленном уровне, а само тестирование сделать естественной частью процесса разработки за счет его непосредственной интеграции с другими известными инструментальными оболочками (SPARCworks, SoftBench, ObjectCenter и ObjectCode).

В процессе отладки/тестирования программ TestCenter показывает строки исходного кода, не исполняемые во время проведения теста, неинициализированные участки памяти, память, которая резервировалась, но не использовалась, использовалась, но не освобождалась, случаи неверного применения операторов malloc/free и др. Имитатор ошибок (Error Simulator) может генерировать редко встречающиеся и трудно отлаживаемые ошибки типа disk full (нет места на диске) или упомянутой out of memory, а имитатор API (Simulator API) - интерфейсные ошибки, например неправильный порядок аргументов при вызове функций или некорректный код возврата. При использовании TestCenter не возникает необходимости в перекомпиляции программ, а для работы Error Simulator не понадобится даже исходного кода тестируемой программы.

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

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

Рис. 1 Тестирование, верификация и валидация

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

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

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

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

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

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

Или еще пример. Предприятие выпускает трубы, предназначенные для закладки в землю, в соответствии с некоторыми ТУ (Техническими условиями). Продукция этим ТУ соответствует, но поступил заказ, предполагающий укладку труб по дну моря. Могут ли трубы, соответствующие имеющимся ТУ, быть применены в данном случае? Именно валидация и дает ответ на этот вопрос.

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

Таким образом, можно констатировать следующее:

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

Валидация — проводится при необходимости, выполняется методом анализа заданных условий применения и оценки соответствия характеристик продукции этим требованиям, результатом является вывод о возможности применения продукции для конкретных условий.

Исходя из вышеописанного, валидация должна быть определена как подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, точно и в полном объёме предопределены, а цель достигнута.

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

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

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

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

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

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

Различие между верификацией и валидацией проиллюстрировано на рисунке 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.