3. 프로젝트 계획하기

 

프로젝트가 어떻게 흘러가는 지 살펴보자.

 

DO-178의 의도는 SAE standard ARP4761(Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment) 에서 시작된다. 그것은 위험 레벨 – A, B, C 혹은 D – 과 아키텍처 레벨의 입력을 결정하기 위한 안전성 평가이다. DO-178B는 시스템 레벨 요구사항과 안전성 평가(설계 보장 레벨을 포함한)를 얻을 수 있는 ARP4761이 없으면 혼란스러워질지 모른다.

역주) ARP 4761에 대해서는 9장에 아래와 같은 그림과 함께 자세하게 설명되어 있다. 이 부분의 저자의 설명은 아래 그림과 관련된 설명이다. (참고 포스팅: 29. DO-178과 System Safety (1))

 

어떤 사람들은 “DO-178B가 ‘훌륭한’ 소프트웨어 요구사항의 개발에 대해서는 말하고 있지 않는데 내가 어떻게 하느냐?”라고 말한다. 그 답은 여기 두 문서에 있다. “훌륭한” 요구사항 보다는 시스템의 비용 효과와 품질이 더욱 더 중요하다.

DO-178B 레이아웃   개요 시스템 특성 라이프사이클 계획 프로세스 ………………………………………. 계획단계 개발 프로세스 ………………………………………. 개발단계 검증 ………………………………………………………. 정확성단계 형상관리 ……………………………………………….. 정확성단계 품질보증 ……………………………………………….. 정확성단계 인증교섭 ……………………………………………….. 정확성단계 항공기 및 엔진 인증의 개요 데이터 및 고려사항 A.    인증레벨에 따른 목표치

 

사실 우리 주변에는 훌륭한 계획 문서를 가지고 있는 많은 회사들이 있다. 하지만 놀랍게도, 그들이 필연적으로 훌륭한 프로젝트를 가지는 것은 아니다. 그 이유는 그들의 계획 문서가 너무 훌륭하기 때문이다. 그 문서의 페이지 어디에도 찢어지거나 접혀진 곳이 없다. 단지 약간의 먼지만 쌓여 있을 뿐이다. 왜냐하면 그것을 책장에 보관해 두고는 사용하지 않기 때문이다. DO-178은 유죄추정의 원칙이 있다는 것을 기억하자. 프로젝트의 마지막 단계에서 우리는 훌륭한 계획 문서를 가졌다는 것을 증명하는 것뿐만 아니라 그 모든 것을 잘 따랐음을 증명해야 한다. 그리고 그것이 본질이다.

역주) 결론적으로 DO-178은 저자의 설명처럼 어렵게 문서작업을 해놓고서는 그 이후에는 펼쳐보지도 않는 그런 형식적인 인증이 아니다. 만들어 놓은 문서를 계속 펼쳐보고 필요하면 다시 수정도 하면서 인증이 완료될 때까지 계속 펼쳐봐야 하는 그런 인증이라고 이해하면 된다. 이 책 전체를 통해서 그 실체를 하나하나 소개하게 된다.

 

때때로 “DO-178B 프로젝트를 위해서 필요한 최소의 인력이 몇 명인가요?”라는 질문을 받는다. 우리는 답한다. “그것 참 재미있는 질문이군요. 그런데 왜 그런걸 묻는거죠?” “글쎄요, 제가 창업한지 얼마 안되었구요, 현재는 저 혼자만 있습니다.” “알겠습니다. 여기 답이 있습니다….”

 

당신은 안전성에 대한 전문가가 한 명 필요하다. 시스템 요구사항을 작성할 누군가가 필요하다. 소프트웨어 및 하드웨어 요구사항에 대해서도 필요하다. 형상관리 시스템을 다룰 사람, 품질보증(QA) 담당자 그리고 한 사람의 DER이 필요하다. 소프트웨어를 위한 설계전문가도 필요하다. 일단 지금은 하드웨어에 관해서는 잊어라. 당신은 소프트웨어 개발자, 소프트웨어 테스터 그리고 그 많은 사람들을 다룰 매니저도 필요하다. 그래서 당신은 11명이 필요하다. 맞나? 아니다, 그것은 정답이 아니다.

 

당신은 DER이 필요하지만 빌릴 수 있다. 중간 크기의 회사들조차도 자신들만의 DER을 직접 고용하지 않는다. 당신은 품질보증을 위한 누군가가 필요하다. 다른 9명은 어떨까? 단지 2명이 더 필요하다. 바로 ‘행위자’와 ‘리뷰어’이다. 그래서 결론적으로 DER + 3명이다. 누가 가장 중요할까? DO-178B를 시작하고 DER을 찾아낸다는 점에서 QA 담당자가 가장 중요하다고 할 수 있다. 하지만 당신에게 필요한 것은 결국 ‘행위자’와 ‘리뷰어’이다.

 

프로젝트에서 두 명의 소프트웨어 개발자와 거기에 더해서 QA와 DER을 가질 수 있는가? 그렇다. 하지만 이것은 소프트웨어 개발자가 자기가 작업한 결과를 리뷰해야 하는지 혹은 자신이 작성한 요구사항을 코드로 작성해야 하는지에 대한 질문을 낳게 된다. 그 답은 ‘아니다’이다. 시험 절차를 따르지 않고 소프트웨어 개발 절차를 따를 수 있는가? 역시나 그 답은 ‘아니다’이다.

 

DO-178B의 한가지 특징은 마치 많은 사람들이 먹이를 주면서 키워야 하는 커다란 짐승처럼 보인다는 것이지만 실제로는 그렇지 않다. 품질보증(Quality Assurance)은 매우 중요하다. QA는 우리가 그 계획을 잘 따르고 있고 DO-178B에서 이야기하는 것들을 그대로 따르고 있으며 그래서 모든 것이 우리가 제대로 진행하고 있다는 것을 증명하기 위한 감사에서 위험레벨을 만족한다는 것을 확인시켜주는 역할을 한다.

역주) 설명이 좀 중구난방이라는 느낌이 있지만 어쨌든 QA의 역할이 중요하다는 것을 강조하고 있다. 그리고 우리가 일반적으로 생각하는 QA의 역할과 뭔가 좀 다른 이야기를 하고 있다는 점을 인식해야 한다. 다른 곳에서 좀 더 자세히 관련된 이야기가 나올 것이다. (참고 포스팅: 14. DO-178과 소프트웨어 품질보증 프로세스 (Section 8.0))

 

DO-178 프로젝트는 세 개의 프로세스로 볼 수 있다. 다음 그림에서 보면 각각의 아이템이 어떤 위치에 있고 상대적인 크기가 어떤 지에 따라서 상당히 많은 의미를 담고 있다.

 

 

계획 프로세스는 모든 것에 앞선다. 그래서 다른 것들에 비해서 가장 왼쪽에 위치하고 있다. 그것은 다섯 개의 계획에 더해서 표준들을 커버한다. 그 다음 이어지는 것이 개발 프로세스이다. 하지만 배경에는 다른 어떤 것들 보다 훨씬 큰 정확성 프로세스가 있다. 시험, 품질보증, 형상관리, 인증교섭 그리고 FAA와의 조율 등을 포함한다. 가장 비용을 많이 발생시키는 요인이기도 하지만 가장 핵심적인 프로세스이기도 하다.

핵심 특성   상세한 계획 다섯 가지 위험 레벨(A, B, C, D, E) 일관성 & 결정론 상세한 요구사항으로의 추적성 수행경로 시험 “유죄추정의 법칙”

 

DO-178B는 일관성과 결정론에 대한 것이다. DO-178B에서 “D”가 “Determinism”의 “D”를 의미하는 것이라고 생각하라. 중요한 것은 정확한 원인과 결과이다. 그것이 DO-178B의 본질이다.

