7. DO-178과 커버리지 분석 – Data / Control Coupling (3)

cast-19.pdf

이번 절에서는 DC/CC 커버리지 분석을 어떻게 수행할 지에 대해서 전체적인 정리를 해보자. 그 전에 먼저 CAST-19 문서의 성격을 다시 한 번 살펴볼 필요가 있다.

 

CAST의 원문은 ‘Certification Authorities Software Team’이다. FAA에 소속된 소프트웨어 팀을 말한다. 이들이 DC/CC를 어떤 관점으로 보는지를 정리한 문서가 CAST-19라고도 할 수 있다. 따라서 이 문서를 제대로 이해할 수 있게 되면 최소한 FAA에서 DC/CC를 어떤 것으로 인식하고 있고 무엇을 중점적으로 체크하는 지를 확인할 수 있다. DO-178 인증을 받기 위해서 DC/CC를 실제로 수행해야 하는 우리로서는 반드시 이해하고 있어야 할 부분이 아닐 수 없다.

 

(1)   CAST 관점에서의 DC 수행 목적

 

우선 DC에 대해서 CAST-19에서는 아래와 같이 정리하고 있다.

 

해석을 보자.

 

CAST는 Data Coupling 분석의 목적이 다음과 같아야 한다고 제안한다.   l  통합 시험 노력의 완료 체크가 된다. 그 분석은 또한 프로그램에 의해서 사용되는 데이터 구조의 구조적 강건성으로의 통찰을 제공한다. 기본적으로 Data Coupling 분석은 훌륭한 소프트웨어 엔지니어링 실행을 강제하려는 의도가 있다. Data Coupling 분석은 소프트웨어에서 파티셔닝과 다른 보호 방법이 구현될 때 특별히 중요하게 된다. l  데이터 의존성을 구분한다. 예를 들어서 하나의 컴포넌트가 데이터 오브젝트를 정의하고 다른 컴포넌트가 어떤 운영 시나리오에서 그 데이터 오브젝트의 정의를 사용할 때 두 컴포넌트 사이에는 데이터 의존성이 존재한다. l  시험과 분석을 통해서 모듈/컴포넌트 사이의 데이터 인터페이스를 검증한다. (시험을 하고 그 다음에 측정한다) l  부적절한 데이터 의존성을 구분한다. l  인터페이스 깊이의 정도를 정의하고 평가한다. l  결합도(Coupling) 상호의존성을 결정하고 최소화한다. l  응집도(Cohesion)를 결정하고 최대화한다. l  입력/출력 데이터 버퍼를 평가한다. l  변경과 요구사항에 미치는 영향의 충격을 발견한다.

 

우리가 앞 절에서 보았던 컴포넌트, 통합 시험, 소프트웨어 설계, 인터페이스, 의존성 등의 핵심 키워드가 모두 포함되어 있다. 아마 앞의 내용을 제대로 읽어본 분들에게는 위의 설명 하나하나가 무엇을 의미하는지 대략적으로 이해가 될 것이다.

 

한 가지 처음 보는 단어가 보인다. 바로 ‘응집도(Cohesion)’이다. 소프트웨어 개발과 관련해서 한 번쯤 들어본 용어일 텐데 이번 기회에 다시 한 번 정리를 해보자. 응집도(Cohesion)를 이야기할 때 반드시 같이 이야기되는 것이 바로 결합도(Coupling)이다. 사실 응집도(cohesion)와 결합도(coupling)를 구글링을 해보면 관련 자료들을 쉽게 찾아볼 수 있다. 아래는 그렇게 구글링한 자료 중 하나이다.

 

그림 12 결합도(Coupling)와 응집도(Cohesion)

출처) https://www.google.co.kr/search?q=cohesion+coupling&newwindow=1&hl=ko&source=lnms&tbm=isch&sa=X&sqi=2&ved=0ahUKEwiOk-La7YTdAhVCUJAKHQWDD0UQ_AUICigB&biw=1920&bih=943#imgrc=4tnGgA2SaUhBgM:

 

