1. DO-178과 추적성 매트릭스(Traceability Matrix)

 

앞서 추적 데이터(Trace Data)에 대해서 DO-178 가이드라인에서는 어떻게 정의하고 있으며 실제요구사항 작성시에 어떻게 활용되는지를 직접 확인해 보았다. 어떻게 보면 추적 데이터 자체에 대한 것은 지금까지 설명된 내용만으로도 충분히 이해할 수 있을 만큼 그렇게 어려운 것이 아닐 지 모르겠다. 하지만 실제 DO-178 인증 현장에서 추적 데이터는 상상 이상으로 많은 곳에서 다양하게 활용되고 있다. 단순히 요구사항의 연결의 매개체로만 인식할 수 없는 중요한 부분인 것이다.

 

이 절에서는 그에 대한 부분을 실제 사용되는 사례를 중심으로 설명하게 된다. 참고로 DO-178 가이드라인에서는 추적 데이터(Trace Data)라는 용어로 설명하고 있지만 실제 현장에서는 그보다는 추적성 매트릭스(Traceability Matrix)라는 용어를 더 많이 사용하고 있다. 앞으로의 설명에서도 추적성 매트릭스로 통일해서 설명한다.

 

(1)   추적성 매트릭스 사용 예시

 

우선 실제로 현장에서 사용되고 있는 추적성 매트릭스의 예시를 보면서 이야기를 풀어보자. 일단 다양한 방법이 있다는 것을 보여주기 위해서 필자가 알고 있는 사례를 모두 정리했다.

 

①    reqTracer를 사용한 추적성 매트릭스 생성

 

아래 그림은 reqTracer라는 툴을 사용해서 실제로 추적성 매트릭스를 보여주는 장면이다. 사실 reqTracer는 하드웨어 개발에 사용되는 도구의 하나인데 필자가 현장에서 실제 사용해 보면서 소프트웨어의 추적성 매트릭스에도 충분히 활용할 수 있다는 것을 확인하면서 이렇게 소개하게 된 케이스이다. 개인적인 생각으로는 가장 직관적으로 추적성을 확인할 수 있고 툴에서 바로 해당 자료를 확인할 수도 있을 뿐만 아니라 원본을 실행(오픈)할 수도 있어서 비용만 커버가능하다면 가장 추천하는 방법이다. (구매 비용이 어머어마하다)

 

 

 

그림 4 추적성 매트릭스 예시 1 – reqTracer 사용

 

※ 출처) https://www.dataweek.co.za/news.aspx?pklnewsid=39316

 

②    traceGEAR를 사용한 추적성 매트릭스 생성

 

이것은 필자가 DO-178 인증을 처음 시작하면서 접한 방법이다. 처음에는 웹기반의 도구였는데 이후 지금과 같은 traceGEAR라는 도구로 형태가 변경되었다. 아래 그림은 traceGEAR에서 추적성 매트릭스 결과를 엑셀파일로 출력한 상태를 보여주고 있다. 처음 보았던 reqTracer 보다는 허접(?)해 보이기도 하고 기능도 많이 없는 게 사실이지만 필자가 DO-178 인증을 진행하는 과정에서는 전혀 문제없이 잘 활용했던 기억이 있다. 물론 traceGEAR가 당시 함께 했던 DER이 직접 개발한 도구여서 자연스럽게 사용된 부분도 있는 게 사실이다. 참고로 구매 비용이 reqTracer보다 저렴하긴 하지만 생각보다는 고가의 도구이다.

 

 

 

그림 5 추적성 매트릭스 예시 2 – traceGEAR 사용(엑셀 출력)

 

※ 출처) http://www.tracegear.net/ (동영상 캡처)

 

③    수작업으로 추적성 매트릭스 작성

 

앞서 요구사항에 대한 설명에서 보았던 추적성 매트릭스이다. 문서에 직접 표를 만들고 아이디를 찾아서 하나하나 기록하는 방식으로 모든 것이 수작업으로 작성되기 때문에 다른 케이스에 비해서 어렵고 시간이 많이 걸리는 방식이라고 할 수 있다. 수작업으로 진행되다 보니 결과에 오류가 포함될 확률이 높아서 DO-178 인증의 관점에서는 절대 추천하지 않는 방법이다. 사실 도구 구매 비용이 없어서 비용면에서 장점이 있는 것처럼 보이기는 하지만 그 대신 인력이 투입되어 많은 시간을 소요하게 되므로 실제 비용을 생각하면 필자의 개인적인 판단으로는 오히려 도구를 구매하는 것보다 더 많은 비용이 소요될 것이다.

 

 

 

