11. DO-178과 소프트웨어 개발 프로세스 (Section 5.0)

그림 20 DO-178 인증 지침서에서 보는 세 가지 핵심 프로세스와 관계

앞서 위와 같은 그림을 본 기억이 있을 것이다. 소프트웨어 계획 프로세스(Planning Process)에 이어지는 단계는 소프트웨어 개발 프로세스(Development Process)라는 것을 보여주고 있다. 우리는 앞에서 소프트웨어 라이프 사이클 전반에 대한 계획이 소프트웨어 계획 프로세스를 통해서 여러 가지 계획 및 표준 문서로 작성되며 그것을 바탕으로 개발이 진행된다는 것을 확인한 바가 있다. 위의 그림에서 화살표는 그런 점을 함축적으로 보여주는 부분이다.

 

사실 위의 그림에서는 개발 프로세스라는 용어로 단순화 시켜서 크게 구분했지만 실제 그 내부적으로는 아래와 같이 여러 프로세스를 가지고 있다.

 

위의 구분을 보면 우리가 일반적으로 알고 있는 각각의 개발단계들이 모두 포함되어 있는 것을 확인할 수 있다. 이번 절에서는 위의 점선으로 표시된 각각의 프로세스들에 대한 설명을 통해서 소프트웨어 개발 프로세스 전반에 대한 내용을 확인하게 된다. 특히 각각의 프로세스가 가지는 목표(Objective)와 활동(Activity)이 무엇인지를 확인하는 것이 주가 될 것이다.

 

참고로 소프트웨어 개발 프로세스 역시 DO-178 가이드라인의 부속물(Annex) A의 관련된 테이블에 목표(Objective)/활동(Activity)/출력(Output)이 아래와 같이 정리되어 있다.

 

 

본격적인 설명에 앞서서 DO-178 가이드라인에서 소프트웨어 개발 프로세스 전반에 대해 설명하기위해 사용한 다음 용어들을 이해할 필요가 있다.

 

다들 요구사항(Requirement)에 대해서는 잘 알고 있을 것이다. 그런데 이 요구사항을 DO-178 가이드라인에서는 위와 같이 몇 가지로 구분해서 사용하고 있다. DO-178 관점에서는 각각의 용어들이 분명하게 구분되는 것들이어서 앞으로 나올 설명들을 제대로 이해하기 위해서는 그러한 부분을 정확하게 이해해야 한다. 해석을 보자.

 

소프트웨어 요구사항 – 주어진 입력과 제약에서 소프트웨어에 의해서 만들어 져야 하는 것에 대한 기술. 소프트웨어 요구사항은 상위레벨 요구사항과 하위레벨 요구사항 모두를 포함한다. 상위레벨 요구사항 – 시스템 요구사항의 분석, 안전 관련 요구사항 그리고 시스템 아키텍처의 분석을 통해서 개발된 소프트웨어 요구사항. 하위레벨 요구사항 – 더 이상의 정보없이 소스코드를 직접적으로 구현할 수 있도록 하는 상위레벨 요구사항, 파생 요구사항 그리고 설계 제약으로부터 개발된 소프트웨어 요구사항. 파생 요구사항 – (a) 상위레벨 요구사항으로 직접적으로 추적할 수 없는, 그리고/혹은 (b) 시스템 요구사항 혹은 상위레벨 소프트웨어 요구사항에 의해서 구체화되지 않는 행위를 상세화하는 소프트웨어 개발 프로세스에 의해서 만들어진 요구사항

 

필자의 과거 경험으로는 요구사항을 위와 같은 형태로 나누는 경우는 잘 없었던 것으로 기억된다. 대부분의 경우 소프트웨어에 대한 요구사항은 모두 하나의 요구사항 문서로 만들어서 정리하는 것이고 거기에 연결된 설계문서가 만들어 지는 형태였다. 하지만 DO-178에서는 위와 같이 좀 복잡한 형태로 요구사항을 구분하고 있다. 사실 처음 보는 사람들에게는 위의 설명만으로는 쉽게 와닿지 않는 부분이 많을 것이다. 게다가 이와 연관된 시스템 요구사항(System Requirement)까지 포함하게 되면 더 복잡하게 느껴질 것이다.

 

