능력 성숙도 모형 결합

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 찾기

능력 성숙도 모형 결합(Capability Maturity Model Integration, 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)"로 나뉘어 배포되기 시작하였다. 현재 2010.12월 1.3v이 최종 발표되었다

CMMI의 프로세스 영역 [편집]

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

CMMI가 지원하는 지식체계의 범위 [편집]

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

시스템 공학(Systems engineering) [편집]

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

소프트웨어 공학(Software engineering) [편집]

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

통합제품 및 프로세스 개발(Integrated product and process development) [편집]

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

  • 통합제품 및 프로세스 개발의 프로세스 영역(Process Area)

공급자 소싱(Supplier sourcing) [편집]

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

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

CMMI가 지원하는 프로세스 영역의 분류 [편집]

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

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

프로세스 관리 [편집]

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

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

프로젝트 관리 [편집]

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

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의 역량 성숙도 [편집]

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

CMMI의 조직 성숙도 [편집]

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의 성숙도 레벨은 평가 조직의 프로세스를 개선 및 평가하기 위해 실행해야할 실행지침을 포함하며, 성숙한 조직의 각 레벨별 특징은 아래와 같다.

소프트웨어 프로세스 성숙도 레벨 5단계 [편집]

  • 레벨 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) - 소프트웨어 프로세스와 소프트웨어 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다.
    • 프로젝트 활동이 정략적으로 관리․통제되고 성과 예측이 가능한 조직
    • 적용 프로세스
  • 레벨 5(Optimizing) - 이 레벨에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.
    • 지속적인 개선활동이 정착화 되고 최적의 관리로 프로젝트가 수행되는 조직
    • 적용 프로세스

CMMI의 프로세스 개선 효과 [편집]

전 세계 많은 기업들은 조직의 프로젝트 수행능력 향상을 위해 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 기준을 기본으로 요구하고 있는 실정이다.

바깥 고리 [편집]

위키미디어 공용에 관련 미디어 분류가 있습니다.
System-installer.svg 이 글은 소프트웨어에 관한 토막글입니다. 서로의 지식을 모아 알차게 문서를 완성해 갑시다.
원본 주소 "http://ko.wikipedia.org/w/index.php?title=능력_성숙도_모형_결합&oldid=10354217"