Необходимо различать процессы верификации и валидации продукта. Эти процессы могут быть схожими по содержанию, но их цели существенно различаются. Различие между верификацией и валидацией можно лучше понять, исходя из уровня применения. Валидация обычно выполняется на уровне продукта. Цикл верификации обычно оценивает системы, подсистемы или компоненты, которые содержат функции более низкого уровня (по сравнению с уровнем продукта).
Ответы на оба традиционных вопроса: «Правильно ли мы строим систему?» (верификация) и «Правильную ли систему мы построили?» (валидация) будут нужны на протяжении всего жизненного цикла.
Продукт тестируют во всех типах ситуаций (сценариев использования), ожидаемых в течение срока службы продукта
Перечислим основные методы верификации:
A. Инспекция (осмотр). Визуальное исследование реализованного продукта для верификации физических параметров или конкретной идентификации производителя. Например, визуальный осмотр на отсутствие следов износа, или ударов и повреждений при транспортировке изделия.
B. Анализ. Применение математического моделирования и аналитических методик с целью прогнозирования соответствия конструкции системным требованиям на основании расчетных данных или результатов верификации компонентов нижестоящих уровней системной структуры.
C. Демонстрация. Это базовое подтверждение рабочей характеристики, которое отличается от испытания отсутствием сбора детальных данных. Показывает, что применение конечного продукта выполняет установленное индивидуальное требование. Например, требование об обеспечении доступа водителя ко всем органам управления автомобилем может быть проверено экспертом на макете кабины или тренажере.
D. Испытания. Это проверки на стенде работы конечного продукта или подсистемы с целью получения детальных характеристик. Проводятся на готовых конечных продуктах, функциональных макетах, экспериментальных образцах или прототипах. При испытаниях измеряют различные технические характеристики в сравнении с их целевыми значениями, чтобы убедиться, что система соответствует заявленным требованиям.
На основе технического проекта выполняют документирование разработанной системной архитектуры нижнего уровня элементов системы, проверку сборочных моделей, и передачу в производство опытных образцов. Для подтверждения требований к характеристикам системы используют процесс верификации, или подтверждения того, что требование или система соответствует входным данным. Верификация требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию?
В процессе разработки необходимо выдерживать важный принцип «Сделай это правильно с первого раза»
5. Создание чертежей и пространственных моделей деталей, узлов и сборочных единиц. На практике приходилось проверять 3-Д сборочные узлы объемом до пятидесяти тысяч входящих единиц деталей.
6. Проведение подробного инженерного анализа, включающего выбор материала, оценку функциональных возможностей с использованием доступных моделей, а также создание прототипов деталей и тестирование для проверки того, что конструкция каждого компонента соответствует заявленным требованиям.
7. Выполнение анализа видов и последствий отказов перед запуском проекта в производство.
8. Сборка проверенных компонентов в модули и подсистемы более низкого уровня и проведение испытаний для проверки соответствия собранных подсистем и компонентов заданным требованиям.
9. Выполнение финальной сборки для создания продукта в целом.
10. Проведение валидации продукта, чтобы убедиться, что он соответствует всем заявленным требованиям, прежде чем будет запущен в производство.
11. Документирование набора технических данных продукта.
Процесс разработки РКД на основе технического проекта обычно включает следующие типовые шаги:
1. Документирование, уточнение и передача спецификаций продукта членам команды. Спецификации продукта включают его характеристики, размеры, функции, производительность для выполнения требований.
2. Формирование набора требований регуляторов (государственных и отраслевых), применимых к продукту в течение всего его жизненного цикла.
3. Уточнение конфигурации продукта для подсистем более низкого уровня вплоть до уровня компонентов.
4. Определение всех интерфейсов (между системами и их нижестоящими системами и компонентами) и разработка требований ко всем интерфейсам (глава 3.6).
Рекомендуется назначать разумные допуски в пределах технологических возможностей обычного производственного оборудования. Чрезмерно жесткие допуски являются дорогостоящим способом гарантировать получение характеристик разработчиками
Следует исключать «авторское сопровождение» выпуска продукции (кое-где осталось под видом исторического наследия), чтобы компенсировать трудности, вызванные непроизводительной конструкцией продукта или процесса. Нужно ясно и понятно документировать техпроцессы проекта на уровень квалификации и опыта работников производственной линии.
При реализации инноваций может пригодиться база проверенных эмпирических правил для нового проекта:
1. Полезно держать на виду перечень показателей эффективности, ПЭ, см. главу 3.7.
2. Активно использовать располагаемое моделирование для проектирования систем.
3. Рекомендуется сначала выполнять работу с высокорисковыми компонентами.
4. Следует уделить нужное внимание конструированию интерфейсов системы.
5. Свои ошибки инженеры должны находить сами.
6. Стараться выделить каждую функцию для только одного компонента.
7. Применять, где можно, быстрое прототипирование (аддитивные технологии).
8. Следует проектировать компоненты с возможностью их изолированного испытания.
9. Оценивать влияние альтернативных вариантов на характеристики конструкции.
10. Убедиться, что задачи понятны сотрудникам, контролируются и выполняются.
11. Поощрять подчиненных задавать вопросы по любому пункту приказов или указаний менеджера, которые они не понимают.
12. Мотивировать сотрудников решать каждую задачу, как их собственную.
13. Проявлять осторожность в наблюдении за процессом. Чрезмерный надзор вредит инициативе, под навязчивым присмотром сотрудники работают хуже.