소프트웨어 품질:: 형상관리 측정 지표

소프트웨어 개발에서 형상관리(Software Configuration Management, SCM)는 소프트웨어의 품질과 일관성을 유지하는데 필수적인 역할을 합니다. 따라서 얼마나 충실하게 SCM이 이루어지고 있는지를 확인할 필요가 있는데, 이를 위해 SCM 지표를 알아보고자 합니다. SCM 지표는 개발 과정에서 체계적으로 관리하고 효율성을 높이는데 중요한 도구입니다.

 

1. 버전 관리 지표 (Version Control Metrics)

변경 요청 수 (Number of Change Requests, NCR)

소프트웨어 변경은 프로젝트 과정에서 수시로 발생하며, 요구사항 분석의 오류나 설계 오류, 버그 등 다양한 이유에서 발생하게 됩니다. NCR은 Fred Brooks는 "The Mythical Man-Month"(1975)에서 변경 관리의 중요성이 처음 논의되었습니다. NCR은 프로젝트 일정상 정해진 기간 동안 발생한 변경의 요청의 합을 의미하며, 다음과 같이 표현됩니다.

NCR은 프로젝트의 복잡성과 변경의 빈도를 파악하는데 유용합니다. 높은 변경 요청 수는 빈번한 수정이나 개선이 필요함을 나타낼 수 있습니다.

여기서 (CR_i)는 각 변경 요청을 의미합나다.

변경 주기 (Change Frequency)

NCR은 변경의 갯수라면, 변경 주기는 변경이 발생하는 빈도를 의미합니다. Barry Boehm의 "Software Engineering Economics" (1981)에서 처음 제안되었으며, 변경 요청이 승인되고, 적용된 평균 시간을 계산하며, 다음과 같이 표현됩니다.

변경 주기는 프로젝트 팀의 응답 속도를 나타내며, 높은 변경 주기는 조직내 개발 프로세스의 개선이 필요성을 시사할 수 있습니다.

여기서 (T_{apply})는 변경 요청이 적용된 시간이고, (T_{request})는 변경 요청이 발생한 시간을 의미합니다.

 

2.품질 관리 지표 (Quality Control Metrics)

결함 밀도 (Defect Density or Fault Density)

결함은 크게 Defect와 Fault로 구분할 수 있습니다. 여기서 Defect는 개발 산출물 중 문서화된 산출물에 존재/발생하는 결함을 Defect라고 볼 수 있으며, Fault는 개발 산출물 중 Code 또는 Model에 존재/발생하는 결함을 Fault로 구분해 볼 수 있습니다. DD/FD는 Michael Fagan의 "Design and Code Inspections to Reduce Errors in Program Development"(1976)에서 처음 제안되었으며, 일정 수의 코드 라인수(Line of Code, LOC)대비 발견된 결함 수를 의미하며, 다음과 같이 표현됩니다.

결함 밀도는 주로 소프트웨어 품질을 평가하는데 사용됩니다. 따라서 낮은 결함 밀도는 높은 품질을 의미하며, 높은 결함 밀도는 코드 리뷰나 테스트 프로세스의 개선이 필요함을 나타냅니다.

여기서 (D)는 발견된 결함의 수, (KLOC)는 1,000 라인당 코드 라인 수를 의미합니다.

결함 수정 시간 (Defect Resolution Time)

결함 수정 시간은 결함이 보고된 시점부터 수정이 완료된 시점까지의 평균 시간을 의미하며, Capers Jones의 "Software Quality: Analysis and Guidelines for Success"(1997)에서 처음 제안되었습니다.

결함 수정 시간은 팀의 결함 처리 능력을 평가하는데 유용합니다. 다시 말해 결함 수정 시간이 짧으면 짧을 수록 조직이 효율적인 문제 해결을 할 수 있는 역량이 있다는 의미입니다.

여기서 (T_{fixed})는 결함이 수정된 시간, (T_{reported})는 결함이 보고된 시간을 의미합니다.

 

