이 페이지가 유용했습니까?
이 콘텐츠에 대한 여러분의 의견은 중요합니다. 의견을 알려주십시오.
추가 의견
1500자 남음
내보내기(0) 인쇄
모두 확장
이 문서는 수동으로 번역한 것입니다. 원본 텍스트를 보려면 포인터를 문서의 문장 위로 올리십시오. 추가 정보
번역
원본

CMMI 원칙 및 값

By David J. Anderson. David J. Anderson은 2003년 출간된 “소프트웨어 엔지니어링을 위한 애자일 매니지먼트: 비즈니스 결과에 제약 이론 적용(Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results)” [1]과 2010년에 출간된 “칸반: 당신의 기술 비즈니스를 위한 성공적인 진화적 변화(Kanban: Successful Evolutionary Change for your Technology Business)” [2]의 저자입니다. 그는 1997~1999년에 싱가포르에서 Agile 소프트웨어 개발 방법인 기능 주도 개발 방법을 만드는 팀의 구성원이었습니다. 그는 Declaration of Interdependence, 2005에서 정의한 Agile 프로젝트 관리 원칙을 만든 사람입니다. David는 CMMI 프로세스 개선에 대한 MSF를 만들었고, 소프트웨어 엔지니어링 기관에서 기술 참고서인 'CMMI냐, 애자일이냐: 둘 다 선택(CMMI or Agile: Why Not Embrace Both!)' [3]를 공동 저술했습니다. 그는 Lean Software & Systems Consortium(http://www.leanssc.org)의 부사장이며, 국제 관리 훈련 및 컨설팅 회사, David J의 책임자입니다. 기술 기업이 더 나은 관리 정책 및 의사 결정을 통해 실정을 향상할 수 있도록 도와주는 Anderson & Associates 주식 회사 http://www.agilemanagement.net

2012년 1월

Anderson이 CMMI 렌즈를 통해 조직을 보는 것이 관리자, 프로세스 엔지니어와 고객, 투자자, 정부 기관 및 감사자를 포함한 모든 외부 관련자에게 얼마나 귀중한 통찰력을 제공하는지 설명합니다.

Application Lifecycle Management, CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

원래 CMM(Capability Maturity Model)은 1991년 처음 게시되었습니다. 10년 후에 CMMI(Capability Maturity Model Integration)으로 발전되었습니다. CMMI는 현재 세 개의 컨스틀레이션으로 알려진 제품군이며, 이 문서는 특히 CMMI-DEV(개발 컨스틀레이션)를 참조합니다. CMM은 미국방부가 대규모 정부 조달 프로그램 소프트웨어 프로젝트가 많은 비용으로 인해 실패에 대해 더 잘 이해하는 데 도움이 되도록 개발되었습니다. CMM을 기반으로 한 평가는 정부 계약을 위한 “적합성”을 확인하는 데 사용되었습니다. 나중에 CMMI를 기반으로 정의된 평가 체계로 발전됩니다.

조직 성숙도의 개념은 논쟁거리로 남아 있습니다. 예를 들어, 어떻게 조직의 성숙도 평가할 수 있습니까? 그리고 조직은 진정으로 개인의 행동이나 작업과 구분되는 태도를 가지고 있습니까? 특정 완성도 수준에서 조직을 평가할 수 있고 이 평가가 정부에 신뢰할 수 있는 작업을 제공하는 기능을 나타내는 지표라는 개념은 지속적인 논쟁의 문제입니다. 그러나, 저는 여전히 CCMI를 지지하고, CCMI 관점에서 조직을 관찰하면 관리자, 프로세스 엔지니어와 고객, 투자자, 정부 기관 및 감시자를 포함한 모든 외부 이해 관계자가 가치 있는 통찰력을 얻을 수 있다고 생각합니다.

CMMI의 완성도는 결정을 내릴 때 위험과 판단을 평가 및 관리하는 방법과 기능을 암시합니다. "완성도"라는 용어는 개인과 관련하여 일반적인 사용 측면에서 실제로 사용되고 있습니다. 예를 들어, 보험은 55세의 여성보다 18세 남성이 차 사고를 낼 확률이 더 높다는 것을 말해 줍니다. 18세의 남성은 차량 처리에 대한 결정을 내릴 때 판단을 잘못할 가능성이 높으며 특정 조치와 관련된 위험을 적절하게 평가할 수 없습니다. 이는 55세의 여성이 피할 수 있는 사고를 일으킬 수 있습니다. 보험 회사는 통계 데이터를 수집하고 증거를 연결하기 때문에 위험을 평가하는 데 특히 능숙합니다.

CMMI의 문제 하나는 인식된 함정이 많아 "완성도"라고 명명된 용어의 속성입니다. 더 높은 완성도는 더 낮은 완성도보다 좋다고 가정합니다. 항상 더 높은 성숙도를 추구해야 합니다. 개별 조건에서 이를 고려할 경우 항상 의미가 있는 것은 아닙니다. 보험 회사는 좀 더 성숙한 사람에게 더 저렴하게 자동차 보험 가격을 책정하겠지만 오픈 휠 레이싱 팀은 젊은이다운 패기와 도전을 높이 평가할 것입니다. 레이싱 팀의 경우 차량 충돌은 비즈니스의 일부입니다. 사실 충돌한 후에 차량에 화재가 발생하지 않은 운전자들입니다.

성숙도 수준에 필요한 이곳의 메시지는 상황과 컨텍스트가 일치해야 합니다. 보다 많은 것이 반드시 더 나은 것은 아니지만 조직 완성도를 올바르게 식별 및 평가하는 기능을 사용하면 비지니스에서 더 쉽게 위험을 관리하고 프로젝트와 제품 결정을 내릴 때 적절한 판단을 할 수 있습니다.

완성도 수준과 원하는 결과 달성 및 제공 사이에의 강한 상관 관계가 있어야 합니다. 완성도 높은 조직은 원하는 목표에 가까운 결과를 제공할 가능성이 매우 높아야 합니다. 여기에는 완성도와 가능성이 있고 달성 가능한 결과를 평가하고 이에 따라 목표를 설정하는 기능이 포함됩니다. 완성도가 떨어지는 조직은 달성 가능한 목표를 설정하고 기대에 부응하여 원하는 결과 제공할 가능성이 낮습니다. 이 동전의 측면의 경우 높은 완성도 조직은 위험을 싫어하고 쉽게 달성할 수 있는 목표만 설정하는 반면 열성적인 낮은 완성도 조직은 행운과 근면으로 뛰어난 성과를 달성할 수 있습니다.

원래 CMM는 Watts Humphrey에 의해 개발되었으며 그의 저서인 소프트웨어 프로세스 관리[4]에 처음으로 나타났습니다(CRM이라는 이름 없이). 이는 20 세기 제조 품질 보증 운동과 Joseph Juran, W의 작업에 영향을 받았습니다. Edwards Deming, and Philip Crosby. “성숙도 모델”이라는 용어와 그 안의 5개 수준은 Crosby의 제조 성숙도 모델로 영감을 받았습니다. 그러나 CMM을 아이디어의 진정한 합성으로 보아야 합니다. “역량”이라는 용어는 거의 Deming에 의해 영감을 받았습니다.

Deming은 '기능'이란 용어를 아마도 단어를 이해하는 보통의 언어보다 훨씬 더 깊은 맥락에서의 매우 특별한 의미로 사용했습니다. 더 정확하게 "기능"은 시스템의 "자연 철학" 또는 시스템 내의 작업으로 고려할 수 있습니다. Deming은 “역량을 연구”하고 이를 통계적으로 분석하도록 관리자들을 격려했습니다. 그는 "심오한 지식의 시스템"[5]을 개발하였습니다. 이는 매니저가 적절한 시스템 디자인 개입을 결정할 수 있도록 결정 프레임워크를 사용하도록 하는 것입니다. Deming은 진정으로 시스템에 대해 고민하는 사람이었습니다. 이 경우 단어 "system"은 사용자가 수행하는 프로세스를 의미합니다. 기술 또는 자동화를 암시할 의도는 없습니다.

Deming은 시스템 성능의 95% 이상이 시스템에서 작업하는 개인의 역량보다 시스템의 디자인에 기인한다고 믿었으며, 또한 증명해 냈습니다. 즉, 향상을 가져오려면 개별 성능 향상에 중점을 두기보다는 사람들이 일하는 시스템 내의 프로세스 변경에 중점을 두어야 합니다. 그래서 그는 목표, 목표에 따른 관리, 동기를 부여하는 포스터 또는 성과가 저조한 개인을 벌하는 것을 좋게 생각하지 않습니다.

따라서 Deming은 역량 모델에 자신의 깊은 지식 시스템을 제공했고 Crosby는 완성도 모델을 제공했습니다. Humphrey가 이러한 개념을 합성하고 소프트웨어 엔지니어링 분야에 적용한 결과 역량 성숙도 모델을 만들었습니다.

평가 및 정부 계약에 적합한 수준의 자격을 추구에 중점을 두어 역량 모델 및 데밍의 영향력이 CMM와 CMMI 문서에서 대부분 사라졌습니다. 그러나 높은 성숙도 수준에서 정의된 프로세스 영역에서 Deming의 영향을 명확하게 볼 수 있습니다.

CMMI는 항상 조직 내에서의 지속적 향상의 문화를 장려하는 프레임 워크를 지향해 왔으며, 시스템 입장에서의 접근 방식을 지향해 왔습니다. CMMI의 루트에서 Lean과 평행한 여러 증거가 있습니다.

CMMI는 조직의 성숙도와 역량을 이해하는 모델입니다. 이것은 표준이 아니며 소프트웨어 개발 또는 프로젝트 관리 프로세스 정의도 아닙니다. 이 문서에서 설명하는 일반 방법은 특정 프로젝트나 개발 중인 제품이 아니라 프로세스 기능을 의미합니다. 예를 들어, 다음 테이블은 모든 프로젝트 또는 제품 배달이 아닌 프로세스 구현 계획을 나타냅니다.

CMMI 모델은 22개의 프로세스 영역과 모든 조직의 추진이 예상되는 세 개의 일반 목표로 구성됩니다.

3가지 일반 목표는 다음과 같습니다.

일반적인 목표

일반 연습

목적

GG 1- 이 프로세스는 식별 가능한 입력 작업 산출물을 식별 가능한 출력 작업 산출물을 생성하도록 변형하여 프로세스 영역의 특정 목표 도달을 지원하고 가능하도록 합니다.

GP 1.1 - 산출물을 생산하기 위한 프로세스의 특정 사례를 수행하고 프로세스 영역의 특정 목표에 달성하기 위한 서비스를 제공합니다.

기본 가정은 프로세스에서 오는 예측 가능한 결과입니다.

GG 2 - 프로세스는 관리되는 프로세스로 규정됩니다.

GP 2.1 - 프로세스를 계획하고 수행하기 위한 조직 정책을 설정하고 유지합니다.

관리는 프로세스의 생성, 관리 및 사용을 장려하여 GP 2.1을 지원해야 합니다. 프로세스가 예측 가능한 결과를 보장하기 위해 따라야 한다는 것을 명시하는 식별 가능한 관리 정책/매크로가 있습니다.

GP 2.2 - 프로세스를 수행하기 위한 계획을 설정하고 유지합니다.

새 활동이 프로세스를 적용하고 따를 수 있도록 하는 계획이 있습니다.

GP 2.3 - 작업 산출물을 개발하고 프로세스 서비스를 제공하여 프로세스 수행에 필요한 충분한 리소스를 제공합니다.

경영진은 다음과 같은 프로세스를 지원하며 자원을 적절히 배분하여 성공하기 위해 프로젝트를 설정합니다.

GP 2.4 - 작업 산출물을 개발하고 프로세스 서비스를 제공하여 프로세스 수행에 필요한 책임과 권한을 부여합니다.

고위 경영진은 프로세스를 수행하고 예상되는 작업 산출물을 생성하도록 프로젝트에 권한을 부여하고 역할과 책임을 설정합니다.

GP 2.5 - 필요할 때 프로세스를 수행하거나 지원하는 사람들을 교육시킵니다.

훈련 프로그램은 프로젝트 직원이 요청받은 작업을 수행하고 바람직한 프로세스 영역 기능을 제공할 수 있도록 적절하게 숙련하기 위해 존재합니다.

GP 2.6 - 프로세스의 선택된 작업 제품을 적절한 제어 수준에 놓습니다.

작업 제품 생성 시(예: 요구 사항 관리 및 추적, 소스 코드 버전 제어 그리고 환경 구성 제어) 모든 필수 아티팩트에 대한 관리 및 문서가 있습니다.

GP 2.7 - 계획한 대로 관련자를 식별하고 포함시킵니다.

모든 필요한 이해 관계자가 참여합니다. 예측 가능한 위험은 결과로 식별됩니다.

GP 2.8 - 프로세스 수행을 위한 계획을 기준으로 프로세스를 감시하고 제어하며, 적절한 수정 작업을 수행합니다.

이는 GP 2.2와 관련이 있으며 계획이 수행된 것을 보여 주기 위해 프로세스를 따르는 계획을 모티터링 할 것을 요청합니다. 예를 들어, 그 계획에서 프로세스 엔지니어가 프로젝트를 만나 정의를 만들도록 요구했다면 그 모임은 이루어졌을까요?

GP 2.9 - 프로세스 설명, 표준 및 절차에 근거하여 프로세스 안정화를 객관적으로 평가하고 준수하지 않은 표준, 절차 등을 알려 줍니다.

프로세스가 피하거나 무시되는 것보다 따르고 있는지 모니터링합니다. 운영 현실과 일치하지 않는 경우 정의된 프로세스 수정을 고려하십시오.

GP 2.10 - 작업, 상태 및 상위 수준의 관리 프로세스의 결과를 검토하고 문제를 해결합니다.

고위 경영진의 참여 및 지원을 유지합니다. 수석 관리자와 운영 검토를 수행하고 역량을 기대치 및 요구 사항과 비교합니다. 리소스 사용 및 교육이 적절한지 고려하고 필요한 경우 프로세스 정의 또는 프로세스 영역 기능 문제를 해결하기 위한 작업을 합니다.

GG 3 - 프로세스는 정의된 프로세스로 규정됩니다.

GP 3.1 – 정의된 프로세스의 설명을 설정하고 유지합니다.

프로세스를 반복하고 의도한 대로 수행하기 위해서는 문서화된 규칙이 필요합니다.

GP 3.2 - 작업 산출물, 측정, 측정 결과, 계획에서 파생된 향상 정보, 이후에 사용할 프로세스 수행 결과, 조직의 프로세스 및 프로세스 자산 향상 결과를 수집합니다.

정량적 방법을 통해 프로세스의 적합성을 관리하고 정략정 방법이 전개될 때 필요를 충족하기 위해 필요에 따라 적합성을 발전시킵니다.

22 프로세스 영역은 엔지니어링, 프로젝트 관리, 프로세스 관리 및 지원의 4개 범주로 정렬됩니다. 각 프로세스 영역은 1~3개의 특정 목표 및 모두 세 가지 일반적인 목표로 구성되어 있습니다. 각 목표에 대한 실행 방법은 목표 달성을 위해 필요합니다. 연습 내에서 하위 연습을 제안할 수 있습니다. CMMI만 필요하거나 목표를 규정합니다. CMMI 모델의 목표 내에 정의된 연습이 예상되지만 필수는 아닙니다. 제공하지 않은 경우 동일한 대체 방법으로 교체해야 합니다. 다음 표에서는 프로세스 영역을 그룹화하는 것을 보여줍니다.

조직 포커스

프로세스 영역

엔지니어링

요구 사항 개발

기술 솔루션(Technical Solution)

제품 통합(Product Integration)

확인

검증

프로젝트 관리

프로젝트 계획(Project Planning)

프로젝트 모니터링 및 통제(Project Monitoring & Control)

통합 프로젝트 관리(Integrated Project Management)

공급자 계약 관리(Supplier Agreement Management)

요구 사항 관리(Requirements Management)

위험 관리(Risk Management)

정량적 프로젝트 관리(Quantitative Project Management)

프로세스 관리

조직 프로세스 중점 관리(Organizational Process Focus)

조직 프로세스 정의(Organizational Process Definition)

조직 교육(Organizational Training)

조직 프로세스 성과(Organizational Process Performance)

조직 혁신 및 이행(Organizational Innovation & Deployment)

지원

구성 관리(Configuration Management)

프로세스 및 제품 품질 보증

측정 및 분석

의사 결정 분석 및 해결

원인 분석 및 해결

따라서 원리는 간단합니다. 즉, 조직에서 각 프로세스 영역 내에서 목표를 달성하는 기능을 나타낼 경우 이러한 조직은 특정 프로세스 영역에서 기능을 가지고 있다고 말할 수 있습니다.

프로세스 영역은 성숙도 수준으로 그룹화되며, 성숙도를 설명하는 약식 방법을 제공합니다. 프로세스 영역의 수준별 그룹화에 대해 여러 수준의 논쟁이 계속되어 왔지만 지난 20년 동안 조직에 대한 경험에 비추어 모델의 현재 버전 1.3(CMMI가 사실상 CMM의 버전 2라고 간주)은 대체로 적절한 것으로 전망됩니다. 낮은 성숙도의 무질서한 조직은 더 높은 수준에서 정의된 프로세스 영역에서 역량을 개발하기 전에 성숙도 수준 2에서 정의한 프로세스 영역에서 역량을 개발하는 경향이 있습니다.

다음 표에서는 프로세스 영역을 수준으로 그룹화하는 것을 보여줍니다.

완성도

프로세스 영역

5

CAR – 원인 분석 및 해결

OPM – 조직 성과 관리

4

OPP – 조직 프로세스 성과(Organizational Process Performance)

QPM – 정량적 프로젝트 관리(Quantitative Project Management)

3

RD – 요구 사항 개발

TS – 기술 솔루션(Technical Solution)

PI – 제품 통합(Product Integration)

VER – 확인

VAL – 유효성 검사

IPM – 통합 프로젝트 관리

RSKM – 위험 관리(Risk Management)

OPF – 조직 프로세스 중점 관리(Organizational Process Focus)

OPD – 조직 프로세스 정의(Organizational Process Definition)

OT – 조직 교육(Organizational Training)

DAR - 의사 결정 분석 및 해결

프로세스 및 제품 품질 보증(Process & Product Quality Assurance)

2

CM - 구성 관리

MA - 측정 및 분석

SAM – 공급자 계약 관리(Supplier Agreement Management)

PP – 프로젝트 계획(Project Planning)

PMC – 프로젝트 모니터링 및 통제(Project Monitoring & Control)

RM – 요구 사항 관리(Requirements Management)

1

모델 수준 1 내에는 프로세스 영역이 없습니다. 수준 1은 검사나 프로세스를 정의하거나 결과를 만든 프로세스 이해를 통해 결과를 반복하는 기능이 없는 정의되지 않은 프로세스를 나타냅니다. 기술적으로 CMMI 평가에서 목표 모델 수준 2의 프로세스 영역에 적합한 목표를 충족하지 않는 조직은 여전히 모델 수준 1입니다. 따라서 새 프로세스를 가진 조직은 정의되지 않은 혼란으로 인해 갈 길이 멀지만 기술적으로 모델 레벨 1로 여전히 간주됩니다.

다음 표에서는 각 프로세스 영역의 주제나 목적 측면에서 개요를 제공합니다.

프로세스 영역

목적

CAR - 원인 분석 및 해결

예외적인 프로세스 문제의 근본 원인을 조사합니다(특별한 원인 변화, W 사용. Edwards Deming의 용어), 재발을 방지하기 위해 프로세스 변경을 제안하고 구현합니다. 관심은 양적으로 이해되는 안정적인 프로세스의 특이한 동작으로 이어집니다. 매일 문제는 CAR보다 위험 관리(RSKM)의 일부로 간주됩니다.

CM- 구성 관리

단순한 소스 코드 버전 제어 이상일 경우 이 프로세스 영역은 시스템 환경, 구성 요소의 구성, 플랫폼, 미들웨어, 응용 프로그램 및 설명서와 관련된 모든 관리를 다룹니다. 이 프로세스 영역 내에 있는 작업 코드를 성공적으로 빌드하고 배포하는 기능입니다.

DAR - 의사 결정 분석 및 해결

프로젝트 또는 제품 개발에서 모든 주요 결정에 대해 대안 또는 옵션 집합이 고려되었으며, 적합한 다양한 옵션들에 접근하기 위해 컨텍스트 요소가 사용되었음을 보여주십시오. 결정과 선택 이유를 기록합니다.

IPM - 통합 프로젝트 관리

CMMI 모델 내에서 프로젝트 관리의 두 번째 수준은 조직이 여러 잠재적인 종속 프로젝트를 동시에 관리할 수 있음을 의미합니다. 이는 종종 프로그램이나 포트폴리오 관리 사무소의 사용을 통해 달성됩니다.

MA - 측정 및 분석

프로세스, 프로젝트 및 제품 성능에 대한 데이터를 수집합니다. 데이터를 기반으로 보고서의 형태로 메트릭과 지표를 생성합니다.

OPD - 조직 프로세스 정의(Organizational Process Definition)

조직은 컨텍스트 내에 정의된 하나 이상의 프로세스 정의를 갖고 있어야 합니다. 컨텍스트는 위험 프로필을 설명합니다. 각 프로젝트는 조직 카탈로그에서 선택되고 적절하게 재단된 위험 및 프로세스 정의에 대해 평가될 수 있습니다.

OPF – 조직 프로세스 중점 관리(Organizational Process Focus)

조직은 프로세스 정의를 통해 기능을 정의하고 기능에 영향을 주며 개선 기능이 주로 개선된 프로세스를 좌우된다는 점을 생각해야 합니다. 결과적으로, 조직이 그 프로세스 정의를 사전에 관리하고 PPQA 프로세스 영역을 사용하여 이들 정의가 뒤따르도록 모니터링합니다.

OPM – 조직 성과 관리

이 프로세스 영역에서는 프로세스가 예상되는 기능을 얼마나 잘 충족하는지에 대한 통계적 이해의 개념을 캡슐화합니다. 프로세스 정의에 대한 변경이 이루어졌을 때 관찰 결과에 기본 모델에서 예측한 것이 반영되지 않는 경우 기능을 향상시키기 위한 프로세스 변경 사항은 평가가 가능하며 프로세스 기본 모델로 간주됩니다. 조직은 비즈니스 요구를 충족하려면 프로세스를 통해 성과를 관리합니다.

OPP – 조직 프로세스 성과(Organizational Process Performance)

이 프로세스 영역은 대개 "벤치마킹"이라고 불리는 성능 비교의 개념을 캡슐화합니다. OPP는 비교를 사용하기 위해 기준 데이터에서 프로세스 모델을 만듭니다. 이는 "[이 특정 프로젝트]를 위해 세 개의 제품 팀 중 어느 팀을 선택해야 하는가?" 같은 질문에 답변하는 기능을 조직에게 제공합니다.

조직 교육(Organizational Training)

특정 실행에서 개별 기능은 프로세스 성능 및 시스템 기능에 중요합니다. 강력한 성능을 보이며 제대로 작동하는 시스템에는 로컬 실행 수준에서 기능의 변동성을 줄일 수 있는 강력한 교육 능력이 있습니다.

제품 통합(Product Integration)

완전한 제품을 형성하고 이를 위한 요소를 관리하려면 여러 구성 요소를 통합할 수 있는 기능이 필요합니다.

프로젝트 모니터링 및 통제

계획, 예측 및 시뮬레이션과 비교하여 진행 중인 프로젝트에 대한 데이터를 수집하고 데이터를 기반으로 적절한 행동을 취하십시오.

프로젝트 계획(Project Planning)

예측, 시뮬레이션, 요구 사항 분석을 기준으로 프로젝트를 계획합니다.

프로세스 및 제품 품질 보증

주로 프로세스 준수 감사 함수입니다. 시스템이 설계대로 작동하는지 보여주기 위한 것입니다. 현재 프로세스가 의도한대로 표시되지 않는 경우 도움말은 문제를 해결하는 프로세스를 변경하는 잠재적인 관리 실수를 방지할 수 있습니다.

정량적 프로젝트 관리(Quantitative Project Management)

CMMI 모델 내에서 프로젝트 관리의 세 번째이자 가장 높은 수준입니다. 통계적으로 건전하고 정량적인 방법은 프로젝트를 계획하고 모니터링하고 관리하는 것을 의미합니다.

요구 사항 개발

요구 사항을 요청하고 협상하고 분석하고 문서화하기 위한 정의된 반복 가능한 프로세스가 있습니다.

요구 사항 관리(Requirements Management)

프로젝트 수명 주기 전체에서 요구 사항을 추적하며, 이상적으로는 제공된 구성과 원래 요구 사항 요청 사이를 종단 간 추적할 수 있습니다.

위험 관리(Risk Management)

전체 CMMI 모델은 위험 관리를 위한 프레임 워크로 볼 수 있지만 이 프로세스 영역은 특히 '이벤트 중심 위험' 또는 특별한 원인으로 인한 변동 가능성 및 영향과 일상적인 문제를 해결합니다. 이 프로세스 영역에는 위험 감소, 완화, 대체 계획, 문제 관리 및 해결이 요구됩니다.

공급자 계약 관리(Supplier Agreement Management)

외부 공급 업체 관리, 계약 정의, 연락처 관리 및 원하는 제품 또는 서비스를 배송하는 기능이 필요합니다.

기술 솔루션(Technical Solution)

소프트웨어 아키텍처, 디자인 및 코딩과 관련하여 필요한 모든 기술입니다.

검증

고객 요구 사항에 대한 인수 테스트입니다.

확인

설계 테스트(기술 솔루션에서). 빌드 중인 제품을 상상하고 설계하여 사용자의 요구를 충족하고 해당 환경에서 작동할 수 있도록 모아놔야 합니다.

각 프로세스 영역에 대해 역량 수준을 평가할 수 있습니다. 4가지 역량 수준이 CMMI의 v1.3에 정의됩니다.

0. 완료 안 됨

1. 수행됨

2. Managed

3. 정의됨

각 특정 목표를 충족하고 일반 목표의 일부를 충족하면 특정 프로세스 영역이 적어도 레벨 1만큼 수행되었다고 평가할 수 있습니다. 기능 수준 1은 팀 멤버가 무엇을 할 것이며 무엇을 하고 있는지를 암시합니다. 그러나 특정 방식은 통계적으로 분석된 경우 안정성을 보여줄 가능성이 없습니다. 연습을 수행 중이지만 여전히 일관성은 부족합니다. 기능 수준 2는 팀이 작동 방법을 인식하고 예측 가능하고 통계적 제어를 보일 수 있는 실행 방식을 수행할 수 있는 수준의 기술을 가지고 있는가를 의미합니다. 팀 구성원의 더 높은 일관성을 위해 교육이나 협력 작업 방법이 필요합니다. 기능 수준 3은 숙달된 기술과 목표를 달성할 수 있는 새롭고 향상된 기술을 개발하는 능력을 의미합니다. 수준 3 기능은 모든 통계 분석에서 기존의 기술이나 방법을 각각 명시적으로 변경한 후에 기준을 다시 지정해야 한다는 것을 의미합니다.

따라서 CMMI 모델은 기본적으로 새로운 미완성된 조직은 먼저 구성과 소스 제어를 관리하고, 수행하는 프로젝트와 작업에 대한 정보를 수집하고 프로젝트를 계획하고 요구 사항을 추적하고 프로젝트 진행율을 모니터링하며 실제 데이터와 계획을 비교하여 조치를 위하는 실제적인 기능을 개발할 예정이라고 언급하고 있습니다. 성숙도 수준 2의 기본입니다.

성숙도 수준 2 기능이 자리를 잡으면서 조직과 직원은 시작되기 시작한 것이 반복되도록 요구 사항을 정의하는 기능, 테스트, 건축과 디자인, 통합 및 정의 프로세스 등 다른 사항으로 관심을 돌립니다. 작업이 안정화될수록 문화와 경영 스타일이 성능에 영향을 끼치는 방식에 대한 이해가 생기며 추가로 성능 향상을 유도할 수 있는 시스템 사고 접근법에 대한 이해도 생길 수 있습니다. 더 안정되고 계획과 프로젝트 모니터링 같은 일상 문제가 부차적인 문제가 되면 위험 관리를 고려하고 결정을 내리기 전에 대안 및 옵션을 분석할 시간이 주어집니다. 여러 종속 프로젝트의 조정과 공유 리소스의 개선된 관리가 나타날 수 있습니다. 아마도 교육 프로그램, 멘토링 구성표, 마스터-실습생 개인 지도 구성표 또는 단순히 공동 작업의 의식화된 형태가 기능을 개선하고 전체 성능 수준을 높이기 위해 출현합니다. 필요한 경우 일부 내부 감사 또는 프로세스 품질 보증 함수가 발생할 수 있습니다. 이 모두가 성숙도 수준 3의 기본입니다.

조직이 견고한 성숙도 수준 3에서 실행되면 업무가 시계처럼 실행됩니다 조직은 약속을 지키고 매우 안정적이고 신뢰성이 있는 것으로 보여집니다. 높은 신뢰 수준은 고객과의 관계에서 나타납니다. 고위 관리자는 "더 향상 시키기 위해 어디에 투자 해야 합니까?"와 "어떤 팀이 최고의 경제 성과를 냅니까?" 같은 질문을 하기 시작합니다. 관리자는 기능과 성능을 더 자세히 파악하고 제품 품질, 제품 고객 인도 및 고객 만족을 향상시키기 위해 시뮬레이션과 통계 분석을 사용할 수 있다는 사실을 인식하기 시작합니다. 관리 결정은 통계 데이터를 사용하여 이제 완전히 객관적이고 방어적일 수 있습니다. 성숙도 수준 4 조직의 기본입니다. 최고위 관리자의 경우 성숙도 수준 4가 이상적인 상태를 나타냅니다. 모든 것이 규칙적으로 실행되고, 그들은 성능 높은 데이터와 높은 수준의 정밀도를 나타낼 수 있습니다. 경제적 성과는 크게 개선되고 조직의 실적을 예측하기 매우 쉽습니다.

성숙도 수준 5 동작은 종종 조직이 실제로 수준 5에 도달하기 오래 전에 나타납니다. 근본 원인 분석은 성숙도 수준 3 조직에서 자주 볼 수 있습니다. 수준 5 기능으로 만드는 것은 정량적 데이터를 사용하여 근본 원인 분석을 수행하며 통계적으로 방어할 수 있는지 여부입니다. 프로세스 혁신 및 및 개선 사항 배포에 대한 정형화된 프로세스는 조직에서 완성도 수준 5로 간주하기 전에 출현할 수도 있습니다. 수준 5에서 프로세스 개선이 규정되고 조직의 문화권에 심어졌습니다. 문화는 항상 현재 상태에 도전하고 향상된 기능, 제품 품질 및 경제적 성과를 찾습니다.

CMMI 성숙도 등급은 평가에 의해 설정됩니다. 평가를 수행하는 표준 프로세스인 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)가 있습니다. 이것은 프로세스에 대한 일부 반복성을 적용하고 결과를 어느 정도 신뢰하기 위해 소개되었습니다. 평가 엄격함의 세 가지 수준은 클래스 A, B 및 C로 언급되며 클래스 A는 가장 엄격함을 의미합니다. 공용 기록 또는 미국 국방부 요구 사항에 적합한 모델 수준 등급의 클래스 A 평가가 요청됩니다.

