9. DO-178과 소프트웨어 라이프 사이클 (Section 3.0)

소프트웨어 생명주기라고도 하는 소프트웨어 라이프 사이클(Software Life Cycle)이라는 용어를 들으면 필자는 항상 아래와 같은 V모델을 떠올리게 된다. 물론 폭포수 모델, 나선형 모델 등 다른 모델도 있지만 DO-178 인증을 이야기하기에는 가장 무난한 형태라서 그런 것이 아닌가 싶다.

 

그림 18 V모델

※ 출처: https://www.oss.kr/info_test/show/75437834-08e1-4023-8197-6f673075ad43

 

사실 DO-178 가이드라인 어디에도 V모델을 직접적으로 언급하는 부분은 없다. 실제로도 DO-178에서 이야기하는 소프트웨어 라이프 사이클은 V모델을 설명하는 것이 아니다. 혹시라도 DO-178은 무조건 V모델이 기준이라고 생각하시는 분이 있으시다면 가이드라인에서는 개발 모델을 특정하지 않는다는 것을 기억하자. 그 말은 어떤 모델이든 DO-178 인증을 받는 데에는 전혀 문제가 없다는 뜻이다.

 

그렇다면 DO-178에서 말하는 소프트웨어 라이프 사이클은 무엇일까? 가이드라인에서는 아래와 같이 구분해서 설명하고 있다.

 

-       소프트웨어 라이프 사이클 프로세스의 구분 (Section 3.1)

-       소프트웨어 라이프 사이클의 정의 (Section 3.2)

-       프로세스간의 전이 기준 (Section 3.3)

 

각각에 대해서 DO-178 가이드라인의 설명을 기준으로 확인해 보자.

 

(1)    소프트웨어 라이프 사이클 프로세스의 구분 (Section 3.1)

 

DO-178 가이드라인에서는 소프트웨어 라이프 사이클을 다음과 같은 세 가지 프로세스로 구분하고 있다.

 

-       소프트웨어 계획 프로세스(Software Planning Process)

-       소프트웨어 개발 프로세스(Software Development Process)

-       필수 프로세스(Integral Process)

 

앞서 보았던 V모델과는 사뭇 다른 느낌이지만 결과적으로 V모델에서 보았던 프로세스들이 모두 포함된 개념이라는 점에서 단순히 표현의 차이로 보아도 무방하다. 이후 설명에서 확인할 수 있을 것이다. 중요한 것은 DO-178에서 각각의 프로세스를 어떤 관점으로 보고 무엇을 중심으로 이야기하는지를 알아야 인증을 받기 위한 정확한 준비와 실행이 가능하다는 점에서 가이드라인의 설명 혹은 의도를 정확하게 이해하는 것이 중요하다.

 

①    소프트웨어 계획 프로세스(Software Planning Process)

 

소프트웨어 계획 프로세스에 대해서 가이드라인에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

a. 소프트웨어 계획 프로세스는 프로젝트에 대한 소프트웨어 개발과 필수 프로세스의 활동을 정의하고 조정한다. Section 4에서 소프트웨어 계획 프로세스를 설명한다.

 

간단한 문장이고 우리가 잘 알고 있는 내용이다. 이런 정도로 이해하고 넘어갈 수 도 있지만 이 한 문장 속에 담겨있는 몇 가지 의미를 이해할 필요가 있다. Section 4에서 좀 더 이야기가 되겠지만 간단하게 정리하면 다음과 같다.

 

-       계획 프로세스는 개발 및 필수 프로세스가 대상이다

-       계획에서 정의된 활동은 반드시 수행되어야 한다

-       계획에서 정의된 활동은 조정할 수 있으며 조정된 결과는 계획에 정의되어야 한다

 

처음 접하는 분들에게는 이 말이나 저 말이나 결국은 똑같은 말로 들리겠지만 실제로 인증 과정을 거치면서 각 프로세스를 경험해 보면 위의 설명이 무엇을 말하는 것인지 이해가 될 것이다. 일단 계획 프로세스에 대해서는 이 정도로 하고 넘어가자.

 

