Traceability(추적성) and consistency(일관성) in Automotive SPICE®

[추적성(Traceability)]

기본적으로 Traceability는 두 가지 관점에서 추적성을 가져야 한다.

첫째, 엔지니어링 프로세스에서 Traceability는 아래 세 가지 항목에 대한 추적성을 보장해야 합니다. (위 그림의 파란색 글씨와 화살표)

1. V 모델의 왼쪽 프로세스에서, 영향을 받는 엔지니어링 작업 산출물의 개별(atomic) 요구사항 또는 구조화된(clustered) 기능 항목들에 대한 추적성 (예, 시스템 요구사항 – 시스템 설계 – 소프트웨어 요구사항 – 소프트웨어 아키텍처, – 소프트웨어 단위설계 – 소스코드)
2. V 모델의 왼쪽에서의 요구사항 및 설계 항목과 오른쪽에서 이에 대응되는 프로세스의 테스트 명세(테스트 케이스들)의 추적성 (예, 시스템 아키텍처-시스템통합 테스트 케이스 등)
3. V 모델의 오른쪽에서 테스트 명세(테스트 케이스들)와 테스트 결과들 (예, 시스템 통합 테스트 케이스 – 시스템 통합 테스트 결과)의 추적성이며, 테스트 결과는 단순 Pass/Fail이 아닌 테스트 수행 Log들의 추적성이 보장되어야 한다.

둘째, 변경관리 프로세스에서 Traceability는 아래 두 가지 항목에 대한 추적성을 보장해야 합니다.

1. 변경 요청과 이에 대응되는 문제점(결함, 이슈, 불일치 사항 등) 사이의 추적성
2. 변경 영향을 받는 작업 산출물 간의 일관성, 완결성 및 영향분석 결과의 보장

여기서, 모든 요구사항이 1:1로 대응되지 않을 수 있으며, 필요한 경우 기능목록 수준에서 다른 설계 요구사항과 추적을 할 수가 있습니다.

또한, 만약 고객이 소프트웨어, 하드웨어 요구사항을 직접 제공하는 경우, 시스템 레벨에서 요구사항을 반드시 작성하여 추적성을 확보할 필요는 없습니다. 이러한 경우는 추적성에 대한 효율적인 전략을 수립해서 1) 고객 요구사항을 시스템을 거치지 않고, 직접 소프트웨어나 하드웨어 요구사항으로 가져오거나 2) 필요한 경우 시스템 요구사항이나 설계의 제약사항으로 구성하여 추적성을 확보할 수 있습니다.

고객이 제공하는 상세 소프트웨어 및 하드웨어 요구사항을 시스템 레벨에서 작성하게 되면, 그 요구사항을 소프트웨어나 하드웨어 레벨에서 거의 같은 수준(예, Copy & Paste)으로 작성되기 때문에, 의미 없는 중복작업을 수행해야만 합니다. 이러한 비 효율적인 방법은 좋은 접근법이 될 수 없습니다.

결론적으로 추적성은 고객이 요청한 모든 요구사항이 최종 실물 제품에 반영되어야 하는 것이 중요한 원칙이므로, 이러한 원칙을 달성하기 위한 전략은 조직이나 프로젝트에 따라 다르게 적용할 수 있습니다.

[일관성(Consistency)]

 엔지니어링 프로세스에서 Consistency는 두 가지 측면에서 이루어집니다.

1. V 모델의 왼쪽에 프로세스에서 영향을 받는 엔지니어링 작업 산출물의 개별(atomic) 요구사항 또는 구조화된(clustered) 기능 항목들이 서로 모순되지 않는 일관성 (예, 시스템 요구사항 – 시스템 설계 – 소프트웨어 요구사항 – 소프트웨어 아키텍처, – 소프트웨어 단위설계 – 코드)
2. V 모델의 왼쪽 프로세스의 요구 및 설계항목과 오른쪽에서 이에 대응되는 프로세스의 테스트 명세(테스트 케이스들)이 일치해야 하는 일관성 (예, 시스템 아키텍처-시스템통합 테스트 케이스 등)

단, V 모델의 오른쪽의 테스트 명세(테스트케이스들)와 테스트 결과 간의 일관성을 요구하지는 않습니다. 즉, 테스트 결과는 테스트 수행에 대한 기록(Record)이며, 이러한 결과는 형상에 영향을 주는 요소가 아닌 수행의 결과로, 관련 결과의 추적이 가능하면 된다는 의미입니다.

