logo

English

이곳의 프로그래밍관련 정보와 소스는 마음대로 활용하셔도 좋습니다. 다만 쓰시기 전에 통보 정도는 해주시는 것이 예의 일것 같습니다. 질문이나 오류 수정은 siseong@gmail.com 으로 주세요. 감사합니다.

프로세스 능력 성숙도 모델(CMMI)의 적용

by digipine posted Oct 28, 2017
?

Shortcut

PrevPrev Article

NextNext Article

Larger Font Smaller Font Up Down Go comment Print
?

Shortcut

PrevPrev Article

NextNext Article

Larger Font Smaller Font Up Down Go comment Print
미국방성(DoD)의 자금 지원를 받아 프로세스 능력 성숙도 모델을 개발하고 있는 카네기멜론대학(Carnegie Mellon University) SEI(Software Engineering Institute)에서는 1993 SW-CMM(Capability Maturity Model for Software) Version 1.1 모델과 1994 SE-CMM(Systems Engineering Capability Maturity Model) Version 1.0을 개발하여 공표한 데 이어, 2002년도에는 CMMI(Capability Maturity Model Integration) Version 1.1 모델을 개발하여 공표하였다또한, CMMI Version 1.1 모델의 발간과 함께, 2003년도 말을 기준으로 하여 기존 SW-CMM 모델의 공식적인 폐기를 선언하였다기존의 소프트웨어공학과 시스템 공학분야로 양분된 모델을 CMMI 모델로 통합한 것이다이에 본 고에서는 CMMI 모델의 개요에 대하여 알아보고관련 표준 동향을 기초로 하여 관련 국제표준 및 모델과의 관계 및 그 적용 방안에 대하여 소개하기로 한다

 

I. 서 론

CMMI(Capability Maturity Model Integration) 프로젝트는 미국방성(Dapartment of Defense) 자금을 받은 NDIA(National Defense Industrial Asso-ciation)의 시스템공학위원회의 산학협력 프로젝트로 시작되었다이 프로젝트의 목적은 조직의 사업 전반에 걸쳐서 개발 프로세스를 개선하고자 하는 조직에 초점을 맞추어소프트웨어공학과 시스템공학으로 양분된 프로세스 모델을 하나로 통합하여 개발하는 것이었다통합된 CMMI 모델을 사용함으로써 프로세스 모델을 적용하고자 하는 조직은 여러 모델을 사용하는데 따르는 중복 비용을 절감하고사업 전반에 걸친 프로세스교육 및 평가와 관련하여 일정 효과를 얻을 수 있게 되었다또한CMMI 프로젝트의 결과로, Staged 혹은 Continuous 모델에도 같이 적용할 수 있는 융튱성 있는 통합 모델이 개발되었다[5].

본 고에서는 카네기멜론대학의 SEI에서 현재 진행 중인 CMMI 프로젝트의 개요와 그 적용방안에 대하여 알아보고최근 동향에 대해서도 소개하기로 한다.

II. CMMI의 개요

1. 개요 [1]

1997미국방성의 OSD(Office of the Under Secretary of Defense) NDIA와 함께 SEI SW-CMM을 계속 발전시키기 위한 프로세스 개선 모델의 통합을 위한 CMMI 프로젝트를 시작하였다. 1989년에 시작된 SW-CMM은 공군에서 경쟁력 있는 소프트웨어 개발업체를 선정하기 위하여 그 조직의 소프트웨어 개발 프로세스를 평가해 보고자 시작되었다그후 1993년에 SW-CMM V1.1[2]이 개발되어 공표되었고계속해서 V2.0이 개발되었으나 공표되지는 않았다. CMMI 프로젝트는 상호 다른 여러 가지 모델을 적용함에 따라 소요되는 비용과 노력을 절감하고엔지니어링 프로세스 개선을 위한 공용성을 극대화하여 통합된 모델을 개발하기 위하여 시작되었다[4].

1998년에 CMMI 프로젝트 추진 조직이 결성되었고아래 세 가지의 소스 모델을 통합하는 것으로 시작되었다[3].

- SEI Capability Maturity Model for Software(SW-CMM)

