다음을 통해 공유

CMMI의 배경

  • 아티클

Software Engineering Institute에서는 CMMI(Capability Maturity Model Integration) for Development에 대한 이해를 돕기 위해 "CMMI: Guidelines for Process Integration and Product Improvement"이라는 가이드를 발행했습니다. 이 책에서는 현재 작성 시간을 기준으로 최신 CMMI 제품군 내의 모델 중 하나인 CMMI-DEV(CMMI for Development) 버전 1.3에 대해 구체적으로 설명하고 있습니다. 이 모델은 매우 안정적이며 2010년 현재뿐 아니라 앞으로도 계속 통용될 것입니다. "CMMI Distilled: A Practical Introduction to Integrated Process Improvement"도 이 주제를 다루는 유용하고 이해하기 쉬운 책입니다. 이러한 책에 대한 자세한 내용은 이 항목 뒷부분에 있는 추가 리소스를 참조하세요.

CMMI는 1987년에 처음으로 Carnegie-Mellon 대학의 연구 센터인 Software Engineering Institute에서 CMM(Capability Maturity Model)이라는 프로젝트로 시작했습니다. 이 센터는 미국 국방부의 자금으로 설립되어 운영되고 있습니다. 1991년에 처음 발표된 CMM for Software는 70년대 말과 80년대 초에 소프트웨어 개발 프로젝트에서의 주요 성공 요인을 정리한 검사 목록을 기반으로 합니다. 이 모델은 IBM(International Business Machines) Corporation과 20세기 품질 보증 리더인 Philip Crosby 그리고 W. Edwards Deming의 연구에 의해서도 알려졌습니다. Capability Maturity Model이라는 이름과 이 항목의 뒷부분에서 설명하는 계층적 표현의 5가지 수준은 모두 Crosby의 Manufacturing Maturity Model에서 영감을 얻은 것입니다. 주로 국방에 적용되는 CMM은 상당히 많은 곳에서 채택하게 되었으며 여러 번의 수정과 반복을 거쳤습니다. 이러한 성공은 소프트웨어를 뛰어넘는 다양한 주제에 대한 CMM 개발로 이어졌습니다. 새로운 모델의 급증으로 혼란이 야기되자 미국 정부에서는 200명 이상의 업계 및 학계 전문가가 참여하는 2년 기간의 프로젝트에 자금을 지원하여 시스템 엔지니어링, 소프트웨어 엔지니어링 및 제품 개발을 통합한 확장 가능한 단일 프레임워크를 만들도록 했습니다. 그 결과로 CMMI가 탄생했습니다.

CMMI-DEV를 이해할 때 가장 중요한 점은 이것이 모델이라는 점입니다. CMMI-DEV는 따라야 할 프로세스나 처방이 아닙니다. 이것은 소프트웨어 개발 및 시스템 엔지니어링에서 장점이 입증된 조직적 동작의 집합입니다. 이러한 모델을 사용하는 이유는 무엇인가요? 모델의 목적은 무엇인가요? 어떻게 하면 가장 잘 활용할 수 있나요? 이러한 질문은 CMMI와 관련된 가장 중요한 질문이자 아마도 가장 오해하기 쉬운 내용이기도 합니다.

모델을 사용하는 이유는 무엇인가요?

조직의 운영 방식, 조직에 필요한 기능과 이러한 기능이 상호 작용하는 방식에 대한 모델이 없다면 작업을 개선하기란 어렵습니다. 모델을 사용하면 조직의 개별 요소를 이해하고 개선해야 할 부분과 개선 방법에 대한 언어 및 논의를 형성하는 데 도움이 됩니다. 모델은 다음과 같은 이점을 제공합니다.

  • 의사 소통을 돕는 일반적인 프레임워크와 언어를 제공합니다.

  • 축적된 경험을 활용할 수 있도록 합니다.

  • 거시적인 안목을 유지하면서 개선에 특히 중점을 둘 수 있도록 합니다.

  • 종종 교육 담당자 및 컨설턴트의 지원을 받을 수 있습니다.

  • 불일치 문제를 해결하는 데 유용한 표준을 제공할 수 있습니다.

