18. 구조적 커버리지 분석

 

구조적 커버리지 분석은 광범위한 요구사항 시험을 포함해서 검증이 모든 objective를 만족하는 정도를 다룬다. 그것은 또한 코드, 코딩 작성자 그리고 시험자에 관한 어떤 특성을 구분한다. 코딩 과정에서의 Dead Code와 같은 것을 발견하는 특성도 있다. Dead Code는 어떤 것이 시험되든 코드의 어떤 부분도 얻을 수 없기 때문에 명확하다. 그것이 작성되었기 때문에 아마도 한번은 사용되었겠지만 그것에 관한 수정이 발생하면 더 이상 필요없게 되고 사용되지도 않는다는 것을 당신은 깨닫게 된다. 더 많은 기능들이 소프트웨어 일부로 불필요하게 추가되었고 따라서 그것은 이런 방식으로 구분된다.

 

구조적 커버리지 시험 – 1   소프트웨어 에러에 대한 최종 방어 지금껏 나온 것들 중에 가장 지루하고 비싼 보호 형태 구조적 커버리지는 “시험”이 아닌 “측정” “커버리지”: objective를 만족하는 검증활동의 영역   DO-178B는 두 가지 유형의 커버리지를 요구한다 요구사항 커버리지 소프트웨어 구조적 커버리지   왜 구조적 커버리지인가? 코드가 위험레벨에서 요구하는 정도로 커버되었다는 것을 증명 의도되지 않은 기능이 존재하지 않는다는 것을 증명 요구사항 기반 시험의 완전성을 확립

 

역주) 앞에서 계속 이야기하고 있는 내용이 반복되고 있다. 그 만큼 DO-178에서는 커버리지 시험이 중요하다는 뜻이다. 따라서 그 개념을 정확하게 이해한 후에 실전에서 적용하는 것이 중요하다. 하지만 저자의 말처럼 정말 지루할 정도로 시간이 오래 걸리고 리소스가 많이 투입되는 작업이기 때문에 결과적으로 그에 따른 비용이 많이 들 수밖에 없다. (참고 포스팅: 4. DO-178과 커버리지 분석(Coverage Analysis))

 

구조적 커버리지 분석은 레벨 D에 대해서는 수행하지 않지만 레벨 C와 그 이상에서는 수행할 부분이 더 늘어난다. 당신은 코딩담당자들이 다소 지나치게 열성적이어서 기능에 대한 요구사항이 없이도 기능을 추가하기 시작한 것을 발견할 지 모른다. 그 사람은 “2년내에 고객이 이것을 원할 것이기 때문에 그것은 괜찮을 겁니다.”라고 말한다. 그런 것들은 시험되지 않을 것이며 커버되지도 않을 것이다.

 

이런 것들이 구조적 커버리지를 수행하는 몇 가지 핵심 이유들이다. 레벨 A 소프트웨어의 경우 소스레벨만으로는 구조적 커버리지를 수행할 수 없는 추가적인 요구사항이 있다. 소스와 오브젝트 사이의 관계에 대해서도 증명해야 하는데 그것은 당신이 레벨 A에 대해서 수행하는 다른 모든 것에 더해서 오브젝트 코드가 컴파일러가 추가하는 것으로 인해서 명확하지 않은 추가적인 수행경로를 포함하지 않는다는 것을 의미한다. 그것이 레벨 A에서 컴파일러 최적화를 사용하는 것이 문제가 될 수 있는 이유이자 그러한 최적화를 유효하게 하기 위해 추가적인 작업이 더해지는 이유이다.

역주) DO-178의 커버리지 시험에서 가장 난해한 부분이 바로 레벨 A, 그 중에서도 오브젝트 파일에 대한 검증이다. 위의 설명은 그 부분에 대한 내용인데 핵심은 컴파일러가 컴파일 과정에서 소스코드의 일부를 수정하는 경우가 있다는 점이다. 기본적으로 컴파일러는 소스와 오브젝트가 1:1로 매칭되도록 컴파일된다. 그런데 컴파일러에 최적화라는 기술이 적용되면서 아주 극소수의 소스가 기존 코드와 다르게 바뀌어서 오브젝트로 출력될 수 있는 것이다. 문제는 그렇게 변경되는 것이 어디이고 어떻게 바뀌는지를 컴파일러 외에는 아무도 모른다는 것이다. 항공기에 탑재되는 소프트웨어의 안전성이라는 관점에서는 이것은 위험한 일이다. 그래서 그 변경이 안전하다는 것을 보여야 한다. 실전에서는 아예 최적화 옵션을 사용하지 말라고 하는 경우도 있다. 가능하면 1:1로 그대로 컴파일하라는 말이다. 물론 그럼에도 컴파일된 오브젝트가 소스와 1:1로 매칭된다는 증거를 보여야 한다. (참고 포스팅: 10. DO-178과 커버리지 분석 – Source Code to Object Code Traceability (1))

 

