23. 재검증

 

역주) ‘Verification Revisited’를 일단 ‘재검증’이라고 번역했다. 다른 곳에서는 ‘Regression Test’라는용어도 나오는데 이것은 ‘재시험’이라고 번역했다. 둘 다 시험을 다시 수행한다는 것을 말하는 것은 이해가 되는데 뭔가 좀 부족한 느낌은 있다. 일단 뉘앙스는 제쳐 두고 내용에 초점을 맞추어 봐주시기 바란다.

 

당신이 연구소에서 코드를 디버그 했고 그것이 동작한다고 생각했다고 가정해보자. 만약 당신이 이제 그 코드에 맞도록 문서를 작성한다면 이것은 DER이 FAA에 의해서 제제를 받도록 만들고 QA 담당자를 필요 없게 만들며 회사가 제품을 인증 받는 것을 막는 가장 빠른 방법이 될 수 있다. 우리는 코드를 작성하고 그런 다음 문서를 작성하고 추적성을 연결하고 품질보증 프로세스를 수행하며 그런 후에 FAA에 보여주는 것을 원하지 않는다. 그것은 사람들이 TSO 인증을 받으면서 해 온 전통적인 방법이다. 왜냐하면 TSO는 단지 마지막에 정보를 요구하기 때문이다. FAA는 그것을 알게 되었고 더 이상 그것을 좋아하지 않는다. DO-178B에 앞선 버전인 DO-178A는 이런 관습을 명시적으로 금지하지 않았다. 하지만 수 십년동안 DO-178B는 상업용 항공전자 프로젝트에 영향을 미쳐왔고 특별히 소프트웨어 라이프사이클 모델과 전이 기준에 대한 필요성, 그에 대해서 충실할 것을 언급해 왔다. DO-178B는 당신이 개발하면서 라이프사이클 프로세스를 따라야 한다고 말한다. 그것은 비록 일부 회사들은 그렇게 해서 제품 인증을 받았다고 하더라도 개발 동안에는 신경도 안 쓰다가 코드가 작성된 후 마지막에 가서야 되살아나서는 안된다. 그것은 객관적이지 않고 품질 혹은 안전에 이바지하는 바도 없다. 그리고 솔직히 그것은 재사용성, 유지보수성 그리고 비용효율의 흐름에 있어서 DO-178B의 대부분을 따랐을 때처럼 기여하지 않는다.

역주) 여기서 언급하는 내용은 일종의 리버스 엔지니어링(Reverse Engineering)이다. 앞에서도 리버스 엔지니어링에 대한 이야기가 나온 적이 있지만 그 자체가 문제가 아니라 DO-178에 맞게 제대로 진행하지 않는 것이 문제이다. 위의 설명은 ‘제대로 진행하지 않는’ 바로 그 부분이 문제라는 점을 지적하고 있다.

 

검증(Verification)

프로세스의 결과를 평가하는 것은 입력과 표준에 대한 정확성과 일관성을 보장한다. 그것은 단지 시험이 아니다. 시험은 검증의 한 가지 방법론이다. 대부분의 시간동안 검증은 주로 리뷰를 통해서 정확성과 일관성을 살펴보는 것을 의미해 왔다. 우리가 즐겨 선택하는 한 가지는 분석, 즉 반복가능한 평가이다. 예를 들면 이런 식이다. “나는 그것을 분석하도록 Joe에게 주었습니다.” “오, 당신은 그것을 분석했나요?” “예, 분석했습니다.” “어떻게요? 어떤 프로세스를 따랐으며 그것은 어디에 작성되어 있나요?” 그것은 당신의 표준 일부가 되어야 한다.

 

재시험 전략과 검증 계획내에 그 프로세스의 개요를 명시해야 한다는 것을 기억하라. 당신은 재시험을 수행하는가? 시험하지 않는 것은 불가능하다. 우리가 수행한 250개 이상의 항공전자 프로젝트에서 개발 과정 전반에 걸쳐서 완벽하고 변경이 없었던 적은 한번도 없다. 결함과 변경은 재시험을 가져왔다. 당신이 수행한 재시험이 검증 계획에 명시한 것과 일치했는가? 가장 좋은 것은 전체를 반복하는 것이다. 그러면 당신은 절대 잘못된 길로 빠지지 않을 것이며 그래서 FAA는 그것을 좋아하고 우리도 좋아하고 – 관리자는 비용 때문에 그것을 싫어한다. 따라서 대부분의 DER, FAA 그리고 이성적인 사람들은 변경된 소프트웨어만 혹은 변경에 의해서 영향을 받을 가능성이 있는 소프트웨어만 재시험하는 것을 허용한다. 우리는 그 모든 것을 검증 계획에 기술한다. 그러면 어떤 시험, 요구사항 그리고 코드를 재시험할지를 어떻게 결정하는가?

 

코드의 일부가 변경되면 먼저 그 코드의 일부에 대해서 재시험을 계획한다. 그런 다음 추적성 매트릭스를 사용하고(당신은 언제나 그것을 업데이트 해왔다. 기억하는가?) 변경된(요구사항, 설계, 코드, 다른 시험, 등) 아이템에 관련되는 항목들은 어떤 것이든 모두 추적 경로를 따라간다. 그것이 당신의 검증 계획이 상세하지는 않더라도 언급해야 하는 것이다. 여러 유형의 분석이 있다. 데이터 분석이 수행될 수 있고 따라서 모듈내에서 코드의 일부와 연관된 데이터, 그러한 데이터가 전개되는 어느 곳이든 그 데이터와 관련된 모든 코드, 예를 들면 전역타입의 데이터 혹은 포인터가 재시험될 필요가 있다. 어떤 요구사항이 반복되어야 하는지를 내가 어떻게 알 수 있을까? 만약 추적성 매트릭스가 수행된다면 분석되는 모든 코드를 살펴보고 요구사항으로 돌아가서 그 요구사항에 대한 시험 케이스를 발견하고 그들을 재시험한다. 당신은 어디에서 시작하고 어디에서 끝나는지를 알고 있다. 거기에는 모호함이 없고 반복가능하다.

 

리뷰 회의록을 읽어보면 우리는 다음과 같은 코멘트를 볼 수 있다. “우리는 그것을 분석했습니다.” “분석을 위해서 무엇을 했나요?” “글쎄요, Jim에게 물어봅시다.” 글쎄, 그것은 적절하지 않을 것이다.

역주) 재검증 혹은 재시험에 대해서 저자가 강조하는 부분 중 하나는 추적성에 대한 것이다. 추적성 연결이 제대로 되어 있으면 코드가 변경될 경우 그 코드의 요구사항이 무엇인지, 시험이 무엇인지를 추적성을 통해서 확인할 수 있다. 그리고 코드의 변경으로 요구사항 자체가 바뀌어야 하는지 아니면 그대로 가도 되는지를 검토하는 것이다. 코드가 변경되면 연결된 시험도 바꾸어야 할 수 있다. 위의 내용은 결국 이런 점을 풀어서 설명한 것이다.   여기서 한가지 더 챙겨볼 것은 이런 과정 자체를 검증 계획 문서(SVP)에 작성해야 한다는 것이다. 세부적인 방법을 하나하나 적어 놓을 필요는 없고 전략수준의 언급이 되어 있으면 그것으로 충분하다.

 

수정에 대한 리뷰의 정성적 평가. 리뷰는 하나의 정성적인 방법이자 개별적인 조사의 평가 그리고 관련된 문서와 함께 리뷰되는 아이템을 평가하는 것이다. 리뷰는 리뷰되는 아이템이 정확한지를 결정하기 위해 엔지니어링 경험이 필요하다. QA가 리뷰를 도와줄 것을 기대하지 마라. 그들의 감사는 기술적이지 않다. 기억하는가? QA는 당신의 프로세스를 따르는지를 보장하는 것이지 당신의 항공전자 프로젝트가 기술적으로 정확하다는 것을 보장하는 것이 아니다. 그것은 이분법이다. 당신은 양쪽을 모두 가질 수는 없다. 기술적인 리뷰와 함께 프로세스 리뷰를 수행하는 QA 담당자는 아마도 요구되는 수준만큼 엄격하게 수행하는 것이 아닐 것이다. 그래서 FAA는 DO-178B를 통해서 QA 리뷰와 감사를 프로세스 중심이 되도록 제한한다. (혹은 “장려한다”) 기술적인 리뷰는 보조적인 것이다. 하지만 리뷰는 단지 “제가 그것을 읽었습니다. 저는 서류상으로 체크를 했습니다.”를 의미하는 것이 아니다. 내가 리뷰를 했고 리뷰한 결과로는 모든 기준을 만족하고 적절하다고 생각한다는 것을 표시하기 위해 그것에 서명했다는 의미이다.

