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

Валидация и верификация требований к системе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

Происхождение термина

Философский и научный термин «верификация» пришел в наш язык из латыни (от лат. verus — «истинный», и facere — «делать»). Он означает проверку какого-либо предположения на соответствие заранее сформулированным требованиям, стандартам или спецификациям. Содержание термина существенно меняется в зависимости от контекста.

Верификация в науке

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

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

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

Подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. (ИСО 9000:2000)

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

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

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

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

Верификация субъекта услуги

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

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

В русскоязычных медиа термин иногда используется в значении «проверка публикуемых фактов». Это чисто русский новояз, весь мир пользуется простым термином “fact cheking”, или «проверка фактов».

Валидация

Валидация на транспорте

Валидатором (от англ. valid – «действительный, правомерный») называют также специальное приспособление, с помощью которого проводят проверку электронных проездных документов. Таким образом определяют правомочность посадки пассажира в салон общественного транспорта. Часто валидатор совмещают с турникетом. Это позволяет экономить значительные средства на организации и проведении контроля оплаты проезда пассажирами. Применяют такие устройства также и для контроля прохода сотрудников на территорию предприятия.

Валидация в системе управления качеством

Формулировка в стандарте ИСО несколько невнятная и слишком похожа на определение «верификации».

«Валидация — подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены».

Основное отличие

В чем основное отличие верификации и валидации?

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

«-К пуговицам претензии есть?

-К лацканам претензии есть?

К рукавам претензии есть?

«-Костюм можно носить?

Основная задача верификации и валидации

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

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

Примеры верификации и валидации

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

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

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

Источник

Верификация проекта и разработки (П7.3.5)

На запланированных стадиях проектирования и разработки проводится верификация (проверка) проекта и разработки с целью оценки соответствия выходных данных требованиям к входным данным.

Верификация (проверка) проекта и разработки может проводиться одним или несколькими методами:

· сравнением требований к входу по отношению к выходу процесса;

· оценкой по отношению к аналогам;

· моделированием и испытаниями с целью контроля соответствия конкретным требованиям к входным данным.

Конкретные виды проверок предусматриваются план-графиками.

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

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

Ответственность за верификацию проекта и разработки в соответствии с направлениями деятельности возложена на определенные должностные лица, например:

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

· зам. директора по направлению «Механика»;

· зам. директора по направлению «Химия»;

· директор по проектированию объектов.

Непосредственное проведение работ возложено на отдел-исполнитель.

Источник

Верификация проекта: опыт атомной промышленности

Виталий Кононов
Генеральный директор, ЗАО «НЕОЛАНТ»
Владислав Тихоновский
К.т.н, директор Департамента информационных технологий энергетического комплекса, ЗАО «НЕОЛАНТ»
Дмитрий Доробин
Начальник отдела, ЗАО «НЕОЛАНТ»
Николай Сальников
Начальник отдела, ЗАО «НЕОЛАНТ»
Даниил Чуйко
Начальник отдела, ЗАО «НЕОЛАНТ»

Конкурентоспособность проектной команды сегодня обеспечивается использованием комплекса 2D и 3D САПР, систем управления проектом строительства и поставками материалов. Иными словами, речь идет о создании всеобъемлющей информационной модели (ИМ) проекта.
В статье представлены результаты практической реализации технологии верификации ИМ энергоблока АЭС, сочетающей возможности применения ручного и автоматического режимов проверки. Это первое в атомной отрасли России решение, включающее автоматизированный режим верификации проектных данных на соответствие требованиям проекта. В его основе — модуль интеграции, обеспечивающий связь между системой управления требованиями (СУТ) и единым хранилищем информации по проекту.

Информационная 6D­модель — это всеобъемлющее хранилище данных, касающихся объекта промышленной инфраструктуры и процесса его сооружения. Модель 6D возникает при дополнении данных инженерной 3D­модели графиками календарно­сетевого планирования (4D­координата — время), информацией о конфигурации, комплектации и поставке необходимых материалов и оборудования (5D­координата), а также о трудовых, финансовых и иных ресурсах (6D­координата).

Важным аспектом эффективного внедрения технологии — проектирования на основе информационной модели — является внедрение технологий верификации ИМ на соответствие требованиям проекта.

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

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

Из рекомендаций стандарта ИСО 9001 следует также необходимость создания технологии анализа и управления требованиями к проекту. Пункт 7.3.5. стандарта ИСО 9001 указывает: «Верификация должна осуществляться в соответствии с запланированными мероприятиями (п. 7.3.1), чтобы удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям».

Особенности ИТ­поддержки информационной модели и системы ее верификации в проекте ВВЭР­ТОИ

К особенностям проекта ВВЭР­ТОИ [1] относятся значительное количество требований к проекту и их сложная иерархичность, а также разнообразие ИТ­платформ, задействованных для поддержки элементов информационной модели.

Одним из базовых элементов ИТ­поддержки проекта ВВЭР­ТОИ стала информационная модель, построенная на базе технологии Multi­D [2]. Технология Multi­D в капитальном строительстве используется для обеспечения конкурентоспособности проектов по таким критериям, как сроки проектирования, стоимость строительства и стоимость эксплуатации объектов.

ИМ проекта ВВЭР­ТОИ на стадиях проектирования и сооружения энергоблока АЭС включает:

В качестве системы управления требованиями (СУТ) в ВВЭР­ТОИ используется платформа IBM Rational DOORS, стандарт де­факто для СУТ в практике компаний, входящих в TOP десяти мировых производителей на рынках высокотехнологичной продукции.

