IT 조직의 역량 강화를 위한 CMMI 기반의 프로세스 개선 · 2015-07-15 ·...

CMMI(Capability Maturity Model Integration) 특집 연재 2005 년 10 월호

IT 조직의 역량 강화를 위한 CMMI 기반의 프로세스 개선

전세계 산업계 표준으로 정착된 CMMI, 올바로 이해하고 적용해야

지난 20 여 년간 소프트웨어의 수요는 100 배 이상 증가하였고, 현재도 매년 12% 이상의 증가율을 보이고 있으나 소프트웨어의 생산성과 품질수준은 사용자들의 요구를 따라가지 못하고 있을 뿐만 아니라, 대부분의 소프트웨어 프로젝트는 처음 수립된 계획 기간 내에 끝내기 조차 어려운 경우가 많았다. IT 전문 조사 기관인 Standish Group 에서 발표한 “Chaos Report(2004)”에 의하면 조사 대상 개발 프로젝트 중, 약 24%의 프로젝트만이 품질, 납기, 비용을 충족한 것으로 나타난 반면, 실패한 프로젝트가 전체의 19%를 그리고 비정상적으로 종료된 프로젝트가 전체의 57%를 차지하는 것으로 나타났다.

이러한 문제점을 해결하기 위해 많은 조직에서 개발 프로젝트를 수행할 때에 객체지향 방법론, CBD 방법론, 프로토타이핑 개발방법 등과 같은 개발 방법론을 도입, 적용하거나, C 와 Ada 등의 구조적 언어의 도입, 시스템 개발 도구인 CASE Tool 활용 등의 노력을 시도하였지만, 근본적인 해결책은 되지 못하고 부분적인 성과만 거두었다. 소프트웨어 업계는 차츰 도구(Tool)나 기술도입의 한계를 경험하게 되면서 이러한 문제점의 근본적인 원인이 소프트웨어 프로세스의 관리 부재라는 것을 인식하게 되었다. 업무수행 방법에 대한 원칙(계획, 절차 등 포함) 부재, 작업자의 경험에 의존한 임기응변(ad-hoc)식의 업무 수행, 적절한 스킬을 갖춘 인원의 부족 등은 소프트웨어 프로세스 관리 부재의 대표적인 현상이었다. 소프트웨어 업계는 이를 해결하기 위해 조직의 현재 소프트웨어 프로세스 상태를 파악하고, 해당 프로세스가 원하는 목표에 도달할 수 있도록 소프트웨어를 개발, 유지보수 하는 과정에서 이루어지는 모든 일련의 활동들을 보다 효율적이고 효과적으로 개선하는 프로세스적인 접근 방법인 소프트웨어 프로세스 개선(Software Process Improvement)을 모색하게 되었다.

이러한 문제에 대한 인식은 국내에서 또한 나타나기 시작하였으며 최근 들어 많은 기업들이 앞 다투어 미국 카네기 멜론 대학 부설 연구개발 센터인 소프트웨어 공학 연구소(Software Engineering Institute, SEI)가 개발한 능력 성숙도 모델(Capability Maturity Model, CMM)이나 통합된 능력 성숙도 모델(Capability Maturity Model, CMMI) 등을 기반으로 한 프로세스 개선 활동을 전개하기 시작하였다.

국내 기업의 프로세스 개선 활동은 급변하는 내/외부적인 환경 변화에 능동적으로 대응하고자 하는 차원에서 시작하게 되었는데, 대표적인 외부 요인으로는 CMM 이나 CMMI 가 소프트웨어 산업계의 능력을 인정해 주는 국제 인증 장치로서 입지를 강화해 가면서 특히, 해외 시장 진입에 있어 CMM 이나 CMMI 가 하나의 평가지표로 활용되게 되면서 해외 진출을 노리는 국내 시스템 통합(System Integration, SI) 업체나 소프트웨어 패키지 등을 개발하는 벤처 기업에서 프로세스 개선 활동이 수출을 위한 하나의 수단이

IT Business Journal


되었기 때문이다. 아울러 최근 국내 정부에서도 소프트웨어 산업의 육성 및 발전을 위하여 소프트웨어 전문 기업 제도 등의 도입을 시도하고 있는데 이러한 전문 기업의 자격을 부여할 때에 해당 기업의 소프트웨어 프로세스 능력을 평가한다는 기준을 마련하고 있으며, 한편으로는 일부 공공기관이나 금융기관에서는 이미 소프트웨어 개발 프로젝트를 발주할 때에 아예 CMM 이나 CMMI 에 따른 일정 능력 성숙도 수준을 확보한 개발 업체에 대해서만 입찰에 참여할 수 있는 자격을 부여하고 있다.

내부적인 요인으로는 국내기업의 대표적인 문화인 “빨리빨리”, “대충대충” 문화가 대부분의 IT 업무에 유입되어 계획적이고, 체계적이며, 표준화된 업무 수행이 이루어지지 않았고 그 결과로 인해 소프트웨어 개발 시 품질 저하와 재 작업이 과다하게 수행되었을 뿐만 아니라 개발이 완료된 후에도 막대한 유지보수 비용이 발생하는 등의 문제점이 발생하였다는 점이다. 특히 최근의 정보기술 환경은 정보시스템이 통합화 되어가고 있으며 이러한 상황에서 기존의 몇몇 능력 있고, 경험 있는 인력에 의해 시스템을 관리하는 방식으로는 통합된 정보시스템을 관리할 수 없으므로 이를 해결하기 위한 수단으로 프로세스 개선 활동의 필요성을 인식하게 된 것이다.

국내에 프로세스 개선 활동이 본격화 되기 시작한 것은 1990 년대 후반으로 몇몇 대기업의 SI 업체 및 소프트웨어 개발업체를 중심으로 프로세스 개선 활동을 위한 참조 모델로 CMM 을 적용하기 시작 하면서부터였다. 그러나 국내 기업의 프로세스 개선 활동은 아직 초보적인 수준으로 2004 년에 한국소프트웨어진흥원 소프트웨어공학센터와 공동으로 실시한 국내기업 대상 정보기술 프로세스 능력 성숙도 수준 조사(CMM 기반)에 따르면 조사대상 30 개 기업 중, 2 개 기업(2 단계: 1 개, 3 단계: 1 개)을 제외한 28 개 기업의 능력 성숙도는 여전히 초기 단계인 1 단계인 것으로 나타났다.

% o

f Org

aniz

atio

ns

100%

1단계 2단계 3단계 4단계

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%93.4%

3.3% 3.3%

<그림 1> 2004년 IT 프로세스 능력수준 조사 결과

출처 : IT 프로세스 능력 성숙도 조사 결과 보고서, 한국소프트웨어진흥원, 2004

% o

f Org

aniz

atio

ns

100%

1단계 2단계 3단계 4단계

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%93.4%

3.3% 3.3%

<그림 1> 2004년 IT 프로세스 능력수준 조사 결과

출처 : IT 프로세스 능력 성숙도 조사 결과 보고서, 한국소프트웨어진흥원, 2004

IT Business Journal


이와 같이 성숙도 수준이 낮게 나타난 데에는 여러 가지 원인이 있을 수 있겠지만 많은 조직들이 프로세스 개선 활동의 필요성에 공감하면서도 프로세스 개선 활동을 어떻게 시작하고 접근해 나가야 되는지를 몰라 아예 시도를 위한 엄두조차 내지 못하거나 활동을 수행하기는 하지만 체계적인 접근 방법이 이루어 지지 않아 활동을 수행하는 만큼의 실효성을 얻지 못하는 데에 기인한다고 할 수 있겠다. 상대적으로 성숙도가 높고 CMM 이나 CMMI 를 이미 적용하고 있는 조직에서도 여전히 이러한 모델 적용의 어려움을 호소하고 있으며, 많은 시행 착오를 반복하고 있다. 이와 같은 현상이 나타나는 요인은 CMM 이나 CMMI 모델의 내용이 국내 환경과는 다소 이질적인 용어로 무엇을(What) 하라는 방향을 주로 제시할 뿐 어떻게(How) 하는 지에 대한 구체적인 가이드라인이 부족하기 때문이다. 따라서, 금번 CMMI 특집에서는 CMM 이나 CMMI 모델을 올바로 이해하고 적용하는 데 고려해야 할 사항들을 총 3 회에 걸쳐 알아 보고자 한다.