일단 가장 단순화해서 정리하자면 아래와 같다.

 

-       시스템 요구사항 = 소프트웨어 요구사항 + 하드웨어 요구사항

-       소프트웨어 요구사항 = 상위레벨 요구사항 + 하위레벨 요구사항

-       상위레벨 요구사항 = 기능 요구사항 + 파생 요구사항

-       하위레벨 요구사항 = 설계 요구사항 + 파생 요구사항

-       파생 요구사항 = 상위레벨로의 추적성이 없는 요구사항

 

위에서 ‘상위레벨 요구사항’이라고 된 부분은 우리가 흔히 요구사항 문서에 작성하는 고객의 요구사항이라고 보면 된다. 그리고 ‘하위레벨 요구사항’은 소프트웨어 설계 문서에 작성하는 코드와 연관된 설명을 정리한 것과 유사한데 그것들을 요구사항의 형태로 정리한 것으로 보면 된다. 그리고 파생 요구사항은 용어자체는 DO-178에서 특화되어 있지만 결국 소프트웨어에 대한 요구사항의 하나라는 점에서 일반적인 요구사항과 크게 다르지는 않다. 다만 상위레벨로의 추적성이 없다는 차이점이 있어서 반드시 상위레벨로의 추적성을 가진 일반적인 요구사항과의 구분을 명확하게 하고 있다. 각각의 상세한 내용은 추후 관련절에서 설명하기로 하고 이제 본격적으로 소프트웨어 개발 프로세스에 포함된 내부 프로세스로 들어가 보자.

 

(1)    소프트웨어 요구사항 프로세스 (Section 5.1)

 

소프트웨어 요구사항 프로세스는 앞서 보았던 상위레벨 요구사항(High-level Requirements)을 개발하는 프로세스이다. DO-178에서는 이러한 상위레벨 요구사항에는 다음과 같은 것들이 있다고 설명한다.

 

해석을 보자.

 

소프트웨어 요구사항 프로세스는 상위레벨 요구사항을 개발하기 위해 시스템 라이프 사이클 프로세스의 출력을 사용한다. 이러한 상위레벨 요구사항은 기능, 성능, 인터페이스 그리고 안전성 관련 요구사항을 포함한다.

 

기능(Functional), 성능(Performance), 인터페이스(Interface), 그리고 안전 관련(Safety-related) 요구사항을 언급하고 있는데 이 용어들이 매우 중요한 핵심 키워드이다. 소프트웨어 요구사항 프로세스는 이러한 키워드와 관련된 상위레벨 요구사항을 개발하는 프로세스라는 점을 반드시 기억하자.

 

①     소프트웨어 요구사항 프로세스의 목표(Objectives)

 

사실 소프트웨어 요구사항 프로세스의 목표는 이미 앞에서 이야기했다. 바로 상위레벨 요구사항을 개발하는 것이다. 다만 기억해야 할 점은 이렇게 개발하는 요구사항은 반드시 시스템 요구사항이 기반이 되어야 한다는 점이다. 그 말은 시스템 요구사항으로의 추적성을 가져야 한다는 뜻이고 실제로 추적성 매트릭스 등의 형태로 추적성을 보여줄 수 있어야 한다.

 

그리고 또 하나가 시스템 요구사항으로의 추적성이 없는 파생 요구사항을 개발하는 것이다. 여기서 유의해야 할 점이 있는데 시스템 요구사항으로의 추적성이 없다고 하더라도 반드시 시스템 안전성에 대한 평가는 받아야 한다는 점이다. 좀 더 자세하게 설명하자면 일반적인 상위레벨 요구사항은 시작단계에서부터 시스템 안전성에 대한 검토를 기반으로 만들어지는 것이지만 파생요구사항은 그러한 검토가 없이 하위 단계에서 임의로 추가된 하나의 기능이므로 그로 인해 기존 시스템에 영향을 미치지 않는지를 확인하는 것이다. 안전을 최우선으로 하는 DO-178의 철학이 드러나는 부분이라고 볼 수 있다.

 

이러한 목표를 가지고 실제로 어떻게 요구사항을 개발하는지에 대해서는 다음에 나오는 소프트웨어 요구사항 프로세스의 활동(Activities)에서 자세하게 설명된다.

 

