10. 계획, 개발 그리고 정확성

 

아래 그림에서 보이는 것처럼 이제 계획, 개발 그리고 정확성의 영역으로 돌아가보자. “정확성 프로세스”가 거의 전체 영역을 어떻게 커버하고 있는지 주목하라. 그것은 검증, 형상관리, 품질보증 그리고 인증교섭이 라이프사이클 영역 전체를 커버하면서 함께 “정확성”을 구성하고 있기 때문이다.

세 가지 핵심 프로세스 계획 프로세스로 시작. 계획이 수행될 때까지 개발 진행되지 않음 개발 프로세스는 계획 프로세스가 완료된 이후에 수행 정확성 프로세스는 프로젝트 시작부터 끝날 때까지 지속적으로 수행됨

 

역주) DO-178은 일단 5개의 계획 문서(PSAC, SDP, SVP, SCMP, SQAP)와 3개의 표준 문서(SRS, SDS, SCS)를 작성해야 한다. 그 작업이 위의 1번 박스라고 보면 된다. 일단 계획이 수립되면 드디어 개발이 시작된다. 2번 박스이다. 그런데 모든 일이 그렇지만 한번에 완벽하게 되는 것은 없다. 개발을 하다 보면 계획을 수정해야 할 수도 있다. 계획이든 개발이든 수정이 이루어지고 그것을 관리하는 활동이 3번 박스이다. 결론적으로 이 3개의 박스가 반복되는 구조이다. 그래서 3번 박스가 1번과 2번을 품고 있는 것이다. 간단한 그림 같지만 위의 그림은 DO-178의 모든 과정을 함축적으로 보여주고 있는 아주 중요한 그림이다.

 

첫 번째 단계는 계획이다. 위의 그림에서 왼쪽으로 가장 멀리 있는 이유이다. 또한 가장 작은 사각형인 것을 볼 수 있는데 다른 활동들만큼 많은 시간이 필요하지 않기 때문이다. DO-178B는 계획에 대한 리뷰를 요구하는데 만약 레벨 A 혹은 B라면 독립적으로 리뷰가 진행되어야 한다. 이 프로세스는 인증계획(PSAC), 품질보증, 형상관리, 개발 그리고 검증 계획을 포함하여 5개의 계획과 3개의 표준을 포함한다. PSAC의 내용은 소프트웨어 라이프사이클에 대한 훌륭한 이해와 함께 DO-178B의 objective를 준수하는 전반적인 방법을 커버해야 한다. 당신이 DO-178B를 준수하는 라이프사이클 내에서 절차와 단계를 그대로 따른다는 것을 보장한다. PSAC이 회사의 운영 절차와 같은 다른 계획 혹은 절차를 가리키게 할 수 있을까? 가능하다. 하지만 기억해야 한다. 일단 그것들이 감사 대상이 되는 순간부터 FAA와 고객 모두로부터의 평가대상이 된다.

역주) 마지막 부분에 나온 내용에 대해서 해석이 필요할 것 같다. DO-178을 위한 5개의 계획과 3개의 표준 문서가 있다고 했는데 이 문서를 무조건 완전히 새로 만들어야 하는 것이 아니고 기존 회사에서 사용하던 문서를 참조하도록 하거나 심지어는 그대로 사용할 수 있다. (특히 형상관리 문서 같은 것들) DO-178에서 제시하는 가이드라인을 지킬 수 있다면 그 형식이나 내용은 어떤 것이든 가능하다는 말이다. 이렇게 되면 새로 만들지 않아도 되므로 일단 편하다. 그런데 이렇게 편한 반면에 앞으로 그 문서는 DER의 감사도 받게 되고 필요한 경우 FAA에 제출도 해야 하므로 이제부터는 DO-178 기준으로 관리해야 하며 필요하면 업데이트도 해야 하는 제약이 생기게 된다. 다소 복잡하기는 하지만 어쨌든 DO-178의 융통성을 보여주는 일례라고 볼 수 있다.

 

 

역주) 앞부분에서도 잠시 언급했지만 원서의 영문 표기를 최신 표기로 변경했다. 동일한 문서를 지칭하는 것이므로 혹시라도 원서를 비교하시는 분은 착오 없으시길.

 

PSAC 개요

PSAC, 즉 인증계획문서는 지원자가 소프트웨어 레벨에 필요한 정도의 엄격함에 부합하도록 소프트웨어 라이프사이클을 제시하는지를 결정하는데 있어서 인증 당국에 의해서 사용되는 주된 방법이다. 이 계획문서는 다음을 포함해야 한다.

 