구조적 커버리지 시험 – 2   구조적 커버리지의 의도는:   코드 구조가 적용 가능한 소프트웨어 레벨에 대해서 필요한 정도로 검증되었다는 것을 증명 의도되지 않은 기능은 존재하지 않는다는 증명을 지원하는 방법을 제공 요구사항 기반 시험의 완전성을 확립. 구조적 커버리지 분석은 요구사항 기반 시험이 코드를 실행한다는 것을 보장하는 방법을 제공 (DO-248A v14 FAA National Software Conference의 FAQ #43 – 2001년 6월 6일)   구조적 커버리지는 화이트박스 시험이다 즉, 코드를 오픈함   레벨 C & 그 이상에 대해서 필요한 것: 레벨 C: statement 커버리지 레벨 B: statement & decision-condition 커버리지 레벨 A: statement, decision-condition, 그리고 modified condition decision 커버리지(MCDC)   소스코드 혹은 바이너리?

 

컴파일러와 소스코드에서 산출물의 조합 때문에 소프트웨어의 추가적인 요소들이 컴파일러에 의해서 주입될 수 있다. 따라서 당신은 그것들이 유효하다는 것을 증명해야 한다. 그런 요소들이 있다면 당신은 그러한 추가적인 오브젝트 레벨 일부를 커버하기 위한 시험을 더 추가한다. 오브젝트 레벨에서 사용 가능한 툴이 거의 없기 때문에 그런 것을 진행하는 것이 더 어렵다. VectorCAST와 같은 대부분의 커버리지 분석툴은 커버리지 분석 결과에 대한 강조된 red, green 그리고 blue 색상의 화면뷰나 출력물을 제공한다. 하지만 그들은 오브젝트 레벨에서는 그것을 지원하지 않는다. 따라서 레벨 A에는 추가적인 도전이 있다.

역주) VectorCAST의 실제 화면을 보면 아래와 같은 형태이다. 오른쪽에 녹색, 붉은색의 글자들이 보일 것이다. 소스파일에 대한 분석결과를 다른 색으로 추가해서 보여주고 있다. 최소한 소스레벨은 이렇게 툴에서 지원할 가능성이 있지만 오브젝트 레벨에서는 이런 부분을 지원하는 툴이 거의 없다. (외국에 있다고는 하는데 역자도 직접 확인한 적은 없다.)

 

보통 구조적 커버리지 시험은 화이트박스 레벨에서 수행되는데 도달하기 어려운 구조에 대해서는 모듈 레벨의 아랫단까지 내려가기도 한다. 당신도 알다시피 레벨 C는 모든 statement를 레벨 B는 모든 decision을 요구한다. 레벨 A는 modified condition decision뿐만 아니라 decision, conditions 그리고 statements를 요구한다. 그리고 소스코드와 바이너리의 상호관계는 레벨 A 소프트웨어만을 위한 것이다. 따라서 소스와 바이너리의 연관성에 대한 요구사항은 레벨 A에만 적용한다.

 

statement 커버리지   각각의 소스 statement가 커버되고 기대한대로 동작하는 것을 증명   “statement”란 무엇인가? 답: 가장 작은 독립요소, 예를 들면 코드의 한 라인     decision condition 커버리지   각각의 decision이 모든 가능한 결과를 가지는 것을 증명 또한 “branch” 시험으로도 알려짐

 

역주) DO-178의 커버리지 시험에 대해서 이야기하다 보니 흔히 접하지 못하는 용어들이 많이 나오고 있다. 번역을 위해서 명쾌한 용어를 사용하고 싶지만 막상 적절한 용어를 찾지 못하다 보니 번역이 많이 어색하다. 이후 저자의 설명이 중간중간 있긴 하겠지만 일단 여기서 그런 용어들을 간단하게 정리하고 갈까 한다.   1.     statement 소스코드 한 줄을 말하는 것으로 이해하면 가장 쉽다. 따라서 statement 커버리지라는 것은 소스코드 한 줄 한 줄을 실행하는지를 체크하는 것이다. 100%가 되어야 한다는 것은 모든 소스코드 라인을 실행해야 한다는 말이다.   2.     decision condition 조건문이라고 생각하면 된다. 조건에 따라서 실행되는 부분이 있고 실행 안 되는 부분도 있을 것이다. 다만 조건절이 복잡한 경우 조건절에서 나올 수 있는 모든 케이스를 확인하지는 않는다는 점에서 MCDC와 차이가 있다. MCDC보다 덜 엄격하다고 이해하면 될 것이다.   3.     modified condition decision(MCDC) 복잡한 조건문이 있을 경우 조건절에서 나올 수 있는 모든 케이스를 확인하게 된다. decision condition보다 더 엄격한 체크가 된다. 당연히 statement보다도 훨씬 더 엄격하다.   4.     source to binary correlation 저자의 설명 중에 source to binary requirement라는 말이 나오는데 같은 말이다. 공식적으로 정해진 용어가 없다 보니 쓰는 곳마다 조금씩 차이를 보이고 있다. 참고로 FAA에서 발간한 관련 자료 중에는 아래와 같이 source to object code traceability라고 하는 부분도 볼 수 있다. 사실 개발자들이 바이너리, 오브젝트 코드, 오브젝트 파일 등과 같이 동일한 대상을 여러 가지 용어로 사용하는 것과 같은 분위기라고 보면 된다. (참고 포스팅: 10. DO-178과 커버리지 분석 – Source Code to Object Code Traceability (1))   반복되는 이야기하지만 이런 내용들은 VectorCAST 교육과 같은 기회를 통해서 제대로 배우기를 추천한다.

 

