23. 소프트웨어 개발 표준문서 – SRS, SDS, SCS

표준문서와 관련해서는 다른 절에서 몇 차례 설명한 바가 있다. 이러한 표준문서는 어떻게 작성하면 되는지 DO-178 가이드라인을 통해서 확인해 보자.

 

(1)    SRS(Software Requirements Standards) (Section 11.6)

 

먼저 요구사항에 대한 표준을 담고 있는 SRS에 대한 내용이다.

 

해석을 보자.

 

소프트웨어 요구사항 표준은 상위레벨 요구사항을 개발하기 위해 사용되는 방법, 룰, 그리고 툴을 정의한다.

 

사실 우리나라에서는 요구사항을 어떻게 작성해야 한다는 룰을 정한다는 것이 생소하게 느껴지는 게 사실이다. 요구사항이란 것은 그야말로 고객이 원하는 것이므로 소위 고객이 마음대로 결정하는 것이라는 인식을 가지고 있기 때문이다. 하지만 적어도 DO-178 인증의 관점에서는 그것은 ‘요구사항’이 아니다. 정확하게는 요구사항의 자격을 갖추지 못한 것이라고 할 수 있다. 따라서 고객이 마음대로 결정해서 통보하는 요구사항은 DO-178 관점의 요구사항을 작성하기 위한 참고자료가 되는 것이며 DO-178 관점에서의 요구사항은 별도의 ‘룰’에 따라서 작성되어야 한다. 여기서 그런 룰을 정리한 문서가 SRS이다.

 

SRS에 포함되어야 할 내용은 다음과 같다.

 

a.      구조적 방법(Structured Methods)과 같은 소프트웨어 요구사항을 개발하기 위해 사용되는 방법

b.     데이터 플로우 다이어그램(Data Flow Diagrams)과 공식적인 규격 언어와 같은 요구사항을 표현하는데 사용되는 표기법

c.      요구사항 개발을 위해 사용되는 툴의 사용 제약사항

d.     시스템 프로세스에 파생 요구사항을 제공하기위한 방법

 

표준과 관련된 문서에 작성되는 내용은 사실 앞서 보았던 계획문서와 달리 위의 설명과 1:1로 매칭되는 형태는 아니다. 하지만 기본적으로 작성되는 내용이 위에서 설명하는 부분을 커버할 수 있다면 그것으로 충분하며 가이드라인에서 설명된 부분과의 형식적인 일치를 고민할 필요는 없다.

 

참고) 표준 문서에 대한 지침이 다른 계획문서들처럼 DO-178 가이드라인에 각각의 섹션으로 설명되어 있기는 하지만 공식적으로는 표준문서는 감사대상이 아니다. 즉, 인증당국에 제출할 필요가 없다는 뜻이다. 그런 면에서도 표준문서의 내용이나 형식에 너무 얽매일 필요는 없다고 할 수 있다. 중요한 것은 DO-178에서 요구하는 수준으로 ‘요구사항’, ‘설계’, ‘코드’가 나올 수 있도록 적절한 표준이 마련되어 있고 언제든 그것을 보여줄 수 있게 하는 것이 중요하다.

 

(2)    SDS(Software Design Standards) (Section 11.7)

 

SDS는 설계에 대한 표준을 담고 있는 문서이다. 가이드라인에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

소프트웨어 설계 표준은 소프트웨어 아키텍처와 하위레벨 요구사항을 개발하기위해 사용되는 방법, 룰 그리고 툴을 정의한다.

 

결과적으로 소프트웨어 설계 문서를 작성하기 위해서 참고해야 할 정보들을 정의하는 것이라고 할 수 있다. 좀 더 구체적으로 아래와 같은 내용들이 포함되어야 한다.

 

a.      설계 작성 방법

b.     네이밍 규칙

c.      허용된 설계 방법상에 적용되는 조건, 예를 들면, 스케쥴링, 인터럽트와 이벤트 기반 아키텍처의 사용, 다이나믹 태스킹, 재진입, 전역 데이터, 예외 처리, 그리고 이러한 것들이 사용되는 이유

d.     디자인툴 사용에 대한 제약

e.      설계에 대한 제약, 예를 들면, 재귀호출, 다이나믹 객체, 데이터 별칭, 그리고 압축된 표현의 배제

f.       복잡도 제한, 예를 들면 중첩된 호출 혹은 조건절의 최대 레벨, 무조건적인 분기, 그리고 코드 컴포넌트의 진입/진출점의 수

 

위의 항목들을 보면 개발하는 소프트웨어의 특성이나 시스템 특성 등에 따라서 서로 다른 내용이 나올 수 있는 것들이다. 결국 다른 표준문서들과 마찬가지로 SDS 역시 다양한 형태로 작성될 수 있다.

 

(3)    SCS(Software Code Standards) (Section 11.8)

 

SCS는 코딩에 대한 표준을 담고 있는 문서이다. 가이드라인에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

소프트웨어 코드 표준은 소프트웨어를 코딩하기 위해 사용되는 프로그래밍 언어, 방법, 룰, 그리고 툴을 정의한다.

 

SCS의 핵심은 ‘코딩룰’을 정의하는 것이라고 할 수 있다. 개발자들이 코드를 작성하면서 공통적으로 따라야 할 규칙을 정함으로써 기본적으로는 통일성을 확보할 수 있고 무엇보다도 DO-178에서 추구하는 안전성을 확보하는 데 상당한 영향을 미치게 된다. DO-178 가이드라인에서는 다음의 항목들이 포함되어야 한다고 가이드하고 있다.

 

a.      사용될 프로그래밍 언어 그리고/혹은 정의된 서브셋. 프로그래밍 언어에 대해서는 구문, 데이터 동작, 그리고 언어의 사이드 이펙트를 명백하게 정의하는 데이터를 참조할 것. 이것은 언어의 특정한 특성의 사용에 제한이 필요할 수 있음

b.     라인수 제한, 들여쓰기, 그리고 공백라인 사용과 같은 소스코드를 나타내는 것에 대한 표준과 저자명, 리비전 히스토리, 입력, 출력, 영향을 받는 데이터와 같은 소스코드 문서화에 대한 표준

c.      컴포넌트, 서브프로그램, 변수 그리고 상수에 대한 네이밍 규칙

d.     소프트웨어 컴포넌트간의 커플링 정도 그리고 논리 혹은 수치 표현의 복잡도와 같은 허용된 코딩 규칙에 부과되는 조건과 제약, 그리고 그것들을 사용하는 이유

e.      코딩툴의 사용에 대한 제약

 

DO-178 가이드라인에서는 설명이 없지만 사실 SCS에 작성되는 코딩룰은 현장에서는 소프트웨어에 대한 정적 분석과 밀접한 관련이 있다. 따라서 이에 대한 구체적인 부분은 정적 분석에 대한 소프트웨어 검증 계획과 연계되어 작성되어야 하는 부분이기도 하다. 이를 포함해서 SCS 역시 다양한 형태로 작성될 수 있다.