프로세스란 무엇인가

프로세스는 문제를 해결하는 것을 도와주는 일련의 단계들(Steps)이다. 이들 단계들은 애매모호하지 않은 방법으로 정의되어야 한다. 즉, 쉽게 이해할 수 있으며 프로세스를 사용하는 어떠한 사람이라도 일관된 방법으로 따를 수 있어야 한다. 왜 이러한 활동들이 일관적으로 수행되어야 하는가? 직원들을 로봇으로 만들도록 우리가 부추기고 있는 것은 아닌가? 프로세스에 중점을 두는 것은 대다수의 조직에서 쓸데없이 반복되는 일들을 줄이고자 하는 것이다. 왜 우리는 새로운 프로젝트를 시작 할 때마다 매번 새로이 틀을 만들어야 하는가? 우리는 매번 프로젝트를 수행할 때 마다, 프로젝트 계획서를 제출하라는 요구를 받고 있는데, 왜 우리 조직은 그것을 작성하는 방법을 설명해주는 절차서를 우리에게 제공해 주지 않는가? 왜 샘플 문서로부터 필요한 내용을 복사하여 쉽게 붙여 넣을 수 있도록 하지 않는가? 우리가 매번 프로젝트 계획서를 새로 만들기 위해 피땀을 흘리는 것 보다는 훨씬 쉬운 일이 아닌가?

프로그램을 개발하는 경우에도 이러한 상황은 유사하다. 대부분의 프로젝트 관리자는 어떤 특정한 프로그램을 구현하는 것이 얼마나 어려운지 물어 보지 않는다. 각 프로그램을 코딩 하는데 얼마나 시간이 걸리는지 물어 보지는 않고 단지 개발자들에게 할당된 프로그램들의 리스트를 전해 주고는 언제까지 가능한지 기한을 말하라고만 한다. 때로는 프로젝트 관리자의 잘못된 견적으로 인한 현실과 동떨어진 작업 일정 때문에 가슴앓이를 하고 매일 야근에 심지어는 주말 작업까지 하여야 한다. 그것도 아무런 보상 없는 무급으로 말이다. 만약 우리가 가진 정보를 입력하여 일정을 예측하는 프로세스를 가지게 된다면 좀 더 현실적인 일정을 도출해 내는 것이 가능 할 것이며, 이해되지 않거나 보이지 않는 무형의 절차를 충실히 따라야 하는 짐을 덜어주는데 도움을 줄

IT Business Journal


것이다.

그렇다면 이 일정수립 프로세스가 언제나 완벽한가? 물론 그렇지 않을 수 있다. 그러나 이 프로세스가 최소한 우리에게 일정에 대한 협상의 여지를 남겨 준다는 것이 중요하다.

프로세스들은 조리법과 같다. 이 조리법은 우리에게 재료를 알려주고, 어떻게 재료를 배합할 것인지, 어떻게 온도를 조절할 것인지, 그리고 얼마나 오랫동안 이 재료들을 요리 해야 하는지 알려준다. 그러나 조리법이 우리에게 재료를 자르고 혼합하고 두들기고 거품 내고, 굽고, 삶고 하는 기술을 가르쳐 주는 것은 아니다. 실습하고 보완하고 개선시켜 나가는 것은 우리의 몫인 것이다.

CMM 및 CMMI 의 탄생

대다수의 조직들은 경쟁적인 시장환경에서 이익을 창출하기 위해 고군분투하고 있으며, 경영층은 이를 위한 보다 효과적인 방안을 모색하곤 한다. 그들은 경영과 전략 그리고 그들이 배운 원칙을 적용하는 데 도움이 될 만한 책들을 읽어 보기도 하고, 때로는 그들 조직이 가지고 있는 문제점을 진단하여 개선안을 도출해 줄 수 있는 컨설턴트를 고용하기도 한다.

CMM 은 이러한 조직의 개선을 위한 접근법 중의 하나로, 이는 소프트웨어 엔지니어링, 시스템 엔지니어링, 인적자원 관리(People Management) 및 소프트웨어 획득 등 특별한 원칙들에 대한 베스트 프랙티스들을 모아 놓은 것이다. 각 각의 개별적 모델들은 조직 프랙티스의 효과성을 평가하는 데 사용할 수 있는 진단 방법을 포함하고 있다.

소프트웨어 공학 연구소와 능력 성숙도 모델

1991 년 미국 카네기 멜론대 부설 소프트웨어 공학 연구소(Software Engineering Institute, SEI)는 소프트웨어를 위한 능력 성숙도 모델(SW-CMM)을 발표하였는데, 이 모델은 조직의 소프트웨어 개발 및 유지보수 능력을 향상시키기 위한 핵심 프랙티스들로 구성되어 있다. SW-CMM 의 접근 방법은 지난 60 년간 지속적으로 관심을 기울여 왔던 제품 품질 관리의 원칙을 근거로 한다. 1930 년대에 Walter Shewhart 에 의해 발표된 통계적 품질관리(Statistical Quality Control, SQC)의 개념은 이후 W. Edwards Deming 과 Joseph Juran 그리고 Phillip Crosby 에 의해 더욱 발전되고 성공적으로 증명되었다. 그리고 이러한 개념들은 SEI 에 의해 받아 들여져 소프트웨어 개발 및 유지보수 프로세스를 지속적으로 개선하기 위한 모델을 개발하는 데 기초가 되었다.

SW-CMM 의 접근법은 전세계 소프트웨어 프로세스를 개선하는 데 지대한 영향을 끼치게 되어 2004 년 12 월말 기준으로 전세계 60 개국 1,036 개 기업에서 도입, 적용하고

IT Business Journal


있는 산업계 표준(De Facto)으로 널리 사용되게 되었다.

SEI 는 SW-CMM 이외에도 시스템 엔지니어링 능력 성숙도 모델(SE-CMM)과 통합된 제품개발 능력 성숙도 모델(IPD-CMM) 등 타 영역에 대한 모델도 추가적으로 개발하여 발표하였다. SW-CMM 과 SE-CMM 그리고 IPD-CMM 은 조직 및 프로젝트 관리 프로세스를 보여줄 뿐만 아니라, 제품 또는 서비스의 개발과 유지보수에 있어서 모든 적합한 원칙들의 상호 보완에 초점을 맞추고 있다.

이렇듯 다른 영역들의 원칙들을 위한 다양한 능력 성숙도 모델의 개발은 긍정적으로 받아 들여지고 있다. 프로세스 개선은 더욱 많은 원칙들에 영향을 끼치고 있으며, 조직으로 하여금 그들의 제품과 서비스를 보다 잘 개발하고 유지 보수할 수 있게끔 도움을 준다. 그러나 이러한 확장은 한편으로는 도전을 불러 일으키기도 한다.

다양한 능력 성숙도 모델은 제품의 품질과 생산성 향상을 위하여 하나 이상의 모델이 조화를 이루며 함께 사용될 때 보다 큰 이익을 창출해 낼 수 있다. 그러나 조직의 많은 관리자들은 SW-CMM 과 SE-CMM 그리고 IPD-CMM 에 대해 모델 상호간의 중첩된 부분과 구조의 다름으로 인해 현장에 적용하는 데 많은 어려움과 비용이 따른다고 불만을 토로하곤 한다. 교육훈련과 진단 그리고 개선 활동들은 이러한 원칙들이 어떻게 통합되어 수행되어야 하는 지에 대한 지침 부족으로 인하여 종종 불필요하게 반복 수행되곤 하였다. 이로 인하여 조직들은 CMM 관련 모델들을 기초로 한 개선 활동들을 성공적이면서도 쉽게 통합할 수 있는 방법이 필요하게 되었다. 다시 말해, 모델 자체의 통합이 필요하게 된 것이다.

