개념: 메트릭
메트릭은 서로 다른 항목이나 시간 기간을 비교하기 위한 품질 표준의 척도로 사용되는 숫자입니다.
관계
관련 요소
기본 설명

측정해야 하는 이유

측정은 기본적으로 프로젝트의 제어를 얻어 프로젝트를 관리하기 위해 수행됩니다. 완료, 품질, 요구사항 준수 등의 관점에서 계획에 설정된 목표에서 얼마나 떨어져 있는지 또는 얼마나 근접해 있는지 평가하기 위해 측정합니다.

또한 지나간 경험을 바탕으로 새 프로젝트 노력, 비용 및 품질을 보다 잘 예상하기 위해서도 측정합니다. 마지막으로, 시간 경과에 따라 프로세스 성능의 주요 측면에서 개선 방법을 평가하여 변경이 미친 영향을 보기 위해 측정합니다.

프로젝트의 일부 주요 측면 측정에는 무시할 수 없는 비용이 추가됩니다. 따라서 측정 가능하다고 해서 다 측정하지는 않습니다. 이런 노력을 위해 아주 정확한 목적을 설정하고 이 목적을 충족시킬 수 있는 메트릭만 수집해야 합니다.

두 가지 유형의 목적이 있습니다.

  1. 지식 목적: 평가, 예측, 모니터와 같은 단어를 사용하여 표현할 수 있습니다. 개발 프로세스를 더 잘 이해하고 싶습니다. 예를 들어, 제품 품질을 평가하거나, 테스트 노력을 예측하기 위한 데이터를 확보하거나, 테스트 적용 범위를 모니터하거나, 요구사항 변경을 추적할 수 있습니다.
  2. 변경 또는 달성 목적: 증가, 감소, 개선 또는 달성과 같은 단어를 사용하여 표현됩니다. 보통 시간이 지남에 따라 하나의 반복에서 다른 반복으로, 하나의 프로젝트에서 다른 프로젝트로 변경되거나 개선되는 방법을 보는 데 관심이 있습니다.

예제:

  • 계획과 비교하여 진행상태 모니터
  • 고객 만족도 개선
  • 생산성 개선
  • 예측 가능성 개선
  • 재사용 증가

이와 같은 일반 관리 목적은 손쉽게 메트릭으로 변환되지 않습니다. 이 목적을 프로젝트 구성원이 목적을 달성하기 위해 취해야 하는 조치를 식별하는 더 작은 하위 목적(또는 조치 목적)으로 변환해야 합니다. 그리고 관련된 인원들이 이점을 이해하는지 확인해야 합니다.

예제

"고객 만족도 개선"을 위한 목적은 다음과 같이 분해됩니다.

  • 고객 만족도 정의
  • 몇 개의 릴리스에 거쳐 고객 만족도 측정
  • 만족도의 향상 여부 확인

"생산성 개선"을 위한 목적은 다음과 같이 분해됩니다.

  • 노력 측정
  • 진행상태 측정
  • 몇 개의 반복 또는 프로젝트에 걸친 생산성 계산
  • 결과 비교

하위 목적 중 일부(모두가 아님)에서는 특정 메트릭을 수집해야 합니다.

예제

다음에서 "고객 만족도 측정"을 얻을 수 있습니다.

  • 고객 설문조사(고객이 다른 관점에서 평가함)
  • 고객 지원 전화 상담 서비스 통화 횟수 및 심각도

자세한 정보는 [AMI95]를 참조하십시오.

이 목적을 분류하는 유용한 방법은 조직, 프로젝트 및 기술 필요에 따라 분류하는 것입니다. 그러면 위에 설명된 정제를 위한 프레임워크가 제공됩니다.

메트릭에 대한 조직적 요구