- Electronic Industries Alliance Systems Engineering Capability Model, Interim Standard (EIA/IS 731): EPIC(Enterprise Process Improvement Collaboration)에 의해 만들어진 Systems Engineering CMM(SE-CMM) INCOSE에 의해 만들어진 Systems Engineering Capability Assessment Model(SECAM)을 통합한 모델

IPD-CMM: 미국방성(DoD)과 산업계에 의해 Integrated Product and Process Develop-ment(IPPD) 환경에 초점이 맞추어진 프로세스 성숙도 모델(EPIC에 의해 draft 형태로 공표됨.)

초창기의 의도는 시스템공학(CMMI-SE)과 소프트웨어공학(CMMI-SW)에 따라 두 가지로 분리된 모델을 생각하였으나여러 토론을 거쳐서 EIA/IS 731.1로부터Continuous representation을 유지하고, SW-CMM에서 익숙한 Staged representation으로 두 가지의 representation을 유지하면서 프로세스 모델은 하나로 통합하는 것으로 최종적으로 결정되었다따라서어떤 representation이 좋은지가 중요한 것이 아니라적용하려는 조직의 요구에 어느representation이 가장 적합한지를 결정하여 적용하는 것이 중요하다 할 수 있다(representations에 대해서는 아래의 2항에서 설명하기로 한다)[4].

2. 모델의 구조[1],[6]

CMMI 모델은 각각의 Process Areas(PAs)내에서 specific goals generic goals의 달성정도를 측정함으로써 개선의 수준(정도)을 나타낼 수 있게 설계되었다. CMMI-SE/SW/IPPD 모델에는 Requirement Development, Validation, Configuration Management, Project Planning 등을 포함하여 총 24개의 PAs로 구성되어 있다.

CMMI 모델은 해당 프로세스가 조직 혹은 프로젝트에 적합한지를 판단할 수는 없다반면에프로세스가 만족해야 하는 최소한의 기준을 제시함으로써모델이 조직의 규모와 사업 목적에 따라서 적절하게 조정되어(tailored) 구현될 수 있게 할 뿐이다.

. Representations

CMMI 모델은 두 가지의 representations을 제공한다이 두 가지의 representations은 사용자 즉조직이 프로세스 개선을 위한 접근 편리성에 따라 선택할 수 있는 각각의 접근 방법을 제공한다. Representations은 겉으로는 다르게 구성되어 있지만본질적으로는 동일한 내용을 담고 있다.

Continuous representation은 프로세스 능력(capability)-프로세스가 성취할 수 있는 예상 결과들의 범위-에 초점이 맞추어져 있다낮은 능력을 가진 프로세스는 즉흥적으로 실행되며 현재의 프로세스 실행자에 너무 의존적이고결과를 예상하기 어려우며 산출물의 품질보다는 프로젝트 일정을 맞추는 데 급급한 모습을 보인다반면에높은 능력을 가진 프로세스는 잘 정의되며 관리되고측정에 의하여 지속적으로 개선되며 해당 분야 기술이 잘 발휘될 수 있는 밑거름이 된다.

Continuous representation은 각 프로세스의 개선 정도에 대한 정보를 제공할 뿐만 아니라지속적인 개선을 위하여 필요한 프로세스를 선택할 수 있도록 조직에게 융통성을 제공한다프로세스의 능력 수준(capability level)은 총 6단계-(0) Incomplete, (1) Performed, (2) Managed, (3) Defined, (4) Quantitatively Managed (5) Optimizing-로 측정된다능력 수준은 각 PA에 제시되어 있는 specific goals generic goals의 달성 정도에 따라 결정된다예를 들어해당 PA specific goals generic goals가 능력 수준 2까지 달성되면그 조직의 해당 PA는 능력 수준 2에 이르게 된다.

Continuous representation은 조직의 사업 목적과 효과적인 위험관리를 위한 적용 프로세스와 개선의 순서를 조직이 스스로 정할 수 있게 되어 있다. Continuous representation EIA/ IS 731.1에서 적용한 representation으로, EIA/IS 731.1에 의하여 프로세스 모델을 구현한 조직에서 선호하는 접근 방법이다.

