ITPE Momentum

1. CMMI 모델의 등장 배경과 개념

1984년 카네기멜론 대학에 소프트웨어 공학 전문 연구소인 SEI(software engineering institute)가 미 국방성의 지원을 받아 미국 소프트웨어 산업 능력을 향상시킬 목적으로 설립되었다. 미 국방성이 이 연구소에 요청한 것은 소프트웨어를 위한 성숙도 모델의 개발이다. 미 국방성은 수많은 업체로부터 소프트웨어 납품을 받는데 업체마다 품질이 달랐다.

그래서 업체의 개발 능력이 과연 어느 정도인지 객관적으로 측정하고, 요구하는 품질에 대한 기준을 제시해줄 목적으로 요청을 한 것이다. 그 결과 성숙도 모델인 SW-CMM(SW-Capability Maturity Model, 이하 CMM)이 만들어졌다. 이는 프로젝트 개발 조직에서 프로세스 성숙도가 높은 조직이 성숙도가 낮은 조직보다 높은 품질의 소프트웨어를 생산할 수 있다는 모델이다.

CMM은 소프트웨어 공급자의 강점과 약점을 평가하는 수단으로, 개발자가 프로세스의 능력을 스스로 평가하고 평가 결과에 따른 개선 방향을 설정하는 데도 사용되었다. 이 후 여러 모델이 추가 개발되고, 소프트웨어 사용 환경의 변화, 기존 모델 등과의 중복 문제 등을 해결하기 위하여 새로운 모델의 필요성이 대두되었다.

SEI는 소프트웨어 역량 성숙도 모델 CMM 2.0 버전과 SECM(System Engineering Capability Model) 그리고 통합제품개발(integrated product development)-CMM 모델을 통합하고 정리하여 ISO 15504(SPICE)와 호환이 가능한 CMMI라는 통합 모델을 2000년 8월 발표하게 되었다. CMM과 CMMI의 차이는 [표 9-12]와 같다.

CMMI(Capability Maturity Model Integration)는 프로세스 표준화의 기준과 방향을 제시하므로 조직 프로세스에 대한 측정뿐 아니라 평가 지표로도 활용할 수 있는데, 이때 능력을 평가하거나 성숙도를 평가할 수 있다. CMMI의 각 약자는 다음과 같은 의미를 지닌다.

■ C(능력, Capability)
일반적으로 능력이 있다, 없다는 뭔가를 할 수 있는 힘이 있느냐, 없느냐로 말할 수 있다. 소프트웨어 개발에서 능력이란 개발 목표(주어진 기간, 정해진 비용, 고품질 등)를 달성할 수 있는 힘이다. 능력이 있는 조직은 개발 목표를 달성할 수 있다. 그러나 능력이 없는 조직은 개발 기간이 연장된다거나 비용이 더 추가된다거나 품질이 떨어지는 소프트웨어를 개발함으로써 개발 목표를 달성하지 못한다.

■ M(성숙도, Maturity)
성숙의 사전적 의미는 '생물의 발육이 완전히 이루어짐', '몸과 마음이 자라서 어른스럽게 됨', '경험이나 습관을 쌓아 익숙해짐' 등으로, 다 자라서(완성되어) 책임감이 있는 느낌을 준다. 소프트웨어 개발에서 성숙도가 높은 조직이란 책임감이 있는 조직으로서 사용자가 만족하는 고품질의 소프트웨어를 개발하기 위해 개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어지는 조직을 말한다.

반면 성숙하지 못한 조직은 책임감이 떨어지는 서투른 조직으로, 개발 프로세스가 객관적인 근거에 의해 진행되지 않기 때문에 사용자가 만족하는 고품질의 소프트웨어가 만들어질 수 없다.

■ M(모델, Model)
여기서 모델은 일반적으로 알고 있는 모델의 의미와 약간 다르다. 여기서는 프로세스를 감사(audit)하는 의미로 사용한다. 즉 기준대로 하고 있는지, 그렇지 않은지를 검사하는 것이다. CMMI는 그 기준을 제시하고 있는데 그것이 '수행 지침(best practice)'이라는 모델이다. 조직이 프로세스 개선을 원한다면, CMMI는 그 조직이 무엇을 해야 하는지에 대해 '수행 지침'을 통해서 알려준다. 그러나 구체적으로 어떻게 할지는 조직의 역량에 맡겨둔다.

■ I(통합, Integration)
여러 가지 프로세스의 기준을 하나로 통합했다는 의미이다. 소프트웨어 개발 생명주기의 각 단계, 즉 계획부터 유지보수까지 모든 과정을 통합한 모델이라는 의미가 있다.

결국 CMMI는 조직의 프로세스에 대한 가이드이자 기준이며 '능력'과 '성숙도'로 조직의 프로세스를 측정하고 평가하는 모델의 통합 버전인 프로세스 개선 성숙도 모델이라 할 수 있다.

2. CMMI의 구성

CMMI는 개발 조직의 소프트웨어 프로세스 성숙도를 [표 9-14]처럼 5단계로 구분한 후, 각 단계별 목적을 달성하기 위해 [표 9-15]와 같이 4개의 범주로 구분된 22개의 프로세스 영역(PS: Process Area)으로 구성하고 있다.

