32. 이전에 개발된 소프트웨어(Previously Developed Software)의 사용 (Section 12.1)
우선 여기에서 말하는 ‘이전에 개발된 소프트웨어’라는 것은 기본적으로 DO-178 인증을 받은 소프트웨어를 말한다. 즉, 이미 개발이 완료되었고 DO-178 인증을 받은 상태로 항공기에 탑재되어 실행된 소프트웨어인 것이다. 이런 소프트웨어를 다시 사용한다고 하면 이미 이전에 승인을 받았으므로 최소한 이 소프트웨어에 해당하는 부분에 대해서는 인증을 생략할 수 있겠구나라고 흔히 생각하기 쉽다. 하지만 이것은 완전히 잘못된 판단이다.
기본적으로 DO-178 인증을 받는다는 것은 특정 비행기의 특정 소프트웨어로 한정되는 것이다. 여기서 비행기든, 소프트웨어든 단 하나라도 변경이 있게 되면 그 이후부터는 이전에 받았던 DO-178 인증은 아무런 효력을 가질 수 없다. 단도직입적으로 새로 인증을 받아야 한다.
다만 그래도 다행(?)스러운 것은 이전에 인증을 받은 데이터와 노하우를 최대한 활용할 수 있다는 점이다. 필자가 실제 경험이 없긴 하지만 예상하기로는 상당 부분의 데이터를 그대로 사용할 수 있을 가능성이 높다. 그것만으로도 상당한 리소스와 비용을 줄여줄 수 있게 된다.
이런 배경을 이해하고 접근을 한다면 결국 변경되는 부분이 어디이고 어느 정도인지가 중요하게 된다. DO-178 가이드라인에서는 이전에 개발된 소프트웨어의 사용과 관련된 이슈에 대해서 다음과 같이 구분해서 설명하고 있다.
- 이전에 개발된 소프트웨어가 수정되는 경우
- 새로운 항공기에 사용되는 경우
- 개발 환경이 변경되는 경우
- 개발기준(Development Baseline)을 업그레이드 해야 하는 경우
- 소프트웨어 형상관리에 대한 고려사항
- 소프트웨어 품질보증에 대한 고려사항
이미 인증을 받은 소프트웨어를 재사용하는 것에 대해서 이렇게까지 신경 써야 하는가 싶지만 그 만큼 항공기의 안전성이 민감하고 중요하다는 방증이므로 어쩔 수 없는 부분이다.
이제 각각의 이슈별로 가이드라인의 지침을 확인해 보자.
(1) 이전에 개발된 소프트웨어가 수정되는 경우 (Section 12.1.1)
앞서 설명한 것처럼 여기서 말하는 ‘이전에 개발된 소프트웨어’는 이전의 소프트웨어 라이프 사이클 프로세스를 통해 만들어진 결과물이 DO-178 가이드라인의 지침을 잘 준수하는 소프트웨어를 말한다. 이러한 소프트웨어의 변경은 요구사항이 바뀌거나 에러가 발견되거나 혹은 소프트웨어가 개선되면서 발생할 수 있다. 이러한 경우 다음과 같은 활동이 수행되어야 한다.
a. 시스템 안전성 평가 프로세스의 수정된 출력이 제안된 수정을 고려해서 리뷰되어야 함
b. 소프트웨어 레벨이 변경되면 DO-178 가이드라인 Section 12.1.4를 고려해야 함
c. 다른 요구사항에 대한 소프트웨어 요구사항 변경의 결과와 수정된 영역 이상으로 재검증의 노력을 가져올 수 있는 여러 소프트웨어 컴포넌트간의 커플링을 포함해서 소프트웨어 요구사항 변경의 충격과 소프트웨어 아키텍처 변경의 충격이 모두 분석되어야 함
d. 변경에 의해서 영향을 받는 영역이 결정되어야 함. 이는 데이터 플로우 분석, 컨트롤 플로운 분석, 타이밍 분석, 추적성 분석 혹은 이들 분석의 조합에 의해서 수행될 수 있음
e. 변경에 의해서 영향을 받는 영역이 DO-178 가이드라인 Section 6과 일치하는지가 재검증되어야 함
결국 변경되는 부분이 어디인지를 명확하게 정의하고 그에 따른 영향이 미치는 모든 부분을 체크해야 한다는 말이다. 변경의 범위와 난이도가 관건이지만 자칫 기존 개발과정에서 수행했던 주요 활동 전체가 새로 수행되어야 할 수도 있다. (물론 앞서 설명한 것처럼 그럴 가능성 보다는 상당부분을 재사용할 수 있을 가능성이 더 높을 것이다)
(2) 새로운 항공기에 사용되는 경우 (Section 12.1.2)
여기에서 새로운 항공기에 사용된다는 것은 기존에 ‘승인된(Approved)’ 소프트웨어에 대해서 앞에서 설명했던 형태의 어떠한 변경도 없는 상태를 기준으로 하는 것이다. 이를 기준으로 다음과 같은 활동이 수행되어야 한다.
a. 시스템 안전성 평가 프로세스의 수정된 출력이 제안된 수정을 고려해서 리뷰되어야 함
b. 만약 소프트웨어에 대한 변경이 필요하다면 DO-178 가이드라인 Section 12.1.1을 만족해야 함
c. 이전의 개발 활동 결과물이 새로운 항공기의 시스템 안전성 목표를 만족하지 못하는 경우 DO-178 가이드라인 Section 12.1.4를 만족해야 함
(3) 개발 환경이 변경되는 경우 (Section 12.1.3)
동일한 소프트웨어를 사용하지만 대신 개발 환경이 변경되는 경우가 있을 수 있다. 여기에는 툴의 변경이 있을 수 있고 타겟 프로세서나 다른 하드웨어가 변경될 수가 있다. 때로는 관련된 다른 소프트웨어가 변경되는 경우가 생길 수도 있다. 결국 주변 환경이 달라지는 것인데 이런 경우에도 기존 소프트웨어는 영향을 받게 되므로 다음과 같은 활동이 수행되어야 한다.
a. 새로운 툴이 사용되는 경우 DO-178 가이드라인 Section 12.2를 적용하는 것을 검토
b. 소프트웨어 프로그래밍 언어의 복잡도와 정교함으로 고려해야 함. 예를 들면 Ada 혹은 객체지향 언어의 문법적인 차이점으로 인해서 더 강화된 엄격함으로 확인되어야 할 수도 있음
c. 자동 코드 생성기(Autocode Generator)를 사용하는 경우 코드 생성기 자체가 다르거나 옵션이 달라지는 경우 만들어지는 코드가 달라질 수 있으므로 그에 대한 검토가 반드시 수행되어야 함
d. 컴파일러가 다른 경우 혹은 컴파일러 옵션이 다른 경우에는 동일한 소스코드를 사용하더라도 컴파일된 오브젝트 코드가 달라질 수 있기 때문에 이전에 수행된 검증활동이 모두 무효가 될 수 있음. 따라서 구조적 커버리지 분석을 포함해서 모든 검증활동이 다시 수행되어야 함. 물론 여기서 무조건 전체 검증활동이 다시 수행되는 것은 아니며 변경 범위를 고려한 적절한 재검증 방법을 적용하게 됨
e. 프로세서가 변경되는 경우에는 변경 충격 분석(Change Impact Analysis)을 수행해서 다음과 같은 사항을 확인
1. 변경되거나 새로 만들어져야 하는 소프트웨어 컴포넌트를 결정
2. 하드웨어/소프트웨어 인터페이스에 대한 이전의 검증 활동 중 다시 수행해야 할 항목을 결정
3. 이전의 하드웨어/소프트웨어 통합 시험 중 다시 수행해야 할 항목을 결정. 최소한의 범위로 수행할 것으로 예상됨
4. 추가적으로 진행해야 할 하드웨어/소프트웨어 통합 시험 및 리뷰를 결정
f. 프로세스 이외의 하드웨어가 변경되는 경우에는 변경 충격 분석을 수행해서 다음과 같은 사항을 확인
1. 변경되거나 새로 만들어져야 하는 소프트웨어 모듈 혹은 인터페이스를 결정
2. 재검증이 필요한 범위를 결정
g. 소프트웨어 인터페이스에서 이전과 다른 변경이 있을 경우 변경 충격 분석을 수행해서 재검증이 필요한지를 확인
정리된 내용들을 보면 평소에는 잘 생각하지 못하는 소프트웨어와 관련된 많은 것들이 확인 대상이 된다는 것을 알 수 있다.
(4) 개발기준(Development Baseline)을 업그레이드 해야 하는 경우 (Section 12.1.4)
여기에서 ‘개발기준(Development Baseline)’을 업그레이드 한다는 것이 무슨 뜻일까? DO-178 가이드라인에서는 이에 대해서 다음과 같이 설명하고 있다.
해석을 보자.
|
이전 어플리케이션으로부터의 소프트웨어 라이프 사이클 데이터가 새로운 어플리케이션과 관련된 요구사항들 때문에 적절하지 않은 것으로 결정되거나 이 문서(참고: DO-178 가이드라인)의 목표를 만족하지 않는 소프트웨어에 대해서 지침이 따른다. 이 지침은 다음과 같은 것에 적용될 때 이 문서의 목표를 만족하는 것을 지원하기 위한 의도이다.
l COTS 소프트웨어 l 다른 지침에 따라서 개발된 항공기 소프트웨어 l 이 문서가 존재하기 전에 개발된 항공기 소프트웨어 l 더 낮은 소프트웨어 레벨로 이 문서에 따라서 이전에 개발된 소프트웨어
|
설명 자체는 좀 복잡해서 이해가 어려울 수 있는데 사례로 제시된 항목들을 보면 여기서 설명하는 ‘개발기준’이 무엇인지 조금 더 쉽게 이해할 수 있다. 위에서 제시된 사례들의 공통점은 지금 현재 설명하고 있는 DO-178 가이드라인 문서를 그대로 따르지 않았다는 점이다. 여기에는 비록 이 문서를 그대로 따라서 진행했다고 하더라도 소프트웨어 레벨이 더 낮은 경우도 포함된다. 정리하자면 개발기준은 개발하고자 하는 소프트웨어에 대해서 지금 현재 설명되고 있는 DO-178 가이드라인에 따라서 결정되는 인증을 받기 위한 기준이라고 할 수 있다.
이러한 개발기준이 변경되는 경우에는 개발기준을 업그레이드하기 위해 다음과 같은 활동을 수행해야 한다.
a. 새로운 어플리케이션의 목표를 만족하는 것에 대해서 이전 개발에서 만들어진 소프트웨어 라이프 사이클 데이터를 이용하는 동안에 DO-178 가이드라인의 목표를 만족해야 함
b. 인증에 대한 소프트웨어 특성이 시스템 안전성 평가 프로세스에 의한 결정에 따른 실패 조건과 소프트웨어 레벨에 기반해야 함. 이전 어플리케이션의 실패 조건에 대한 비교는 업그레이드가 필요한 영역을 결정하게 됨
c. 이전 개발로부터의 소프트웨어 라이프 사이클 데이터는 필요한 레벨만큼의 엄격함과 독립성으로 새로운 어플리케이션에 대해서 해당 소프트웨어 레벨의 소프트웨어 검증 프로세스 목표를 만족한다는 것을 보장하기 위해 평가되어야 함
d. DO-178 가이드라인의 목표를 만족하는데 있어서 적절하지 않거나 누락되는 소프트웨어 라이프 사이클 데이터를 재생성하기 위해 리버스 엔지니어링(Reverse Engineering)이 사용될 수도 있음. 소프트웨어 제품을 생산하는 것에 더해서 소프트웨어 검증 프로세스 목표를 만족하기 위해 추가적인 활동이 수행될 필요가 있을 수 있음
e. 개발기준을 업그레이드하면서 DO-178 가이드라인의 목표를 만족하기 위해 제품 서비스 히스토리(Product Service History)의 사용이 계획된다면 DO-178 가이드라인 Section 12.3.4가 고려되어야 함
f. 지원자는 PSAC에 DO-178 가이드라인에 대한 준수를 달성하기 위한 전략을 명시해야 함
다시 한 번 강조하자면 여기서의 핵심은 소프트웨어가 아니라 이미 이전에 개발된 소프트웨어에서 생성된 소프트웨어 라이프 사이클 데이터이다. 이런 관점을 유의하면서 위의 설명을 간단하게 정리하자면 이미 생성되어 있는 소프트웨어 라이프 사이클 데이터를 재사용하기 전에 DO-178 가이드라인을 만족하는지 다시 한 번 확인해 보라는 것이다. 물론 그 과정에서 부족한 점이 있다면 그때는 소프트웨어 수정과 같은 전혀 다른 형태의 새로운 활동이 필요할 수도 있게 된다.
(5) 소프트웨어 형상관리에 대한 고려사항 (Section 12.1.5)
기본적으로 소프트웨어 형상관리에 대한 부분은 DO-178 가이드라인 Section 7을 따라야 한다. 여기에 더해서 새로운 어플리케이션에 대해서 다음과 같은 형상관리 활동이 포함된다.
a. 이전 어플리케이션의 소프트웨어 제품과 소프트웨어 라이프 사이클 데이터로부터 새로운 어플리케이션으로의 추적성 제공
b. 문제점 리포트, 문제점 해결, 그리고 하나 이상의 어플리케이션에 사용된 소프트웨어 컴포넌트로의 변경에 대한 추적성을 가능하게 하는 변경 추적을 제공
DO-178 인증에서 형상관리의 핵심이라고 할 수 있는 추적성은 당연히 이전에 개발된 소프트웨어와도 연계되어야 한다. 그래야 이전에 개발된 소프트웨어로부터 어떤 부분이 어떻게 변경되었는지를 정확하게 확인할 수 있다. 그리고 새롭게 변경되는 부분 역시 완벽한 추적성으로 연결되어야 한다.
(6) 소프트웨어 품질보증에 대한 고려사항 (Section 12.1.6)
이전에 개발된 소프트웨어가 사용되는 경우 소프트웨어 품질보증 역시 기본적으로 DO-178 가이드라인 Section 8을 따라야 한다. 여기에 더해서 다음과 같은 품질보증 활동이 포함된다.
a. 소프트웨어 컴포넌트가 새로운 어플리케이션에 대한 소프트웨어 레벨의 소프트웨어 라이프 사이클 기준을 만족하거나 초과한다는 것에 대한 보장을 제공
b. 소프트웨어 라이프 사이클 프로세스에 대한 변경이 소프트웨어 계획에 작성되어 있다는 보장을 제공
품질보증에 있어서 소프트웨어 레벨은 상당히 중요하다. 특히 이전에 개발된 소프트웨어의 레벨보다 더 높은 레벨로 적용하게 되는 경우에는 당연히 이전에 수행했던 품질보증 활동보다 더 엄격한 활동이 수행되어야 한다.