3. 생산성 지표 (Productivity Metrics)

커밋 빈도 (Commit Frequencty)

커밋 빈도는 다양한 오픈 소스의 프로젝트 성공 사례 분석에서 도출되었습니다. 특히 Eric S. Ramond의 "The Cathedral and The Bazaar" (1999)에서 처음 제안되었으며, 주어진 기간 동안의 커밋 수를 집계합니다.

커밋 빈도는 개발 활동의 빈도를 나타내며, 일정한 커밋 빈도는 지속적인 개발과 일관된 작업 패턴을 의미합니다.

여기서 (C)는 특정 기간동안의 커밋 수, (T)는 기간의 길이 (예, Day, Week, Month)를 의미합니다.

코드 라인 수 (Lines of Code, LOC)

코드 라인 수는 프로젝트 기간 중 작성된 코드 라인수를 의미합니다. 이때 코드 내 공백과 주석은 제외하고 라인수를 계산하게 되며, Tom DeMarco의 "Controlling Software Projects: Management, Measurement, and Estimates"(1982)에서 처음 제안되었으며, 개발자의 생산성을 평가하는데도 사용될 수 있지만, 코드의 질적인 측면을 고려하지 않으므로 단독으로 사용되기보다는 다른 지표와 함께 사용하는 것이 좋습니다.

여기서 (LOC_i)는 각 파일의 코드 라인 수를 의미합니다.

 

4. 프로젝트 관리 지표 (Project Management Metrics)

프로젝트 완료 비율 (Project Completion Rate)

프로젝트 완료 비율은 완료된 작업 항목 또는 구현해야 할 기능 리스트 상의 기능의 수를 전체 작업 항목 또는 기능의 수로 나누어 백분율로 표현합니다. 프로젝트 완료 비율은 Watts Humphrey의 "Managing the Software Process" (1989)에서 처음 제안되었으며, 프로젝트의 진행상황을 평가하는데 유용하며, 높은 완료 비율은 프로젝트가 계획대로 진행되고 있음을 의미합니다.

여기서 (T_{completed})는 완료된 작업 또는 구현된 기능 수를 의미하며, (C_{total})은 전체 작업 항목 또는 전체 기능 리스트에서 기능의 수를 의미합니다.

일정 준수율 (Schedule Adherence Rate)

일정 준수는 Barry Boehm의 "Software Engineering Economics" (1981)에서 처음 제안되었으며, 계획된 일정 대비 실제 완료된 일정의 비율을 계산합니다. 일정 준수율은 프로젝트 시간 관리 능력을 평가하며, 낮은 준수율은 일정 관리의 개선 필요성을 시사합니다.

여기서 (T_{planned})는 계획된 일정, (T_{actual})은 실제 완료된 일정을 의미합니다.

 

5. 테스트 커버리지 지표 (Test Coverage Metrics)

코드 커버리지 (Code Coverage)

코드 커버리지는 일반적으로 단위 테스트의 품질을 평가하기 위한 지표로 활용됩니다. 그러므로 높은 커버리지는 테스트가 잘 되었다는 것을 의미하지만, 커버리지 비율이 높더라도 테스트 케이스 품질이나 프로젝트 관리 지표와 같은 다른 여러 지표와 함께 해석하는 것이 중요합니다. Glenford J. Myers의 "The Art of Software Testing" (1979)에서 처음 제안되었으며, 여러 커버리지 유형이 있으나, 대표적으로 Statement Coverage의 경우 다음과 같이 정의될 수 있습니다.

기능 커버리지 (Function Coverage)

Boris Beizer의 "Software Testing Techniques"(1990)에서 처음 제안되었으며, 테스트된 기능의 수를 전체 기능의 수로 나누어 백분율로 표현합니다. 높은 기능 커버리지는 중요한 기능들이 테스트되었음을 의미하지만, 코드 커버리지와 마찬가지로 기능의 중요도와 테스트의 질도 함께 고려해야 합니다.

 

6. 유지보수성 지표 (Maintainability Metrics)