CMMI 모델의 목적은 무엇인가요?

앞서 언급한 책을 보면 알 수 있듯이 모델의 목적은 조직 프로세스의 완성도를 평가하고 제품 개선으로 이어지는 프로세스 개선을 위한 지침을 제공하는 것입니다. Software Engineering Institute 측 인사와 직접 이야기해 보면 CMMI는 위험 관리용 모델로서 위험을 관리하는 조직의 능력을 나타내는 지표라고 말할 수도 있습니다. 이러한 지표는 조직에서 약속을 지킬 수 있거나 시장의 반응을 이끌어 낼만한 수준 높은 제품을 제공할 수 있는지의 가능성에 대한 증거입니다. 다른 측면에서 보면 CMMI 모델은 조직이 스트레스를 받는 상황에서 얼마나 성과를 낼 수 있는지를 나타내는 좋은 지표로도 생각해 볼 수 있습니다. 완성도가 높고 역량이 큰 조직은 스트레스가 쌓이는 예기치 못한 이벤트에 수월하게 대처하고 반응하고 변화하며 앞으로 나아갑니다. 완성도와 역량이 낮은 조직에서는 스트레스를 받는 상황에서 공황 상태에 빠지거나 필요성이 배제된 절차를 맹목적으로 따르거나 모든 프로세스를 함께 던져 놓고 큰 혼란에 빠지는 경향이 있습니다.

CMMI는 조직의 경제적 성과를 나타내는 좋은 지표로 입증되지는 않았습니다. 완성도가 더 높은 조직은 위험을 더욱 잘 관리하고 예측 가능성이 더 높아질 수 있음에도 불구하고 완성도가 더 높은 기업일수록 위험을 심하게 기피한다는 증거가 있습니다. 이러한 기피 현상은 지연 시간의 증가와 경쟁력 약화를 불러오는 혁신의 부족으로 이어지고 관료주의를 더욱 강화할 수 있습니다. 완성도가 낮은 기업은 보다 혁신적이고 창의적이지만 혼란스럽고 예측하기 힘든 경향이 있습니다. 결과를 달성했을 때 이러한 결과는 개인이나 관리자의 탁월한 노력 덕분인 경우가 많습니다.

CMMI 모델을 활용하는 가장 좋은 방법은 무엇인가요?

이 모델은 프로세스 개선을 위한 기준으로 사용하도록 개발되었으며, 개선도 측정을 위한 지원 시스템으로서 평가용으로만 개발되었습니다. 이러한 용도로 사용하여 얻은 결과는 성공적인 경우도 있고 그렇지 않은 경우도 있습니다. 이 모델을 기존 프로세스에서 메꾸어야 할 수 있는 간극을 식별하는 맵이 아니라 프로세스 정의라고 오해하고 그대로 따르려고 하기가 너무 쉽습니다. CMMI의 기본 구성 요소는 목표와 이러한 목표를 충족하는 데 종종 사용되는 여러 활동을 정의하는 프로세스 영역입니다. 프로세스 영역의 한 가지 예로는 프로세스 및 제품 품질 보증이 있습니다. 또 다른 예로는 구성 관리가 있습니다. 프로세스 영역이 프로세스가 아니라는 점을 이해해야 합니다. 단일 프로세스는 여러 프로세스 영역을 넘나들고 개별 프로세스 영역은 여러 프로세스와 관련되어 있을 수 있습니다.

CMMI-DEV는 실제로는 동일한 내부 요소를 공유하는 두 가지 모델입니다. 첫 번째 모델은 가장 친숙한 모델로서 조직의 5가지 완성도 수준 중 하나에 매핑된 22가지 프로세스 영역을 나타내는 계층적 표현입니다. 조직 평가로 조직의 운영 수준을 평가합니다. 이러한 수준은 조직의 위험 관리 능력을 나타내는 지표가 되므로 약속을 이행할 수 있는 조직의 능력을 나타냅니다.