조직은 알려진 품질(객관적 및 주관적)의 제품과 적절한 유지보수 요구를 충족시키면서 '항목'당 비용을 알고 개선하여 빌드 시간(출시 시간)을 줄여야 합니다. 조직은 때때로(또는 계속) 경쟁에서 살아남기 위해 성능을 개선해야 합니다. 위험성을 줄이기 위해 조직은 인력의 스킬 레벨 및 경험 레벨을 알아야 하고 선택된 분야에서 경쟁할 능력 및 기타 자원을 가지고 있어야 합니다. 조직은 새 기술을 도입하고 그 기술의 비용 편익을 판별할 수 있어야 합니다. 다음 표는 소프트웨어 개발 조직에 대한 이런 요구와 관련되는 일부 메트릭 유형 예를 나열한 것입니다.

관심사항

메트릭

항목 비용 코드 행당 비용, 기능 점수당 비용, 유스 케이스당 비용. 코드 행당, 기능 점수당 또는 유스 케이스당 정규화된 노력(라이프사이클, 프로그래밍 언어, 인력 등급 등의 정의된 부분에 걸친 노력). 이 메트릭은 보통 단순한 숫자가 아닙니다. 전달하는 시스템의 크기와 스케줄의 단축 여부에 따라 달라집니다.
생성 시간 코드 행당 또는 기능 점수당 경과 시간. 이는 시스템 크기의 영향도 받습니다. 스케줄은 인력을 추가하여 줄일 수도 있습니다(단 일정 수준까지). 조직의 관리 능력에 따라 한계가 정확히 판별됩니다.
전달된 제품의 결함 밀도 코드 행당 또는 기능 점수당 결함(인도 후 발견된 결함) 수
주관적 품질 사용 용이성, 오퍼레이션 용이성, 고객 적합성. 이 요소들의 의미가 명확하지 않더라도 정량화하는 다양한 방법이 고안되어 있습니다.
유지보수성 연간 코드 행당 또는 기능 점수당 비용
스킬 프로파일, 경험 프로파일 인적 자원 그룹은 특정 유형의 스킬 및 경험 데이터베이스를 가질 것입니다.
기술 능력
  • 도구 - 조직은 일반적으로 사용하는 도구와 정기적으로 사용하지 않는 도구에 대한 전문 지식 범위를 알아야 합니다.
  • 프로세스 성숙도 - 예제: SEI CMM 스케일에서 조직 등급의 위치
  • 도메인 능력 - 응용프로그램 도메인에서 조직이 수행할 수 있는 내용
프로세스 개선 척도
  • 프로세스 실행 시간 및 노력
  • 결함 비율, 원인 분석 통계, 수정 비율, 폐기 및 재작업

메트릭에 대한 프로젝트 필요사항

프로젝트는 전달 이전에 다음 기준을 충족해야 합니다.

  • 필수 기능적 및 비기능적 능력
  • 다양한 기술 제한조건
  • 예산 및 스케줄 제한조건
  • 특정 전이, 운영 및 유지보수 특성

프로젝트 관리자는 이와 같은 목적을 향해 나아가고 있는지 확인할 수 있어야 합니다. 프로젝트 측정과 관련하여 고려할 사항에 대한 아이디어가 다음 표에 표시됩니다.

관심사항

프로젝트 노력 및 예산
  • 프로젝트가 계획과 비교하여 노력 및 비용을 추적하는 방법은?
프로젝트 스케줄
  • 프로젝트가 해당 이정표를 충족시킵니까?
전이/설치
  • 예측된 노력, 비용 및 스킬 요구사항이 허용 가능합니까?
오퍼레이션
  • 예측된 노력 및 스킬 요구사항을 고객이 지원할 수 있습니까?
유지보수성/지원 가능성
  • 예측된 노력 및 스킬 요구사항이 고객에게 허용 가능합니까?
기능적 요구사항
  • 요구사항이 올바르고 완전합니까?
  • 요구사항이 반복에 할당되어 있습니까?
  • 요구사항이 계획에 따라 실현됩니까?
