소프트웨어 측정

소프트웨어 측정을위한 프레임 워크는 세 가지 원칙을 기반으로합니다.

검사 할 개체 분류
관련 측정 목표 결정
조직이 도달 한 성숙도 수준 식별

검사 할 개체 분류

소프트웨어 엔지니어링에서는 주로 세 가지 유형의 엔티티가 존재합니다. 그들은-

Processes
Products
Resources

이러한 모든 엔티티에는 내부 및 외부 엔티티가 있습니다.

Internal attributes프로세스, 제품 또는 자원 자체의 관점에서 순전히 측정 할 수있는 것입니다. 예 : 크기, 복잡성, 모듈 간의 종속성.
External attributes환경과의 관계에 대해서만 측정 할 수있는 것입니다. 예 : 사용자가 경험 한 총 실패 수, 데이터베이스를 검색하고 정보를 검색하는 데 걸리는 시간.

각 엔티티에 대해 측정 할 수있는 다른 속성은 다음과 같습니다.

프로세스

프로세스는 소프트웨어 관련 활동의 모음입니다. 다음은 프로세스에 대해 직접 측정 할 수있는 내부 속성 중 일부입니다.

프로세스 또는 활동 중 하나의 기간
프로세스 또는 활동 중 하나와 관련된 노력
프로세스 또는 활동 중 하나에서 발생한 특정 유형의 인시던트 수

프로세스의 다양한 외부 속성은 비용, 제어 가능성, 효율성, 품질 및 안정성입니다.

제품

제품은 경영진이 제공하기로 약속 한 항목 일뿐만 아니라 소프트웨어 수명주기 동안 생성 된 아티팩트 또는 문서이기도합니다.

다양한 내부 제품 속성은 크기, 노력, 비용, 사양, 길이, 기능, 모듈성, 재사용, 중복성 및 구문 정확성입니다. 이 중 크기, 노력 및 비용은 다른 것보다 상대적으로 측정하기 쉽습니다.

다양한 외부 제품 속성은 사용성, 무결성, 효율성, 테스트 가능성, 재사용 성, 이식성 및 상호 운용성입니다. 이러한 속성은 코드뿐만 아니라 개발 노력을 지원하는 다른 문서도 설명합니다.

자원

이들은 프로세스 활동에 필요한 엔티티입니다. 소프트웨어 생산을위한 모든 입력이 될 수 있습니다. 여기에는 인력, 재료, 도구 및 방법이 포함됩니다.

리소스의 다양한 내부 속성은 연령, 가격, 크기, 속도, 메모리 크기, 온도 등입니다. 다양한 외부 속성은 생산성, 경험, 품질, 유용성, 신뢰성, 편안함 등입니다.

관련 측정 목표 결정

특정 측정은 프로세스 또는 결과 제품 중 하나를 이해하는 데 도움이되는 경우에만 유용합니다. 프로세스 또는 제품의 개선은 프로젝트에 프로세스 및 제품에 대한 목표가 명확하게 정의 된 경우에만 수행 할 수 있습니다. 목표에 대한 명확한 이해는 프로세스 성숙도 프레임 워크의 맥락에서 주어진 프로젝트에 대한 제안 된 지표를 생성하는 데 사용될 수 있습니다.

GQM (Goal-Question-Metric) 패러다임

GQM 접근 방식은 다음 세 단계를 포함하는 프레임 워크를 제공합니다.

개발 또는 유지 보수 프로젝트의 주요 목표 나열
목표 달성 여부를 결정하기 위해 답해야하는 각 목표에서 질문 도출
질문에 적절하게 답할 수 있도록 측정해야 할 사항 결정

GQM 패러다임을 사용하기 위해 먼저 조직의 전반적인 목표를 표현합니다. 그런 다음 목표가 충족되고 있는지 확인할 수 있도록 답변을 알 수 있도록 질문을 생성합니다. 나중에 각 질문에 답하기 위해 필요한 측정 값과 관련하여 각 질문을 분석합니다.

일반적인 목표는 생산성, 품질, 위험, 고객 만족 등으로 표현됩니다. 목표와 질문은 청중의 관점에서 구성되어야합니다.

목표, 질문 및 메트릭 생성을 돕기 위해 Basili & Rombach는 일련의 템플릿을 제공했습니다.