②     소프트웨어 요구사항 프로세스의 활동(Activities)

 

DO-178 가이드라인에서는 소프트웨어 요구사항 프로세스에서 상위레벨 요구사항을 개발하기 위해 아래와 같은 항목들이 입력되어야 한다고 말하고 있다.

 

-       시스템 요구사항^※

-       하드웨어 인터페이스^※

-       시스템 아키텍처^※

-       소프트웨어 개발 계획(Software Development Plan)

-       소프트웨어 요구사항 표준(Software Requirements Standards)

 

참고) ※로 표시된 항목들은 원칙적으로는 DO-178 영역, 즉 소프트웨어 라이프 사이클에 포함되는 것이 아니다. 그 보다 상위 단계라고 할 수 있는 시스템 라이프 사이클에서 나오는 결과물들이다. 이런 경우 원칙적으로는 DO-178 가이드라인에서는 그 부분에 대한 지침을 제공하지 않으며 해당되는 부분을 언급할 필요가 없는게 사실이지만 실제 소프트웨어 개발 과정에서 반드시 필요한 부분이기 때문에 가이드라인에서도 이를 명시적으로 언급하고 있는 것이다.

 

여기에 소프트웨어 요구사항 프로세스의 주요 출력(Output)은 ‘Software Requirements Data’라고 설명하고 있다. 이것이 바로 우리가 일반적으로 이야기하는 요구사항 문서이다. 참고로 출력의 이름을 ‘Software Requirements Data’라고 하고 있지만 필자는 현장에서 주로 ‘Software Requirements Document’라는 이름으로 사용하고 있다.

 

이러한 입력을 통해서 출력을 만들어 내기 위한 활동으로 DO-178 가이드라인에서는 아래와 같은 것들이 제시되고 있다.

 

a.     소프트웨어로 할당된 시스템 기능과 인터페이스 요구사항이 모호하지 않은 지, 일관성이 없는 게 아닌 지, 정의되지 않은 조건이 없는지를 분석해야 함

b.     소프트웨어 요구사항 프로세스로의 입력이 부적절하거나 혹은 정확하지 않은 경우 확인이나 수정을 위해서 이전 단계로 피드백 되어야 함

c.     소프트웨어로 할당된 각각의 시스템 요구사항이 상위레벨 요구사항으로 구체화되어야 함

d.     시스템 위험을 막기위해 소프트웨어로 할당된 시스템 요구사항을 설명하는 상위레벨 요구사항이 정의되어야 함

e.     상위레벨 요구사항이 소프트웨어 요구사항 표준(Software Requirements Standards)을 따라야 하며 검증가능하고 일관성을 가지고 있어야 함

f.      상위레벨 요구사항은 가능한 허용오차를 가지는 양적인 용어로 언급되어야 함

g.     상위레벨 요구사항은 구체적이고 정당한 설계 제약을 제외하고 설계 혹은 검증에 대한 상세한 내용을 기술하지 않아야 함

h.     파생 요구사항과 그들이 존재할 이유가 정의되어야 함

i.      파생 요구사항은 시스템 안전성 평가 프로세스를 포함해서 시스템 프로세스로 제공되어야 함

j.      파라미터 데이터 아이템(Parameter Data Items)이 사용될 계획이라면 상위레벨 요구사항은 어떤 파라미터 데이터 아이템이 소프트웨어에 의해서 어떻게 사용되는지, 그리고 그들의 구조, 데이터 요소들의 특성, 각 요소들의 값 등이 설명되어야 함

 

요구사항 하나 작성하는 데 너무 많은 것들을 이것 저것 나열해 놓은 것 같지만 오히려 DO-178에서 요구하는 수준과 작성 방향을 명확하게 제시해준다는 점에서 상당히 중요한 내용들이라고 할 수 있다. 각각의 항목을 설명하는 데에도 상당히 많은 분량이 필요하므로 여기서는 일단 이런 항목들이 있다는 정도로만 넘어가자.

 

(2)    소프트웨어 설계 프로세스 (Section 5.2)

 

소프트웨어 설계 프로세스의 핵심은 바로 소스코드를 작성할 수 있는 하위레벨 요구사항(Low-level Requirements)을 작성하는 것에 있다. DO-178 가이드라인에서는 그에 대해서 아래와 같이 설명한다.

 

