Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
자동차 한 대에 탑재되는 소프트웨어의 규모가 갈수록 커지고 있습니다. 자율주행, 인포테인먼트, ADAS 등 핵심 기능 대부분이 소프트웨어로 구현되면서, 이제 소프트웨어의 품질이 곧 자동차의 안전과 경쟁력을 의미하게 되었습니다.
하지만 소프트웨어 품질은 눈에 보이지 않아 측정하기 어렵습니다. 어떻게 하면 잠재적인 위험을 예방하고, 우리 제품의 품질이 높다는 것을 객관적으로 증명할 수 있을까요?
이 질문에 대한 해답 중 하나가 바로 HIS Metrics입니다. 이번 포스팅에서는 자동차 소프트웨어 품질을 측정하는 핵심 지표, HIS Metrics에 대해 알아보겠습니다.
01. HIS Metrics란 무엇인가?
"
HIS (Hersteller Initiative Software)
"
'HIS Metrics'를 알기 전에 'HIS'가 무엇인지 먼저 알아봅시다.
HIS는 '제조사 주도 소프트웨어'를 의미하는 독일어(Hersteller Initiative Software)의 약어입니다. 이름 그대로 Audi, BMW, Daimler, Porsche, Volkswagen 등 독일의 주요 자동차 제조사(OEM)들이 모여 결성한 연합체입니다.
이 HIS에서 자동차 ECU 소프트웨어의 품질과 신뢰성을 확보하기 위해 프로그래밍 규칙, 테스트, 툴 체인 등 다양한 분야의 표준을 공동으로 연구하고 정의했습니다. 그게 바로 HIS Metrics입니다.
Source Code Metrics
'Metrics'는 '측정 지표'를 의미합니다. 즉, 소스 코드 메트릭스(Source Code Metrics)란 소프트웨어의 품질과 복잡도 등을 객관적인 수치로 측정하기 위한 기준입니다.
HIS Metrics
결국 HIS Metrics란, 이 HIS 연합에서 정의한 자동차 소프트웨어 품질 측정에 특화된 소스 코드 메트릭스(지표)를 의미합니다.
02. HIS Metrics의 필요성
"
그렇다면 HIS Metrics는 왜 필요할까요?
"
가장 큰 목적은 "복잡성을 낮추고, 유지보수성을 높여" 결함 없는 고품질의 소프트웨어를 만드는 것입니다.
이는 자동차 기능 안전 표준인 ISO 26262와도 밀접한 관련이 있습니다. ISO 26262는 잠재적 위험을 예방하기 위해 코드의 복잡도를 낮추고 테스트 용이성을 높일 것을 요구합니다. HIS Metrics는 이러한 표준을 준수하고 있음을 객관적인 수치로 증명하는 강력한 근거 자료가 됩니다.
또한 많은 OEM들에서 HIS Metric을 요구하는 경우가 많습니다. OEM의 요구사항을 충족하기 위해서는 HIS Metric을 측정하고 관리하는 것은 필수적입니다.
코드 품질 향상
코드의 구조적 문제점을 파악하고 개선합니다.
개발/유지보수 비용 절감
복잡하고 이해하기 어려운 코드를 사전에 식별하여 수정함으로써, 향후 발생할 수 있는 버그 수정 및 기능 추가 비용을 줄입니다.
신뢰성 및 안전성 향상
잠재적 오류 가능성이 높은 코드를 식별하고 제거하여 소프트웨어의 안정성을 높입니다.
03. HIS Metrics의 주요 항목
HIS Metrics는 다음과 같이 다양한 항목을 통해 코드의 상태를 다각도로 측정합니다.
HIS Metrics 주요 항목들
1. COMF : 주석 밀도 (Comment Density) - 코드 내 주석의 비율
2. PATH : 코드 경로 수 (Number of Paths) - 실행 가능한 모든 경로의 수
3. GOTO : goto문 수 (Number of Go to Statements)
4. v(G) : 순환 복잡도 (Cyclomatic Complexity) - 코드의 논리적 복잡도
5. CALLS : 호출하는 함수 수 - (현재 함수가) 호출하는 다른 함수들의 개수
6. CALLING : 호출되는 횟수 - (현재 함수가) 다른 함수들로부터 호출되는 횟수
7. PARAM : 함수 파라미터 수 - 함수가 받는 파라미터(인자)의 개수
8. STMT : 함수 내 문장 수 - 함수 내의 실행 가능한 문장(Instruction)의 수
9. LEVEL : 호출 깊이 (Call Level) - 함수 호출 단계의 최대 깊이
10. RETURN : 반환 지점 수 - 함수 내 return문의 개수
11. Si : 안정성 지수 (Stability Index) - 파일(모듈) 변경 시 영향도
12. VOCF : 언어 범위 (Vocabulary) - 사용된 연산자/피연산자의 다양성
13. ap_cg_cycle : 재귀 호출 수 (Number of Recursions) - 재귀 함수 호출 횟수
14. NOMV : MISRA 위반 총 개수 - MISRA HIS 서브셋 규칙 위반 총합
15. NOMVPR : 규칙 당 MISRA 위반 수 - 개별 MISRA 규칙 당 위반 횟수
04. HIS Metrics 항목 예시 : 순환 복잡도
"
v(G) (순환 복잡도 : Cyclomatic Complexity)
"
앞서 본 15가지 Metrics 중 가장 널리 쓰이는 지표가 바로 이 순환 복잡도(v(G))입니다. 이는 코드의 논리적 복잡성을 측정하며, '얼마나 많은 테스트 케이스가 필요한가'를 가늠하는 척도가 됩니다.
함수는 기본적으로 1의 값을 가지며, if, for, while, switch-case 등 분기문이 추가될 때마다 1씩 증가합니다. v(G) 값이 높을수록(보통 10 이상) 코드가 복잡하고 버그가 발생할 확률이 높다고 판단합니다.
순환 복잡도를 계산하는 방법은 다음과 같이 3가지가 있습니다.
- V(G) = R (R : 영역의 개수)
- V(G) = P + 1 (P : 분기 노드의 개수)
- V(G) = E – N + 2 (E : 간선의 개수, N : 노드의 개수)
다음 예시([그림 1])를 보며 3가지 계산 방법을 순서대로 적용해 보겠습니다.
[그림 1] 순환 복잡도 예시
(1) 영역의 수로 계산 (V(G) = R)
[그림 2] 순환 복잡도 예시 – 영역의 수로 계산
영역을 나눠봤을 때 총 4개의 영역으로 나뉩니다.
따라서 순환 복잡도가 4로 계산됩니다.
(2) 분기문의 개수로 계산 (V(G) = P + 1)
[그림 3] 순환 복잡도 예시 – 분기문의 개수로 계산
[그림 3]에서 분기문이 총 3개인 것을 확인할 수 있습니다.
따라서 3+1 = 4
순환 복잡도가 4로 계산됩니다.
*분기문이란?
조건에 따라 프로그램의 실행 흐름을 변경하는 제어문입니다. 주로 if, else if, else나 switch와 같은 조건문이 이에 해당하며, 주어진 조건의 참/거짓 여부에 따라 특정 코드를 선택적으로 실행하도록 합니다.
(3) 노드와 간선의 수로 계산 (V(G) = E – N + 2)
[그림 4] 순환 복잡도 예시 – 노드와 간선의 수로 계산
Node(노드) 개수가 8개, Edge(간선) 개수가 10개로
식에 적용해보면 v(G) = E – N + 2 = 10 – 8 + 2 = 4가 됩니다.
순환 복잡도가 4로 계산되는 것을 확인할 수 있습니다.
05. HIS Metrics, 정적 분석 도구가 필요한 이유
HIS Metrics는 코드 품질을 객관적으로 보여주는 지표입니다. 하지만 이 모든 항목을 개발자가 코드를 리뷰하며 수동으로 계산하고 관리하는 것은 사실상 불가능합니다. 이때 필요한 것이 바로 정적 분석 도구입니다.
정적 분석 도구는 코드를 실행하지 않고도 소스 코드 자체를 분석하여, HIS Metrics 측정은 물론 잠재적인 오류까지 자동으로 검출해 줍니다.
정적 도구 Helix QAC는 자동으로 코드를 분석하여, 위에서 설명한 모든 HIS Metrics를 자동으로 측정하고 리포트를 생성해줍니다.
[그림 5] HelixQAC HIS Metrics Report
[그림 5]처럼 HIS Meteric Report으로 각 항목을 확인할 수 있습니다.
