팀장님 근데 CMMI 가 뭐에여 ?

1. 팀장님 근데 CMMI가 뭐에여?

2. CMMI • CapabilityMaturity Model Integration • 조직의 개발 능력이 얼마나 성숙했는지를 보기 위한 것. • “그 회사는 CMMI Level 3이야” 라고 하면 • -> “그 회사는 개발 조직이 CMMI에서 정의한 Level 3 정도의 성숙도이다.”라고 이해하면 되겠다. 성숙 능력

3. 성숙? • 조직이 성숙해야 한다고? 왠 성숙? • 성숙하지 않은 조직은 • 프로젝트의 성공이 특정 개인의 역량에 의존되고. • 프로젝트 계획/일정이 고무줄이고. • 일은 터지고, 대응은 오로지 야근과 특근. • 이걸 바꾸면 저게 오동작하고. • 문서는 그야말로 문서를 위한 문서고. 매뉴얼은 엉망이고. • 맨날 고객에게서 전화 오고, 전 실무자는 퇴사하고 없고. • 이전에 진행된 프로젝트에서 건질 것은 커녕, 정리도 안되어 있고.

4. 성숙? • 당신 같으면 그런 미성숙 조직에 프로젝트 맡기고 싶겠는가? 혹은 그런 조직에서 일하고 싶겠는가? • A 회사에서는 영업의 계약에 의해 일정이 박혀서 전달되고, B 회사에서는 계약 전 당연히 검토되어야만 진행되고. • 이러한 차이가 단지 프로세스 때문인가? • 계약 전 검토를 당연히라고 느껴지는 것이 바로 성숙함이다.

5. CMMI에서의 성숙 • CMMI에서는 성숙도를 판정하기 위하여 당연히 해야 하는 실천항목들을 정의해 놓았다. • 그리고 그 실천항목을 가지고 5개의 Level로 그룹지었다. • 각 Level 별로 실천해야 하는 실천항목이 정해져 있다. • 상위 Level은 하위 Level의 실천항목을 포함한다.

6. CMMI의 실천항목 • CMMI의 실천항목들은 전부 무엇 무엇을 하고 있는가, 라는 것들이다. • 살펴보면세삼스럽지도 않은 어찌 보면 당연한 것들이다. • 계획 했는가? 검토했는가? 기록했는가? 테스트 했는가? 점검했는가? • 이러한 당연한 것들을 당연히하는 그런 성숙한 조직인지를 보자는 것이고 그것을 판단하기 위해 실천할 사항들을 정리해 놓은 것이다.

7. CMMI에서 바라는 성숙은? • 계획하고 • 검토하고 • 기록하고 • 측정하고 • 점검하고 • 개선하라. • 언급했듯이 당연한 것을 하자는 것이다.

8. Level 별 의미 • Level 1 : 관리되지 않는. • Level 2 : 관리되는(Managed) • Level 3 : 표준화된 프로세스에 의해(Defined) • Level 4 : 정략적으로(Quantitively Managed) • Level 5 : 지속적인 프로세스 개선(Optimized) • 상위 레벨은 하위레벨을 만족한다. • 예 : Level3일 경우 Level2도 역시 만족한다.

9. PA • PA(Practice Area) : 실천 영역 • 실제로 취하여야 하는 실천 항목을 영역 별로 구분해 놓았다 • Level 별로 요구하는 실천영역이 있다. • Level 1 : X • Level 2 : 7개 • Level 3 : 11개 • Level 4 : 2개 • Level 5 : 2개 • 성숙도 Level 3일 경우 18개(Level2 7개+Level3 11개)의 실천영역에 대한 실천항목을 모두 만족시킨것을 의미한다.

10. PA 리스트

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

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

