14. DO-178과 소프트웨어 품질보증 프로세스 (Section 8.0)

필자는 현재 DO-178 컨설팅을 하고 있지만 그와 함께 QA로 불리는 활동을 수행하는 경우가 많다. 여기서 QA가 바로 이번 절에서 설명하려고 하는 품질보증(Quality Assurance)이다. 용어 자체로만 보면 소프트웨어의 품질을 책임지는 역할 정도로 이해가 되지만 실제 DO-178 인증의 관점에서는 다소 뉘앙스가 다르다. 앞으로 나오는 DO-178 가이드라인에 대한 설명을 통해서 그 차이를 확인해 보자.

 

소프트웨어 품질보증 프로세스 역시 앞서 보았던 다른 프로세스와 마찬가지로 소프트웨어 계획 프로세스(Software Planning Process)를 통해서 소프트웨어 품질보증 계획(Software Quality Assurance Plan) 문서로 작성되며 이 계획 문서에 작성된 대로 진행되어야 한다.

 

(1)    소프트웨어 품질보증 프로세스의 목표(Objectives) (Section 8.1)

 

DO-178 가이드라인에서는 소프트웨어 품질보증 프로세스의 목표(Objective), 활동(Activity), 결과(Output)를 부속물(Annex) A의 Table A-9에서 다음과 같이 확인할 수 있다.

 

 

앞서 여러 번 같은 형태의 설명을 드린 바가 있기 때문에 이제 위의 표를 어떻게 활용하는지에 대해서는 대략적으로 이해를 할 수 있을 것이다. 위의 표에서 ‘Ref’칸에 작성된 링크를 통해서 관련된 자세한 내용을 확인하게 된다.

 

우선 위의 표를 기준으로 간략하게 정리하면 다음과 같다.

 

1.      이 문서(즉, DO-178 가이드라인)를 따르고 일관성을 가지도록 소프트웨어 계획과 표준이 개발되고 리뷰된다는 것을 보장해야 함

2.      소프트웨어 라이프 사이클 프로세스가 승인된 소프트웨어 계획을 따른다는 것을 보장해야 함

3.      소프트웨어 라이프 사이클 프로세스가 승인된 소프트웨어 표준을 따른다는 것을 보장해야 함

4.      소프트웨어 라이프 사이클 프로세스에 대한 전이 기준을 만족한다는 것을 보장해야 함

5.      소프트웨어 적합성 리뷰(Software Conformity Review)가 수행되는 것을 보장해야 함

 

위의 내용을 보면 소프트웨어 계획과 표준이 자주 언급되고 있다. 그 만큼 DO-178에서는 계획과 표준이 중요하다는 것을 다시 한 번 보여주고 있다. 여기에 마지막 5번에는 소프트웨어 적합성 리뷰(Software Conformity Review)라는 다소 익숙하지 않은 용어가 나온다. 이것은 일종의 최종 시험이라고 할 수 있는데 DO-178 관점에서 어떤 시험인지를 정확하게 알아야 한다. 이에 대해서는 별도의 절에서 다시 설명한다.

 

표에 포함되어 있는 링크를 따라가보면 위에서 정리한 것과 거의 동일한 내용으로 소프트웨어 품질보증 프로세스의 목표가 정리되어 있다. 그 중 추가적인 설명이 필요한 몇 가지를 정리해 본다.

 

①     납품업체(Supplier)

 

먼저 아래 문장에 나오는 납품업체(Supplier)에 대한 부분이다.

 

해석을 보자.

 

b. 납품업체들의 것들을 포함해서 소프트웨어 라이프 사이클 프로세스가 승인된 소프트웨어 계획과 표준을 따른다.

 

DO-178 인증은 오직 소프트웨어와 그 소프트웨어를 만드는 과정에 초점을 맞춘다. 그것은 인증 대상이 되는 소프트웨어를 누가 만드느냐는 중요하지 않다는 뜻이다. 다들 알고 있는 것처럼 소프트웨어는 때때로 일부를 별도의 납품업체에 일임해서 개발하는 경우가 있다. 이런 경우 자신과 직접 관련이 없다는 생각으로 납품업체에 대한 부분은 별로 신경을 쓰지 않는 경우가 많다. 필자의 경험으로는 DO-178 인증의 대상이 된다는 자체를 생각하지 못하는 경우도 있었다. 하지만 원칙적으로 납품업체 역시 DO-178 가이드라인을 그대로 따라야 한다. 위의 내용은 그것을 설명하고 있는 것이다. 참고로 그런 경우에 납품업체가 어떤 형태로, 어느 수준으로 DO-178 인증을 진행해야 하는지는 인증 전문가의 도움을 받아서 조율할 필요가 있다.

 

②     전이기준(Transition Criteria)

 

다음으로 나오는 것이 전이기준(Transition Criteria)이다.

 

해석을 보자.

 

c. 소프트웨어 라이프 사이클 프로세스에 대한 전이기준이 만족된다.

 

DO-178 가이드라인에서는 전이기준을 다음과 같이 정의하고 있다.

 

해석을 보자.

 