당신은 또한 정의된 모든 것이 완전하게 구현되었다는 것을 보여주기 위해 완전한 Top-Down 추적성이 필요하다. 그런 후에 정의된 것만 포함되었음을 보여준다는 타당한 이유로 Bottom-Up 추적성이 필요하다.

역주) 여담이지만 솔직히 번역을 하면서 원서의 서술 순서가 좀 중구난방이라는 것을 여러 번 느끼게 된다. 맘 같아서는 그런 부분까지 교정하고 싶지만 일단 원서의 순서만큼은 손을 안 대려고 한다. 여기서도 갑자기 추적성에 대한 설명이 나온다. DO-178의 주요 핵심 개념으로 나온 것 같은데 어쨌든 DO-178에서는 Top-Down 과 Bottom-Up 추적성이 모두 나와야 된다는 것을 기억하자. 이는 완전한 구현과 정확한 구현의 확인을 강조하는 부분이다.

 

상세한 계획

어떤 개발 활동이든 시작하기 전에 반드시 계획이 있어야 한다. 집을 짓는 것에 대한 아이디어를 개발한다고 상상해보자. 처음 해야 할 것 중 하나는 건축가가 간단한 스케치를 하고 그런 후에 건축 엔지니어가 청사진을 계획하고 작성하는 것이다. 이 과정에서 당신이 그저 “네 개의 욕실과 다섯 개의 침대방을 만들어 주세요.”라고만 말하면 안된다. 건축가는 당신의 라이프스타일이나 취향을 알지 못한다. 그는 다섯 개의 작은 침대방을 지하실에 위치시킬지도 모른다. 하지만 그것은 절대 당신이 상상하던 것이 아니다. 그래서 당신은 건축가에게 당신의 취향을 설명해야 하며 그제야 그 건축가는 전기, 하수, 지진 혹은 다른 기술적인 문제들을 해결하면서 제대로 만들 수 있다.

 

다음은 당신 지역의 승인 프로세스에 경험을 가지고 있는 전문 엔지니어다. 그의 리뷰를 거치고 나면 계획이 승인된다. 그것이 또한 DER의 역할이다. 앞서 잠시 나왔던, 집을 짓기 위한 계획은 이제 지역 담당자에게 제출될 수 있고 “좋습니다. 승인합니다.”라는 답을 받을 수도 있다. 만약 당신이 사전 계획 없이 짓기 시작한다면 당신은 집 짓기 자체를 실패할 것이고 혹은 아예 다 부수고 스펙에 맞게 새로 짓도록 강요받을 수도 있다.

 

소프트웨어에 대해서도 당신은 “내가 어떻게 DO-178B에 의해 제시된 의도와 룰을 만족할 수 있을까?”라는 질문으로 시작하면서 계획을 세울 필요가 있다. 요약을 하면 다음과 같다.

상세한 계획   계획은 개발에 앞서야 한다 계획에는 DO-178B의 모든 특성이 기술되어야 한다 계획을 모두 준수했다는 증거를 제공해야 한다 계획은 무엇(What), 언제(When), 그리고 누가(Who)… 그리고 아주 약간의 ‘어떻게(How)’가 기술된다 계획은 일반적으로 QA에 의해서 작성되고 받아들여지고 따르게 되며 DER에 의해서 승인받는다

 

소프트웨어 개발 계획을 고려하면서 다음과 같은 질문들을 할 수 있다. 어떤 툴들이 필요한가? 누가 그것들을 사용할 것인가? 스케쥴은 어떻게 될 것인가? 개발은 누가하고 검증은 누가하며 QA는 누가하는가? 업무 환경은 어떤가? 어떤 컴파일러를 사용하나? Windows 상에서 개발하는가 아니면 UNIX 시스템상에서 혹은 다른 베이스에서 개발하는가? 시뮬레이션 툴은 무엇인가? 디버거로는 무엇을 사용하나?

 

당신은 또한 툴, 프로세스 그리고 인력을 사용한 제품 검증을 위해서 검증 계획을 수립한다. 스케쥴과 시간 계획은 어떻게 되며 리소스 할당은 어떻게 되는가? 모든 데이터의 형상관리를 위한 형상관리 계획이 필요하다. 계획과 프로세스 기반으로 품질이 어떻게 검사될지에 대한 정의를 위해서 품질보증 계획이 있어야 한다.

 

표준은 요구사항 개발, 설계 및 코딩에 대한 일관성있는 접근을 제공한다. DO-178B는 이들 세 가지 표준을 작성할 것을 요구한다. DO-254 역시 비슷한 표준 문서들이 있고 제조과정에서의 시험과 제품 보증을 요구한다.

 

이것이 전체적인 라이프사이클에 접근하고 이들 계획을 잘 준수했음을 증명하는 전체적인 관점이다. 앞서 언급한 것처럼 계획은 무엇을 언제 하느냐가 아니라 누가 그 일을 하고 어떻게 도달하는가를 기술해야 한다.

역주) DO-178 인증에서 반드시 작성해야 하는 계획(Plan) 문서와 표준(Standard) 문서에 대해서 설명하는 부분이다. 추후 자세히 설명되겠지만 계획과 표준 문서를 왜 작성하고 어떤 내용을 담고 있는지를 파악하는 것이 DO-178 인증에 대해서 이해하는 핵심이다.

 

앞서 언급된 문서들은 일반적으로 개발팀에 의해서 작성되는데, 반드시 DER 혹은 프로그램 매니저가 작성해야 하는 것은 아니다. 계획은 당신의 팀에 의해서 작성될 필요가 있는 반면에 QA는 그 계획을 잘 따르고 있는지 뿐만 아니라 DO-178B의 모든 특성을 잘 준수한다는 것을 보장한다. 그리고 DER은 DO-178B가 의도하는 바를 충족했음을 확인함으로써 그 결과를 승인하게 된다.

 

당신이 이 지점에 도달하면 일종의 계약의 근거를 가지게 된다. 다섯 개의 계획문서와 세 개의 표준문서이다. 그 문서들이 모든 사람들에게 승인을 받고 나면 당신은 개발을 시작할 수 있다. 하지만 그건 이상적인 이야기이고 현실이 항상 그렇게 되는 것만은 아니다. 10개의 프로그램이 있다면 그 중 7개는 PSAC이 여전히 업데이트되고 있거나 제품이 생산되려고 하는 그 시점에 협의가 이루이지기도 한다. 때때로 현실은 전혀 다른 그림을 선사하기도 하기 때문이다. 소프트웨어는 개발 기간 동안 변경될 수 있다. 즉 고객이 추가적인 툴셋을 필요로 하는 기능을 요구하는 것이다. 이러한 변경들은 당신이 하고자 하는 방대한 양의 세부사항들과 일치하지 않을지 모른다. 최초 계획이 프로그램 개발이 시작되고 3개월 혹은 4개월 후에나 실행될 때도 있다.

 

3년의 기간이 소요되는 프로그램이 있다고 하자. 당신은 승인을 받을 수 있을 만큼 아주 상세하게 계획을 작성해야 한다. 하지만 그럼에도 여전히 계획을 준수하는 데에는 충분한 융통성이 존재한다. 예를 들면, 당신은 “나는 X회사의 소프트웨어 시험툴을 사용하겠어.”라고 말하면서 어떤 컴파일러를 선택하고 결정한다. 그런데 만약 이때 특정 버전을 명시하게 되면 그 버전에 영원히 종속될 수 있다. 이게 무슨 말이냐 하면, 개발이 진행되면서 상당한 시간이 지나고 다른 버전이 나왔을 때 당신은 최신 버전, 예를 들면 Version 7을 선택해야 할지도 모른다는 것이다. 당신이 계획을 작성했을 때는 Version 2라고 적은 것이다.

 

