12. DO-178과 소프트웨어 검증 프로세스 (Section 6.0)

필자는 소프트웨어 검증 프로세스(Software Verification Process)라고 하면 매번 ‘시험(Test)’을 가장 먼저 떠올리게 된다. 물론 시험(Test)이 DO-178의 소프트웨어 검증 프로세스의 핵심적인 부분이긴 하지만 DO-178 관점에서는 그 외에도 검증 프로세스로서 이해해야 할 부분이 상당히 많다. 본 절을 통해서 그런 부분들을 살펴보게 될 것이다.

 

여기서 한 가지 자칫 별 생각없이 쉽게 놓쳐버릴 수 있는 부분이 있는데 소프트웨어 검증 프로세스에 대한 계획은 앞서 우리가 보았던 소프트웨어 계획 프로세스(Software Planning Process)를 통해서 소프트웨어 검증 계획(Software Verification Plan) 문서로 작성된다는 점이다. 그렇게 작성된 계획대로 진행되어야 하는 것은 물론이다.

 

먼저 DO-178 가이드라인에서는 ‘검증(Verification)’을 아래와 같이 정리하고 있다.

 

 

해석을 보자.

 

검증은 소프트웨어 계획 프로세스, 소프트웨어 개발 프로세스 그리고 소프트웨어 검증 프로세스의 출력에 대한 기술적인 평가이다.

 

그리고 가이드라인에서는 다음과 같은 추가 설명이 이어진다.

 

 

해석을 보자.

 

검증은 단순히 시험이 아니다. 시험은 일반적으로 에러의 부재를 보여줄 수 없다. 결과적으로 다음 섹션들은 소프트웨어 검증 프로세스 활동을 논의하기 위해 “test” 대신 “verify”라는 용어를 사용하며 그것은 일반적으로 리뷰, 분석, 그리고 시험의 조합이다.

 

DO-178에서 ‘검증’은 단순히 소프트웨어를 시험하는 것 만을 의미하지 않는다. 심지어 소프트웨어 검증 프로세스 자체를 포함해서 개발 과정 전체에서 만들어지는 결과물, 진행되는 과정 하나하나를 ‘리뷰’하고 ‘분석’하고 ‘시험’하게 되는데 그런 모든 것들을 ‘검증’이라고 칭하고 있는 것이다. DO-178 가이드라인 전반에 걸쳐서 사용되는 ‘Verification’의 의미를 위의 설명을 기준으로 이해할 필요가 있다.

 

소프트웨어 검증 프로세스는 목표(Objective)/활동(Activity)/출력(Output)에 대한 내용이 아래와 같이 부속물(Annex) A의 Table A-3에서부터 Table A-7에 걸쳐서 나뉘어져 있다. 테이블 제목을 보면 프로세스별 검증으로 구분된 것을 알 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

다른 프로세스와 달리 5가지의 테이블로 구분될 만큼 소프트웨어 검증 프로세스에서 다루는 부분이 상당히 광범위하다는 것을 알 수 있다. 다른 것과 마찬가지로 여기에서도 DO-178 가이드라인에서 가이드하는 내용을 제대로 이해하는 것이 중요한데 이를 위해서 세부 내용으로 들어가기 전에 우선 목차를 통해서 무엇을 이야기하는지를 전체적인 관점으로 파악해 보자.

 

 

다소 복잡하게 보이겠지만 위의 목차에서 주목할 부분은 점선으로 표시된 ‘Review’, ‘Analysis’ 그리고 ‘Test’이다. 앞서 DO-178 가이드라인에서 사용하는 ‘Verify’가 단순한 ‘Test’를 말하는 것이 아니라는 점을 이야기한 바가 있다. 그러한 구분에 따라서 소프트웨어 검증에 포함되는 ‘Review’, ‘Analysis’, ‘Test’를 구분해서 설명하고 있는데 특히 소스 코드 리뷰를 제외하면 소스 이외에 주로 문서와 같은 데이터에 대해서는 리뷰와 분석이 수행되고 그 외의 대부분의 경우에는 시험이 수행되는 것을 확인할 수 있다. 쉽게 보자면 소프트웨어 검증 프로세스에서는 문서는 리뷰나 분석을, 나머지는 시험을 주로 수행한다고 생각하면 크게 틀리지 않다.

 

참고로 모든 소프트웨어에 대해서 이러한 소프트웨어 검증 활동이 이루어 지지만 소프트웨어 레벨에 따라서 그 범위나 수준은 달라진다. 앞으로 나오는 설명에는 이러한 차이점이 포함되어 설명될 것이다.

 

(1)    소프트웨어 검증의 목적 (Section 6.1)

 

흔히 우리가 소프트웨어에 대한 시험을 한다고 하는 것은 결국 소프트웨어 내부에 잠재되어 있는 버그를 찾아서 수정하기 위한 것이다. DO-178 가이드라인에서 말하는 ‘검증’ 역시 크게 다르지 않다. DO-178 가이드라인에서 설명하고 있는 다음 글을 보자.

 

 

해석을 보자.

 

소프트웨어 검증 프로세스의 목적은 소프트웨어 개발 프로세스 동안에 주입될 수 있는 에러를 탐지하고 레포트하는 것이다. 에러의 제거는 소프트웨어 개발 프로세스의 하나의 활동이다.

 

위의 설명을 자세히 살펴보면 소프트웨어 검증 프로세스가 에러를 탐지하고 레포트하는 것이라고 언급하고 있고 아울러 그에 대한 ‘제거(Remove)’는 검증의 영역이 아니라 개발의 영역으로 구분 짓는 다는 점이다. 어찌 보면 당연한 말이지만 DO-178 인증을 제대로 받기 위해서는 이런 정도의 프로세스 구분까지도 이해하고 있어야 한다.

 

소프트웨어 검증과 관련해서 우리가 DO-178 가이드라인을 통해서 명확하게 이해해야 할 부분은 DO-178에서는 검증을 어떤 기준으로 나누어서 수행하느냐이다. 어찌 보면 소프트웨어에 대해서 어떤 식으로든 시험을 진행해서 문제가 없다는 결과만 제대로 보여줄 수 있으면 되지 않느냐고 생각할 수도 있지만 DO-178에서는 결과 못지 않게 과정도 매우 중요하게 받아들인다. 따라서 완벽한 결과가 있다고 하더라도 그 과정을 제대로 확인할 수 없다면 그 결과는 의미가 없어진다. 이런 배경에서 DO-178 가이드라인에서는 아래와 같은 기준을 바탕으로 검증을 진행하도록 가이드하고 있다.

 