위의 그림을 통해서 결합도(Coupling)와 응집도(Cohesion)가 무엇인지를 대략적으로 구분할 수 있을 것이다. 그럼 이제 다음 그림을 보자. 역시나 구글링으로 찾은 자료이다.

 

출처) https://www.slideshare.net/SaurabhKumar210/couplingand-cohesion-student

 

결합도(Coupling)의 여러 형태를 보여주며 결합도(Coupling)가 복잡해지면 수정이 어렵다는 것을 설명하고 있다. 이를 통해서 결합도(Coupling)는 복잡할 수록 좋지 않다는 것을 알 수 있다. 하나를 수정하면 다른 연관된 것들이 모두 영향을 받기 때문에 그 부분도 추가로 확인해야 한다. 응집도(cohesion)는 반대이다. 즉 복잡할수록 좋다. 이제 응집도(cohesion)를 최대화하는 것을 선호한다는 CAST의 설명이 이해가 될 것이다.

 

(2)   CAST 관점에서의 CC 수행 목적

 

이번에는 CC에 대해서 확인해 보자.

 

해석을 보자.

 

CAST는 Control Coupling 분석의 목적이 다음과 같아야 한다고 제안한다.   l  통합 시험 노력의 보완적인 완료 체크가 된다. (즉, Data Coupling 분석을 보완한다) 그 분석은 또한 실행, 시간 그리고 스케쥴링의 구조적 강건성으로의 통찰을 제공한다. 기본적으로 Control Coupling은 훌륭한 소프트웨어 엔지니어링 실행을 강제하려는 의도가 있다. Control Coupling은 소프트웨어에서 파티셔닝과 다른 보호 방법이 구현될 때 특별히 중요하게 된다. l  Control 의존성을 구분한다. 하나의 실행이 다른 것에 의지할 때 두 컴포넌트 사이에는 Control 의존성이 존재한다. 예를 들면, 하나의 모듈/컴포넌트가 어떤 운영 시나리오에서 다른 것을 호출한다. (즉 피호출자는 호출자에 의존한다) 또 다른 예는 하나의 모듈/컴포넌트가 어떤 운영 시나리오에서 다른 모듈/컴포넌트에 의해 영향을 받는 실행 순서를 결정하는 데이터 오브젝트를 정의하는 것이다. l  부적절한 컨트롤 의존성을 구분한다. l  호출 순서(모듈/컴포넌트/파트/유닛/오브젝트들 간의)의 정확한 실행을 검증한다. l  인터페이스 깊이의 정도를 정의하고 평가한다. l  검증 스케쥴링(예를 들면, 프레임 오버런을 일으킬 수 있는 호출 순서에서의 문제점을 탐지)을 지원한다. l  최악의 실행 시간(WCET, Worst-Case Execution Time) 분석(부가적인 이득)에 대해서 지원한다. l  변경과 요구사항에 미치는 영향의 충격을 발견한다.

 

DC와 달리 CC에는 첫 부분에 특이한 내용이 나온다. 바로 CC가 DC를 보완하는 역할을 한다는 것이다. 사실 필자는 지금까지 DC와 CC는 동등한 레벨로 생각해서 둘 다 같은 비중으로 준비해야 하는 것으로 인식하고 있었다. 오히려 DC가 CC의 보완재로 생각을 했었는데 그런 필자의 잘못된 판단을 여기서 바로잡아 주고 있다. 그 외의 항목에 대해서는 DC에서와 마찬가지로 이해하기 어려운 부분은 없을 것이다.

 

정리해 보면 통합 시험을 통해서 DC가 전반적으로 분석되고 CC를 통해서 부족한 부분을 추가로 확인하게 된다. 그런 과정에서 위에서 정리한 CAST 관점에서 보는 것들을 하나하나 꼼꼼히 살펴보아야 한다. 그리고 그에 일치하는 부분은 DER에게 증빙으로 제출할 수 있어야 하며 일치하지 않는 부분은 수정하거나, 그대로 유지하는 경우 그에 합당한 이유를 DER에게 설명할 수 있어야 한다.

 