CMMI 단계적 표현

수준 4와 수준 5는 일반적으로 더 높은 완성도 수준을 가리킵니다. 정량적 관리와 행동의 최적화를 보여주는 완성도가 높은 조직과 단지 관리되고 정의된 프로세스를 따르기만 하는 완성도가 낮은 조직 간에는 대부분 분명한 차이가 존재합니다. 완성도가 높은 조직에서는 프로세스의 가변성이 낮고 일반적으로 통계적인 설명이 가능한 관리 방법의 일부로 선행 지표를 사용합니다. 따라서 완성도가 높은 조직은 예측 가능성이 더욱 높을 뿐만 아니라 다른 관료주의가 방해하지 않는다는 가정하에 새로운 정보에 더 빨리 대응하는 경향이 있습니다. 완성도가 낮은 조직에서는 개인의 탁월한 노력이 빛을 발하는 경향이 있는 반면에 완성도가 높은 조직도 스트레스가 많은 상황에서 맹목적으로 프로세스를 따르다가 프로세스 변경이 보다 적절한 대응일 수 있다는 점을 인식하지 못할 수 있습니다.

두 번째 모델은 각각의 22가지 프로세스 영역 내의 모델 프로세스 기능인 연속적 표현으로, 조직에서 가장 높은 비즈니스 가치를 제공하는 프로세스에 맞춰 향상 노력을 조정할 수 있도록 합니다. 이 모델이 Crosby의 원래 모델과 좀 더 일치합니다. 이 모델을 토대로 평가를 수행하면 업무 수행 능력을 숫자 하나로 나타내는 것이 아니라 프로필로 나타낼 수 있습니다. 물론 조직의 완성도 수준은 대부분의 관리직 및 경영자가 이해하는 수준이므로 연속적 모델 평가의 결과를 다섯 계층에 매핑하는 방법도 있습니다.

CMMI 연속 표현

계층적 모델을 프로세스 개선 프로그램의 기초로 사용할 경우 구현자가 CMMI는 프로세스 또는 워크플로 모델이 아니라 단지 프로세스 및 워크플로에서 달성할 목표를 제공하는 것이라는 점을 잊을 수 있으므로 위험합니다. 이러한 목표를 달성하면 조직의 완성도와 이벤트가 계획대로 전개될 가능성이 높아집니다. 아마도 가장 큰 실패 모델은 수준 달성을 목표로 삼고서 단순히 평가를 통과하기 위해 프로세스 및 인프라를 마련하는 것일 겁니다. 모든 프로세스 개선 활동의 목표는 단순한 수치가 아니라 측정 가능한 개선이어야 합니다.

연속적 모델에는 프로세스 향상에 대한 지침으로 몇 가지 뛰어난 성공 기준이 있는 것처럼 보이고 일부 컨설팅 회사에서는 연속적 모델에 대한 지침만 제공하기로 선택하고 있습니다. 가장 확실한 차이점은 연속적 모델을 기준으로 마련된 프로세스 향상 프로그램에는 완성도 수준으로 결정된 인위적인 목표가 없다는 사실입니다. 연속적 모델은 본질적으로 조직에 대한 경제적 이점을 활용할 가능성이 가장 큰 영역에 프로세스 개선 사항을 적용하는 데 적합합니다. 따라서 연속적 모델을 따르는 조직에서는 CMMI 모델 기반의 이니셔티브로부터 긍정적인 피드백을 받을 가능성이 더 큽니다. 게다가 긍정적인 피드백은 뛰어난 개선 주기를 개발하는 원동력이 될 가능성이 높습니다.

CMMI 모델의 요소

CMMI 모델은 아래 테이블에 표시된 22가지 프로세스 영역으로 나뉩니다.