해석을 보자.

 

상위레벨 요구사항은 소스코드를 구현하기 위해 사용될 수 있는 소프트웨어 아키텍처와 하위레벨 요구사항을 개발하기 위한 소프트웨어 설계 프로세스로 한 번 혹은 그 이상의 반복을 통해서 정제된다.

 

소스코드를 위한 요구사항 개발이라는 말과 함께 위의 설명 중에서 ‘정제된다’는 말에 주목할 필요가 있다. 실제로 소프트웨어 요구사항을 작성해 본 분들이라면 누구나 느끼는 것이지만 요구사항이라는 것이 그렇게 쉽게 만들어 지는 것이 아니다. 하나의 요구사항을 정의하는 데에도 많은 고려사항이 있을 수 있고 그런 것들을 검토하고 수정하면서 하나의 요구사항을 완성해 나가게 된다. 하위레벨 요구사항은 여기에 상위레벨 요구사항을 고려하고 그것을 바탕으로 소스코드가 만들어 질 수 있는 요구사항으로 작성되어야 한다. 결코 쉽지 않은 일이다. DO-178에서도 이러한 하위레벨 요구사항이 쉽게 만들어 지기 어렵다는 것을 알고 있다. 그래서 그 중간 과정에서 여러 번의 반복이 있을 수 있다는 것을 가이드라인에서도 명시적으로 전제를 하고 있는 것이다. 이 부분 역시 DO-178이 현실을 반영하는 사례라고 할 수 있다.

 

①     소프트웨어 설계 프로세스의 목표(Objectives)

 

소프트웨어 설계 프로세스의 목표는 단순하다. 상위레벨 요구사항으로부터 소프트웨어 아키텍처 그리고 하위레벨 요구사항을 개발하는 것이다. 여기에 추가로 파생 요구사항이 정의되는데 이때 상위레벨 요구사항과 마찬가지로 시스템 안전성 평가를 위해 시스템 프로세스로 전달되어야 한다. 이유는 상위레벨 요구사항에서 설명했던 것과 동일하다.

 

②     소프트웨어 설계 프로세스의 활동(Activities)

 

DO-178 가이드라인에서는 소프트웨어 설계 프로세스에 아래와 같은 항목들이 입력되어야 한다고 말하고 있다.

 

-       소프트웨어 요구사항 데이터(Software Requirements Data)

-       소프트웨어 개발 계획(Software Development Plan)

-       소프트웨어 설계 표준(Software Design Standards)

 

그리고 소프트웨어 설계 프로세스의 주요 출력(Output)은 소프트웨어 아키텍처와 하위레벨요구사항이 포함된 ‘Design Description’이라고 설명하고 있다. 이것이 바로 우리가 일반적으로 이야기하는 설계 문서라고 할 수 있다. 참고로 출력의 이름을 ‘Design Description’라고 하고 있지만 필자는 현장에서 주로 ‘Software Design Document’라는 이름으로 사용하고 있다.

 

이러한 입력을 통해서 출력을 만들어 내기 위한 활동으로 DO-178 가이드라인에서는 아래와 같은 것들이 제시되고 있다.

 

a.     소프트웨어 설계 프로세스 동안에 개발된 하위레벨 요구사항과 소프트웨어 아키텍처는 소프트웨어 설계 표준을 따라야 하며 추적 가능하고 검증 가능하며 일관성을 가지고 있어야 함

b.     파생 요구사항과 그들이 존재할 이유가 정의되고 상위레벨 요구사항이 손상되지 않는다는 것을 보장할 수 있도록 분석되어야 함

c.     소프트웨어 설계 프로세스의 특성상 파티셔닝 기법과 같은 특정한 아키텍처 방법이 적용될 수 있는데 이 경우 소프트웨어 일부의 레벨을 변경시킬 수 있기 때문에 그러한 점을 고려한 파생 요구사항 정의나 시스템 안전성 평가 등을 수행해야 함

d.     데이터 플로우(Data Flow) 및 컨트롤 플로우(Control Flow)의 형식에서 소프트웨어 컴포넌트 간의 일관성을 가지는 인터페이스가 정의되어야 함

