능력 성숙도 통합 모델

이 문서는 대부분 또는 전부 하나의 출처에 의존하고 있습니다. 내용에 대한 의견이 있으시다면 토론 문서에서 나누어 주세요. 추가적인 출처를 제시하여 문서의 질을 높여 주세요. (2018년 8월)

능력 성숙도 통합 모델(Capability Maturity Model Integration, CMMI)은 소프트웨어 개발 및 전산장비 운영 업체들의 업무 능력 및 조직의 성숙도를 평가하기 위한 모델을 말한다. CMMI는 기존 능력 성숙도 모델(CMM)을 발전시킨 것으로서, 기존에 소프트웨어 품질보증 기준으로 사용되던 SW-CMM과 시스템 엔지니어링 분야의 품질보증 기준으로 사용되던 SE-CMM을 통합하여 개발한 후속 평가 모델이다. CMMI는 1~5단계까지 있으며, 5단계가 가장 높은 수준이다. CMMI는 소프트웨어 개발 및 전산장비 운영 분야의 품질 관련 국제 공인 기준으로 사용되고 있다.

CMMI는 소프트웨어와 시스템 공학의 역량 성숙도를 평가하는 모델이다. (Software Engineering, Sommerville)

CMMI는 모델 SW-CMM(Software Capability Maturity Model, 소프트웨어 역량 성숙도 모델)v2.0과 SECM(System Engineering Capability Model) 그리고 IPD-CMM(통합제품개발-CMM)이 합쳐진 통합모델이다.

• CMM Integration 프로젝트의 기반이 되는 모델
  • SW-CMM: CMM v 2.0 draft C
  • SECM: EIA/IS-731(Systems Engineering)
  • IPD-CMM v 0.98

다양한 정의와 표준 모델들 간의 차이로, 교육/평가/개선에 추가 비용 유발 등의 문제로 인하여 통합된 모델을 필요로 하게 되었으며, 이와 함께 ISO/IEC에서는 표준 번호 15504로 CMMI가 아닌 유럽의 SPICE(Software Process Improvement and Capability dEtermination==ISO 15504)모델을 국제 표준으로 선정함에 따라 이에 대항하기 위해 SEI는 CMMI를 배포하게 되었다.

2006년 8월에 발표된 CMMI 버전1.2부터는 "개발을 위한 CMMI(CMMI for Development)-2006년 8월 배포", "발주를 위한 CMMI(CMMI for Acquisition)-2007년 10월 배포", "서비스를 위한 CMMI(CMMI for Services)"로 나뉘어 배포되기 시작하였다. 현재

CMMI는 조직의 개발 프로세스를 5 단계의 성숙도 레벨과 6단계의 역량 레벨로 나누어 평가한다. 이에 관련하여 20여개의 프로세스 영역을 지원하고 있으며, 이에 대한 4가지 지식체계와 4가지 분류를 제공하고 있다.

CMMI는 “확장된 프레임워크”를 제공한다. 현재 아래와 같은 4가지 지식체계를 구성하고 있는데 이 각각의 영역을 Discipline이라고 한다.

• 시스템 공학은 모든 시스템 개발에 해당된다. 소프트웨어를 포함시켜도 되고 안해도 된다.
• 시스템 공학은 고객의 요구/기대/제한사항들을 제품에 반영하고, 제품 전체 생명주기 동안의 지원 활동에 중점을 둔다.

• 아래는 시스템 공학의 프로세스 영역(Process Area)이다.
  • 조직 프로세스 정의(Organizational Process Definition)
  • 조직 프로세스 중점(Organizational Process Focus)
  • 조직 훈련(Organizational Training)
  • 조직 프로세스 성과(Organizational Process Performance)
  • 조직 혁신 및 이행(Organizational Innovation and Deployment)
  • 원인분석 및 해결(Causal Analysis and Resolution)
  • 형상관리(Configuration Management)
  • 의사결정 분석 및 해결(Decision Analysis and Resolution)
  • 측정 및 분석(Measurement and Analysis)
  • 제품 통합(Product Integration)
  • 프로젝트 진행 관리(Project Monitoring and Control)
  • 프로젝트 계획(Project Planning)
  • 프로세스 및 제품 품질보증(Process and Product Quality Assurance)
  • 정량적 프로젝트 관리(Quantitative Project Management)
  • 요구사항 개발(Requirement Development)
  • 요구사항 관리(Requirement Management)
  • 위험관리(Risk Management)
  • 공급자 계약 관리(Supplier Agreement Management)
  • 기술 솔루션(Technical Solution)
  • 확인(Validation)
  • 검증 (Verification)