Staged representation은 조직 전체의 성숙도(organizational maturity)-수준별 관련 프로세스 집합의 전체 능력-에 초점이 맞추어져 있다그리하여높은 성숙도를 가진 조직은 조직이 가지고 있는 프로세스 집합의 능력이 낮은 성숙도를 가진 조직보다 더 높다는 것을 의미한다조직의 성숙도 수준(maturity level)은 총 5단계-(1) Initial, (2) Managed, (3) Defined, (4) Quantitatively Managed, (5) Optimizing-로 측정된다성숙도 수준은 성숙도가 높은 조직으로 가기 위한 과정상에 있는 잘 정의된 중간 단계로 볼 수 있다.

Staged representation은 기초적인 수준의 basic management practices부터 시작해서 정해진 경로(path) 및 순서에 따라 계속 발전해 나가면서 프로세스 개선을 추진하는 접근 방법을 사용하고 있다동일한 성숙도 수준을 적용하고 있는 SW-CMM으로부터 별도의 추가적인 조치가 없이 바로CMMI로 전환하는 것도 가능하다.

Staged representation에서 generic practices common features로 분류되어 각각의 내용에 포함되어 있다. Common features중에서 Commitment to Perform은 경영방침(management policy)을 개발하고 그에 대한 지원(sponsorship)을 확보하는 practices로 구성되어 있고Ability to Perform은 계획자원,책임과 권한교육 등을 개발하고 실행해 나가는practices로 특성화되어 있다Directing Implementation은 측정하고 관리하는 성과 관련practices로 구성되어 있고Verifying Implementation은 실행(implementation) 및 그 적합성에 관련된 practices로 이루어져 있다.

. Integration

기존의 프로세스 개선 모델과 CMMI 모델과의 가장 큰 차이는 프로세스 개선에 대한 여러 분야의 관점을 하나로 통합했다는 것이다. CMMI-SE/SW모델은 시스템공학과 소프트웨어공학 분야에 공통된 PAs을 통합하였다. CMMI-SE/SW/IPPD 모델은 Integrated Product and Process Development 환경에 필요한 몇가지practices를 추가하였다. CMMI-SE/SW/IPPD 모델은 일부 내용상 약간의 개정과 두 가지 PAs만을 추가한 점이 CMMI-SE/SW 모델과 다른 점이다. 2002년에 정식으로 공표된 CMMI-SE/SW/IPPD/SS 모델은 CMMI-SE/SW/IPPD 모델에서 아웃소싱과 관련된 practices가 더하여졌다그리하여기본 모델에서 일부 최소한의 추가만으로 여러 분야에 적용가능한 모델을 개발하였다.

3. Process Areas[1],[6],[7]

 (그림 1)은 조직이 사업을 수행하기 위하여 사용하는 다양한 프로세스들 간의 통합성을 표현하고다양한 CMMI process areas 간의 관계를 보여주고 있다.

 

. Process Management Process Areas

프로세스 개선 프로그램을 성공적으로 실행하기 위하여 필요한 모든 practices을 포함하고 있으며우수 사례프로세스 자산 및 교훈 등을 공유하고 문서화하는 능력을 제공한다또한품질과 프로세스 성과를 정량적인 목표로 세우기 위한 좀 더 진보된 능력도 제공한다.

. Project Management Process Areas

프로젝트를 계획하고 모니터링 및 통제하기 위한 프로세스 관리 활동들을 담고 있으며공급자 혹은 고객과의 공약(commitment)을 체결유지 및 모니터링하는 메커니즘을 제공한다또한협력적인 팀제 환경을 마련하고 유지하는 메커니즘과 프로젝트를 역동적이고 정량적으로 관리하는 공통된 방법을 제공한다.

. Engineering Process Areas

초기 요구사항 개발에서부터 사용자 환경에서의 결과물 인도에 이르기까지 제품 개발 생명주기 활동들을 지원한다.

. Support Process Areas

제품 개발과 유지보수를 지원하기 위해 필요한 프로세스들을 제공하고통합을 원활하게 하기 위한 작업환경의 개발과 유지보수를 지원한다.

. Custom Process Areas