비기능적 요구사항
  • 성능
    • 시스템이 응답성, 처리량, 복구 시간에 대한 요구사항을 충족시킵니까?
  • 용량
    • 시스템이 요구된 동시 사용자 수를 처리할 수 있습니까? 웹 사이트가 초당 요구된 히트 수를 처리할 수 있습니까? 필수 고객 레코드 수를 위해 충분한 저장영역이 있습니까?
  • 품질 요소
    • 신뢰성: 시스템 실패가 허용되는 빈도는? 시스템 실패를 구성하는 내용은?
    • 사용성: 시스템 사용이 쉽고 즐겁습니까? 사용 방법과 필수 스킬을 학습하는데 어느 정도의 기간이 걸립니까?
    • 결함 허용치/견고함/탄력성/존속성: 실패 발생 시 시스템이 계속 작동할 수 있습니까? 시스템이 잘못된 입력을 잘 처리할 수 있습니까? 시스템이 실패 후 자동 복구할 수 있습니까?
  • 특수 엔지니어링 요구사항
    • 안전성: 시스템을 생명 또는 자산에 대한 위험성 없이 수행할 수 있습니까(확실 또는 불확실)?
    • 보안/개인정보: 시스템이 권한 없는 액세스로부터 민감한 데이터를 보호합니까? 시스템이 고의적 액세스로부터 안전합니까?
    • 환경 영향: 시스템이 환경 요구사항을 충족시킵니까?
  • 기타 규제 또는 법적 요구사항
  • 제한조건
    • 외부 환경: 시스템이 미리 정해진 환경에서 동작할 수 있습니까?
    • 자원, 호스트, 대상: 시스템이 CPU, 메모리, 언어, 하드웨어/소프트웨어 환경, 제한조건을 충족시킵니까?
    • COTS(Commercial-off-the-shelf) 및 다른 기존 소프트웨어 사용: 시스템이 재사용 제한조건을 충족시킵니까?
    • 인력 가용성 및 스킬: 주어진 인력 수 및 유형으로 시스템을 빌드할 수 있습니까?
    • 인터페이스 지원/호환성: 시스템이 다른 시스템으로(부터) 요구된 액세스를 지원할 수 있습니까?
    • 재사용가능성: 시스템이 재사용가능하도록 만들어진 규정은 무엇입니까?
    • 부과된 표준: 시스템 및 개발 방법을 준수합니까?
    • 기타 디자인 제한조건(예: 아키텍처, 알고리즘): 시스템이 요구된 아키텍처 스타일을 사용하고 있습니까? 미리 정해진 알고리즘을 사용하고 있습니까?

이는 포괄적이지만 철저하지는 않은 프로젝트 관리자 관심사항 목록입니다. 대부분 메트릭 분석 및 콜렉션을 필요로 하며, 일부는 조사하는 질문에 응답하기 위한 특정 테스트(척도를 도출하기 위한) 개발도 필요로 합니다.

메트릭에 대한 기술 필요사항

많은 프로젝트 필요사항에 직접적인 척도가 없습니다. 직접적인 척도가 있어도 개선하기 위해 수행하거나 변경해야 할 사항이 명백하지 않을 수 있습니다. ISO 표준 9126(소프트웨어 품질 특성 및 메트릭)에 식별된 속성과 프로젝트 필요사항에서 위에 언급된 속성과 같은 다양한 상위 레벨 품질 속성에 비해 하위 레벨 품질 속성을 사용하여 품질을 빌드할 수 있습니다. 이와 같은 기술 척도는 프로젝트 레벨 메트릭 필요사항에 기여하는 엔지니어링(구조 및 동작) 특성 및 영향(프로세스 및 제품 관련)의 척도입니다. 다음 표의 속성을 사용하여 RUP 중간 산출물 및 프로세스에 대한 메트릭 샘플 세트를 도출했습니다. 이 샘플은 중간 산출물 가이드라인: 메트릭에서 볼 수 있습니다.

품질

속성