다음으로 레벨 C 혹은 그 이상을 수행하면서 우리가 알아야 할 것을 생각해 보자. 위험레벨에 어떤 일이 발생하는지 기억하자. 일반적으로 그것은 오르기만 한다. 그래서 원래는 레벨 C로 개발되었던 당신의 소프트웨어가 결국은 레벨 B 그리고 A에 도달할 지 모른다. 왜 레벨이 높아지는 걸까? 시스템이 더 중요해지고 조종사의 작업량이 증가하고 중복이 감소하는 등의 이유가 있을 수 있다. 위험레벨에 따라서 서로 다른 등급의 구조적 커버리지를 요구받게 된다. 위험레벨 중에서 레벨 D와 C사이에서 가장 큰 비용 차이가 있었던 것을 기억하자. 구조적 커버리지가 그 이유이다. 그것은 DO-178B의 독특한 부분이다. 사실 DO-178B는 사실상 결정론에 관한 것이다. 우리가 유죄가 아니며 DO-178B에 대한 일반적인 준수에 있어서 강력한 프로세스를 가지고 있다는 것을 보여줌으로써 무죄를 증명하는 것이다. DO-178B/DO-254는 프로세스 문서가 아니라 일반적인 가이드라인이기 때문에 그 안에 기술된 대로 정확하게 되어야 할 필요는 없다. 하지만 당신의 프로세스는 적어도 그런 “가이드라인”을 만족할 수 있을 정도는 되어야 한다. 가장 중요한 것은 당신이 인증을 달성하기 위해 당신의 시스템 위험레벨에 대해서 그것을 보여야만 한다는 것이다.

역주) 갑작스레 DO-178 문서의 성격을 이야기하고 있다. 앞부분을 기억하시는 분들은 이미 언급했던 내용들임을 알 수 있을 것이다. DO-178/DO-254는 “단지” 가이드라인일 뿐이라는 것이고 가이드라인이 안내(?)하는 대로 잘 따라가면 된다는 것인데 사실 이 부분이 쉽게 와닿지는 않을 것이다. 그럼에도 불구하고 이 부분이 이해되어야 한다. 그래야 DO-178/DO-254를 원활하게 진행할 수 있다. 물론 쉽지 않은 일이고 그래서 DER과 같은 전문가의 도움이 필요하다. (참고 포스팅: 6. DO-178 가이드라인)

 

그것이 DO-178B에 대해서 독특한 점이다. DO-178B는 여러 개의 위험 레벨을 가진 유일한 표준이다. 미국 식약청의 경우 의료기구는 Class 1 혹은 Class 2 장비가 있다. 하지만 그들 사이에는 그렇게 큰 차이가 없다. DO-178B에는 그것이 있으며 그로 인해서 재미있는 질문들이 나오게 된다.

 

왜 우리는 모든 것들을 레벨 A로 만들지 않는가? 그렇게 하면 더 높은 품질을 가지게 되는 것이 아닌가? 그렇다. 그럴 것이다. 그런데 왜 우리는 그렇게 하지 않을까? 이 책을 누가 작성했는지를 기억하자. 주로 산업계에서 작성했다. 그리고 그들의 세 가지 최고 관심사는 바로 ‘이익’, ‘이익’, 그리고 ‘이익’이다. 안전성도 물론이다. 하지만 어떤 비용을 들여서라도 그렇게 하겠다는 것이 아니라 합리적인 비용으로 안전성을 확보한다는 뜻이다. DO-178B와 DO-254는 합리적이다. 좋은 소식은 우리가 제대로 하면 레벨 A는 레벨 D에 비해서 단지 25 ~ 40%의 추가비용만 들 것이라는 것이다. 솔직히 레벨 D 준수는 달성하기가 매우 쉬어야 한다. 왜냐하면 레벨 D내에서는 아무것도 요구되지 않기 때문이다. 제대로 된 회사라면 어쨌든 수행하지 않을 것이다.

역주) 여기서도 DO-178 문서의 성격을 이야기하고 있다. DO-178은 항공업계 관계자들이 주도적으로 만들었다는 것이고 그렇다면 기업 입장에서는 비용이 가장 중요하므로 무조건 많은 돈을 들여서 ‘우주 최강’의 안전성을 확보하려고 하는 짓은 하지 않을 것이라고 말하고 있다. 실제로 그렇기도 하다. 말장난 같이 들리겠지만 이에 대해서는 역자도 동의하는 부분이다. 분명 DO-178은 많은 비용이 들고 어려운 것이지만 막상 나중에 문제가 터졌을 때 추가되는 비용이나 충격을 생각한다면 오히려 비용이 더 적게 드는 것일 수도 있다는 생각이 든다. 문제는 현실은 항상 시간과 돈에 쫓긴다는 점이다.

 

컨설턴트로써 우리는 그들 제품의 첫 번째 버전을 생산하고 있었던 능력있는 고객과 함께 일한 적이 있다. 당신은 소프트웨어 소스코드 파일에 대한 평균적인 버전 번호를 예상할 수 있는가? 그것은 20 ~ 30 사이였던 것으로 밝혀졌다. 개발자에 의한 여러 개의 버전과 업데이트가 있었고 그 후에 단위시험과 동료검토로 더 업데이트가 발생했다. 이것은 비공식 및 공식시험을 통한 많은 변경에 의한 것이다. 지금은 많아야 약 8이다. 하지만 20 ~ 30이라니! 무슨 일이 일어난 것인가? 그들은 항공기상에서 단지 설계를 하고 있는 것이지만 그것은 설계가 아니다. 그렇지 않은가? 그것은 추측하는 것이다. 당신의 친구들과 한 무더기의 목재만으로 집을 짓는다는 것을 상상할 수 있는가? 단지 몇 년 동안 기초와 벽을 이리 저리 옮기면서 서로 다른 버전을 만들어 보는 것일 뿐이다. 맞나? 물론 그렇지 않을테지만 소프트웨어 산업에서는 왜 이런 식의 시나리오가 많이 일어나는가?