사업환경에 따라, information insurance, enterprise integration, safety등의 특성화된 process area가 필요할 수 있다.

4. 모델의 평가[4]

일반적으로CMMI 모델을 이용한 프로세스 개선 프로그램을 실행하려고 하는 조직은 조직내 개선이 필요한 부분을 식별하고 조직내 프로세스가 모델에 합당한지를 알아보기 위하여 자체 진단 심사(diagnostic assessment)를 실시한다. CMMI Product Suite의 한 요소인 Appraisal Require-ments for CMMI(ARC) CMMI 모델을 이용한 평가 방법을 적용하고자 할 때 고려해야 할 요구사항을 정의한 것이다이러한 요구사항은 자체적인 진단 평가 방법을 개발하려고 하는 조직에서 지침으로 사용될 수 있다평가 방법에 대한 또 하나의 대안으로, Standard CMMI Appraisal Method for Process Improvement(SCAMPI)를 사용할 수 있다. SCAMPICMMI process area의 능력과 성숙도 수준을 측정할 수 있도록 표준화된 툴이다. CMMI V1.1 Product Suite에서 중요 추가 사항 중의 하나는 프로세스 개선을 위한 내부 평가뿐만 아니라 외부 평가를 위한 통일된 방법이다. SCAMPI는 외부 평가뿐만 아니라 내부 평가에도 모두 적용할 수 있는 평가 방법이다.

III. CMMI의 적용

1. 초기 Pilot testing 결과[4]

CMMI의 초기 pilot test 목적은 모델교육평가 방법 등을 이용하여 경험을 얻고 그 경험을 CMMI products에 피드백하여 개선시키고자 하는데 있었다. 1999년에 CMMI V0.2 draft 모델이 최초로 개발되고 나서, CMMI Phase I Pilot Program이 실시되었다여기에 7개의 조직이 참여를 신청하여, 1999 12월부터 2000 6월까지 실시되었다그 후에 발간된 V1.0에 대해서도 2000 10월에 Phase II Pilot Program 8개의 조직을 대상으로 하여 실시되었다두번에 걸친 pilot program에서 평가 방법으로는 SCAMPI 모델이 사용되었으며, 18PAs를 가진 CMMI-SE/SW 모델을 이용한 성숙도 수준 3에 대한 평가를 시행하였다특히, Pilot II 에서는 PA당 평균 5간의 인터뷰가 실시되었으며이 때 이루어진 결과는 SCAMPI V1.1에 반영되어 개선되었다Pilot program에 참가한 조직은 Boeing사를 비롯하여 BAE SYSTEMS, Goddard Space Flight Center NASA, Lockheed Martin, Motorola Inc., Northrop Grumman Information Technilogy Sector, Raython Company, THALES, United Space Alliance, U.S. Army TACOM-ARDEC Software Enterprise 등이 참여하였다.

Pilot Program을 통해 얻어진 경험들은 여러 논문이나 학회(Software Engineering Process Group Conference, DoD Software Technology Conference, SEI Symposium )를 통하여 발표되었다여기에 5가지 key lessons learned를 요약하면 다음과 같다.

검증된 technology transition approaches CMMI에 적용된다계획을 포함한 검증된 transition approaches가 적용되며그러한 approaches는 성공 확률을 높이는 데 필요하다.

한 분야에 국한된 모델을 적용할 때보다 CMMI를 적용할 때 더 광범위한 지원이 필요하다조직 구조에 따라 다르지만일반적으로 higher management or executive level, additional peer management sponsors, greater subset of the overall enterprise를 필요로 한다.

한 분야에 국한된 모델보다는 CMMI 모델을 사용하는 것이 프로세스 산출물에 미치는 영향이 더 크다예를 들면여러 분야로의 확장으로 인해 존재하는 프로세스 자산에 대한 재사용의 기회가 확대된다.

통합된 기반구조(integrated infrastructure) CMMI 모델을 적용하는 데 결정적인 역할을 한다. Process group, management steering group, process asset library(PAL) 등을 포함하는 기반구조를 필요로 한다.