e.     컨트롤 플로우와 데이터 플로우는 와치독 타이머, 타당성 체크 그리고 크로스 채널 비교와 같은 안전 관련 요구사항이 적용되는 시점이 모니터링될 수 있어야 함

f.      실패 조건에 대한 응답이 안전 관련 요구사항과 일관성을 가져야 함

g.     부적절하거나 혹은 정확하지 않은 입력은 시스템 라이프 사이클 프로세스, 소프트웨어 요구사항 프로세스, 혹은 소프트웨어 계획 프로세스로 피드백되어야 함

 

소프트웨어 요구사항 프로세스에서처럼 여러 가지 활동들을 요구하고 있는데 이것 역시 DO-178이 요구하는 수준과 작성 방향을 제시한다는 점에서 상당히 중요한 내용들이다. 특히 실제 소스코드의 구현과 연결되어 있는 만큼 파티셔닝과 같은 아키텍처 변경이 소프트웨어 설계 프로세스 자체에도 다양한 고려사항을 안겨줄 뿐만 아니라 그 상위레벨의 프로세스에도 영향을 미칠 수 있기 때문에 안전성과 관련된 내용이 많이 제시되고 있다. 여기서 제시되는 가이드를 명확하게 이해하고 그에 맞도록 설계 프로세스를 진행해야 한다.

 

③     소프트웨어 설계 프로세스의 추가 고려사항

 

DO-178 가이드라인에서는 소프트웨어 설계 프로세스에 대한 내용 중 특히 아래의 두 가지 항목에 대한 설계에 대해서 추가로 설명하고 있다.

 

-       사용자 수정가능 소프트웨어(User-Modifiable Software)

-       비활성화된 코드(Deactivated Code)

 

둘 다 DO-178 인증의 관점에서는 안전성에 상당한 영향을 미치는 항목들이다. 먼저 사용자 수정가능 소프트웨어에 대한 내용을 살펴보자. 참고로 사용자 수정가능 소프트웨어에 대해서는 앞 절에서 우리나라 국토교통부에서 발행한 문서에서의 정의를 살펴본 바가 있는데 DO-178 가이드라인에서도 아래와 같이 정의하고 있다.

 

해석을 보자.

 

사용자 수정가능 소프트웨어 – 만약 원래의 인증 프로젝트 동안에 만들어진 수정 제약범위 안에 있는 한 인증당국, 항공기 제조사 혹은 장비 판매자에 의한 리뷰 없는 수정을 의도한 소프트웨어

 

설명이 좀 어렵기는 하지만 결국 소프트웨어가 개발이 완료된 이후에도 사용자가 직접 수정이 가능하도록 만든 소프트웨어를 말하는 것이다. 사용자가 수정할 수 있다는 것 자체를 하나의 요구사항으로 구현한 것이라고 볼 수 있다. 실제로 이런 경우가 있을까 싶지만 가이드라인에서 아래와 같은 예시를 들고 있다.

 

해석을 보자.

 

사례에는 두 가지 장비 옵션 중 하나를 선택하기 위해 사용되는 하나의 메모리 비트, 메시지 테이블 혹은 유지보수 기능을 위해 프로그램되고, 컴파일되고, 링크될 수 있는 메모리 영역을 포함한다.

 

실제 사례에 대한 부분은 추후 기회가 되면 자세히 설명하기로 하고 일단 여기서는 이러한 경우에 어떤 부분을 유의해야 하는지 이해하는 것이 중요하다. DO-178 가이드라인에서는 아래와 같은 활동을 수행할 것을 가이드하고 있다.

 

a.     수정이 불가능한 컴포넌트(Non-modifiable Component)가 수정가능한 컴포넌트(Modifiable Component)로부터 영향(안전성 포함)을 받지 않도록 보호되어야 함. 이러한 보호는 소프트웨어, 하드웨어, 툴 중 하나 혹은 조합에 의해서 제공될 수 있음

b.     수정가능한 컴포넌트를 변경할 수 있는 방법은 유일해야 함

 

결국은 사용자가 수정하는 것 때문에 안전에 문제를 일으키면 안된다는 것이 기본적인 전제이다. 이를 위한 판단 기준과 방법을 가이드하고 있다.

 