모든 A 클래스 감정 평가와 B와 C 클래스의 감정 평가 대부분은 소프트웨어 공학 연구소(Software Engineering Institute)에서 승인한 CMMI 선임 심사원에 의해 실시되고 있습니다. 이러한 컨설턴트는 연습 라이선스를 받기 전에 철저한 교육 프로그램을 거쳤습니다. 일부 평가자가 추가 교육을 받았으며 CMMI의 완성도 높은 수석 평가자로 지정됩니다. 모델 수준 4 또는 5 평가를 원하는 조직은 높은 완성도 수석 평가자와 작업해야 합니다.

증명 정보에서 CMMI 프로세스 영역 내에서 목표 달성을 위해 업무를 수행한 증거를 찾습니다. 프로젝트의 포트폴리오를 실행하고 아마도 여러 사업부를 가진 조직 내에서 복잡한 수식은 범위를 평가해야 하는 프로젝트의 수를 결정하는 데 사용합니다. 이것의 목적은 조직이 필요한 각 프로세스 영역에서 기능을 제도화하는 것을 증명하는 프로젝트의 샘플 집합에 대해 공정한 검사를 하는 것입니다. 리드 평가자는 이 공식을 기반으로 평가할 프로젝트를 결정합니다.

평가 중인 각 프로젝트 내에서 프로세스 영역 내에서 충분한 기능을 표시하는 데 필요한 절차가 완료되었음을 증명하는 증거를 수집해야 합니다. 각 실행 방법에 대해 평가자는 계획, 소스, 코드, 디자인, 아키텍처 문서에 기록되어 있는 인위 결과라 알려진 구체적인 증거를 찾습니다. 또한 이들은 확인을 찾습니다. 확인은 일반적으로 계획 회의 참석에 대해 설명하는 일화 등의 업무를 수행하는 방법에 대한 직원의 이야기 등 전문 증거입니다. 확인은 평가 중인 프로젝트에 참여한 직원을 인터뷰하여 수집됩니다. 확인은 문서의 유효성에 대해 의문을 제기하는 평가자의 주도로 문서 상의 근거를 보완하거나 반박할 수 있습니다.