역주) 소스를 생성하고 20 ~ 30번을 거쳐서 완성을 하든 8번만에 완성을 하든 중요한 것은 제대로 구현하는 것이다. 하지만 저자의 말처럼 20 ~ 30번이나 소스코드를 수정한다는 것은 개발자의 실력이 부족해서가 아니라 애초에 무엇을 구현할 것인지 제대로 정의가 안되어 있을 가능성이 높다. 저자는 이 부분을 이야기하고 있는 것이다.

 

우리는 요구사항과 추적성이 완료되지 않은 채로 소스코드 동료검토를 해왔다. 그래서 무엇이 리뷰되고 있었는가? 그것이 우아한가? 아름다운가? 컴파일이 될 것 같은가? 그것을 이해할 수 있나? 모두 합리적인 질문들이다. 하지만 코드가 수행하고자 하는 것이 무엇이고 무슨 요구사항이 달성되도록 노력하고 있었는가? 분명하게 그 코드리뷰는 잘못된 것이고 무효이다. 만약 당신이 코드가 수행하고자 하는 것에 대해서 전혀 알지 못한다면 어떻게 코드리뷰를 할 수 있을까? 그것이 코딩에 앞서서 완전하고 독립적으로 리뷰된 요구사항이 필요한 이유이다. 완전하고 추적되는 요구사항이 없는 코드 동료검토에 대해서 DO-178B는 무엇이라고 말하는가? 분명하게 아무것도 아니라고 말한다. 아무런 의미도 없고 당신은 그저 시간을 낭비한 것이다.

역주) 동료검토로써 코드리뷰라고 하면 코드 자체를 보면서 리뷰를 하는 경우가 많다. 이 경우 결국은 코딩룰 수준의 리뷰가 되고 만다. 아마도 코딩 테크닉이 뛰어난 지를 확인할 수도 있을 것이다. ‘이 친구 실력있는 프로그래머군.’이라고 감탄하면서. 동료검토는 이것이 핵심이 아니다. 요구사항에 맞게 제대로 구현했는지를 확인해야 하고 잘못된 코드, 불필요한 코드가 들어가 있지 않은지를 확인해야 한다. 이것이 빠진 코드리뷰는 할 필요가 없다. 괜히 시간낭비일 뿐이다. 이것은 DO-178에만 해당하는 것이 아니고 모든 개발에 공통으로 해당하는 부분일 것이다.

 

유럽에서 항공전자장비를 만드는 중간 크기의 한 회사가 우리에게 감사를 요청했다. 우리는 코드리뷰에서 거의 실수를 발견하지 못했다. 그것은 레벨 B 프로젝트였고 훌륭한 엔지니어링으로 진행되었는데 아마도 우리가 만나봤던 수 백 개의 프로젝트들보다 더 나았었다. 그들이 직면한 도전은 리버스 엔지니어링이었다. 우리는 물어봤다. “코드리뷰는 어떻게 진행했나요?” 그들은 우리가 오랫동안 보아온 가장 똑똑한 엔지니어들이었고 그들의 결과에 자부심을 가지고 있었다. 그들은 테이블에 모여 앉아서 모든 것을 분석했다. 그들은 작성된 요구사항이 전혀 없었고 코드리뷰를 위한 기준도 작성되어 있지 않았지만 그들은 요구사항과 자신들의 시스템에 대해서 매우 잘 알고 있었다.

 

그런 코드리뷰에 대해서 그들은 얼마나 신뢰할 수 있을까? 제로다. 당신이 모든 항목과 모든 소스코드 라인마다 범위를 벗어난 값 4개씩을 체크했다는 것을 각 모듈에 대한 3페이지 혹은 4페이지의 체크리스트만으로 어떻게 알 수 있는가? 당신은 알지 못한다. 훌륭한 체크리스트와 코드리뷰가 있다는 것만으로 당신이 그 만큼 소프트웨어를 개선할 수 있을까? 그럴 수 없다. 소스코드는 훨씬 더 큰 전체 패키지이다. 항공전자 소프트웨어는 가장 약한 링크만큼만 강할 뿐이다. DO-178B는 주어진 위험레벨에 대한 전체 엔지니어링 라이프사이클을 통해서 지속적으로 강한 체인을 만들어 내는 것에 관한 것이다. 레벨 B 체인이 레벨 A 체인만큼 “강한”가? 물론 그렇지 않다. 하지만 그 체인은 단지 레벨 B가 필요할 뿐이다. 왜 더 강하게 만드는가? 정확하게만 만들면 된다.

역주) 소프트웨어 위험 레벨에 대해서 설명하고 있는 체인에 대한 비유는 상당히 핵심을 명확하게 말해주고 있다. 아무리 강력한 체인이라고 하더라도 그 중 하나의 고리가 끊어져 버리면 다른 체인들이 아무리 강력해도 아무런 소용이 없게 된다. 따라서 체인의 품질을 모두 균등하게 만드는 것이 중요하다. (굳이 비용을 더 들여가면서 초강력 체인을 만들 필요는 없다) DO-178은 이렇게 균일한 강도의 체인을 만들고 있는지를 체크하는 부분이라고 할 수 있다.

 

그것이 DO-178B 라이프사이클에서 가장 중요한 점이다. 지속적으로 모든 프로세스를 따르고 시험을 포함하는 정확성 프로세스를 통해서 그것들을 검증함으로써 품질을 확립하라. 훌륭한 준수 결과를 만들어라. DO-178B로 그것을 통합하고 모든 것을 합치며 실제로 다른 것은 각 위험레벨에 따른 구조적 커버리지를 가지는 것이다.

 