요구사항의 우수성
  • 휘발성: 새 요구사항 도입 비율, 변경 빈도
  • 유효성: 올바른 요구사항입니까?
  • 완전성: 요구사항이 누락되어 있습니까?
  • 표현식의 정확성: 요구사항이 적절히 제시되었습니까?
  • 명백성: 설명을 이해할 수 있고 명백합니까?
디자인의 우수성
  • 결합: 시스템 요소 사이의 연결이 얼마나 광범위합니까?
  • 결합력: 컴포넌트 각각에 잘 정의된 단일 목적이 있습니까?
  • 원시성: 클래스의 메소드 및 오퍼레이션을 클래스의 다른 메소드 및 오퍼레이션에서 생성할 수 있습니까? 생성할 수 있는 경우 원시성(원하는 특성)이 아닙니다.
  • 완전성: 디자인이 요구사항을 완전히 실현합니까?
  • 휘발성: 아키텍처 변경 빈도.
구현의 우수성
  • 크기: 구현이 얼마나 (문제점을 해결하기 위해) 최소 크기에 근접해 있습니까. 구현이 제한조건을 충족시킵니까?
  • 복잡도: 코드가 알고리즘 방식에서 어렵거나 복잡합니까? 이해하고 수정하기가 어렵습니까?
  • 완전성: 구현이 모든 디자인을 정확하게 실현합니까?
테스트의 우수성
  • 적용 범위: 테스트 연습에서 소프트웨어가 얼마나 제대로 수행됩니까? 모든 지시사항이 테스트 세트에 의해 실행됩니까? 테스트 연습이 코드를 통해 많은 경로로 수행됩니까?
  • 유효성: 테스트 자체가 요구사항의 올바른 반영입니까?
프로세스의 우수성(최하위 레벨)
  • 결함 비율, 결함 원인: 타스크에서 결함 발생 빈도는 얼마입니까? 원인을 무엇입니까?
  • 노력 및 지속 기간: 활동에 요구되는 지속 기간과 인적 노력은 어느 정도입니까?
  • 생산성: 인적 노력 단위당 활동에서 생성되는 것은 무엇입니까?
  • 중간 산출물의 우수성: 타스크 산출물에서 결함 레벨은 무엇입니까?
프로세스/도구 변경 유효성 (프로세스 우수성과 같지만 총 값이 아니라 백분율 변경임)
  • 결함 비율, 결함 원인
  • 노력 및 지속 기간
  • 생산성
  • 중간 산출물의 우수성

메트릭 개념에 대한 보다 자세한 내용은 [WHIT97]을 참조하십시오.

메트릭의 개념

두 가지 유형의 메트릭을 구별합니다.

  • 메트릭은 엔티티의 측정 가능한 속성입니다. 예를 들어, 프로젝트 노력은 프로젝트 크기의 척도(즉, 메트릭)입니다. 이 메트릭을 계산할 수 있으려면 프로젝트의 모든 작업시간 현황표 기장을 합산해야 합니다.
  • 기본 메트릭은 메트릭 계산에 사용되는 원래 데이터 항목입니다. 위의 예에서 작업시간 현황표 기장은 기본 메트릭입니다. 기본 메트릭은 일반적으로 데이터베이스에는 존재하지만 분리되어 해석되지 않는 메트릭입니다.

각 메트릭은 하나 이상의 수집된 메트릭으로 구성됩니다. 당연히 각 기본 메트릭은 명백하게 식별되어야 하며 해당되는 콜렉션 프로시저가 정의되어야 합니다.

변경 또는 달성 목적을 지원하기 위한 메트릭은 종종 시간 경과에 따른 "첫 번째 파생"(또는 반복이나 프로젝트)입니다. 여기에서는 절대값이 아니라 상태동향에 관심이 있습니다. "품질을 개선"하려면 알려진 결함의 나머지 레벨이 시간이 지나면서 감소하는지 확인해야 합니다.

템플리트

메트릭 템플리트