a.     시스템 요구사항을 만족하는 상위레벨 요구사항이 개발되었는가?

b.     상위레벨 요구사항을 만족하는 소프트웨어 아키텍처와 하위레벨 요구사항이 개발되었는가?

c.     소프트웨어 아키텍처와 하위레벨 요구사항을 만족하는 소스 코드가 개발되었는가?

d.     실행가능 오브젝트 코드가 소프트웨어 요구사항을 만족하는가? 그리고 의도되지 않은 기능이 존재하지 않는가?

e.     실행가능 오브젝트 코드가 비정상적인 입력과 조건에도 올바로 응답할 수 있는가?

f.      이러한 검증에 사용되는 방법들이 소프트웨어 레벨에 따라서 기술적으로 올바르고 완전한가?

 

위의 내용이 일반적인 설명이라고만 볼 수도 있지만 DO-178에서는 위의 항목 하나하나를 구분해서 검증해야 한다. 그리고 각각에 해당하는 정확한 증빙이 나와야 한다. 이는 결코 쉬운 것이 아니다. 그저 마지막에 최종 시험 한 번으로 위에서 이야기한 대부분의 내용이 한 번에 모두 해결되는 그런 것이 아니라는 말이다. 예를 들면 e의 경우는 예외적인 부분에 대한 처리를 언급하는 것이어서 설명 자체는 한 줄이지만 그 한 줄을 만족하기 위해서는 엄청나게 복잡하고 많은 활동이 수행되어야 한다. 자세한 내용은 별도의 절에서 추가 설명될 것이다.

 

이 단락을 정리하기 전에 여기에 나오는 설명 중 DO-178 관점에서 바라보는 특이점 하나를 살펴볼 필요가 있다. 다음 문장을 보자.

 

 

해석을 보면

 

만약 상위레벨 요구사항과 하위레벨 요구사항 사이에 하나 혹은 그 이상 레벨의 소프트웨어 요구사항이 개발된다면 요구사항의 이어지는 레벨들은 각각의 연속된 하위레벨이 바로 상위 레벨 요구사항을 만족하도록 개발된다. 만약 코드가 상위레벨 요구사항으로부터 직접 생성되면 이것은 적용되지 않는다.

 

설명이 좀 복잡하게 느껴질 텐데 쉽게 말하자면 지금까지 우리가 이야기한 상위레벨 요구사항과 하위레벨 요구사항 사이에 또 다른 레벨의 요구사항이 정의될 수 있다는 의미이다. 이는 요구사항을 상위/하위 2단계로만 구분하기에는 너무 복잡하다거나 그렇게 구분하기 어려운 경우에 나타날 수 있는 상황이다. 만약 이렇게 중간 단계가 추가로 만들어지는 경우에는 그 중간 단계가 자신을 기준으로 상위와 하위로의 추적성을 가져야 한다. 아무렇게나 중간에 추가한다고 끝이 아니라는 말이다.

 

그리고 반대로 상위/하위 2단계도 필요 없이 상위레벨 요구사항에서 바로 소스 코드가 만들어 질 수도 있다. 정말 간단한 요구사항의 경우에는 그럴 수도 있을 것이다. DO-178에서는 이런 경우도 정상적인 케이스로 받아들인다. 무조건 상위/하위레벨 요구사항을 정의해야 하는 것은 아니다.

 

(2)    소프트웨어 검증 프로세스 활동의 개요 (Section 6.2)

 

DO-178 가이드라인에서 제시하는 검증 방법은 크게 리뷰(Reviews), 분석(Analyses) 그리고 시험(Tests)으로 구분할 수 있다고 했다. 이 중 리뷰와 분석은 소프트웨어 요구사항, 아키텍처 그리고 소스 코드 모두에 해당하는 검증 방법이며 시험은 실제로 그 절차를 진행함으로써 요구사항을 만족하는 지를 직접적으로 확인할 수 있게 해 준다.

 

DO-178 가이드라인에서는 이러한 소프트웨어 검증 프로세스의 입력(Inputs)으로 다음과 같은 것들을 제시하고 있다.

 

-       시스템 요구사항

-       소프트웨어 요구사항

-       소프트웨어 아키텍처

-       추적 데이터

-       소스 코드

-       실행가능 오브젝트 코드

-       소프트웨어 검증 계획

 

위의 입력을 바탕으로 소프트웨어 검증 프로세스가 수행되면 아래와 같은 출력(Outputs)이 나오게 된다.

 

-       소프트웨어 검증 케이스 및 절차(Software Verification Cases and Procedures)

-       소프트웨어 검증 결과(Software Verification Results)

-       관련된 추적 데이터

 

위의 항목 중 소프트웨어 검증 케이스 및 절차는 DO-178에서 필수로 작성해야 할 시험관련 문서인데 추후 관련 절에서 추가 설명이 있을 예정이다.

 

소프트웨어 검증 프로세스를 진행하다 보면 여러가지 고려해야 할 부분이 생기게 된다. DO-178 가이드라인에서는 그러한 고려사항들이 어떤 것들이 있고 각각을 어떻게 다루어야 하는지 다음과 같이 설명하고 있다.

 

a.     시험되는 코드가 항공기에 탑재되는 소프트웨어와 동일하지 않다면 그 차이점이 구체적으로 제시되고 정당화되어야 함

b.     특정 소프트웨어 요구사항이 현실적인 시험 환경에서 소프트웨어를 실행해서 검증할 수 없다면 다른 방법이 제시되고 그 방법에 대한 정당성이 정의되어야 함

c.     소프트웨어 검증 프로세스에서 발견되는 결점과 에러는 다른 소프트웨어 라이프 사이클 프로세스에 리포트되어야 함

d.     수정이나 변경에 대한 재검증(Reverification)이 이루어져야 하며 그러한 수정이 올바르다는 것을 보장해야 함

e.     툴 사용을 포함해서 검증에 대한 독립성이 확보되어야 함. 이를 위해서는 소스 코드를 구현한 사람과 시험케이스를 작성하는 사람이 동일해서는 안됨

 

DO-178 인증에서 어려운 점은 바로 이러한 고려사항들을 개념적으로 이해하는 것만이 아니라 각각을 실제로 어떻게 고려해서 처리했는지를 그 과정을 포함해서 결과에 이르기까지 하나하나 정확하게 정리하고 증빙으로 남겨야 한다는 점이다. 일반적인 개발활동에서 시험을 수행하는 자체만으로도 많은 어려움이 있다는 점을 생각해 본다면 이는 결코 쉽지 않은 일이다.

 

