20. SVP(Software Verification Plan) (Section 11.3)

‘소프트웨어 검증 계획’으로 번역할 수 있는 SVP 문서는 다음과 같은 내용을 담고 있다.

 

해석을 보자.

 

소프트웨어 검증 계획은 소프트웨어 검증 프로세스 목표를 만족시키기 위해 사용되는 검증 절차에 대한 설명이다. 이러한 절차는 부속물 A의 테이블에 정의된 소프트웨어 레벨에 의해서 변할 수 있다.

 

SDP와는 달리 소프트웨어 레벨에 대한 설명이 나오고 있다. 소프트웨어 개발에 있어서는 소프트웨어 레벨에 따른 차이가 별로 없지만 소프트웨어 검증 과정은 차이가 많다는 점을 보여주고 있다. 다른 절에서 이미 확인한 것처럼 실제로 부속물 A의 테이블에는 아래와 같이 레벨에 따라서 해당하는 목표가 달라진다.(붉은색 표시 참조)

 

 

따라서 SVP에는 소프트웨어 레벨에 따라서 소프트웨어 검증에 대한 작성 내용이 달라질 수 있다. 이런 점을 염두에 두고 SVP에 포함되어야 할 내용을 살펴보자.

 

a.      조직(Organization)

 

일반적으로 소프트웨어 개발에는 개발조직뿐만 아니라 검증, 지원 등의 여러 조직이 관여하게 된다. SVP에 작성하는 조직이라는 것은 그러한 조직들을 나열하는 것이 아니라 다음에 설명하는 내용을 작성하는 것이다.

 

해석을 보자.

 

a. 조직: 다른 소프트웨어 라이프 사이클 프로세스와의 소프트웨어 검증 프로세스 및 인터페이스내에서의 조직의 책임

 

초점이 소프트웨어 검증 프로세스 자체에 있다는 것을 알 수 있다. 이처럼 SVP에는 소프트웨어 검증 프로세스의 관점에서 다른 소프트웨어 라이프 사이클과의 관계와 책임이 작성되어야 한다.

 

b.      독립성(Independence)

 

독립성에 대한 것은 아래 표의 붉은색 표시를 주의해서 보아야 한다. 가만히 보면 레벨별로 검정색으로 채워진 원과 흰색의 원으로 구분된 것을 알 수 있다. 바로 이것이 독립성을 구분하는 정보이다.

 

 

가이드라인에는 검정색원과 흰색원 그리고 우측의 ‘Control Category by Software Level’에 표시된숫자에 대해서 다음과 같이 설명하고 있다.

 

 

검정색원에는 다음과 같이 설명되어 있다.

 

-       목표가 독립적으로 만족되어야 한다

 

그런데 흰색원에는 ‘독립적으로’라는 말이 없이 그냥 ‘만족되어야 한다’고만 되어 있다. 이것이 독립성에 대한 구분이며 따라서 검정색원으로 표시된 목표(Objective)는 반드시 독립적으로 달성되어야 한다는 의미이다.

 

‘독립적’이라는 것이 구체적으로 어떤 것인지 대충 짐작이 될 텐데 간단하게 말하면 만든 사람과 검사하는 사람이 달라야 한다는 것을 말한다. 좀 더 자세한 설명이 추가될 수는 있겠지만 결국 핵심은 그것이다. 표를 기준으로 보면 레벨이 높을수록 달성해야 할 목표도 많아지고 독립성도 더 요구된다는 것을 확인할 수 있다.

 

다시 처음으로 돌아가서 독립성에 대한 가이드라인의 설명은 다음과 같다.

 

해석을 보자.

 

b. 독립성: 필요할 때, 검증의 독립성을 수립하기 위한 방법에 대한 설명

 

앞서 설명한 것처럼 이 부분은 소프트웨어 레벨에 따라서 달라지게 되며 실제 작성 내용은 해당하는 레벨을 준수한다는 정도로 간단하게 작성하면 되지만 중요한 것은 실제로 해당하는 레벨의 검증결과와 해당하는 레벨의 독립성을 어떻게 확보하고 보여줄 것이냐가 관건이다. 물론 가장 좋은 방법은 독립된 품질 조직 혹은 담당자를 두고 독립적인 활동을 보장하는 것이다.

 

c.      검증방법(Verification methods)

 

검증 계획문서인만큼 당연히 검증 방법이 작성되어야 한다. 가이드라인에서는 다음과 같은 검증 방법에 대한 설명을 작성하도록 가이드하고 있다.

 

1.     리뷰 방법, 체크리스트 혹은 다른 보조를 포함