하나하나가 결코 쉽지 않은 일이다. 그리고 아무리 비싸고 좋은 툴을 사용한다고 하더라도 이 모든 것을 완벽하게 자동화로 지원하는 툴은 아직 존재하지 않는다. 따라서 사람이 직접 수행해야 하는 부분이 상당히 많다.

 

(3)   DC/CC 커버리지 분석에 대한 방법론

 

이제 이러한 DC/CC 커버리지 분석을 제대로 수행하기 위한 방법에 대해서 CAST가 제시하는 방안을 정리해 보자.

 

우선 기본적으로 가장 중요한 것은 설계를 제대로 하는 것이다. DC/CC를 수행하는 목적이 결국 의도한 설계대로 제대로 만들었는지를 확인한다고 봤을 때 설계가 제대로 되어 있지 않게 되면 결국 DC/CC를 통해서 확인할 부분이 많아지게 되는 것이다. CAST-19에서는 이렇게 설명하고 있다.

 

해석을 보자.

 

4.1 훌륭한 설계와 통합 실행의 장점   인증당국은 훌륭한 설계를 구체화하고 잘 정의된 통합 실행을 가진 지원자들은 Data Coupling과 Control Coupling 이슈들을 구분하고 설명할 수 있으며 다음을 가능하게 한다는 것을 관찰해 왔다.   l  동작에 대해서 더 잘 이해하게 할 수 있다. l  기능을 커버할 시험 케이스들과 지원 코드 구조, 코드 인터페이스 그리고 요구사항의 수를 감소시킬 수 있다. l  효율적이고 효과적인 변경 충격 분석을 수행할 수 있다. l  랩시험에서 발견하기 어렵고 필드에서는 수정하기에 비용이 많이 드는 에러들을 발견할 수 있다. l  더 효과적인 유지를 수행할 수 있다.

 

지금까지 인증당국에서 DO-178 인증을 진행하면서 실제 사례들을 보았을 때 기본적으로 설계를 제대로 하고 그것을 통합시험으로 제대로 확인하는 것이 위와 같은 가시적인 효과가 있다는 점을 확인했다고 설명하고 있다.

 

이제 제대로 된 설계와 통합 시험의 중요성을 바탕으로 CAST-19에서 제시하는 DC/CC 커버리지 분석 수행 방법과 과정에 대해서 확인해 보자.

 

해석을 보자.

 

4.2 Data Coupling과 Control Coupling 분석 목표를 만족시키기 위한 가이드라인   인증당국은 항공 소프트웨어에 Data Coupling과 Control Coupling 분석을 적용하는 데 많은 문제점을 발견해 왔다. 아래의 가이드라인은 이러한 이슈들을 적극적으로 설명하는 것을 도와준다.   l  지원자는 그들의 계획문서에 Data Coupling과 Control Coupling을 기술해야 한다. (즉, 그들이 이러한 분석들을 어떻게 수행할 지를 선행해서 계획하라) 어떤 경우에는 여러 계획들 사이에 분산되어 있을 수 있다. 아무리 그것이 문서화되더라도 그것은 완전하고 정확한 타당성을 제공해야 한다. (즉, 그것은 완전해야 한다) l  지원자는 그들의 개발/설계 노력의 일부로써 Data Coupling과 Control Coupling을 고려해야 한다. (예를 들면, 컴포넌트 간의 인터페이스(I/O) 요구사항과 의존성을 구체화하라) l  지원자는 목표를 만족하는 “분석” 그리고/혹은 “시험” 특성에 대한 그들의 타당성을 구체화할 수 있어야 한다. 그 목표는 정적 활동(예를 들면 Link Map이나 Call Tree를 살펴보기), 동적 활동(예를 들면 시험 수행), 혹은 양쪽의 조합으로 충족될 수 있다. l  지원자는 Data와 Control Coupling 분석이 두 개의 서로 다른 분석이라는 것을 인식해야 한다. (즉, 그것들은 하나의 활동으로 합쳐져서는 안 된다) l  만약 툴이 사용된다면 그것이 인증을 받아야 하는지 혹은 그렇지 않은지에 대한 결정이 평가되거나 정당화되어야 한다. l  만약 선택적인 링커가 사용된다면 Data Coupling과 Control Coupling에 미치는 영향이 분석되어야 한다.

 