- CMMI-SE, CMMI-SW, CMM-SE/SW 모델에 동일한 PAs, goals, practices가 존재하기 때문에 모델 범위를 여러 분야로 확장하는 것이 용이하다예를 들면, CMMI-SW 모델로부터 CMMI-SE/SW 혹은 CMMI-SE/SW/IPPD 모델로의 확장이 용이하다는 것이다.

2. CMMI 적용시 고려 사항[4]

CMMI를 적용하고자 결정하려는 조직이 고려해야 할 사항으로는 다음과 같은 세 가지를 들 수 있다.

- Stability: 안정성은 적용을 고려하는 조직에게는 매우 중요한 사항으로 상대적으로 변화가 적은 안정적인 모델을 고려하게 된다. CMMI V1.0에서 실시된 pilot test에 의하여 한번 정화하고 에러를 수정하는 과정을 거쳐서 V1.1이 공식적으로 발간되었기 때문에 안정성에 대한 신뢰할 만하다.

- Usability: 적용 모델을 고려할 때 사용 편리성 또한 매우 중요한 요소이다. CMMI는 여러 상이한 환경에서 사용하는 공통된 용어와 단계를 적용하려고 노력하였으며프로세스 개선 그룹과 평가팀의 입장에서 개선과 그에 대한 검증을 명확하게 할 수 있도록 많은 시간을 투자하였다.

- Extensibility: 확장성 또한 중요한 고려 사항이다. CMMI V1.0이후에 계속적인 확장을 통하여 V1.1을 발간하였다. Integrated Product and Process Development 환경을 위하여 몇가지 goals Pas를 추가하였고, Supplier Sourcing 환경을 위한 PAs도 추가하였다그리하여모델간의 공통성(Commonality)을 극대화하였으며새로운 분야와의 통합을 위한 모델 확장을 최소화였다.

3. CMMI 적용을 위한 접근 방법 [7]

조직에서 CMMI를 기반으로 변화를 추구하고자 할 때 적용할 수 있도록, SEI에서 제공하고 있는 일반적인 접근 방법은 SEI 홈페이지(www.sei.cmu.edu/ideal/ideal.html)에서 쉽게 찾을 수 있다. SEI에서 제시한 IDEAL 모델은 개선 조치를 시작하고계획하며실행하기 위한 접근 방법을 제공한다. IDEAL 모델에서 정의하는 5단계는 Initiating, Diagnosing, Establishing, Acting, Learning 등이다.

 

IDEAL과 유사하지만, CMMI를 실행하는 다른 접근 방법으로는 (그림 2)에서 보여주는 enterprise-level roadmap이 있다 roadmap의 목적은 다음과 같다.

기존의 프로세스 모델을 CMMI transition하고자 하는 조직을 지원하기 위한 일반적인 프레임워크의 제공

- CMMIprinciples practices에 기초하여 조직 차원에서 사업 차원으로 움직이기 위해서 필요한 프로세스의 제공

실행 전에 고려해야 할 조직 및 인력 차원의 issues에 초점을 맞춘 변화의 준비Enterprise- level roadmap은 세 사이클로 구성되어 있으며다음과 같다.

- Entry/Reentry Cycle: transition 프로세스를 평가하고 적용하며 추진하기 위해 필요한 조치들을 식별한다이 사이클은 transition의 진행 상태에 대한 평가에 따라 반복적으로 수행될 수 있다.

① 현재의 practice에서 transition하기 위하여 필요한 변화를 식별한다.

② 적절한 대안을 조사하고 선택한다.

③ 자원 요구 사항을 결정하고 그 자원의 가용성을 보장한다.

④ transition 프로세스를 적용하고 실행할 것을 천명하고 추진한다.

⑤ Assessment points recycle decision criteria를 정의한다.

- Implementation Cycle: transition에 필요한 환경과 기반구조를 정비하는 데 필요한 조치들을 식별한다이 사이클은 환경의 변화와 lessons learned를 자본화하기 위해 주기적으로 재실행될 수 있다.

① Key stakeholders를 식별하고 같이 참여하게 한다.

② 비전을 개발하고 내재화하며(internalize) 상호 공유한다(communicate).

③ Goals, expectations, measures를 정의하고 문서화한다.

④ Change agents를 지정하고 권한을 준다.

