CMMI(Background to Capability Maturity Model Integration)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
개발용 CMMI(기능 완성도 모델 통합)에 대한 최종 가이드는 소프트웨어 엔지니어링 연구소에서 "CMMI: 프로세스 통합 및 제품 개선에 대한 지침"으로 게시합니다. 이 책에서는 CMMI 제품 제품군 내의 모델 중 하나인 CMMI-DEV(CMMI-DEV) 버전 1.3에 대해 구체적으로 설명합니다. CMMI에 대한 유용하고 접근성 있는 책인 "CMMI 증류: 통합 프로세스 개선에 대한 실용적인 소개"를 찾을 수도 있습니다.
참고 항목
여기에 제공된 지침은 CMMI용 버전 1.3을 기반으로 하며 Azure DevOps에서 사용할 수 있는 CMMI 프로세스를 지원합니다. 현재 이 콘텐츠를 업데이트하여 이후 버전을 지원할 계획이 없습니다.
기록 노트
CMMI는 1987년 SEI(소프트웨어 엔지니어링 연구소)의 프로젝트인 CMM(기능 완성 모델)으로 시작되었습니다. SEI는 카네기 멜론 대학의 연구 센터이며, 미국 국방부에 의해 설립되고 자금을 지원했습니다. 1991년에 처음 게시된 소프트웨어용 CMM은 중요한 성공 요인의 검사 목록으로 시작되었습니다. 이 모델은 또한 국제 비즈니스 머신 (IBM) 공사와 필립 크로스비와 W. 에드워즈 데밍과 같은 20 세기 품질 보증 리더의 연구를 기반으로 구축. 이름, 기능 완성도 모델 및 스테이징 표현 5개 수준은 모두 크로스비의 제조 완성도 모델에서 영감을 받았습니다. 방어 프로그램에 기본 적용된 CMM은 상당한 채택을 달성하고 몇 가지 수정을 거쳤습니다. 그 성공은 소프트웨어를 넘어 다양한 주제에 대한 CMM의 개발로 이어졌습니다. 새로운 모델의 확산은 혼란스러웠습니다. 이에 따라 정부는 시스템 엔지니어링, 소프트웨어 엔지니어링 및 제품 개발을 통합하는 확장 가능한 단일 프레임워크를 만들기 위해 2년 프로젝트에 자금을 지원했습니다. 이러한 노력에는 200명 이상의 업계 및 학술 전문가가 참여했습니다. 결과는 CMMI였습니다.
CMMI-DEV는 모델입니다. 그것은 과정이 아니다, 도 처방을 따라. 대신, CMMI-DEV는 소프트웨어 개발 및 시스템 엔지니어링에서 사용 중인 것으로 입증된 일련의 조직 동작을 제공합니다. 이러한 모델을 사용하는 이유는 무엇인가요? 그 목적은 무엇입니까? 그리고 어떻게 가장 잘 사용해야합니까? 이러한 중요한 질문은 아마도 CMMI에서 가장 오해되는 문제일 것입니다.
모델을 사용하는 이유
개선 작업에는 조직의 작동 방식, 필요한 기능 및 해당 함수가 상호 작용하는 방식에 대한 모델이 필요합니다. 모델은 조직 요소에 대한 이해를 제공하고 개선할 수 있는 방법과 개선해야 할 사항에 대한 논의를 지원합니다.
모델은 다음과 같은 이점을 제공합니다.
- 커뮤니케이션에 도움이 되는 공통 프레임워크 및 언어 제공
- 수년간의 경험을 활용합니다.
- 사용자가 개선에 집중하면서 큰 그림을 고려하도록 도와줍니다.
- 트레이너 및 컨설턴트가 지원하는 경우가 많습니다.
- 합의된 표준을 제공하여 불일치를 해결하는 데 도움이 될 수 있습니다.
CMMI 모델의 용도는 무엇인가요?
CMMI 모델의 목적은 조직 프로세스의 완성도를 평가하고 향상된 제품을 목표로 프로세스 개선에 대한 지침을 제공하는 것입니다. 또한 CMMI는 위험 관리를 위한 모델이며 위험을 관리하는 조직의 기능을 측정하는 방법을 제공합니다. 위험 요소를 관리하는 기능은 고품질 제품을 제공하는 조직의 기능에 영향을 줍니다. 위험 관리에 대한 또 다른 관점은 조직이 스트레스를 받고 얼마나 잘 수행하는지입니다. 높은 완성도의 높은 기능 조직은 예상치 못한 스트레스가 많은 이벤트에 쉽게 대응할 수 있습니다. 낮은 성숙도와 낮은 기능 조직은 스트레스에 당황하거나, 맹목적으로 모호한 절차를 따르거나, 모든 프로세스를 완전히 버리고 다시 혼돈으로 돌아가는 경향이 있습니다.
그러나 CMMI는 조직의 경제 성과에 대한 입증된 지표가 아닙니다. 만기가 더 높은 조직은 위험을 더 잘 관리하고 더 예측 할 수 있지만 만기 기업이 위험 회피하는 경향이 있다는 증거가 있습니다. 위험 회피는 혁신의 부족이나 긴 리드 타임과 경쟁력의 부족을 초래하는 더 큰 관료주의의 증거로 이어질 수 있습니다. 낮은 성숙도 기업은 더 혁신적이고 창의적이지만 혼란스럽고 예측할 수없는 경향이 있습니다. 결과가 달성될 때, 그들은 종종 개인이나 관리자에 의해 영웅적인 노력의 결과입니다.
CMMI 모델을 사용하는 가장 좋은 방법은 무엇인가요?
이 모델은 개선 사항을 측정하기 위한 지원 시스템만 평가에 사용하는 프로세스 개선 이니셔티브의 기초로 사용하도록 설계되었습니다. 이 사용량과 혼합된 성공이 있었습니다. 채워야 할 수 있는 기존 프로세스의 간격을 식별하는 맵 대신 프로세스 정의에 대해 모델을 실수하고 따르려고 하는 것은 너무 쉽습니다. CMMI의 기본 구성 요소는 목표와 이를 충족하는 데 자주 사용되는 여러 활동을 정의하는 프로세스 영역입니다. 프로세스 영역의 한 가지 예는 프로세스 및 제품 품질 보증입니다. 또 다른 구성 관리입니다. 프로세스 영역이 프로세스가 아니라는 것을 이해하는 것이 중요합니다. 단일 프로세스는 여러 프로세스 영역을 교차할 수 있으며 개별 프로세스 영역에는 여러 프로세스가 포함될 수 있습니다.
CMMI-DEV는 실제로 동일한 기본 요소를 공유하는 두 가지 모델입니다. 첫 번째이자 가장 친숙한 것은 5개의 조직 완성도 수준 중 하나로 매핑된 22개의 프로세스 영역을 표시하는 스테이징 표현입니다. 조직의 평가는 운영 수준을 평가하고, 이 수준은 위험을 관리하고 약속을 이행할 수 있는 능력을 나타내는 지표가 될 것입니다.
수준 4와 5는 종종 더 높은 완성도 수준이라고 합니다. 정량적 관리 및 최적화 동작을 보여 주는 높은 완성도 조직과 단순히 관리되거나 정의된 프로세스를 따르는 낮은 완성도 조직 간에는 명확한 차이가 있는 경우가 많습니다. 성숙도가 높은 조직은 프로세스의 가변성이 낮으며 통계적으로 방어할 수 있는 관리 방법의 일부로 선행 지표를 사용하는 경우가 많습니다. 그 결과, 성숙도 높은 조직은 다른 관료주의가 방해가 되지 않는다고 가정하여 새로운 정보에 응답할 때 더 예측 가능하고 빠르게 대응하는 경향이 있습니다. 낮은 성숙도 조직이 영웅적인 노력을 보여 주는 경향이 있는 경우, 높은 완성도 조직은 스트레스를 받을 때 맹목적으로 프로세스를 따르고 프로세스 변경이 더 적절한 응답일 수 있음을 인식하지 못할 수 있습니다.
연속 표현 모델은 각 22개의 프로세스 영역 내에서 기능을 개별적으로 처리하므로 조직은 가장 높은 비즈니스 가치를 제공하는 프로세스에 맞게 개선 노력을 조정할 수 있습니다. 이 표현은 크로스비의 원래 모델과 더 일치합니다. 이 모델에 대한 평가는 단일 숫자가 아닌 기능 프로필을 생성합니다. 조직의 완성도 수준은 대부분의 관리자와 경영진이 이해하는 수준이기 때문에 연속 모델 평가 결과를 5단계로 매핑하는 방법이 있습니다.
구현자가 CMMI가 프로세스나 워크플로 모델이 아니라는 사실을 잊어버린 경우 단계적 모델을 프로세스 개선 프로그램의 기초로 사용하는 것은 위험할 수 있습니다. 대신 CMMI는 프로세스 및 워크플로가 달성할 목표를 제공하도록 설계되었습니다. 이러한 목표를 달성하면 조직의 완성도와 이벤트가 계획대로 전개될 가능성이 높아집니다. 아마도 가장 큰 실패 모드는 목표를 달성한 다음 단순히 평가를 통과하기 위한 프로세스 및 인프라를 만드는 것입니다. 프로세스 개선 작업의 목표는 숫자가 아니라 측정 가능한 개선이어야 합니다.
연속 모델은 프로세스 개선 가이드로서 성공을 거두었습니다. 일부 컨설팅 회사는 연속 모델에 대한 지침만 제공하기로 선택합니다. 가장 명백한 차이점은 연속 모델을 중심으로 설계된 프로세스 개선 프로그램에는 성숙도에 따라 결정되는 인위적인 목표가 없다는 것입니다. 연속 모델은 조직에 경제적 이익을 활용할 가능성이 가장 큰 영역에서 프로세스 개선을 적용하는 데에도 적합합니다. 따라서 연속 모델을 따르는 사용자는 CMMI 모델을 기반으로 하는 이니셔티브에서 긍정적인 피드백을 받을 가능성이 더 높습니다. 또한 긍정적인 피드백은 선순환 개선의 발전으로 이어질 가능성이 높습니다.
CMMI 모델의 요소
다음 표에서는 CMMI 모델(버전 1.3)을 구성하는 22개의 프로세스 영역을 나열합니다.
| 머리글자어 | 프로세스 영역 |
|---|---|
| 자동차 | 인과 분석 및 해결 방법 |
| CM | 구성 관리 |
| Dar | 의사 결정 분석 및 해결 |
| Ipm | 통합 프로젝트 관리 |
| MA | 측정 및 분석 |
| OID | 조직 혁신 및 배포 |
| OPD | 조직 프로세스 정의 |
| OPF | 조직 프로세스 포커스 |
| Opp | 조직 프로세스 성능 |
| OT | 조직 교육 |
| PI | 제품 통합 |
| PMC | 프로젝트 모니터링 및 제어 |
| PP | 프로젝트 계획 |
| PPQA | 프로세스 및 제품 품질 보증 |
| QPM | 정량적 프로젝트 관리 |
| RD | 요구 사항 정의 |
| REQM | 요구 사항 관리 |
| RSKM | 위험 관리 |
| SAM | 공급업체 계약 관리 |
| TS | 기술 솔루션(Technical Solution) |
| 버전 | 확인 |
| 발 | 유효성 검사 |
스테이징된 표현에서 프로세스 영역은 다음 그림과 같이 각 단계에 대해 매핑됩니다.
연속 표현에서 프로세스 영역은 다음 그림과 같이 기능 그룹으로 매핑됩니다.
각 프로세스 영역은 필수, 예상 및 정보 구성 요소로 구성됩니다. 모델에 대한 평가를 충족하는 데 필요한 구성 요소만 실제로 필요합니다. 필요한 구성 요소는 각 프로세스 영역에 대한 특정 및 제네릭 목표입니다. 예상 구성 요소는 각 특정 또는 제네릭 목표에 대한 특정 및 제네릭 사례입니다. 예상 구성 요소는 단지 예상되고 필요하지 않으므로 특정 또는 일반 사례를 동등한 사례로 바꿀 수 있음을 나타냅니다. 구현자 및 평가자를 안내하는 데 필요한 사례가 있습니다. 대체 사례를 선택하는 경우 평가자에게 조언하고 대체 관행이 적절한 이유를 정당화하는 것은 구현자에게 달려 있습니다. 정보 제공 구성 요소는 CMMI 모델에서 안내하는 프로세스 개선 이니셔티브를 구현자가 시작하는 데 도움이 되는 세부 정보를 제공합니다. 정보 제공 구성 요소에는 제네릭 및 특정 사례 및 일반적인 작업 제품의 하위 요소가 포함됩니다.
일반 및 특정 목표만 필요합니다. 다른 모든 항목은 가이드로 제공됩니다. 예상 및 정보 구성 요소의 예를 들어 CMMI 문헌은 큰 공간 및 방어 시스템 프로젝트에서 데이터를 가져왔습니다. 이러한 프로젝트는 조직에서 수행되는 프로젝트 유형을 반영하지 않을 수도 있고 Agile 소프트웨어 개발 방법의 출현과 같은 업계의 최신 추세를 반영할 수도 없습니다.