• Capability Maturity Model Integration

• 조직의 개발 능력이 얼마나 성숙했는지를 보기 위한 것 .

• “ 그 회사는 CMMI Level 3 이야” 라고 하면 -> “ 그 회사는 개발 조직이 CMMI 에서 정의한 Level 3

정도의 성숙도이다 .” 라고 이해하면 되겠다 .

능력 성숙

• 조직이 성숙해야 한다고 ? 왠 성숙 ?

• 성숙하지 않은 조직은• 프로젝트의 성공이 특정 개인의 역량에 의존되고 .• 프로젝트 계획 /일정이 고무줄이고 .• 일은 터지고 , 대응은 오로지 야근과 특근 .• 이걸 바꾸면 저게 오동작하고 .• 문서는 그야말로 문서를 위한 문서고 . 매뉴얼은 엉망이

고 .• 맨날 고객에게서 전화 오고 , 전 실무자는 퇴사하고 없고 .• 이전에 진행된 프로젝트에서 건질 것은 커녕 , 정리도

안되어 있고 .

• 당신 같으면 그런 미성숙 조직에 프로젝트 맡기고 싶겠는가 ? 혹은 그런 조직에서 일하고 싶겠는가 ?

• A 회사에서는 영업의 계약에 의해 일정이 박혀서 전달되고 , B 회사에서는 계약 전 당연히 검토되어야만 진행되고 .• 이러한 차이가 단지 프로세스 때문인가 ?• 계약 전 검토를 당연히라고 느껴지는 것이 바로

성숙함이다 .

• CMMI 에서는 성숙도를 판정하기 위하여 당연히 해야 하는 실천항목들을 정의해 놓았다 .

• 그리고 그 실천항목을 가지고 5 개의 Level 로 그룹지었다 .

• 각 Level 별로 실천해야 하는 실천항목이 정해져 있다 .

• 상위 Level 은 하위 Level 의 실천항목을 포함한다 .

• CMMI 의 실천항목들은 전부 무엇 무엇을 하고 있는가 , 라는 것들이다 .

• 살펴보면 세삼스럽지도 않은 어찌 보면 당연한 것들이다 .• 계획 했는가 ? 검토했는가 ? 기록했는가 ? 테스트 했는

가 ? 점검했는가 ?

• 이러한 당연한 것들을 당연히하는 그런 성숙한 조직인지를 보자는 것이고 그것을 판단하기 위해 실천할 사항들을 정리해 놓은 것이다 .

• 계획하고• 검토하고• 기록하고• 측정하고• 점검하고• 개선하라 .

• 언급했듯이 당연한 것을 하자는 것이다 .

• Level 1 : 관리되지 않는 .• Level 2 : 관리되는 (Managed)• Level 3 : 표준화된 프로세스에 의해 (Defined)• Level 4 : 정략적으로 (Quantitively Managed)• Level 5 : 지속적인 프로세스 개선 (Optimized)

• 상위 레벨은 하위레벨을 만족한다 .• 예 : Level3 일 경우 Level2 도 역시 만족한다 .

• PA(Process Area) : 실천 영역• 실제로 취하여야 하는 실천 항목을 영역 별로 구분해 놓았다

• Level 별로 요구하는 실천영역이 있다 .• Level 1 : X• Level 2 : 7 개• Level 3 : 11 개• Level 4 : 2 개• Level 5 : 2 개

• 성숙도 Level 3 일 경우 18 개 (Level2 7 개 +Level3 11 개 ) 의 실천영역에 대한 실천항목을 모두 만족시킨것을 의미한다 .

Level 약어 Process Name 프로세스 명 목적 혹은 의미

Level 2

1. REQM Requirements Management 요구사항 관리 요구사항을 관리하자

2. PP Project Planning 프로젝트 계획 수립 프로젝트 계획을 수립하자 .

3. PMC Project Monitoring and Control 프로젝트 감시 및 통제 프로젝트가 잘되고 있는지 파악하고 조정하자 .

4. SAM Supplier Agreement Management 공급업체 계약 관리 공급업체를 잘 관리하자 .

5. MA Measurement and Analysis 측정 및 분석 모든 활동을 측정하고 분석하자 .

6. PPQA Process and Product Quality Assurance