②    소프트웨어 개발 프로세스(Software Development Process)

 

소프트웨어 개발 프로세스에 대해서 가이드라인에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

b. 소프트웨어 제품을 생산하는 소프트웨어 개발 프로세스. 이들 프로세스로는 소프트웨어 요구사항 프로세스, 소프트웨어 설계 프로세스, 소프트웨어 코딩 프로세스 그리고 통합 프로세스가 있다. Section 5에서 소프트웨어 개발 프로세스를 설명한다.

 

앞서 V모델에서 보았던 항목들이 모두 나오고 있다. 우선 이것으로 DO-178 가이드라인이 V모델을 커버할 수 있다는 것을 알 수 있다. 자세한 내용은 Section 5에서 설명한다.

 

소프트웨어 개발 프로세스에 대해서 마무리하기 전에 추가로 기억할 점은 소프트웨어 개발 프로세스가 “소프트웨어 계획 프로세스에서 정의된” 활동들(Activities)을 수행하는 프로세스라는 점이다. 이는 계획 프로세스에서 정의되지 않은 활동은 수행하지 않는다는 의미이자 반대로 개발 프로세스에서 수행하는 활동은 반드시 계획 프로세스에 정의되어 있어야 한다는 것을 의미한다.

 

③    필수 프로세스(Integral Process)

 

필수 프로세스에 대해서 가이드라인에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

c. 소프트웨어 라이프 사이클 프로세스와 출력에 대한 정확성과 컨트롤 그리고 신뢰를 보장하는 필수 프로세스. 필수 프로세스에는 소프트웨어 검증 프로세스, 소프트웨어 형상 관리 프로세스, 소프트웨어 품질 보증 프로세스 그리고 인증 교섭 프로세스가 있다. 전체 프로세스는 소프트웨어 라이프 사이클 전반에 걸쳐서 소프트웨어 계획과 개발 프로세스와 함께 수행된다는 것을 이해하는 것이 중요하다.

 

위의 설명에서 필수 프로세스에 포함되는 것으로 나오는 프로세스들을 다시 한 번 정리해 보자.

 

-       소프트웨어 검증 프로세스

-       소프트웨어 형상 관리 프로세스

-       소프트웨어 품질 보증 프로세스

-       인증 교섭 프로세스

 

인증 교섭 프로세스를 제외하고는 친숙한 이름일 것이다. 그리고 소프트웨어 개발에서는 반드시 포함되어야 하는 프로세스라는 것도 이해할 수 있을 것이다. 인증 교섭 프로세스에 대해서는 추후 관련 절에서 자세히 설명하겠지만 DO-178 인증의 관점에서 특별하게 요구되는 필수 프로세스라고 이해하면 된다.

 

위의 설명을 이해하는데 도움이 될 수 있는 그림이 있다. 아래는 필자가 번역한 DO-178 인증지침서에 나오는 그림이다.

 

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

※ 출처: Avionics Certification: A Complete Guide to DO-178 (software), DO-254 (hardware) / Vance Hilderman, Tony Baghi

 

비록 “3. Correctness Process”가 다르긴 하지만 위의 그림은 지금까지 설명한 소프트웨어 라이프 사이클에서의 계획/개발/필수 프로세스의 관계를 보여주는 그림이다. 앞으로 각각의 프로세스에 대한 상세한 설명이 이어지는데 내용이 방대하고 복잡해서 자칫 전체적인 그림을 놓치게 되는 경우가 있을 수 있다. 그럴 때마다 전체적인 구성을 보여주는 위의 그림을 기억하도록 하자.

 

(2)    소프트웨어 라이프 사이클의 정의 (Section 3.2)

 

DO-178 가이드라인에서는 소프트웨어 라이프 사이클에 대한 설명을 위해 다음과 같은 독특한 그림을 사용하고 있다.

 

 

위의 그림은 앞서 설명한 계획/개발/전체 프로세스 중에서 특히 개발 프로세스에 대한 부분을 설명하고 있다. 전체적인 흐름을 설명하면 다음과 같다.

 