복잡도 지수 (Complexity Index)

소프트웨어의 복잡성은 소프트웨어 유지보수를 어렵게 할 수 있습니다. 따라서 간단하고 직관적인 코드의 구조를 유지하는 것이 중요합니다. Thomas J. McCabe의 "A Complexity Measure" (1976)에서 처음 제안되었으며 싸이클로매틱 복잡도(Cyclomatic Complexity)가 대표적입니다. 싸이클로매틱 복잡도는 소스코드에 대한 제어 흐름 그래프에서 독립적인 경로의 수를 계산한 것으로 다음과 같이 계산됩니다.

통상 소프트웨어 복잡도는 1~10이면 복잡도가 낮다고 판단하며, 11~20은 보통, 그리고 21이상은 복잡도가 높다고 볼 수 있습니다. 다만, 이는 일반적인 내용일뿐 각 산업별, 제품군별, 조직별로 다른 기준으로 판단될 수 있습니다.

여기서 (E)는 그래프의 엣지 수, (N)은 노드 수, (P)는 연결된 컴포넌트의 수를 의미합니다.

변경 영향도 (Change Impact)

변경 영향도는 변경된 코드에 영향을 받는 모듈의 수를 지표화 한 것으로 "Software Engineering Body of Knowledge (SWEBOK)"에서 처음 언급되었습니다. 변경 영향도는 코드 변경시 영향을 받는 모듈의 범위를 평가하는 것으로 높은 변경 영향도는 변경 시 리스크가 크다는 것을 의미하므로, 모듈 간의 의존성을 줄이는 것이 좋습니다.

여기서 (M_{impacted})는 영향을 받은 모듈 수, (M_{total})는 전체 모듈의 수를 의미합니다.

 

7. 성능 지표 (Performance Metrics)

응답 시간 (Response Time)

시스템이 입력을 받고 응답을 반환하는데 걸리는 평균 시간을 측정하는 것으로 짧은 응답 시간은 시스템의 성능이 좋음을 의미하며, 긴 응답 시간은 성능 튜닝이 필요함을 나타냅니다.

자원 사용율 (Resource Utilization)

Raj Jain의 "The Art of Computer Systems Performance Analysis" (1991)에서 처음 언급되었으며, 사용된 자원의 양을 총 자원 양으로 나누어 백분율로 표시한 지표입니다. 어떤 자원이 사용되었는지에 대한 검토 및 전처리가 필요하며, 높은 자원 사용율은 자원이 효율적으로 사용되고 있음을 나타내지만, 과도한 사용율은 병목 현상을 초래할 수도 있습니다.

 

---

이 밖에도 소프트웨어 형상관리를 위한 지표들이 존재할 수 있습니다. 그리고 소프트웨어 형상관리만을 위한 지표가 따로 정의되지 않을 수도 있습니다. 그러나 위에 정리된 여러 지표들을 조합하여 형상관리 적절성을 평가할 수 있을 것으로 생각합니다. 또한 각 지표는 소프트웨어 개발 및 관리 과정에서 특정한 목적을 위해 사용되며, 정확한 해석을 위해서는 프로젝트의 특성과 상황을 고려하는 것이 중요합니다. 또한 소프트웨어 형상관리 지표를 효괒거으로 활용하면 프로젝트의 전반적인 성공 확률을 높일 수 있으며, 체계적인 접근 방식을 통해 더욱 높은 품질의 소프트웨어를 개발할 수 있습니다.

 

 

2024.07.03 - [System & Software Engineering] - 소프트웨어 형상관리와 소프트웨어 개발

소프트웨어 형상관리와 소프트웨어 개발

 

2021.01.24 - [System & Software Engineering] - 소프트웨어 신뢰성 관련 용어 정리

소프트웨어 신뢰성 관련 용어 정리

 

2021.01.24 - [System & Software Engineering] - 일반적인 소프트웨어 측도 (Measurement)의 유형

일반적인 소프트웨어 측도 (Measurement)의 유형