키워드: CMMI；; 을 눌러 섹션을 인쇄할 수도 있습니다 소프트웨어 메트릭 소프트웨어 프로세스 기능 측량 프로젝트 임계값
소개하다
소프트웨어 측정의 목적은 프로젝트 관리를 위한 프로젝트 구현의 충분한 가시성을 제공하는 것입니다. 이를 통해 프로젝트 관리자는 프로젝트의 실제 진행 상태와 프로젝트 계획 간의 편차를 알 수 있으므로 수정 조치를 취하고 원활한 프로젝트 진행을 보장할 수 있습니다. 효과적인 소프트웨어 측정 프로세스는 조직의 소프트웨어 프로세스 능력 향상을 촉진합니다. 소프트웨어 메트릭은 소프트웨어 특성의 정량적 표현 및 분석 방법입니다. 소프트웨어 측정 단위는 소프트웨어 제품 측정 단위와 소프트웨어 프로시저 측정 단위로 나눌 수 있습니다. 소프트웨어 제품 측정 (소프트웨어 제품 특성의 정량 표현 및 분석) 은 제품 생산 프로세스와 독립적인 측정입니다. 소프트웨어 프로세스 측정 단위 (소프트웨어 프로세스 특성의 정량 표현 및 분석) 는 관리자에게 제품 생산 프로세스를 제공하는 상태 정보 및 지침의 기초입니다.
소프트웨어 제품 측정의 요소는 품질 요소, 평가 기준 및 측정 요소입니다. 여기서는 주로 수요 측정, 규모 측정, 진행 측정, 작업 로드 측정, 위험 관리 측정 및 품질 보증 측정 단위를 통해 소프트웨어 프로세스 측정 단위를 분석합니다.
1 3 계층 아키텍처 소프트웨어 제품 지표
1..1품질 요소
소프트웨어 품질은 소프트웨어의 기본 특징인 6 가지 요소로 나눌 수 있습니다. 기능: 소프트웨어가 사용자 요구를 충족하는 기능을 구현합니다. 신뢰성: 지정된 시간 및 조건 하에서 소프트웨어가 성능 수준을 유지할 수 있는 정도 사용 편의성: 소프트웨어의 경우 사용자가 출력을 학습, 조작, 입력 준비 및 이해하기 위한 노력의 정도입니다. 효율성: 규정된 조건 하에서, 소프트웨어는 시간을 포함한 컴퓨터 자원을 이용하여 어떤 기능을 실현하는 데 있어서 효과적이다. 서비스 용이성: 사용자 요구 사항, 환경 변화 또는 소프트웨어 오류를 충족하기 위해 소프트웨어를 수정하는 데 필요한 노력의 정도 이식성: 소프트웨어가 한 컴퓨터 시스템이나 환경에서 다른 시스템 또는 환경으로 쉽게 이전할 수 있는 정도입니다.
1.2 평가 기준
평가 기준에는 정확성, 견고성, 보안, 통신 유효성, 처리 유효성, 장비 유효성, 운영 가능성, 교육, 무결성, 일관성, 추적 가능성, 가시성, 하드웨어 시스템 독립성, 소프트웨어 시스템 독립성, 확장성, 공통성, 모듈식, 명확성이 포함됩니다
1.3 미터법 요소
소프트웨어 요구 사항 분석, 전체 설계, 상세 설계, 구현, 조립 테스트, 검증 테스트 및 유지 관리의 7 단계에 따라 각 단계의 측정 요소가 개발되었습니다.
2 CMMI 기반 소프트웨어 프로세스 측정 단위
소프트웨어 기업의 관점에서 볼 때, 소프트웨어 메트릭은 다양한 메트릭을 통해 소프트웨어 수명 주기의 다양한 요소를 측정하고, 프로젝트 관리자에게 프로젝트에 대한 다양한 중요한 정보를 제공하며, 소프트웨어 평가 활동의 토대이기도 합니다.
카네기 멜론 대학의 SEI 는 다음과 같은 소프트웨어 측정 프로세스 맵을 제시했습니다.
그림 1 소프트웨어 측정 프로세스 아키텍처
위의 구조를 분석해 봅시다.
측정 프로세스를 위한 계획은 두 가지 활동으로 구성됩니다. 하나는 확인 범위이고 다른 하나는 절차 단계를 정의하는 것입니다. 범위 확인: 측량 수요의 크기를 정의하여 기업 자체의 요구에 적합한 측정 프로세스를 정의합니다. 한정된 인력, 물력 등 자원은 전체 측정 과정에 지출해야 하기 때문에 비현실적이고 완전하거나 실제 결과를 반영하기에 충분하지 않아 측정 프로세스의 신뢰성과 기업의 개발 능력에 영향을 미칠 수 있습니다. 절차 단계 정의: 범위를 결정한 후 작업 및 측정 프로세스의 단계를 정의하고 서면으로 보관합니다. 주요 업무는 완전하고 일관되며 운영 가능한 측정 기준을 정의하는 것입니다. 데이터 수집 방법 및 데이터 기록 및 저장 방법 정의 측량 데이터를 분석할 수 있는 관련 기술을 정의하여 사용자가 측량 데이터를 기반으로 실질적인 결과를 얻을 수 있도록 합니다.
프로세스 구현에는 두 가지 활동이 포함됩니다. 하나는 데이터 수집이고 다른 하나는 데이터 분석입니다. 데이터 수집: 정의된 측정 작업에 따라 데이터를 수집, 기록 및 저장합니다. 또한 데이터를 적절하게 검사하여 유효성을 확인해야 합니다. 이 활동을 전개할 때는 목표적이어야 하며, 프로젝트나 활동에 필요한 실제 데이터가 다르기 때문에 활동 상태를 추적하는 것이 매우 중요하다는 점에 유의해야 한다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 활동명언) 데이터 분석: 데이터 분석, 보고서 준비, 보고서 제출 및 검토를 포함하여 보고서가 충분히 정확한지 확인합니다. 보고서가 사용자에게 유용한 도움말을 제공하지 않거나 사용자가 보고서의 내용을 이해하지 못할 수 있으므로 이러한 프로그램을 반복해야 할 수 있습니다. 두 경우 모두 피드백을 제공하고 데이터 분석을 위해 측정 프로세스를 다시 시작해야 합니다.
프로세스 개선에는 활동의 한 측면, 즉 최적화 프로세스만 포함됩니다. 프로세스 최적화: 프로세스를 동적으로 개선하고 프로세스 개선과 관련된 여러 문제를 통합하고 처리할 수 있는 구조적인 방법을 제공합니다. 또한 이 활동은 측정 프로세스 자체를 평가해야 하며, 보고된 사용자는 데이터의 유효성에 대한 피드백을 제공합니다. 이러한 피드백은 다른 활동에서 나올 수 있지만 일반적으로 새로운 측정 프로세스의 라이프 사이클에 통합되어 측정 프로세스를 새로 확인하고 정의합니다.
구현 프로젝트에서는 프로젝트가 시작된 후 프로젝트 측정 작업이 정식으로 시작됩니다. 프로젝트 계획 단계에서 프로젝트 관리자는 프로젝트의 특성에 따라 측정 계획을 수립하고 측정 데이터 수집 및 정량 분석 제어 전략을 수립해야 합니다. 프로젝트 구현 과정에서 프로젝트 관련 구성원은 미리 설정된 주기에 따라 다양한 측정 데이터를 수집하고 관련 소프트웨어 측정 기록표를 작성합니다. 측정 책임자는 프로젝트 측정 테이블에 따라 적절한 방법을 사용하여 프로젝트 레벨 측정 데이터를 비교 분석하고 측정 분석 보고서를 작성합니다. 필요한 경우 프로젝트 계획 수정 및 관련 교육 실시와 같은 시정 조치를 취합니다. 프로젝트가 끝나면 측정 책임자와 관련자는 측정 규정 및 관련 문서, 측정 수집 데이터, 분석 결과 및 보고서를 검증하여 적절한 측정 데이터베이스에 배치해야 합니다.
실제 소프트웨어 프로젝트 상황에 따라 측정 프로젝트를 결정합니다. 프로젝트 진행, 작업량 및 품질에 더 많은 관심을 기울이면 프로젝트 진행 편차는 25%, 프로젝트 작업량 편차는 20%, 결함 복구율은 90% 이하를 측정 목표로 삼을 수 있습니다.
2. 1 수요 측정
수요의 안정성은 프로젝트의 규모, 작업량 및 진행에 큰 영향을 미칩니다. 수요 불안정은 소프트웨어 제품 품질 저하, 프로젝트 비용 증가, 프로젝트 일정 연기 등과 같은 부정적인 영향을 미칠 수 있습니다. 요구사항의 안정성을 추적하고 분석하면 프로젝트 구성원이 소프트웨어 요구사항을 관리하고 제어할 수 있는 능력이 반영됩니다. 현재 국내 소프트웨어 프로젝트의 수요 분석과 통제가 상대적으로 약해 개발자가 두 배의 노력을 기울였지만 사용자 만족도는 여전히 만족스럽지 못하다. 따라서 프로젝트 요구 사항을 효과적으로 측정하고 관리해야 합니다.
수요 측정에는 최초 총 수요 수, 이 단계에서 추가된 수요 수, 이 단계에서 삭제된 수요 수, 이 단계에서 수정된 수요 수 등이 포함됩니다.
수량, 이 단계의 수요 변화 수, 이 단계의 총 수요 변화 수, 프로젝트 종료 시 총 수요 변화 수, 프로젝트 종료 시 총 수요 변화 수, 수요 변화 비율, 수요 실현률 등
수요의 변화는 규모 증가, 진도 연기, 비용 증가 및 재작업으로 이어질 수 있습니다. 프로젝트 구성원은 수요의 변화 (수요 증가, 수정 및 삭제 포함) 와 총 수요의 변화를 정기적으로 측정하고 수요의 변화를 통제하며 적절한 조치를 취해야 합니다. 그림 2 는 수요의 안정성을 보여 주며, 두 개의 점선은 모니터링 중 총 수요의 변화와 수요 변화 수의 변화를 나타냅니다. 수요 기준 검토가 세 번째 프로젝트 모니터링 기간 동안 발생한다고 가정하면, 수요 검토 후 네 번째 수요 총량과 네 번째, 다섯 번째, 여섯 번째 수요 변화 횟수가 눈에 띄게 증가하여 7 번째 이후 수요가 안정화되는 것을 알 수 있습니다. 설명 수요 기준 요소 검토 후 수요는 오랫동안 불안정합니다. 다음과 같은 이유가 있을 수 있습니다: (1) 필요
본문은 원문이 부족하고, 오해하고, 애매하고, 불완전하고, 정확하지 않다. (2) 고객 수요는 자주 변한다. 해결 방법: 수요 조사를 할 때 고객의 요구를 충분히 발굴하고 확인합니다. 자주 변경되는 수요의 경우 프로젝트 멤버는 자원 재할당 및 규모, 작업량 및 일정 재평가와 같은 조치를 취해야 할 수 있습니다.
그림 2 수요 변화 추세 차트
2.2 규모 측정
규모는 프로젝트의 기본 측정이며 소프트웨어 프로젝트 비용을 결정하는 가장 기본적인 요소이며 작업량과 진도 추정, 생산성 계산, 결함 밀도 등 프로젝트 평가 지표의 기초이다. 규모를 효과적으로 추정, 추적 및 통제하면 프로젝트가 예정된 계획에 따라 순조롭게 진행될 뿐만 아니라 조직의 이익 목표 달성도 보장할 수 있습니다.
실제 규모와 예상 규모 사이의 편차를 감시하다. 필요한 경우 작업량과 진행 상황을 재평가합니다.
이정표 단계 (예: 수요 단계, 설계 단계) 에서 중대한 수요 변경이 발생하거나 프로젝트 상황을 요약할 때 프로젝트 관리자는 규모 변화율을 분석하여 제품의 유효 규모 편차를 모니터링해야 합니다.
스케일 변경률이 제어 상한 및 하한 내에 있는 경우 측정 결과가 허용됩니다.
스케일 변경률이 제어 상한 및 하한을 초과하면 원인을 분석하고 적절한 조치를 취합니다.
측정 프로젝트는 주로 예상 프로젝트 크기, 실제 프로젝트 크기, 크기 변화율, 예상 프로젝트 원가, 실제 프로젝트 원가, 재사용 가능한 코드 라인 등을 포함합니다. 실제 상황에 따라 선택할 수 있습니다.
2.3 진행 측정
소프트웨어 프로젝트의 진행 상황을 보장하는 것은 프로젝트 비용을 통제하고 사용자 만족을 얻는 열쇠입니다. 소프트웨어 프로젝트는 진행 중에 문제가 발생하기 쉽다. 프로젝트 진행 상황을 정량화하고 투명하게 관리하면 가능한 한 빨리 진행 지연을 발견하고 그에 따라 신속하게 조정할 수 있습니다. 구체적인 측정 프로젝트에는 예상 프로젝트 진행, 실제 프로젝트 진행, 진행 편차, 총 마일스톤 계획 일수, 총 마일스톤 실제 일수, 총 마일스톤 차이 일수, 총 프로젝트 계획 일수, 총 프로젝트 실제 총 일수, 총 프로젝트 차이 일수가 포함됩니다. 진행 편차가 통제 한도를 초과하면 원인을 분석하고 진행 상황이 통제될 때까지 조치를 취하고 진행 상황을 추적합니다.
2.4 워크로드 측정
작업량을 추적하는 목적은 프로젝트 인력이 충분한지, 각 단계에 할당된 작업량이 적절한지 평가하는 것입니다. 작업량에 대한 정확한 추정 및 통제는 프로젝트에 적합한 인적 자원을 할당하고 프로젝트 비용을 통제하는 데 도움이 됩니다. 각 단계, 활동별 작업량이 총 작업량에서 차지하는 비율을 집계하고 계획 비율과 비교하면 프로젝트 구현의 편차를 확인할 수 있습니다. 경험적 교훈을 요약하면 소프트웨어 엔터프라이즈 개발 팀의 특징에 맞는 최적의 작업량 조합을 점진적으로 형성하는 데 도움이 됩니다.
작업 로드 측정의 구체적인 방법은 작업 로드 측정의 기본 측정 항목을 결정하고, 관계자가 기본 측정 항목을 선택하여 작업 로그를 채우고, 특정 시점에 기본 측정 항목을 집계하여 관련 파생 측정 항목을 계산하는 것입니다. 관련 측정 프로젝트에는 활동당 총 작업 로드, 단계당 총 작업 로드, 활동별 작업 로드 분포, 단계당 작업 로드 분포, 프로젝트 예상 (총) 작업 로드, 프로젝트 실제 (총) 작업 로드, 작업 로드 편차 등이 포함됩니다.
그림 3 재작업 작업 로드 분석 차트
분석: 데이터 및 차트에서 재작업 작업량은 약 16% 로 정상 범위 내에 있습니다. 임계값을 초과하지 않았습니다.
2.5 위험 관리 지표
위험을 식별 및 측정하고 식별된 위험과 향후 프로젝트 문제가 되는 위험 수를 계산합니다. 위험 측정 프로젝트는 주로 이 단계에서 식별된 위험 수, 이 단계에서 문제로 변환되는 위험 수, 프로젝트에서 식별된 총 위험 수, 프로젝트가 문제로 전환되는 총 위험 수를 포함합니다.
위험 관리는 프로젝트의 잠재적 문제를 식별하여 관리 방안을 마련하고, 프로젝트 수명 주기 동안 이러한 문제를 처리하고, 잠재적 문제의 영향과 확률을 낮추는 것입니다. 위험 측정은 향후 프로젝트의 위험 관리에 대한 참조 데이터를 제공합니다.
그림 4 프로젝트 위험 및 문제 추세 차트
2.6 품질 보증 지표
소프트웨어 품질 보증 과정에서 불합격에 대한 통계를 통해 프로젝트 구성원이 소프트웨어 개발 프로세스 사양을 얼마나 준수하는지, 결함을 예방하고 프로세스를 개선할 수 있습니다. 품질 보증 활동의 작업량을 집계하여 프로젝트 지원 활동에 대한 작업량 데이터를 누적할 수 있습니다.
그림 5 는 해결 추세 차트를 충족하지 않습니다
측정 프로젝트는 주로 QA 활동의 작업량, 총 부적합 수, 다양한 문제에 대한 부적합 수, 신규 부적합 수, 해결된 부적합 수, 현재 해결되지 않은 부적합 수, 부적합 해결 비율, 부적합 해결 시간 지연, 부적합 해결 작업 로드, 조직 표준 프로세스 세트의 작업 로드 자르기 등이 포함됩니다.
3 실천 결과
어떻게 소프트웨어 품질을 향상시킬 것인가는 줄곧 소프트웨어 공학 분야의 중요한 연구 방향이다. 측정 기반 양적 관리는 현재 가장 효과적인 품질 보증 방법 중 하나이며, 국내 많은 소프트웨어 기업들도 이 방면의 연구와 실천을 진행하고 있다. 이 측정 분석 모델은 여러 특정 프로젝트 응용 프로그램에서 사용되었으며 SEI 전문가 검토 및 CMMI3 공식 검토를 통과했습니다. 이 글은 소프트웨어 프로세스 개선과 소프트웨어 측정 분석에 대한 탐구와 실천을 진행하였으며, 구체적인 소프트웨어 프로젝트와 결합하여 구체적인 실천을 설명하였으며, 향후 소프트웨어 측정 분석의 적용과 우리나라 소프트웨어 프로세스의 개선에 어느 정도 실질적인 의의가 있다.
4 결론
다음 단계에서는 소프트웨어 메트릭 라이브러리 (예: 전자 정부 애플리케이션 보안 소프트웨어 메트릭 라이브러리) 의 구축 및 적용을 강화하고 소프트웨어 메트릭 분석을 장기적인 메커니즘으로 삼아 소프트웨어 프로세스가 질서 정연하고 건강하게 발전하도록 해야 합니다.