그림 6 추적성 매트릭스 예시 3 – 수작업으로 작성(워드)

 

④    DOORS를 사용한 추적성 매트릭스 생성

 

우선 필자는 DOORS가 아주 유용하고 좋은 도구라고 생각하고 있다. 지금 이야기하고 있는 추적성 매트릭스를 위한 용도뿐만 아니라 요구사항 관리에서도 막강한 기능을 가지고 있다고 알고 있다. 하지만 개인적으로는 DO-178 인증을 위한 도구로는 그다지 추천하지 않는다. 특히 소규모 업체라면 엄청난 비용이 필요한 DOORS를 사용해서 진행하기는 애초에 불가능하다고 판단하고 있다. 아래는 DOORS를 사용해서 추적성 매트릭스를 확인하는 모습이다. 필자가 잘 몰라서 그런 것일 수도 있지만 지금까지 설명한 방법에 비해서 더 유용하다는 느낌은 들지 않는 것이 사실이다. 일단 이런 것도 있다고 소개하는 선에서 넘어간다.

 

 

 

그림 7 추적성 매트릭스 예시 4 – DOORS 사용

 

※ 출처) https://www.researchgate.net/figure/Traceability-matrix-between-UCM-components-and-external-requirements_fig3_262408353

 

⑤    ALM(Application Lifecycle Management)을 사용한 추적성 매트릭스 생성

 

이번 케이스는 브라우저를 통한 사용자 인터페이스를 갖춘 도구의 예이다. 주로 개발 과정 전체를 총괄하는 형태로 사용하는 경우가 많은데 일부 기능으로 포함되어 지원되는 경우가 많다. 필자는 아직 제대로 사용해 본 적이 없어서 정확한 장단점을 설명하기는 어렵고 이것 역시 소개하는 선에서 넘어간다.

 

 

 

그림 8 추적성 매트릭스 예시 5 – HP ALM(Application Lifecycle Management) 사용

 

※ 출처) http://qamindset.blogspot.com/2015/06/requirements-tracebality-matrix.html

 

지금까지 본 것처럼 추적성 매트릭스를 사용하는 방법은 여러가지이다. 아마 필자가 모르는 다른 방법들도 많이 있을 것이다. 중요한 점은 각자의 상황에 맞는 적절한 방법을 선택하는 것인데 사실 처음 접하는 분들에게는 이것이 결코 쉽지 않은 일이다.

 

이런 경우 필자가 추천하고 싶은 방법은 DER을 통해서 추천을 받는 방법이다. 반드시 그런 것은 아니겠지만 아무래도 인증을 진행할 DER이 잘 알고 있는 방법을 사용하게 되면 부가적인 장점이 있을 수 있다. 또한 함께 할 DER이라면 지원자의 현재 상태와 수준을 어느 정도 파악할 수 있으므로 지원자의 상황에 맞는 방법을 제안해 줄 수도 있을 것이다.

 

그리고 무엇보다도 DO-178 인증에 대한 검토 과정에서 추적성 도구의 구매에 대한 부분을 반드시 고려해야 한다는 점을 기억하자.

 

(2)   추적성 매트릭스의 구성

 

기본적으로 추적성 매트릭스는 요구사항의 추적성을 나타내는 것이라고 말한 바가 있다. 여기서 요구사항의 추적성이라는 것은 단순히 요구사항 자체만을 의미하는 것이 아니다. 다음 그림을 보자.

 

 

 

위의 그림은 예전에 필자가 포스팅한 내용 중에 사용된 그림이다. 요구사항의 구분이 표시되어 있고 각각의 요구사항에 연결된 시험이 보인다. 일단 당장 위의 그림만 보더라도 다음과 같은 추적성을 확인할 수 있다.

 

-       상위레벨 요구사항 <-> 하위레벨 요구사항

-       상위레벨 요구 사항 <-> 상위레벨 시험

-       하위레벨 요구사항 <-> 하위레벨 시험

 