역주) 우리나라에서는 일반적으로 품질보증 담당자(QA)라고 하면 개발에 대한 모든 것을 알고 있다고 생각하는 경향이 있는 것 같다. 그래서 QA가 리뷰를 한다고 하면 당연히 기술적인 부분을 포함하는 것으로 생각한다. 현실적으로 누가 QA를 맡느냐에 따라서 그것이 가능할 수도 있다. 하지만 DO-178에서는 적어도 QA가 기술적인 부분을 리뷰한다고 생각하지 않는다. DO-178을 진행하는 경우 이 부분을 제대로 인식하고 있어야 한다.

 

당신은 무엇에 따라서 리뷰를 했는가? FAA는 당신이 DO-178B에 대해서 생각하고 그것에 따라서 리뷰를 수행하기를 원한다. 어떤 기준을 만족해야 하는가? 거기에 체크리스트가 들어오게 된다. 당신은 정말로 상세한 체크리스트가 필요하다.

 

시험은 정성적인 프로세스가 아니다. 그것은 그렇게 인식되든 아니든 분명한 프로세스이다. (일부 똑똑한 사람들은 이것에 대해서 동의하지 않을 것이다) 통과 혹은 실패를 시험한다. 시험은 반복가능하고 정량화할 수 있다. 그것은 시스템을 동작시키고 특정한 요구사항을 만족한다. 그것은 어떤 것이 동작하는지 동작하지 않는지를 결정한다. 예상 입력과 출력 그리고 프로세스를 가진다. 그것은 동일한 답에 대해서 계속해서 반복될 수 있다. 따라서 일단 코딩과 개발 프로세스가 수행되면 우리는 코드를 갖게 된다.

 

그런데 코드는 무엇인가? 소프트웨어는 무엇인가? 소스는 무엇인가? 그것은 하나의 문서이며 단지 다른 언어로 작성된 것일 뿐이다. 당신이 가진 것은 소스이고 소스가 비행기에 적재되는 것은 아니다.

 

통합시험은 컴파일을 하고 타겟 하드웨어 혹은 그 복제본을 포함하는 시험을 통해서 통합된 소프트웨어를 체크하는 것이다. 우리는 실행파일을 체크하려고 하기 때문에 현실세계를 모사하는 시험을 수행하고 결과를 얻기 위해 시험 케이스와 절차가 작성된다. 그 단계에서 당신은 코딩으로부터 컴파일 단계를 수행하고 에러를 제거하는 또 다른 전이 과정을 수행하게 된다. 희망하기로는 Polyspace와 같은 정적분석툴이 컴파일 단계를 벗어나는 실행시간 에러를 제거한 다음 당신은 시험 케이스가 정확하다는 것을 확인하고자 할 것이다. 또한 그런 다음에 당신은 결과가 정확하다는 것을 보장하기 위해 리뷰를 수행한다.

 

검증 동안에 별개로 시험할 수 없는 영역의 분석과 함께 리뷰와 시험을 수행한다. 군의 시험 표준과 달리, DO-178B는 검증 방법으로써 시연은 절대 사용하지 않는다. 덧붙여 말하자면 DO-178B는 조사에 대해서도 이야기하지 않는다. 비록 “조사”와 “리뷰”라는 단어가 때때로 교환가능하게 사용되긴 하지만 소프트웨어는 조사되는 것이 아니라 리뷰되는 것이다. 조사를 하고 있을 때에도 적절한 용어는 “리뷰된다”이다. 결국 당신은 조사없이는 리뷰를 할 수 없지만 리뷰 기준을 고려하지 않고서도 조사를 할 수 있다. 따라서 DO-178B에서는 당신의 리뷰가 항상 상세한 체크리스트에 따라서 수행하기 때문에 조사가 아니라 리뷰를 한다.

역주) 저자가 여기에서 설명하고 있는 리뷰, 조사, 시연, 시험 등은 어떤 방법을 사용하든 결국 그렇게 진행한 결과가 증빙으로 사용될 수 있느냐가 기준이 된다. DO-178에서는 조사는 조사를 하는 사람에 따라서 그 결과가 달라질 수 있고 결과에 대한 해석도 보는 사람에 따라서 달라질 수 있다고 생각하기 때문에 증빙으로 인정하지 않는다. 뒤에서 나오겠지만 시연도 마찬가지다. 이렇게 말하면 리뷰나 시험도 마찬가지가 아니냐고 할 수 있지만 거기에는 다른 전제가 있다. 바로 체크리스트와 시험절차서와 같은 공식적으로 인정되는 기준을 가지고 진행한다는 것이다. 다소 논쟁의 여지가 있는 부분이긴 하지만 저자의 설명은 이런 정도로만 이해하고 넘어가자.

 

잠시만…우리는 방금 당신이 상세한 체크리스트로 리뷰를 한다고 했는데 그럼 그런 체크리스트는 어디에서 얻는가? 그것들은 DO-178B의 뒷부분 Appendix에 있다. 맞나? 아니다. 그것들은 체크리스트가 아니다. 그것들은 단지 당신의 계획안에 고려되고 참조될 필요가 있는 각각의 라이프사이클 단계에 대한 주요 특성일 뿐이다. 그럼 당신은 어디에서 체크리스트를 얻는가? 왜 DO-178B는 체크리스트를 포함하지 않는가? 기억하자. DO-178B는 산업계에 의해서 개발되었고 그 합의는 어떤 회사도 DO-178B를 통해서 다른 이들에게 자신들의 방식을 강요하지 않는 것이었다. 그리고 당신의 체크리스트는 당신의 방식이 구체화된 것이다. 또한 소송을 좋아하는 미국에서 만약 FAA가 체크리스트를 제공했고 당신이 정확하게 그것을 만족했음에도 비행기가 추락했다면 그것은 누구의 잘못일까? 어떤 배심원은 그것이 체크리스트의 잘못이었다고 설득될 지 모른다. 그렇게 되면 그런 체크리스트를 제공한 FAA의 잘못이 될 수 있는 것이다. FAA는 두 가지 모두에서 더 영리하다. 각 회사는 자신의 개발 관행과 방식을 반영하는 자신들만의 체크리스트를 개발하거나 구매할 필요가 있다. 써드파티로부터 체크리스트를 구매할 수 있을까? 물론이다. 현재는 21세기이고 원하는 것은 거의 대부분 비용을 지불하고 구매할 수 있다. 우리는 HighRely의 체크리스트를 사용하며 따라서 그 회사의 방식으로 치우쳐 있지만 다른 회사들 역시 체크리스트를 판매한다. 어떤 소스를 사용할 지 결정하기 위해 자신만의 기준을 사용하라.

역주) DO-178을 처음 진행하는 경우 전문가의 확보와 함께 문서에 대한 템플릿을 구매하는 것이 좋다. 소위 맨땅에 헤딩하는 방식으로 진행할 수 있는 수준이 아니다. 따라서 비용을 지불하더라도 반드시 구매하기를 권장한다. 굳이 구매할 목록을 정리하자면 아래 정도가 될 것 같다.   1.     5가지 Plan 문서와 3가지 Standard 문서의 템플릿 2.     DO-178 인증 전반에 걸쳐서 사용되는 체크리스트: 요구사항(SRD, SDD), 시험에 대한 체크리스트는 필수, 나머지도 자금이 허락한다면 모두 3.     감사 단계별 체크리스트: SOI#1, 2, 3, 4 단계   참고로 이들에 대한 구매방법은 DER을 컨택하는 과정에서 국내 담당자나 DER로부터 구매가 가능할 것이다. 그리고 그렇게 구매하는 것이 DER의 감사과정에 자연스럽게 사용되면서 작성 및 활용에 도움을 받을 수도 있다.

 

DO-178B 프로세스에서 시연을 사용해 본 적이 있는가? 아닐 것이다. 왜냐하면 그것은 DO-178B가 요구하는 결정론을 만족하지 않기 때문이다. 시연을 통해서 한 사람이 관찰하는 것이 다른 사람에게도 반드시 동일한 것은 아니다. 시연은 에러가 발견되었다는 것을 객관적으로 증명하지 않으며 당신은 그 시연을 반복하고 동일한 결과를 얻었음을 확실하게 증명할 수도 없다. 거기에는 리뷰가 없고 그냥 시연일 뿐이다. 전등이 깜빡인다고 해보자. 우리는 이유를 알지 못하지만 그렇게 동작하고 있고 아마도 그 깜빡임은 우리가 조사해야 할 어떤 문제가 있다는 것을 가리킬 것이다. 시연으로는 우리는 알지 못하며 그래서 그것은 전혀 사용되지 않는다.

 