2.     분석 방법, 추적성과 커버리지 분석을 포함

3.     시험 방법, 시험 케이스, 사용될 시험 절차, 그리고 생성될 시험 데이터의 선택을 포함

 

소프트웨어 개발 과정에서 사용되는 리뷰(Review), 분석(Analysis), 시험(Test)이 무엇인지 구체적으로 작성되어야 한다. 여기서 구체적이라는 범위가 어느 정도인지가 애매할 수 있지만 적어도 인증당국에서 보았을 때 이 소프트웨어에 대해서 어떤 검증이 이루어지는지를 이해할 수 있는 수준이 되어야 한다. 여전히 애매하기는 하지만 너무 상세하게 작성할 필요는 없다는 것은 짐작할 수 있을 것이다.

 

d.      검증환경(Verification environment)

 

시험을 위한 장비, 시험 및 분석툴, 이러한 툴의 적용 방법, 하드웨어 시험 장비에 대해서 설명하는 부분이다. 타겟/시뮬레이터/에뮬레이터의 차이에 대한 설명이 필요한 경우 여기에 작성하게 된다.

 

e.      전이기준(Transition criteria)

 

여기서 말하는 전이기준에 대해서 가이드라인의 설명은 다음과 같다.

 

해석을 보자.

 

e. 전이기준: 소프트웨어 검증 프로세스로 들어가기 위한 전이 기준

 

위의 내용만 보면 검증 프로세스로 들어가는 것만 언급되어 있고 그 전단계가 무엇인지는 나와 있지 않다. 필자가 지금까지 경험하고 확인한 것들을 기준으로 보자면 기본적으로는 통합 프로세스(Integration process)로부터의 전이를 이야기하는 것이다. 이럴 경우 통합 프로세스가 상당부분 완료된 상태라고 볼 수 있으므로 아래와 같은 여러가지 조건들이 있을 수 있다.

 

-       소프트웨어 아키텍처가 완료되어야 함

-       소스코드가 완전하게 작성되어야 함

-       실행가능파일이 완성되어야 함

-       타겟이 완전하게 갖추어 져야 함

 

여기서 혹시 검증 프로세스가 오직 통합 프로세스가 완료되어야만 가능한 것으로 이해될 수도 있을 듯 한데 이곳에 작성되는 내용은 전이기준을 공식적인 기준으로 설명하는 것이며 실제 진행과정에서 이루어 지는 부분적인 검증 활동은 이와는 관계없이 SVP에 작성되어 있는 검증계획에 따라서 수시로 진행하게 된다.

 

그 외에 SVP에 포함되어야 할 항목들은 아래와 같다.

 

-       파티션 고려사항: 파티션 사용 시 파티션의 완결성을 검증할 수 있는 방법

-       컴파일러 가정: 컴파일러, 링커 에디터, 혹은 로더의 정확성에 대한 가정

-       재검증 방법: 소프트웨어 수정사항이 발생한 경우 소프트웨어와 실행파일의 영향을 받는 부분을 구분하고, 분석하고, 검증하는 방법

-       이전에 개발된 소프트웨어: 이전에 개발된 소프트웨어가 사용될 경우 동일한 검증 방법을 적용할 수 없을 경우 현재 개발중인 소프트웨어 개발에서 사용되는 검증 요구사항을 만족시킬 방법

-       다중 버전 비유사성 소프트웨어: 다중 버전 비유사성 소프트웨어가 사용될 경우 수행할 소프트웨어 검증 프로세스 활동 (이에 대해서는 다른 절에서 추가 설명이 있을 예정)

 

위의 항목 중에서 검증 관점에서 특히 유의해야 할 부분은 ‘재검증 방법(Reverification method)’이다. 가이드라인에서는 다음과 같이 설명하고 있다.

 

해석을 보자.

 

h. 재검증 방법: 소프트웨어 수정에 대해서 소프트웨어의 영향을 받는 영역과 실행가능 오브젝트 코드의 변경되는 부분을 구분하고 분석하고 검증하는 방법에 대한 설명

 

특히 개발이 완료되어 가는 시점이나 완료된 이후에 발생하는 수정사항은 그것이 미치는 영향을 제대로 확인하지 못하는 경우 자칫 엄청난 문제를 일으킬 수 있다. 하지만 현장에서는 그런 부분을 제대로 챙기지 못하고 넘어가는 경우가 많다. DO-178에서는 그것이 용납되지 않으며 계획단계에서부터 그런 부분까지 고려해서 SVP에 작성하도록 함으로써 실제 그런 상황이 발생하는 경우 SVP를 근거로 제대로 된 검증활동을 수행하도록 하고 있다.