만약 위의 그림에 ‘시스템 요구사항’, ‘소스 코드’가 연결되면 추적성은 그 만큼 더 늘어나게 된다. 게다가 시험에 대해서도 ‘시험 케이스’와 ‘시험 절차’로 구분하게 되면 추적성은 또 늘어나게 된다. 결과적으로 DO-178 인증에서는 지금까지 이야기한 추적성이 모두 확인되어야 한다. 따라서 최종적으로는 아래와 같은 연결성을 예상할 수 있다.

 

 

 

그림 9 DO-178 인증을 위한 추적성 연결도((c) Steven H. VanderLeest, CC-BY-SA 3.0)

 

※ 출처) http://www.wikiwand.com/en/DO-178C

 

위의 그림은 구글링을 통해서 찾은 DO-178 인증에서의 추적성에 대한 전체적인 그림이다. 필자가 앞에서 설명한 내용을 포함해서 DO-178 관점에서 확인해야 할 추적성이 모두 표시되어 있다. (심지어 소스 코드와 실행파일과의 추적성도 포함되어 있다) 거기에 소프트웨어 레벨에 따른 구분과 함께 관련된 Objective와의 연결까지 포함되어 있어서 필자가 이야기하고 싶은 부분 이상으로 훨씬 많은 내용을 담고 있는 그림이라고 할 수 있다. 처음 보시는 분들이라면 너무 복잡하게 보일 수도 있을 것 같은데 그런 분들은 화살표 중간에 표기된 부분은 무시하고 박스간의 연결만 보시기 바란다.

 

(3)   추적성 매트릭스의 활용 방법

 

수작업이든 도구를 사용하든 추적성 매트릭스를 만들게 되면 이제 이것을 DO-178 인증에서 활용해야 한다. 물론 그 자체로 산출물이자 증빙으로써 충분한 가치를 가지지만 실제 현장에서는 DO-178 인증에 관련된 모든 당사자들이 추적성 매트릭스를 활용하게 된다.

 

사실 다음에 설명되는 활용 방법들은 일반화해서 이야기할 수 없는 것일지도 모르겠다. 사람들마다, 그리고 상황에 따라서 활용 방법이 달라질 수 있기 때문이다. 사실 이는 DO-178의 특징이기도 하다. 하지만 이런 내용을 이해함으로써 비록 그대로 진행하지는 않더라도 나름대로의 ‘응용’이 가능해진다. 그리고 현장에서 발생하는 유동적인 부분을 적절하게 대응할 수 있게 된다. 그런 배경으로 다음의 내용들을 이해하도록 하자.

 

①    지원자(Applicant) 관점에서의 활용 방법

 

여기서 ‘지원자’라는 것은 DO-178 인증을 신청한 사람을 말한다. 지원자는 DO-178 인증 과정에서 추적성 매트릭스를 만들어야 하며 DER이 보고자 하는 경우 언제든 결과물을 보여주어야 한다. 참고로 원칙적으로는 인증을 위한 최종 자료로 추적성 매트릭스를 제출하는 것은 아니지만 인증 과정에서 제출되는 자료에는 대부분 포함되어야 하므로 제출 시점에서의 정확한 추적성이 연결되어 있어야 한다.

 

결과적으로 지원자 관점에서의 활용 방법은 인증을 위한 산출물 및 증빙으로써의 제출이라고 할 수 있다.

 

②    개발자(Developer) 관점에서의 활용 방법

 

앞에서 지원자가 추적성 매트릭스를 만들어야 한다고 했지만 사실 현실적으로는 그 역할을 개발자가 하는 경우가 많다. 그런 경우 개발자는 추적성 매트릭스를 만드는 사람이자 활용하는 사람이라고 할 수 있다. 이는 중간 과정에서의 업데이트도 포함된다.

 

기본적으로 개발자에게 추적성 매트릭스는 연결된 항목들을 직관적으로 확인할 수 있는 편리한 도구가 된다. 상위레벨 요구사항 하나에 대해서 그 상위 요구사항인 시스템 요구사항이 무엇인지를 찾아갈 수 있고, 연결된 하위레벨 요구사항을 거쳐서 하위레벨 요구사항을 구현한 소스 코드가 무엇인지에 대해서도 바로 확인할 수 있다. 또한 요구사항에 대한 시험 케이스가 무엇인지, 시험 절차가 어떻게 되는지도 바로 찾아볼 수 있다. 이는 개발과정에서 발생할 수 있는 혼선을 상당부분 줄여줄 수 있는 부분이다.

 