군의 프로세스인 498, 2167, 56, 55 defense와 다른 IEEE 타입 표준들은 시연을 통한 시험을 허용한다. 만약 그것이 당신의 프로세스라면 시연을 시험으로 변경해라. 당신은 입력을 가졌고 이 시연을 돌렸고 시험단계의 폭포수 라이프사이클을 거쳐오면서 결과물을 얻었다. 모든 전이점에서 단계를 리뷰하라. 일관성과 정확성을 어떻게 결정하는지를 잊지 마라. 체크리스트가 어떻게 역할을 수행하는지를 언급해라.

 

당신은 이 단계에서 리뷰, 분석 그리고 시험을 할 것이고 그것은 모두 DO-178B의 objective이다. 당신은 그 리뷰에서 정확성과 일관성을 어떻게 결정하는가?

 

실행파일도 레벨 A에 대해서 필요로 하는 소스와 바이너리와의 상호관계로 체크하게 되지만 이것은 일반적으로 시험이다. 모든 베이스라인안에서 상위레벨은 하위레벨 요구사항으로 추적가능해야 하며 해당 베이스라인은 그러한 요구사항을 만족하는지를 보장하기 위해 검증되어야 한다. 당신은 타겟상에서 하드웨어 의존성, I/O, BSP 그리고 RTOS와 같은 모든 것을 실행하며 따라서 타겟과의 호환성을 본질적으로 제공할 것이다.

 

만약 그것이 타겟상에서 실행된다면 그것은 타겟과 호환되는 것이다. 만약 시험이 타겟상에서 실행하는 것이 아니라면 당신은 그것이 타겟과 호환된다고 말할 수 있을까? 만약 당신이 시험을 하고 있고 신뢰성을 가지고 있는 상태에서 시뮬레이션상에서 그것을 수행하는 것이라면 그것은 허용된다. 당신이 보지 못하는 체크 중 하나는 타겟과의 호환성이다. 당신은 아직 그것을 체크하지 않았다. 지금까지 당신이 수행한 모든 것은 기능과 기능에 대한 요구사항을 체크한 것이다.

 

당신은 설계와 그것을 실행하는 코드로 내려가는 추적성을 가지는 요구사항을 리뷰하고 있고 그 요구사항을 검증하는 기능에 대한 시험 케이스를 리뷰하고 있다. 희망하기로는 당신은 검증을 위해 동일한 컴파일러와 타겟 바이너리를 사용하고 있고 따라서 당신은 유효한 결과를 얻게 될 것이다. 그러한 요구사항의 기능 시험 동안에 구조적 커버리지 분석툴과 함께 타겟 바이너리를 사용함으로써 시험하는 과정에서 얻어지는 구조적 커버리지의 상당 부분에 대해서 신뢰성을 얻을 수 있다. 만약 내가 그 시험에 대해서 시뮬레이터를 사용한다면 시뮬레이션 환경의 유효성을 증명하기 위해 실제 타겟상에서 대표적인 샘플을 구성하는, 아마도 5 ~ 10% 수준의 시험 일부를 반복하기를 원할 것이다. 해당 시험의 대표적인 셋이 실제로 타겟상에서도 역시 제대로 동작한다는 것을 보일 것이다. 시뮬레이션 시험에 관해서 대부분의 결함 시험 유형 처리는 시뮬레이션상에서 진행하게 되는데 타겟 환경에서는 결함 조건을 임의로 주기가 어렵고 일부 강건성 시험을 수행하기 어렵기 때문이다.

역주) 시험의 가장 이상적인 환경은 타겟이라는 것은 누구나 알고 있지만 현실적으로 타겟에서 모든 시험을 진행하기는 정말 어렵다. DO-178에서도 이런 현실을 잘 이해하고 있기 때문에 타겟과 시뮬레이션 환경의 적절한 조합을 권장하고 있다. 그럼에도 사람의 생명이 달려있는 항공기의 안전성이라는 특수성때문에 결국은 타겟에서 최종 시험 결과를 취합해서 보여주어야 한다. 정말 예외적으로 타겟에서 수행할 수 없다고 인정되는 부분을 제외하고는 나머지는 모두 타겟 시험이 기본이다. DO-178 인증을 진행하고 있다면 이 점을 명심해야 한다. 이어지는 내용에서 자세히 설명하고 있다.

 

강건성 시험과 만들기 어려운 에러/경계값 시험에 대해서는 타겟에서 시험하는 것을 피하도록 노력하라. 대부분의 타겟 환경은 소프트웨어가 요구사항을 만족하는지를 결정하기 위한 위험한 시험은 지원하지 않는 경향이 있다. 이상적으로는 그런 결함 주입과 타이밍 컨트롤을 허용하는 타겟 시험 환경을 가지고 있을 수 있다. 하지만 실제 그렇게 되는 경우는 아주 드물다. 당신은 시뮬레이션 시험 환경에서 그런 것들을 수행할 것이다. 5,000개 이상의 요구사항과 50,000라인 이상의 코드를 가진 거대한 시스템에 대한 시험은 시뮬레이션 환경과 타겟 환경 사이에 분리된 시험 케이스들을 가진다. 당신은 시뮬레이션으로 3,000개, 타겟으로 2,000개를 시험할 지도 모른다. 물론 시뮬레이션상의 3,000개에서 500 ~ 600개를 취해서 타겟상에서 다시 수행함으로써 동등성을 보여주게 된다. 예를 들면 시뮬레이션상에서 동작했던 것처럼 타겟에서도 여전히 동일하게 수행한다는 것을 보이는 것이다. 레벨 A라면 어쨌든 그런 비교를 보여야 한다. 레벨 B라면 반드시 소스와 바이너리의 비교를 보여주어야 하는 것은 아니지만 어떤 DER이든 아마도 그렇게 한 것을 보기를 원할 것이다. 왜냐하면 당신이 시험을 오로지 시뮬레이션상에서만 수행했다면 우리는 그것을 신뢰하지 않기 때문이다. 그것이 비행중에는 실행되는 것이 아니라고 하더라도 우리는 여전히 그것을 보기를 원한다. 요구사항의 대부분이 시뮬레이션상에서 검증되었다는 것을 보여주는 것은 받아들여질 만한다. 우리는 논리적이고 실용적인 사람들이다. 우리는 제대로만 만들어진다면 시뮬레이션이 어느 정도 현실 세계를 표현한다는 점을 알고 있다. 우리는 당신이 기능을 시험하고 있다는 것을 안다. 유일한 질문은 타겟이 동일하게 동작하는가 이다.

 

만약 시뮬레이터가 명령어 시뮬레이터라면, 우리는 그 명령어셋 시뮬레이터를 확인하려고 하지 않을 것이다. 그 이유는 그 명령어셋 시뮬레이터가 동일한 바이너리를 실행하기 때문에 우리가 그 명령어셋이 대표하는 타겟상에서 동일한 결과를 보여주기 때문이다. 만약 당신이 DO-254를 하고 있다면 ModelSim을 사용할 수 있다. 그것은 FPGA 동작을 모의하고 CPLD가 실제로 어떻게 동작하는지를 모의한다. 그 ModelSim은 그런 관점에서 툴인증이 필요할 수 있다. ModelSim은 현재도 존재하며 우리는 몇 년 동안 성공적으로 그것을 사용해 왔다.

 

올바르게 동작한다는 것을 내가 어떻게 알 수 있을까? 우리는 타겟에서 시험을 실행하고 그것이 동일한 결과로 동일하게 동작한다는 것을 보인다. 이제 질문은 시뮬레이션 결과를 받아들일 수 있다는 것을 보여주기 위해 몇 퍼센트의 시험을 타겟에서 재실행해야 하느냐이다. 엄격한 DER 혹은 실제 FAA 담당자가 “전부 다 실행하세요.”라고 말할 지 모른다. 하지만 그들은 우리가 비용과 일정에 대해서 걱정하는 것을 아는 합리적인 사람들이다. 따라서 당신은 대표적인 샘플만으로 실행할 수 있다. 이제 우리는 요구사항에 대해서 모두 배웠는데, 하지만 “대표적인” 샘플은 무엇일까? 거기에는 정답이 없다. 왜냐하면 그것은 협상이기 때문이다. 협상을 먼저 시작하고 동의를 얻는 것에 대해서 확인하라. 당신이 “10%”의 검증계획을 작성했고 담당자가 동의했다면 그 동의가 가리키는 것을 확인하라. 비록 그것이 30 ~ 40% 조금 넘는 정도만 실행된 어처구니없는 상황이라는 것을 우리가 알고 있다고 하더라도 10% 이상 수행할 필요가 없다.

 