• 소프트웨어 공학은 소프트웨어 시스템의 개발에 해당된다.
• 소프트웨어 공학은 소프트웨어의 개발/운영/유지보수에 대해 체계적이고 훈련되었으며 정량화 가능한 접근 방법에 중점을 둔다.
• 소프트웨어 공학의 프로세스 영역(PA)은 시스템 공학(System Engineering)과 동일하다.

통합제품 및 프로세스 개발은 고객의 요구/기대치/요구사항을 만족하기 위해 제품 전체 생명주기 동안 관련 이해 당사자와의 적절한 협업을 수행할 수 있는 체계적인 접근방법이다.

• 통합제품 및 프로세스 개발의 프로세스 영역(Process Area)
  • 통합 팀(Integrated Teaming)
  • 통합 조직 환경(Organizational Environment for Integration)

작업이 점점 복잡해지면서, 프로젝트 관리자는 프로젝트에 필요한 특정 제품에 대해 기능 수행을 공급자에게 요청하거나, 수정을 요청할 수 있다. 이러한 활동들이 치명적일 때, 제품 인도 전에 더 나은 소스 분석과 공급자 활동 모니터링을 통한 이득을 얻을 수 있다. 이러한 환경에서 공급자 소싱은 발주자의 제품 획득 방식을 다룬다.

• 공급자 소싱의 프로세스 영역(Process Area)이다.
  • 통합 공급자 관리(Integrated Supplier Management)

CMMI의 프로세스 영역은 크게 4가지로 분류된다.

• 프로세스 관리(Process Management)
• 프로젝트 관리(Project Management)
• 공학(Engineering)
• 지원(Support)

프로세스 관리 영역은 프로세스를 정의하고 계획하고 전개하고,적용하고,감시하고,조정하고, 평가하고 측정하고 개선하기 위한 프로젝트 간의 활동을 포함한다.

CMMI의 프로세스 관리 프로세스 영역은 아래와 같이 5개의 프로세스 영역으로 구분된다.

• 조직 프로세스 중점(Organizational Process Focus)
• 조직 프로세스 정의(Organizational Process Definition)
• 조직 훈련(Organizational Training)
• 조직 프로세스 성과(Organizational Process Performance)
• 조직 혁신 및 이행(Organizational Innovation and Deployment)

프로젝트 관리 프로세스 영역은 프로젝트를 계획하고 감시하고 통제하는 것과 관련된 프로젝트 관리활동들을 다룬다.

CMMI의 프로젝트 관리 프로세스 영역은 다음과 같다.

• 프로젝트 계획(Project Planning)
• 프로젝트 감시 및 통제(Project Monitoring and Control)
• 공급자 계약 관리(Supplier Agreement Management)
• 통합 프로젝트 관리(Integrated Project Management)
• 위험관리(Risk Management)
• 통합팀(Integrated Teaming)
• 정량적 프로젝트 관리(Quantitative Project Management)

엔지니어링 프로세스 영역은 개발과 엔지니어링 Disciplines 간의 공유되는 유지보수 활동을 다룬다. 엔지니어링 프로세스 영역은 또한 소프트웨어 공학과 시스템 공학을 하나의 제품 개발 프로세스로 통합하고, 제품 기반 프로세스 개선 전략을 지원한다. CMMI의 엔지니어링 프로세스 영역은 아래와 같다.

• 요구사항 개발(Requirements Development)
• 요구사항 관리(Requirements Management)
• 기술 솔루션(Technical Solution)
• 제품통합(Product Integration)
• 검증(Verification)
• 확인(Validation)

제품 개발 및 유지보수를 지원하는 활동을 다룬다. 다른 프로세스들이 제대로 수행될 수 있도록 하는 프로세스들이다. 일반적으로 지원 프로세스 영역은 프로젝트를 목표로 하며,조직에 대해 좀 더 일반적인 프로세스들이다. 예를 들어 PPQA는 프로세스의 객관적 평가와 모든 프로세스 영역에서 정의되는 작업 산출물을 제공하기 위한 모든 프로세스 영역에 사용될 수 있다. 모든 PA들에서 사용할 수 있는 기능들을 제공하며, 몇몇 일반 실행(generic practice) 들을 구현하는 것을 도와준다. CMMI의 지원 프로세스 영역은 다음과 같다.