Purpose − 이해, 평가, 관리, 엔지니어링, 학습, 개선 등을 위해 (프로세스, 제품, 모델, 메트릭 등)을 (특성화, 평가, 예측, 동기 부여 등) Example: 그것을 배우기 위해 제품을 특성화합니다.
Perspective − 개발자, 관리자, 고객 등의 관점에서 (비용, 효과 성, 정확성, 결함, 변경, 제품 조치 등)을 검토합니다. Example: 고객의 입장에서 결함을 검사합니다.
Environment − 환경은 프로세스 요인, 사람 요인, 문제 요인, 방법, 도구, 제약 조건 등으로 구성됩니다. Example:이 소프트웨어의 고객은 도구에 대한 지식이없는 사람들입니다.

측정 및 프로세스 개선

일반적으로 측정은 다음에 유용합니다.

프로세스 및 제품 이해
기준선 설정
결과 접근 및 예측

SEI에서 제공하는 프로세스의 성숙도 수준에 따라 측정 유형과 측정 프로그램이 다릅니다. 다음은 각 성숙도에 적용 할 수있는 다양한 측정 프로그램입니다.

Level 1: Ad hoc

이 수준에서 입력은 잘못 정의되고 출력은 예상됩니다. 입력에서 출력으로의 전환은 정의되지 않고 제어되지 않습니다. 이 수준의 프로세스 성숙도를 위해 측정을위한 시작점을 제공하기 위해 기준 측정이 필요합니다.

Level 2: Repeatable

이 수준에서 프로세스, 제약 및 리소스의 입력 및 출력을 식별 할 수 있습니다. 반복 가능한 프로세스는 다음 다이어그램으로 설명 할 수 있습니다.

입력 측정은 요구 사항의 크기와 변동성이 될 수 있습니다. 출력은 시스템 크기, 직원 노력의 자원, 비용 및 일정의 제약으로 측정 될 수 있습니다.

Level 3: Defined

이 수준에서 중간 활동이 정의되고 입력 및 출력이 알려지고 이해됩니다. 정의 된 프로세스의 간단한 예가 다음 그림에 설명되어 있습니다.

중간 활동에 대한 입력과 출력을 조사, 측정 및 평가할 수 있습니다.

Level 4: Managed

이 수준에서 초기 프로젝트 활동의 피드백을 사용하여 현재 활동에 대한 우선 순위를 설정하고 나중에 프로젝트 활동에 대한 우선 순위를 설정할 수 있습니다. 프로세스 활동의 효과를 측정 할 수 있습니다. 측정은 전체 프로세스의 특성과 주요 활동 간의 상호 작용을 반영합니다.

Level 5: Optimizing

이 수준에서 활동의 측정은 측정 피드백에 따라 프로세스 활동을 제거 및 추가하고 프로세스 구조를 동적으로 변경하여 프로세스를 개선하는 데 사용됩니다. 따라서 프로세스 변경은 조직과 프로젝트 및 프로세스에 영향을 미칠 수 있습니다. 이 프로세스는 센서 및 모니터 역할을하며 경고 신호에 대응하여 프로세스를 크게 변경할 수 있습니다.

주어진 성숙도 수준에서 해당 수준과 그 아래의 모든 수준에 대한 측정 값을 수집 할 수 있습니다.

성숙도 확인

프로세스 성숙도는 보이는 것만 측정하도록 제안합니다. 따라서 프로세스 성숙도와 GQM의 조합은 가장 유용한 측정을 제공합니다.

에서 level 1, 프로젝트에 잘못 정의 된 요구 사항이있을 수 있습니다. 이 수준에서는 요구 사항 특성을 측정하기가 어렵습니다.
에서 level 2, 요구 사항이 잘 정의되어 있으며 각 요구 사항 유형 및 각 유형에 대한 변경 횟수와 같은 추가 정보를 수집 할 수 있습니다.
에서 level 3, 중간 활동은 각 활동에 대한 시작 및 종료 기준으로 정의됩니다.

목표 및 질문 분석은 동일하지만 측정 항목은 성숙도에 따라 달라집니다. 프로세스가 성숙할수록 측정치가 더 풍부 해집니다. 프로세스 성숙도와 함께 GQM 패러다임은 관리자가 측정 프로그램을 설계하는 데 도움이되는 여러 도구의 기반으로 사용되었습니다.

GQM은 속성 측정의 필요성을 이해하는 데 도움이되며 프로세스 성숙도는 의미있는 방식으로 속성을 측정 할 수 있는지 여부를 나타냅니다. 함께 측정을위한 컨텍스트를 제공합니다.