Инструментарий SmartPlant Enterprise используют в своих проектах такие компании мировой атомной индустрии, как General Electric, Toshiba, Hitachi, Westinghouse, AECL, Chinergy, Fluor, Mitsubishi Shaw Stone & Webster, Siemens. Этот список — практически весь пул компаний, проектирующих АЭС и оборудование для мировой атомной отрасли, выбор которых разделяют и ряд проектных организаций атомной отрасли России, ориентированных на работу с зарубежными заказчиками.

Oracle Primavera входит в число ИТ­продуктов, на основе которых Госкорпорация «Росатом» с 2009 года проводит масштабную трансформацию корпоративной ИТ­платформы.

Программные приложения ENOVIA и DELMIA использованы ОАО «НИАЭП» в технологии Multi­D для детального моделирования процессов строительно­монтажных работ.

Однако оборотной стороной выбора лучших платформ является разнообразие форматов данных и необходимость создания целого набора интеграционных модулей. Ведь необходимо обеспечить установление информационных связей между объектом «требование», содержащимся в СУТ, с элементами, входящими во все программные инструменты информационной модели проекта ВВЭР­ТОИ.

Логика верификации

На рис. 1 представлена предложенная для проекта ВВЭР­ТОИ логика верификации ИМ на соответствие требованиям на этапе проектирования.

На первом этапе архитектор­инженер в итерационном режиме формирует в СУТ полученные от заказчика требования 1­го уровня к проекту АЭС (предварительные технико­экономические требования) и согласует их с дизайн­центром ВВЭР­ТОИ.

Рис. 1. Общая схема верификации ИМ проекта ВВЭР-ТОИ

По завершении согласования дизайн­центр в рамках технического задания и частного технического задания формирует требования 2­го и 3­го уровня к проекту АЭС и согласует их с архитектором­инженером, который вводит и формализует эти требования в СУТ.

Следующий шаг дизайн­центра ВВЭР­ТОИ — координация элементов ИМ (элементы АЭС в системе управления инженерными данными (СУИД), задачи в системе календарно­сетевого планирования (СКСП) и т.д.) с предъявляемыми к ним требованиями. Установление связей возможно как в ручном, так и автоматическом режимах. Выбор режима определяется логикой конкретных решений по интеграции программных инструментов.

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

Рис. 2. Схема взаимодействия информационных систем в рамках проекта ВВЭР-ТОИ

На рис. 2 представлена схема взаимодействия программного инструментария в процедурах верификации требований. В приведенной схеме передача требований из СУТ в СУПОС производится через PLM­приложение Enovia, поддерживающее функционал предъявления требований к строительным операциям, моделируемым в DELMIA.

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

Рис. 3. Автоматическая и ручная верификация 6D-модели ВВЭР-ТОИ

Автоматическая верификация возможна, если требование в СУТ может быть параметризировано, то есть оно представляет собой конкретное требование к значению определенного свойства элемента 3D­модели, к задаче плана­графика, к записи в смете. Пример параметризуемого требования — указание: «Для уравнительных сосудов должна быть применена коррозионностойкая сталь марки 08Х18Н1 ОТ». Его можно связать с характеристикой «Материал» уравнительных сосудов в соответствующем программном инструменте ИМ проекта ВВЭР­ТОИ с помощью интеграционного модуля. Результат проверки — отчет о выявленных несоответствиях, полученный автоматически с помощью модуля интеграции.

Верификация в ручном режиме проводится, если требование в СУТ носит описательный характер (например, «Крепление трубопроводов должно быть осуществлено надежно, чтобы авария одного трубопровода не вызвала повреждения других»). В этом случае верификацией занимается специалист по верификации. Требование в СУТ может быть связано с элементом 3D­модели, задачей плана­графика или записью в смете в соответствующем программном инструменте с помощью интеграционного модуля для облегчения поиска специалистом необходимых для верификации данных. Результатом проверки является отчет, формируемый специалистом по верификации вручную.

Заметим, что в предложенной для проекта ВВЭР­ТОИ технологии методика верификации требований не меняется для любой стадии жизненного цикла АЭС [3]. Разница заключается лишь в проверяемых компонентах информационной модели и в программном инструменте, в котором верификация производится.

На пути к практической реализации концепции

В настоящее время специалистами «НЕОЛАНТ» разработан модуль интеграции для связывания объектов из SmartPlant Foundation (системы, оборудование, трубопроводы, арматура и пр.) или их параметров (давление, температура, класс безопасности, массогабаритные характеристики и пр.) с соответствующими им требованиями в СУТ на платформе Rational DOORS.

Интеграционный модуль разработки «НЕОЛАНТ» позволяет отслеживать выполнение требований для любого объекта АЭС и его свойств: от энергоблока АЭС в целом до конкретной характеристики экземпляра оборудования или документа. Предложенное решение позволяет обеспечить четкое соответствие многих тысяч элементов АЭС нескольким десяткам требований к проекту. Интеграционный модуль поддерживает связь «многие ко многим», то есть с любым требованием можно связать любое количество объектов, и наоборот. «Дерево» требований из Rational DOORS копируется в SmartPlant Foundation автоматически, и в SPF оно доступно только для чтения.

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

Источник

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

«Верификация должна осуществляться в соответствии с запланированными мероприятиями (7.3.1), чтобы удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4)» (ГОСТ Р ИСО 9001-2008).

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

Соотношение между верификацией и валидацией представлены на рисунке 12.1

Рисунок 12.1 – Соотношение между анализом, верификацией и валидацией

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

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

— выполнение альтернативных расчетов;

— сравнение новой разработки с аналогичными, выполненными ранее, если таковые имеются:

— проведение испытаний и демонстраций;

— анализ документации данной стадии разработки перед ее реализа­цией.

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

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

Потребители могут участвовать в процессе проверок, если это огово­рено в заказе.

Дата добавления: 2015-03-07 ; просмотров: 2733 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник