칩 설계팀과 전자 시스템 설계팀은 테스트 수를 늘리거나 회귀 프로세스를 자동화하는 것 이상의 문제에 직면해 있다. 제품이 소프트웨어 의존도가 더 높은 아키텍처로 전환되고 하드웨어, 소프트웨어 및 서브시스템이 통합되면서 검증 증거는 서로 다른 도구와 팀, 단계에 분산되고 있으며, 요구사항과 설정은 변경되고 지식재산은 새로운 맥락에서 재사용되고 있다.
이러한 맥락에서 Jake Wiltgen과 Mike Andrews는 핵심 과제가 더 많은 기록을 생성하는 것이 아니라 수명 주기 전반에서 의미와 연결성을 유지하는 것이라고 본다. Sponsor Blog 형식으로 게재된 이 글은 검증 스레드라는 개념을 요구사항과 표준, 검증 활동, 설정 및 결과를 체계적으로 연결하는 디지털 연결로 제시한다.
문제는 데이터 부족이 아니다
검증 환경은 이미 기록, 파형, 신호, 확인 결과, 커버리지 지표, 성공 또는 실패 결과를 생성한다. 그러나 성공적인 테스트 결과만으로는 어떤 요구사항을 다뤘는지, 어떤 설계 버전과 테스트 환경 및 설정이 사용되었는지, 또는 시나리오를 규정한 가정이 무엇이었는지를 설명할 수 없다.
커버리지 수치도 마찬가지다. 커버리지 수치는 활동이나 진행 상황을 나타내지만, 그것만으로 검증이 충분하다는 사실을 입증하지는 못한다. 요구사항이나 설정이 변경되면 팀은 영향을 받는 테스트가 무엇인지, 이전 결과가 여전히 유효한지를 파악하기 위해 맥락을 수작업으로 재구성해야 한다.
검증 스레드는 무엇을 더하는가?
두 저자는 각 검증 이벤트를 회귀 보고서의 단순한 한 줄이 아니라 재사용 가능한 엔지니어링 증거로 다룰 것을 제안한다. 여기에는 활동을 요구사항 또는 엔지니어링 의도에 연결하고, 기준, 설계 버전, 실행 환경, 자극, 제약조건 및 관련 증거를 기록하는 일이 포함된다.
이러한 연결을 통해 팀은 «테스트를 수행했다»는 말에서 벗어나 더 구체적인 답변으로 나아갈 수 있다. 즉 요구사항을 어떻게 검증했는지, 어떤 조건에서 검증했는지, 어떤 증거를 사용했는지, 어떤 격차가 남아 있는지를 파악할 수 있다. 또한 모듈을 재사용하거나 파생 설계를 개발할 때 이전 결과의 유효성을 평가하는 데 도움이 되므로, 작업을 무작위로 반복하거나 분석 없이 배제하는 일을 줄일 수 있다.
도구 통합에서 의미의 통합으로
이 글은 애플리케이션을 연결하거나 파일을 교환하는 것만으로는 진정한 검증 스레드를 구축하기에 충분하지 않다고 강조한다. 하드웨어 검증, 소프트웨어 검증, 시스템 테스트, 안전성 분석 및 요구사항 관리는 서로 다른 추상화와 성공 기준을 사용한다.
따라서 제안된 모델은 서로 다른 환경에서 생성된 경우에도 요구사항, 기준, 설정 및 증거 객체를 연결하는 공통 의미를 필요로 한다. 그 결과는 누락되었거나 중복되었거나 오래된 증거를 식별하고, 요구사항 변경이 관련 테스트와 결과에 미치는 영향을 추적할 수 있는 엔지니어링 지식 네트워크와 유사한 형태가 된다.
이 소식이 중요한 이유
이 주장의 중요성은 검증을 나중에 수행하는 문서화 단계가 아니라 지속적인 엔지니어링 구조의 문제로 재정의한다는 데 있다. 서로 다른 팀과 공급업체, 지리적으로 분산된 장소 사이에서 진행되는 개발은 암묵적 지식에 대한 의존도를 낮추며, 승인 단계에서 지연과 모호성의 비용이 증가하는 상황에서는 증거의 완전성과 방어 가능성이 더욱 중요해진다.
그러나 이 글은 분명한 제약도 제시한다. 도구나 디지털 스레드만으로는 모호한 요구사항, 정의되지 않은 기준 또는 일관되지 않은 방식으로 기록된 증거를 해결할 수 없다. 이 접근 방식이 성공하려면 요구사항을 검증 가능한 기대사항으로 세분화하고, 기준을 명시적으로 만들며, 검증 이벤트를 구조화된 형태로 기록해야 한다.
제시된 사실에 따르면 실질적인 핵심 가치는 새로운 대시보드를 추가하는 데 있는 것이 아니라 검증 결과를 이해하고 재사용하며 영향 분석할 수 있도록 만드는 데 있다. 한편 Questa One VeriThreader 솔루션과 «Rethinking Traceability for Modern Systems» 백서에 대한 언급은 홍보성 글의 마지막 부분에 등장하며, 해당 제품을 평가하거나 다른 대안과 비교할 수 있을 만큼 독립적인 세부사항은 충분히 포함하지 않는다.