가장 먼저 시스템 요구사항으로부터 소프트웨어 각각의 기능이 할당된다. 이어서 각각의 할당된 기능은 컴포넌트(Component) W, X, Y, Z로 구분되어 각각 개발된다. 이때 각각의 컴포넌트는 저마다의 특성을 가질 수 있는데 일단 아래와 같은 특성을 가지고 있다고 가정한다.

 

-       컴포넌트 W: 시스템 요구사항의 한 세트를 구현, R-D-C-I 개발 사이클 적용

-       컴포넌트 X: 이전에 개발된 소프트웨어를 사용, R-I 개발 사이클 적용

-       컴포넌트 Y: 요구사항으로부터 바로 코딩 가능, R-C-I 개발 사이클 적용

-       컴포넌트 Z: 프로토타입 전략 사용, R-C-I-C-I-R-D-C-I와 같이 반복적인 개발 사이클 적용

 

컴포넌트마다 서로 다른 개발 사이클이 적용되기 때문에 개발이 완료되어 통합되는 시점이 저마다 다를 수 있다. 이를 반영하여 전체적인 통합이 이루어지면 최종적으로 소프트웨어 제품(Software Product)이 만들어 지는 것이다.

 

어쩌면 가장 현실적인 개발 현장의 흐름을 보여주는 그림이라고 할 수 있다. 즉, 다양한 소프트웨어 라이프 사이클로 구현된 부분들이 서로 합쳐져서 시스템에서 할당한 기능을 수행하는 최종 소프트웨어를 만들어 내는 것이다. 그리고 DO-178 가이드라인은 그것을 가이드하는 문서라고 할 수 있다. 참고로 여기에서 설명하고 있는 내용은 DO-178 가이드라인이 이론적인 내용만 담고 있는 것이 아니라 현실적인 면을 반영하고 있는 문서라는 것을 부분적으로나마 보여주는 부분이다.

 

(3)    프로세스간의 전이 기준 (Section 3.3)

 

DO-178 가이드라인에서는 프로세스간의 ‘전이 기준(Transition Criteria)’에 대해서 다음과 같이 정의하고 있다. 참고로 아래의 정의는 Section 3.3이 아닌 가이드라인 맨 뒤의 부록에 있다.

 

해석을 보자.

 

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

 

조금 성격이 다르기는 하지만 결국은 우리가 흔히 사용하는 PDR, CDR에서의 진입/진출 기준(조건)과 유사하다고 볼 수 있다.

 

DO-178 가이드라인에서는 전이 기준으로 사용할 수 있는 것에 대해서 아래와 같은 예를 들고 있다.

 

-       소프트웨어 검증 프로세스 리뷰가 수행되었음

-       입력에 대한 형상구분이 완료됨

-       입력에 대한 추적성 분석이 완료됨

 

여기서 실제로 전이 기준으로 작성했던 사례를 살펴보자. 아래가 그 예시이다.

 

해석을 보자.

 

6.1.3 전이 기준   요구사항 분석 프로세스로 진행하기 전에 만족해야만 하는 전이 기준은 계획 리뷰 체크리스트로 설명된다.

 

요구사항 분석 프로세스로 넘어가기 위한 전이 기준이 바로 계획 리뷰 체크리스트라는 설명이다. 사실 필자가 참여했던 인증 과제에서는 위의 내용보다 훨씬 더 복잡하게 작성했었는데 어차피 가이드라인에서 작성 내용이나 분량을 특정하는 것은 아니기 때문에 위와 같은 비교적 간단한 문장도 실제 진해되는 내용을 작성한 것이라면 전혀 문제가 되지 않는다.

 

여기서 한 가지 기억할 점은 전이 기준은 반드시 소프트웨어 계획 프로세스(Planning Process)에서 결정되어야 한다는 것이다. 소프트웨어 개발 프로세스(Development Process)에서는 계획 프로세스에서 결정된 전이 기준에 따라서 다음 프로세스로 들어갈 지를 결정하게 된다. 전이 기준에 대해서는 DO-178 인증문서를 작성하는 방법에 대한 설명에서 좀 더 상세한 설명이 이어진다.