(3)    소프트웨어 리뷰 및 분석 (Section 6.3)

 

이제 소프트웨어 검증 프로세스에서 리뷰와 분석에 대한 구체적인 DO-178 가이드라인을 확인해 보자. 앞서 언급된 것처럼 리뷰와 분석은 소프트웨어 요구사항, 아키텍처 그리고 소스 코드 모두에 해당하는 검증 방법으로써 각각에 대한 목표(Objective)가 제시되고 있다. 전체적으로 비슷한 부분이 많지만 각각의 특성에 따른 차이점이 있기 때문에 그에 대한 구분도 할 수 있어야 한다.

 

①     상위레벨 요구사항의 리뷰 및 분석

 

요구사항에 대한 절에서 다시 설명이 되겠지만 DO-178에서는 요구사항을 제대로 작성해야 한다. 여기서 ‘제대로’라는 의미는 DO-178 가이드라인이 제시하는 기준과 일치한다는 의미이다. 소프트웨어 검증 프로세스에서 상위레벨 요구사항의 리뷰와 분석을 하는 것은 결국 ‘제대로’ 작성되었는지를 확인하는 작업이라고 할 수 있다. DO-178 가이드라인에서는 상위레벨 요구사항이 다음의 목표를 만족할 수 있는지를 확인하도록 가이드하고 있다.

 

a.     시스템 요구사항에 대한 준수: 상위레벨 요구사항이 시스템 요구사항을 보장해야 하며, 파생요구사항은 존재 이유가 정의되어야 함

b.     정확성과 일관성: 상위레벨 요구사항이 모호하지 않고 명확하며 상호간에 충돌이 없어야 함

c.     타겟 컴퓨터와의 호환성: 상위레벨 요구사항과 하드웨어/소프트웨어 특성과의 충돌이 없어야 함. 특히 시스템 응답 시간과 입/출력 하드웨어

d.     검증가능성: 상위레벨 요구사항이 검증가능해야 함

e.     표준을 준수: 앞서 언급된 소프트웨어 요구사항 표준(Software Requirements Standards)을 따라야 함

f.      추적가능성: 상위레벨 요구사항과 시스템 요구사항 간의 추적성이 존재해야 함. 이는 결국 시스템 요구사항이 소프트웨어로 할당되어 상위레벨 요구사항으로 개발되었다는 것을 의미함

g.     알고리즘 특성: 사용되는 알고리즘의 정확도와 제대로 된 동작을 보장해야 한다는 것으로 특히 불연속(Discontinuities)의 영역에서는 더 유의해야 함. (참고로 필자는 이 항목에 대해서는 아직도 명확하게 와닿지 않는 것이 사실인데 추후 적절한 예시로 추가 설명을 하도록 하겠다)

 

상위레벨 요구사항에 대한 리뷰와 분석에서 특히 주목할 부분은 바로 시스템 요구사항과의 연계성이다. 상위레벨 요구사항이 시스템 요구사항으로부터 만들어지는 만큼 다른 어떤 것 보다도 그 부분이 명확하고 정확해야 한다.

 

②     하위레벨 요구사항의 리뷰 및 분석

 

아래 정리된 내용을 보면 알겠지만 상위레벨 요구사항의 리뷰 및 분석과 크게 다르지 않다. 다만 하위레벨 요구사항은 상위레벨 요구사항으로부터 만들어지는 만큼 그 연계성에 유의해야 한다.

 

a.     상위레벨 요구사항에 대한 준수: 하위레벨 요구사항이 상위레벨 요구사항을 보장해야 하며, 파생요구사항은 존재 이유가 정의되어야 함

b.     정확성과 일관성: 하위레벨 요구사항이 모호하지 않고 명확하며 상호간에 충돌이 없어야 함

c.     타겟 컴퓨터와의 호환성: 하위레벨 요구사항과 하드웨어/소프트웨어 특성과의 충돌이 없어야 함. 특히 버스 로딩, 시스템 응답시간 그리고 입/출력 하드웨어

d.     검증가능성: 하위레벨 요구사항이 검증가능해야 함

e.     표준을 준수: 앞서 언급된 소프트웨어 설계 표준(Software Design Standards)을 따라야 함

f.      추적가능성: 상위레벨 요구사항과 파생요구사항이 하위레벨 요구사항으로 개발되어야 함

g.     알고리즘 특성: 사용되는 알고리즘의 정확도와 제대로 된 동작을 보장해야 한다는 것으로 특히 불연속(Discontinuities)의 영역에서는 더 유의해야 함.

 

③     소프트웨어 아키텍처의 리뷰 및 분석

 

DO-178 가이드라인에서는 소프트웨어 아키텍처가 다음의 목표를 만족할 수 있는지를 확인하도록 가이드하고 있다.

 

a.     상위레벨 요구사항과의 호환성: 상위레벨 요구사항이 소프트웨어 아키텍처와 충돌이 없어야 함. 예를 들면 파티션 구조

b.     일관성: 설계 관점에서 아키텍처는 주로 컴포넌트의 조합으로 표현되는데 이때 컴포넌트간의 관계에서 충돌이 없고 연관성이 명확해야 한다는 것을 의미함. 참고로 이를 확인하기 위해서 데이터 플로우(Data Flow)와 컨트롤 플로우(Control Flow)가 활용됨

c.     타겟 컴퓨터와의 호환성: 특히 소프트웨어 아키텍처와 타겟 컴퓨터의 하드웨어/소프트웨어 특성 간의 초기화(Initialization), 비동기적인 동작(Asynchronous Operation), 동기화(Synchronization), 인터럽트(Interrupts)에서의 충돌이 없어야 함

d.     검증가능성: 소프트웨어 아키텍처가 검증가능해야 함. 예를 들면 끝없이 반복되는 재귀 알고리즘과 같은 문제가 없어야 함

e.     표준을 준수: 앞서 언급된 소프트웨어 설계 표준(Software Design Standards)을 따라야 함

f.      파티션 무결성: 파티션 위반이 보호되어야 함

 

앞서 보았던 상위레벨 요구사항과 하위레벨 요구사항에 대한 리뷰 및 분석과 비슷한 듯 하면서도 다른 부분이 많다. 무엇보다도 많은 수의 컴포넌트와 그 컴포넌트간의 관계로 이루어 지는 아키텍처를 중심으로 검증하는 부분은 검증 범위와 검증 결과에 있어서 상위레벨 요구사항에 대한 검증과는 비교할 수 없을 정도로 그 범위와 대상이 방대하다고 할 수 있다.

 