위의 내용은 기본적으로 DO-178 인증 획득을 위한 과정을 기준으로 설명하고 있다. 그래서 중간에 툴인증에 대한 내용도 포함되어 있다. 비록 전부는 아니지만 일부 구체적인 예시와 함께 DO-178 인증을 위해서 반드시 고려해야 할 내용들이 함께 제시되고 있어서 실제 진행하는 경우에 실질적인 도움이 될 수 있는 내용들이다.

 

그럼 각각의 내용을 조금 더 자세히 살펴보자.

 

①     계획 문서에 반영

 

l  지원자는 그들의 계획문서에 data coupling과 control coupling을 기술해야 한다. (즉, 그들이 이러한 분석들을 어떻게 수행할지를 선행해서 계획하라) 어떤 경우에는 여러 계획들 사이에 분산되어 있을 수 있다. 아무리 그것이 문서화되더라도 그것은 완전하고 정확한 타당성을 제공해야 한다. (즉, 그것은 완전해야 한다)

 

위의 설명은 결론적으로 SVP(Software Verification Plan) 문서에 DC/CC를 어떻게 수행할 지를 작성하라는 것이다. DO-178 가이드라인에 보면 아래와 같이 SVP 문서에 커버리지 분석에 대한 내용이 포함되어야 한다고 가이드하는 부분을 확인할 수 있다.

 

DO-178에서는 계획 문서가 아주 중요하다. 기본적으로 인증과 관련된 주요 내용은 계획 문서에 모두 작성되어 있어야 한다. DC/CC를 포함한 커버리지 분석에 대한 내용도 당연히 포함되어 있어야 한다. 계획 수준이므로 상세하게 작성할 필요는 없지만 DER이 그 내용을 보고 어떤 식으로 진행할 지를 이해할 수 있는 정도의 수준으로는 작성되어야 한다. 참고로 작성이 어려운 경우에는 DER과 상의해서 작성할 수 있다.

 

②     설계에 반영

 

l  지원자는 그들의 개발/설계 노력의 일부로써 Data Coupling과 Control Coupling을 고려해야 한다. (예를 들면, 컴포넌트 간의 인터페이스(I/O) 요구사항과 의존성을 구체화하라)

 

위의 내용은 결국 소프트웨어 설계 시 결합도(Coupling)와 응집도(Cohesion)를 고려하라는 말이다. 예를 든 컴포넌트 간의 인터페이스가 당연히 설계에 포함될 텐데 그에 대한 요구사항과 함께 의존성을 고려해서 설계에 반영해야 한다. 그렇게 함으로써 DC/CC에 대한 고려가 반영되는 것이다.

 

③     구체적인 DC/CC 커버리지 분석 활동의 예시

 

l  지원자는 목표를 만족하는 “분석”과/혹은 “시험” 특성에 대한 그들의 타당성을 구체화할 수 있어야 한다. 그 목표는 정적 활동(예를 들면 Link Map이나 Call Tree를 살펴보기), 동적 활동(예를 들면 시험 수행), 혹은 양쪽의 조합으로 충족될 수 있다.

 

여기에서 일부 구체적인 방법이 아래와 같이 제시되고 있다.

 

-       정적활동: Link Map 분석, Call Tree 분석

-       동적활동: 시험 수행

 

