Документ должен быть написан на языке заказчика или пользователя.
Информация в документе должна быть уместна и полезна для читателя.
Информация в документе должна быть упорядочена в соответствии с утвержденным общим шаблоном.
Информация в документе должна быть полной, не должно быть нераскрытых ссылок, типа «будет определено позже».
Все определения должны быть однозначными.
Все формулировки должны быть четкими и краткими.
Изложение в документе должно быть единообразным по терминологии. Это означает, что одно и то же слово должно использоваться для одного и того же понятия каждый раз, когда оно упоминается.
Документ не должен содержать избыточной или копируемой информации.
Должны быть указаны источники данных, для возможности их верификации.
В процессе разработки необходимо выдерживать важный принцип «Сделай это правильно с первого раза» потому, что низкое качество исполнения обычно приводит к большим потерям проекта из-за необходимости последующих исправлений. Еще один практический принцип гласит, что ошибаются все инженеры, но профессионалом становится только тот, кто обнаруживает свои ошибки самостоятельно. Среди причин неудач новых продуктов отмечены отсутствие маркетинговых исследований, плохо реализованные проекты разработки, интерфейс, слабое экономическое обоснование, недостаточный объем испытаний. Большинство недостатков возникает на начальной стадии инновационного процесса. При дефектах качества очевидны провалы управления.
2.6 Верификация и валидация
Важными звеньями процесса инновационных ОКР являются верификация и валидация результатов.
На основе технического проекта выполняют документирование разработанной системной архитектуры нижнего уровня элементов системы, проверку сборочных моделей, и передачу в производство опытных образцов. Для подтверждения требований к характеристикам системы используют процесс верификации, или подтверждения того, что требование или система соответствует входным данным. Верификация требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию? Это процесс снижения рисков перед переходом к следующему этапу, чтобы выявить отклонения, несоответствия или дефекты во всех элементах путем интеграции системы, чтобы избежать превышения бюджета из-за ненужной доработки.
Верификация ориентирована на компоненты и подсистемы, и проводится:
в процессе разработки;
чтобы убедиться, что утвержденные требования будут выполнены;
как правило, в лабораторных условиях.
Задачи процесса верификации:
демонстрация соответствия конструкции и характеристик установленным требованиям на заданных уровнях;
обеспечение соответствия продукта разработанному проекту, отсутствия дефектов производства и пригодности к применению;
подтверждение способности компонентов системы выполнять требования для интеграции;
документирование результатов проверки, в том числе анализа рисков, результатов испытаний, отклонений и проверенных решений проекта в хранилище данных.
Перечислим основные методы верификации:
A. Инспекция (осмотр). Визуальное исследование реализованного продукта для верификации физических параметров или конкретной идентификации производителя. Например, визуальный осмотр на отсутствие следов износа, или ударов и повреждений при транспортировке изделия.
B. Анализ. Применение математического моделирования и аналитических методик с целью прогнозирования соответствия конструкции системным требованиям на основании расчетных данных или результатов верификации компонентов нижестоящих уровней системной структуры.
C. Демонстрация. Это базовое подтверждение рабочей характеристики, которое отличается от испытания отсутствием сбора детальных данных. Показывает, что применение конечного продукта выполняет установленное индивидуальное требование. Например, требование об обеспечении доступа водителя ко всем органам управления автомобилем может быть проверено экспертом на макете кабины или тренажере.
D. Испытания. Это проверки на стенде работы конечного продукта или подсистемы с целью получения детальных характеристик. Проводятся на готовых конечных продуктах, функциональных макетах, экспериментальных образцах или прототипах. При испытаниях измеряют различные технические характеристики в сравнении с их целевыми значениями, чтобы убедиться, что система соответствует заявленным требованиям.
В заключение разработки проводится валидация системы или продукта, с участием заказчика. Валидация представляет процесс подтверждения того, что набор требований, проект или система соответствует предназначению заказчика. Отвечает на вопрос: построили ли вы правильную систему для решения проблемы? Как правило, проводится с привлечением внешних инстанций, регулирующих органов, представителей заказчика, межведомственных комиссий, и др. Продукт тестируют во всех типах ситуаций (сценариев использования), ожидаемых в течение срока службы продукта, и проводят валидационные оценки работы системы или ее элементов в эксплуатационной среде. Они включают операционную эффективность, пригодность, устойчивость, нейтральность к окружающей среде и живучесть. В процессе можно использовать любую динамическую модель, макеты и прототипы продукта, чтобы непредвзято доказать, что разрабатываемый дизайн соответствует потребностям пользователя. Результаты испытаний используются для доказательства того, будет ли продукт приемлемым для потребителей. Обнаруживаемые дефекты валидации системы могут включать чрезмерную чувствительность модели к определенному параметру или требованию, несоответствия между моделью и реальной системой, и неудачный дизайн.
Целями процесса валидации продукта является подтверждение того, что:
был реализован нужный продукт, который необходим заказчику;
обеспечены заданные показатели эффективности;
созданный продукт пригоден для целевого применения в заданной среде.
Необходимо различать процессы верификации и валидации продукта. Эти процессы могут быть схожими по содержанию, но их цели существенно различаются. Различие между верификацией и валидацией можно лучше понять, исходя из уровня применения. Валидация обычно выполняется на уровне продукта. Цикл верификации обычно оценивает системы, подсистемы или компоненты, которые содержат функции более низкого уровня (по сравнению с уровнем продукта).
Ответы на оба традиционных вопроса: «Правильно ли мы строим систему?» (верификация) и «Правильную ли систему мы построили?» (валидация) будут нужны на протяжении всего жизненного цикла.
Верификация требований нужна как доказательство того, что каждое требование было удовлетворено. Она может осуществляться путем логических аргументов, инспекции, моделирования, динамического моделирования, анализа, экспертной оценки, испытаний или демонстрации. Для целей верификации или валидации могут использоваться различные виды испытаний. Процесс испытаний и оценки системы включает проверку работы подсистем при объединении в целостную систему; оценку обоснованности проектных допущений; и проверку работы системы в различных условиях и режимах работы. Чтобы свести к минимуму необходимость перепроектировать всю систему из-за неисправных компонентов, на испытаниях следует двигаться «снизу вверх», сначала исследовать компоненты, затем подсистемы, и в финале работу всей системы. Собранные данные анализируют, чтобы определить, соответствуют ли продукт, или его компоненты заявленным требованиям.
На этапе интеграции системы или продукта выполняется верификация модулей и сборок нижних уровней, чтобы убедиться, что утвержденные требования будут выполнены. Она проводится, как правило, в лабораторных условиях, и ориентирована на компоненты и подсистемы. Необходимо документировать результаты испытаний, корректирующих действий, отклонений и проверенных решений проекта. Успешная верификация системы или ее компонента подтверждает, что синтез системы выполнен правильно, и она соответствует требованиям. При так называемых стресс-тестах к системе прилагается дополнительная испытательная нагрузка, чтобы определить ее способность работать в более тяжелых, чем это планировалось, условиях.
Валидация требований означает обеспечение того, что набор требований является правильным, полным и последовательным; может быть создана модель, удовлетворяющая требованиям; может быть построено и протестировано реальное решение, чтобы доказать, что оно удовлетворяет требованиям. Если обнаружится, что заказчик запросил вечный двигатель, проект следует остановить.
Дефекты валидации требований включают:
1) неполные или противоречивые наборы требований или вариантов использования;
2) требования, которые не соответствуют требованиям верхнего уровня или концепции эксплуатации;
3) чрезмерную чувствительность модели к определенному параметру или требованию;
4) несоответствия между результатами динамического моделирования и реальной системой;
5) тестовые примеры, которые не отслеживают полный набор сценариев (вариантов использования).
Валидация обычно выполняется в реальных или смоделированных условиях эксплуатации, в процессе или после процедуры интеграции системы. Выявленные недостатки, а также рекомендуемые корректирующие действия и результаты должны быть документированы. По результатам валидации требуется обеспечить устранение выявленных проблем до поставки реализованного продукта.
Также в процессе валидации проверяют работоспособность системы в так называемых нерасчетных условиях эксплуатации (аварийные ситуации, устойчивость к внешним воздействиям, и др.). Иногда необходимо оценить ряд специфических вопросов. Например, могут ли использовать систему люди, которые находятся в стрессовых ситуациях (например, операторы электростанций, полиция, диспетчеры скорой помощи), допустив разумное количество ошибок.
В нашей практике подрядчикам поручили спроектировать и изготовить поворотный дроссель для перекрытия входного участка трубопровода на испытательном стенде. На сборке дроссель работал нормально, а после установки на стенд при прокачке потока воздуха дроссель заклинило. Усилий гидравлического привода не хватало для поворота сектора заслонки. Пригласили экспертов и начали задавать вопросы:
Какие материалы были выбраны при анализе поворотной части дросселя?
Подходят ли допустимые пределы прочности деталей для этого использования?
Какие допущения приняты при моделировании работы поворотного сочленения для учета условий окружающей среды?
Что потребуется, в части времени и ресурсов, для изменения механизма?
Существуют ли прототипы механизма, которые можно было бы включить в проект, даже если они не совсем отвечали заданным требованиям?
Причина заклинивания поворотной заслонки при работе стенда оказалась в том, что при прокачке скоростного потока воздуха на дроссельной заслонке возникал перепад давлений, который прижимал поворотную часть к неподвижной с большим усилием. Для доработки дросселя было предложено снизить возникающую силу трения путем разделения поворотной заслонки и неподвижного диска шариковыми шарнирами. Через неделю стенд был введен в строй.
При валидации сложного продукта также требуется заранее сформировать комплексный план. Он включает согласованный набор испытаний и оценок результатов с входными данными и целевыми ожиданиями продукта соответственно утвержденным требованиям заинтересованных сторон (пользователей, экспертов, заказчиков, инвесторов, а также регуляторов, ответственных за разработку и обеспечение соблюдения нормативных требований к продукту).
Задача оценки результатов верификации и валидации может состоять из множества шагов или подзадач. Например, задача посадки в транспортное средство будет включать в себя выполнение пользователем ряда подзадач, таких как отпирание двери, открытие двери, вход в транспортное средство, посадка на сиденье водителя, и закрытие двери.
При валидации план испытаний системы в целом может быть достаточно объемным. Типичная высокотехнологичная система насчитывает от 1000 до 10 000 требований. Какие-то из них можно проверить одновременно, с помощью набора связанных действий. При этом снижается стоимость программы испытаний. Планирование процедур верификации и валидации узлов и компонентов осуществляется еще на ранних стадиях проекта с учетом потребных сроков на проектирование и изготовление стендов и моделей. В ходе верификационных процедур удобно использовать типовые вопросники (чек-листы), составленные и пополняемые с учетом традиций компании и накапливающегося опыта. На этапе валидации завершается процесс разработки системы.
Типы оценок результатов испытаний можно разделить на объективные и субъективные. К объективным данным относят такие, на которые не влияет человек. Субъективные измерения обычно основаны на восприятии и опыте оценщика во время выполнения задач по использованию продукта. Объективные показатели более точны и беспристрастны. Удовлетворенность клиентов, вероятно, является наиболее важной субъективной мерой проверки продукта, которую можно оценить, общаясь непосредственно с пользователями.
Субъективными методами измерения, используемыми в процессе разработки продукта, являются, например, оценка по шкале и методы, основанные на парном сравнении. Для определения рейтинга по шкале оценщику сначала дают инструкции по процедуре оценки продукта, включая пояснения по шкалам оценки, которые должны использоваться для масштабирования каждого свойства. Шкалы интервалов могут различаться по определению конечных точек шкал, количества используемых интервалов. При этом для сравнения продуктов используют следующие варианты оценки:
число предпочтительных оценок, то есть сумма испытуемых, которые оценили продукт в интервале выше среднего;
количество непредпочтительных оценок, то есть сумма испытуемых, которые оценили продукт в интервале ниже среднего;
отношение числа предпочтительных оценок к числу непредпочтительных;
среднее значение оценок;
стандартное отклонение оценок.
В методе парного сравнения каждого испытуемого просят сравнить два продукта в выбранной паре с использованием заранее определенной процедуры и определить лучший продукт на основе заданного свойства (например, комфорта или удобства использования). Задача оценки здесь проще по сравнению с оценкой по шкале, поскольку эксперт должен сравнивать только два продукта в каждом испытании, и определять лучший продукт в паре. Основное преимущество метода парного сравнения заключается в том, что он делает задачи оценки субъекта простыми и более точными. Однако, если необходимо оценить несколько продуктов, то оценщик должен пройти через каждую комбинацию из возможных пар и определить лучший продукт в каждой паре, что делает процесс оценки очень трудоемким.