25. 디자인 설명 (Section 11.10)

앞서 DO-178은 요구사항이라는 것에 대해서 독자적인 개념을 가지고 있다고 말한 바가 있다. 필자가 판단하기로는 지금 설명하는 설계 문서를 요구사항의 관점으로 다루고 있는 부분이 가장 큰 차이가 아닌가 싶다. 참고로 여기서도 용어가 좀 헷갈릴 수 있는데 ‘Design Description’은 우리가 일반적으로 SDD라고 부르는 것으로 이해해도 무방하며 필자는 ‘Software Design Document’라고 주로 사용하고 있다. 일단 DO-178 가이드라인은 SDD에 대해서 다음과 같이 설명하고 있다.

 

해석을 보자.

 

디자인 설명은 상위레벨 요구사항을 충족할 소프트웨어 아키텍처와 하위레벨 요구사항의 정의이다.

 

사실 위의 설명은 우리가 일반적으로 이해하는 설계 문서와 같다고 보면 된다. 하위레벨 요구사항이라는 용어를 사용해서 그렇지 결국은 우리가 설계 문서에 작성하는 코드와 관련된 내용이기 때문이다. 실제로도 DO-178 가이드라인에서는 하위레벨 요구사항을 가지고 코드를 작성하도록 가이드하고 있다.

 

SDD에는 구체적으로 아래와 같은 항목들이 포함되어야 한다.

 

a.      알고리즘, 데이터 구조, 그리고 소프트웨어 요구사항이 어떻게 프로세서와 태스크로 할당되는지를 포함해서 소프트웨어가 어떻게 상세화된 상위레벨 요구사항을 충족하는지에 대한 상세한 설명

b.     요구사항을 구현하기 위해 소프트웨어 구조를 정의하는 소프트웨어 아키텍처에 대한 설명

c.      입/출력에 대한 설명, 예를 들면, 소프트웨어 아키텍처 전반에 걸쳐 내부적 및 외부적인 데이터 사전

d.     설계상의 데이터 플로우 및 컨트롤 플로우

e.      리소스 제약, 각각의 리소스와 그들의 제약을 관리하는 전략, 한계, 그 한계를 측정하는 방법, 예를 들면 타이밍과 메모리

f.       Time-rigid sequencing, 선점형 스케쥴링, Ada rendezvous 그리고 인터럽트를 포함하는 스케쥴링 절차와 프로세서 상호간/태스크 상호간의 통신 메커니즘

g.     설계 방법과 구현에 대한 상세한 내용, 예를 들면 소프트웨어 로딩, 사용자 수정가능 소프트웨어 혹은 다중 버전 비유사성 소프트웨어

h.     파티션 방법과 파티션 침범 방지 방법

i.       소프트웨어 컴포넌트에 대한 설명, 그것들이 새로 개발되는지 혹은 이전에 개발된 것인지, 만약 이전에 개발된 것이라면 어느 시점의 베이스라인을 참조하는지

j.       소프트웨어 설계 프로세스로부터 나온 파생 요구사항

k.      만약 시스템이 비활성화된 코드를 포함한다면 그 코드가 타겟 컴퓨터에서 활성화되지 않을 것을 보장하기 위한 방법을 설명

l.       안전성과 관련된 시스템 요구사항으로 추적가능한 설계 결정사항에 대한 이유

 

참고) 다음으로 나오는 것이 소스코드(Source Code)와 실행가능 오브젝트 코드(Executable Object Code)이다. 두 가지 모두 DO-178이라고 해서 특별히 다를 것이 없어서 따로 설명하지 않고 생략한다.