레벨 D에는 구조적 커버리지가 없다. 쉽게 처리할 수 있다. 레벨 C에서는 모든 statement가 커버되어야 한다. 그 말은 우리가 각 소스 statement가 예상대로 수행한다는 것을 증명한다는 의미이다. 문제는 “statement가 무엇이냐?”이다. DO-178B는 그것을 다루지 않는다. 얼마나 많은 소스코드 라인이 있는가? 그것도 말하지 않는다. 소스코드 라인을 어떻게 카운트하는가? 16명의 사람이 있다면 16가지의 서로 다른 방법으로 카운트한다!

 

statement는 일반적으로 세미콜론에 의해서 표시되는 가장 작은 독립요소이다. 레벨 B에서는 모든 decision condition 생성자(“branches”)를 포함하기 때문에 ‘연역적’인 시험 기준으로 그들을 실행했다는 것을 증명하는 것이 좀 더 진행되어야 한다. 레벨 C에 대해서 우리는 “단지” 모든 statement를 커버한다. 이제 우리는 대부분의 회사들보다 10배 더 나은 상태이지만 다른 모든 구조를 체크하는 것과는 거리가 멀다. 왜일까? 그것은 branch와 다른 가능성 있는 decision condition을 체크하지 않기 때문이다.

 

레벨 B에 대해서는 모두 합쳐지고 누적된다. statement 커버리지가 수행되고 거기에 더해서 branch 커버리지라고 하는 근사한 이름의 decision 커버리지가 수행된다. case 문, switch 문 그리고 루프문의 양쪽면을 시험한다. 우리는 모든 가능한 결과에 대해서 각각의 결정문을 증명해야 한다. 그것은 때때로 branch 시험으로써 비공식적으로 참조된다.

 

구조적 커버리지 비용을 어떻게 반으로 줄이는지 살펴보자. 정상범위 시험, 강건성 시험 그리고 기능 시험은 모두 DO-178B 검증 프로세스에 포함된다. 기능 시험이 먼저 오게 되는 데 요구사항 시험이다. 만약 상세한 요구사항들이 존재한다면 우리는 거의 모든 정상범위 시험 케이스, 많은 강건성 시험 그리고 많은 구조적 커버리지 시험을 선택하게 된다. 이들의 크기는 상당히 비슷한다. 하지만 그 크기가 DO-178B에서 구체화되지 않은 상태에서 우리가 상세한 요구사항들을 가진다면 얼마나 상세화되어야 하는 걸까? 그것은 매우 주관적이다.

역주) 솔직히 저자의 설명이 매끄럽지가 못하다. 물론 역자의 부족함도 있을 것이다. 어쨌든 여기서의 요지는 요구사항이 제대로 정의되면 그 요구사항을 기준으로 한 시험 케이스가 제대로, 많이 나올 수 있다는 것이다. 그렇게 되면 첫 단계의 시험으로 높은 %를 커버할 수 있을 가능성이 높아진다. 나머지 부족한 부분을 다른 시험으로, 다른 방법으로 커버한다는 말이다. 이렇게 하면 무작정 100%를 채우려고 이런 저런 시도를 하는 것보다 저자의 주장으로는 비용을 반으로 줄일 수 있다고 한다. 실제로 비용의 반이 될지는 모르겠지만 적어도 이런 전략 자체에 대해서만큼은 역자도 100% 동의하는 바이다.

 

20,000라인의 코드를 가진 시스템에서 상세한 요구사항에 대해서 우리가 필요로 하는 소스코드 라인당 요구사항은 얼마나 많아야 할까? 800, 900, 1000? 그것은 말하기 어렵다. 하지만 이것이 DO-178B가 많은 이중 안전장치와 이중 체크를 가지고 있는 부분이다. HighRely사와 다른 주요 항공전자장비 개발회사들에게 사용되고 있는 훌륭한 경험법칙은 매 20라인의 소스코드마다 적어도 하나의 요구사항을 가지는 것이다. 하지만 그것은 시스템의 종류에 따라 다르다. 예를 들어 알고리즘 집약적인 기능, 푸리에 변환이라고 한다면 소스코드 라인당 거의 한 개의 요구사항을 가지게 되는 독립장치의 조합에 대한 로직보다 소스코드 라인당 더 적은 요구사항을 가질 것이다. 하지만 흔히 우리는 소스코드 라인당 한 개의 요구사항보다 더 적은 일반적인 항공전자 소프트웨어를 본다. 이것은 다음과 같은 질문이 분명 나오게 된다. “개발자들이 코드를 작성할 때 정확히 무엇을 가정했나?” 실제로 DER/FAA는 같은 질문을 했고 그것은 유쾌하지 않은 결과를 가져왔었다.

역주) DO-178에서는 요구사항(하위레벨)을 보면서 코드를 작성한다는 점을 다시 한 번 기억하자. 따라서 요구사항은 소스코드와 직접 연결된다. 그렇다면 소스코드 라인 한 줄 당 요구사항이 하나씩 연결되면 될까? 물론 그래도 된다. 하지만 그렇게 한다면 양이 너무 많아서 개발자는 중간에 포기할 지경이 될 것이다. 그렇다고 너무 포괄적으로 작성하게 되면 저자의 말처럼 소위 개발자의 ‘상상’이 코드에 포함될 수 있다. 이 점 역시 조심해야 할 부분이다. DO-178이 이런 부분을 규정하지는 않는다. 그저 DER이 OK할 수 있는 수준으로 하라고 할 뿐이다. 그래서 어려운 것이긴 하지만 이것 역시 그 동안 개발하던 방식과 달라서 그렇지 익숙해지면 충분히 납득할 수 있는 부분이다. (참고 포스팅: 1. DO-178과 소프트웨어 요구사항(Software Requirements))

 