그래서 융통성이 필요하다. 당신은 시험을 기반으로 소스코드의 구조적 커버리지를 확인하기 위한 어떤 버전이 필요할 수 있다. 하지만 개발 환경이 변할 수 있기 때문에 계획문서에 툴에 대해서 아주 상세한 정보들을 모두 다 작성하려고 하지는 않을 것이다.

역주) DO-178은 현실에서 일어나는 문제점을 충분히 인지하고 있다고 볼 수 있다. 쉽게 말해서 계획과 실행이 따로 돌아갈 가능성이 높음을 알고 있다는 말이다. 이 책 전반에 걸쳐서 저자는 그런 현실적인 부분을 예로 들면서 그것을 어떻게 받아들이고 대응해야 하는지를 설명하게 될 것이다. 일종의 타협점을 보여준다고도 할 수 있다. 물론 그렇다고 여기서 설명하는 것들이 완전한 해결책도 아니고 자신의 상황과 맞지 않을 수도 있지만 적어도 DO-178이 현실과 괴리된 형식적인 인증은 아니라는 점을 미리 알려드리고 싶다. 그리고 바로 그런 점이 전문가의 도움이 필요한 이유이기도 하다.

 

계획문서의 양은 예를 들면 각각 20 ~ 30페이지 정도가 될 수 있다. 만약 계획 문서를 150페이지로 작성한다면 당신은 너무 많이 간 것이다. 따라서 계획문서는 “무엇(What)”과 약간의 “어떻게(How)”로 작성하되 나중에 당신이 원하지 않는 형태로 얽매이게 될 정도의 상세한 형태로는 작성하지 말아야 한다.

DO-178B의 진화   문서 기준 주요 특성 DO-178 498 & 2167A 산출물, 문서, 추적성, 관리, 계약, 시험 DO-178A DO-178 프로세스, 시험, 컴포넌트, 네 개의 위험레벨, 리뷰, 폭포수 방법론 DO-178B DO-178A 통합, 개발 방법, 데이터(문서가 아님), 툴, COTS DO-178C DO-178B 주관적인 부분을 줄임, 모델링과 리버스 엔지니어링의 기술

 

역주) 위의 박스에서 COTS는 Commercial Off The Shelf의 약자인데 우리말로는 일반적으로 ‘상용제품’이라고 번역하고 있다. COTS라는 영어를 그대로 많이 사용하기 때문에 따로 번역을 하지 않았다. 그리고 리버스 엔지니어링의 경우는 앞 절에서 설명한 바가 있다. (참고 포스팅: 26. DO-178과 COTS의 사용 (1))

 

1980년대에 DO-178이 나오고 얼마 지나지 않아서 여러 가지 질문들이 나왔다. PDR(Preliminary Design Review)은 어떻게 수행해야 하나? 문서 포맷은 무엇인가? 소프트웨어 신뢰성 수준은 어느 정도인가? 완벽한 시험을 할 수 없으므로 실패 확률은 1, 즉 그것은 실패할 것이다. 이에 대한 한 가지 대체 방법으로는 당신이 모든 입력 조합에 대해서 모든 가능한 출력의 검증을 통해 소프트웨어를 100% 시험할 수 있다는 것을 FAA에 증명하는 것이다. 당신은 단지 DO-178B에 존재하는 몇 가지 “빠져나갈 구멍” 중 하나로 “대체 준용 방법”을 사용한 것일 뿐이다. 하지만 그것이 정말 “빠져나갈 구멍”일까? 아니다. 그것은 DO-178B에서 필요로 하는 단계 중 하나로써 충분한 정당성을 가진 대체 단계일 뿐이다. 그렇다면 “대체 준용 방법”을 자주 사용하면 어떨까? 그건 안된다. 오로지 당신이 정말로 어쩔 수 없는 상황에 부딪치고 필요로 하는 DO-178B의 단계 중 하나를 당신에게 역할을 다할 수 있는 다른 어떤 것으로 대체해야 할 필요가 있을 때에만 사용해야 한다. 그것은 당신이 대체하려고 하는 DO-178B의 영역을 벗어나지 않는 선에서 충분해야 한다. 그것은 대부분 상식적이고 그 정당성이 기록으로 남아 있다. 기본적으로 당신이 “대체 방법”을 사용하기 전에 당신 회사의 QA 담당자와 DER이 공식적으로 그것을 인정하는 것을 문서화했는지 확인하라.

역주) 여기에서 설명하는 것들이 바로 DO-178이 현실과의 타협점을 어떻게 찾고 어떻게 진행하는 지 간략하게 설명하는 부분이다. 실제로도 DO-178 인증(혹은 준용)을 하다 보면 동일한 단계에 대해서도 업체마다, 프로젝트마다 심지어 사람에 따라서도 서로 다른 방법을 사용하게 되는 경우가 많다. 그리고 그것이 당연한 것이다. 만약 모든 업체, 프로젝트가 동일한 방법을 사용할 수 있다면 소프트웨어 개발의 ‘유일하고 최선의 방법’이 이미 만들어 졌을 것이다.

 

이런 방법은 소프트웨어 일부에서도 사용될 수 있다. 예를 들어 보자. 간단한 사인 함수 같은 경우라면 그래프를 사용해서 경계 점을 포함한 모든 점을 시험할 수 있고 그래서 다른 DO-178B 시험이 필요하지 않다. 이런 대체 준용 방법을 사용함으로써 가능한 모든 입력과 출력이 검증된다. 하지만 10,000 라인의 코드, 말하자면 비행 조종 프로그램에 대해서 그렇게 할 수 있는가? 불가능하다. 너무 많은 변수들과 입력 조건들이 있기 때문이다.

 

이럴 때 당신은 “대체 준용 방법”을 선호하게 되고 그 운용 프로그램에 대해서는 하나도 빠짐없이 모두 사용한다는 것을 보여주는 단순한 방법을 사용해서 시험하는 것을 피하고 싶은 것이 솔직한 심정일 것이다. 그런데 잠깐만. 그 운영 시스템을 왜 그런 식으로 시험할 수 없는가? 운영 시스템으로 들어가는 입력의 조합이 무엇이고 출력의 조합이 무엇인지 몰라서?

 

우리에게 필요한 것은 설계 보증 프로세스이다. 예를 들어서 만약 하나의 레지스터가 완전하게 시험될 수 있다면 그 레지스터는 모든 가능한 입력과 출력을 시험할 수 있기 때문에 더 이상 DO-254를 따를 필요가 없어진다. 그 의미는 그 하드웨어가 “단순하다”라는 의미이다. 그렇지 않다면 “복잡하다”는 것이고 DO-254를 통해서 인증을 받아야 한다. 그것이 필요한 전부이다.

역주) 항공전자 소프트웨어와 하드웨어는 반드시 DO-178과 DO-254에 대한 인증을 받아야 한다? 사실 기준이 있다. 만약 모든 시험 케이스를 다 나열할 수 있고 그 결과를 직접 확인할 수 있다면(도구를 사용하지 않고) 그때는 굳이 DO-178이든 DO-254이든 인증을 받지 않아도 된다. 그야말로 그 소프트웨어 혹은 하드웨어는 문제없이 완벽하게 동작한다는 것을 직접적으로 보여줄 수 있기 때문이다. 하지만 현실적으로 대부분의 소프트웨어와 ‘복잡한 하드웨어’, 일반적으로 FPGA로 대표되는“Complex Hardware”는 수작업으로 그 모든 것을 보이는 것이 거의 불가능하다. 그래서 DO-178, DO-254가 나온 것이다. 이런 개념이 흔히 나오는 내용이 아니지만 생각보다 단순한 개념이라고 할 수 있다.

 