• 형상관리(Configuration Management)
• 프로세스 및 제품 품질보증(Process and Product Quality Assurance)
• 측정 및 분석(Measurement and Analysis)
• 통합을 위한 조직 환경(Organizational Environment for Integration)
• 결정분석 및 해결(Decision Analysis and Resolution)
• 원인분석 및 해결(Causal Analysis and Resolution)

CMMI의 조직 개발 프로세스 성숙도는 레벨1~레벨5로 나뉘어 있다. 레벨1은 매우 미숙하고 혼돈된 프로세스(Ad-hoc Process)이며, 레벨5는 최적화된 가장 성숙한 최고수준의 프로세스(Optimizing)이다.

CMMI는 조직의 프로세스 개선을 통한 소프트웨어 개발 과정에서의 비용, 품질, 일정 등 모든 것을 충족시키며 특정 성숙도 레벨로 진입하기 위한 최소한의 기준 제시와 반드시 수행해야할 활동들의 집합으로, 프로세스 프레임워크의 성숙도 향상을 위한 모델이다.

CMMI 모델의 각 프로세스 영역(Process Areas)의 특정 목표(specific goals, SP)과 공통 목표(generic goals, GG)의 달성정도를 측정함으로써 프로세스 개선 수준을 나타낼 수 있다.

CMMI는 조직의 SW 개발뿐만 아니라 시스템설계, 하드웨어, 운영 등 시스템통합(System Integration, SI) 사업 전반에 대한 프로세스를 평가하고 정의하는 방법인 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)를 제공한다.

특히 제품 또는 서비스의 개발, 획득, 유지보수하기 위한 조직의 공정 및 관리 능력을 향상시키기 위한 가이드를 제공과 이를 통해 프로세스 개선 시 필요한 목표와 체계의 제공이 가능하다. 5단계로 구성되는 CMMI의 성숙도 레벨은 평가 조직의 프로세스를 개선 및 평가하기 위해 실행해야할 실행지침을 포함하며, 성숙한 조직의 각 레벨별 특징은 아래와 같다.

• 레벨 1(Initial) -개인의 역량에 따라 프로젝트의 성공과 실패가 좌우된다. 소프트웨어 개발 프로세스는 거의 없는 상태를 의미한다.
  • 표준화된 프로세스 없이 프로젝트 수행결과 예측이 곤란한 조직
  • 적용 프로세스 없음.
• 레벨 2(Managed) - 프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이다. 기존 유사 성공사례를 응용하여 반복적으로 사용한다.
  • 기본적인 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직
  • 적용 프로세스
    • 요구사항 관리(Requirement Management)
    • 프로젝트 계획(Project Planning)
    • 프로젝트 감시 및 제어(Project Monitoring & Control)
    • 공급자 계약 관리(Supplier Agreement Management)
    • 측정과 분석(Measurement & Analysis)
    • 프로세스와 제품 품질 보증(Process & Product Quality Assurance)
    • 형상관리(Configuration Management)
• 레벨 3(Defined) - 레벨 2에서는 프로젝트를 위한 프로세스가 존재한다면 레벨 3에서는 조직을 위한 표준 프로세스가 존재한다. 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인받아 사용한다.
  • 세부 표준 프로세스가 있어 프로젝트가 통제되는 조직
  • 적용 프로세스
    • 요구사항 개발 (Requirement Development)
    • 기술적 해결 (Technical Solution)
    • 제품 통합 (Product Integration)
    • 검증 (Verification)
    • 조직 프로세스 중점 (Organization Process Focus)
    • 조직 프로세스 정의(Organization Process Definition)
    • 조직 훈련(Organization Training)
    • 통합된 프로젝트 관리(Integrated Project Management)
    • 통합된 공급자 관리(Integrated Supplier Management)
    • 위험(Risk Management)
    • 결정분석 및 해결(Decision Analysis & Revolution)
    • 통합 조직 환경(Organizational Environment for Integration)
    • 통합된 팀 구성(Integrated Teaming)
• 레벨 4(Quantitatively Managed) - 소프트웨어 프로세스와 소프트웨어 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다.
  • 프로젝트 활동이 정략적으로 관리․통제되고 성과 예측이 가능한 조직
  • 적용 프로세스
    • 조직적 프로세스 성과(Organizational Process Performance)
    • 정량적인 프로젝트 관리(Quantitative Project Management)