능력 성숙도 모델 통합의 필요성

CMM 관련 모델들 및 이의 교육과정 그리고 진단 방법들을 보다 잘 활용하기 위한 통합의 필요성이 각계 각층으로부터 요구되기 시작하였으며, 이에 따라 the Office of the Under Secretary of Defense for Acquisition and Technology 는 CMMI 프로젝트를 주관하게 되었다. 다양한 조직의 다양한 경험을 보유한 전문가들이 본 프로젝트의 참여를 권유 받았으며, 그들은 현재 및 미래에 활용할 보다 나은 모델을 개발하기 위하여 참여하게 되었다.

1998 년 2 월, 산업계와 정부 그리고 SEI 는 소프트웨어 산업에 있어서 가장 기본이 되는 소프트웨어 엔지니어링, 시스템 엔지니어링 그리고 통합된 제품 및 프로세스 개발의 세가지 원칙을 커버하는 통합된 모델 개발에 착수하게 되었다. 그리고 이 통합된 모델(CMMI) 개발을 위하여 다음의 세가지 모델이 참조되었다.

- Capability Maturity Model for Software (SW-CMM) version 2.0 draft C

- Electronic Industries Alliance Interim Standard 731 (EIA/IS 731),

IT Business Journal


Systems Engineering Capability Model (SECM)

- Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98a

“프로세스 개선 모델을 통합하는 것은 결코 쉬운 일이 아니다. CMMI 프로젝트를 위해 활용되는 기초 모델들은 각기 다른 접근법과 구조를 가지고 있으며 각각의 모델들은 약간은 상이한 주제들을 커버한다. CMMI 프로덕트 개발 팀은 종종 다양하면서도 어려운 이슈들을 해결하기 위해 충돌하곤 한다. 특히, 어려운 점은 CMMI 프로덕트가 다양한 조직들의 현재 요구사항뿐만 아니라, 향후에 발생 가능한 더 많은 조직들의 요구사항까지도 반영할 수 있어야 한다는 것이다.”라고 구조설계 책임자인 로저 베이트는 이야기 한다.

개발 팀의 또 다른 사명은 CMMI 프로덕트가 국제 표준화 기구의 15504 표준 (ISO15504, 일명 SPICE)을 준수하여 비록 조직이 CMMI 프로덕트를 활용하더라도 국제적 표준에 벗어나지 않도록 하는 데에 있었다.

CMMI 프로젝트는 프로세스 개선에 대한 정부와 업계의 투자를 유지하는 한편, 보다 폭 넓은 기업에 본 프로덕트가 적용될 수 있도록 노력하였다. 더욱이 광범위한 원칙들 안에서 CMM 적인 접근의 활용도를 높이기 위하여, CMMI 에는 일반적으로 사용되는 전문용어 및 구성 요소 그리고 진단 방법과 교육훈련 교재들이 사용된다. 정부, 산업계 그리고 SEI 등 각계 각층의 다양한 전문가들로 구성된 그룹들이 CMMI 프로덕트를 개발하고 검토하는 데 참여하였으며, CMMI 프로덕트 내용의 충실성을 기하기 위해 일반인 검토를 수행하기 전에 핵심 그룹에 의한 집중적인 검토가 이루어 졌다.

CMMI 의 현재 상태

CMMI 프로덕트는 CMMI 모델과 프레임워크, 교육훈련 교재 및 진단 방법론으로 구성 된다. CMMI 프레임워크는 각기 다른 원칙들이 조화롭게 CMMI 프로덕트로 통합된 규칙과 개념을 보여준다.

프레임워크는 CMMI 프로덕트로부터 각 조직에 가장 적합한 하나 또는 그 이상의 원칙들을 선정하여 활용할 수 있도록 도움을 줄 것이다.

CMMI 프로덕트는 모델과 진단 방법 그리고 교육훈련 과정에 대해 몇 차례에 걸친 내부 전문가 검토, 외부 일반인 검토 및 파일럿을 수행하였으며 그 결과를 바탕으로 프로덕트에 대한 보완 과정을 거쳐 마침내 2002 년 1 월 11 일, 현재 우리가 사용하고 있는 CMMI-SE/SW 버전 1.1 을 발표하게 되었다. CMMI-SE/SW 모델이 시스템 및 소프트웨어 공학 분야만을 다루는데 비해 통합 제품 및 프로세스 개발 분야까지도 포괄적으로 다루는 CMMI-SE/SW/IPPD 버전 1.1 이 같은 시기에 발표되었으며, 여기에

IT Business Journal


공급업체 소싱분야까지를 포함시킨 CMMI-SE/SW/IPPD/SS 버전 1.1 은 같은 해인 2002 년 3 월 1 일에 발표되었다. 또한 기존의 SW-CMM 을 적용하던 기업이 쉽게 CMMI 로 전환할 수 있도록 소프트웨어 공학 분야만을 다루는 CMMI-SW 버전 1.1 이 2002 년 8 월 19 일에 발표됨으로써 CMMI 모델은 총 4 개의 원칙(Discipline)이 유용하게 되었다.

이러한 원칙들은 각각 단계적(Staged) 접근 방법과 연속적(Continuous) 접근 방법을 취한다. 단계적 접근 방법은 SW-CMM 에서 사용하고 있는 접근 방법이며, 연속적 접근 방법은 성숙도 수준을 정의하는 데 있어 프로세스 별로 정의하는 방법으로 ISO15504 의 능력 성숙도 판정 방법과 유사하다.

CMMI 모델의 출시에 맞추어 미국방성의 정책이 변경되어 2005 년 이후로는 더 이상 CMM 모델에 대한 지원이 이루어 지지 않게 됨에 따라 현재 많은 국내외 기업들이 CMMI 로의 전환이나 도입을 검토하게 되었다. 따라서 지금부터는 CMMI 에 보다 초점을 맞추어 설명을 해 나가고자 한다.

CMMI 의 표현 방법

CMMI 는 총 4 개의 원칙에 각각 단계적 접근 방법과 연속적 접근 방법의 2 가지 접근 방법을 사용할 수 있다고 위에서 언급하였다. 기존의 SW-CMM 이 단계적 접근 방법 한가지만을 사용한 데 반하여 CMMI 가 두 가지 접근 방법을 사용하게 된 데에는 CMMI 개발에 참고가 된 근거 모델인 SW-CMM, SECM, IPD CMM 이 각각 단계적이고 연속적인 접근 방법을 사용하고 있었음에 기인한다. CMMI 프로젝트 팀은 두 가지 접근 방법 중 하나의 접근 방법을 선정하는 데에 있어 결론에 이르지 못하였고 결국 두 가지 접근 방법 모두를 제공하기로 합의하였다. 이러한 접근 방법을 CMMI 모델에서는 단계적 표현(Staged Representation)과 연속적 표현(Continuous Representation)이라고 부른다. 그리고 각 접근 방법을 통해 도출한 결과는 변환표 (Equivalent Staging)를 통해 상호 연계할 수 있도록 하였다.

두 가지 표현 방법에 있어 가장 큰 차이점은 연속적 표현 방법은 개별 프로세스 영역별 평가를 통해 개별 프로세스 영역별 능력을 알 수 있다는 점이며, 단계적 표현 방법은 기 정의된 프로세스 집합의 평가를 통해 조직 전체의 프로세스 능력을 알 수 있다는 점이다.

IT Business Journal


0

1

2

3

4

5

프로세스영역

프로세스영역

프로세스영역

프로세스능력

초기

관리됨

정의됨

정량적으로 관리됨

최적화

1

2

3

4

5

Continuous Continuous 표현표현 방법방법 Staged Staged 표현표현 방법방법VS.

Capability LevelCapability Level Maturity LevelMaturity Level

<그림 2> Continuous와 Staged 표현 방법의 비교

0

1

2

3

4

5

프로세스영역

프로세스영역

프로세스영역

프로세스능력

0

1

2

3

4

5