당신은 FAA에 이야기하고 동의하지 않을 권리를 가지고 있다. 비록 당신이 그런 권리를 가지고 있지만 그것은 현명한 방법이 아니다. 그것은 협상에서 피하는 게 좋은 긴장을 유발한다. 기억하라. 당신은 전투에서 이길 수 있지만 전쟁에서 지게 된다. 그리고 만약 FAA 혹은 DER과 당신의 관계가 “전투”의 상태에 도달한다면 당신은 어찌되었든 지게 된다. 장기적인 관점에서의 성공은 계속되는 대결관계가 아니라 윈윈 관계를 통해서 발생하는 것이다.

 

DER 혹은 FAA와 논쟁하지 마라. 우리는 FAA 사람들이 DER에게 “우리는 당신들의 DER을 우리와 논쟁하기 위해서 승인한 게 아니라 우리를 대표해서 나가서 어떤 일을 하도록 승인한 것입니다.”라고 말하는 것을 들은 적이 있다. 기억하자. 당신의 DER들은, 심지어 당신이 그들을 고용했다고 하더라도 그들이 DER의 자격을 가지고 있는 상황에서는 언제나 FAA를 대표하고 있다. 하지만 만약 FAA와 절대 “논의”(협상)를 하지 않는 DER이 있다면 그를 해고해라. 왜냐하면 그는 아마도 당신의 이익을 대변하지 않을 것이기 때문이다. 거의 항상, 약간의 협상의 여지와 합리성을 기대할 수 있는 부분이 있다. 당신은 몇 가지(단지 몇 가지) 지점에서 도전적으로 임할 수도 있지만 그러지 않는 게 좋다. 타겟에서의 시험을 재실행하는 것은 단지 대표적인 범위에서만 재실행해라. 어느 정도? 당신의 검증 계획안에 논리적인 관점에서 대표적인 샘플을 정한 다음에 동의를 얻기 위해 협상해라.

역주) DER을 어떻게 상대해야 하는지에 대한 내용이 나온다. DER을 상대하는 것은 결국 FAA를 상대하는 것과 같다. 앞서 DER을 경찰관이자 컨설턴트로 말한 적이 있다. 딱 그 정도라고 보면 된다. 어떤 면에서는 경찰관처럼 엄격하기 때문에 그저 지적하는 대로 받아들일 수밖에 없어 보이지만 또 한편으로는 컨설턴트로써 우리에게 어떤 대안을 제시해 주기도 한다. 사실 이런 미묘한 부분을 우리가 적극적으로 활용할 수 있어야 한다. 결국 사람과의 관계이기 때문이다. 물론 말은 쉽고 행동은 어렵다. 어쨌든 저자의 설명을 이런 배경으로 받아들이자.

 

시험 objective는 소프트웨어가 그 요구사항을 만족하고 pass-fail에 의해서 수행된다는 것을 검증한다. 요구사항으로 추적가능한 여러 개의 시험 케이스와 절차를 사용해라. 만약 통과한다면 분명하게 그것은 맞는 것이다. 만약 에러가 존재한다면 그것이 구분된다는 확신을 가질 수 있을 정도로 확인하라.

 

소프트웨어 레벨로부터의 시작

시험은 구조적 커버리지 관점에서 소프트웨어가 제대로 동작하는지, 그렇지 않은지를 말하지는 않는다. 구조적 커버리지 분석이 말하는 모든 것은 완전성의 관점에서 당신이 요구사항을 얼마나 잘 작성했고 검증했는지에 대한 측정기준이다. 따라서 소프트웨어 레벨에서 시작하라. 당신은 요구사항에 대해서 강건성을 가지고 커버하는 시험을 작성했는가? 모든 동치클래스를 시험하고 정상범위 시험을 수행했는가? 시험이 모든 요구되는 수행경로(위험레벨에 따라서)를 가졌는가?

 

소프트웨어 요구사항 시험 생성은 하드웨어, 소프트웨어 시험, 소프트웨어 통합시험 및 하위레벨 요구사항 시험을 커버한다. 당신은 세 가지 종류 모두를 가져야 한다. 그것들은 각각의 상황으로 나뉠 수 있지만 현실적으로 우리는 인터페이스, 기능 요구사항 그리고 파생 요구사항을 시험할 길을 찾고 있다. 그것이 의미하는 것은 당신의 추적성을 거치는 것이다. 거기에는 그것이 기능 요구사항이든, 상위레벨 요구사항, 하위레벨 요구사항이든 혹은 파생 요구사항이든 요구사항의 모든 유형에 대한 시험이 있어야 한다. 때로는 표준이 있을 수 있는데, 당신이 그것들을 만족한다는 것을 보여줄 시험을 요구한다.

 

커버리지 분석은 소프트웨어의 어떤 기능이 시험되지 않는지를 결정한다. 만약 당신이 요구사항을 완전하게 밝히지 않았거나 완전하게 시험하지 않았다면 시험에 의해서 커버되지 않는 과도한 양의 코드를 가지게 될 것이다. 당신은 먼저 당신이 요구사항을 시험에 다 할당했는지, 실제로 시험이 그것을 모두 커버하는지를 확인하기 위해 추적성 매트릭스만을 사용해서 요구사항 커버리지 분석을 수행한다. 만약 당신이 요구사항을 개발하는 시점에 시험 케이스를 개발할 만큼 현명하다면 이것은 요구사항 프로세스의 일부로써 수행되었어야 한다. 만약 그렇게 현명하지 못하거나 혹은 시험을 준비하면서 좀 더 추가적인 비용을 낭비하는 것을 즐기는 것이라면 당신은 요구사항 리뷰 동안에 사용되기에는 너무 늦게 시험 케이스를 작성했을 것이고 따라서 그런 기능 시험 케이스들을 나중에 리뷰했을 것이다. 어떤 방법을 선택하든 당신은 시험 케이스 리뷰의 일부로써 추적성 매트릭스를 리뷰했어야하며 요구사항은 모두 커버되었어야 할 것이다. 그럼에도 불구하고 당신은 그것이 최신 업데이트된 것인지 그리고 기능 시험으로 모든 요구사항을 커버하는지를 확인하기 위해 구조적 커버리지 프로세스를 초기화하기 전에 추적성 매트릭스를 다시 리뷰하기를 원할 것이다. 당신은 “무료 점심”(역주 – 무료인 것 같지만 알고 보면 비싸게 치이는 것)을 얻으려고 노력하고 있고 그러한 기능 시험과 함께 구조적 커버리지를 얻는다.

역주) 저자의 설명이 난해하다는 느낌이다. 다 맞는 말이고 중요한 말이긴 한데 이렇게 설명해 버리면 받아들이는 입장에서는 너무 포괄적이지 않나 싶다. 나름대로 정리하자면 아래와 같다.   1.     요구사항을 작성하면서 요구사항에 대한 시험을 같이 작성하라. 2.     요구사항과 시험의 연결성은 추적성 매트릭스로 확인할 수 있어야 한다. 3.     1, 2번이 제대로 수행된다면 의미 있는 구조적 커버리지를 얻을 수 있다.   물론 이상적인 주장이다. 현실에서 그렇게 진행하기 힘들기 때문에 결국은 돈과 시간이 더 필요하게 된다. 이런 점을 이야기하고 있는 부분이다.

 

어떤 경우에는 시험이 존재하는지를 확인하라는 요구가 있는데 그것은 현대적인 툴로 쉽게 수행된다. 추적성 매트릭스에서 구멍을 찾아보고 만약 하나를 발견하면 그것은 모든 요구사항이 커버되지 않았다는 것을 의미한다. 이런 경우 어떻게 해야 할까? 그것은 간단하다. 소프트웨어 구조적 커버리지 분석을 수행하는 것이고 희망하기로는 당신은 시험을 수행하는 동안 모든 코드에 시험용 코드를 넣을 수 있을 것이다. 그 결과는 만약 커버되지 않은 곳이 있다면 어떤 코드를 봐야하는 지를 말해주거나 혹은 반드시 커버해야 하는 곳이지만 도달하지 않았기 때문에 살펴보아야 할 그런 코드를 알려주게 되고 그런 후에는 분석을 수행한다.

 