하지만 개발자에게 추적성 매트릭스의 가장 큰 장점은 바로 수정사항이 발행했을 때 연결된 부분을 확인할 수 있다는 점이다. DO-178 가이드라인에는 다음과 같은 설명이 나온다.

 

 

 

해석을 보자.

 

b. 만들어져야 할 변경과 수행되어야 할 행동을 구분하는 소프트웨어 라이프 사이클상의 문제점 혹은 제안된 변경의 영향에 대한 평가

 

설명이 좀 복잡한데 핵심은 바로 ‘문제점 혹은 제안된 변경의 영향에 대한 평가’라는 부분이다. 즉 수정사항이 발생하는 경우 그 수정사항으로 인해서 발생할 수 있는 영향이 무엇이 있는지를 평가해야 한다는 의미이다. 바로 이때 추적성 매트릭스를 이용해서 연결된 항목을 찾고 그 중에 영향을 받는 부분이 없는지를 체크하게 된다. 이는 DO-178 인증을 위한 중요한 활동으로 추적성 매트릭스를 활용함으로써 그러한 평가 과정이 제대로 수행되고 있다는 것을 보여주는 중요한 근거 자료가 될 수 있다.

 

③    QA(Quality Assurance) 관점에서의 활용 방법

 

DO-178 인증을 받기 위해서는 개발자와 함께 QA의 역할도 상당히 중요하다. 자칫 개발에만 집중해서 QA 활동에 대해서는 신경을 쓰지 않는 경우가 많은데 그렇게 해서는 절대로 DO-178 인증을 받을 수 없다.

 

QA가 추적성 매트릭스를 활용하는 것은 결국 내부 감사(Audit)를 진행할 때이다. 여기서 내부 감사는 쉽게 말해서 소프트웨어 개발 과정이 계획대로 진행되고 있는지를 확인하는 것이다. 이 과정에서 문제점에 대한 수정을 확인하는 경우가 있을 수 있는데 바로 이 때 추적성 매트릭스를 이용해서 개발자가 활용한 방식으로 연결된 부분을 찾고 수정에 따른 영향이 고려되었는지를 확인하게 된다.

 

 

④    DER 관점에서의 활용 방법

 

DER이 추적성 매트릭스를 활용하는 것은 어떻게 보면 QA가 활용하는 방법과 유사하다고 할 수 있다. QA가 내부적인 감사라면 DER의 감사는 외부적인, 공식적인 감사라는 차이가 있을 뿐이고 실질적으로 수행되는 활동에는 유사한 부분이 많다.

 

QA와 같은 방식으로 감사 수행과정에서 문제점에 대한 수정을 확인하면서 추적성 매트릭스를 활용하는 것 이외에 DER은 SOI#1 ~ SOI#4의 감사를 진행하는 동안에 추적성 매트릭스를 활용해서 샘플링된 자료의 연결고리와 결과물을 확인하게 된다. 따라서 만약 감사 시점에 추적성 매트릭스가 잘못 작성되어 있는 경우, 그리고 그것이 DER에게 확인되는 경우에는 소프트웨어 전체에 대한 신뢰도가 그만큼 떨어지는 결과를 가져올 수 있다. 쉽게 말해서 DER이 현재 상태를 ‘제대로 준비하지 못한 상태, 문제가 많은 상태’로 볼 여지를 주는 것이다. 우리가 일상 생활에서 첫인상이 중요하다는 말을 하곤 하는데 DO-178 인증에서 보자면 DER과의 첫인상은 추적성 매트릭스가 좌우할 수도 있다.

 

이상이 필자가 판단하는 추적성 매트릭스의 활용방법이다. 사실 이 부분은 DO-178 가이드라인에서 구체적으로 설명하는 내용이 아니기 때문에 필자의 주관적인 판단이 많이 포함되어 있다. 하지만 현장에서의 경험을 바탕으로 한 것이고 핵심적인 내용만 정리했으므로 실전에서 참고하더라도 큰 무리가 없을 것이다.