-
메트릭은 단순하고 객관적이며 수집하기 쉽고 해석하기 쉬우며 오해할 여지가 적어야 합니다.
-
메트릭 콜렉션은 자동화되어야 하고 간섭이 없어야 합니다. 즉, 개발자 활동으로 개입되지 않아야 합니다.
-
메트릭은 라이프사이클 초반(소프트웨어 품질을 개선하려는 노력이 효과를 가지는 시기)에 품질 평가에 기여해야 합니다.
-
관리 직원 및 엔지니어링 직원은 일관된 형식으로 진행상태 및 품질을 커뮤니케이션하는 데 적극적으로 메트릭의 절대 값 및 상태동향을 사용해야 합니다.
-
메트릭의 최소 또는 보다 포괄적인 세트에 대한 선택사항은 프로젝트 특성 및 컨텍스트에 따라 다릅니다. 프로젝트가 크거나 안전성 또는 신뢰성 요구사항이 엄격하고 개발 및 평가팀이 메트릭에 대한 지식을 많이
가지고 있는 경우 기술적인 메트릭을 수집하고 분석하는 것이 유용할 수 있습니다. 계약에 따라 특정 메트릭을 수집해야 할 수도 있습니다. 또는 조직이 특정 영역의 프로세스에서 도움이 되도록 개선하려고 할 수
있습니다. 모든 상황에 맞는 단순한 대답은 없습니다. 측정 계획을 세운 후 프로젝트 관리자가 적절한 사항을 선택해야 합니다. 그러나 메트릭 프로그램을 처음 도입하는 경우 단순성의 측면에서 실수를 저지르기
쉽습니다.
프로젝트의 특정 측면에 대한 메트릭은 다음을 포함합니다.
-
크기 및 복잡도와 관련된 진행상태
-
요구사항이나 구현, 크기 또는 복잡도의 변경 비율과 관련된 안정성
-
변경 범위와 관련된 모듈화
-
오류의 유형 및 수와 관련된 품질
-
오류 빈도와 관련된 성숙도
-
예상 비용 대 프로젝트 비용과 관련된 자원
상태동향은 시간의 절대값 모니터보다 더 중요합니다.
메트릭
|
목적
|
샘플 척도/관점
|
진행상태
|
반복 계획
완전성
|
-
클래스 수
-
SLOC
-
기능 점수
-
시나리오
-
테스트 케이스
이 척도는 클래스 및 패키지별로 수집할 수 있습니다.
|
안정성
|
수렴성
|
-
변경 유형 및 수(버그 대 개선사항, 인터페이스 대 구현)
이 척도는 반복 및 패키지별로 수집할 수 있습니다.
|
적응성
|
수렴성
소프트웨어 "재작업"
|
이 척도는 반복 및 패키지별로 수집할 수 있습니다.
|
모듈화
|
수렴성
소프트웨어 "폐기"
|
이 척도는 반복별로 수집할 수 있습니다.
|
품질
|
반복 계획
재작업 지표
릴리스 기준
|
-
오류 수
-
결함 발견 비율
-
결함 밀도
-
상속 깊이
-
클래스 결합
-
인터페이스 크기(오퍼레이션 수)
-
대체된 메소드 수
-
메소드 크기
이 척도는 클래스 및 패키지별로 수집할 수 있습니다.
|
성숙도
|
테스트 적용 범위/타당성
사용 시 견고성
|
이 척도는 반복 및 패키지별로 수집할 수 있습니다.
|
비용 프로파일
|
재무 관점
계획 대 실제
|
|
가장 작은 프로젝트에서도 프로젝트의 스케줄 및 예산이 정해져 있는지 판별하고, 그렇지 않은 경우 범위 변경이 필요한지 다시 예상하고 판별하기 위해 진행상태를 추적할 수 있습니다. 따라서 이 최소 메트릭 세트는
진행상태 메트릭에 중점을 둡니다.
-
획득 가치(EV). 이 항목을 사용하여 나머지 프로젝트에서 스케줄 및 예산을 다시 예상하고 범위 변경에 대한 요구를 식별합니다.
-
결함의 상태동향. 이 항목을 사용하여 결함을 제거하는데 필요한 노력을 예상하는데 도움을 줍니다.
-
테스트 진행상태 상태동향. 이 항목을 사용하여 실제로 기능성이 완료된 정도를 판별합니다.
아래에서 더 자세히 설명합니다.
획득 가치(EV)
진행상태를 측정할 때 가장 공통적으로 사용되는 메소드([PMI96])는 획득 가치(EV)
분석입니다.
획득 가치(EV)를 측정하는 가장 단순한 방법은 완료한 모든 타스크에서 원래 예상 노력의 합계를 계산하는 것입니다. 프로젝트의 "완료 백분율"은 프로젝트에서 획득 가치(EV)를 원래 예상 총 노력으로 나누어 계산할
수 있습니다. 생산성(또는 성능 지수)은 완료 타스크에서 소모된 실제 노력으로 나눈 획득 가치(EV)입니다.
예를 들어 코드 노력이 여러 타스크로 나뉘어 있고 현재 대부분 완료된 상황을 가정해 보십시오. 완료된 타스크의 원래 예상은 30일(노력)입니다. 프로젝트의 총 예상 노력은 100일이므로 프로젝트의 약 30%가
완료되었다고 예상할 수 있습니다.
예산 이하에서 타스크를 완료했다고 가정해 보십시오(완료하는 데 25일만 필요함). 성능 지수는 30 / 25 = 1.2 또는 120%입니다.
프로젝트가 20% 예산 이하에서 완료되고 이에 따라 예상값이 줄어들 것으로 예상할 수 있습니다.
고려사항
-
성능 지수는 유사한 타스크에서 예상을 조정하는 경우에만 사용해야 합니다. 요구사항 수집 타스크를 조기에 완료해도 코드가 더 빨리 완료되는 것은 아닙니다. 따라서 유사한 타스크 유형에 대해서만 성능 지수를
계산하고 유사한 타스크에 대해서만 예상을 조정하십시오.
-
기타 요소를 고려하십시오. 유사한 조건에서 유사한 스킬을 가진 직원이 향후 타스크를 수행합니까? 데이터가 "외부 요소"에 의해 오염이 되었습니까(타스크가 심각하게 과대 평가 또는 과소 평가됨)? 보고 시간이
일치합니까(예: 시간 외 근무에 대해 지급받지 않아도 이를 포함해야 함)?
-
최신 타스크의 예상에서 이미 성능 지수를 고려하고 있습니까? 고려하는 경우 성능 지수가 100%에 더 가까워지면서 새 타스크의 예상이 목표에 더 가까워지는 경향이 있습니다. 불완전한 모든 타스크를 일관되게
다시 예상하거나 XP(Extreme Programming)[JEF01]의 다음 사례를
채택해야 합니다. 원래 예상을 "점수"라고 하며, 실제 성능을 조정하지 않은 채 이 동일한 "점수"로 새 타스크를 측정하십시오. "점수"의 장점은 성능상의 증가(또는 저하)를 추적할 수 있다는 점입니다(XP
용어로 "프로젝트 속도"라고 함).
타스크가 큰 경우(5일 초과) 또는 부분적으로 완료된 타스크가 많은 경우 해당 타스크를 분석의 요소로 포함하고자 할 수 있습니다. 주관적인 "완료 백분율"을 적용하고 이 값에 타스크의 예상 노력을 곱한 후 획득
가치(EV)에 포함하십시오. 완료 백분율을 지정할 때 사용할 명확한 규칙이 있으면 결과의 일관성이 더 커집니다. 예를 들어 한 규칙에서 코드 타스크의 완료율이 80% 이상이어야 코드가 코드 검토를 받을 수 있다고
정할 수 있습니다.
획득 가치(EV)는 전체 메트릭 세트: 프로젝트 계획 섹션 아래에서 자세히 논의합니다.
결함의 상태동향
종종 알려진 열림 및 닫힘 상태의 결함의 상태동향을 추적하는 것이 유용합니다. 이는 완료할 결함 수정 작업의 중요한 백로그가 있는지 여부 및 결함을 닫는 속도에 대한 개략적인 표시를 제공합니다.
결함의 상태동향은 Rational ProjectConsole에서 제공하는 메트릭 중 하나에 해당합니다.
고려사항
-
모든 변경 요청의 가중치는 변경 요청으로 코드의 한 행이 영향을 받든지 전체적으로 다시 디자인하게 되든지 상관없이 동일할 수 없습니다. 이 문제는 다음 기법 중 일부를 사용하여 해결할 수 있습니다.
-
외부 요소를 고려하십시오. 실질적인 작업이 필요한 변경 요청은 그렇게 식별되어야 하며, 많은 수의 일반 버그 수정으로 묶는 대신 별도의 타스크로 추적해야 합니다. 많은 수의 작은 수정사항이
상태동향을 주도하는 경우, 변경 요청이 보다 일관된 작업 단위를 표시할 수 있도록 이 수정사항을 그룹화하는 방법을 고려하십시오.
-
더 많은 정보를 기록할 수 있습니다(예: 주관적인 "노력 카테고리", "1일 미만", "5일 미만", "5일 이상").
-
각 변경 요청에서 예상 SLOC 및 실제 SLOC를 기록할 수 있습니다. 아래 소형 메트릭 세트를
참조하십시오.
-
기록할 결함이 부족하다는 것은 테스트가 부족함을 의미할 수 있습니다. 결함의 상태동향을 점검할 때 발생하는 테스트 노력의 레벨에 유의하십시오.
테스트 진행상태 상태동향
완전성의 최종 측정은 얼마나 많은 기능성이 통합되었는지 여부입니다.
각 개발 타스크가 통합된 기능성 세트를 표시하는 경우 획득 가치(EV) 상태동향 차트로도 충분합니다.
진행상태를 커뮤니케이션하는 매우 단순한 방법은 테스트 진행상태 상태동향을 사용하는 것입니다.
고려사항
일부 테스트 케이스는 다른 항목보다 더 많은 가치 또는 노력을 표시할 수 있습니다. 이 그래프에 너무 많은 내용을 바라지는 마십시오. 이 그래프는 완전한 기능성을 향한 진행상태를 보여 줄 뿐입니다.
이전에 설명한 최소 메트릭 세트는 많은 프로젝트에서 충분하지 않습니다.
소프트웨어 프로젝트 관리, 통합 프레임워크[ROY98]에서는 모든 프로젝트에서
다음 메트릭 세트를 권장합니다. 이 메트릭에는 각 변경 요청에서 소스 코드 라인 수(SLOC)의 예상 및 실제 값이 필요합니다. 이 값을 수집하려면 추가 노력이 필요합니다.
메트릭 및 기본요소 메트릭
총 SLOC
|
SLOCt = 코드의 총 예상 크기. 요구사항을 더 잘 이해하고 디자인 솔루션을 마무리하는 경우 많이 변경될 수 있습니다. 팀에서 변경하기 쉬운 재사용 소프트웨어를 포함합니다.
|
구성 중 SLOC
제어
|
SLOCc = 현재 기준선
|
주요 결함
|
SCO0 = 0 유형의 SCO 수(여기서 SCO는 소프트웨어 변경 주문으로, 다른 용어로 변경 요청이라고 함)
|
일반 결함
|
SCO1 = 1 유형의 SCO 수
|
개선 요청
|
SCO2 = 2 유형의 SCO 수
|
새 기능
|
SCO3 = 3 유형의 SCO 수
|
SCO 수
|
N = SCO0 + SCO1 + SCO2
|
열린 재작업(파손)
|
B = SCO1 및 SOC2로 인해 파손된 누적식 SLOC
|
닫힌 재작업(수정)
|
F = 수정된 누적식 SLOC
|
재작업 노력
|
E = 노력 확장 수정 유형의 누적식 0/1/2 SCO
|
사용 시간
|
UT = 실제 사용법 사나리오에서 지정된 기준선이 운영되는 시간
|
최종 제품의 품질 메트릭
이 작은 메트릭 세트에서 일부 흥미로운 메트릭을 도출할 수 있습니다.
폐기율
|
B/SLOCt, 제품 폐기 백분율
|
재작업 비율
|
E/총 노력, 재작업 노력 백분율
|
모듈화
|
B/N, SCO당 평균 파손
|
적응성
|
E/N, SCO당 평균 노력
|
성숙도
|
UT/(SCO0 + SCO1), 평균 결함 시간 간격
|
유지보수성
|
(폐기율)/(재작업 비율), 유지보수 생산성
|
진행 지표
재작업 안정성
|
B - F, 시간에 따른 수정 대 파손
|
재작업 백로그
|
(B-F)/SLOCc, 현재 열린 재작업
|
모듈화 상태동향
|
시간에 따른 모듈화
|
적응성 상태동향
|
시간에 따른 적응성
|
성숙도 상태동향
|
시간에 따른 성숙도
|
다음은 측정할 항목입니다.
-
프로세스 - 소프트웨어 제품 및 기타 중간 산출물을 생성하도록 호출된 타스크 시퀀스
-
제품 - 소프트웨어, 문서 및 모델을 포함하는 프로세스의 중간 산출물
-
프로젝트 - 프로젝트 자원, 타스크 및 중간 산출물 모두
-
자원 - 프로젝트에서 사용 가능한 인력, 메소드 및 도구, 시간, 노력 및 예산
프로세스 특징을 설명하려면 정규 계획 타스크의 최하위 레벨로 측정해야 합니다. 타스크는 예상의 초기 세트를 사용하여 프로젝트 관리자가 계획합니다. 레코드는 작성된 예상 갱신 및 시간에 따른 실제 값을 유지해야
합니다.
메트릭
|
부가 설명
|
지속 기간
|
타스크의 경과 시간
|
노력
|
직원 인력 단위(직원-시간, 직원-일 등)
|
산출물
|
중간 산출물 및 해당 크기와 수량(테스트 활동의 산출물에 결함이 포함됨을 참고)
|
소프트웨어 개발 환경 사용
|
CPU, 저장영역, 소프트웨어 도구, 장비(워크스테이션, PC), 1회용 기기. 이들은 SEEA(Software Engineering Environment Authority)에 의해
프로젝트에 대해 수집될 수 있음에 유의하십시오.
|
결함, 발견 비율, 정정 비율
|
총 복구 시간/노력 및 총 폐기/재작업(측정 가능한 경우) 역시 수집해야 합니다. 이는 결함에 대해 수집되는 정보에서 얻을 수 있습니다(중간 산출물로 간주).
|
변경 요청, 부담 비율, 처분 비율
|
위 시간/노력에서 설명함
|
이 메트릭과 관련이 있는 기타 사건(자유 양식 텍스트)
|
프로세스에 영향을 주는 이벤트의 레코드에 있는 메트릭입니다.
|
직원 수, 시간에 따른 프로파일 및 특성
|
|
직원 교체
|
프로세스가 특히 잘 진행되거나 잘못 진행되는 이유를 사후 검토에서 설명할 수 있는 유용한 메트릭
|
노력 응용프로그램
|
계획 활동의 수행 중 노력이 소비된 방법(비용 계정 관리에 정규 기록된 시간 대비)은 이 생산성의 변수를 설명하는 데 도움이 될 수 있습니다. 예를 들어 노력 응용프로그램의 일부
서브클래스는 다음과 같습니다.
-
훈련
-
숙지
-
관리(management)(예: 팀장이 주도함)
-
관리(administration)
-
연구
-
생산적인 작업. 중간 산출물별로 이 항목을 기록하면 도움이 됩니다. "심사 숙고" 시간과 캡처 시간을 분리하십시오(특히 문서에 대해). 이 항목은 엔지니어 시간 중 얼마의
시간이 문서 프로세스에 소요되는지 프로젝트 관리자에게 알려줍니다.
-
낭비 시간
-
회의
-
검수, 둘러보기, 검토 - 준비 및 회의 노력(이 중 일부는 별도의 활동으로 해당 활동에 투자된 시간 및 노력은 특정 검토 타스크에 대해
기록됨)
|
검수, 둘러보기, 검토(타스크 중 - 별도로 계획되지 않은 검토)
|
이 항목의 수 및 해당 지속 기간과 제기된 문제 수를 기록하십시오.
|
프로세스 편차(비준수로 제기됨, 프로젝트를 변경해야 함)
|
이 항목의 수 및 심각도를 기록하십시오. 추가 교육이 필요하거나 프로세스를 잘못 적용했거나 프로세스 구성 방법이 올바르지 않음을 알리는 지표입니다.
|
프로세스 문제점(프로세스 결함으로 제기됨, 프로세스를 변경해야 함)
|
이 항목의 수 및 심각도를 기록하십시오. 사후 검토에서 유용한 정보이고 SEPA(Software Engineering Process Authority)의 중요한 피드백입니다.
|
Rational Unified Process(RUP)에서 제품은 문서, 모델 또는 모델 요소에 해당하는 중간
산출물입니다. 모델은 모델 요소와 같은 항목의 콜렉션으로, 적용 대상인 모델과 함께 권장 메트릭이 여기에 나열됩니다. 일반적으로 메트릭이 전체 또는 요소로 모델에 적용되는지 여부를 확실히 알 수 있습니다.
명확하지 않은 경우 설명 텍스트가 제공됩니다.
중간 산출물 특성
일반적으로 측정 시 관심이 있는 특성은 다음과 같습니다.
-
크기 - 모델에서 항목의 수, 항목 길이, 항목의 크기 또는 부피 측정
-
품질
-
결함 - 중간 산출물이 지정된 대로 수행하지 않거나 스펙을 준수하지 않거나 다른 원치 않는 특징이 있는 경우 표시
-
복잡도 - 알고리즘 또는 구조의 복잡도 측정. 복잡도가 클수록 구조를 이해하고 수정하기 어렵습니다. 복잡한 구조는 실패할 가능성이 높습니다.
-
결합 - 시스템의 요소가 상호 연결된 정도를 측정
-
응집 - 요소 또는 컴포넌트가 잘 정의된 단일 목적의 요구사항을 충족시키는 정도를 측정
-
원시성 - 클래스의 메소드 또는 오퍼레이션이 클래스에서 제공하는 다른 항목과 복합될 수 있는 정도
-
완전성 - 중간 산출물이 모든 요구사항을 충족시키는 정도를 측정(명시 및 함축 - 이행되지 않은 예상의 위험성을 제한하기 위해 프로젝트 관리자는 가능한 명시적으로
표현하려고 해야 함). 여기서는 충분 및 완전을 서로 구분하지 않습니다.
-
추적성 - 한 레벨의 요구사항이 하위 레벨의 중간 산출물에 의해 만족되며, 다른 방식으로 보면 모든 레벨의 중간 산출물에 존재 이유가 있음을 알리는 표시
-
휘발성 - 결함 또는 요구사항 변경으로 인한 중간 산출물의 불완전함 또는 변경 정도
-
노력 - 중간 산출물을 생성하는 데 필요한 작업(직원-시간 단위) 측정
이 모든 특성이 모든 중간 산출물에 적용되는 것은 아닙니다. 다음 표에서 특정 중간 산출물과 함께 관련 특성이 정제됩니다. 한 특성에 대해 여러 메트릭이 나열된 경우 여러 각도에서 특성에 대한 완전한 설명을
제공하므로 모두 잠재적으로 유용합니다. 예를 들어 유스 케이스 추적성을 고려할 때 궁극적으로 (테스트되는) 구현 모델에 대해 모두 추적 가능해야 합니다. 그 동안 진행상태 측정을 위해, 프로젝트 관리자는 분석
모델에 대해 추적할 수 있는 유스 케이스 수에 관심이 있을 수 있습니다.
문서
권장되는 메트릭은 모든 RUP 문서에 적용됩니다.
특성
|
메트릭
|
크기
|
페이지 수
|
노력
|
직원-시간 단위(프로덕션, 변경 및 복구 포함)
|
휘발성
|
변경, 결함, 열림, 닫힘 수, 페이지 변경
|
품질
|
결함 수를 통해 직접 측정
|
완전성
|
직접 측정되지 않음: 검토를 통해 판단
|
추적성
|
직접 측정되지 않음: 검토를 통해 판단
|
모델
요구사항
요구사항 속성
실제로 모델 요소입니다.
특성
|
메트릭
|
크기
|
-
총 요구사항 수(= Nu + Nd + Ni + Nt)
-
유스 케이스에서 추적할 수( = Nu)
-
디자인, 구현, 테스트에서만 추적할 수( = Nd)
-
구현, 테스트에서만 추적할 수( = Ni)
-
테스트에서만 추적할 수( = Nt)
여기서 요구사항은 유스 케이스에서 모델링할 항목과 모델링하지 않을 항목으로 파티션됨에 유의하십시오. 유스 케이스 추적성은 디자인, 구현 및 테스트를 추적하기 위해 유스
케이스에 지정된 해당 요구사항을 고려한다고 예상합니다.
|
노력
|
|
휘발성
|
|
품질
|
|
추적성
|
|
유스 케이스 모델
특성
|
메트릭
|
크기
|
-
유스 케이스 수
-
유스 케이스 패키지 수
-
보고된 유스 케이스 레벨(IBM 웹 사이트에 있는 백서, "유스 케이스에 기반하여 노력 및 크기 예상" 참조)
-
유스 케이스당 시나리오 수 및 총계
-
액터 수
-
유스 케이스 길이(예: 이벤트 플로우 페이지 수)
|
노력
|
-
직원-시간 단위(프로덕션, 변경 및 복구 포함)
|
휘발성
|
|
품질
|
-
보고된 복잡도(0 - 5, 클래스 레벨의 COCOMO[BOE81]에서 유추, 복잡도 범위는 높은 추상 레벨에서 더 좁아짐, IBM 웹 사이트에 있는 백서, "The Estimation of Effort and Size based on Use
Cases" 참조)
-
결함 - 결함 수, 심각도별(열림, 닫힘 상태)
|
완전성
|
-
완료된 유스 케이스(검토를 받고 형상 관리 중 결함이 나타나지 않음)/식별된 유스 케이스(또는 유스 케이스의 예상 수)
-
요구사항 대 UC 추적성(요구사항 속성에서)
|
추적성
|
|
디자인
분석 모델
특성
|
메트릭
|
크기
|
-
클래스 수
-
서브시스템 수
-
서브시스템의 서브시스템 수
-
패키지 수
-
클래스, 내부, 외부당 메소드 수
-
클래스, 내부, 외부당 속성 수
-
상속 트리 깊이
-
하위 수
|
노력
|
-
직원-시간 단위(프로덕션, 변경 및 복구 포함)
|
휘발성
|
|
품질
|
복잡도
|
-
클래스에 대한 응답(RFC): 상호작용 다이어그램의 전체 세트가 필요하므로 계산이 어려울 수 있습니다.
|
결합
|
|
응집
|
|
결함
|
|
완전성
|
-
완료한 클래스 수/예상 클래스 수(식별됨)
-
분석 추적성(유스 케이스 모델)
|
추적성
|
적용 불가능 - 분석 모델이 디자인 모델이 됩니다.
|
익숙하지 않은 일부 00 특정 기술 메트릭 검토 - 상속 트리 깊이, 하위 수, 클래스에 대한 반응, 오브젝트 간 결합 등. 이 메트릭의 의미 및 히스토리에 대한 자세한 내용은 [HEND96]을 참조하십시오. 이 메트릭 중 몇 가지는 원래 Chidamber 및 Kemerer("A metrics suite for object
oriented design", IEEE Transactions on Software Engineering, 20(6), 1994 참조)에서 제안되었지만, 여기에서는 [HEND96]에 제시된 대로 이 메트릭을 적용하고 LCOM(Lack of Cohesion in Method)의 정의를 선호합니다.
디자인 모델
특성
|
메트릭
|
크기
|
-
클래스 수
-
디자인 서브시스템 수
-
서브시스템의 서브시스템 수
-
패키지 수
-
클래스, 내부, 외부당 메소드 수
-
클래스, 내부, 외부당 속성 수
-
상속 트리 깊이
-
하위 수
|
노력
|
|
휘발성
|
|
품질
|
복잡도
|
-
클래스에 대한 응답(RFC): 상호작용 다이어그램의 전체 세트가 필요하므로 계산이 어려울 수 있습니다.
|
결합
|
|
응집
|
|
결함
|
|
완전성
|
|
추적성
|
구현 모델의 클래스 수/클래스 수
|
구현
구현 모델
특성
|
메트릭
|
크기
|
-
클래스 수
-
파일 수
-
구현 서브시스템 수
-
서브시스템의 서브시스템 수
-
패키지 수
-
클래스, 내부, 외부당 메소드 수
-
클래스, 내부, 외부당 속성 수
-
메소드 크기*
-
속성 크기*
-
상속 트리 깊이
-
하위 수
-
완료 시 예상 크기*
|
노력
|
-
직원-시간 단위(별도의 프로덕션, 변경 및 복구)
|
휘발성
|
-
변경 요청 및 결함 수
-
각 정정 또는 완전 변경의 파손*, 예상(수정 이전) 및 실제(완결 시)
|
품질
|
복잡도
|
-
클래스에 대한 응답(RFC)
-
메소드 복잡도 측정계**
|
결합
|
-
하위 수
-
오브젝트 간 결합(클래스 팬 아웃)
-
메시지 전달 결합(MPC)***
|
응집
|
|
결함
|
|
완전성
|
-
테스트된 클래스 단위 수/디자인 모델의 클래스 수
-
통합된 클래스 단위 수/디자인 모델의 클래스 수
-
구현 추적성(유스 케이스 모델)
-
구현 추적성(요구사항
속성)
-
테스트 모델 추적성 * 테스트 완전성
-
활성 통합 및 시스템 테스트 시간(테스트 프로세스에서 누적됨), 즉, 시스템 운영 시간(성숙도 측정 시 사용)
|
* 코드 크기를 측정하는 일부 메소드를 선택하여 일관되게 적용해야 합니다(예: 주석 없음, 공백 없음). 메트릭으로 '코드 라인'을 적용하는 것과 그 장점을 논의하려면 [ROY98]을 참조하십시오. 또한 '파손'의 정의에 대해서도 위 문서를 참조하십시오.
** 순환 복잡도 사용은 보편적으로 특히 클래스 메소드에 적용하는 경우에는 허용되지 않습니다. 이 메트릭에 대한 논의는 [HEND96]을 참조하십시오.
*** 원래 Li 및 Henry, "Object-oriented metrics that predict maintainability", J. Systems and Software, 23(2), 1993, 및 [HEND96]에서도 설명합니다.
테스트
테스트 모델
특성
|
메트릭
|
크기
|
-
테스트 케이스, 테스트 프로시저, 테스트 스크립트의 수
|
노력
|
-
직원-시간 단위(별도의 프로덕션, 변경 및 복구), 테스트 케이스의 프로덕션 등에서
|
휘발성
|
-
테스트 모델에 대해 파일된 변경 요청 및 결함 수
|
품질
|
-
결함 - 심각도별(열림, 닫힘 상태) 결함 수(테스트 모델 자체에서 발생한 결함, 다른 소프트웨어를 대상으로 테스트팀이 발견한 결함이 아님)
|
완전성
|
-
작성된 테스트 케이스 수/예상 테스트 케이스 수
-
테스트 추적성(유스 케이스 모델)
-
테스트 추적성(요구사항 속성)
-
코드 적용 범위
|
추적성
|
-
테스트 평가 요약에서 성공으로 보고된 테스트 케이스 수/테스트 케이스 수
|
관리
변경 모델 - 일관된 프리젠테이션에 대한 개념 모델 - 이 메트릭은 변경 요청을 관리할 때 사용하는 시스템에서 수집됩니다.
특성
|
메트릭
|
크기
|
-
결함 수, 심각도 및 상태별 변경 요청. 완전 변경 수, 적응 변경 수 및 정정 변경 수로도 분류됩니다.
|
노력
|
-
직원-시간 단위의 결함 복구 노력, 변경 구현 노력
|
휘발성
|
|
완전성
|
-
발견된 결함 수/예측 결함 수(신뢰성 모델을 사용하는 경우)
|
프로젝트 계획(소프트웨어 개발 계획의 4.2 섹션)
프로젝트 관리 시 획득 가치(EV) 기법을 적용하여 얻은 측정입니다. 이 모두를 함께 비용/스케줄 제어 시스템 기준(C/SCSC)이라고 합니다. 단순 획득 가치(EV) 기법은 위의 최소 메트릭 세트에서 설명합니다. 더 자세한 분석은 다음을 포함한 관련 메트릭을 사용하여 수행할 수 있습니다.
-
계획된 작업의 예산 비용(BCWS)
-
수행된 작업의 예산 비용(BCWP)
-
수행된 작업의 실제 비용(ACWP)
-
완료 시 예산(BAC)
-
완료 시 예상(EAC)
-
계약 예산 기초(CBB)
-
최근 개정된 예상(LRE)
비용 및 스케줄 변수에 대해 파생된 요소입니다. 소프트웨어 프로젝트 관리에 대한 획득 가치(EV) 접근 방식의 응용프로그램을 논의하려면 [ROY98]을 참조하십시오.
프로젝트는 유형, 크기, 복잡도 및 양식 측면에서 특성화해야 합니다(일반적으로 유형, 크기 및 복잡도로 양식이 판별됨). 왜냐하면 이 측면은 하위 레벨 측정 시 다양한 임계값에 대한 예상의 조건이 되기 때문입니다.
다른 제한조건은 계약 또는 스펙에서 캡처되어야 합니다. 프로세스, 제품 및 자원에서 파생된 메트릭은 모든 기타 프로젝트 레벨 메트릭을 캡처합니다. 프로젝트 유형 및 도메인은 텍스트 설명으로 기록될 수 있습니다.
그러면 충분한 세부사항으로 프로젝트를 정확히 설명할 수 있습니다. 프로젝트 크기를 비용, 노력, 지속 기간, 개발할 코드 크기, 전달하려는 기능 점수별로 기록하십시오. 프로젝트의 복잡도는 다소 주관적으로 설명할 수
있습니다. - 다른 완료된 프로젝트와 비교하여 기술 및 관리 복잡도를 표시하는 차트에 프로젝트를 배치하여 설명합니다. [ROY98], 그림 14-1에서 이
다이어그램을 표시합니다.
[ROY98]에서 설명되는 파생 메트릭은 프로젝트 관리자의 기본 지표이며, 제품 및 프로세스에서 수집된 메트릭으로부터 얻을 수 있습니다. 이는 다음과
같습니다.
-
모듈화 = 구현 모델에서 완전 또는 정정 변경 당 평균 파손(NCNB*)
-
적응성 = 구현 모델에서 완전 또는 정정 변경 당 평균 노력
-
성숙도 = 활성 테스트 시간/정정 변경 수
-
관리 가능성 = 유지보수 생산성/개발 생산성 = [실제 누적 수정사항/완전 및 정정 변경의 누적 노력]/[완료 시 NCNB의 예상 수/완료 시 예상 프로덕션 노력]
-
재작업 안정성 = 누적 파손 - 누적 수정사항
-
재작업 백로그 = [누적 파손 - 누적 수정사항]/테스트한 NCNB 단위
* NCNB는 주석이 없고 공백이 없는 코드 크기입니다.
진행상태는 프로젝트 계획에서 보고되어야 합니다. 이는 중간 산출물 완료 메트릭(작업 소프트웨어의 프로덕션에 지정된 획득 가치(EV) 관점의 특정 가중치 사용)을 사용합니다.
COCOMO([BOE81] 참조)와 같은 예상 모델을 사용한 경우 다양한 측정 인수 및 가격 요인을 기록해야 합니다. 이는 실제로 프로젝트의 자세한 설명을 구성합니다.
측정할 항목으로는 인원(경험, 스킬, 비용, 성능), 메소드 및 도구(생산성 및 품질에 대한 효과의 관점에서 비용), 시간, 노력, 예산(소비된 자원, 나머지 자원)이 있습니다.
인력 구성 프로파일은 시간에 따라 기록되어야 합니다. 이때 유형(분석가, 디자이너 등), 등급(비용을 함축하는 항목) 및 할당된 팀이 표시됩니다. 실제 및 계획 모두 기록되어야 합니다.
다시 COCOMO 모델에는 소프트웨어 개발 환경과 직원 경험 및 능력의 특성화가 필요합니다. 이 모델은 이 메트릭을 유지하는 데 필요한 좋은 프레임워크입니다.
지출, 예산 및 스케줄 정보는 프로젝트 계획에서 파생됩니다.
|