결국 당신은 커버되지 않은 코드를 발견하게 될 것이라는 점은 확실하다. 이제 무엇을 해야 할까? 먼저 그 코드가 실행되는지, 예를 들면, 동작하는 동안에 도달할 수 있는지를 결정한다. 이것은 이진 결정이다. “아마도 그럴 것이다”는 받아들여지지 않는다. 실행할 수 있거나, 이 경우 추가로 해야 할 일이 있다, 혹은 실행할 수 없다. 만약 동작하는 동안에 실행할 수 없다면 그것이 Dead Code인지 비활성화된 코드인지를 결정한다. Dead Code는 거기에 있을 이유가 없으므로 반드시 제거되어야 한다. 그걸로 끝이다. 만약 그 비실행 코드가 당신의 바이너리에 남아있어야 할 이유가 없다면 당신은 그것을 제거해야만 한다. 만약 그 코드를 비행중에 실행할 수 있다면 왜 그것이 커버되지 않았는지를 결정할 필요가 있다. 만약 시험을 통해서 그 코드에 도달할 수 있다면 그것은 실제로도 도달하는 것이다. 이전으로 돌아가서 그 코드를 포함할 수 있도록 요구사항을 추가하고 그렇게 함으로써 이전에는 실행하지 않았던 코드가 그 요구사항을 검증하면서 실행될 것이다. 만약 이 커버되지 않는 코드를 수행할 시험 시나리오를 고안해 내는 것이 사실상 불가능하다면 당신은 그것을 검증하기 위해 분석을 사용할 지 모른다. 만약 당신의 DER이 유능하고 빈틈이 없다면 당신은 그에게 그런 분석을 정당화할 필요가 있을 것이다. 그런 것과 관계없이 그 분석을 시험 결과 리포트내에 문서화해라.

역주) 복잡한 설명이 길게 나왔는데 이 부분은 결국 구조적 커버리지 분석에 대한 내용이다. 구조적 커버리지 분석은 사실 그것만 따로 분리해서 별도로 파악해야 할 부분이다. 지금 이곳의 내용이 이해되지 않더라도 좌절(?)하지 말고 계속 진도를 나가보자.

 

이제 당신은 커버되지 않은 코드를 발견했고 요구사항을 추가했고 비행 중에 실행될 수 있다는 것을 보여주는 분석이 없으며 시험케이스는 거기에 도달하지 않을 것이다. 자, 그렇다면 당신은 비활성화된 코드 혹은 Dead Code를 가지고 있으며 그 중 무엇이 되는지를 결정할 필요가 있다. Dead Code는 비행 중에 실행될 수 없는 코드이며 거기에 있을 이유가 없다. 그것은 제거되어야 한다. 절대 실행되지 않는 경우 왜 제거되어야 할까? 과연 당신은 그것이 실행되지 않을 것이라는 것을 진정으로 보장할 수 있는가? 예를 들어 실수로 쉬프트키를 건드려서 코딩 중에 잘못된 문자를 입력하는 간단한, 검출되지 않는 코딩 에러가 있다면 어떻게 될까? 불가능하다고? 절대 그렇지 않다. 경험많은 모든 프로그래머들이 알고 있는 것처럼 쉬프트를 누르는 경우는 언제든 발생할 수 있다. 그런 경우에, 그리고 다른 경우에서도 실행될 수 없는 코드가 실행되는 것이 가능하다. 검출되지 않는 포인터 에러도 항상 발생한다. 또한 실행할 수 없는 기능을 포함한 유지보수 코드는 미래의 실수에 대한 가능성을 증가시킨다. 따라서 Dead Code는 반드시 제거되어야 한다.

역주) Dead Code에 대해서는 다들 이해를 하실 것으로 생각된다. 개념 자체는 쉬운데 DO-178의 관점에서는 그것이 Dead Code라는 것을 증명할 수 있어야 하고 그렇게 증명이 되면 반드시 삭제해야 한다는 부분이 좀 어렵다. 이 역시 구조적 커버리지 분석과 함께 이해되어야 할 부분이다.

 

이제 당신은 당신의 Dead Code가 거기에 있어야 할 이유가 있기 때문에 실제로는 Dead Code가 아니라고 말하며 당신은 그 이유를 정당화하기를 원한다. 당신이 그것을 정당화할 수 있다면 그리고 DER이 승인한다면(당신은 결국 DER의 승인이 필요할 것이다 따라서 가급적 일찍 그것을 얻는 게 좋다) 이 Dead Code는 결국 Dead Code로 불리지 않으며 실제로는 “비활성화된” 것이 된다.  비활성화된 코드가 무엇인가? 동작하는 동안에는 실행되지 않는 것으로 알려진 코드지만 그것을 포함하는 정당한 이유가 존재한다. 그런 적법성은 무엇으로 구성될까? 유지보수 소프트웨어, 특정 컴파일러 입력, 방어코드, 다른 항공기 설정을 위한 코드 등이 있다. 비활성화된 코드는 반드시 리뷰되고 분석되며 당신의 시험 결과 내에서 방어되어야 하며 그런 다음에는 DER에 의해서 승인되어야 한다.

 

만약 조건 컴파일 혹은 컴파일러가 제공하는 소프트웨어 라이브러리를 사용한다면 어떻게 될까? 그것이 Dead Code 혹은 비활성화된 코드를 만들어내게 될까? 이것은 아주 중요해서 좀 더 논의할 가치가 있다. 조건 컴파일은 그 자체로 비활성화된 코드를 생성하지는 않는다. 조건 컴파일은 컴파일을 위한 소스 코드를 선별적으로 추가하거나 제외하는데 사용된다. 소스코드가 컴파일 하는데 포함되지 않으면 그것은 바이너리에 포함되지 않는다. 그리고 그것이 바이너리에 없다면 그것은 항공기 동작 중에는 말할 것도 없고 타겟에서 실행될 가능성이 없다.

 

컴파일러 제공 소프트웨어 라이브러리는 다를 수 있다. 라이브러리, 그리고 당신이 사용하는 링커에 따라서 바이너리는 사용되지 않는 혹은 참조되지 않는 함수를 포함할 지 모른다. 따라서 그것은 실행될 수 없는 구조를 포함할 수 있다. 그런 구조는 비활성화된 구조이며 그들에 대한 처리는 비활성화된 소프트웨어에 대해 위에서 설명한 대로이다.

 

당신의 코딩 표준은 Dead Code의 제거에 대한 이유와 비활성화된 코드의 포함에 대한 잠재적인 이유에 대해서 분명하게 언급해야 한다. 소프트웨어 개발자들은 거기에 따라서 훈련되어야 한다. 그들이 Dead Code는 절대 포함되어서는 안되며 비활성화된 코드는 최소화되어야 한다는 것을 알 때 그 부분이 가장 쉬워질 수 있다.

 

요구사항과 구조적 커버리지가 당신에게 필요한 전부이고 DOORS가 당신의 요구사항 관리툴이라면 그것은 모두 한 곳에 있는 것이다. 우리는 문서를 생성할 필요가 없다. 그것은 좋은 아이디어이며 시험은 완전하게 이루어 지게 된다.

역주) 저자의 마지막 설명은 다소 이상하다. DOORS의 장점을 설명하고자 한 것 같은데 DOORS를 사용한다고 문서를 만들지 않아도 된다는 보장은 그 어디에도 없다. 시험이 잘된다는 보장도 역시 없다. 아마도 관리적인 부분에서 도움을 줄 수 있다는 뉘앙스가 담긴 설명이 아닌가 생각된다.

 

시험 개발

당신은 조직차원에서 계획을 수행해 왔고 이제는 시험케이스를 개발하는 단계이다. 시험 절차 안에 시험 케이스를, 혹은 시험 케이스 안에 시험 절차를 얼마나 많이 가지고 있는가? 회사에 따라서 그 정의는 제각각이다. 일부는 10개 혹은 20개의 케이스를 가진 하나의 프로세스를 가지면서 그것을 실행할 하나의 상위절차를 가진다. 다른 사람들은 하나의 케이스를 가지고 다른 절차들에서 10번 혹은 15번을 반복한다고 말한다. 그것은 어떻게 정의하느냐의 문제이긴 하지만 구체화되어야 한다. DO-178B와 DO-254는 분명히 당신이 어떤 정의를 사용해야 하는지를 명시하지 않는다. 그저 당신의 용어를 정의하고 구체화시켜라.

 