DC/CC 커버리지 분석은 위에서 제시된 것들 이외에도 다양한 방법을 사용할 수 있다. 그리고 분석에 대한 출력은 커버리지 분석툴이나 개발도구 등의 도움을 받아서 추출할 수도 있다. 문제는 이렇게 추출된 결과를 누가 어떻게 확인하고 분석하느냐이다. 현실적으로는 주로 개발자들이 할 수밖에 없을 텐데 개발을 진행하면서 그런 부분을 제대로 수행하는 것이 결코 쉽지 않다는 점을 염두에 두어야 한다. 따라서 혹시 커버리지 분석툴을 구매하는 경우라면 판매처를 통해서 일정 부분 지원을 받는 방법도 고려해 볼 수 있는 부분이다. (물론 추가 비용이 들겠지만) 참고로 이런 부분 역시 툴을 구매하기 전에 확인해야 할 부분이라고 할 수 있다.

 

④     DC와 CC의 구분

 

l  지원자는 Data와 Control Coupling 분석이 두 개의 서로 다른 분석이라는 것을 인식해야 한다. (즉, 그것들은 하나의 활동으로 합쳐져서는 안 된다)

 

이 부분은 필자가 잘못 알고 있었던 부분이기도 하다. DC와 CC가 명칭 자체가 달라서 당연히 서로 다른 것은 알고 있었지만 앞서 보았던 것처럼 CC가 DC를 보완하는 역할을 한다는 것을 명확하게 인식하지 못하고 있었던 것이다. DC/CC 커버리지 분석을 할 때 이 점을 명확하게 인식하고 진행해야 정확한 해석과 제대로 된 결과를 얻어낼 수 있다.

 

⑤     툴인증에 대한 고려

 

l  만약 툴이 사용된다면 그것이 인증을 받아야 하는지 혹은 그렇지 않은지에 대한 결정이 평가되거나 정당화되어야 한다.

 

툴인증에 대해서는 우선 필자의 다른 포스팅을 참고하기 바란다.

 

위의 설명은 DC/CC 커버리지 분석을 위해서 툴을 사용하는 경우 툴에서 나온 결과물을 어떻게 받아들이느냐에 대한 내용이다. 결과물을 아무런 의심 없이 그대로 사용하겠다면 (즉 결과물을 일일이 확인하지 않는다면) 그 결과를 만든 툴에 대해서 툴인증을 받아야 한다. 툴인증을 받지 않는다면 그 결과물은 하나하나 확인되어야 한다. 그리고 그렇게 확인한 증빙을 DER에게 보여줄 수 있어야 한다.

 

⑥     링커(Linker)의 영향에 대한 고려

 

l  만약 선택적인 링커가 사용된다면 Data Coupling과 Control Coupling에 미치는 영향이 분석되어야 한다.

 

이 부분은 필자가 이해하기로는 링크 과정에 영향을 주는 옵션에 대한 내용이 아닌가 싶다. 그와 별개로 링커는 많은 모듈로 구성된 소프트웨어의 연결을 결정하는 중요한 역할을 하므로 그 부분에 어떤 영향이 있다는 것은 그 결과물에도 영향을 미치는 것이므로 원칙적으로는 DC/CC에 미치는 영향을 분석하는 것이 당연하다. 다만 현실적으로 그런 수준까지 확인하고 고려할 수 있는지에 대해서는 의구심이 드는 것도 사실이다.

 

이상으로 DC/CC 커버리지 분석에 대해서 FAA에서 제공하는 참고문서인 CAST-19에 대해서 알아보았다. 개념과 방법에 대한 충분한 이해까지는 아니더라도 어느 정도 방향은 잡을 수 있는 정도의 내용이 아니었나 싶다. 그럼에도 아직 이해가 안 되는 분이 있다면 DER이나 툴을 판매하는 담당자의 도움을 받을 것을 추천한다. 특히 툴을 판매하는 곳에서는 기본적인 교육도 무료로 진행하는 곳이 많기 때문에 그런 부분을 놓치지 말고 활용하도록 하자. 물론 여의치 않은 경우에는 구글링 등을 통해 참고자료를 확인하면서 독학(?)을 하는 방법이 있을 것이다. 때로는 실제 진행 과정에서 이해가 되는 부분도 많을 것이다. 결코 쉬운 주제가 아니기 때문에 제대로 이해하는 시점까지는 실전에서의 시행착오도 반드시 거쳐야 하는 과정 중 하나가 될 것이다.