사실상 하나의 레지스터에 대해서 할 수 있는 완전하고 철저한 시험이 수백만개의 게이트 조합의 ASIC에도 적용할 수 있을까? 그 숫자가 백만의 제곱이 될 것이고 당연히 그 모든 시험 케이스를 실행할 수가 없다. 그래서 DO-178과 DO-254에서 제시하는 설계 보증 프로세스를 따르는 것이다.

 

처음 DO-178A가 세상에 나왔을 때 매우 괜찮은 것처럼 보였다. 그러나 새로운 툴, 방법론 그리고 언어를 통해서 소프트웨어 산업이 빠르게 발전하면서 상황이 달라졌다. DO-178A는 그러한 급격한 발전을 따라갈 수 없었고 그래서 구조적 방법, 툴, 타겟에서의 비동기 시험 그리고 대체 방법 등으로 DO-178B가 개발되었다.

 

예전에 신규 항공기에 대해서 일하고 있을 때 우리는 이미 1990년대 초반에 DO-178B가 발표될 것이라는 것을 알고 있었다. 재미있는 사실은 그 때 당시 DO-178B가 나오기 전에 기존의 DO-178A로 인증을 받으려고 지원자들이 형식인증을 일찍 제출하는 경우가 많았다는 사실이다. 오늘날, 새로운 DO-178C가 더 엄격해질 것이라는 걱정으로 DO-178B로 인증을 받으려고 하는 지원자들이 몰리고 있다.

역주) 원서가 나왔을 때에는 아직 DO-178C가 나오기 전이었다. 물론 현재는 DO-178C가 가장 최신버전이고 무조건 이것을 따라야 한다.

 

DO-178B에서는 더 이상 문서의 개념에 얽매이지 않는다. MIL-STD-498을 따를 필요도 없다. 단지 요구사항과 설계를 담고 있는 적절한 데이터와 프로세스 모델이 필요할 뿐이다. 그것들을 형상관리하에 유지할 수만 있다면 그것으로 충분하다.

 

이전에는 모든 문서에 대해서 형상관리 계획이 별도로 필요했지만 이제는 프로세스와 데이터로 그 부분을 대체하고 있다. 더 이상 하나의 문서가 아니라 데이터민으로도 소프트웨어 개발 계획과 합쳐질 수도 있다. FAA는 데이터 항목을 개발하는 데 있어서 여지를 주고 있다.

역주) 설명이 간단해서 의미가 잘 와 닿지 않을지 모르겠다. 여기서 이야기하는 것은 예전(DO-178A)에는 증빙을 위해서 제출하는 데이터로 문서만을 고려했었는데 DO-178B가 나온 시점에서는 인증에 대응할 수 있다면 문서뿐만 아니라 어떤 형태의 데이터도 사용 가능하다는 의미이다. 인증 데이터의 개념이 문서에서 좀 더 확장되었다고 보면 된다.

 

산출물은 당신이 소프트웨어를 리뷰했다는 것을 보여준다. “당신이 리뷰를 수행했다는 것을 증명하는 산출물이 무엇인가요?”라는 질문을 받을지 모른다. 그것은 마치 세금 혜택을 받기 위한 증빙을 위해서 영수증을 사용하는 것과 같다. 회계사가 이런 말을 할 것이다. “올해 네 개의 서류가방에 대한 공제를 원하시는군요. 좋습니다. 하지만 영수증을 주셔야 합니다.”

 

체크리스트는 눈 위를 걸을 때 남는 발자국 같은 산출물이다. 어떤 사람들은 그것을 “빵부스러기”라고 부른다. 즉, 라이프사이클 프로세스 동안에 당신이 한 것을 증명하는 무언가를 남기는 것이다. 일반적으로 종이형태로 캐비닛에 저장되거나 전자파일 형태로 소프트웨어 개발 폴더, 즉 형상관리 서버에 보관될 것이다.

 

우리는 형상관리툴의 사용을 추천한다. 형상관리툴은 DO-178B에 의해서 공식적으로 요구되는 것은 아니지만 형상관리툴이 없으면 인증을 준수한다는 것을 증명하기가 거의 불가능하다. 또한 그런 툴은 효율성을 상당히 개선시켜준다. 모든 자료들을 체크하고 보관하게 해주며 체계적인 리비전을 할 수 있게 해준다. 즉 소프트웨어 개발 계획 버전 1이 우리가 확인하고자 하는 버전이라고 할 때 버전 1의 리뷰가 산출물로 존재한다는 말이다. 문서와 리비전 번호는 체계적으로 구성된다.(사실 우리는 회사 자체의 방식으로 그렇게 해오고 있다.) 당신은 당신 회사의 프로세스가 어떻게 만들어 졌는지 그리고 그것이 SEI CMMI Level 4를 만족한다는 것을 공표하기를 원하는가? 아마도 아닐 것이다. 왜냐하면 경쟁사들은 거기에 도달하기위해 당신이 사용한 5백만달러를 회피하기위해 그것을 사용할 수 있을 것이기 때문이다.

 

차를 구입하는 것과 비교해 보자. 당신은 제로백이 3초이고 갤런당 50마일의 연비 그리고 일곱 식구가 탈 수 있는 차를 원한다. 또한 디자인도 좋고 가격도 15,000불을 넘지 않기를 원한다. 하지만 아마 당신이 실제로 갖게 될 차는 그 5가지 중 2개 정도만 만족할 것이다. 비슷하게 각 회사는 서로 다른 목표를 가지고 있다. 누군가에게는 그것이 스케쥴이고 또 다른 누군가에게는 그것이 제한된 리소스여서 비슷한 태스크를 달성하기 위해 선택되는 프로세스가 서로 다르다. 한 가지로 모든 것을 커버하는 완벽한 툴은 없다.

 

동일한 프로젝트에 대해서도 DER에 따라서 서로 의견이 다를 수 있다. 그럼에도 그들 모두는 옳다! 재미있는 상황이지만 당신은 그것을 받아들여야 한다. 오늘날 항공전자와 항공산업에서 가장 큰 변수는 DER이다. DER이 시키는 대로 하면서 비용이 많이 들 수도 있고 그것 때문에 당신이 더 합리적이고 융통성이 있으며 같이 일하기 더 편한 다른 DER을 찾게 만들지도 모른다. 어쩌면 그 사람은 당신이 비용을 덜 들게 하고 시간을 줄여줄 수도 있다. 그것이 그가 “조작을 한다”는 것을 의미하는 것은 아니다. 그의 마음속에는 모든 DER이 그렇게 할 것으로 예상되는 것을 당신이 그대로 따르고 있다고 생각한다. 그들은 규정을 만들거나 특정 프로세스가 어떻게 동작해야 하는지를 말하지 않는다. 그들의 일은 당신이 DO-178B 혹은 DO-254를 준수하는지를 판정하는 것이다.

 

다섯가지 핵심 계획문서들   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP   PSAC 소프트웨어 인증계획(Plan for Software Aspects of Certification) SQAP 소프트웨어 품질보증 계획(Software Quality Assurance Plan) SCMP 소프트웨어 형상관리 계획(Software Configuration Management Plan) SDP 소프트웨어 개발 계획(Software Development Plan) SVP 소프트웨어 검증 계획(Software Verification Plan) ** 세 가지 표준문서 포함: Requirements, Design 그리고 Coding   역주) 원서에는 위의 표기와 달리 QA, CM으로만 적혀 있고 SWDP, SWVP라고 약어가 소개되어 있다. 현재 일반적으로 사용하는 방식과 차이가 있으므로 굳이 원서와 똑같이 설명하는 것이 큰 의미는 없어 보여서 최근에 사용하는 형태로 표기한다.

 