13. 근데 우리는 • 한번 솔직해 보자고. 필수적일 수 밖에 없는 것 중에 코딩 고것밖에 신경 쓰지 않은 거 사실 아닌가? • 하여간에 계획 세우고 • 요구사항 파악하고 • 요구사항 함부로 변경되지 않게 하고 • 필요 기술력 파악하고 • 인력 적당한지 봐야 하고 • 좀 불안한 사항 있다면 미리 고민해 둬야 하고 • 개발하고 • 테스트 하고 • 개발된 것 잘 보관해야 하고 • 배포 전에 통합적으로 테스트 해야 하고 • 그래서 행복해 졌습니까? 버그 적어졌습니까? 사용자 배포 문서 스스로 맘에 듭니까? 야근 좀 줄었습니까? 유지보수 할만 합니까? 회사 계속 다니고 싶습니까?

14. 필수적인 것 하고 PA관계는? • 필수적인 것이 어떤 PA에 해당하나 • 하여간에 계획 세우고 : Project Planning • 요구사항 파악하고 : Requirements Development • 요구사항 함부로 변경되지 않게 하고 : Requirements Management • 필요 기술력 파악하고 : Technical Solution • 인력 적당한지 봐야 하고 • 좀 불안한 사항 있다면 미리 고민해 둬야 하고 : Risk Management • 개발하고 : ????? • 테스트 하고 : Verification, Validation • 개발된 것 잘 보관해야 하고 : Configuration Management • 배포 전에 통합적으로 테스트 해야 하고 : Product Integration • 18개 중에 9개가 필수적인 거였네. 그럼 나머지 9개는? • 개발 자체에 대해선 해당하는 게 없네. 특이하다.

15. 이외에 다른 PA는 뭔가요? • 이외의 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

16. PA는 많아도 • 결국 제대로 개발하기 위해 필수적으로 해야 하는 것을 미루거나 모른척하지 말고 제대로 실천하자는 것이다. • 이것이 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 • 이외 조직의 프로세스 개선을 위한 것이 …

17. 그래도 많아 보이는 PA • 필수라 생각되는 것 9개와 이외 9개. • 모두 18개. 그래도 많아 보인다. • 프로젝트 하려면 꼭 그 18개 전부 해야 되는 건가요? • -> 그렇다 ! • 우린 실상 하긴 하고는 있었다. 근데 전부 주먹구구식이였고, 계속 시행착오만 되풀이 하고 있었고, 개선되지는 않았고.

18. 꼭 다해야 하는가? • 이제는 쫌! • 계획 제대로 세우고, • 적당한 일정에서, • 필요 인력 제대로 투입하고, • 요구사항 제대로 파악하고, • 뒤엎기 좀 피하고, • 테스트 좀 제대로 하고, • 문서도 제대로 만들고 • 이외에 • 제대로 된 프로세스 안에서 일을 진행하고 • 했던 실수 또 하고 또 하고 하지 말고 • 지난번 프로젝트에서 배운점 개선하고, 데이터 활용하고 • ‘너밖에 할 사람 없잖아’ 요러지 말고

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

20. CMMI와 문서 • 그런데 무조건 문서가 있어야 하나요? • -> 그렇다. • 문서의 양이 문제가 아니다. • 하여간에 무언가를 했다면 그것을 정리된 기록으로 남기는 것이 중요하다. • 꼭 문서가 아니라 시스템이나 툴을 사용해도 좋다. • 요구사항관리를 위해 툴을 사용할 수도 있고, 형상관리를 위해 SVN을 사용할 수도 있고. • 중요한 것은 PA에서 정의된 실천항목을 실행하는 것이고, 이를 기록으로 남기라는 것이다.

21. 그 수많은 문서 만들다 보면, 개발은? • 개발할 것도 태산인데 언제 문서 만들고 있나요? • 그런데도 무조건 문서가 있어야 하나요? • -> 그렇다. • 왜 항상 시간은 없고 할 것은 많은가? • 스스로 생각해보라. 정말 생산적인 코딩을 하는 시간이 얼마나 되는가? • 삽질하고, 뒤집고, 버그를 다시 만드는 버그 픽스에, 재미는 없고 • 언제까지 이럴 것인가? • 다시 말하지만 문서 자체가 중요한 것이 아니다. 실천을 하고 기록을 하면 그것이 문서가 되는 것이다.