당신은 절차를 만들고 여러 개의 케이스를 넣은 다음 시험을 초기화한다. 이상적으로는 당신은 요구사항 리뷰 프로세스의 일부로써, 그리고 소프트웨어를 가지기 아주 오래 전에 기능 시험 케이스를 개발했을 것이다. 우리는 계속해서 단위 시험을 수행하게 되는데 단위 시험으로 신뢰를 얻을 수 있는가? 우리는 계속해서 “아니다”라고 말하고 있지만 당신은 일부 모듈 시험, 일부 통합 시험, 일부 ATP 시험 그리고 일부 항공기 시험을 수행하기 위한 전략을 개발해 올 수 있었다. 이러한 모든 것이 합쳐지면 모든 시험에 대한 충분한 커버리지를 제공한다. 개발자에 의해서 소프트웨어 모듈(파일에 대한 근사한 이름인)에 대해서 하위 레벨 수준의 단위 시험이 수행될 때 우리는 그것을 단위 시험이라고 부르고 그런 시험은 비공식적인 것이다. 모듈의 하위 레벨 시험이 독립적으로 수행되면서 그에 대한 인증관점의 신뢰를 확보하려고 하는 경우 우리는 그것을 모듈 시험이라고 부른다.

 

인증의 신뢰를 위한 모듈 시험은 정당화될 수 있고 때로는 바람직한 것이다. 비공식적인 코드 품질 개선 프로세스의 일부로써 개발자에 의해서 수행되는 단위 시험 또한 바람직하다. 단지 그런 단위 시험을 DO-178B 시험 기준에 대한 신뢰를 위해서 하지는 말아라. 그것이 당신의 전략이다. 당신은 요구사항이 커버되고 구조적 커버리지 분석이 그것을 증명하게 만들어야 한다. 한 가지 받아들여질 수 없는 것은 하위 단위 레벨에서의 중요한 구조적 커버리지인데 그것은 요구사항으로부터 수행되는 것이 아니며 비동기화된 시스템 접근이기 때문이다. 구조적 커버리지 분석의 목적은 작성되지 않은 요구사항 혹은 실행에서의 Dead Code를 식별하는 것이다. 그것이 기준이다.

역주) 소프트웨어 개발에서 시험의 중요성은 두 말할 필요가 없다. 당연히 DO-178에서도 시험이 큰 비중을 차지하는데 문제는 DO-178 관점에서 바라보는 시험의 종류를 제대로 이해하고 접근할 필요가 있다는 점이다. 그저 시험을 많이 하고 꼼꼼하게 하는 게 중요한 것이 아니라 시험의 의도와 목적에 맞게 적절한 시점에서 적절한 결과를 얻어 내는 것이 중요하다. 그리고 그것이 DO-178 인증을 위한 증빙이 된다. 이런 관점에서 모듈 시험, 단위 시험, 구조적 커버리지 분석 등을 DO-178에서 어떻게 바라보는지를 명확하게 이해해야 한다.

 

정상 범위 시험은 입력 범위, 정상적인 이벤트 인터럽트 그리고 정상적인 상태 전이에 대한 것이다. 우리가 정상 범위 시험에 대해서 이야기할 때 그것은 정상적인 조건과 입력을 포함하게 되는데 사람들은 종종 그것을 무시한다. 일반적으로 그들은 정상적인 조건과 입력은 당연한 것으로 받아들여서 그저 요구사항 작성을 지연시키는 것이라고 생각한다. 우리가 언제나 요구사항에 대해서 이야기하지만 정상적인 이벤트 인터럽트를 요구사항으로 받아들이는 이유는 그것들이 파생요구사항이기 때문이다. 이들 인터럽트는 당신의 설계 – 아키텍처의 하나의 조건 – 에 의해서 만들어지는 것이다.

 

모든 파생요구사항에 대한 시험이 존재해야 한다. 당신이 그것을 모두 가지고 있다는 것을 확인하기 위해 파생요구사항이 당신의 요구사항 추적성으로 피드백되고 요구사항 자체로도 피드백된다는 것을 밝혀야 한다. 이전에 기술된 프로세스를 커버하는 당신의 요구사항은 당신이 그것들을 모두 시험할 것을 보장할 것이다.

 

상태 전이. 만약 상태 다이어그램이 구조의 일부분 혹은 어딘가에 있는 하나의 정의라면 DER은 엔지니어의 한 사람으로써 어떤 상태에서 다른 상태로, 또 다른 상태로의 전이에 대한 시험을 보는 것을 기대하게 된다. 그런 상태 전이를 모두 실행하라. 당신은 정상적인 로직 프로세스는 대부분 커버하게 된다. 그리고 거의 매번 이들 상태 전이의 대부분은 단지 상세한 요구사항으로부터 기능 요구사항을 작성하는 것으로 커버된다. 단지 당신이 가능한 모든 상태전이에 대해서 완전한 커버리지를 달성했는지를 확인하라.

 

우리는 상위레벨 시험을 하는 것에 대해서 이야기하지만 단위 시험에 대해서는 이야기하지 않는다. 결과적으로 당신이 시험하기를 원하는 한 가지는 초기값에서 최종값까지 거치게 되는 카운터를 가진 루프문과 같은 것이다. 만약 카운터가 잘못 동작하거나 결과적으로 최종값이 요구되는 값과 같지 않다면 무슨 일이 발생하게 될까? 당신은 잠재적으로 그 지점에 이르게 되는 어떤 종류의 시험을 만들어낼 필요가 있다. 문제가 되는 루프가 있다는 것을 알고 있는지 확인하기 위해 모든 코드를 체크해야 하는가? 단지 한 가지 시험이 필요하다. 그 카운터에 대한 경계값 시험이 그것이다.

 

에러가 있고 포인터가 아무데도 가리키지 않는다면 무슨 일이 발생하는가? 그런 종류의 에러에 대한 시험이 있어야 한다. 많은 사람들은 지속적으로 메모리를 체크하는 것이라든지 혹은 흐름을 체크하는 와치독 타이머와 같은, 실제로 동작하는 빌트인 테스트를 가지고 있다고 말한다. 그런 식의 문제가 발생하면 리셋을 할 것이다. 그것은 유효한 답변이다.

 

만약 For 루프(그 작은 카운터)가 잘못되면 무슨 일이 발생하는지, 그 코드가 어떻게 영향을 받는지에 대한 부분은 사실 그 상황이 발생하면 모든 것이 뒤엉켜버리고 몇 밀리세컨드 후에는 재시작이 되기 때문에 우리는 그런 부분은 체크하지 않을 것이다. 그것은 유효한 답변이지만 당신은 그것을 시험하고 리셋이 발생하는 것을 볼 필요가 있다. 이런 시험을 잊어버리는 이유는 그것들이 당신의 요구사항에 존재하지 않기 때문이다. 그것들은 일반적으로는 설계로부터 나오는 파생 요구사항이다. 만약 그것들이 추적성 매트릭스에 존재한다면 당신은 분명히 그것들에 대해서 시험을 작성할 것이다.

 

만약 당신이 Integrity-178B와 같은 현대적인 RTOS를 사용한다면 타이밍 침범을 막기 위한 시간 파티션 특성을 포함하기를 원할 것이다. 그리고 거의 항상 마이크로프로세서나 혹은 주어진 시간 할당을 넘어서는 프로세스가 멈추는 것까지도 체크하는 와치독 타이머 기능을 사용하기를 원할 것이다. 대부분의 BSP는 프로세서가 규칙적으로 감소하고 모니터되는 하나의 레지스터내에 카운터를 유지하는 와치독 타이머를 지원한다. 당신의 BSP와 어플리케이션 소프트웨어는 규칙적으로 그것을 탐지해야 하며, 그것은 크고 0이 아닌 값에 리셋이 되는 것을 의미한다. 그런 다음, 만약 와치독 타이머가 0으로 감소되어 리셋을 일으킨다면 그것이 의미하는 것은 더 높은 값을 탐지하도록 할당된 태스크가 프로세싱 스트림상에서의 어딘가에서 지연이나 정지로 인해서 실행될 수 없었기 때문에 정지된다는 것을 의미한다. 짠! 성공적인 와치독 타이머 동작이다.

역주) 운영체제도 결국은 소프트웨어이다. 그렇다면 민간항공기에 탑재되어 있는 운영체제는 결국 DO-178 인증을 받았다는 의미가 된다. 복잡하고 난해한 운영체제, 특히나 RTOS가 어떻게 DO-178 인증을 받았을 지 의심스럽기는 하지만(?) 그런 RTOS가 실제로 존재한다. 저자가 이야기한 Integrity-178B도 그렇고 VxWorks653이라는 RTOS는 파티션을 지원하면서 멀티OS를 구동하는 놀라운 능력을 보유하고 있기도 하다. 참고로 한컴MDS에서 만든 NEOS라고, 국내 최초로 DO-178 인증 준용을 받은 제품도 있다.

 