DO-254에 대해서는 조금 다른 점이 있다. 소프트웨어를 빼고 하드웨어라는 단어를 넣는 것을 제외하면 계획문서는 거의 동일하다고 할 수 있다. 품질보증은 소프트웨어에 적용되는 단계 및 데이터와 동일한 부분이 하드웨어 제작 전체 과정에 걸쳐서 이루어지기 때문에 “제품 보증”으로 변경되었다. 이들 계획은 당신이 어떻게 이 제품과 프로세스 보증을 만들어 나갈지에 대한 청사진으로써 당신 팀과 FAA의 사이의 계약 기반이 된다.

역주) 원서에서 뭔가가 빠진 게 아니라면 위의 표를 제시하면서 DO-254만 달랑 이야기하는 것은 뭔가 좀 이상하다. 최소한 위의 박스에 있는 것들이 세 가지 표준 문서를 포함해서 DO-178에서 핵심이 되는 다섯 가지 계획문서라는 언급이라도 해야 하는 게 아닌가 싶다. 어쨌든 원서에서는 그 부분이 빠져 있어서 이렇게 역주에서라도 간단하게 말씀드리고 넘어간다.

 

소프트웨어 인증 계획(Plan for Software Aspect of Certification, PSAC)   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP   20 ~ 30 페이지 시스템, 아키텍처 그리고 소프트웨어에 대한 개요 안전성, 위험도 그리고 인증에 대해서 논의 다른 계획 및 산출물들을 참조 DER의 도움을 받고 DER에 의해서 승인받음 FAA에 제출되고 승인받음

 

200페이지의 PSAC을 쓰는 것은 필요하지도 않고 이상적인 것도 아니다. 따라서 30 혹은 40페이지를 유지하라. 너무 상세하게 작성하게 되면 프로그램 개발 과정에서 너무 이른 시기에 질문의 여지가 너무 많아지게 된다.

역주) 사실 이 부분이 DO-178에서 문서를 대하는 기본적인 철학을 보여주는 부분이다. 지금은 잘 와닿지 않겠지만 어쨌든 DO-178에서는 문서를 많이 적는 것에 대해서는 관심이 없다. 오로지 필요한 내용을 작성했느냐가 핵심이다. 실전에서 경험해봐야 그 느낌이 오겠지만 일단 이런 마인드를 이해하고 앞으로 나올 내용들을 받아들이기 바란다. (참고 포스팅: 18. PSAC(Plan for Software Aspects of Certification) (Section 11.1))

 

시스템, 아키텍처 그리고 소프트웨어에 대한 개요는 PSAC에 작성해야 한다. 여기에 시스템 설명을 작성하는 것이 왜 중요할까? 그것은 소프트웨어는 그 자체로 인증을 받는 것이 아니라 시스템의 일부로써 인증을 받기 때문이다. 그것이 아키텍처를 보여주는 시스템 개요가 필요한 이유이다.

역주) 중요한 개념이어서 원서보다 역주가 더 많아지더라도 이렇게 추가한다. DO-178이 소프트웨어 인증이라고 많이들 알고 있다. 그런데 여기서 인증이라는 것은 우리가 흔히 생각하는 그런 형태가 아니다. 저자의 말처럼 소프트웨어는 그 자체로는 DO-178 인증을 받을 수 없다. 반드시 그 소프트웨어가 돌아가는 시스템이 확정되어야 하고 그 시스템이 인증을 받을 때 비로서 소프트웨어도 DO-178 인증을 받는 것이다. 미묘하고 잘 이해가 안될 수 있겠지만 이것이 기본적인 개념이라는 것을 명심하자.

 

소프트웨어가 이중으로 구현되어 있는지, 그 소프트웨어를 모니터링하는 기능이 포함되어 있는지를 알아야 한다. 어떤 언어가 사용되는가? 마이크로프로세스는 무엇을 사용하는가? 동일한 마이크로프로세서상에서 돌아가는 레벨 A와 레벨 C의 파티션된 소프트웨어가 존재하는가? 그들의 무결성은 어떻게 보여줄 것인가?

 

안전성, 위험레벨 그리고 인증에 대한 논의. PSAC에 위험 레벨이 A, B, C, D 혹은 E인지 그리고 그 이유는 무엇인지가 정의되어야 한다. 이유에 대해서 시스템 안전성 분석과 같은 이전에 수행된 데이터를 제시할 수도 있겠지만 어쨌든 왜 그 레벨이 결정되었는지가 정당화되어야 한다.

 

다른 계획문서와 산출물들에 대한 참조. 품질보증에 대해서 계획이 수립되고 나면 약 30페이지 정도의 품질보증 계획 문서(Software Quality Assurance Plan)를 작성한다. 그런 과정을 통해서 SQAP는 DO-178B에 따른 품질보증을 어떻게 보여줄 지를 정확하게 상세화한다.

 

FAA는 거의 항상 소프트웨어 인증계획을 승인하는 권한을 유지한다. DER로부터의 추천도 좋아하지만 승인에 대해서는 그들이 직접 행사한다. 감항당국의 담당자가 “Charlie, 이거 저 대신 승인해줄 수 있나요? 당신이 승인했다는 최종 양식을 저에게 보내주세요.”라고 흔히를 이야기하는 경우가 많다.(여기서 Charlie는 Charlies Soderstrom을 말하는데 상당한 경험을 보유한 DER이다.) 이런 “위임된 권한”은 FAA의 업무부하가 증가함으로 인해서 어떤 영역에서는 더 잦아지게 되었다. 당신에게 필요한 것은 어쨌든 이들 계획문서들이 무사히 승인받을 수 있기를 비는 수밖에 없다.

역주) DER이 생기게 된 이유가 잠깐 언급되고 있다. 특히 미국의 경우 거대한 땅덩어리에 비례해서 수많은 항공기가 운용되고 있기 때문에 DER은 필수라고 할 수 있다. DER에 대해서는 추후 좀 더 설명하게 된다. (참고 포스팅: 21. DO-178과 DER(Designated Engineering Representative) ? Job Aid (7))

 

품질보증 계획(SQAP)   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP   프로세스 전반에 걸친 QA의 역할을 기술 모든 계획과 프로세스 전반에 대한 조율이 되고 이를 그대로 따르는 지를 보증 전이 기준을 만족하는지를 보증 합치성에 대한 리뷰와 검사를 기술 QA에 의한 감사/리뷰의 가이드라인과 일정을 제공(체크리스트 포함)

 

품질보증 계획(Software Quality Assurance Plan)은 라이프사이클 전반에 걸친 품질 혹은 프로세스 보증을 기술한다. 이 소프트웨어에 대해서 FAA가 하는 일은 무엇인가? 누가 검사를 하는가? QA는 얼마나 자주 감사를 수행하는가? QA가 시험을 참관하거나 코드리뷰를 수행하는가? 계획에 있는 어떤 프로세스나 활동을 QA가 참석하는가? QA는 보고를 누구에게 하는가?

 

한 가지 예를 들어보자. 우리 팀의 QA는 나에게 보고한다. 나는 그 소프트웨어를 만드는 책임자인데 만약 그가 ‘좋은’ QA가 아니라면, 그 말은 그가 내가 하는 것을 맘에 들어 하지 않는다는 것인데, 그렇다면 나는 나와 맞는 다른 누군가를 찾을 것이다. 하지만 이러한 방식은 좋은 방법이 아니다. FAA는 그것이 좋지 않은 방법이라고 말할 것이다. QA는 회사의 품질에 책임이 있는 책임자에게 보고해야 한다. 그리고 기억하자. QA는 실질적인 엔지니어링 활동(요구사항, 설계, 코드, 시험)의 어떤 것도 관여할 수 없다. QA의 주된 역할은 다섯 가지 핵심 계획문서들과 세 가지 표준 문서들이 프로젝트에 대해서 적용가능한 DO-178B 기준을 완전하게 담고 있는지를 확인하고 실제 개발이 그 계획과 표준을 따르는 지를 감사를 통해서 확인하는 것이다.

 