• 레벨 5(Optimizing) - 이 레벨에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.
  • 지속적인 개선활동이 정착화 되고 최적의 관리로 프로젝트가 수행되는 조직
  • 적용 프로세스
    • 조직 혁신 및 이행(Organization Innovation & Deployment)
    • 분석과 해결(Casual Analysis & Revolution)

전 세계 많은 기업들은 조직의 프로젝트 수행능력 향상을 위해 CMMI를 적용하고 있으며, 국내ㆍ외에서 최근 프로젝트 참여나 제품 공급을 위한 전제조건으로 제시되는 경우가 늘어나면서 IT서비스 기업은 물론 많은 제조, 금융권 기업 등이 CMMI 인증 획득을 추진하고 있는 추세이다. 흔히, CMMI 도입의 타당성을 얘기하면서 투자대비 효과를 언급한다. 프로젝트 일정준수율 이나 생산성, 품질, 비용, 고객만족도 측면에서 많은 효과를 본 것으로 나타나고 있다. 물론 이런 긍정적인 효과를 본 조직이 전체적으로 많지는 않지만 충실하게 CMMI를 적용한 조직에서는 이러한 긍정적인 효과를 얻을 수 있을 것이다. 그러나 국내 기업들의 CMMI 적용의 효과는 조사 결과만큼 좋지 못한 것이 사실이다. 이러한 원인은 국내 SW개발 문화의 차이나 CMMI 적용방식의 차이 등에서 찾을 수 있을 것이다.