다음으로 나오는 것이 비활성화된 코드(Deactivated Code)이다. 비활성화된 코드는 쉽게 말해서 실행되지 않는 코드인데 상대적으로 자주 비교되는 ‘죽은 코드(Dead Code)’라는 것이 아무런 의도없이 단순히 잘못 구현된 소스 코드인데 반해 비활성화된 코드는 최소한 소스 코드가 의도를 가지고 구현되었다는 차이를 가지고 있다.

 

DO-178 가이드라인에서는 비활성화된 코드에 대해서 다음과 같은 활동을 수행할 것을 가이드하고 있다.

 

a.     비활성화된 기능이 기존 기능 혹은 컴포넌트에 영향을 미치지 않는다는 점을 보장할 방법을 제시해야 함

b.     사용이 의도되지 않는 환경에서 비활성화된 코드가 수행되지 않는다는 증거가 제시되어야 함

c.     비활성화된 코드의 개발도 기존의 활성화된 코드의 개발과 동일한 수준으로 개발되어야 함

 

비활성화된 코드 역시 그것으로 인해 안전성에 영향을 미치지 않아야 한다는 것이 기준이다. 그것에 대한 객관적이고 확실한 증거가 마련되어야 한다. 참고로 DO-178 가이드라인에서는 비활성화된 코드의 예로 아래와 같은 것들을 들고 있다.

 

해석을 보자.

 

선택되지 않는 기능 혹은 사용되지 않는 라이브러리 기능 혹은 사용되지 않는 데이터와 같은 것이다. 비활성화된 코드는 죽은 코드와는 다르다.

 

구체적인 예시와 함께 죽은 코드(Dead Code)와는 다르다는 점도 분명하게 언급하고 있다.

 

(3)    소프트웨어 코딩 프로세스 (Section 5.3)

 

소프트웨어 코딩 프로세스 자체에 대해서는 많은 사람들이 잘 알고 있는 부분이지만 DO-178 관점에서 반드시 인식하고 있어야 할 부분은 바로 하위레벨 요구사항(Low-level Requirements)으로부터 소스코드가 작성된다는 사실이다. 이에 대해서는 소프트웨어 코딩 프로세스의 목표에도 분명하게 제시되고 있다.

 

①     소프트웨어 코딩 프로세스의 목표(Objectives)

 

다른 설명은 없고 위의 단 두 줄만이 적혀 있다. 그 만큼 가장 핵심이자 명확한 부분이라는 것을 알 수 있다.

 

②     소프트웨어 코딩 프로세스의 활동(Activities)

 

DO-178 가이드라인에서는 소프트웨어 코딩 프로세스에 아래와 같은 항목들이 입력되어야 한다고 말하고 있다.

 

-       하위레벨 요구사항 및 소프트웨어 아키텍처: 소프트웨어 설계 프로세스로부터 나옴

-       소프트웨어 개발 계획(Software Development Plan)

-       소프트웨어 코드 표준(Software Code Standards)

 

소프트웨어 코딩 프로세스의 출력(Output)은 당연히 소스 코드이다. 위의 입력을 통해서 출력인 소스 코드를 만들어 내기 위한 활동으로 DO-178 가이드라인에서는 아래와 같은 것들이 제시되고 있다.

 

a.     소스 코드가 하위레벨 요구사항을 구현하고 소프트웨어 아키텍처를 확인해야 함

b.     소스 코드는 소프트웨어 코드 표준을 확인해야 함

c.     부적절하거나 혹은 정확하지 않은 입력은 소프트웨어 요구사항 프로세스, 혹은 소프트웨어 설계 프로세스 그리고/혹은 소프트웨어 계획 프로세스로 피드백되어야 함

d.     자동코드 생성기의 사용은 계획 프로세스에 정의된 제약을 확인해야 함

 

