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

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

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

1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.

2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.

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

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

5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.

6. Созданная система не соответствует описанию.

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

Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.

Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация - это в том числе проверка описания на непротиворечивость, полноту и понятность.

Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.

Тезис Дюэма - Куайна
Метаязык Тексты Основные начала
Течения Эмпириокритицизм , Махизм
Люди Конт , Тэн , Милль , Спенсер

В различных сферах деятельности человека под верифика́цией (от лат. verus - «истинный» и facere - «делать») могут подразумеваться разные понятия. Например:

• Верификация - это подтверждение соответствия конечного продукта предопределённым эталонным требованиям.

• Верификация - методика распознавания лжи (укрывательства, искажения).

В значении доказуемости, проверяемости объяснений (моделей) объектов /явлений , в зависимости от степени подтверждаемости реальностью (эмпирически , фактами), образует понятия :

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

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

Wikimedia Foundation . 2010 .

Синонимы :

Смотреть что такое "Верификация" в других словарях:

- (этим. см. предыд. сл.). Удостоверение, проверка. Словарь иностранных слов, вошедших в состав русского языка. Чудинов А.Н., 1910. ВЕРИФИКАЦИЯ свидетельство, удостоверение в подлинности. Словарь иностранных слов, вошедших в состав русского языка.… … Словарь иностранных слов русского языка

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

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

Верификация - Верификация ♦ Verification Проверка истинности высказывания с целью его оценки. Так, расчет можно проверить, повторив ту же операцию или проделав другую, а гипотезу – посредством опыта. Правда, остается вопрос об истинности самой проверки –… … Философский словарь Спонвиля

В культурологии (позднелат. verificatio доказательство, подтверждение верности или истинности чего либо; от лат. verus истинный и facio делаю) установление истинности тех или иных суждений (утверждений и отрицаний) о культуре в знании о… … Энциклопедия культурологии

Проверка, сличение, подтверждение, свидетельство Словарь русских синонимов. верификация сущ., кол во синонимов: 5 валидация (4) … Словарь синонимов

верификация - и, ж. vérification f. Свидетельство, удостоверение в подлинности. СИС 1954. Не для суеты, но для оного я в сие плодовитое описание вошел; некие происшествия я забыл и не помню верификациев чисел и имян, не писавши у себя никогда никаких записок.… … Исторический словарь галлицизмов русского языка

Верификация - (лат. verificatio дәлел, растау) – ғылыми ақиқат пен оның деректері (мәліметтері) эмпирикалық, яғни тәжірибелік тексеру арқылы айқындалады деген әдістемелік концепция, принцип. Ол логикалық позитивизм мен аналитикалық философияның бір тармағы… … Философиялық терминдердің сөздігі

верификация - контроль проверка Установление соответствия принятой и переданной информации с помощью логических методов . верификация (ITIL Service Transition) Деятельность, которая… … Справочник технического переводчика

Англ. verification А. Проверка подлинности, правильности оформления документов, материалов. Б.Процесс сличения копии с оригиналом Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов

- (от латинского verus истинный и facio делаю), проверка, эмпирическое подтверждение теоретических положений науки путем сопоставления их с наблюдаемыми объектами, фактическими данными, экспериментом … Современная энциклопедия

Книги

• Верификация гипотезы М. Фарадея о силовых линиях в космосе. Силовые линии М. Фарадея в космосе , Серков Аркадий. Эта книга будет изготовлена в соответствии с Вашим заказом по технологии Print-on-Demand. Конкретизируя гипотезу М. Фарадея, гравитационное поле рассматривается как вязко-упругое тело,…

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

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

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

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

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

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

Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.

Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

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

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

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

Видео по теме

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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