이름 메트릭의 이름 및 알려진 동의어
정의 이 메트릭을 사용하여 측정된 엔티티의 속성, 메트릭 계산 방법 및 계산의 기초가 된 기본 메트릭
목적 이 메트릭에 관련되는 목적 및 질문 목록. 또한 메트릭을 수집하는 이유에 대한 일부 설명
분석 프로시저 메트릭을 사용하려는 방법. 메트릭 해석의 전제 조건(예: 다른 메트릭의 올바른 범위). 대상 값 또는 상태동향. 사용할 분석 기법 및 도구 모델. 내재된 가정사항(예: 환경 또는 모델의 가정사항). 측정 프로시저. 저장영역
책임 측정 데이터를 수집 및 집계하고 보고서를 준비하며 데이터를 분석할 사람

기본 메트릭 템플리트

이름 기본 메트릭의 이름
정의 프로젝트 환경 관점에서 메트릭의 명백한 설명
콜렉션 프로시저 콜렉션 프로시저의 설명. 사용할 데이터 콜렉션 도구 및 양식. 라이프사이클에서 데이터가 수집되는 위치. 사용할 검증 프로시저. 데이터 저장 위치, 형식, 정밀도
책임 데이터를 수집해야 하는 사람. 데이터를 확인해야 하는 사람

메트릭 타스크

두 가지의 타스크가 있습니다.

  • 측정 계획 정의
  • 척도 수집

측정 계획 정의는 일반적인 계획 활동의 일부로, 또는 간혹 개발 사례에서 프로세스 구성의 일부로 개발 주기마다 한 번 수행됩니다(도입/인식(Inception) 단계에서 수행). 소프트웨어 개발 계획의 다른 섹션과 마찬가지로 프로젝트 과정 중에 측정 계획을 다시 살펴볼 수 있습니다.

척도 수집은 반복마다 최소 한 번, 때때로 더 자주 되풀이되어 수행됩니다(예: 여러 달에 걸친 반복에 대해 매주 수행).

수집된 메트릭은 프로젝트의 진행상태 및 성능 평가 시 이용할 상태 평가 문서의 일부입니다. 나중에 프로젝트 예상 및 조직 전체의 상태동향에 사용하기 위해 메트릭이 누적될 수도 있습니다.

메트릭 사용 방법

예상

특히 프로젝트 관리자는 예산 및 스케줄을 사용하여 타스크에 자원을 지정하는 계획을 세워야 합니다. 생성할 내용을 판단하여 노력과 스케줄을 예상하거나, 그 반대로 고정된 자원 및 스케줄이 있으며 생성할 수 있는 내용을 예상해야 합니다. 예상은 일반적으로 계획 목적을 위해 다른 요소(일반적으로 크기 및 생산성)를 기반으로 하는 자원 요구의 계산과 관련됩니다.

예측

예측(prediction)은 예상(estimation)과 약간 달라서, 일반적으로 해당 요소와 기타 영향을 주는 요소의 현재 값을 기반으로 특정 요소의 나중 값을 계산하려는 것입니다. 예를 들어, 성능 데이터 샘플이 있을 경우, 전체 로드 하에 있거나 자원 제한 또는 성능 저하 상태의 구성에서 시스템의 성능을 아는 데(예측) 유용합니다. 신뢰성 예측 모델은 결함 비율 데이터를 사용하여 시스템이 특정 신뢰성 레벨에 도달하는 시기를 예측합니다. 활동을 계획한 후, 프로젝트 관리자는 완료 날짜 및 완료 시 노력을 예측할 데이터를 필요로 합니다.

평가

평가는 예를 들어 임계값과의 비교, 상태동향 식별 또는 대안 사이의 비교를 위해 사용되거나 또는 예상이나 예측의 기초로 현재 위치를 설정하는 데 사용됩니다.

프로젝트 관리의 메트릭에 대한 자세한 정보는 [ROY98]을 참조하십시오.