하위레벨 요구사항으로부터 코드가 만들어진다는 것이 핵심이긴 하지만 위의 활동들에서 또 하나 놓치지 말아야 할 부분이 나온다. 바로 ‘소프트웨어 코드 표준’을 확인하는 부분이다. 물론 이는 소스 코드를 작성하면서 코딩룰을 준수한다는 일반적인 내용이 될 수도 있지만 DO-178에서는 이를 좀 더 구체적인 수준으로 요구하게 된다. 바로 조직내의 코딩 표준을 구체적으로 정하고 모든 프로그래머들이 그것에 따라서 소스 코드를 작성하도록 하는 것이다. 이는 코딩의 일관성을 유지하도록 함으로써 코딩 자체에서 발생할 수 있는 변수들을 최소화하고 그 만큼의 안전성을 확보할 수 있도록 하기 위한 것이다. 소프트웨어 코드 표준에 대해서는 별도의 절에서 자세한 설명을 하겠다.

 

(4)    통합 프로세스 (Section 5.4)

 

DO-178 가이드라인에서는 ‘통합’에 대해서 다음과 같이 설명하고 있다.

 

해석을 해 보면 아래와 같이 정리될 수 있다.

 

-       통합 프로세스 = 소프트웨어 통합 + 소프트웨어/하드웨어 통합

 

DO-178이 소프트웨어에 대한 인증이라고 보면 여기에서의 통합 프로세스는 시스템 차원이 아니라 소프트웨어 중심의 통합이라는 것을 이해할 수 있다. 그런 의미에서 통합 프로세스에 대해 다음과 같은 설명이 나온다.

 

해석을 보자.

 

통합 시스템 혹은 장비를 개발하기 위해 통합 프로세스에서 타겟 컴퓨터와 소프트웨어 코딩 프로세스로부터의 소스 코드가 컴파일, 링크 그리고 데이터 로딩(11.16을 보라)과 함께 사용된다.

 

위의 설명처럼 통합 프로세스에서는 타겟 컴퓨터와 소스 코드가 가장 핵심이 된다. 통합 프로세스를 통해서 소스 코드의 컴파일, 링크 그리고 로딩을 통해서 타겟 컴퓨터에 적재되는 것이다. 이는 통합 프로세스의 목표에도 잘 나와 있다.

 

①     통합 프로세스의 목표(Objectives)

 

해석을 보자.

 

a. 실행 가능 오브젝트 코드와 만약 존재한다면 그와 연관된 파라미터 데이터 아이템 파일들이 만들어지고 하드웨어/소프트웨어 통합을 위해 타겟 하드웨어로 적재된다.

 

앞서 언급되었던 타겟 컴퓨터와 소스 코드를 통해서 만들어지는 실행가능 오브젝트 코드 외에 추가로 파라미터 데이터 아이템 파일이 언급되고 있다. 이는 앞서 설명한 적이 있다. 구현되는 소프트웨어에 따라서 이것이 사용될 수도 있고 사용되지 않을 수도 있지만 만약 존재한다면 통합 프로세스에서 반드시 함께 포함되어 확인되어야 한다.

 

②     통합 프로세스의 활동(Activities)

 

통합 프로세스의 입력(Input)은 다음과 같다.

 

-       소프트웨어 아키텍처: 소프트웨어 설계 프로세스로부터 나옴

-       소스 코드: 소프트웨어 코딩 프로세스로부터 나옴

 

이러한 입력들을 통해서 다음과 같은 출력(Output)을 얻을 수 있다.

 

-       오브젝트 코드 혹은 실행가능 오브젝트 코드

-       파라미터 데이터 아이템 파일

-       컴파일, 링크, 로딩 데이터

 

DO-178 가이드라인에서는 통합 프로세스에서 수행해야 할 활동들을 아래와 같이 가이드하고 있다.

 

a.     소스 코드와 컴파일, 링크 그리고 로딩 데이터로부터 오브젝트 코드와 실행가능 오브젝트 코드를 생성함. 만약 존재한다면 파라미터 데이터 아이템 파일이 생성됨.

b.     소프트웨어 통합이 호스트 컴퓨터, 타겟 컴퓨터 에뮬레이터 혹은 타겟 컴퓨터상에서 수행되어야 함.

c.     소프트웨어는 하드웨어/소프트웨어 통합을 위해서 타겟 컴퓨터로 로드되어야 함.

d.     부적절하거나 혹은 정확하지 않은 입력은 소프트웨어 요구사항 프로세스, 혹은 소프트웨어 설계 프로세스, 소프트웨어 코딩 프로세스, 혹은 소프트웨어 계획 프로세스로 피드백되어야 함.