- Process Cycle: transition 프로세스를 실행하고 모니터링하는데 필요한 조치들을 식별한다이 사이클은 지속적인 프로세스 개선 목적과CMMI principles practices의 내재화에 따라 반복적으로 수행될 수 있다.

① Key stakeholders의 참여를 독려하고 확인한다.

② Change agents의 진행 상태를 모니터링한다.

③ CMMI principles practices의 내재화(institutionalization)를 평가한다.

④ Commitments를 다시 평가하고 다음 단계를 결정한다.

4.    CMMI compatibility[7]

기존 모델과의 compatibility

CMMI < 1>에서 보여주는 능력 수준과 프로세스 개선을 위한 다양한 프레임워크들과 compatibility를 갖는다.

 

표준과의 compatibility

표준 혹은 지침 문서들 간의 상호 비교는 본질적으로 사과와 오렌지를 비교하는 것과 같다각 표준 혹은 지침 문서는 특정 목적으로 특정 계층에 정보를 제공하기 위하여 작성되었으므로 각기 다른 형태와 내용으로 구성되어 있다그러나많은 조직들은 조직적인사업적인 혹은 공학적인 관리 등 다양한 측면에서 여러 표준 혹은 지침문서들을 고려해야 할 상황이기 때문에다양한 표준 혹은 지침문서들 간의 유사성과 상이점 등을 비교한 정보는 매우 유용하다.

< 2>의 목적은 일반적으로 이루어지는 표준들 간의 비교와는 약간 다르다여기의 비교 분석에는 일부 표준에 대한 공식적이고 조직적인 상세한 비교가 포함되어 있다이 비교 분석은 일반적으로 조직의 방침프로세스 및 절차를 수립하고 개선시키는 책임을 맡고 있는 프로세스 엔지니어들에게 유용할 것이다그러나이 분석은 관리자들에게 다음과 같은 두 가지의 종합적인 관점을 제공하기 위하여 실시되었다. (1) CMMI와 관련된 문서들에서 어떤 주제들(topics)이 포함되거나 포함되지 않았는지에 대한 이해, (2) CMMI topic과 관련하여 제공되는 지침 정보가 CMMI보다 많은지 혹은 적은지에 대한 이해추가로, CMMI practice와 모순되는 부분은 강조되었다.

 

참고로이 분석에서 CMMI의 소스 모델(CMMs, EIA731 )은 다른 자료들에서도 많이 찾을 수 있으므로 포함되지 않았다.

< 2>에서 사용된 표기의 범례는 다음과 같다.

- Similar: CMMI와 동일한 깊이/강도로 언급됨.

- Out of scope: 언급되지 않음.

- More guidance: CMMI보다 더 많은 지침/설명이 포함됨.

- Less guidance: CMMI보다 더 적은 지침/설명이 포함됨.

- Minimal guidance: 최소한의 지침만이 약간 언급됨.

- Different focus: CMMI와는 매우 다른 관점에서 언급됨.

비교 대상이 된 표준은 다음과 같다.

- ISO 9001:2000 Quality Management Systems-Requirements: 품질경영 시스템의 실행을 지원하기 위한 조직 차원의 기반구조에 초점이 맞추어진 표준으로 일부 프로젝트 관리와 엔지니어링에 관련된 요구 사항을 포함하고 있다.

- ISO 10006 Quality Management: Giuideline to Quality in Project Management, 1997: ISO 9004-1을 보충하는 지침문서로normative 표준은 아니다오히려프로젝트 관리 practices관점에서 ISO 9004-1에 대한 설명을 제공하는 문서이다주요 소스들 중의 하나는 Project Management Institute Guide to the Project Management(PMBOK), 1996 버전이다.

- IEEE 1220 Standard for Application and Management of the Systems Engineering Process: 시스템 공학 생명주기 표준으로이 표준에는 ISO9001:1994 품질경영 시스템이 존재한다는 것과 IEEE 1220 ISO 12207의 요구 사항과 모순되지 않는다는 기본 가정이 포함되어 있다.

5. CMMI 적용을 위한 자원예산 및 일정[7]