QA는 자신의 많은 활동들을 나에게 보고할 수 있는데 “당신의 엔지니어들은 이것 혹은 저것을 하지 않았다.”라고 말하면서 그가 개발에 대해 지적하는 것이 맘에 들지 않는다고 하더라도 그것으로 그를 해고할 수는 없다. 그것이 좀 이상하게 보일 지 몰라도 조직 구조상으로 별도의 보고 프로세스가 존재해야 하는 이유이다. 집을 짓는 계획이 있다고 한다면 전체적인 구조가 결정되지 않은 상태로 배관이나 전기작업을 하려고 하지는 않을 것이고 혹은 계획없이 일하다 보니 온수 탱크 바로 아래에 퓨즈박스를 두게 되는 그런 상황을 원하지는 않을 것이다. 품질보증계획이 개발계획과 충돌하는 것을 원하지는 않을 것이다. 따라서 품질보증 담당자는 팀의 일원으로 혹은 “시스템”으로써 존재할 필요가 있다.

역주) DO-178에서 QA, 즉 품질보증에 대해서 정리하자면 한마디로 계획대로 잘 진행하고 있는지를 체크하는 활동이라고 말할 수 있다. 소프트웨어 개발 과정을 계획대로 진행한다는 것이 말처럼 쉬운 것이 아니다. 그래서 DO-178이 어려운 것이고 그런 의미에서 QA의 존재와 활동이 상당히 중요하다고 할 수 있다. (참고 포스팅: 22. SQAP(Software Quality Assurance Plan) (Section 11.5))

 

품질보증은 예를 들면 전이 기준과 같은 활동들을 보장한다. 이것은 소프트웨어 개발의 하나의 프로세스로부터 다른 프로세스로의 이동을 의미한다. 다음 프로세스로 이동하기 전에 진입과 진출 기준이 필요하다.

 

집을 짓는 것에도 유사한 부분이 있다. 집을 짓기 위한 모든 계획이 승인되고 나면 가장 먼저 하는 것은 일반적으로 기초공사를 하고 시멘트를 붓는 것이다. 하지만 검사관이 “기초를 위한 적당량을 부었군요. 정확한 강도와 혼합입니다. 계속 진행하세요. 승인합니다.”라고 말하기 전에는 뼈대 작업을 시작하지 않는다. 당신은 진입과 진출 기준을 충족한 것이다.

 

만약 진입과 진출 기준을 만족하지 않은 상태에서 뼈대 작업을 시작한다면 자칫 그것을 모두 부수어야 할 수도 있다. 소프트웨어에서는 좋은 요구사항이 필요하고 그런 다음에 리뷰, 승인 그리고 설계와 코딩으로 들어가기 전에 모든 반복이 이루어지는 과정을 따라야 한다. 예전에는 PDR/CDR을 진행했었다. 사실상 그것들이 전이 기준이고 DO-178A에서 강조되었던 것들이다.

 

이어서 나온 DO-178B에서는 제품이 그런 식이 아니라 반복적인 방법으로 개발된다는 것을 알게 되었다. 하나의 요구사항을 취하고 설계로 전이되어 간다. 왜냐하면 요구사항 문서는 하룻밤사이에 완성되는 것이 아니기 때문이다. 15, 20 혹은 30번의 PDR이 필요할 지 모르고 그래서 점진적으로 수행된다. 그리고 그것을 전이 기준이라고 말하게 된다.

 

개발이 계획과 일치하고 제조 과정을 통한 생산과 일치해야 한다. 문제가 발견되면 무엇을 할지, 얼마나 자주 할지, 왜 그것을 할지를 품질보증 계획하에서 결정하라.

 

우리는 품질보증 계획에서 퍼센티지를 주장하는 FAA 담당자와 마주친 적이 있다. 몇 퍼센트의 코드가 QA에 의해서 감사될까? 계획문서에는 QA가 소스코드를 감사하고 프로세스를 리뷰할 것이라고 말하지만 퍼센티지에 대한 것은 없다. FAA에서는 10, 15, 20 혹은 또 다른 숫자를 원했다. DO-178B는 그런 가이드라인을 제시하지 않지만 이 경우에는 우리는 숫자를 제시했고 승인을 받았다.

 

QA가 “10”이라고 답했다고 가정해 보자. 그러면 FAA는 답한다.

“충분하지 않습니다.”

“그래요, 그럼 당신은 얼마를 원하나요?”

FAA가 말한다.

“100%입니다.”

QA가 말한다.

“그건 아닌 것 같네요. 그렇게 되면 그것은 더 이상 감사가 아니라 완벽한 리뷰입니다.”

 

이제 DER이 관여하게 되면서 협의된 결과가 나왔다. 40%. 이제 모든 사람들이 만족한다. 그러나 이후에도 많은 논쟁과 협의를 통해서 더 낮은 퍼센티지로 합의가 이루어졌다.

 

역주) 혹시 위의 대화가 선문답처럼 느껴지는 사람이 있을지 모르겠다. 실제로 역자가 현장에서 인증 컨설팅을 하면서 QA 활동도 하는 경우가 있는데 이 때 내부 감사를 하면서 어느 정도의 양으로 어느 정도 상세하게 감사를 해야 할 지 애매한 경우가 많다. 이 대화는 바로 그런 경우를 예로 든 것이라고도 할 수 있다. 결론적으로 100% 다 한다는 것은 말이 안되는 것이고 40%도 상당히 많다고 봐야 한다. 개인적인 의견으로는 랜덤으로 진행하면서 문제가 어떤 수준으로 발견되느냐에 따라서 QA가 주관적으로 판단해서 결정할 부분이라고 본다. 물론 QA의 그런 판단은 이후 DER(혹은 감항당국에 해당하는 주체)에 의해서 다시 한번 판단을 받게 된다.

 

품질보증은 하나의 프로세스이기 때문에 그 활동이 프로세스를 따른다는 것을 FAA에 확인시켜줄 방법이 있어야 한다. 기억하라. QA의 주된 역할은 모든 프로젝트 프로세스와 계획 그리고 표준이 DO-178B를 준수하고 모든 사람들이 그것들을 따르며 그것을 증명할 수 있다는 것을 보장하는 것이다. 그것이 체크리스트, 증빙 그리고 산출물들이 필요한 이유이다. FAA는 DER에 의지하는 것처럼 QA를 의지한다. DER은 QA, 개발자 그리고 검증자가 각자의 역할을 했고 개발 기간동안 단계가 변경되기 전에 가능한 많은 문제점들을 발견했다는 것을 보장한다. FAA는 모든 사람들이 인증을 준수하기 위해서 제대로 했다는 것을 보장한다. 일반적으로 문제점들은 이러한 감사 과정에서 발견된다.

 

형상관리 계획에서는 제품, 데이터, 문서 그리고 라이프사이클 과정에서의 산출물에 대한 엄격한 형상관리가 되어야 한다. 리비전 절차와 함께 네이밍과 넘버링에 대한 정의도 필요할 것이다.

역주) 다른 계획 문서와 달리 형상관리계획에 대해서는 그림이 안 보인다. 아마도 원서에서 누락된 것 같은데 그래도 없으면 허전하니까 아래 그림으로 참고하자. (참고 포스팅: 21. SCMP(Software Configuration Management Plan) (Section 11.4))     형상관리 계획(SCMP)   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP

 