CMMI의 전신에 해당하는 CMM(Capability Maturity Model)은 미국 카네기 멜론 대학(CMU)의 소프트웨어 공학 연구소(SEI; Software Engineering Institute가 IT 개발의 프로세스 관리능력 향상을 위해 미국방성(Department of Defense)의 자금 지원을 받은 프로젝트로 1986년부터 연구하기 시작하여 1991년도에 발표한 표준 모델이다. CMM은 가장 먼저 개발된 SW-CMM을 일컫는 말이기도 하지만 현재는 소프트웨어 이외에도 적용할 수 있는 많은 분야가 있어 이런 부류의 성숙도 모델을 총칭하는 의미로 사용된다. SEI는 2005년부터 CMM에 대한 지원과 업데이트를 중단하고 CMMI 확산에 주력하겠다는 방침을 밝힌바 있다.

CMMI는 항공전자 소프트웨어 개발이나 북미, 유럽, 아시아, 오스트레일리아, 남아메리카, 아프리카 등의 나라들의 정부 주체로 실시하는 프로젝트 등에서 넓게 사용되어 오고 있어 이러한 나라들에서 CMMI에 대한 관심은 높다. 현재, 몇 개의 나라들의 정부기관에서는 소프트웨어 개발 계약에 있어서 지원 업체에게 레벨3 기준을 기본으로 요구하고 있는 실정이다.

기술 솔루션은 성숙 단계 3에 포함된 14개의 프로세스 영역들 중 하나이며 시스템 엔지니어링 활동과 관련하여 CMMI에 새롭게 추가된 프로세스 영역으로써 복잡한 제품을 개발하는 경우에 유용하게 사용될 수 있다.

‘기술 솔루션’ 프로세스 영역의 목적은 요구사항에 대한 솔루션을 설계, 개발, 구현하기 위한 것이다. 여기서 솔루션이란 제품, 제품 컴포넌트, 그리고 제품의 생명주기 프로세스까지 포함하고 있다.

• 요구사항들을 만족시키는 솔루션을 평가, 선택
• 선택한 솔루션을 위한 세부 설계를 개발
• 제품이나 제품 컴포넌트 설계를 구현

• 요구사항 개발(Requirements Development) 프로세스 영역
• 확인(Verification) 프로세스 영역
• 의사결정 분석 및 해결(Decision Analysis and Resolution) 프로세스 영역
• 요구사항 관리(Requirements Management) 프로세스 영역
• 조직 혁신 및 적용 관리(Organizational Innovation and Deployment) 프로세스 영역

기술 솔루션 프로세스 영역에서의 특정 목적과 특정 프랙티스는 다음과 같다.

• SP1.1-1: 구체적인 후보 솔루션 및 솔루션 선정 기준을 개발해야 한다.
  • 후보 솔루션과 선정기준을 개발한다.
• SP1.2-1: 운영 개념 및 운영 시나리오를 구체화해야 한다.
  • 각 제품 컴포넌트를 위한 특정 운영상태, 조건들, 운영방식을 설명하기 위한 운영 개념, 시나리오, 환경들을 구체화한다.
• SP1.3-1: 제품 컴포넌트에 대한 솔루션을 선정해야 한다.
  • 선정 기준을 가장 만족하는 제품 컴포넌트 솔루션을 선정한다.

• SP2.1-1: 제품 혹은 제품 컴포넌트에 대한 설계 작업을 수행해야 한다.
  • 제품이나 제품 컴포넌트에 대한 설계 작업을 수행한다.
• SP2.2-1: 기술 데이터 패키지를 정의해야 한다.
  • 기술 데이터 패키지란 제품 아키텍처, 요구사항, 컴포넌트, 개발 프로세스, 주요 제품 특징, 물리적인 제품 특성 및 제약사항, 인터페이스 요구사항, 컴포넌트에 대한 요구사항, 제조 과정에서의 요구사항, 검증기준, 사용조건 및 사용법, 의사결정 근거 등을 포함하는 개념으로 개발해야 하는 제품이나 제품 컴포넌트에 대해 개발자들이 명확하게 이해할 수 있도록 설명해 놓은 것이라고 할 수 있다.
• SP2.3-1: 기준에 근거하여 인터페이스를 설계해야 한다.
  • 제품 컴포넌트 인터페이스를 위한 솔루션을 수립하고 유지한다.
• SP2.4-1: 자체 개발, 구매, 혹은 재사용에 대한 분석 작업을 수행해야 한다.
  • 선정기준에 따라 제품 컴포넌트를 자체 개발, 구매, 재사용할지에 대한 평가를 수행한다.

• SP3.1-1: 설계를 구현해야 한다.
  • 제품 컴포넌트의 설계를 구현한다.
• SP3.2-1: 제품 지원 문서를 개발해야 한다.
  • 엔드유저를 위한 문서를 개발하고 유지한다.

모든 프로세스 영역에서 공통적으로 적용될 수 있는 목적으로 기술 솔루션 프로세스가 조직에 내재화되어 있는지 판단하는데 도움을 준다.

• GG 1 특정 목표들을 달성한다.
  • GP 1.1 기본 프랙티스들을 수행
• GG 2 관리 프로세스를 내재화한다.
  • GP 2.1 조직의 정책 수립
  • GP 2.2 프로세스 계획
  • GP 2.3 자원 제공
  • GP 2.4 책임 할당
  • GP 2.5 훈련
  • GP 2.6 구성요소 관리
  • GP 2.7 관련 이해관계자들 식별 및 포함
  • GP 2.8 프로세스 관찰 및 통제
  • GP 2.9 객관적인 평가
  • GP 2.10 높은 수준의 관리와 상태 검토
• GG 3 정의된 프로세스 내재화한다.
  • GP 3.1 정의된 프로세스 수립
  • GP 3.2 개선 사항 수집
• GG 4 정량적으로 관리하는 프로세스를 내재화한다.
  • GP 4.1 프로세스를 위한 정량적 목표들을 수립
  • GP 4.2 하위 프로세스 성능의 안정화
• GG 5 최적의 프로세스를 내재화한다.
  • GP 5.1 계속적인 프로세스 개선을 보증
  • GP 5.2 문제의 근본적인 원인

기술 솔루션 프로세스 영역에는 여러 개의 대안들에 대한 분석 활동을 통해 요구사항을 충족시킬 수 있는 솔루션을 선정하고, 운영 시나리오를 개발하고, 설계 작업을 수행하고, 기술 데이터 패키지를 작성하고, 구체적인 인터페이스를 설계하고, 자체 개발, 구매 또는 재사용에 대한 분석 작업을 수행하고, 제품 지원 문서를 개발하는 활동 등이 포함된다.

• 능력 성숙도 모델

• Mary Beth Chrissis, Mike Konrad, Sandy Shrum CMMI®: Guidelines for Process Integration and Product Improvement, 2003

• CMMI 공식 웹사이트
• 한국 CMMI 포럼
• S3M Archived 2008년 6월 7일 - 웨이백 머신
• (영어) 능력 성숙도 통합 모델 - Curlie
• List of Published SCAMPI Appraisal Results (CMMI레벨검색사이트)