④     소스 코드의 리뷰 및 분석

 

과거 필자가 개발자로 한창 일하던 시기에는 소스 코드의 리뷰라고 하면 회사 동료들끼리 진행하는 코드 리뷰 정도가 전부였다. 그나마도 안 하는 경우가 더 많았던 게 사실이다. 개발자를 믿고(?) 그냥 넘어가는 것이다. 하지만 DO-178에서는 소스 코드에 대한 리뷰 및 분석을 상당히 엄격하게 제시하고 있다. 즉, 소스 코드는 소프트웨어 요구사항(특히 하위레벨 요구사항), 소프트웨어 아키텍처 그리고 소프트웨어 코드 표준(Software Code Standards)과 일치해야 하는 것이다. 이런 점들이 기존의 개발 과정과 별다를 게 없을 것 같지만 DO-178에서는 그 기준에 맞는 증빙이 정확하게 제시되어야 한다는 점에서 실제 진행하기에 상당히 어려운 부분이기도 하다. 아래에 제시된 목표들에서도 그런 면을 확인할 수 있다.

 

a.     하위레벨 요구사항에 대한 준수: 소스 코드는 하위레벨 요구사항과 일치해야 함. 반대로 하위레벨 요구사항에 없는 코드는 있어서는 안됨

b.     소프트웨어 아키텍처에 대한 준수: 소스 코드가 소프트웨어 아키텍처에 정의된 데이터 플로우(Data Flow)및 컨트롤 플로우(Control Flow)와 일치해야 함

c.     검증가능성: 검증되지 않는 소스 코드가 존재하면 안됨. 시험을 위해서 임의로 수정하면 안됨

d.     표준을 준수: 앞서 언급된 바가 있는 소프트웨어 코드 표준(Software Code Standards)을 따라야 함

e.     추적가능성: 하위레벨 요구사항이 모두 소스 코드로 구현되어야 함

f.      정확성과 일관성: 요구사항에 대한 정확성과 일관성과는 달리 소스 코드 관점에서의 기준으로 다음과 같은 예들이 제시되고 있음

l  스택 사용(Stack usage)

l  메모리 사용(Memory usage)

l  고정소숫점연산 오버플로우와 정밀도(Fixed point arithmetic overflow and resolution)

l  부동소숫점 연산(Floating-point arithmetic)

l  리소스 경쟁 및 제약(Resource contention and limitations)

l  Worst-case 실행 타이밍(Worst-case execution timing)

l  캐시 관리(Cache management)

l  사용되지 않는 변수(Unused variables)

l  태스크 혹은 인터럽트 충돌로 인한 데이터 손상(Data corruption)

 

특히 f의 경우 컴파일러나 링커와 같은 소프트웨어 개발 도구에서의 옵션의 차이, 혹은 하드웨어 특성에 따라서 Worst-case 실행 타이밍과 같은 부분에 영향을 줄 수 있기 때문에 그런 부분에 대해서도 정확한 검증을 요구하고 있다.

 

⑤     통합 프로세스의 출력에 대한 리뷰 및 분석

 

DO-178에서는 앞서 언급된 상위레벨과 하위레벨 요구사항, 아키텍처 그리고 소스 코드에 대한 리뷰와 분석 이외에 통합 프로세스에서 나오는 출력(Outputs)에 대해서도 리뷰와 분석을 수행하도록 가이드하고 있다. 이는 통합 프로세스가 제대로 수행되었는지를 출력을 통해서 확인하는 것이다. 구체적으로는 컴파일, 링크 그리고 로드 데이터와 메모리맵에 대한 조사가 있으며 이를 통해서 아래와 같은 에러들이 검출될 수 있다.

 

-       컴파일러 경고(Warning)

-       잘못된 하드웨어 주소

-       메모리 중복

-       소프트웨어 컴포넌트 누락

 

(4)    소프트웨어 시험 (Section 6.4)

 

소프트웨어 요구사항을 만족하는지를 알아보기 위해서는 리뷰나 분석이외에도 시험을 수행해야 한다. 소프트웨어 시험을 통해서 에러가 발생하지 않는다는 것을 확인할 수 있다. DO-178 가이드라인에서 제시하는 소프트웨어 시험의 목표(Objectives)는 아래와 같다.

 

a.     실행가능 오브젝트 코드가 상위레벨 요구사항을 충족함

b.     실행가능 오브젝트 코드가 상위레벨 요구사항에 대해서 강건성(Robust)을 가짐

c.     실행가능 오브젝트 코드가 하위레벨 요구사항을 충족함

d.     실행가능 오브젝트 코드가 하위레벨 요구사항에 대해서 강건성(Robust)을 가짐

e.     실행가능 오브젝트 코드가 타겟 컴퓨터와 호환됨

 

사실 DO-178 관점에서의 소프트웨어 시험은 단순히 시험 그 자체만을 이야기하는 것이 아니다. 보다 포괄적이고 광범위한 활동을 담고있는 개념이라고 할 수 있다. 이를 잘 보여주는 것이 바로 아래와 같은 그림이다.

 

 

 

그림의 제목을 보면 소프트웨어 시험 활동들이라고 되어 있는데 우리가 일반적으로 시험에 대해서 생각하는 활동에 비해서 상당히 복잡하고 많은 활동들이 있다는 것을 알 수 있다. 실제로 DO-178 인증을 받기 위해서는 위에서 나오는 모든 것들을 수행하고 그 결과를 제시해야 한다.

 

소프트웨어 시험에 대한 DO-178 가이드라인을 이해하기 위해서는 위의 그림에 나오는 용어들을 이해하고 상호간의 연결과 흐름을 해석할 수 있어야 한다. 기본적으로 각각의 항목에 대해서는 관련된 가이드라인이 표시되어 있다. 즉, 세부 내용은 해당 절을 통해서 파악하게 된다. 이제부터 위의 그림을 제대로 이해해 보자.

 

①     구조적 커버리지를 중심으로 한 시험 활동 전반에 대한 이해

 