전이 기준 – 하나의 프로세스로 들어가기 위해 만족되어야 하는 소프트웨어 계획 프로세스에 의해서 정의된 최소한의 조건들

 

우리가 일반적으로 알고 있는 PDR, CDR 진입/진출 기준이라고 할 수 있는데 DO-178에서는 이를 앞서 설명한 바가 있는 여러가지 프로세스들을 기준으로 하는 차이가 있을 뿐이다. 참고로 이러한 전이기준은 소프트웨어 계획 프로세스에서 작성되는 계획문서 중에서 소프트웨어 개발 계획(Software Development Plan)문서에 작성하도록 하고 있다. 따라서 해당 문서에 작성된 전이기준의 만족여부를 확인하게 된다.

 

③     적합성 리뷰(Conformity Review)

 

마지막으로 확인할 부분은 다음에 나오는 적합성 리뷰(Conformity Review)이다.

 

해석을 보자.

 

d. 소프트웨어 제품의 적합성 리뷰가 수행된다.

 

적합성 리뷰에 대해서는 뒤에서 좀 더 자세하게 설명된다.

 

(2)    소프트웨어 품질보증 프로세스 활동 (Section 8.2)

 

서두에서 소프트웨어 품질보증 프로세스가 일반적인 품질보증 활동과는 뉘앙스가 조금 다르다고 말한 바가 있다. DO-178 가이드라인에서 제시하는 품질보증 프로세스에서 수행해야 할 활동이 무엇인지 정확하게 확인해 보고 그 차이를 이해해 보자.

 

a.      품질보증 프로세스는 소프트웨어 라이프 사이클 프로세스의 활동에서 적극적인 역할을 수행해야 함. 특히 앞서 설명된 목표(Objectives)를 만족하기 위해서 그 만큼의 권한(Authority), 책임(Responsibility) 그리고 독립성(Independence)을 가지고 수행해야 함

b.     소프트웨어 계획과 표준이 개발되고 이 문서를 제대로 따르는 지, 일관성을 가지고 있는지에 대한 보장을 품질보증 프로세스가 제공해야 함

c.      품질보증 프로세스는 소프트웨어 라이프 사이클 프로세스가 승인된 소프트웨어 계획과 표준을 따른다는 것을 보장해야 함

d.     품질보증 프로세스는 소프트웨어 라이프 사이클 동안에 다음과 같은 보장을 확보하기 위해서 감사를 포함해야 함

1.     소프트웨어 계획이 DO-178 가이드라인 Section 4.2에 기술한 대로 이용 가능함

2.     소프트웨어 계획과 표준과의 차이가 탐지되고 기록되고 평가되고 추적되고 해결됨

3.     승인된 차이가 기록됨

4.     소프트웨어 개발 환경이 소프트웨어 계획에 기술된 대로 제공됨

5.     문제점 리포트, 추적 그리고 수정 행위 프로세스 활동이 소프트웨어 형상관리 계획(Software Configuration Management Plan)을 따름

6.     시스템 안전성 평가 프로세스를 포함해서 시스템 프로세스에 의해 소프트웨어 라이프 사이클 프로세스로 제공되는 입력이 작성됨

 

e.      품질보증 프로세스는 소프트웨어 라이프 사이클 프로세스를 위한 전이 기준이 승인된 소프트웨어 계획을 따른다는 것을 만족해 왔다는 것을 보장해야 함

f.       품질보증 프로세스는 소프트웨어 라이프 사이클 데이터가 관리 범주(Control Category)에 따라서 컨트롤된다는 것을 보장해야 함

g.     소프트웨어 제품이 인증 지원의 일부로써 제출되기 앞서서 소프트웨어 적합성 리뷰(Conformity Review)가 수행되어야 함

h.     품질보증 프로세스는 각 소프트웨어 제품이 인증 지원의 일부로써 제출되기 위해 감사 결과와 소프트웨어 적합성 리뷰의 완료 증거를 포함해서 품질보증 프로세스 활동의 기록을 생산해야 함

i.       품질보증 프로세스는 승인된 소프트웨어 계획과 표준을 따르는 납품업체 프로세스와 산출물을 제공해야 함

 

상당히 많은 내용이 나오는데 실제로 DO-178 인증을 받기 위해서는 위의 품질보증 활동을 하나하나 정확하게 수행해야 한다. 그리고 그에 따른 결과를 정확하게 남기고 인증당국에 제출할 수 있어야 한다. 필자가 여기서 DO-178 인증에서의 품질보증 활동이 일반적인 것과 뉘앙스가 다르다고 말하고자 하는 부분은 바로 우리가 일반적으로 생각하는 품질이라는 단어가 지금까지 나온 활동들에서는 핵심이 아니라는 것이다. 오히려 품질 자체에 대해서 말하는 부분은 하나도 없다. 위의 내용만 보면 이것이 우리가 일반적으로 생각하는 품질보증 활동이 맞나라는 생각이 들지도 모르겠다.

 