시스템 개요. 이 섹션은 시스템의 기능과 하드웨어 및 소프트웨어로의 할당, 아키텍처, 사용되는 프로세서, 하드웨어/소프트웨어 인터페이스 그리고 안전성 특성을 포함한 시스템의 개요를 제공한다.

역주) 여기에 나오는 내용들은 결국 PSAC 문서에 포함되어야 할 것들에 대해서 말하고 있다. 역자도 이제서야 확인한 것이지만 DO-178 가이드라인의 내용을 그대로 가져온 부분이다. 말이 나온 김에 살짝 맛보기로 보여드리면 다음과 같다. (아래의 내용은 a. System overview를 그대로 가져왔다.) (참고 포스팅: 6. DO-178 가이드라인)   DO-178을 배우려고 하는 분들은 영문으로 작성된 가이드라인을 직접 확인해 보시기 바란다.

 

소프트웨어 개요. 이 섹션은 제시된 안전성과 파티션 컨셉에 대한 강조와 함께 소프트웨어 기능을 간략하게 작성한다. 예를 들면 리소스 공유, 중복성, 다중 버전 이종 소프트웨어, 고장 허용범위, 타이밍, 스케줄링 전략이 있다.

인증 계획(PSAC)   40페이지 이하로 유지 소프트웨어 활동에 대한 이해에 있어서 상위레벨을 개발 DO-178B objective에 대한 준수를 보여줌 상세한 계획문서를 가리키면서 특정한 내용을 언급함 특별한 고려사항을 기술함(툴인증, COTS, 서비스 히스토리 등) 탑 레벨의 스케쥴 포함

 

인증 고려사항. 이것은 소프트웨어 특성과 관련된 인증 준수 방안을 포함하는 인증 기준에 대한 요약이다. 이 섹션은 또한 제안된 소프트웨어 레벨을 언급하고 실패 조건에 소프트웨어가 잠재적으로 얼마만큼 영향을 미치는지를 포함해서 시스템 안전성 평가 프로세스에 의해서 제공되는 소프트웨어 레벨에 대한 정당성을 요약한다.

역주) 원서에 보면 ‘means of compliance’라는 말이 나온다. 처음 이 부분을 보면서는 그냥 ‘준수방법’ 정도로 해석을 했었는데 최근 감항인증에 대해서 자세히 보다 보니 감항인증 전반적으로 ‘Means of Compliance(MOC)’라고 사용되는 것을 확인할 수 있었다. 일부 번역된 책자나 문서들에는 ‘인증수단’ 혹은 ‘입증방법’ 등으로 번역이 된 경우가 있다. 중요한 것은 그냥 일반적인 설명의 일부가 아니라 감항인증에서 전문적으로 사용되는 ‘용어’라는 점이다. 혹시 관련해서 더 자세히 알고 싶은 분들은 ‘감항인증’이라는 좀 더 상위레벨에서 그 부분을 확인해 보면 좀 더 명확하게 이해할 수 있을 것이다. (참고 포스팅: 2. 감항인증에 대한 이해)

 

소프트웨어 라이프사이클. 이것은 소프트웨어 라이프사이클을 정의하고 대응하는 계획 문서에 상세한 정보가 정의되어 있는 각각의 소프트웨어 라이프사이클과 그 프로세스들에 대한 요약을 포함한다. 그 요약은 각각의 소프트웨어 라이프사이클 프로세스의 objective를 어떻게 만족할 지를 설명하며 관계되는 조직 구성, 조직의 책임, 시스템 라이프사이클 프로세스와 인증교섭 프로세스의 책임 등에 대해서 기술한다.

 

소프트웨어 라이프사이클 데이터. 이 섹션은 소프트웨어 라이프사이클 프로세스에 의해서 만들어지고 컨트롤되는 소프트웨어 라이프사이클 데이터를 기술한다. 또한 데이터 상호간의 관계, 혹은 시스템을 정의하는 다른 데이터와의 관계, 인증 당국에 제출되어야 할 소프트웨어 라이프사이클 데이터, 그 데이터의 형식 그리고 소프트웨어 라이프사이클 데이터가 인증 당국에 받아들여질 수 있도록 만드는 방법들을 기술한다.