프로세스 및 제품 품질보증 모든 활동과 프로젝트 산출물을 점검하자 .

7. CM Configuration Management 형상 관리 모든 결과물들을 형상관리하자 .

Level 3

8. RD Requirements Development 요구사항 개발 요구사항을 개발하자 .

9. TS Technical Solution 기술 솔루션 적절한 기술 솔루션을 선택하자 .

10. PI Product Integration 제품 통합 배포를 위해 제품을 제대로 통합하자 .

11. VEL Verification 검증 원 목적대로 제대로 만들었는지 점검하자 .

12. VAL Validation 확인 요구사항이 적절한지 점검하자 .

13. OPF Organizational Process Focus 조직 프로세스 중점 관리 프로세스를 개선하자 .

14. OPD Organizational Process Definition 조직 표준 프로세스 정의 프로세스를 정의하자 .

15. OT Organizational Training 조직 교육 관리 교육시키자 .

16. IPM Integrated Project Management 통합 프로젝트 관리 복수의 프로젝트들을 통합적으로 관리하자 .

17. RSKM Risk Management 위험관리 위험을 관리하자 .

18. DAR Decision Analysis and Resolution 의사결정분석 및 해결 제대로 의사결정을 하자 .

Level 4

19. OPP Organizational Process Performance

20. QPM Quantitative Project Management

Level 521. OID Organization Innovation &

Deployment

22. CAR Causal Analysis and Resolution

• 우와 디따 많다 .• 프로젝트 하려면 그 각 PA 들 전부 해야 되는 건가요 ?• 얘기 들어보니 전부 문서로 만들어야 한다던데 , 으악…

• 제대로 개발을 하려면 필수적인 것이• 하여간에 계획 세우고• 요구사항 파악하고• 요구사항 함부로 변경되지 않게 하고• 필요 기술력 파악하고• 인력 적당한지 봐야 하고• 좀 불안한 사항 있다면 미리 고민해 둬야 하고• 개발하고• 테스트 하고• 개발된 것 잘 보관해야 하고• 배포 전에 통합적으로 테스트 해야 하고

• 한번 솔직해 보자고 . 필수적일 수 밖에 없는 것 중에 코딩 고것밖에 신경 쓰지 않은 거 사실 아닌가 ?• 하여간에 계획 세우고• 요구사항 파악하고• 요구사항 함부로 변경되지 않게 하고• 필요 기술력 파악하고• 인력 적당한지 봐야 하고• 좀 불안한 사항 있다면 미리 고민해 둬야 하고

• 개발하고• 테스트 하고• 개발된 것 잘 보관해야 하고• 배포 전에 통합적으로 테스트 해야 하고

• 그래서 행복해 졌습니까 ? 버그 적어졌습니까 ? 사용자 배포 문서 스스로 맘에 듭니까 ? 야근 좀 줄었습니까 ? 유지보수 할만 합니까 ? 회사 계속 다니고 싶습니까 ?

• 필수적인 것이 어떤 PA 에 해당하나• 하여간에 계획 세우고 : Project Planning• 요구사항 파악하고 : Requirements Development• 요구사항 함부로 변경되지 않게 하고 : Requirements

Management• 필요 기술력 파악하고 : Technical Solution• 인력 적당한지 봐야 하고• 좀 불안한 사항 있다면 미리 고민해 둬야 하고 : Risk Management• 개발하고 : ?????• 테스트 하고 : Verification, Validation• 개발된 것 잘 보관해야 하고 : Configuration Management• 배포 전에 통합적으로 테스트 해야 하고 : Product Integration

• 18 개 중에 9 개가 필수적인 거였네 . 그럼 나머지 9 개는 ?• 개발 자체에 대해선 해당하는 게 없네 . 특이하다 .

• 이외의 PA 를 살펴 봅시다 .• 프로젝트 진행 파악해야 하고 : Project Monitoring and Control• 하청 업체 있으면 관리해야 하고 : Supplier Agreement

Management• 그냥 말이 아닌 수치로 얘기하자고 : Measure and Analysis• 중간 중간 점검은 해야잖아 : Process and Product Quality

Assurance• 이전 프로젝트의 경험을 써먹자 . : Integrated Project