전통적인 형상관리 시스템(여전히 일부 회사들에서 사용되고 있는)은 도서관에서 책을 빌리는 것과 유사하다. 사서가 카드에 도장을 찍고 2주가 지나면 책이 반납된다. 빌리고 반납하는 형태의 시스템은 대부분 자동화된 시스템으로 교체되었다. 형상관리 시스템은 내부 네트워크 기반이어서 자체적으로 시스템을 정의하고 개발자들이 어떻게 사용할지를 결정한다. 어떻게 설치하고 누가 사용할 수 있고 사용할 수 없는지 문제점은 어떻게 보고되고 시스템이 어떻게 추적되는지에 대한 기준이 결정된다. 소프트웨어의 변경은, 무엇이 문제였고 그것이 어떻게 수정되었으며 승인되었는지와 같은 근거가 없이는 이루어질 수 없다.

 

오늘날 보안 역시 큰 관심사이다. 시스템에 대한 백업은 어떻게 이루어지는가? 소프트웨어를 복구하려면 어떻게 해야하며 형상관리는 누가 책임지는가? 형상관리의 책임은 시스템에서 작업하는 모든 사람에게 있다. 그리고 이들은 문제를 어떻게 등록하고 데이터를 어떻게 체크인, 체크아웃하는지를 알아야 한다. 이와 관련된 문서들은 프로그램상에서 작업하는 모든 엔지니어들이 사용할 수 있어야 한다.

 

소프트웨어 개발 계획(SDP)   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP   일정, 인력, 의존성, 최종결과물, 마일스톤 그리고 조직을 정의 개발 환경과 툴을 기술 라이프사이클 프로세스들(요구사항, 설계, 코딩, 통합, 시험, 변경 등….)을 기술 최종결과물 뿐만 아니라(전이 기준을 포함한) 형상관리와 품질보증이 관여하는 부분도 기술

 

소프트웨어 개발 계획은 소프트웨어가 설계되고 개발되며 구현되고 그런 후에는 통합되는 과정에서의 인력, 일정, 최종결과물, 마일스톤, 툴 그리고 소프트웨어 개발환경에 대한 것이다. 라이프사이클 프로세스들, 요구사항이 어떻게 정의되는지 그리고 모델 기반의 개발을 진행할 것이지 등을 기술한다. 구조적 방법을 사용해서 개발할 것인가? Ada 혹은 C를 사용하는가? 사용하는 툴은 어떤 것들이 있고 요구사항에 대한 추적성에는 어떤 툴을 사용하는가?

 

요구사항 추적을 위해서 DOORS를 사용하는가? 그래픽 기반의 소프트웨어 결과물을 자동으로 생성하기 위해서 Engenuity사의 QCG를 사용하는가? 항공전자장비의 RTOS로 Integrity-178B를 사용하는가? 이러한 상세한 내용들이 개발 계획에 포함된다. 툴을 어떻게 설치하고 사용하는가? 만약 정적 분석을 하고자 한다면 유닛테스트를 작성할 수 있다. 개발 환경은 타겟과 다를 지 모른다. 예를 들면 윈도우용 PC 혹은 UNIX 시스템을 사용할 수 있다.

 

역주) DO-178에서는 툴에 대해서 상당히 민감하다. 툴인증을 아예 별도로 구분해서 DO-178과 거의 동일한 수준으로 심각하게(?) 다루기도 한다. 그저 단순히 이런 툴을 사용하고 있다라는 정도에서 끝나는 것이 아니라 툴의 결과물이 소프트웨어에 어떤 영향을 주는지까지도 꼼꼼하게 따진다는 것을 염두에 두어야 한다. (참고 포스팅: 19. SDP(Software Development Plan) (Section 11.2))

 

 

소프트웨어 검증 계획(SVP)   1. PSAC 2. SQAP 3. SCMP 4. SDP 5. SVP   리뷰와 검증 결과에 대한 수용을 기술 추적성 시험과 통합의 모든 특성 시험 환경과 툴 회귀시험과 재검증 리소스와 관리

 

소프트웨어 검증 계획은 소프트웨어가 리뷰되고 검증되며 그런 후 정확성을 확인 받는 과정에서의 인력, 일정, 최종결과물, 마일스톤, 툴 그리고 소프트웨어 검증 환경에 대한 것이다. 요구사항, 설계 그리고 코드가 어떻게 검증되는지, 라이프사이클 프로세스를 기술한다. 공식적인 툴을 사용할 것인가? 동료검토 전에 코드를 체크하기 위해서 Polyspace와 같은 툴을 사용하는가? 사용하는 툴은 어떤 것들이 있고 요구사항에 대한 추적성에는 어떤 툴을 사용하는가?

 

코드 커버리지를 구조적으로 분석하고 시험하기 위해서 VectorCAST를 사용하는가? 이러한 상세 내용이 검증 계획에 포함될 것이다. 툴을 어떻게 설치하고 사용할 것인가? 하드웨어/소프트웨어 통합 시험을 어디에서 진행할 지, 그리고 회귀시험 전략을 기술할 수 있다.

 

역주) 검증을 소프트웨어 개발 과정 중의 일부로만 생각할 수도 있지만 DO-178에서는 검증을 개발과 동급(즉 완전히 분리해서)으로 다루고 있다. (참고 포스팅: 20. SVP(Software Verification Plan) (Section 11.3))

 

다른 데이터 항목들도 만들어져야 한다. 계획 문서들이 작성 완료되면 요구사항 작성, 설계 및 코드 작성을 위한 표준을 개발하게 된다. 만약 10명의 개발자가 있다면 그들 각자가 자기만의 스타일과 포맷으로 작업하기를 원하지는 않을 것이므로 완전한 표준을 가지는 것이 중요하다. 이때 일관성을 가지는 것이 중요하다.

추가적인 문서와 산출물들   소프트웨어 요구사항 표준(Software Requirements Standard) 소프트웨어 설계 표준(Software Design Standard) 소프트웨어 코딩 표준(Software Coding Standard) 소프트웨어 형상 인덱스(Software Configuration Index(SCI)) 혹은 버전 기술문서(Version Description Document(VDD)) 추적성 매트릭스 요구사항, 설계, 코딩 & 시험/결과 툴 인증 계획/데이터/평가 소프트웨어 환경 형상 인덱스(Software Environment Configuration Index(SECI)) 소프트웨어 완수 요약(Software Accomplishment Summary(SAS)) 형상 레코드 & 문제점 리포트 QA & DER 감사레코드

 

안전한 설계와 코딩 컨셉을 기술하는 것이 또한 중요하다. 예를 들어 코딩 담당자들이 코드에 넣지 않았으면 하는 C++ 특성이 있다면 허용 가능한 C++ 서브셋을 정의하고 그것을 소프트웨어 코딩 표준에 상세하게 설명해야 한다. 또 다른 예로 극단적으로는 전체 소프트웨어가 한 줄로 작성될 수 있지만 그것은 좋은 코딩 습관이 아니다.

 

한 라인에 몇 글자를 사용하고 파일 하나에 얼마나 많은 함수를 사용할 것인가? 하나의 파일에 모든 함수가 다 포함되어서는 안되므로 코딩 표준에 기본적인 기준과 허용가능한 McCabe의 최대값과 같은 좀 더 복잡한 이슈들을 정의하라. C에서의 순환코드는 문제를 만들 수 있다. 안전하지 않은 스택 오버플로우도 있다. C++에서 상속을 사용할 수 있는가? 안된다. 레벨 A에 대해서는? 역시 안된다. 이런 활동들을 제약하거나 그것들을 분석할 수 있도록 소프트웨어 코딩 표준에 정의할 필요가 있다.

 