예외 처리. 운영체제는 예외처리 핸들러를 가지고 있지만 당신이 어떤 RTOS를 사용하느냐에 따라서, 그것이 동작할 것이라고 가정해서는 안된다. 만약 당신이 인증 받은 상용 RTOS를 가지고 있지 않다면 당신은 자신만의 예외처리 핸들러를 작성하기를 원할지 모른다. 비교 오류와 같은 에러가 있다면 우리는 그것에 대한 로그를 남기고 이전 상태로 되돌아 간다. 당신은 그것에 대한 요구사항을 가지고 있지 않을 수도 있다. 그것은 파생 요구사항이었을 지도 모른다. 그것이 실제로 그런 식으로 나타나는지 확인하고 만약 당신이 그런 종류의 코드를 작성했다면 구조적 커버리지 분석을 하면서 그것을 발견해야 하고 그 코드가 제대로 동작하는지를 확인해야 한다. 만약 그렇다면 요구사항 또한 존재해야 한다.

 

성능 시험과 분석. 이것은 놀라울 수 있다. 특정 사이클내에서 할당되는 경우에 실행되는 요구사항이 있다고 하자. 우리는 폴링 루프를 포함하는 포그라운드 및 백그라운드 아키텍처를 구성한다. 그것은 30밀리세컨드 사이클이고 20밀리세컨드내에서 실행된다. 10밀리세컨드가 백그라운드 비트개발을 위해 남겨진다. 그것이 임베디드 개발 제품에 대한 공통된 아키텍처이다. 그 요구사항은 30밀리세컨드 프레임시간으로 20밀리세컨드 내에 실행하는 것이다. 우리는 가장 좋은 상황과 가장 안 좋은 상황을 평가할 필요가 있다. 이것은 강건성 시험의 일부이다. 기억하자. 강건성 시험의 내부적인 정의는 “소프트웨어를 부수는” 것이고 따라서 어서 그것을 부수려고 시도해보라. 모든 입력과 출력으로 시스템을 완전히 로드하고 그것이 항상 20밀리세컨드내에 실행되는지 확인하라.

 

만약 시간을 넘게 되면 무슨 일이 생기는가? 사람들은 때때로 성능 시험을 잊어버린다. Software Accomplishment Summary에서 DO-178B는 당신이 그것을 아키텍처 특성으로 할당한다고 말한다. 그것은 무엇을 뜻하는가? 그 코드는 얼마나 빨리 동작하는가? 얼마나 많은 메모리를 사용하는가? 얼마나 많은 용량의 스택이 사용되고 그것이 오버플로우되는 것을 보여주기 위해 어떻게 시험되는가? 그것이 실증적으로 시험되었는가? 소프트웨어상에서 타이밍 순서가 결정되는 곳을 어떻게 결정했는가?

 

시험은 때때로 요구사항의 일부가 아니기 때문에 개발되지 않는다. 제품이 허용가능한 신뢰성을 가지고 있는지를 보는 방안인 스트레스 시험을 정의하는 노골적인 요구사항은 없다. 그것은 DO-178B에서 요구되는 것이 아니다. 스트레스 시험은 정상적으로 보다는 몇 배나 더 어렵게 동작하도록 하기 위해 모든 것을 하는 또 다른 프로세스이다. 만약 그것이 35밀리세컨드 프레임 시간이라면 우리는 35밀리세컨드를 위한 데이터로 과부하를 걸고 수천 주기 이상으로 그것을 실행한다. 우리는 가장 최악의 수준으로 스트레스를 주려고 하며 그것이 실제로 초과하는지를 본다.

 

그 아이디어는 만약 당신이 그 구조를 가지고 있다면 당신은 35밀리세컨드 주기, 포그라운드 및 백그라운드 루프를 가지고 있으며 그것은 종종 35밀리세컨드를 초과하게 된다는 것이다. 우리는 그것이 한 번은 발생할 것을 안다. 두 번 발생할 수도 있을 것이다. 많은 주기에서 이것이 일어나도록 하게 되면 어떻게 될까? 그렇게 되면 완전히 망가질 때까지 잡아내지 못할 정도로 초과하게 되는 것일까? 그것이 그 아이디어이고 대부분의 아키텍처는 결국 그들이 잡아내지 않는 정도까지 초과하게 된다.

 

우리는 항상 파괴적인 시험은 무시한다. 클럭속도를 높이고, 내부로 들어가서 핀을 뽑고, 트레이스를 제거한다. 당신은 그것을 에뮬레이션에서 파괴적이지 않게 할 수 있다. 만약 당신이 레벨 A이고 더 높은 수준의 엄격함을 원한다면 필요한 것은 아니지만 약간의 파괴적인 시험이 있을 수 있다. 대부분의 개발자들은 프로젝트의 종료가 가까워지면서 실험실내에 15개에서 20개의 카드를 가지고 있게 된다. 그리고 개발에서 그런 것처럼 여러 단계를 거치면서 7개 또는 8개의 LRU를 가지게 된다. 당신은 제품이 인증받은 후에 발생할 수도 있는 문제점을 확인하기 위해 아마도 한 개를 못쓰게 만들 만한 여유가 있을 것이다. 사실 그들은 선반으로 올라가서는 절대 다시 보지 않을 것들이다. 따라서 스트레스 시험을 하고 만약 당신이 원한다면 몇 개를 망가뜨려라. 다만 기억할 것은 만약 당신이 같은 것을 달성하기 위해서 분석을 사용할 수 있다면 그것이 무조건 필요한 것은 아니라는 점이다. CPU의 핀을 뽑고 무슨 일이 발생하는지를 살펴본다는 것은 재미있는 시도가 아닐 수 없다. 당신의 소프트웨어는 그것을 어떻게 다루는가? 그것이 원자폭탄을 떨어뜨리는가?

 

우리는 주요 폭격기 프로젝트에 대해서 작업한 적이 있는데 그런 종류의 방어코드를 작성한 적이 있다. 우리는 2성 장군이 시뮬레이터에 앉아서 비행을 하고 폭탄을 떨어뜨리는 시험을 했다. 우리는 화면을 담당하고 있었고 완벽하게 진행했다. 거대한 스크린이 그 행위를 보여주었다. 장군은 트랙을 따라 비행하면서 폭탄을 투하하고 있었는데 아주 잘 진행되었다. “좋습니다. 한 번 더 해보죠.” 그래서 그는 우리가 지켜보는 가운데 한 번 더 폭탄을 투하했다. “이런! 이것이 진짜 동작하다니!” 장군은 그것을 대단히 현실감있게 하고 싶었기 때문에 우리는 버섯구름을 볼 것이라고 예상했다. 그런데 갑자기 “밀러 타임!”이라고 쓰여진 배너가 하늘위에 펄럭이고 있었다. 음…. 장군은 그것을 좋아하지 않았다. 우리는 어떤 엔지니어가 그 일에 책임이 있는지 알지 못하지만 우리는 납득할 만한 좋은 아이디어를 가진 것이다. 당신은 재미있게 할 수 있지만 당신의 시험 케이스에 넣지는 말아라.

역주) 일반적인 시험이라면 기능 시험을 말한다. 개발자들은 보통 기능 시험 수준까지는 수행하게 된다. 자신이 제대로 구현한 것인지를 확인해야 하기 때문이다. 하지만 그 이상으로 예외적인 부분, 범위를 벗어나는 부분 등의 더 꼼꼼한 시험까지는 못하는 경우가 많다. 시간이 부족하고 거기까지 신경쓰기가 힘들기 때문이다. 하지만 DO-178에서는 그런 부분까지 확실하게 챙겨야 한다. 그렇지 않으면 절대 DO-178 인증을 받을 수 없다. 현재 저자는 전체적으로 이것을 중심으로 이야기하고 있다.

 

시험 케이스 레벨

유닛으로 정의되는 것이 무엇인지 기억하는가? 만약 당신이 CSCI, CSC 그리고 CSU의 MIL-STD-498 방법론을 사용한다면 당신은 유닛을 정의한 것이다. CSCI를 시험하라. CSC를 시험하라. 당신은 아마도 CSC 레벨에서 요구사항 시험을 수행할 것이다. 따라서 모든 CSC 혹은 모든 CSCI에 대해서 그 레벨의 요구사항 시험을 수행하고 그 레벨의 구조적 커버리지 분석 시험을 수행하고 그에 대한 신뢰를 확보하라. 그런 다음 당신은 더 큰 퍼즐의 일부에 대해서 논쟁할 수 있다. 전체 시스템을 만들어야 하는 것은 아니다.

 