프로세스영역

프로세스영역

프로세스영역

프로세스능력

초기

관리됨

정의됨


최적화

1

2

3

4

5

초기

관리됨

정의됨


최적화

1

2

3

4

5

Continuous Continuous 표현표현 방법방법 Staged Staged 표현표현 방법방법VS.

Capability LevelCapability Level Maturity LevelMaturity Level

<그림 2> Continuous와 Staged 표현 방법의 비교

즉, 연속적 표현 방법은 기업 경영목표 상 필요한 프로세스 영역의 개선 작업에 중점을 둘 수 있는 유연성을 제공한다는 장점이 있는 반면, 단계적 표현 방법은 프로세스 개선 작업을 수행함에 있어 이를 위한 로드 맵을 제시해 준다는 장점이 있다. 따라서 프로세스 개선 활동을 수행하는 조직에서는 해당 조직의 목표에 맞게 필요한 원칙과 그에 따른 표현 방법을 선정하여 사용할 수 있다. 현재 국내에서는 단계적 표현 방법에 따라 프로세스 개선 활동을 수행하는 경향이 많기 때문에 단계적 표현 방법에 따른 CMMI 의 구성과 구조를 조금 더 상세히 살펴 보도록 하겠다.

단계적 표현 방법에 따른 CMMI 의 구성

CMMI 의 구조를 잘 이해하기 위해서는 프로세스 능력(Capability)과 프로세스 성과 (Performance) 그리고 프로세스 성숙(Maturity)과의 관계를 잘 이해할 필요가 있다.

프로세스 능력(Capability)은 프로세스를 따름으로서 성취되는 기대 결과를 말한다. 따라서 차기 프로젝트의 기대 결과를 예측하는 수단이 된다. 이는 “비용, 일정, 납기, 고객 만족, 생산성 등의 여러 목표를 달성하는 확률”로 쉽게 이해할 수 있다. 능력 수준이 높을수록 비용, 일정, 품질 등의 목표를 쉽게 달성하고 여러 프로젝트들 사이의 목표 달성 결과의 폭도 그만큼 줄어든다.

프로세스 성과(Performance)는 실제로 수행된 결과 값을 의미한다. 이렇게 수집된 자료들을 바탕으로 조직의 능력을 평가한다. 그러나 능력이 반드시 성과로 연결되는 것은 아니다. 바람직한 것은 능력이 성과에 반영 되고, 나아가서는 더 나은 수행 성과가

IT Business Journal


나와서 능력이 향상되는 것이다. 하지만 능력이 있어도 꾸준히 노력하지 않으면, 수행 성과는 능력과는 다르게 나빠질 수도 있다.

프로세스 성숙(Maturity)은 조직의 능력을 성과에 반영시키고, 나아가서는 프로세스 능력을 성장 시킬 수 있는 조직의 잠재력을 의미한다. 조직의 소프트웨어 프로세스가 성숙하게 되면 성능도 향상되고 수행 성과가 좋아지는 방식으로 조직은 발전하게 되는 것이다. 그러므로 조직은 성숙 수준을 높이기 위한 노력을 해야 하는데, CMMI 가 바로 이러한 성숙 수준을 높이기 위한 로드 맵을 제시한다. CMMI 는 소프트웨어 개발 조직의 프로세스가 미성숙한 상태에서 성숙한 상태의 프로세스로 가는 점진적인 개선의 5 가지 단계를 제시하고 점증적으로 발전해 가도록 유도하고 있다. CMMI 를 적용하고자 하는 조직은 먼저 2 단계에서 제시하는 사항들을 충족시키고, 점차적으로 3 단계, 4 단계 그리고 5 단계로 나아가게 된다.

1

2

3

4

5

Process unpredictable, poorly controlled, and reactive

Process characterized for projects and is often reactive

Process characterized for the organization and is proactive

Process measuredand controlled

Focus on processimprovement

Optimizing

QuantitativelyManaged

Defined

Initial

Managed

Optimizing

Defined

<그림 3> 프로세스 성숙도 단계

1

2

3

4

5






Optimizing


Defined

Initial

Managed

Optimizing

Defined

1

2

3

4

5






Optimizing


Defined

Initial

Managed

Optimizing

Defined

<그림 3> 프로세스 성숙도 단계

성숙도 단계별 특징

각 성숙도 단계는 다음과 같은 특징을 갖는다.

Level 1: 초기(Initial)

1 단계는 구조화된 프로세스를 가지고 있지 않다. 개발은 혼돈 속에 임기응변으로 이루어진다. 예산과 일정은 자주 초과된다. 제품에 대한 품질은 예측이 어렵다.

1 단계의 특징인 임기응변이란 우리에게 불필요한 상황이 발생하게 될 때 비로소 그러한 상황을 어떻게 대처할 지에 대해 결정한다는 의미이다. 그래서 이 수준에서는

IT Business Journal


진정한 구조를 가지고 있지 않다. 다시 말해서, 이 수준은 제품을 개발하는 것을 향한 혼돈적인 접근을 나타낸다. 만약 혼란이 구조화 된다면, 그것은 혼돈스럽지 않다. 그래서 1 단계 조직은 구조화된 것이 없으며 이로 인해 1 단계 조직이 된다는 것은 바람직하지 않은 것이다.

Level 2: 관리(Managed)

2 단계에서는 기본적인 프로젝트 관리 프로세스가 비용, 일정, 그리고 기능에 대한 정보를 추적하기 위해 설정된다. 성공적으로 완료된 프로젝트에 활용되었던 유사한 프로세스가 다시 사용됨으로써 내재화(Institutionalization)가 이루어 지기 시작한다.

Level 3: 정의(Defined)

3 단계에서는 소프트웨어 프로세스가 문서화되고, 표준화되고, 조직의 표준 소프트웨어 프로세스와 통합된다. 조직에서 수행되는 모든 프로젝트는 소프트웨어를 개발, 관리하기 위해 조직의 표준 소프트웨어 프로세스를 사용한다. 이때 조직의 표준 프로세스는 프로젝트의 특성에 맞추어 조정하여 적용된다.

3 단계는 제품 개발을 위한 보다 강하고, 의미 있고, 전체 조직적인 접근법을 유지한다. 2 단계와 3 단계의 가장 중요한 차이점은 프로세스들이 3 단계에서는 2 단계에서 보다 더 자세하고 정확하게 묘사된다는 것이다. 혁신적으로 관리된 프로세스들은 상호관계들의 정교한 이해력, 프로세스의 측정들, 그리고 프로세스의 부분들을 기초로 한다. 3 단계는 더욱 정교하고, 더욱 조직적인 인식에서 발전되어왔다.

Level 4: 정량적 관리 (Quantitatively Managed)

4 단계에서는 소프트웨어 프로세스와 생산품의 품질에 대한 상세한 측정이 수집된다. 모든 프로젝트에 대한 중요한 소프트웨어 프로세스 활동의 생산성과 품질이 측정되며, 성과의 변동을 수용 가능한 정량적인 범위 내로 최소화하여 제품과 프로세스에 대한 통제를 수행한다.

4 단계는 제품에 대한 개선이 필요할 지 아닌지에 대한 올바른 의사결정을 위해 측정을 위한 메트릭을 이용하는데 초점을 맞춘다. 3 단계와 4 단계의 차이점은 3 단계에서의 프로세스들은 질적으로 예상 가능한 반면, 4 단계에서의 프로세스들은 정량적으로 예상 가능하다는 것이다. 4 단계는 프로세스 편차의 특정 원인들을 파악하고 이를 통해 시정조치를 취할 수 있는 것을 의미한다.

Level 5: 최적(Optimizing)

5 단계에서는 지속적인 프로세스 개선이 프로세스에 대한 정량적 피드백과 혁신적인 아이디어, 기술의 적용으로 이루어진다. 그리고 발견된 결함의 형태가 다시 발생하지 않도록 소프트웨어 프로세스가 평가되고 얻어진 교훈이 전 조직에 확산된다.

IT Business Journal