[중복성(Redundancy)]

 위 그림(Figure D.4)에서 볼 수 있는 Redundancy of Traceability and Consistency에 대해 기술하도록 하겠습니다.

1. 1 BP6, BP7 (System requirements – Software requirements)
2. 3 BP5, BP6 (Software requirements – Software detailed design and unit construction)

엔지니어링 프로세스 SWE.1과 SWE.3에는 추적성과 일관성 수립을 위한 또 다른 경로가 존재합니다.

• 시스템 요구사항 (SYS.2)으로부터 직접 소프트웨어 요구사항 (SWE.1)로 추적성과 일관성을 유지하는 경로입니다.
• 소프트웨어 요구사항 (SWE.1)으로부터 직접 소프트웨어 상세설계와 소프트웨어 단위(SWE.3)로 추적성과 일관성을 유지하는 경로입니다.

이러한 중복되는 부분은 일관성(consistency) 측면에서 즉 추적성(traceability)을 반영하더라도 일관성에 대한 품질(Quality) 이슈를 방지하기 위해 중복 경로를 사용하고 있습니다. 즉 추적성이 일관성을 담보하지 못하는 경우를 방지하기 하려는 의도입니다.

하지만, 굳이 특별한 이유로 예를 들면, 상이한 개발 조직의 협업 개발, 복수개의 마이크로 컨트롤러 등과 같이 Redundancy의 필요성이 없다면 굳이 추가적인 Traceability나 Consistency를 유지할 필요는 없습니다. 그래서 Automotive SPICE Guidelines에서는 “하나의 경로로 추적성을 설명할 수는 있으나, 이를 통해 중복 경로가 증명되지 않으면, 추적성 지표는 하향 평가되어야 한다.”라고 기술하고 있습니다. 즉 하나의 경로만 유지하더라도, SYS.2-SWE.1-SWE.3이 추적성과 일관성이 보장된다면 심사 시에 약점이 될 수 없다는 의미입니다.

추가로 Project Management 차원에서 Consistency는 위의 엔지니어링 프로세스와 더불어 고객 요구사항, 프로젝트 범위(Scope – work package), 일정(Time), 추산된 리소스(Estimated resource) 등이 프로젝트 계획 및 모니터링 결과 등과 일관성을 가져야 하며, 불일치 사항이 발생 시 조정되는 활동들이 수행이 되어야 한다.

Traceability와 Consistency의 몇 가지 적용 방안을 정리하면 다음과 같습니다.

• 제품 또는 프로젝트 상황에 따라 산출물의 모든 개별(atomic) 요구사항, 엘리먼트, 소프트웨어 단위 레벨만이 아닌 구조화된(clustered) 레벨에서도 추적이 고려될 수 있다.
• 고객이 제공하는 다른 상세요구사항(예, 소프트웨어, 하드웨어 및 설계 구성요 등)을 반드시 시스템 레벨에서 같은 수준의 요구사항으로 반복적으로 전개하지 않고, 시스템의 제약사항이나 또는 해당 소프트웨어와 하드웨어 요구사항으로 전개할 수 있다
• 테스트 결과(기록)에 대한 일관성 확보를 위한 리뷰 기록이나, 형상 항목으로의 식별이 꼭 필요한 것은 아니다.
• 상세화가 가장 낮은 단위의 요구사항 레벨로 추적성과 일관성의 확보가 필요하다.
• 프로젝트의 복잡도에 따라 수동 또는 자동화된 도구를 이용할 수 있으며, 자동화된 툴이 꼭 필수적인 것은 아니다. (하지만 복잡성이 높음에도 수작업으로 추적한다면 약점은 존재할 수 있다)
• 엔지니어링 프로세스에서 추적성의 이슈가 있으면 당연히 일관성에 대한 이슈가 발생할 수 있다.
• 일관성은 꼭 리뷰 기록(Review record)로만 설명하는 것이 아니라, 산출물에 대해 동료가 검토한 코멘트나 설명, 산출물의 변경 이력 및 서로 다른 엔지니어가 교차로 작성한 이력 등을 통해 일관성을 설명할 수 있다.