만약 상세화 된 요구사항이 없더라도 당신은 여전히 정상범위 시험과 강건성 시험을 수행해야 한다. 그리고 기능시험에서 가졌던 상세한 요구사항에 대한 시험 케이스를 여기서는 가지고 있지 않기 때문에 정상범위와 강건성 시험에 대해 더 많은 별도의 시험 케이스를 작성한다. 그렇게 DO-178B는 당신을 확인한다. 어떤 방식으로든 당신은 비슷한 시험과 요구사항으로 끝나게 된다. 유일한 질문은 당신이 프로젝트 초기에 그것을 함으로써 시간을 줄일 것이냐 혹은 더 많은 비용을 들이면서 나중에 그것을 추가하느냐이다. DER 혹은 QA가 감사를 할 때 그가 묻는다. “당신은 기능 시험 케이스 영역 이외에 왜 그렇게 많은 정상범위와 강건성 시험 케이스를 가지고 있습니까?” 그에 대한 답은 이렇게 될 것이다. “제가 개발단계에 앞서서 가졌어야 하는 상세한 요구사항을 가지고 있지 않았기 때문에 QA와 DER이 시험 단계에 대한 진출 기준으로써 제가 그것들을 추가하게 만들었습니다.”

 

해결책은 이전으로 돌아가서 당신이 소프트웨어 설계를 시작하기 전에 더 상세한 요구사항을 추가하는 것이다. 만약 당신이 코드를 작성한 후에 요구사항을 추가한다면(소스코드가 요구사항과 일치한다는 것을 보장하는 잘못된 방법임에도 불구하고 흥미로운 부분이다) 마지막에는 그 방법이 정당화되고 당신이 DO-178B를 준수한다고 생각할지 모른다. 하지만 이것은 당신의 소프트웨어 개발 프로세스를 따르는 것에 대한 실패를 속이는 것이고 QA는 이것을 막아야만 한다. 심지어 당신의 QA가 역시 실패하더라도 DER과 FAA는 코드리뷰의 시점에 요구사항의 상태가 어떠했는지를 확인하는데 당신의 형상관리시스템을 사용할 수 있을 것이다. 그리고 그 요구사항들은 완전히 완료되었어야 하며 그렇지 않으면 당신의 프로젝트는 실패할 것이다.

역주) 저자가 여기에서 이야기하는 것은 시험을 나중에 추가로 작성하는 부분에 대한 것이다. 그런데 시험을 나중에 추가하는 것 자체를 문제 삼는 것은 아니다. 중요한 점은 그렇게 나중에 추가하더라도 과연 요구사항에 기반해서 추가했느냐이다. 보통은 시간도 없고 복잡하니까 그냥 개발자가 알고 있는 내용으로 시험을 추가하고 진행하는 경우가 많다. 그렇게 하지 말라는 것이다. DO-178을 진행하고 있다면 DER은 그 부분을 정확하게 찾아낼 수 있다. 그리고 결국은 빠진 부분을 다시 진행해야 한다. 결과적으로 오히려 시간과 비용이 더 들게 되는 결과가 나올 수 있는 것이다. 혹시 당신이 QA를 맡고 있다면 당신이 그 부분을 잡아내야 한다.

 

약 40년 전에 쓰인 “The Mythical Man Month”라고 불리는 책(우리는 여전히 엔지니어링 매너저라면 반드시 읽어야 할 책이라고 생각하는)에서는 이상적인 팀크기를 결정하기 위해 소프트웨어 조직을 비교했다. 저자는 이상적인 숫자가 있다는 결론을 내렸다. 바로 한 명! 엔지니어들은 커뮤니케이션 보다는 정량화하는데 더 뛰어나기 때문에 한 명인 팀은 커뮤니케이션의 실패로 스스로를 혼란스럽게 만들 일이 없을 것이다. 하지만 현실세계에서는 우리는 추정을 해야 하고 상세한 요구사항을 가져야 하며 그것을 작성함으로써 다른 누군가가 그것을 체크할 수 있어야 한다. 당신은 같은 사람이 소프트웨어를 구현하고 시험하는 것을 원하지 않는다. 아무리 레벨 D에서는 그것이 허용되더라도 그것은 어리석은 일이다.

 

만약 레벨 B 프로젝트라면 당신은 독립성이 필요하다. 레벨 D에서는 독립성이 없이도 허용된다. 만약 당신이 그런 독립성을 지금까지 제공하지 않았다면 나중에 레벨 B로 업그레이드할 수 있는가? 안된다. 당신은 모든 것을 다시 진행해야 한다. 그런데 당신은 왜 독립된 리뷰를 수행하려고 하지 않는가? 그것은 다른 누군가는 그 학습곡선을 습득해야 하기 때문에 약간 더 비용이 든다. 하지만 당신 자신의 작업을 리뷰하는 것은 어리석은 일이며 작성자는 개인적인 경험에 의지해서 입증할 수 있을 뿐이다.

역주) 여기서 독립성은 쉽게 말해서 3자가 시험하거나 리뷰하는 것을 말한다. 혹시 팀이 2명밖에 안되더라도 최소한 내가 한 것을 스스로 검사하지 말라는 것이다. DO-178 가이드라인에서는 이러한 독립성의 기준을 엄격하게 제시하고 있다.

 

MCDC 시험   DO-178B 정의: “모든 decision은 모든 가능한 결과를 적어도 한 번 가지며 하나의 decision에서 모든condition은 그 decision의 결과에 독립적으로 영향을 미치는 것을 보여준다.”   만약 하나의 condition이 결과에 홀로 영향을 미친다면 그 condition이 decision의 결과에 독립적으로 영향을 미친다

 