Management• 중요 결정 사항 있으면 주먹구구로는 곤란하지 . : Decision Analysis

and Resolution• 모르는 게 있으면 교육받아야 하고 : Organizational Training• 이외 조직의 프로세스 개선을 위한 것이

• Organizational Process Focus• Organizational Process Definition

• 결국 제대로 개발하기 위해 필수적으로 해야 하는 것을 미루거나 모른척하지 말고 제대로 실천하자는 것이다 .

• 이것이 CMMI Level3 에서 요구하는 것 중 반절이다 .• 나머지 반절은 개발자 보다는 관리자의 입장에서 실천해야 하는

것이라고 볼 수도 있다 .• 프로젝트 진행 파악해야 하고 : Project Monitoring and Control• 하청 업체 있으면 관리해야 하고 : Supplier Agreement Management• 그냥 말이 아닌 수치로 얘기하자고 : Measure and Analysis• 중간 중간 점검은 해야잖아 : Process and Product Quality Assurance• 이전 프로젝트의 경험을 써먹자 . : Integrated Project Management• 중요 결정 사항 있으면 주먹구구로는 곤란하지 . : Decision Analysis and Resolution• 모르는 게 있으면 교육받아야 하고 : Organizational Training• 이외 조직의 프로세스 개선을 위한 것이 …

• 필수라 생각되는 것 9 개와 이외 9 개 .• 모두 18 개 . 그래도 많아 보인다 .• 프로젝트 하려면 꼭 그 18 개 전부 해야 되는 건가요 ?• -> 그렇다 !

• 우린 실상 하긴 하고는 있었다 . 근데 전부 주먹구구식이였고 , 계속 시행착오만 되풀이 하고 있었고 , 개선되지는 않았고 .

• 이제는 쫌 !• 계획 제대로 세우고 ,• 적당한 일정에서 ,• 필요 인력 제대로 투입하고 ,• 요구사항 제대로 파악하고 ,• 뒤엎기 좀 피하고 ,• 테스트 좀 제대로 하고 ,• 문서도 제대로 만들고

• 이외에• 제대로 된 프로세스 안에서 일을 진행하고• 했던 실수 또 하고 또 하고 하지 말고• 지난번 프로젝트에서 배운점 개선하고 , 데이터 활용하고• ‘ 너밖에 할 사람 없잖아’ 요러지 말고

• 어느 실천영역 (PA) 이건 다음을 하는게 맞지 않는가 ?• 실행하기 위한 조직의 방침을 세우고 ,• 계획을 세우고• 자원을 지원하고 ( 툴 , 시스템 , 인력 )• 적절한 담당자를 선임하고• 교육을 시키고• 산출물을 관리하고• 관련자들을 같이 꼬득이고• 때론 점검도 받고• 경영자들과 같이 살펴보자 .

• 그런데 무조건 문서가 있어야 하나요 ?-> 그렇다 .

• 문서의 양이 문제가 아니다 .• 하여간에 무언가를 했다면 그것을 정리된 기록으로 남기는 것이

중요하다 .• 꼭 문서가 아니라 시스템이나 툴을 사용해도 좋다 .• 요구사항관리를 위해 툴을 사용할 수도 있고 , 형상관리를 위해 SVN

을 사용할 수도 있고 .

• 중요한 것은 PA 에서 정의된 실천항목을 실행하는 것이고 , 이를 기록으로 남기라는 것이다 .

• 개발할 것도 태산인데 언제 문서 만들고 있나요 ?• 그런데도 무조건 문서가 있어야 하나요 ?

-> 그렇다 .

• 왜 항상 시간은 없고 할 것은 많은가 ?• 스스로 생각해보라 . 정말 생산적인 코딩을 하는 시간이 얼마나

되는가 ?• 삽질하고 , 뒤집고 , 버그를 다시 만드는 버그 픽스에 , 재미는

없고

• 언제까지 이럴 것인가 ?• 다시 말하지만 문서 자체가 중요한 것이 아니다 . 실천을 하고 기록을

하면 그것이 문서가 되는 것이다 .

• 하지만 더 중요한 것은 CMMI 도 Process 도 시스템도 아니다 .

• 무얼 가져다 놓아도 사람의 마인드가 변하지 않으면 말짱 황이다 .

