Команды, разрабатывающие микросхемы и электронные системы, сталкиваются с проблемой, которая выходит за рамки увеличения числа тестов или автоматизации регрессионных процессов. По мере перехода продуктов к архитектурам, в большей степени зависящим от программного обеспечения, и интеграции аппаратных компонентов, программного обеспечения и подсистем доказательства верификации распределяются между различными инструментами, командами и этапами, тогда как требования и настройки меняются, а интеллектуальная собственность повторно используется в новых контекстах.
В этом контексте Jake Wiltgen и Mike Andrews считают, что основная задача заключается в сохранении смысла и взаимосвязей на протяжении жизненного цикла, а не просто в создании большего числа записей. В опубликованном материале в формате Sponsor Blog предлагается концепция «нити верификации» как структурированной цифровой связи между требованиями, критериями, действиями по верификации, настройками и результатами.
Проблема не в недостатке данных
Среды верификации уже создают записи, временные диаграммы, сигналы, подтверждения, показатели покрытия и результаты успешного или неуспешного выполнения. Однако сам по себе успешный результат теста не объясняет, какое требование он охватывал, а также какие версия проекта, среда тестирования и настройки использовались или какие предположения лежали в основе сценария.
То же относится и к показателям покрытия. Они указывают на активность или прогресс, но сами по себе не доказывают достаточность верификации. Когда требования или настройки меняются, команды вынуждены вручную восстанавливать контекст, чтобы определить затронутые тесты и понять, сохраняют ли прежние результаты силу.
Что добавляет нить верификации?
Авторы предлагают рассматривать каждое событие верификации как повторно используемое инженерное доказательство, а не просто как строку в отчете о регрессии. Это включает связывание действия с требованием или инженерным замыслом, а также регистрацию критериев, версии проекта, среды выполнения, стимулов, ограничений и связанных доказательств.
Такая взаимосвязь позволяет командам перейти от фразы «мы провели тест» к более точному ответу: как было проверено требование, при каких условиях, с помощью каких доказательств и какие пробелы остаются? Она также помогает оценивать применимость прежних результатов при повторном использовании модулей или разработке производных проектов, вместо того чтобы случайным образом повторять работу или исключать ее без анализа.
От интеграции инструментов к унификации смысла
В материале подчеркивается, что связывания приложений или обмена файлами недостаточно для построения настоящей нити верификации. Верификация аппаратного обеспечения, верификация программного обеспечения, системные тесты, анализы безопасности и управление требованиями используют разные абстракции и критерии успеха.
Поэтому предложенной модели необходимы общие значения, связывающие требования, критерии, настройки и объекты доказательств, даже если они возникают в разных средах. В результате формируется нечто похожее на инженерную сеть знаний, с помощью которой можно выявлять отсутствующие, дублирующиеся или устаревшие доказательства и отслеживать влияние изменения требования на связанные с ним тесты и результаты.
Почему это важно?
Важность этого подхода заключается в том, что он переопределяет верификацию как непрерывную инженерную архитектуру, а не как последующий этап документирования. Разработка, распределенная между командами, поставщиками и географически разными площадками, снижает зависимость от неявных знаний, а рост стоимости задержек и неопределенности на этапах сертификации повышает значение полноты и доказательной защищенности материалов.
Однако в материале содержится четкое ограничение: инструмент или цифровая нить не могут исправить неясные требования, неопределенные критерии или доказательства, регистрируемые непоследовательно. Успех подхода требует разложения требований на проверяемые ожидания, явного определения критериев и регистрации событий верификации в структурированной форме.
Согласно представленным фактам, основная практическая ценность заключается не в добавлении новой информационной панели, а в том, чтобы сделать результаты верификации понятными, повторно используемыми и пригодными для анализа влияния. Упоминание решения Questa One VeriThreader и белой книги «Rethinking Traceability for Modern Systems» приводится в конце рекламного материала и не содержит достаточно независимых подробностей для оценки продукта или его сравнения с другими альтернативами.