시험에 대한 위의 그림을 이해하기 위해서 우선 ‘구조적 커버리지’가 무엇인지를 이해하는 것이 중요하다. 아마도 ‘구조적 커버리지(Structural Coverage)’에 대해서는 주로 ‘statement coverage’, ‘MCDC coverage’라는 용어로 접하는 경우가 많았을 것 같은데 DO-178에서 ‘구조적 커버리지’는 가장 중요한 요소이다. 왜냐하면 소프트웨어에 대한 구조적 커버리지의 결과를 제출함으로써 DO-178 검증 프로세스의 시험 단계가 종료될 수 있기 때문이다.

 

우선 DO-178 가이드라인의 부속물(Annex) A에 있는 아래의 테이블을 한 번 보자.

 

 

 

 

표의 제목을 보면 위의 표는 검증 프로세스 결과에 대한 검증으로써 목표(Objective), 활동(Activity), 출력(Output)등을 나타내고 있다. 위의 목표를 보면 구조적 커버리지와 관련해서 다음과 같은 4가지 목표가 제시되어 있다.

 

-       Modified condition/decision coverage

-       Decision coverage

-       Statement coverage

-       Data coupling 및 Control coupling

 

여기서 각각의 항목을 자세히 설명하기에는 너무 내용이 방대해 지므로 별도의 절에서 설명하기로 하고 일단 DO-178에서는 위와 같은 구조적 커버리지에 대한 요구사항(목표)이 있다는 것을 이해하고 가자. 앞서 본 시험 활동에 대한 복잡한 그림은 결과적으로 위의 4가지 목표를 달성하는 과정을 나타낸 것으로 보아도 무방하다. 실제로 위의 그림에서 일부를 잘라낸 아래 그림을 보면 구조적 커버리지 분석이 완료되면 시험이 종료되는 것을 확인할 수 있다.

 

 

그림 21 구조적 커버리지 분석과 시험 종료

 

이렇게 보면 구조적 커버리지 분석의 이전 단계로 나오는 것들은 결국 구조적 커버리지 분석을 위한 사전 활동이라고 할 수 있다. DO-178 가이드라인에서는 그러한 활동들을 크게 다음과 같이 나누고 있다.

 

-       소프트웨어 요구사항기반 시험 생성

-       하드웨어/소프트웨어 통합 시험

-       소프트웨어 통합 시험

-       하위레벨 시험

-       추가적인 검증 고려사항

 

바로 아래 그림의 부분이다.

 

 

 

그림 22 소프트웨어 시험 활동들

 

DO-178 가이드라인에서는 특히 아래와 같은 세가지 시험에 초점을 맞추고 있다.

 

 

해석을 보자.

 

l  하드웨어/소프트웨어 통합 시험: 타겟 컴퓨터 환경에서 소프트웨어의 올바른 동작을 검증하기 위함 l  소프트웨어 통합 시험: 소프트웨어 요구사항과 컴포넌트간의 상관관계를 검증하고 소프트웨어 아키텍처 안에서 소프트웨어 요구사항과 소프트웨어 컴포넌트의 구현을 검증하기 위함 l  하위레벨 시험: 하위레벨 요구사항의 구현을 검증하기 위함

 

위의 그림과 연계해서 보면 시험은 기본적으로 요구사항을 기반으로 해서 만들어 지는 것이고 그렇게 만들어진 요구사항 기반의 시험을 이용해서 하드웨어/소프트웨어 통합 시험, 소프트웨어 통합 시험, 하위레벨 시험이 수행되는 것을 확인할 수 있다.

 

이렇게 시험을 수행하게 되면 아래와 같이 커버리지를 분석하는 단계로 이동한다..

 

 

그림 23 시험수행 결과를 바탕으로 커버리지 분석

 

DO-178 가이드라인에는 그림에 나오는 각각의 시험 방법에 대해서 설명이 나온다. 그에 대한 내용을 확인해 보자.

 

②     요구사항 기반 시험 방법(Methods) (Section 6.4.3)

 

미리 언급할 부분이 있는데 DO-178 가이드라인에서 이야기하는 방법이라고 해서 무조건 따라야 하는 것은 아니라는 점이다. DO-178 가이드라인은 기본적으로 달성해야 할 목표에 초점을 맞추어 가이드하는 것이며 그 목표에 달성하는 방법은 프로젝트마다, 그 프로젝트를 수행하는 조직마다, 혹은 나라마다 다를 수 있다. 그리고 그것은 당연한 것이다. 따라서 여기에서 설명되는 방법에 대해서 참고는 하되 너무 얽매일 필요는 없다. DO-178 가이드라인 전반적으로 그런 성격을 가지고 있다는 점을 기억하자.

 

요구사항을 기반으로 수행하는 시험 방법에는 다음과 같은 것들이 있다.

 

a.     요구사항 기반 하드웨어/소프트웨어 통합 시험: 이 시험의 핵심은 타겟에서 수행한다는 점이다. 타겟이라는 시험 환경의 특성상 상위레벨 기능 위주로 시험이 이루어 지기 때문에 상위레벨 요구사항을 만족하는지를 시험하게 된다. DO-178 가이드라인에서는 이를 통해서 다음과 같은 에러들이 검출될 것이라고 예상하고 있다.

 

l  잘못된 인터럽트 핸들링

l  실행시간 요구사항을 만족하지 못함

l  하드웨어의 일시적 동작 혹은 실패에 대한 잘못된 소프트웨어 응답, 예를 들면 시동순서, 일시적인 입력부하, 입력 전원의 순간적인 구동이 있음

l  메모리 맵핑과 같은 데이터 버스와 다른 리소스의 충돌 문제

l  빌트인 시험에서 실패를 탐지하지 못함

l  하드웨어/소프트웨어 인터페이스상의 에러

l  컨트롤 루프의 잘못된 동작

l  소프트웨어 컨트롤하에서 메모리 관리 하드웨어 혹은 다른 하드웨어 장비에 대한 잘못된 컨트롤

l  스택 오버플로우

l  현장 적재가능 소프트웨어(Field-loadable Software)에 대한 정확성과 호환성을 보장하기 위해 사용되는 매커니즘의 잘못된 운영

l  소프트웨어 파티션 위반

 

참고로 이 시험을 통해서 위의 에러들이 무조건 발생하는 것은 아니지만 적어도 위의 에러를 체크하는 시험을 수행했는지에 대해서는 반드시 확인할 필요가 있다. 즉, 잠재된 문제점 확인을 위한 시험이 반드시 수행되어야 한다.

 