5 단계는 해탈(Nirvana)이다. 모든 사람이 팀의 생산적인 팀원이고, 결함은 지속적으로 감소하고 제품은 적시에 그리고 견적된 시간 안에 고객에게 인도된다.

CMMI 의 구조

성숙도 단계별 프로세스 영역(Process Area, PA)

CMMI 는 각각의 성숙도 단계별로 실행 목표들을 제시하고 있는데, 개론적인 수준의 설명부터 구체적인 실무 프랙티스들까지 계층적 구조를 가지고 있다. CMMI 의 계층적 구조의 중심은 프로세스 영역이며, 2 단계에서 5 단계까지 총 25 개의 프로세스 영역으로 구성되어 있다. 프로세스 영역은 각 단계의 달성을 위해 조직과 프로젝트에서 필요한 활동들의 모임을 나타낸다.

Organizational Innovation and DeploymentCausal Analysis and Resolution5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

ContinuousProcess Improvement

QuantitativeManagement

ProcessStandardization

BasicProjectManagement

Organizational Process PerformanceQuantitative Project Management

Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational Training Integrated Project Management for IPPDRisk ManagementIntegrated TeamingIntegrated Supplier ManagementDecision Analysis and ResolutionOrganizational Environment for Integration

Requirements Management Project PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management

1 Initial

Process AreasLevel Focus

<그림 4> 성숙도 단계별 프로세스 영역

Organizational Innovation and DeploymentCausal Analysis and Resolution5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed2 Managed



QuantitativeManagement

ProcessStandardization

BasicProjectManagement

Organizational Process PerformanceQuantitative Project Management

Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational Training Integrated Project Management for IPPDRisk ManagementIntegrated TeamingIntegrated Supplier ManagementDecision Analysis and ResolutionOrganizational Environment for Integration

Requirements Management Project PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management

1 Initial

Process AreasLevel Focus

<그림 4> 성숙도 단계별 프로세스 영역

CMMI 를 적용하려는 조직이 원하는 성숙도 단계를 구현하기 위해서는 각 단계 별로 제시하고 있는 프로세스 영역에 집중해야 할 것이다. 예를 들어, 2 단계의 프로세스 영역 중 하나가 요구사항 관리(Requirements Management) 프로세스 영역인 데, CMMI 2 단계를 준비하는 조직에서는 이 요구사항 관리 프로세스가 CMMI 2 단계를 달성하기 위해 집중해야 하는 영역이 된다.

IT Business Journal


프로세스 영역의 구조

각 성숙도 단계의 프로세스 영역들은 일정한 구조의 형식으로 기술되어 있으며 그 형식들을 도식화 하면 다음과 같다.

Commitmentto Perform

Maturity Levels

GenericPractices

GenericGoals

Process Area 2

Common Features

Process Area 1 Process Area n

Abilityto Perform

DirectingImplementation

VerifyingImplementation

SpecificGoals

SpecificPractices

<그림 5> CMMI 모델 구조

Commitmentto Perform

Maturity Levels

GenericPractices

GenericGoals

Process Area 2

Common Features

Process Area 1 Process Area n

Abilityto Perform

DirectingImplementation

VerifyingImplementation

SpecificGoals

SpecificPractices

<그림 5> CMMI 모델 구조

그림에서 보듯이 모든 프로세스 영역은 다시 특정 목표(Specific Goal)와 범용 목표(Generic Goal)로 구분되고 범용 목표는 공통수행항목(Common Features)으로 구성된다.

목표(Goals)

각각의 프로세스 영역은 해당 프로세스 영역의 목적을 만족시키기 위해 필요한 여러 가지 목표들을 가지고 있으며 이 목표에는 두 가지 형태가 있다.

- 특정 목표(Specific Goals): 특정한 프로세스 영역과 연관된 목표들

- 범용 목표(Generic Goals): 여러 개의 프로세스 영역에서 공통적으로 사용되는 목표들 해당 프로세스 영역이 내재화 되었는지 판단하는 기준이 된다.

프랙티스(Practices)

프랙티스들은 각각의 프로세스 영역들에 대한 목표들을 만족시키기 위해 실행되어야 하는 활동들로써 단 하나의 목표에만 관련이 되어 있다. 프랙티스에는 두 가지 종류가 있다.

- 특정 프랙티스(Specific Practices): 특정 목표와 관련되어 있다.

- 범용 프랙티스(Generic Practices): 내재화를 위한 범용 목표와 관련되어 있다.

예를 들어, 프로젝트 계획 프로세스 영역에서의 프랙티스들 중 하나는 프로젝트

IT Business Journal


계획서를 작성하는 것이며 또 다른 하나는 필요한 인력의 수를 견적하고 일정을 작성하는 것 등이다.

공통수행항목(Common Features)

공통수행항목들은 프랙티스들이 수행되는 기능에 따라서 프로세스 영역 안에서 범용 프랙티스들과 함께 간단히 분류되는 것이다.

- 이행 방침(CO: Commitment to Perform)

- 이행 능력(AB: Ability to Perform)

- 직접 이행(DI: Directing Implementation)

- 이행 검증(VE: Verifying Implementation)

이행 방침은 상위경영층의 의지와 문서화된 정책들을 통하여 보여진다. 이행 능력은 업무에 있어서의 전 직원 교육, 적절한 자원과 자금 공급, 책임 할당, 프로세스 계획, 그리고 테일러링 되고 정의된 프로세스 수립 등을 통해 나타난다. 직접 이행은 형상을 관리하고 관련 이해관계자를 참여시키고, 프로세스를 감시 및 조정하고 개선 정보들을 수집하고 이를 활용하는 것으로써 설명된다. 이행 검증은 객관적인 평가를 엄수(조직 정책, 절차, 그리고 표준에 대한 프로세스와 제품 엄수 모두)하고, 상위 관리자와 함께 상태에 대한 분석을 통해 이루어 진다.

CMMI 의 활용

CMMI 를 어떻게 활용할 것인가에 대해서는 조직마다 방법이 각기 다를 수 있겠으나 일반적으로 프로세스 심사 관점과 개선 관점에서 살펴볼 수 있겠다.

프로세스 심사 관점은 모델을 만족시키기 위해 최소로 필요한 것이 무엇인지에 대한 파악을 통해 심사를 통과하기 위한 활용 방법에 중점을 두게 되는 반면에 프로세스 개선의 관점은 우리 조직에 가장 잘 맞는 것은 무엇이고 조직을 발전시키는 데 필요한 것은 무엇인지에 중점을 둔다.

이 두 개의 관점이 CMMI 의 활용 상태를 어떻게 나타내는지에 대한 예로는 프로세스 영역의 계획, 프로세스, 절차 및 방법들을 조직이 충실하게 따르고 있는지의 여부를 얼마나 객관적으로 평가하는지에 대한 부분에서 알 수 있다.

심사 관점에서 볼 때 조직은 개발자나 엔지니어가 서로의 작업에 대한 검토를 수행하도록 결정할 수 있다. 이 접근법은 개발자나 엔지니어가 검토를 위한 방법에 대해 훈련을 받아야 하고 검토를 수행하기 위해 추가적인 비용과 스케줄이 필요하다는 사실을 우리가 깨닫기 전까지는 독립적인 검증을 할 수 있는 가장 빠른 방법인 것처럼 보인다.

IT Business Journal


심사 관점의 역기능은 심사를 만족시키기 위해서 대단히 큰 프로그램 또는 프로젝트 전체를 검토하는 단 한 사람이 존재한다는 것만으로도 통과할 수 있다는 것이다.

그러나 프로세스 개선 관점에서 볼 때, 조직은 품질 관련 활동들을 정의한 명백한 책임이 필요하다는 것을 인식할 수 있다. 훈련되고 경험이 많은 전문가들로 이루어진 독립적 품질 그룹을 만드는 것은 조직이 구축된 프로세스를 지속적으로 수행하는 것을 보증하기 위해 시간이 많이 필요한 장기적인 방법이 될 것이다. 이 그룹은 충분히 효과적인 수준에 있는 사람들로 구성되어야 할 것이다. 대부분의 경우에 이 그룹은 실무진의 3 ~ 5 퍼센트 이상으로 구성됨을 의미한다.