여기에서는 CMMI를 적용하여 프로세스를 효과적으로 개선하기 위하여 필요한 인적 자원과 교육예산 및 일정에 대하여 설명한다.

인적자원과 교육

(그림 3)은 프로세스 개선 인력을 위하여 구성 가능한 조직내 구조를 제시하였다.

 

프로세스 개선 계획을 수립하고 그에 따라 실행하는 것이 장기적인 관점에서 매우 중요하다전체 조직내에서 Management Steering Group은 다음과 같은 역할을 수행한다.

프로세스 개선 활동을 주관한다.

조직의 사업 목적과 연결된 프로세스 개선 목적에 대한 장기 비전을 제시한다.

프로세스 개선 활동을 수행하기 위해 필요한 자원(인력과 예산)을 지원한다.

Engineering Process Group은 조직의 사업 목적과 연계된 프로세스 개선 목적에 대하여 깊이있게 이해하고 프로세스 개선경험을 가진 change agent로 구성되며다음과 같은 역할을 수행한다.

여러 분야(품질보증형상 관리과제 관리 등)에서 프로세스 개선 mentor로써의 역할을 수행한다.

조직내 프로세스 개선 활동을 조직화하고그 조직은 개별적인 프로젝트 단위별로 구성될수 있다.

프로세스 개선 활동을 수행하기 위해 필요한 자원(인력과 예산)을 지원한다.

조직내 프로세스 개선 활동기간 동안 존재하며영구히 유지될 수 있다.

Process Action Teams(PATs)는 조직의 문화와 역사를 이해하고 조직의 변화를 유발하는 능력을 가진 change agent로 구성되며다음과 같은 역할을 수행한다.

지속적으로 개선해야 할 특정 process area에서의 실행계획을 수립하고 실행한다.

조직 혹은 프로젝트에서 필요한 기간 동안 존재한다.

이러한 인력에 대한 교육은 다음과 같은 여러 수준으로 구분되어 진행될 수 있다.

 

예산

조직내에서 수행하는 다른 프로젝트와 같이, CMMI 적용을 프로젝트화하여 추진하는 것이 좋다. CMMI 적용 프로젝트 추진을 위한 예산은 각기 조직의 특성에 따라 다르겠지만다음과 같은 지침은 유용할 것이다.

- Engineering Process Group의 멤버는 full-time funding을 지원한다.

- Process Action Team(PAT)의 멤버는 근무시간의 50% funding을 지원한다. PAT는 제한된 기간 동안 작은 규모로 운영한다.

- PAT의 결과와 비용을 관리한다이슈가 있다면 필요한 활동들의 funding과 범위를 적절히 조정하여 준비한다.

change agent PAT를 위한 적절한 CMMI 교육을 실시한다최소한 CMMI 초급 및 중급과정에 1주일의 예산을 준비한다.

일정

조직의 특성에 따라 CMMI 적용을 위한 일정은 매우 다르게 추진할 수 있다각 조직의 시작 시점은 다르다 할지라도다음과 같은 지침은 유용할 것이다.

- CMMI 적용은 다른 조직문화의 변화와 동일하게 추진한다시작보다는 적용을 위한 추진기간이 더 많은 시간을 필요로 한다.

- CMM-SW를 적용할 때의 SEI 측정자료를 참고하면프로세스 개선 경험이나 기반구조가 거의 없는 조직은 성숙도 level 2에 이르는데 일반적으로 18개월 혹은 24개월이 소요된다여기에서 다시 성숙도 level 3까지의 소요기간은 추가적으로 12개월이 소요된다.

높은 프로세스 성숙도 혹은 능력 수준을 가진 조직은 약 1년의 기간이 소요된다일반적으로새로운 프로세스를 조직내에 내재화하는 데는 최소한 6개월이 소요된다.

IV. 결 론

