CMMI의 목표
실제, SI업체나 SW벤더들은 무엇을 목표로해야 하는 것 일까요? 이 글에서는 "소프트웨어의 품위"라고 하는 조금 다른 시점에서 CMMI를 생각해 볼 것입니다.
일부 CMMI를 오해하는 사람들이 있습니다. 그 오해로 인하여, CMMI를 도입하려 하는 (혹은, 도입한) 기업에서는 CMMI를 인증 취득으로만 생각하여 도입 그 자체를 목표로 하고 있기도 합니다. 그러나, CMMI는 기업의 인증 자격이 아닐 뿐더러 도입만으로는 아무런 의미가 없습니다.
본래, CMMI는 조직의 성숙도 달성 상황을 알아보는 것입니다. 달리 말하면, CMMI의 레벨 취득은 해당 조직의 소프트웨어 프로세스 품질을 높이는 통과점입니다. 어디까지나 통과점에 지나지 않으며, CMMI의 최종적인 목표는 소프트웨어 프로세스의 PDCA를 돌리는 것입니다.
한편, CMMI와 같은 소프트웨어 개발 지표에서는, 소프트웨어 프로세스의 품질이 좋다면 제품(산출물)의 품질도 좋다고 합니다. 즉, 아무리 소프트웨어 자체의 품질을 향상하기 위해 노력해도, 소프트웨어 프로세스가 나쁘면 좋은 품질의 제품을 만들어 내는데 한계가 있다는 것입니다.
다시 말하건데, CMMI를 도입함으로써 소프트웨어 프로세스의 품질을 향상시켜 소프트웨어 프로세스의 PDCA 사이클을 유지하는 것이 중요합니다.
그러나, 실제 소프트웨어 개발 현장에서는 소프트웨어 프로세스의 품질이나 소프트웨어 프로세스의 PDCA사이틀을 생각하며 개발을 하고 있을까요? 소프트웨어 개발에 있어서 높은 품질과 고 생산성 짧은 납기라고 하는 캐치프레이즈를 걸고 있지만, 납기 엄수, 목표 품질 지수 달성과 원가 보전을 위한 수단은 생각하지 않고 프로젝트나 소프트웨어 개발을 하고 있지는 않습니까?
그나마, 위의 3가지를 추구하고 있다면 그래도 괞찮은 축에 속합니다만, 납기 엄수나 원가 보전만을 최 우선하여 품질을 소홀히하는 것은 용서받지 못할 잘못을 저지르는 것입니다.
소프트웨어 개발에도 "아름다움"이 필요하고, CMMI는 소프트웨어를 아름답게 꾸미기 위한 안내서 랍니다.
소프트웨어 개발의 품위
그렇다면, 소프트웨어 개발의 "아름다움"이란 무엇일까요? 물론, 기간과 코스트를 무시한 고품질의 제품을 만들어내는 것이나, 관료적인 조직을 만들고 수많은 표준을 도입하여 소프트웨어 개발을 숨도 못쉬게 만들어버리는것도 아닙니다.
기간과 코스트, 품질을 전체적으로 최적화한 조직 표준을 소프트웨어 개발에 자연스럽게 내제화시킴으로써, 한층 원활한 Feed-back과 Feed-forward를 가능하게 하는것이 소프트웨어 개발에서의 "아름다움"이 됩니다.
이러한 "아름다움"은, 개개의 소프트웨어 개발이나 프로젝트 뿐만 아니라, 조직 차원에서의 "아름다움"이 되어야 합니다. 당연히 그 아름다움에는 "품위"가 있어야 하고요.
즉, 소프트웨어 개발에서의 아름다움이란, "소프트웨어 개발의 품위, 프로젝트의 품위, 조직으로서의 품위, 기업으로서의 품위"를 의미한다고 볼수도 있겠습니다. 이런 높은 품위를 갖추기 위해서는 소프트웨어 프로세스의 품위나 프로젝트 매니지먼트의 품위가 중요합니다. 품위라고 하는것은 있다 없다의 기준이 아니라, 서서히 갖추어지는 것입니다.
"지금 어느정도의 품위를 갖추고 있는가?", "앞으로 어떻게 해야지 더 높은 품위를 갖출 수 있을까?", "지금 우리의 품위를 낮추고 있는것은 아닌가?"라는 궁금증을 가지게 된다면, CMMI가 필요한 것입니다. 이것들 때문에 CMMI에서 KPI가 중요하게 됩니다.
*** KPI(Key Performance Indicator): 기업이 기업목표나 비지니스 전략을 위해서 설정한 구체적인 업무 프로세스를 모니터링 하기 위한 상당히 중요한 지표입니다.
소프트웨어 개발은 성숙도를 높임으로써, 소프트웨어 개발 품격을 조직과 기업이 파악하게 하는게 중요합니다. 저는 CMMI를 도입함(본질을 제대로 도입함을 의미...)으로써 소프트웨어 개발이 품위를 가질수 있다고 생각합니다. 그리고 그것이 CMMI의 도입 목표는 아닐까요?
다음 글에서는 CMMI 레벨2의 주요 키워드인 관리(프로젝트관리)에 대해서 생각해 봅시다.@
출처 : Tong - 투명잉크님의 S/W공학통