e.     기본적으로 요구사항, 아키텍처 혹은 소프트웨어 검증으로부터 나온 결과의 수정을 구현한 패치는 사용되지 않아야 함. 다만 컴파일러 오류와 같은 소프트웨어 개발 환경에서의 알려진 문제를 해결하는 패치와 같은 경우는 사례별로 그리고 제한된 형태로 적용할 수도 있음

f.      패치가 사용되는 경우 다음이 고려되어야 함:

1.     형상관리 프로세스가 패치를 효과적으로 추적할 수 있다는 것에 대한 확인

2.     패치된 소프트웨어가 모든 적용가능한 목표들을 만족한다는 증거를 제공하기 위한 분석

3.     패치 사용에 대한 소프트웨어 완수 요약(Software Accomplishment Summary)에서의 정당성

 

DO-178에서는 통합의 수행을 타겟/호스트/에뮬레이터 어디에서든 수행될 수 있다는 것을 가정한다. 추후 관련 절에서 좀 더 설명이 되겠지만 개발의 현실적인 상황에 맞게 진행할 수 있다는 뜻이다. 그럼에도 최종적으로는 타겟 컴퓨터로의 로드 및 수행이 필수라는 점은 반드시 기억하자.

 

그리고 패치에 대한 내용이 나오는데 이것은 결국 통합 과정에서는 소스 코드에 대한 임의의 수정을 하면 안된다는 것이다. 만약 수정이 필요하다면 그것은 결과적으로 아직 통합 프로세스를 진행할 수 없는 단계임을 말해주는 것이다.

 

(5)    소프트웨어 개발 프로세스 추적성 (Section 5.5)

 

필자가 생각하는 DO-178의 가장 중요한 항목은 요구사항(Requirements)이다. 그리고 그 다음을 꼽자면 추적성(Traceability)이 아닐까 싶다. DO-178 가이드라인에서는 소프트웨어 개발 프로세스에 대한 설명에서 이러한 추적성을 별도의 섹션으로 구분해서 추가로 설명하고 있다. 추적성에 대한 활동(Activities)에는 다음과 같은 것들이 제시되어 있다.

 

a.     소프트웨어로 할당된 시스템 요구사항과 상위레벨 요구사항 간의 양방향 관계를 보여주는 추적 데이터의 개발. 이 추적 데이터의 목적은:

1.     소프트웨어로 할당된 시스템 요구사항의 완전한 구현을 검증하게 함

2.     시스템 요구사항으로 직접 추적할 수 없는 파생 요구사항에 대한 가독성을 제공

 

b.     상위레벨 요구사항과 하위레벨 요구사항 간의 양방향 관계를 보여주는 추적 데이터의 개발. 이 추적 데이터의 목적은:

1.     상위레벨 요구사항의 완전한 구현에 대한 검증을 가능하게 함

2.     상위레벨 요구사항과 소프트웨어 설계 프로세스 동안에 만들어진 아키텍처 설계 결정사항으로 직접 추적할 수 없는 파생 하위레벨 요구사항에 대한 가독성을 제공

 

c.     하위레벨 요구사항과 소스 코드 간의 양방향 관계를 보여주는 추적 데이터의 개발. 이 추적 데이터의 목적은:

1.     소스 코드가 문서화되지 않은 기능을 구현하는지에 대한 검증을 가능하게 함

2.     하위레벨 요구사항의 완전한 구현에 대한 검증을 가능하게 함

 

추적성의 확인을 위해서는 결국 추적성 데이터(Trace Data)가 만들어 져야 한다. 필자는 이러한 추적성 데이터를 보통 ‘추적성 매트릭스’라고 부르고 있다. 이러한 추적성 매트릭스를 통해서 시스템 요구사항/상위레벨 요구사항/하위레벨 요구사항/소스 코드에 이르는 전체적인 연결을 확인할 수 있게 된다. 이는 단순한 구현 뿐만 아니라 소프트웨어 라이프 사이클 전체에 걸쳐서 모든 활동의 기준점이 될 수 있기 때문에 상당히 중요한 의미를 담고 있다. 이 부분 역시 별도의 절에서 자세히 설명된다.