22. 더 중요한 마인드 • 하지만 더 중요한 것은 CMMI도 Process도 시스템도 아니다. • 무얼 가져다 놓아도 사람의 마인드가 변하지 않으면 말짱 황이다. • 태도가 변하지 않으면 CMMI도 뭐도 다 짐일 뿐이고, 더 일만 늘어 난다. • 제대로 해보려는 마인드가 제일 중요하다.

23. 어떤 마인드? • 무엇이건 계획하고, 기록하고, 검토하려하는. • 그리고 개선해 보려는.

24. 그런 마인드가져 봤자 • 하면 좋죠. 마인드 가지면 좋죠. 그런데 일 떨어지는 것 보면. • 맞는 야그다. 아무리 개발자가 해볼라 해도 경영진 마인드가 아니면 여전히 삽질일 뿐이다. • CMMI에 의한 프로세스 개선은 경영자의 의지 없이는 불가능하다. 어떨 지 모르지만 어쨌든 믿어봐야 하지 않겠나?

25. 구체적으로 무얼 해야 하나요? • 계획하라. • 일정을 • 상세한 작업 내용을 • 위험요소와 그 대처를 • 검토 방법을 • 형상관리 방법을 • 기술요소를 • 기록하라 • 작업한 모든 것을 • 검토하라 • 작업된 대상은 검토되어야 한다. • 문서든, 코드든.

26. 실제 적용 • 실제로 프로젝트를 진행할 땐 전사표준 프로세스(OSSP)를 가지고 각 프로젝트에 맞게끔 다듬는다. • OSSP : Organizational Software Standard Process • OSSP에는 표준적인 프로세스와 산출물 예제가 있다. • 이러한 프로세스를 프로젝트에 맞도록 수정하고, • 산출물을 프로젝트에 맞도록 수정한다. • 그리고 프로젝트가 종료된 후에 프로젝트 결과물을 가지고 각 조직에 맞도록 다시 OSSP를 개선해 나간다.

27. CMMI의 목적 • 프로세스 개선! • 실천항목을 제시하고, 이의 준수를 요구함을써 개발 프로세스를 개선하려고 한다. • 이를 통해 제품 품질을 높이고자 하는 것이다. • 단순한 개선된 프로세스의 존재뿐이 아닌, 그 프로세스가 몸으로 익어진 상태(내재화; institutionalization)을 원한다. • 이렇게 내재화가 되어 조직원 전부가 해야할 것을 당연히 여기게 되었을 때 조직이 성숙했다고 한다.

28. EPG • EPG : Engineering Process Group • 조직내의 프로세스 개선을 위한 팀 • 경영자의 강한 의지와 실제 개선을 위한 EPG가 없으면 프로세스 개선은 불가능하다.

29. CMMI 심사 방법 • gap 분석 : 현재의 상태와 goal과의 차이를 파악한다. • Readiness Review : 심사준비가 되었는지 파악하고. • Appraisal : 실제 심사 • 모든 실천영역에 대한 실천항목에 대하여 증거의 여부를 파악한다. • 증거와 더불어 간접증거를 파악하고 인터뷰를 통해 이를 검증한다. • 증거의 목록을 PIID라 한다. • 모든 영역의 모든 실천항목에 대하여 충분한 실천에 대한 직접증거와 간접증거로 인정되어야만 그 성숙도가 인정된다.

30. 기타 CMMI 관련 이런 저런 사실들 • 인증이 아니라 rating이다. • Carnegie Melon의 SEI(Software Engineering Institute)에서 주관 • 국내 현황 : 2007/09 현재 87개 심사됨 • LG CNS, 삼성 SDS 등이 Level 5 • 프로젝트 발주 시 가산점을 주기도 한다.

31. CMMI 용어들 • 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 : Practice Area • RR : Readiness Review • Appraisal • SCAMPI : Standard CMMI Appraisal Method for Process Imporvement

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