역주) DO-178에서는 이론적으로는 표준 문서가 계획 문서와 같은 필수 문서는 아니지만 실제 현장에서는 반드시 있어야 하는 문서이다. 요구사항, 설계, 코딩에 대해서 일종의 내부 기준을 정해놓고 진행을 한다는 의미가 있기 때문에 FAA(DER)에서는 개발과정 전반에 걸쳐서 표준에 정한 내부 기준대로 실제 요구사항, 설계, 코딩이 이루어졌는지 확인하게 된다. (참고 포스팅: 23. 소프트웨어 개발 표준문서 ? SRS, SDS, SCS)

 

소프트웨어 형상 인덱스(SCI) 혹은 버전 기술 문서(VDD). VDD는 오래 전에 사용된 용어인데 여전히 군에서 사용되고 있다. 같은 역할을 하는 것이 소프트웨어 형상 인덱스인데 VDD가 요구하지 않는, 하지만 소프트웨어 형상 인덱스에서는 필요한 추가적인 항목들 몇 가지가 포함되어 있다. 그것은 제품에 대해서 뿐만 아니라 제품이 개발되는 환경에 대한 것이다.

 

다음으로 추적성 매트릭스가 있다. 요구사항, 설계, 코드 그리고 시험 결과는 당신이 수행하는 활동의 실제적인 결과이다. 소프트웨어 환경 형상 인덱스는 제품을 개발하고 시험하며 사용되는 도구가 포함된 환경을 기술한다. 추적성은 앞서 설명한 것처럼 Top-Down과 Bottom-Up으로 구성된다.

역주) 계속 이야기하는 것이지만 원서의 내용이 두서없이(의식의 흐름대로?) 설명된 부분이 많다는 걸 다시 한번 느끼는 부분이다. 어쩔 수 없이 이 글을 읽으시는 분들이 다음에 이어진 문장들과의 연관성이 이해가 안되는 경우에는 각 문장이 원래부터 전혀 다른 설명이라는 점을 이해하는 수 밖에 없을 것 같다. 의역을 하더라도 저자의 작성 순서에 까지는 손을 대지 않고 있기 때문에 이런 부분은 감안해 주시기 바란다. 물론 기회가 된다면 역자가 따로 설명드리는 방법도 있을테지만. (참고 포스팅: 3. DO-178과 추적성 매트릭스(Traceability Matrix))

 

소프트웨어 완수 요약(Software Accomplishment Summary)은 결론적으로 당신이 무엇을 했느냐를 정리한 것이다. 소프트웨어 인증 계획(PSAC)이 인증을 받기 위해서 앞으로 무엇을 해 나갈지를 말하는 것이지만 만약 정확하게 따르지 못했다면 그런 차이가 발생한 부분과 이유의 정당성을 소프트웨어 완수 요약에서 언급해야 한다.

 

품질 기록과 문제점 리포트는 라이프사이클 전반에 걸쳐서 생성되고 작성되는데 여기에는 DER이 어디에서 관여되었는지에 대한 기록, 각 프로세스 단계별로 생성된 체크리스트, 감사 기록들, 그리고 라이프사이클 전반에 걸쳐서 생성된 산출물들을 포함한다.

 

항공전자 시스템 문서들에는 제품 개발의 가이드를 위해서 고객으로부터 받게 되는 규격서들이 포함된다. 또한 고객이 시스템 설계를 제공하고 그것을 개발해 달라고 요구할 수도 있다. 시스템 설계는 동일한 시스템 내에서 여러 대의 LRU와 이중화 그리고 서로 다른 수행경로를 가질 수 있다. 그래서 동일한 동작을 수행하는 유닛의 숫자가 시스템 설계의 일부이다. 일단 진행되기 시작하면 시스템 설계는 두 개의 영역으로 나뉜다. 기능은 소프트웨어 혹은 하드웨어 요구사항 중 하나로 수행될 것이다.

 

그러나 여기에 도달하기 전에 기능, 실패 그리고 안전 정보를 살펴보는 안전성 분석을 통해서 시스템 아키텍처와 설계에 대한 개발 프로세스를 거쳐야 한다. 이것은 전체 시스템의 고장을 일으키는 한 가지 실패 요인으로써 그러한 불안전한 조건을 찾아낸다. 예를 들면 보조익을 컨트롤하는 모듈로의 모든 전원이 항공기의 오른쪽 엔진에서 오는 경우 만약 그 엔진이 고장이 나면 보조익 역시 기능을 상실하게 된다. 이것을 피하기 위해서 서로 다른 여러 개의 전원 공급원을 가져야 할 수도 있다.

 

하나의 수압 시스템은 네 개의 전기적인 조정을 가진 다섯 개의 중복된 전원 소스를 가지고 있을 수 있다. 어떤 항공기에서는 그 다섯 번째를 Ram Air Turbine이라고 해서 RAT라고 부른다. 그것은 만약 모든 전원 공급이 실패하는 경우에도 항공기 동체의 문을 열고 작은 팬을 떨어뜨려서 공기 흐름 속에서 돌도록 함으로써 비상 전원을 공급하게 된다. 간단하지만 최후의 방어선이 되는 것이다.

역주) 공식적으로는 DO-178에는 포함되지 않지만 그럼에도 DO-178에서 가장 우선적으로 관심을 가지는 것은 바로 시스템 안전성(System Safety)이다. 실제로 소프트웨어의 DO-178 인증 레벨은 이 시스템 안전성으로부터 나오며 그것을 기반으로 소프트웨어에 대한 요구사항이 정확하게 정의될 수 있다. 어떻게 보면 DO-178의 시작점이 된다고 할 수 있다.. 이에 대한 부분은 다음 장에서 자세하게 소개된다. (참고 포스팅: 29 DO-178과 System Safety (1))

 

설계 보증 프로세스의 관점에서는 “펌웨어”라는 단어는 더 이상 사용되지 않는 것에 주의하자. 하드웨어(DO-254) 혹은 소프트웨어(DO-178)가 있을 뿐이다. 예전에는 “펌웨어”라고 하면 실리콘 기반의 로직을 말했지만 이제는 오로지 “복합 하드웨어”라고 부른다.

 

DO-178과 DO-254는 시스템을 다루며 DO-254는 일반적으로 ASIC, PLD, FPGA와 같은 복합 전자 부품에 해당한다. 또한 DO-178B는 BSP, RTOS, 어플리케이션 소프트웨어, 라이브러리, 드라이버를 다룬다. 아래 그림에서 보듯이 어떻게 컨트롤되고 분류되느냐에 따라서 LRU의 부품이 나뉘어진다.

DO-178B & DO-254 영역 항공전자 LRU

 

그리고 당신의 프로젝트를 계획하는 방법은 앞서 언급했던 고려사항들과 전략들을 적용하는 것이다. 이제 DO-178B와 DO-254를 적용하고 시작할 준비가 되었다.

역주) 앞서 DO-254에서 말하는 하드웨어는 일반적인 의미의 하드웨어와 다르다는 점을 설명한 바가 있다. 일반적으로 생각하는 기계적인 관점의 하드웨어가 아니라 위의 그림에서처럼 프로그래밍이 가능한 하드웨어를 말하는 것이다. 실제 개발과정을 보더라도 소프트웨어를 프로그래밍 하는 것과 유사한 형태로 개발되기 때문에 한편으로는 DO-178과 유사한 면이 많다고 할 수 있다. 그런 의미에서 미리 말하자면 이 책에서는 주로 DO-178에 대해서 이야기를 하고 있지만 DO-178을 제대로 이해하게 되면 DO-25에 대해서도 이해할 수 있는 충분한 배경을 갖추게 된다고 할 수 있다. 혹시 그런 케이스에 해당하는 분이라면 한 번에 두 마리 토끼를 잡는다는 생각으로 열심히 학습해 보시기를 이 글을 보시는 분들에게 제안해 드리고 싶다.