CMMI는 22개 각각의 프로세스 영역을 만족시키기 위해서 반드시 일반(공통) 목표(GG: Generic Goal)와 세부(구체) 목표(SG: Specific Goal)를 만족시켜야 한다.

■ 일반 목표와 수행 지침
• 목표 : 모든 프로세스 영역에 공통으로 적용되는 목표로서 하나의 프로세스 영역에서 일반적인 목표를 달성했다는 것은 해당 프로세스의 활동들이 조직에 내재화되어 자연스럽게 수행될 수 있음을 의미한다.

• 수행 지침 : 일반적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명한다.

■ 세부 목표와 수행 지침
• 목표 : 특정 프로세스 영역에만 적용되는 좁은 의미의 구체적인 목표로서 특정 프로세스 영역을 만족시키기 위해서는 반드시 세부적인 목표를 완전히 만족시켜야 한다.

• 수행 지침 : 세부적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명한다.

각 프로세스 영역의 구성 요소는 3가지 범주로 그룹화되는데, 22개의 프로세스 영역(PA)이 [그림 9-18]과 같은 구조를 따른다. 반드시 달성해야 할 필수 구성 요소에 일반 목표와 세부 목표가 있고, 수행할 것으로 기대되는 예상 구성 요소에는 일반 수행 지침과 세부 수행 지침이 있으며, 정보 제공 측면의 다양한 구성 요소가 있다.

■ 필수 구성 요소
조직이 프로세스 영역을 만족시키기 위해 무엇을 성취해야 하는지를 기술하는 구성 요소이다. 세부 목표와 일반 목표가 이에 해당한다. 목표를 만족시키는 것은 프로세스 영역이 만족되었는지를 결정하기 위한 기반으로 평가 시 사용된다.

■ 예상 구성 요소
조직이 필수 구성 요소를 성취하기 위해 전형적으로 무엇을 구현해야 하는지를 기술하는 구성 요소이다. 이 구성 요소들은 누가 평가를 수행하고 개선을 구현하는지를 가이드한다. 일반 수행 지침과 세부 수행 지침이 이에 해당된다.

■ 정보 제공 구성 요소
필수 구성 요소와 예상 구성 요소에 접근할 수 있도록 돕는 세부 내용을 제공한다. 예제 작업 산출물, 하위 지침, 일반 수행 지침의 정책, 입문 노트, 관련 프로세스 영역 등이 이에 해당된다.

3. CMMI의 평가 방법

CMMI 평가는 단계적 표현(staged representation) 방법의 성숙 단계(maturity level)와 연속적 표현(continuousrepresentation) 방법의 능력 단계(capability level)로 나누어 이루어진다.

4. 단계적 표현 방법의 성숙 단계

성숙 단계는 조직에서 해당 업무를 얼마나 체계적으로 수행하고 있는지를 나타내며, 지표로는 1에서 5까지 5단계로 구분하여 사용하고 있다.

CMMI 성숙 단계는 [표 9-16]과 같이 단계별로 충족되어야 하는 프로세스 영역이 정의되어 있고, [그림 9-21]처럼 계단형으로 구성되어 단계적 표현 방법이라고도 한다. 그리고 각 단계의 프로세스 영역을 모두 만족하면 다음 단계로 넘어간다. 예들 들어, 정의 단계는 관리 단계의 프로세스 영역을 모두 만족하고, 정의 단계의 프로세스 영역까지 모두 만족한다는 의미이다.

5. 연속적 표현 방법의 능력 단계

능력 단계에 대한 이해를 돕기 위해 성숙 단계와 같은 예를 사용해보자. 연속적 표현 방법의 능력 단계는 국어(80점), 수학(90점), 영어(70점), 과학(85점), 사회(78점)의 각 과목별 등급을 정하는 것이다. 즉 능력 단계는 프로세스 영역 능력 수준을 측정하는 연속적 표현 모델로, 해당 조직의 각 프로세스 영역에 대한 능력이 얼마나 되는지를 나타낸다.

능력 단계는 프로세스 영역별 능력 수준을 확인함으로써 어떤 영역이 잘되고, 어떤 영역의 능력이 떨어지는지를 살펴 보완할 부분을 파악하기도 한다.

이렇게 프로세스 영역별 능력 수준을 점검하면 어떤 프로세스 영역이 다른 프로세스 영역에 비해 떨어지는지 알 수 있으므로 그 영역만 집중적으로 관리할 수 있다. 또 중요하다고 생각하는 프로세스 영역에 대해서는 그 수준을 높이기 위해 더 많은 자원을 투입하여 능력 수준을 높일 수 있다. 앞에서 든 비유로 설명한다면, 과학 과목이 다른 과목보다 성적이 낮은 경우 과학 과목을 열심히 공부해서 점수를 올리고, 수학이 중요하다고 생각하면 다른 과목보다 수학을 집중적으로 공부하여 수학 실력을 향상시킬 수 있는 것과 같다.