• 태도가 변하지 않으면 CMMI 도 뭐도 다 짐일 뿐이고 , 더 일만 늘어 난다 .

•제대로 해보려는 마인드가 제일 중요하다 .

• 무엇이건 계획하고 , 기록하고 , 검토하려하는 .• 그리고 개선해 보려는 .

• 하면 좋죠 . 마인드 가지면 좋죠 . 그런데 일 떨어지는 것 보면 .

• 맞는 야그다 . 아무리 개발자가 해볼라 해도 경영진 마인드가 아니면 여전히 삽질일 뿐이다 .

• CMMI 에 의한 프로세스 개선은 경영자의 의지 없이는 불가능하다 . 어떨 지 모르지만 어쨌든 믿어봐야 하지 않겠나 ?

• 계획하라 .• 일정을• 상세한 작업 내용을• 위험요소와 그 대처를• 검토 방법을• 형상관리 방법을• 기술요소를

• 기록하라• 작업한 모든 것을

• 검토하라• 작업된 대상은 검토되어야 한다 .• 문서든 , 코드든 .

• 실제로 프로젝트를 진행할 땐 전사표준 프로세스 (OSSP) 를 가지고 각 프로젝트에 맞게끔 다듬는다 .

• OSSP : Organizational Software Standard Process

• OSSP 에는 표준적인 프로세스와 산출물 예제가 있다 .• 이러한 프로세스를 프로젝트에 맞도록 수정하고 ,• 산출물을 프로젝트에 맞도록 수정한다 .

• 그리고 프로젝트가 종료된 후에 프로젝트 결과물을 가지고 각 조직에 맞도록 다시 OSSP 를 개선해 나간다 .

• 프로세스 개선 !

• 실천항목을 제시하고 , 이의 준수를 요구함을써 개발 프로세스를 개선하려고 한다 .

• 이를 통해 제품 품질을 높이고자 하는 것이다 .

• 단순한 개선된 프로세스의 존재뿐이 아닌 , 그 프로세스가 몸으로 익어진 상태 ( 내재화 ; institutionalization) 을 원한다 .

• 이렇게 내재화가 되어 조직원 전부가 해야할 것을 당연히 여기게 되었을 때 조직이 성숙했다고 한다 .

• EPG : Engineering Process Group• 조직내의 프로세스 개선을 위한 팀

• 경영자의 강한 의지와 실제 개선을 위한 EPG 가 없으면 프로세스 개선은 불가능하다 .

• gap 분석 : 현재의 상태와 goal 과의 차이를 파악한다 .• Readiness Review : 심사준비가 되었는지 파악하고 .• Appraisal : 실제 심사• 모든 실천영역에 대한 실천항목에 대하여 증거의 여부를

파악한다 .• 증거와 더불어 간접증거를 파악하고 인터뷰를 통해 이를

검증한다 .• 증거의 목록을 PIID 라 한다 .

• 모든 영역의 모든 실천항목에 대하여 충분한 실천에 대한 직접증거와 간접증거로 인정되어야만 그 성숙도가 인정된다 .

• 인증이 아니라 rating 이다 .• Carnegie Melon 의 SEI(Software Engineering

Institute) 에서 주관• 국내 현황 : 2007/09 현재 87 개 심사됨• LG CNS, 삼성 SDS 등이 Level 5• 프로젝트 발주 시 가산점을 주기도 한다 .

• CMMI : Capability Maturity Model Integration• SEI : Carnegie Melon 대학의 Software

Engineering Institute• EPG : Engineering Process Group• PIID : Practice Implemented Indicator

Description• PAL : Process Asset Library• OSSP : Organizational Software Standard

Process• WBS : Work Breakdown Structure• PA : Process Area• RR : Readiness Review• Appraisal• SCAMPI : Standard CMMI Appraisal Method for

Process Imporvement

• 본 문서는 CMMI 가 뭔지 감잡기 쉽도록 가이드한 것으로 , 이 문서의 모든 내용은 주관적인 느낌과 판단에 의한 것이며 , 실제와 다를 수 있습니다 . 또한 개인적인 문서로서 특정 업체나 기관과 관계없습니다 . 주의바랍니다 .

• 임도형 , dh-rim@hanmail.net