그 동안 많은 조직들과 일을 해 본 우리의 경험은 단지 심사의 관점에만 중점을 두는 조직은 실패할 것이라는 사실을 말해 준다. 그들은 본질적으로 내재화의 부족 때문에 모델을 진정으로 만족시키지 못한다. 또한 비용 투자에 대한 효과 측면에 있어서도 그들의 조직에게 진정한 비즈니스 가치를 제시하는데도 실패하게 될 것이다.

프로세스 개선의 관점을 가진 조직들은 비즈니스 가치를 제시하는데 성공할 것이며, 또한 심사에 있어서도 좀더 나은 성과를 얻을 것이다. 물론 이러한 접근 방법은 상당한 노력을 요구하지만 진정으로 성공하는 유일한 길인 것이다. 따라서 지금부터는 프로세스 개선의 관점에서 CMMI 를 활용하는 방법을 얘기 하고자 한다.

Level 1 조직에서 Level 2 조직으로의 이동

대부분 조직들이 미성숙한 조직에서 좀더 성숙한 조직으로의 여정을 시작할 때 직면하는 가장 큰 장애물은 성숙도 수준 1 단계에서 성숙도 수준 2 단계로 뛰어넘는 것이다. 성숙도 수준 1 단계는 임기응변의 프로세스로 특징 지워진다. 다시 말해 사람들이 일을 하는 프로세스들은 그들이 그들에게 주어진 업무를 달성하기 위해 그들 자신이 창조해 내는 것이다. 이 방법에서 문제는 반복적인 일이 자주 행해지고, 사람들은 조직차원에서 그들의 방법을 공유하려 하지 않고, 몇몇 접근방식은 조직차원에서 더 효과적으로 운영하게 만드는 것과 실제로는 반대인 것이다. 몇몇 개별적 접근법들이 개인을 위해 존재함으로써 그 개인의 접근법은 실제로 나쁜 방향으로 행해지는 경우가 많고 이로 인해 많은 갈등이 발생한다. 결과는 더 많은 작업 지연, 재 작업 그리고 좌절감이다. 분쟁이 일반적이고 조직은 영웅적인 사람들에 의해 유지된다. 그리고 결국 이런 영웅적인 사람들이 조직을 이탈할 때, 심한 고통을 받게 된다.

성숙도 수준 2 단계는 그들이 얻은 교훈들과 최상의 실행 결과들을 공유하는 것으로써 특징 지워진다. 그리고 프로젝트 수준에서, 어떤 경우에는 조직 전체의 수준에서 예비 프로세스들을 고안하는 것으로 특징 지워진다. 성숙도 수준 2 단계는 일반적이고 매일 매일의 작업 일과에 영향을 주는 관리 이슈들에 중점을 둔다. 성숙도 수준 2 단계는 프로젝트 관리 효율성에 영향을 주는 프로세스 영역들로 구성된다.

IT Business Journal


각각의 프로세스 영역은 그 프로세스 영역에만 해당되는 특정 목표와 성숙도 수준에 있어 모든 프로세스 영역에 적용되는 범용 목표를 가지고 있다. 이들 목표들은 프로세스 영역의 내재화를 이루게 한다. 다시 말해, 조직이 이들 범용 목표들을 조직을 통하여 지속적으로 실행할 때, 이들 목표들과 관련 있는 프로세스 영역들은 이들 영역의 절차서 들을 만든 사람들이 떠난 후에도 조직에서 적절하게 적용하는 데에 아무 어려움이 없도록 해 준다.


성숙도 수준 3 단계는 이제 비즈니스를 수행하는 데에 있어 기존의 프로젝트 관점에서 조직적 관점으로 옮겨졌다는 점에서 2 단계와는 다르다고 할 수 있다. 이것이 의미하는 것은 프로젝트에서 얻은 교훈들과 최상의 수행 결과들은 조직의 인식을 창조하기 위해 조직의 수준으로 부풀려지는 것이다. 각각의 프로젝트에서는 일단위로 수행해야 할 업무들을 위한 일반적이고 공유되는 접근법들이 있다. 예를 들면, 프로젝트의 사이즈 견적은 각 해당 주제의 전문가들이 기본적으로 일련의 최상의 케이스 및 최악의 케이스 평가에 대해서 견적하는 델파이 기법이나 기존의 LOC 방법 대신에 기능점수법 등을 이용하는 표준 메트릭(Metric), 그리고 사이즈를 실제로 계산하는데 이용하는 표준 도구 등을 이용하여 이루어진다.

비즈니스를 수행하는데 있어 조직적 관점은 조직의 표준 프로세스로써 문서화 된다. 그렇다면, 프로젝트는 이러한 표준 프로세스를 프로젝트 목적에 보다 적절하게 맞도록 테일러링하여야 하는가? 그 테일러링 요구는 일반적으로 엔지니어링 프로세스 그룹 (Engineering Process Group, EPG)과 같은 의사결정 조직으로 넘어가게 되는데, 만약 적절하다고 판단이 되면 그 요구는 받아들여질 것이다. 이러한 예로써, 기능 점수 대신 LOC 방법에 의해 사이즈를 계산하는 레가시(Legacy) 시스템을 들 수 있을 것이다. 기능 점수를 계산하기 위한 도구를 이용하기 위해서 시스템에 있는 수백만의 코드 라인들의 크기를 개량화하기 보다는 그리고 그것을 수동으로 하기 보다는, 프로젝트에서는 간단히 LOC 에 의해 사이즈를 계산하는 것이 바람직할 수 있다.

성숙도 수준 3 단계를 달성하기 위해서, 조직은 2 단계와 3 단계 모두에 있는 프로세스 영역들에 대한 모든 목표들에 대해 반드시 만족되어야만 한다. 때때로 예외는 만들어 진다. 예를 들면, 만약 조직이 외부와의 계약 관계가 전혀 없다면, 2 단계의 공급업체 계약관리와 3 단계의 통합된 공급업체 관리 프로세스는 적용되지 않을 수도 있다. 이때에, 이들 프로세스 영역들은 “적용되지 않음(Not Applicable, NA)”로 결정된다. 그러나 주의를 기울어야 한다. 프로세스 영역 전체에 대해 테일러링 하는 것은 일반적으로는 허용되지 않는다. 프랙티스들의 경우, 만약 충분히 대안 프랙티스들에 의해 대처된다면 테일러링이 가능하다. 테일러링은 하면 할수록 개선 활동을 수행하는 데에 어려움이 따르고

IT Business Journal


그럼으로 인해 심사를 통해 성숙도 수준에 도달하는 데에 더욱 힘이 드는 조직이 될 것이다.

성숙도 수준 3 단계에서는 조직이 프로세스를 더욱 더 명확하게 정의할 것을 요구한다. 이 의미는 우리로 하여금 프로세스들을 정의하기 위해서 3 단계까지 기다리라고 하는 것을 말하는 것은 아니다. 프로세스들을 정의 할 때, 조직은 항상 프로세스들을 명확하게 정의하도록 노력해서 비록 2 단계에서라도 프로세스들을 따를 수 있도록 하여야 한다. 프로세스들을 어떻게 수행하는가에 대한 상세 내용은 그들과 관련된 절차서에 있는데, 이러한 절차서의 수준이 프로세스의 수준을 보여준다고 할 수 있다.

CMMI 에서는 프로세스를 정의함에 있어 다음의 속성들이 필요하다고 언급하고 있는 데, 가능한 이러한 요구에 따라 프로세스를 정의하는 것이 바람직하다. 물론, 조직에 따라 프로세스를 기술하는 방법이나 구조는 다를 수 있겠다.

- 목적: 해당 프로세스를 수행하는 목적

- 입력물: 작업산출물, 계획, 검토 및 승인 회람 (일반적으로 명사)