b.     요구사항 기반 소프트웨어 통합 시험: 이 시험은 앞서 보았던 하드웨어/소프트웨어 통합 시험과 비교되는 부분이 있는데 가장 큰 차이점은 이 시험은 타겟에 의존적이지 않다는 점이다. 물론 타겟 상에서 소프트웨어 통합 시험을 수행하는 것이 보다 더 정확한 결과를 얻는 것이지만 소프트웨어 컴포넌트 간의 아키텍처 관점에서의 상관 관계에 초점이 맞추어 지기 때문에 반드시 타겟 환경이 아니라고 해도 호스트 환경에서 시험을 수행할 수 있다. DO-178 가이드라인에서 예상하는 아래의 에러들을 보면 타겟에 의존적이지 않은 소프트웨어 자체의 동작과 관련된 부분이라는 점을 이해할 수 있을 것이다.

 

l  변수 및 상수에 대한 잘못된 초기화

l  파라미터 전달 에러

l  데이터 손상, 특히 전역 데이터

l  부적절한 수치 범위의 대입

l  이벤트와 동작의 부정확한 순서

 

c.     요구사항 기반 하위레벨 시험: 이 시험은 앞서 살펴 보았던 시험들과 비교해서 소스 레벨에 더 가까운 시험이라고 할 수 있다. 특히 앞에서 본 통합 시험에서 여러 가지 제약으로 확인하지 못하는 에러가 있을 경우 이 시험을 통해서 발견하게 될 수도 있다. DO-178 가이드라인에서는 이를 통해서 아래와 같은 에러들이 검출될 것이라고 예상하고 있다.

 

l  소프트웨어 요구사항을 만족하기 위한 알고리즘의 실패

l  정확하지 않은 루프 동작

l  정확하지 않은 로직 결정

l  입력 조건의 정당한 조합을 정확하게 수행하는 것을 실패하는 것

l  누락 혹은 손상된 입력 데이터에 대한 정확하지 않은 응답

l  배열 한계의 산술적 오류 혹은 손상과 같은 예외에 대한 부정확한 핸들링

l  정확하지 않은 계산 순서

l  부적절한 알고리즘 정밀도, 정확도, 혹은 성능

 

이렇게 세 가지 유형의 시험을 수행하고 나면 다음 단계인 요구사항 기반의 테스트 커버리지 분석을 수행하게 된다. 그런데 다음으로 넘어가기 전에 DO-178 가이드라인에서 제시하는 아래 유의사항을 반드시 짚고 넘어갈 필요가 있다.

 

 

해석을 보자.

 

유의사항: 만약 하드웨어/소프트웨어 통합 시험 혹은 소프트웨어 통합 시험을 위해 시험 케이스와 그와 관련된 시험 절차가 개발되고 실행되며 요구사항 기반 커버리지와 구조적 커버리지가 만족한다면 하위레벨 시험에 대한 시험을 중복할 필요는 없다. 상위레벨 시험에 대해서 명목상 동등한 하위레벨 시험을 대체하는 것은 시험되는 전반적인 기능성의 양을 줄이기 때문에 덜 효과적일 수 있다.

 

뒤에서 살펴보겠지만 커버리지 분석은 기본적으로 100%를 달성해야 한다는 기준이 있다. 소프트웨어 레벨에 따라서 100%를 달성하는 항목이 다를 수는 있지만 어쨌든 해당 레벨에서 요구하는 100%를 달성해야 한다. 위의 설명은 간단하게 말하면 하드웨어/소프트웨어 통합 시험 혹은 소프트웨어 통합 시험을 통해서 100%가 달성되면 굳이 하위레벨 시험을 추가로 할 필요가 없다는 말이다. 무조건 세 가지 유형의 시험을 모두 수행해야 하는 것은 아니라는 점에서 실질적인 업무량을 감소시키는 부분이라고 할 수 있다.

 

③     시험 커버리지 분석 (Section 6.4.4)

 

 

그림 24 커버리지 분석의 구분

 

앞서 보았던 세 가지 유형의 시험이 완료되면 위의 그림과 같이 커버리지 분석이 진행된다. DO-178 가이드라인에서는 위의 두 단계의 커버리지 분석을 다음과 같이 설명하고 있다.

 

 

해석을 보자.

 

시험 커버리지 분석은 요구사항 기반 커버리지 분석과 구조적 커버리지 분석이 포함된 두 단계의 프로세스이다. 첫 번째 단계는 선택된 시험 케이스들이 특정 기준을 만족하는 것을 확인하기 위해 소프트웨어 요구사항과의 관계에서 시험케이스를 분석한다. 두 번째 단계는 요구사항 기반 시험 절차들이 적용가능한 커버리지 기준에 따라서 코드 구조를 실행했다는 것을 확인한다.

 

설명만으로는 첫 번째 단계와 두 번째 단계가 정확하게 무엇을 말하는지 잘 와 닿지 않을 것 같 다. 간단하게 말하면 첫 번째 단계는 요구사항 기반으로 시험 케이스 자체를 정성적으로 분석하는 것이고 두 번째 단계는 첫 번째 단계에서 수행한 요구사항 기반 시험이 소스 코드 하나하나에 대해서 어떻게 수행되었는지를 가지고 실제로 커버리지를 확인하는 것이다. 사실 이 부분을 이해하기 위해서는 실제로 커버리지 분석을 수행하는 도구를 통해서 확인하는 것이 가장 효과적이다. 일단 여기서는 개념적으로 이러한 구분이 있다는 정도로 이해하고 넘어가고 이 부분은 추후 실제 도구나 관련 자료들을 통해서 별도로 설명할 예정이다.

 

n  요구사항 기반 시험 커버리지 분석 (Section 6.4.4.1)

 

커버리지 분석의 첫 번째 단계인 요구사항 기반 시험 커버리지 분석에 대해서 DO-178 가이드라인에서는 다음과 같은 활동을 수행할 것을 가이드하고 있다.

 

a.     시험 케이스가 각각의 소프트웨어 요구사항을 위해 존재한다는 것을 확인하기 위해 관련된 추적 데이터를 사용해서 분석

b.     정상(Normal) 및 강건성(Robustness) 시험의 기준을 만족하는 시험 케이스를 확인하기 위한 분석

c.     분석을 통해서 확인되는 결함에 대한 해결. 가능한 해결책은 시험 케이스를 추가하거나 강화하는 것

d.     구조적 커버리지를 달성하기 위해 사용된 모든 시험 케이스, 그에 따른 모든 시험 절차가 요구사항으로 추적가능하다는 것을 확인하기 위한 분석

 