CMMI 모델을 유용하게 만들기 위해 CMMI를 평가할 필요는 없습니다. CMMI는 소프트웨어 개발 조직이 완성도 기능과 완성도를 이해하고 이를 고객과 기타 외부 이해 관계자의 기대와 비교할 수 있도록 도움을 제공합니다. 조직이 CMMI 모델을 어느 곳에 적용할지 대략적인 개념을 갖는 것은 압박 상황에서의 행동 양식과 기대치를 수행할 수 있는 능력을 평가하는 방법을 제공합니다. 낮은 완성도의 견고한 기반을 갖지 않고 높은 완성도 활동을 수행하는 조직은 대개 예측할 수 없습니다. 높은 완성도 동작이 존재하며 이는 신뢰할 만하지만 이러한 높은 완성도 사례는 견고한 기초에 빌드되지 않으므로 신뢰할 수 없습니다.

CMMI 평가는 조직 차원의 프로세스 개선 이니셔티브의 유효성 검사 방법으로 종종 사용됩니다. 이를 통해 "테스트를 통과하라."는 압력이 발생합니다. 포커스는 각 프로세스 영역의 각 연습이 표시되어 그 증거를 나타내는 증명 중 하나가 됩니다. 고객 기대에 대한 능력 입증과 명시적인 관리 조치를 통한 기능 개선이라는 정말로 중요한 사항에 대해 포커스를 놓칠 수 있습니다. “테스트 통과”에 초점을 맞추면 조직에서 종종 상당한 부작용과 오작동이 발생합니다. 결과적으로 CMMI는 업계에서 강한 비난 세력을 발전시켰습니다. CMMI 모델이 올바르고 조직 내의 관리자에게 유용한 지식을 제공한다고 강하게 확신한다면 이는 유감스러운 일입니다. 이러한 지식은 향상된 기능, 성능 및 개선된 고객 만족도로 이어져야 합니다.

[1] Anderson, David J., 소프트웨어 엔지니어링을 위한 애자일 매니지먼트: 비즈니스 결과에 제약 이론 적용(Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results), Prentice Hall PTR, 2003년

[2] Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

[3] Glazer, Hillel, and Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, November 2008

[4] Humphrey, Watts S., Managing the Software Process, Addison Wesley Professional, 1989

[5] Deming, W. Edwards, The New Economics for Industry, Government, Education, 2nd Edition, The MIT Press, 2000

커뮤니티 추가 항목

추가
표시:
© 2015 Microsoft