여기에서도 DO-178의 철학을 엿볼 수 있다. 즉, DO-178에서는 계획과 표준에 따라서 제대로 수행하는 것을 제대로 된 품질을 갖추는 것이라고 보는 것이다. 사실 조금만 생각해 보면 이 말은 분명히 품질보증 활동이 맞다. 가장 기본이 되는 활동이다. 하지만 현실에서는 그렇게 진행하는 것이 너무도 어렵고 비용이 많이 들다 보니 어느새 그런 부분을 무시하고 지나가게 되었는지 모른다. 그런 면에서 어쩌면 그것은 가장 어려운 품질보증 활동일지도 모른다.

 

어쨌든 여기서도 적합성 리뷰(Conformity Review)가 아주 중요하게 언급되고 있다. 이제 그것에 대해서 살펴보자.

 

(3)    소프트웨어 적합성 리뷰 (Section 8.3)

 

DO-178 인증에서는 소프트웨어 적합성 리뷰가 상당히 중요하다. 그리고 이는 반드시 수행되어야 하고 아울러 정확하게 수행되어야 한다. 그러기 위해서는 그 의미를 정확하게 파악하고 DO-178 가이드라인에서 요구하는 것을 빠짐없이 수행해야 한다. 먼저 아래의 설명을 보자.

 

해석을 보자.

 

소프트웨어 적합성 리뷰의 목적은 인증 지원의 일부로써 제출되는 소프트웨어 제품에 대해서 소프트웨어 라이프 사이클 프로세스가 완료되고, 소프트웨어 라이프 사이클 데이터가 완전하고 실행가능 오브젝트 코드와 만약 있다면, 파라미터 데이터 아이템 파일이 컨트롤되고 재생성 될 수 있다는 것에 대한 보장을 확보하는 것이다.

 

앞서 적합성 리뷰를 일종의 최종시험 정도로 이야기했지만 위에서 보듯이 분명 그 이상의 복잡한 의미를 담고 있다. 특히 인증을 위해서 적합성 리뷰의 결과가 제출되어야 하기 때문에 위에서 언급하고 있듯이 소프트웨어 라이프 사이클 프로세스가 완벽하게 수행되었고 거기에서 나오는 데이터가 완전하다는 것을 보장할 수 있어야 한다. 거기에는 언제든 이 데이터를 이용해서 인증을 받게 되는 소프트웨어와 동일한 소프트웨어가 만들어 질 수 있다는 것을 보장하는 것까지 포함된다.

 

정말 간단하게 적기는 했지만 이것은 절대 간단하게 될 수 있는 것이 아니다. 적합성 리뷰 자체는 상대적으로 간단하게 끝날 수 있을지 모르지만 그것을 수행하기까지 준비하고 완료되어야 하는 것이 상상을 할 수 없을 정도로 어마어마하게 많다. 그리고 그 중에 하나라도 제대로 준비되지 않으면 적합성 리뷰를 수행할 수 없게 된다.

 

이런 모든 것을 감안하고 그것을 기준으로 준비가 완료된다면 이제 리뷰를 통해서 다음을 결정하게 된다. 참고로 여기에서 리뷰라는 단어를 사용했는데 이는 우리가 이전에 설명한 바가 있는 그런 단순한 리뷰를 말하는 것이 아니라 전반적인 리뷰, 분석 그리고 시험까지를 모두 포함하는 일종의 프로세스 관점으로 이해하기 바란다.

 

a.      소프트웨어 라이프 사이클 데이터의 생성을 포함해서 인증 신뢰를 위한 계획된 소프트웨어 라이프 사이클 프로세스 활동이 완료되고 그 완료의 기록이 유지됨

b.     특정한 시스템 요구사항, 안전성 관련 요구사항, 혹은 소프트웨어 요구사항으로부터 개발된 소프트웨어 라이프 사이클 데이터가 그러한 요구사항과 추적 가능함

c.      소프트웨어 라이프 사이클 데이터가 소프트웨어 계획과 표준에 따라서 생산되었다는 증거가 존재하고 형상관리 계획에 따라서 컨트롤됨

d.     문제점 리포트가 평가되고 그 상태가 기록되어온 증거가 존재함

e.      소프트웨어 요구사항 차이점들이 기록되고 승인됨

f.       실행가능 오브젝트 코드와 만약 있다면 파라미터 데이터 아이템 파일이 저장된 소스코드로부터 재생성 될 수 있음

g.     승인된 소프트웨어가 릴리즈된 명령의 사용을 통해서 성공적으로 적재될 수 있음

h.     이전 소프트웨어 적합성 리뷰로부터 연기된 문제점 리포트가 그 상태를 결정하기 위해 재평가됨

i.       만약 인증 신뢰가 이전에 개발된 소프트웨어(Previously Developed Software)를 사용하려고 한다면 현재 소프트웨어 제품 베이스라인이 이전 베이스라인과 그 베이스라인에서의 승인된 변경을 추적 가능함

 

말그대로 소프트웨어가 DO-178 인증을 받을 수 있는지를 최종적으로 체크하는 내용이 모두 포함되어 있다. 위의 내용 중 하나라도 결정되지 않으면 결과적으로 그 소프트웨어는 적합성 리뷰를 수행할 수 없고 따라서 DO-178 인증을 받을 수 없다.