위의 내용 중에서 정상(Normal) 및 강건성(Robustness) 시험을 주목할 필요가 있다. 실질적으로 시험 케이스는 모두 위의 두 가지 중 하나로 만들어 진다. 그런데 이들이 만들어지는 데에는 일정한 기준이 있다. 즉, 적당하게 시험 가능할 정도로 만드는 것이 아니라 DO-178에서 제시하는 지침에 따라서 그에 맞는 시험 케이스를 만들어야 하는 것이다.

 

n  정상 범위 시험 케이스(Normal Range Test Cases) (Section 6.4.2.1)

 

먼저 DO-178 가이드라인에서는 아래와 같이 정상 범위 시험 케이스(Normal Range Test Cases)에 대해서 다음과 같이 설명하고 있다.

 

 

해석을 보자.

 

정상 범위 시험 케이스는 정상 입력과 조건에 응답하는 소프트웨어의 능력을 보여준다.

 

‘정상 입력과 조건’에 유의해서 가이드라인에서 제시하는 다음의 활동(Activities)을 살펴보자.

 

a.     실수와 정수형 입력 변수는 동등한 클래스와 경계값을 사용해서 수행되어야만 함

b.     필터(Filters), 통합기(Integrators) 그리고 딜레이(Delays)와 같은 시간과 관련된 기능의 경우 상황에 맞는 기능 특성을 확인하기 위해 코드에 대한 여러 번의 반복이 수행되어야 함

c.     상태 전이에 대해서 정상 동작 동안에 가능한 전이를 수행하기 위한 시험 케이스가 개발되어야 함

d.     로직 방정식에 의해서 표현되는 소프트웨어 요구사항을 위해 정상 범위(Normal Range) 시험 케이스가 변수 사용과 이진 연산자를 검증해야 함

 

사실 정상(Normal) 범위 시험이라는 것은 일반적으로 생각하는 요구사항에 정의된 일정 범위 안에서의 시험이고 지금까지의 설명이 좀 딱딱(?)해서 그렇지 DO-178이라고 해서 다르지 않다. 다만 위의 활동들과 같이 자칫 놓치고 갈 수 있는 부분들도 모두 확인해서 시험해야 한다는 것이다.

 

n  강건성 시험 케이스(Robustness Test Cases) (Section 6.4.2.2)

 

이는 강건성(Robustness) 시험에서도 마찬가지이다. 우선 강건성 시험에 대한 가이드라인의 설명을 보자.

 

 

해석을 보면

 

강건성 시험 케이스는 비정상적인 입력과 조건에 응답하는 소프트웨어의 능력을 보여준다.

 

DO-178 가이드라인에서는 다음과 같이 강건성 시험에 대해서 상대적으로 더 다양한 활동(Activities)을 제시하고 있다.

 

a.     실수와 정수형 입력 변수는 동등한 클래스와 경계값을 사용해서 수행되어야만 함

b.     시스템 초기화가 비정상적인 조건 동안에 수행되어야 함

c.     입력되는 데이터에서 발생할 수 있는 실패 모드가 결정되어야 함. 특히 외부 시스템으로부터의 복잡한, 디지털 데이터 스트링

d.     루프 카운트가 계산되는 루프의 경우 루프 카운트의 범위를 벗어나는 계산을 시도하는 시험 케이스가 개발되어서 강건성을 시험해야 함

e.     올바르게 응답하는 프레임 시간을 넘어서는 경우에 대한 방어 메커니즘을 보장하기 위한 체크가 되어야 함

f.      필터(Filters), 통합기(Integrators) 그리고 딜레이(Delays)와 같은 시간과 관련된 기능들을 위해서 산술적인 오버플로우 방지 매커니즘을 위한 시험 케이스가 개발되어야 함

g.     상태 전이에 대해서 소프트웨어 요구사항에 허용되지 않는 전이를 일으키는 시험 케이스가 개발되어야 함

 

상당히 복잡하고 어려운 내용들이 제시되고 있고 실제로 현장에서 위의 내용들을 모두 고려해서 시험 케이스를 만들고 실제로 시험까지 진행하기에는 상당한 어려움이 있는 것이 사실이다. 하지만 항공기의 안전성이라는 점을 생각해 보면 위에서 설명하는 강건성(Robustness) 시험 활동들이 반드시 필요하다는 것을 받아들이지 않을 수 없는 것도 사실이다.

 

n  구조적 커버리지 분석 (Section 6.4.4.2)

 

시험 케이스를 중심으로 한 요구사항 기반 시험 커버리지 분석이 완료되면 그 다음 단계는 구조적 커버리지 분석(Structural Coverage Analysis)이 이루어 진다. DO-178 가이드라인에서는 구조적 커버리지 분석의 역할을 다음과 같이 정의하고 있다.

 

 

해석을 보자.

 

이 분석은 컴포넌트간의 인터페이스를 포함해서 어떤 코드 구조가 요구사항 기반 시험 절차에 의해서 실행되지 않았는지를 결정한다.

 

위의 설명은 결과적으로 시험을 수행했을 때 소스 코드를 100% 수행했는지를 체크한다는 내용이다. 커버가 된 범위가 어느 정도인지를 확인하는 것이다. 이러한 구조적 커버리지 분석은 기본적으로는 소스를 기준으로 분석을 진행하게 된다. 사실 이는 대부분의 경우 그렇다는 것이고 실제로는 오브젝트 코드 혹은 실행가능 오브젝트 코드로도 커버리지 분석이 가능은 하다. 하지만 그렇게 진행하기는 현실적으로 너무 어렵고 비용이 많이 들기 때문에 현장에서 그 정도까지 진행되는 경우는 드물다고 보아야 한다. 필자는 아직 소스 코드 수준의 진행만 보았고 다른 사례는 경험한 바가 없다.

 

커버리지 분석을 위한 활동에는 다음과 같은 것들이 있다.

 

a.     요구사항 기반 시험 중에 수집된 구조적 커버리지 분석을 확인하여 구조적 커버리지의 범위가 해당 소프트웨어 레벨에 적합한지를 확인

b.     구조적 커버리지 분석은 소스 코드, 오브젝트 코드, 혹은 실행가능 오브젝트 코드상에서 수행될 수 있음. 특히 소프트웨어 레벨이 A이고 컴파일러, 링커 혹은 다른 방법으로 직접적으로 추적할 수 없는 소스 코드가 추가되는 경우가 있다면 그렇게 추가된 코드가 정확하다는 것을 확인할 수 있는 추가적인 검증