이제 구조적 커버리지 단계이다. 상세한 요구사항 작성과 정상범위 그리고 강건성 시험이 잘 이루어졌다면 모든 소스 branch와 구조의 70 ~ 80%가 커버되어야 한다. 사실 기능 및 강건성 시험을 통해서 많은 MCDC 조건을 커버하지는 못할 것이지만 대부분의 코드는 많은 MCDC를 가지고 있지 않으며 그런 것들은 어쨌든 레벨 A에 대해서만 커버될 필요가 있다.

 

비용은 얼마나 들까? 많은 사람들이 레벨 A는 레벨 B보다 30 ~ 60% 더 비싸다고 예상한다. 그것이 산업계의 공통된 믿음이지만 실제로는 매우 과장된 것이다. 사실상 레벨 A는 레벨 B 대비 5 ~ 10%를 더한다. 레벨 A에 대해서 당신은 모든 decision이 적어도 한 번은 모든 가능한 결과를 가지며 각 decision에서 모든 condition은 결과에 독립적으로 영향을 미친다는 것을 보여준다는 점을 검증한다. 그것이 DO-178에서 원하는 것이다. 그것은 모든 condition을 고정한 상태로 코드내의 각각의 condition을 조작해야 하며 그 하나의 condition을 조작한 결과로 출력이 변한다는 것을 증명한다는 것을 의미한다. 그것은 설계, 통합 그리고 로직에 대한 훌륭한 체크이며 사실 그것은 거의 컴파일러 수준의 체크이다.

 

구조적 커버리지 예시   WOW(Weight on Wheels)와 TR(Thrust Reversers)   Begin    If WOW & TR activated:      Activate_Thrust_Reverser;   End;   질문: 레벨 D 구조적 시험 케이스는? 레벨 C? 레벨 B? 레벨 A?

 

여러 라인의 소스코드를 가진 하나의 기능에 대한 예제를 보자.

 

마지막은 실제로는 진입하지 않는 편집 지점일 뿐이다. 만약 비행기가 막 착륙했다고 말할 수 있는, Weight On Wheels(WOW)가 있다면, 당신은 역추진장치를 활성화시키기를 원한다. 그것은 바퀴에 무게가 실리기 전까지는 실행되어서는 안된다. 그리고 그것은 근접센서와 역추진장치 컨트롤 시스템의 코드로 보인다. 글쎄, 꼭 그렇지 만은 않다. 실제 시스템에는 이것을 컨트롤 하기 위한 10,000라인 이상의 코드가 있다. 대형 민간 항공기의 경우 일반적인 역추진장치 근접센서 시스템의 경우 35,000 ~ 40,000라인에 달한다.

 

우리 엔지니어들은 B-777에 대해서 레벨 A로 그런 소프트웨어를 개발하고 검증했다. 하지만 20%만 레벨 A가 될 필요가 있었다. 비용을 줄이기 위해서 나머지는 레벨 B와 C로 인증 받았다. 특별히 짧은 활주로에서 안전한 착륙을 위해 흔히 필요한 역추진장치와 같은 그런 중요한 시스템에게는 특이하게 들릴지 모른다. 그에 대한 답은 그 시스템이 어떤 코드는 다른 코드만큼 중요하지 않다는 것을 보여주면서 파티션될 수 있다는 것이다. 그것은 비용을 15 ~ 20% 감소시킬 수 있는 접근법이다. 그 아이디어는 작업을 최소화하면서도 안전을 타협하지 않는다. 위험레벨은 이런 것이다. 다시 한번 말하지만 모든 것을 레벨 A로하는 것은 간단할 것이다. 혹은 말이 나왔으니 말이지만 모든 항공전자 소프트웨어를 레벨 A로 인증하는 것이다. 하지만 DO-178B와 DO-254는 주로 산업계에 의해서 개발된 “합리적인” 표준이다. 비용과 일정이 중요하다.

역주) 저자가 파티션에 대해서 이야기하면서 비용을 절감할 수 있다고 했는데 사실 이 부분은 그렇게 간단한 내용이 아니다. 파티션을 적용한다는 것은 실질적으로 파티션 OS를 사용한다는 것인데 이 OS를 구매하고 그에 맞추어 기존 개발을 변경해야 하는 부분의 비용도 생각해 봐야 하기 때문이다. 모든 소프트웨어를 레벨 A로 개발하는 데 드는 비용도 많이 들겠지만 이런 추가적인 비용도 분명 많이 들기 때문에 이런 경우 무조건 적게 든다고 단정할 수는 없다. 하지만 개념적으로는 위험레벨을 분리해서 개발할 수 있다면 모두 최상위 레벨로 개발하는 것보다는 확실히 효율적이고 비용을 줄일 수 있는 여지는 있는 게 사실이다.

 

위의 예제에서 당신은 모든 statement가 커버된다는 것을 보여주면서 한 번의 시험 케이스로 구조적 커버리지 분석을 완료할 수 있다. Weight On Wheels 값이 양수이고 역추진장치가 활성화되는 것과 같이 if statement를 true로 만드는 한 세트의 조건이 있다. 그러면 역추진장치를 활성화하는 라인은 한 번의 시험케이스로 실행된다. 이것은 레벨 C를 준수하는 것이다.

 