머리글자어

프로세스 영역

CAR

원인 분석 및 해결(Causal Analysis & Resolution)

CM

구성 관리(Configuration Management)

DAR

의사 결정 분석 및 해결(Decision Analysis & Resolution)

IPM

통합 프로젝트 관리(Integrated Project Management)

MA

측정 및 분석(Measurement & Analysis)

OID

조직 혁신 및 배포(Organizational Innovation & Deployment)

OPD

조직 프로세스 정의(Organizational Process Definition)

OPF

조직 프로세스 중점(Organizational Process Focus)

OPP

조직 프로세스 성과(Organizational Process Performance)

OT

조직 교육(Organizational Training)

PI

제품 통합(Product Integration)

PMC

프로젝트 모니터링 및 제어(Project Monitoring & Control)

PP

프로젝트 계획(Project Planning)

PPQA

프로세스 및 제품 품질 보증(Process & Product Quality Assurance)

QPM

정량적 프로젝트 관리(Quantitative Project Management)

RD

요구 사항 정의(Requirements Definition)

REQM

요구 사항 관리(Requirements Management)

RSKM

위험 관리(Risk Management)

SAM

공급자 계약 관리(Supplier Agreement Management)

TS

기술 솔루션(Technical Solution)

VER

확인

VAL

유효성 검사

계층적 표현에서 이러한 프로세스 영역은 다음 그림에 표시된 것과 같이 각 계층에 매핑됩니다.

프로세스 영역이 표시된 단계 표현

연속적 표현에서 이러한 프로세스 영역은 다음 그림에 표시된 것과 같이 기능적 그룹에 매핑됩니다.

프로세스 영역이 표시된 연속 표현

각 프로세스 영역은 필수 구성 요소, 기대 구성 요소 및 정보 구성 요소로 구성됩니다. 이 모델을 기준으로 한 평가를 만족시키는 데 실제로 필요한 것은 필수 구성 요소뿐입니다. 필수 구성 요소는 각 프로세스 영역의 구체적이고 일반적인 목표입니다. 기대 구성 요소는 각각의 구체적이거나 일반적인 목표를 달성하기 위한 구체적이고 일반적인 방법입니다. 기대 구성 요소는 단지 기대될 뿐 반드시 필요한 것은 아니므로 구체적이거나 일반적인 방법을 같은 종류의 다른 방법으로 대체할 수 있음을 나타냅니다. 기대 방법은 구현자와 평가자를 안내하는 용도로 사용됩니다. 대체 방법이 선택된 경우 평가자에게 조언하고 어떤 대체 방법이 적절한지 이유를 설명하는 것은 구현자가 할 일입니다. 정보 구성 요소는 구현자가 CMMI 모델의 지침을 따르는 프로세스 개선 활동을 쉽게 시작할 수 있도록 세부 정보를 제공합니다. 정보 구성 요소에는 일반적이고 구체적인 방법의 하위 방법과 일반적인 작업 산출물이 포함됩니다.

오직 일반적이고 구체적인 목표만이 필요하다는 점을 이해하는 것은 매우 중요합니다. 그 밖의 모든 구성 요소는 안내 용도입니다. CMMI 연구에서 제공되는 기대 구성 요소와 정보 구성 요소의 예는 대규모 우주 및 국방 시스템 통합 프로젝트에서 흔히 찾아볼 수 있습니다. 이러한 프로젝트는 Carnegie-Mellon 대학의 Software Engineering Institute를 후원 및 지원하는 업체에서 운영하고 있습니다. 이러한 프로젝트는 개별 조직에서 맡은 프로젝트의 형식과 맞지 않을 수도 있고, Agile 소프트웨어 개발 방법의 출현과 같은 업계 최신 동향을 반영하지 않을 수도 있습니다.

추가 리소스

자세한 내용은 다음 웹 리소스를 참조하세요.

참고 항목

개념

Visual Studio ALM용 MSF for CMMI Process Improvement