- 입력기준: 해당 프로세스를 시작 하기 전에 어떤 것이 반드시 유발되는가? (일반적으로 이전 프로세스 혹은 이전 단계의 출력기준으로 동사로써 기술된다)

- 활동: 반드시 수행되어야 할 과업. 이들 과업들은 보통 어떻게 과업을 수행해야 할지에 대한 보다 자세한 절차로 세분화 된다.

- 역할: 누가 무엇을 하는가 (일반적으로 지위)

- 측정치: 해당 프로세스를 수행하는데 측정해야 할 항목들은 어떤 것들이 있는가

- 검증단계: 해당 프로세스를 따르고, 올바른 결과를 생산하고 있는지 결정하기 위해 수행되는 검토는 무엇인가 (일반적으로 관리 그리고 품질보증 검토, 그러나 때때로 고객과 동료 그리고 프로젝트 팀 검토를 포함할 수 있다)

- 출력물: 작업산출물, 계획, 승인된 절차 (완성된 입력물이 될 수 있다)

- 출력기준: 해당 프로세스가 완료되는 시점이 언제인지 어떻게 알 수 있는가? (보통 동사로 표현되고 일반적으로 다음 프로세스 단계 또는 다음 프로세스를 위한 입력기준이 된다)

관리되는 프로세스는 프로젝트 관리 노력을 다루는 프로세스이고, 정책에 따라서 계획하고 실행하고, 프로세스 기술서에 대한 표준 준수 여부를 확인하기 위해 감시하고 검토하는 프로세스이다. 이것은 성숙도 수준 2 단계에서 기대되는 프로세스 형태이다. 그러나 성숙도 수준 3 단계에서는 다른 특징들이 프로세스들과 관련하여 만들어 지게 된다. 정의된 프로세스는 특정 프로젝트의 필요에 맞게 테일러링 한 조직적 프로세스를 구현함으로써 관리되는 프로세스를 구축하게 되는 것이고, 조직적 수준의 프로세스와

IT Business Journal


프로젝트 수준의 프로세스 모두 개선시키기 위해 조직에 의해 시행되는 개선 노력들과 관련된 정보를 수집하는 것과도 관련이 있다.


성숙도 수준 4 단계는 숫자들에 관한 모든 것 일 뿐이다. 프로젝트들은 “숫자들에 의해” 관리된다. 조직적 의사결정 또한 “숫자에 의해” 이루어 진다. 프로세스, 서비스, 그리고 제품 품질은 모두 “숫자들에 의해” 측정된다. 4 단계에서의 조직은 2, 3 단계의 목표들을 모두 성취해야 한다. 3 단계에서는 프로세스들이 안정적이라고 하는 것이 정량적으로 예측 가능했다면, 4 단계에서는 프로세스들이 안정적이라고 하는 것이 정량적으로 예측 가능하다는 것을 증명할 수 있어야 한다. 4 단계와 다음 단계인 5 단계 사이의 가장 주요한 차이점은 4 단계는 수집된 데이터를 분석하고, 그리고 정량적인 관리 및 통제를 지원하는 것인데 반해, 5 단계는 편차의 공통원인들을 강조한다는 것이다.

그래서 4 단계를 위해 조직은 안정적이고 지속적인 데이터가 필요하다. 4 단계를 심사할 때, 심사원의 주요 관심사는 다음과 같다. “이 조직의 데이터는 진짜 정확한 것인가?” “이 조직은 올바른 데이터를 모으기 위해 올바른 방법으로 수집하고 있는가?” 좋은 데이터를 얻기 위해, 조직은 보통 여러 해 동안 또는 적어도 여러 제품들과 여러 제품의 생명주기들을 통하여 데이터를 수집해야 한다. 만약 우리가 이제서야 데이터를 수집하기 시작했다면, 이러한 데이터들은 앞으로 지속적으로 사용하게 될 데이터가 아닐 수도 있기 때문이다.

측정 데이터는 2 단계의 시작과 함께 수집되곤 한다. 물론 대부분의 조직들이 1 단계에서도 모으기 시작하지만 문제는 이 때에 모아지는 데이터들은 프로젝트들에서 이용되는 프로세스들이 아직 안정적이고 지속적이지 못하기 때문에, 데이터로써의 가치가 매우 미미하다고 할 수 있다. 데이터는 그 자체가 마술은 아니다. 데이터는 단순히 프로젝트에서 무엇이 진행되는지를 반영한다. 중요한 것은 조직은 하룻밤 사이에 4 단계로 갈수 없고, 이를 위한 초점은 데이터에 있다는 것이다.

조직이 3 단계에서 4 단계로 이동하기로 결심할 때, 조직에서 우리가 볼 수 있는 문제점은 무엇인가? 3 단계에서는 보통 사이즈 및 노력과 관련한 측정치들이 수집되고, 초기 관리 기준(Thresholds)이 구축된다. 만약 이러한 관리 기준이 초과되는 경우가 발생하게 된다면, 어떠한 형태로든 시정조치들이 취해 질 것이다. 4 단계에서는 통제를 위한 관리 기준들이 수년간 축적된 데이터에 기반을 두고 있고, 이들 데이터에 의해 트랜드 분석이 행해진다. 더 많은 데이터가 수집되고, 그러므로 더 많은 관리 기준들이 필요한 만큼 구축되고, 감시되고, 개량될 것이다. 3 단계에서의 데이터는 다소 지속적이지 않고 불필요한 것일 수 있다. 물론 모든 조직이 그러한 것은 아니지만 3 단계에서의 중점사항은 4 단계 기대 수준인 안정적이고 표준화되고 통계학적으로 정확한 데이터에

IT Business Journal


있는 것이 아니라, 조직 프로세스 관점에 있기 때문이다. 3 단계에 대한 기준을 겨우 만족하는 조직들에서 우리가 볼 수 있는 문제점은 프로세스들이 조직을 통하여 지속적으로 수행되지 않는다는 것이다. 이것은 실제로는 이 조직이 3 단계에 도달하지 못했음을 의미한다.

3 단계에서 우리는 조직의 표준 프로세스에 대한 무작위 테일러링으로 인해 결국은 표준 프로세스로부터 많이 왜곡된 프로세스가 사용될 수 있음을 알 수 있고 게다가, 3 단계에서의 측정 문화는 자주 잘 이해가 되지 않는다. 사람들은 왜 그들이 메트릭을 수집하는지 진정으로 이해하지 못한다. 그들은 단지 그들이 모델에 의해 “요구”되기 때문에 수집한다. 메트릭은 일관성과 순수성을 가지고 연구되지 못하거나 왜 숫자들이 불일치성을 띄는지에 대해서도 분석할 수 없고, 잠재적인 문제가 존재하는지 아닌지 알 수도 없다. 숫자들이 너무나 “광활”하기 때문에, 숫자들을 이용하여 만들어지는 경영적 결정은 거리가 아주 먼 것이 될 수 밖에 없다. 그리고 불일치성의 데이터를 기반으로 분석된 결과를 통해 여러 프로젝트들의 성과를 비교하는 것은 더더욱 어려운 일이다.

4 단계에서의 관리자와 데이터 분석가들은 데이터를 반드시 이용하고, 잠재적 문제점들을 인식하고 활동을 감시하기 위한 통계학적이고 정량적인 기술을 적용 시켜야 한다. 4 단계는 프로세스를 안정적이고 예상 가능하게 만드는 것이며 5 단계는 이를 기반으로 조직의 기능을 개선하기 위해 안정적인 프로세스들을 개선하는 것이다. 측정할 수 없는 것은 개선할 수 없기 때문이다.


성숙도 수준 5 단계에서의 조직은 2, 3 그리고 4 단계의 모든 목표들을 성취해야 한다. 5 단계는 편차의 공통원인을 식별하고 이를 통해 프로세스 개선 시범 운영에 의해 조건들의 근본원인을 결정하고 그리고 개선점들과 시정조치를 조직의 표준 프로세스 또는 적절하게 프로젝트의 정의된 프로세스로 통합시켜서, 조직 프로세스의 전반적인 품질을 증진시키는데 집중한다.