이런 상황에 대한 스펙에는 요구사항이 있다. 우리가 기능시험을 수행할 때 그 구조적 커버리지를 달성할 것이다. 이것은 역추진장치 로직을 시험하기 위한 정상 동작 조건이다. 만약 우리가 그것을 요구사항으로 가지지 못해서 놓쳤다면, 코드를 살펴보자. 우리는 정상 범위 시험 케이스를 작성했고 만약 그것을 빼먹었다면, 어쨌든 우리는 레벨 C에 따른 시험, 강건성 시험을 실시했을 것이고 그것을 발견했을 것이다. 그래서 우리는 레벨 C에 대해서 추가적인 구조적 커버리지 시험 케이스를 작성했어야 하는데 라고 생각할 수 있을까? 그럴 수 없다. 우리는 기능 시험과 강건성 시험 동안에 그런 중요한 요구사항과 코드 블록을 검증하지 않은 실제로 불충분한 상태가 될 것이다. 하지만 그런 상황이 발생하면 우리가 해야 하는 부분이다.

역주) 설명이 난해하다. 정리하자면 이곳에서 저자가 말하고자 하는 것은 시험케이스가 누락되는 경우 요구사항이 있는지 확인하라는 것, 그리고 그 요구사항에 기반해서 누락된 시험케이스를 추가하라는 것이다. 그냥 시험하다가 보니까 누락된 게 보여서 시험케이스를 하나 추가하는 것이 아니라는 말이다. 이렇게 누락된 부분을 추가하는 과정 자체도 제대로 된 절차를 거쳐야 한다는 점을 이야기하고 있다.

 

단지 레벨 C에 대해서도 여섯 가지 레벨의 체크가 있다. 예를 들어 휴대폰을 하나 만든다고 하면 상당한 양의 로직과 수 십만 라인의 코드가 있을 것이다. 나는 품질을 보증하기 위해 사실 어떤 상용의 비항공전자 임베디드 프로젝트에 대해서든 적어도 레벨 C를 수행할 것이다. 그리고 그것이 의료 장비와 핵발전소 관계자들이 레벨 A가 아닌 레벨 C에 대한 DO-178B 스타일의 프로세스를 채택하는 이유이다.

 

다음은 레벨 B이다. 당신은 아마도 안전에 대한 세 가지 시험 케이스 중 최소 숫자내에서 그것을 수행할 수 있을 것이다. 하지만 그 최소는 두 개이다. 내가 필요한 것은 “if” statement가 false (활성화되지 않은)이자 “if” statement가 true인 레벨 C 시험 케이스의 반복인 한 세트의 조건이다. 그런 다음 그것은 복합문이 아니기 때문에 나는 branch를 커버하게 된다. 복합문은 MCDC의 수행을 필요로 하는 한 세트의 조건을 참조한다.

 

MCDC - 유효성   MCDC로 발견된 에러의 빈도   에러를 발견한 사람들 중: 21%는 안전에 민감한 에러들이 발견되었다고 말함

 

구조적 커버리지   구조적 커버리지는, 심지어 MCDC조차도 “품질”을 보증하지 않는다   MCDC는 이상적인 시험에 대한 ‘근거없는 소문’이 되어 왔다   직접적으로 품질을 개선하지 않는다. 단지 품질을 평가하고 선행하는 시험이 코드 커버리지를 얻는 정도를 평가한다

 

15년 전, 상용 구조적 커버리지 분석 툴과 같은 DO-178 툴을 가지기 전에는 페이지당 132 컬럼의 소스리스트를 출력했었다. 색깔이 있는 연필(펜이 아님)로 많은 원을 그리면서 “시험 케이스 127B는 condition Y를 수행”이라고 말했었다. 누군가 소스코드를 수정하면 당신은 그것을 반복했다. 이제 우리는 DO-178B 프로세스의 가장 지루한 이 구조적 커버리지 분석을 자동화함으로써 엄청난 비용을 줄여주는 툴을 가지고 있다.

 

결론적으로, MCDC는 매우 비싸고 대부분의 경우에서 그것은 많은 에러를 탐지하지 않는다. 우리는 프로젝트에서 MCDC로 많은 의미있는 에러를 발견하지 않는다. Weight On Wheels 시험이 잘못 변경되는 바람에 비행기 한 대가 추락하는 일이 발생했었다. 시험은 다시 수행되지 않았었다. 소프트웨어가 그것을 탐지하는 데 실패했었는데 소프트웨어가 변경되었기 때문이었다. 그리고 그것이 레벨 A의 본질이고 그것이 시스템 레벨에서 시험되는 이유이다. 그것이 실제 하드웨어 출력이었다면 우리는 하드웨어상에서 그것을 시험해야 했을 것이다.

 

MCDC는 일반적으로 그렇게 생산적이지 않지만 소프트웨어가 항공기에 탑재된다면 MCDC를 수행하는 것이 좋다. 비록 MCDC를하더라도 품질이 보증되는 것은 아니다. MCDC는 이상적인 시험에 대한 ‘근거없는 소문’이 되어 왔다. 그렇지 않다. 그것은 직접적으로 품질을 개선하지는 않는다. 그것은 선행하는 시험의 엄격함을 평가하고 우리가 더 안전한 시스템을 얻는 것을 도와주는 DO-178B 체인에서 단지 하나의 링크일 뿐이다.

역주) 흔히들 시험을 잘하는 조직에 대해서는 품질관리가 잘되고 있구나라는 말을 한다. 그리고 막연히 품질 수준이 높겠지라고 생각하게 된다. 시험은 현재 있는 문제점을 찾아낼 수 있도록 도와주는 것으로 현재 구현된 수준에서 최선의 품질이 나올 수 있도록 도와주는 역할을 하는 것이지 그 자체로 품질을 더 높여줄 수는 없다. DO-178에서의 품질은 이런 관점에서 이해할 필요가 있다.