역주) 소프트웨어 라이프사이클 데이터가 문서만 의미하는 것은 아니다. 예전에는 그냥 문서로 받아들여지면서 사용되긴 했지만 이제는 증빙이 될 수 있는 것이라면 그 어떤 것도 여기서 말하는 데이터가 된다. 예를 들면 형상관리의 이력을 보여주는 로그도 소프트웨어 라이프사이클 데이터라고 할 수 있다.

 

PSAC 내용 – 예시   목차 범위 문서 구분 문서 개요 참조 문서 적용 가능 문서 참조 문서 리비전 참조 문서 약어 제품 인증 킷 소프트웨어 개요 인증가능 제품 개요 제품명 소프트웨어 컴포넌트 사용자 정의 코드 시스템 라이브러리 타겟 시스템 사용이력

 

스케쥴. 이 섹션은 소프트웨어 라이프사이클 프로세스 활동을 인증 당국에 가시적으로 보여주기 위해서 지원자가 사용하는 방법을 기술하는 것으로 이를 통해서 리뷰가 계획될 수 있다.

 

추가적인 고려사항. 이 섹션은 인증 프로세스에 영향을 미칠 수 있는 특별한 특성을 기술하는 것으로 예들 들면 대체 준수 방법, 툴인증, 사전 개발 소프트웨어, 옵션 선택 가능 소프트웨어, 사용자 수정가능 소프트웨어, COTS 소프트웨어, 현장로딩가능 소프트웨어, 다중 버전 이종 소프트웨어 그리고 제품 사용 이력 등이 있다.

역주) 여러 가지 어려운 용어가 나오고 있다. 여기서 중요한 점은 현재 개발하는 소프트웨어가 인증을 받는데 영향을 주는 것들이 무엇인지를 파악하는 것이 중요하다는 점이다. DO-178을 진행하다 보면 추가로 고려해야 할 것들이 많다. 툴인증만 보더라도 소프트웨어를 아무리 잘 만들었다고 해도 툴인증을 받지 못한 경우에는 절대 DO-178 인증을 받을 수 없다. 이런 식의 추가적인 고려사항이 필요한 것들이 여기에 작성된다. 각각의 정의는 좀 더 자세한 설명이 필요한데 이에 대해서는 다른 기회를 통해서 정리할 예정이다. (참고 포스팅: 31. DO-178과 추가적인 고려사항(Additional Considerations) (Section 12.0))

 

PSAC 상세 – 예시   인증 가능한 제품을 추구하는 인증 보증 소프트웨어 개발 프로세스(A-2) 소프트웨어 요구사항 프로세스의 산출물을 검증(A-3) 소프트웨어 설계 프로세스의 산출물을 검증(A-4) 소프트웨어 코딩 & 통합 프로세스의 산출물을 검증(A-5) 통합 프로세스의 산출물을 시험(A-6) 검증 프로세스 결과의 검증(A-7) 인증 교섭 프로세스(A-10) 소프트웨어 개발 및 검증 툴인증 개발툴 검증툴 요약 소프트웨어 위험 레벨 위험레벨의 할당 추가적인 고려사항 향후 개발 활동 제품명 개발 툴 고려사항

 

역주) 위의 표에 나오는 내용들도 PSAC에 들어갈 수 있는 핵심 항목들이라고 보면 되는데 결국 중요한 것은 개발 과정 전체에 걸쳐서 인증을 위해 진행되는 검증과 증빙확보의 개요가 작성되어야 한다는 점이다. 대체로 위의 항목들을 고려해서 PSAC을 작성하게 되면 FAA에서 받아들일 수 있는 정도의 내용이 모두 포함되는 것으로 이해하면 된다.

 

PSAC 내에 특별한 고려사항을 반드시 작성해야 한다. 비록 사전 개발 소프트웨어를 가지고 있지 않더라도 “이 프로그램에는 해당사항 없음”이라는 문구라도 넣어라. 이렇게 함으로써 당신은 그것을 고려한 것이 되고 FAA는 “당신은 사전 개발 소프트웨어의 사용에 대해서 고려했나요?”라고 묻지 않는다. 그런 질문이 나오더라도 당신은 다음과 같이 답할 수 있다. “네, PSAC에 특별 고려사항으로 포함되어 있습니다. 저희는 사전 개발 소프트웨어를 사용하지 않으며 전체 소프트웨어를 새롭게 개발합니다. 그래서 그렇게 작성했습니다.”