지금까지 프로세스 능력 성숙도 모델인 CMMI에 대한 전반적인 개요와 CMMI를 적용하고자 할 때 참조할 수 있는 적용 방안에 대하여 살펴보았다.현재 CMMI는 미국 카네기멜론대학의 소프트웨어공학연구소(SEI)에서 개발된 모델로 소프트웨어공학과 시스템공학을 통합한 프로세스 능력 성숙도 모델로써 새로운 발전의 기회를 맞이하고 있다또한국제표준화기구(ISO)에서 국제표준으로의 전환이 확정되어 표준 제정이 활발히 진행 중인SPICE (ISO/IEC 15504)와 함께 프로세스 능력 성숙도 모델이라는 고유한 영역을 확보해 나갈 것으로 기대된다조직에서 제공하는 제품과 서비스의 품질을 향상시키기 위하여 프로세스 모델의 적용을 고민하고 있는 조직에게 CMMI는 국제표준인 SPICE(ISO/IEC 15504)와 함께 많은 도움을 줄 수 있을 것이다.

<참 고 문 헌>

[1]    Capability Maturity Model Integration(CMMISM), Version 1.1, Software Engineering Institute, Carnegie Mellon University, 2002.

[2]    M. Paulk, B. Curtis, M.M. Chrissis, and C. Weber, Capability Maturity Model for Software, Version 1.1(CMU/SEI-93-TR-024), Software Engineering Institute, Carnegie Mellon University, 1993.

[3]    SEI, CMMISM Tutorial, Software Engineering Institute, Carnegie Mellon University, 2001.

[4]    P. Curtis, D.M. Phillips, and J. Weszka, CMMISM-The Evolution Continues!, Systems Engineering, Vol.5, No.1, 2002.

[5]    J. Weszka, Special Issues on Capability Maturity Model IntegrationSM, Systems Engineering, Vol.5, No.1, 2002.

[6]    D.M. Ahern, A. Clouse, R. Turner, CMMISM Distilled: A practical Introduction to Integrated Process Improvement, Addison-Wesley, 2001.

[7]    SEI, Transitioning to CMMI: A GUIDE for Executives, Version 0.51, Software Engineering Institute, Carnegie Mellon University, 2002.

 

출처 : ITFIND 주간기술동향 1171호


List of Articles
No. Subject Author Date Views
» 프로세스 능력 성숙도 모델(CMMI)의 적용 digipine 2017.10.28 154
79 포렌식을 활용한 정보보호 digipine 2017.11.02 139
78 초고속망 통신사 DNS 서버 주소 모음 - DNS 설정 digipine 2017.11.03 1050
77 임베디드SW 개발자센터 이용안내(성남시 분당구, 개발공간 무료제공) digipine 2017.11.02 54
76 유닉스/리눅스 명령어 레퍼런스 digipine 2017.11.03 218
75 윈도우즈 도스 커멘드(Command) 네트워크 관련 명령어 lizard2019 2019.02.07 309
74 윈도우 한영 전환 쉬프트 스페이스로 변경 digipine 2017.11.03 136
73 우분투 Nabi 한글 입력기 Tray(트레이) 상단 메뉴바로 옮기기 digipine 2017.11.03 309
72 언어 IDE 별로 git ignore 파일을 자동으로 만들어 주는 사이트 엉뚱도마뱀 2018.12.17 207
71 악성코드 종류 구분 digipine 2017.11.13 390
70 수학적 구조물 모델링 만들기 소개 비디오 엉뚱도마뱀 2018.09.24 366
69 소프트웨어 테스팅 전문가들을 위한 사이트 digipine 2017.11.02 94
68 비밀번호 해쉬에 Salt(소금) 첨가하기 file 엉뚱도마뱀 2017.11.23 1073
67 리눅스 커널의 Swap Memory에 대해서 digipine 2017.11.02 107
66 리눅스 /dev/random을 이용한 랜덤값 생성 엉뚱도마뱀 2017.11.22 341
65 대칭키 암호화관련 개념 정리 digipine 2017.11.09 496
64 난수발생기 개론 엉뚱도마뱀 2017.11.22 890
63 공짜 무료 C/C++ 컴파일러들 file digipine 2017.10.28 2020
62 [ubuntu, 우분투] sendmail 설치 digipine 2017.11.02 838
61 [Swift, MacOS] 맥 한글 파일명이 윈도우에서 자소 분리되는 현상 해결, NFD, NFC 엉뚱도마뱀 2018.12.11 1751
Board Pagination Prev 1 2 3 4 Next
/ 4