우리는 구조적 커버리지 시험을 수행하고 바로 거기에서 요구사항 시험을 하는 것을 선호한다. 모든 코드를 가지고 컴파일하고 통합하고 모든 시험 코드를 만든 후에 모든 시험을 한 번에 수행한다. 하지만 그것은 축복받은 상황에서나 가능한 일이고 현실 세계에서는 그런 일이 아주 드물게 나타난다. 대부분의 경우에 당신은 상당양의 CSC 유형의 통합을 하고 큰 응집력을 가진 함수들을 함께 모은다. 이 레벨에서는 시험 시뮬레이터가 허용된다. 마침내 당신이 전체 시스템에 도달할 때 당신은 아마도 타겟상에서 그것을 하기를 원할 것이다. 만약 상위레벨 시험을 계속할 수 있다면 많은 장점이 있다.

 

시험 소프트웨어 기능 요구사항

대부분의 기능 요구사항은 시험을 통해서 더 많은 커버리지를 제공하고 더 현실적인 검증을 가능하게 하는 시스템으로써 시험되어야 한다. 만약 당신이 전체 시스템을 가질 수 있다면 모두 합쳐서 시험 코드를 만들어라. 그것은 당신이 미리 계획해 왔을 때에나 종종 가능한 이상적인 케이스이다. 충분한 실행 속도가 있다면 환상적이다. 단지 전원을 켜는 것 만으로도 많은 부분을 시험하게 된다. 당신은 이런 이야기를 들어 봤을 텐데 그것은 사실이다.

 

불리한 점

하위레벨 시험은 시스템 레벨에서 셋업하기가 어렵다. 현실에서는 특히 시험 코드가 추가되는 경우에는 일반적으로 모든 케이스에 대해서 메모리와 처리 속도가 충분하지 않다. 모든 시험은 실제 하드웨어에서는 셋업될 수 없고 LRU 내부로 접근할 수도 없을 것이다. CPU 내부를 엿보고 무슨 일이 발생하는지를 보기 위한 툴셋을 항상 가질 수는 없다. 더 상위레벨에서 전체적인 시험을 하는 것은 더 많은 노력이 들긴 하지만 그만한 가치는 있을 것이다. 일단 그 프로세스는 당신이 재시험을 할 때 셋업되면 그것으로 반복하기가 쉽고 제품의 수명 기간 동안 본전을 뽑게 될 것이다.

 

시험 결과는 더 많은 분석을 요구한다. 무엇이 잘못되었을까? 만약 당신이 더 높은 레벨에 있고 잘못된 답을 얻는다면 코드의 어디에서 그것이 발생한 것일까? 그것은 구조적 커버리지를 결정할 툴을 필요로 하는 어려운 분석이다.

 

우리가 작업했던 한 시스템은 연결된 4개의 DSP와 2개의 Power PC를 가졌었다. 우리는 그것을 하나의 시스템으로 합칠 수 없었으며 구조적 커버리지 분석을 할 수 없었다. 그래서 우리는 한 번에 하나의 프로세스를 수행했다. 음, DSP는 독특한 놈이다. 우리는 전체 DSP를 수행할 수 없었으며 단지 특정 기능에 대해서 수행할 수 있었다. 그것 역시 만족스럽지 않았다. 우리는 결국 한 번에 하나의 모듈에 대해서 수행했고 수백번의 구조적 커버리지 분석을 실행해야 했다.

역주) 계속해서 이런 저런 사례를 포함해서 저자의 설명이 이어지고 있다. 사실 하나 하나 풀어서 설명할 수 있으면 좋겠지만 역자의 능력이 부족하기도 하고 이런 부분은 실제 진행하면서 파악해야 할 부분이다. 여기서 이야기하는 부분을 막연하게나마 이해하는 정도로 넘어가고 실전에 들어갔을 때 현장에서 부딪히는 이슈들을 통해서 DER 및 관련된 담당자들의 도움을 받아가면서 하나하나 실질적인 부분을 이해하는 형태로 진행하시기를 추천드린다.

 

만약 당신이 시험을 자동화하지 않으면 당신은 최악의 상황으로 들어가는 것이다. DSP 코드로 시험코드를 작성하고 DSP상에서 구조적 커버리지를 수행하는 것이 가능한 툴이 아직은 그렇게 많지 않다. 우리는 우리 자신의 툴이 동작하는 지를 확인하기 위해 우리 자신의 코드를 작성해야 했다. 3개월 후에 우리는 마침내 하나의 툴을 가지게 되었다. 이제 우리는 DSP에 대해서 수백번을 시험했고 매번 일부 답을 얻었다. 우리는 그런 부분적인 답을 모두 모으고 통합하며 그래서 어떤 코드가 실제로 동작했고 어떤 시험이 무슨 코드를 실행했는지를 알 수 있는 툴을 만들어야 했다. 그것이 현실이다. 만약 당신이 더 상위레벨 시험을 수행할 수 있다면 아주 좋은 일이지만 현실은 셋업하기도 커버리지 분석을 수행하기도 어렵다. 우리는 항공전자분야의 선배 엔지니어이자 DER로서 우리가 제대로 했다는 것을 FAA에게 확신시켜줄 수 있었다는 점이 기쁘다.

 

만약 요구사항이 매우 상세한 레벨로 작성된다면 그것은 매우 특별한 것이고 당신은 정확하게 무엇을 시험해야 하는지 알고 있는 것이다. 그것은 제대로 제한되고 구분되는 것이다. 만약 단지 4개의 개발 시스템을 가지고 있고 우리가 상위레벨에서 작업하고 있다면 그것은 네 사람이 시험을 하고 있다는 의미이다. 거기에는 오직 4개의 시스템이 있지만 하나가 하위레벨이라면 그들은 시뮬레이션 시스템, PC 혹은 워크스테이션에 앉을 수 있으며 많은 시험을 수행할 수 있다. 그것이 하위레벨에서 그것을 수행하는 힘이다. 당신은 100만달러의 자동화 시스템 시험에 대한 셋업을 개발할 필요가 없다. 왜냐하면 그것은 모두 상위레벨 즉, 시스템 레벨에서 수행되기 때문이다. 당신은 시험 코드의 주입과 디버깅을 위해 시뮬레이션을 만들 수 있다.

 

전략

당신의 검증 시험 전략은 검증 계획에 정의되어야 한다. 시험의 각 레벨을 어디에서 수행할 것인지가 명시되어야 한다.  서로 다른 레벨로 수행하는 이유가 있으며 당신은 그것을 작성할 필요가 있다. 당신은 알고리즘 실패를 체크할 것이기 때문에 하위레벨 시험을 수행한다. 그것은 아무렇게나 해서는 안된다. 요약하면 DO-178B하에서의 시험 단계는 간단치가 않다. 개발 예산의 약 40 ~ 50%가 시험, 검증 그리고 분석에 사용된다. 만약 그것이 25% 이하로 떨어질 수 있다면 그것은 세계적인 수준이다.

 

분석

시험 컨텐츠가 복잡할 때는 여러가지 의미가 있을 수 있다. 분석이 사용될 때는 그저 그것을 분석했다고 말하지 말고 그것이 의미하는 것이 무엇인지, 당신이 예상한 것은 무엇인지, 그리고 무엇을 발견했는지를 말하라. 그것은 반복할 수 있어야 한다. 만약 당신의 파트너가 완전히 동일한 분석을 사용한다면 반드시 동일한 결과를 얻어야 한다.

 

시험을 위한 많은 전략들이 있다. 결정은 개발 유형에 달려있다. 만약 그것이 운영체제라면 우리는 많은 하위레벨 시험을 수행한다. 만약 그것이 단지 인터페이스 혹은 BSP라면 우리는 많은 하위레벨 시험을 수행할 것이다. 만약 그것이 비행 관리 시스템을 만드는 것이라면 당신은 많은 상위레벨 시험을 원할 것이다.

 

이것을 하는데 올바른 하나의 방법이 있는 것은 아니다. 검증에 대해서 중요한 점은 만약 당신이 수행한 것이 정확하다는 것을 믿는다면 그것은 DO-178B의 의도에 결정론적으로 그리고 일관성을 가지고 만족하며 그런 다음에는 그러한 믿음을 준비를 하고 당신의 주장을 하는 것이다. 그것을 작성하라. 누군가 당신에게 불필요한 무언가를 하도록 함으로써 당신을 방해하지 못하게 하라.