역주) 여기서 저자가 강조하는 것은 어떤 섹션이 해당사항이 없는 경우 문서에서 아예 빼는 것이 아니라 섹션을 남겨두고 그냥 “해당사항 없음(역주, 영어로는 Not Applicable 혹은 N/A를 자주 사용함)”이라는 식으로 작성하라는 말이다. 아예 빼버리면 의도적으로 뺀 것인지 아니면 누락된 것인지 구분이 안된다. 하지만 “해당사항 없음”으로 적으면 최소한 그것을 이미 검토해서 결론을 내렸다는 의미가 된다. DO-178 문서를 작성할 때 주의해야 할 부분이다.

 

단지 한 줄이지만 만약 당신이 그 문구를 넣지 않으면 당신은 질문을 받게 된다. 따라서 가정하지 않게 해야 한다. 해당 섹션의 타이틀을 작성하고 거기에 “COTS는 사용되지 않음” 혹은 “사용 이력이 있음” 이라는 식으로 작성하라. 그리고 항상 최상위 레벨의 스케쥴을 가져라. 그것은 거의 항상 시간이 지나면서 변경될 것이다.

 

우리는 4년 전 완료 스케쥴로 승인된 PSAC을 본 적이 있다. 그 프로그램은 여전히 진행 중이다. 당신은 이전으로 돌아가서 PSAC을 업데이트하지 않는다. 왜냐하면 그것은 말이 안되기 때문이다. 하지만 당신이 단지 최상위 레벨의 마일스톤 7줄을 넣지 않은 것 때문에 그것이 거절되었을 수 있다.

 

PSAC은 FAA나 고객이 당신의 DO-178B 수행 능력을 보는 첫 번째 단계이므로 중요한 문서이다. 우리는 PSAC을 아무렇게나 작성하고서는 그저 피드백을 얻고 그런 다음 그것을 따르고 수정하기만 하는 회사들을 보아 왔다. 그들은 미리부터 좋은 결과를 만들어 내려고 노력하는데 시간을 소모하는 것을 원하지 않는다. 우리 모두는 첫인상이 얼마나 중요한지 알고 있다. 첫인상이 나쁘면 다른 것들에 대해서 더 엄격하게 될 것이다. 하지만 첫인상이 좋게 되면 이후부터는 세세한 것에 대한 질문을 받지 않게 될 것이다. FAA 담당자가 우리에게 이렇게 말한 적이 있다. “저 회사, 우리는 믿을 수 없습니다. 저 사람들은 문서의 반만 작성해서 가져왔는데 그렇다면 그 때부터 그 프로젝트는 나빠지고 있는 것이죠.”

역주) DO-178 인증도 결국 사람이 하는 일이다. 우리의 입장에서 보자면 외국의 인증이고 특히 처음 해보는 경우라면 잘 안 되는 것이 당연한 것인데 그런 어려움조차도 결국 사람이 하는 일이므로 당연히 합리적인 판단을 통해서 진행될 수 있다. 특히 어려움이 닥치면 비록 감사를 받는 입장과 감사를 하는 입장이라고 하더라도 서로 도와줄 수 있는 여지가 생기기 마련이다. 그런데 저자의 말처럼 첫인상이 나빠지면 그 가능성이 상당히 낮아지게 된다. 쉽게 말해서 시작부터 신뢰를 잃어버리게 되는 것이다. PSAC이 그 첫인상이라는 점을 반드시 기억하자.

 

따라서 PSAC을 좋은 상태로 시작하라. 그냥 내버려 두지 말고, 이를테면 각 단락을 설명하는 10개의 파워포인트 차트로 하나의 슬라이드를 만들어서 그것을 발표하라. 사람들은 절대 그 문서를 읽어보지 않지만 이렇게 함으로써 사람들의 관심을 가져오게 되고 모두에게 더 쉽게 다가가게 된다. 그리고 PSAC을 고객이나 FAA에 제출하기 전에 DER이 리뷰하고 승인하는지를 확인해야 한다.

역주) 나중에 다시 설명되겠지만 DER은 당신의 ‘적’이 아니다. 비록 감사를 하는 사람이지만 한편으로는 당신이 돈을 주고 고용한 ‘컨설턴트’이기도 하다. 많은 돈을 준 만큼 많이 물어보고 도움도 요청하면서 최대한 이용해야 한다. 실제로 DER의 역할 중에 그 부분이 큰 비중을 차지한다. 위의 내용은 바로 그런 면을 이야기하고 있는 것이다. (참고 포스팅: 21. DO-178과 DER(Designated Engineering Representative) – Job Aid (7))