성숙도 수준 5 단계에서의 초점은 프로세스들을 개선하는데 있으며 조직의 표준 프로세스는 이를 위해 가장 우선의 초점을 제공하는 통제 문서이다. 조직의 표준 프로세스를 이용하여, 프로세스 개선은 더욱 더 이유 있고 효율적인 관점에서 조직으로 엔지니어링 될 수 있다.

4 단계에서는 조직의 프로세스들에 있어 편차의 특정 원인들에 중점을 두었다면 5 단계에서는 전반적인 개선의 결과를 낳는 공통 원인들을 인식하고 수정하는 노력에 중점을 두게 된다. 측정은 개선사항을 선택하는데 이용되고, 그리고 개선을 시도하기 위해 비용 및 수익을 신뢰성 있게 견적하는데 이용된다. 측정은 개선의 실제 비용과 수익을 증명하기 위해 이용되며 이를 통해 미래의 개선 노력을 정당화할 수 있게 된다.

IT Business Journal


개선 전략에는 혁신적 전략과 점진적인 전략의 두 가지 형태가 있다. 점진적 방법은 초기 개선의 기초를 쌓는 것이고, 혁신적인 방법은 더 근본적이고 과감한 개선의 방법을 시도하는 것이다. 두 가지 방법 모두 조직의 문화와 조직 리더의 정치적이고 카리스마적인 힘에 의존하여 조직에서 적용된다. 그러나, 대부분 조직들은 프로세스를 개선시키기 위해 점진적 접근법이 더 오래 지속적인 효과와 더 빠른 내재화로 이끄는 경향이 있다는 것을 알고 있다. 성숙도 수준 5 단계에서의 중점 사항은 지속적으로 프로세스를 검토하고 개선한다는 것이다. 그러나 이들 개선 사항들은 프로세스 안정성을 관리하고 유지하기 위해서, 반드시 질서 있는 방식으로 활용되어야 한다.

CMMI 도입 효과

CMMI 도입 현황

2004 년 12 월말 기준의 SEI 보고 자료에 의하면 2002 년 CMMI 모델 버전 1.1 이 발표된 이후 지금까지 CMMI 공식 심사는 전 세계 36 개국, 298 개 기업, 567 개 조직, 2339 개의 프로젝트에 대해 총 630 회가 실시 되었다. 공식 심사에 참여한 조직의 규모는 100 명 이하가 38.5%로 가장 많았고, 101~200 명 이하가 17.7%, 201~500 명 이하가 22.3%, 501 명 이상인 조직이 21.5%였다. 공식 심사를 수행하였던 567 개 조직 중 상위 수준의 성숙도인 4 단계와 5 단계를 달성한 조직은 4 단계 4.4%, 5 단계 20.5%로 나타나고 있다.

출처 : Process Maturity Profile, CMU/SEI, 2005년 3월

<그림 6> CMMI Class A 공식 심사 현황 (2004년 12월말 기준)

출처 : Process Maturity Profile, CMU/SEI, 2005년 3월

<그림 6> CMMI Class A 공식 심사 현황 (2004년 12월말 기준)

IT Business Journal


국내의 경우에도 2005 년 9 월말 기준으로 CMMI Level 5 에 도달한 조직이 2 개, Level 4 에 도달한 조직이 2 개, Level 3 에 도달한 조직이 16 개, Level 2 에 도달한 조직이 6 개로 현재 많은 기업에서 CMMI 를 적용하고 있거나 CMMI 도입을 검토 중에 있다.

CMMI 도입 효과

그 동안 많은 국내외 기업들이 CMMI 모델을 기반으로 프로세스 개선 활동을 수행하면서 가시적인 성과가 있었고 이러한 결과들은 종종 언론매체나 외부 컨퍼런스 등을 통해 발표되고 있다. 이 가운데 지난 2003 년 미국 SEI 에서 발표한 스페셜 리포트 (CMU/SEI-2003-SR-009)에 의하면 CMMI 를 초기에 적용한 11 개 조직(Accenture, Boeing

Australia, General Motors, Lockheed Martin, Northrop Grumman, Thales Air Traffic, Thales Training & Simulation, Thales Research & Technology, Bosch Gasoline, JP Morgan Chase & Company, Sanchez Computer Associates)에서 다음과 같은 개선 효과가 나타났음을 알 수 있다.

<표 1> 11 개 선진 조직의 CMMI 도입 효과

구 분 효 과

Cost • 33% decrease in the average cost to fix a defect

• 20% reduction in unit software costs

• 15% decrease in defect find and fix costs

• 4.5% decline in overhead rate

• Improved and stabilized Cost Performance Index

Schedule • Reduced by half the amount of time required to turn around release

• 60% reduction in work and fewer outstanding actions following pre-test and post-

test audits

• Increased the percentage of milestones met from approximately 50% to

approximately 95%

• Decreased the average number of days late from approximately 50 to fewer than 10

• Increased through-put resulting in more releases per year

• 30% increase in software productivity

• Improved and stabilized Schedule Performance Index

• Met every milestone on time, with high quality and customer satisfaction

Quality • Met goal of 20 +/- 5 defects per KLOC

• Only 2% of all defects found in the fielded system

• Reduction in defects found from 6.6 per KLOC to 2.1 over 5 causal analysis cycles

• Increased focus on quality by developers

IT Business Journal


<표 1> 11 개 선진 조직의 CMMI 도입 효과

구 분 효 과

Customer

Satisfaction

• Increased award fees by 55% compared to an earlier SW-CMM baseline at maturity

level 2

• Received more than 98% of possible customer award fees

• Earned a rating of “Exceptional” in every applicable category on their Contractor

Performance Evaluation Survey

Return on

Investment

• 5:1 ROI for quality activities

• 13:1 ROI calculated as defects avoided per hour spent in training and defect

prevention

• Processes for earlier defect detection, improved risk management, and better project

control implemented after showing positive return on investment during pilot

지금까지 국내 많은 기업들이 IT 역량을 강화하기 위해 이미 도입하였거나 도입을 고려하고 있는 CMMI 모델을 올바로 이해하기 위해 CMMI 모델이 만들어지기까지의 배경부터 CMMI 모델의 구성 및 구조 그리고 CMMI 모델을 기반으로 프로세스 개선 활동을 수행할 때에 고려해야 할 사항과 CMMI 모델을 조직에 적용했을 시의 기대 효과를 알아 보았다.

그러나 아무리 CMMI 기반으로 프로세스가 잘 정립되어 있어도 이러한 프로세스를 지속적으로 유지하고 발전해 나가기 위해서는 이를 위한 적절한 조직 구조와 인력의 역량을 꾸준히 강화시켜 나갈 수 있는 교육 프로그램이 필요하다. 또 한편으로는 수작업에서 오는 불편함을 해소하고 보다 효율적으로 프로세스를 이행하기 위한 프로세스의 자동화도 아울러 고려되어야 한다.

따라서 다음 호에서는 IT 프로세스의 효과적 운영을 위한 조직 구조 및 프로세스 자동화 방안에 대해서 알아 보도록 하겠다. <끝>.

IT Business Journal


필자 소개

이민재 티큐엠에스 대표컨설턴트

이민재 티큐엠에스(www.tqms.co.kr) 대표는 볼랜드/테라퀘스트

제휴 컨설턴트로써 미국 로체스터대학교를 졸업하고 뉴욕대학교

정보기술대학원에서 정보기술 감리학을 전공하였다. 현재 SEI 공인

CMMI 및 CMM 선임심사원으로써 국내 다수 기업에 대한 프로세스

개선 컨설팅 및 CMMI 공식 인증 심사를 수행하고 있다.

IT Business Journal

http://www.tqms.co.kr/

IT 조직의 역량 강화를 위한 CMMI 기반의 프로세스 개선 · 2015-07-15 ·...

Documents

Transcript of IT 조직의 역량 강화를 위한 CMMI 기반의 프로세스 개선 · 2015-07-15 ·...