c.     요구사항 기반 시험이 코드 컴포넌트간의 데이터 및 컨트롤 커플링을 수행했는지를 확인하기 위한 분석

d.     구조적 커버리지 분석의 해결, 즉 실행되지 않은 코드에 대한 처리

 

위의 내용 중 b에서 나오는 ‘직접적으로 추적할 수 없는 소스 코드가 추가되는 경우’라는 것은 쉽게 말해서 컴파일러가 소스 코드를 최적화하는 경우를 생각하면 된다. 이 경우 실제 개발자가 작성한 소스 코드와 컴파일러를 거친 컴파일된 코드는 일부 다른 형태가 될 수 있다. DO-178에서는 그런 부분까지도 확인을 해서 문제가 없다는 것을 보이라고 요구하는 것이다. 이에 대한 구체적인 내용은 다른 절에서 다시 설명하겠다.

 

n  구조적 커버리지 분석의 해결 (Section 6.4.4.3)

 

이 부분은 앞서 진행되었던 구조적 커버리지 분석의 문제점에 대한 해결방법에 대해서 설명하는 것이다. DO-178 가이드라인에서는 이러한 ‘문제점’의 범위를 다음과 같이 규정하고 있다.

 

 

해석을 보자.

 

구조적 커버리지 분석은 인터페이스를 포함해서 시험 동안에 수행되지 않았던 코드 구조를 보여줄 수 있다.

 

일단 소스 코드가 수행되지 않았다는 것이 중요하다. 소스 코드가 수행되지 않으면 그 부분은 커버리지에서 누락되는 것이고 그렇다면 그 부분이 왜 수행되지 않았는지가 밝혀져야 한다. DO-178 가이드라인에서는 그에 대한 원인을 다음과 같은 것들로 구분하고 각각의 해결방법을 제시하고 있다.

 

a.     요구사항 기반 시험 케이스 혹은 절차의 부족: 이런 경우는 시험 케이스 혹은 절차를 수정해야 함. 한편으로는 요구사항 기반 커버리지 분석에 사용된 방법이 제대로 되었는지를 다시 체크해야 함

b.     불충분한 소프트웨어 요구사항: 소프트웨어 요구사항 자체가 충실하지 못한 것으로 부족한 부분을 채운 새로운 요구사항이 나오게 되면 추가적인 시험 케이스가 만들어지고 시험 절차가 수행되어야 함. (참고: 사실 이런 경우에는 해당하는 요구사항과 관련된 소프트웨어 라이프 사이클 전체가 다시 진행되어야 할 수도 있다.)

c.     죽은 코드(Dead Code)를 포함한 관계없는 코드: 기본적으로 Dead Code는 제거되어야 함. 그리고 제거를 하게 되면 제거로 인해서 기존 코드에 영향이 없는지를 체크해야 함. 컴파일 과정에서 포함되지 않는다는 것이 100% 보장된다면 남아있을 수도 있다는 설명이 있긴 하지만 실전에서는 그냥 제거하는 것이 제일 깔끔하다고 할 수 있음. (참고: 죽은 코드와 다음에 나오는 비활성화된 코드에 대해서는 다른 절에서 자세히 설명된다.)

d.     비활성화된 코드: 비활성화된 코드는 전혀 실행되지 않는 케이스(Category One)와 특정 상태에서만 실행되는 케이스(Category Two)로 구분됨.

1.     Category One: 비활성화된 코드가 의도치 않게 실행되는 것을 방지하거나 완전하게 분리시키거나 혹은 제거하는 방법을 제시해야 함

2.     Category Two: 승인된 조건에서만 실행되는 설정이 만들어지고 커버리지를 만족하기위한 추가적인 시험 케이스 및 절차가 개발되어야 함

 

커버리지 누락에는 다양한 원인이 있을 수 있기 때문에 그에 따른 활동도 다양하게 이루어 질 수 있다. 따라서 커버리지 분석 결과를 잘 분석해서 정확한 원인이 무엇인지 파악하고 위에서 제시된 내용들을 참고해서 원인에 맞는 활동이 수행되어야 한다.

 

(5)    소프트웨어 검증 프로세스 추적성 (Section 6.5)

 

DO-178에서는 소프트웨어 검증에서도 소프트웨어 요구사항과 같이 추적성은 필수이다. 그렇다면 실제로 추적성은 어떻게 연결해야 하는 것일까? DO-178에서는 아래와 같이 가이드하고 있다.

 

a.     소프트웨어 요구사항과 시험 케이스간의 양방향 연결성을 보여주는 추적성 데이터 개발. 이렇게 만들어지는 추적성 데이터는 요구사항 기반 시험 커버리지 분석에 사용됨

b.     시험 케이스와 시험 절차간의 양방향 연결성을 보여주는 추적성 데이터 개발

c.     시험 절차와 시험 결과간의 양방향 연결성을 보여주는 추적성 데이터 개발

 

(6) 파라미터 데이터 아이템(Parameter Data Items)에 대한 검증 (Section 6.6)

 

앞서 파라미터 데이터 아이템은 일반적으로 파일형태로 사용되는 일종의 ‘설정파일’이라고 말 한 바가 있다. 설정파일이라는 것은 보통 메인이 되는 실행 파일과 함께 사용되는 것이므로 실행파일이 시험될 때 함께 사용되는 것이 일반적이고 따라서 시험 과정을 통해서 자연스럽게 설정파일도 시험되는 것이라고 할 수 있다.

 

하지만 DO-178 가이드라인에서는 이 부분에 대해서도 상당히 엄격한 가이드를 제시하고 있다. 즉, 파라미터 데이터 아이템 자체를 실행파일과 분리해서 독립적으로 시험하라고 하는 것이다. 이는 결과적으로 파라미터 데이터 아이템에 대한 요구사항부터 별도로 존재한다는 것을 의미한다. 특히 실행파일과 함께 이루어 지는 시험을 통해서는 파라미터 데이터 아이템을 포함한 기능이 정상적으로 수행되는 것을 확인하는 것이라면 리뷰 혹은 분석을 통해서 파라미터 데이터 아이템이 요구사항에 맞게 만들어 졌는지를 주로 체크하게 된다.

 

이와 관련된 DO-178 가이드라인의 내용을 여기서 자세히 설명하지는 않지만 만약 본인의 소프트웨어가 파라미터 데이터 아이템을 사용한다면 DO-178 가이드라인에서 제시하는 검증 방법을 반드시 수행해야 한다는 것을 명심하자.