능력 성숙도 모델

Capability Maturity Model

능력 성숙도 모델(CMM)은 연구에 자금을 지원한 미국 국방부와 계약한 조직으로부터 수집한 데이터를 연구한 후 1986년에 작성된 개발 모델입니다.'성숙도'라는 용어는 임시방편에서 공식적으로 정의된 단계, 관리 결과 지표, 프로세스의 능동적 최적화까지 프로세스의 형식 및 최적화 정도에 관련되어 있습니다.

이 모델의 목적은 기존 소프트웨어 개발 프로세스를 개선하는 것이지만 다른 프로세스에도 적용할 수 있습니다.

2006년, Carnegie Mellon 대학의 소프트웨어 엔지니어링 연구소는 CMM을 대체하여 일부 [1]단점을 해결하는 Capability Matity Model Integration을 개발했습니다.

개요

능력 성숙도 모델은 원래 계약된 소프트웨어 프로젝트를 구현하기 위한 정부 청부업자의 프로세스의 능력을 객관적으로 평가하기 위한 도구로서 개발되었습니다.이 모델은 IEEE[2] Software에서 처음 설명한 프로세스 성숙도 프레임워크를 기반으로 하며, 이후 1989년 Watts Humphrey의 "Managing the Software Process"에서 기술되었습니다.그것은 나중에 1993년에 보고서에[3] 발표되었고 1995년에 같은 저자들에 의해 책으로 출판되었다.

이 모델은 소프트웨어 개발 분야이지만 일반적으로 비즈니스 프로세스를 지원하는 모델로도 사용되며, 전 세계적으로 관공서, 상업 및 [4][5]산업 분야에서도 광범위하게 사용되고 있습니다.

역사

소프트웨어 프로세스의 선행 요구

1980년대에는 컴퓨터 사용이 더욱 광범위해지고 유연해지고 비용도 절감되었습니다.조직은 컴퓨터화된 정보 시스템을 채택하기 시작했고 소프트웨어 개발에 대한 수요는 크게 증가했습니다.소프트웨어 개발을 위한 많은 프로세스가 초기 단계에 있었으며, 표준 또는 "베스트 프랙티스" 접근법이 거의 정의되지 않았습니다.

그 결과 프로젝트 실패가 일반적이고 컴퓨터 과학 분야는 아직 초기 단계이며 프로젝트 규모와 복잡성에 대한 야망은 계획한 예산 내에서 적절한 제품을 제공할 수 있는 시장 능력을 넘어섰습니다.Edward [6]Yourdon, Larry Constantine, Gerald Weinberg,[7] Tom DeMarco,[8] 그리고 David Parnas와 같은 개인들은 소프트웨어 [4][9]개발 과정을 전문화하기 위해 연구 결과를 포함한 기사와 책을 출판하기 시작했다.

1980년대에 소프트웨어 하청업체와 관련된 여러 미군 프로젝트는 예산을 초과하여 계획보다 훨씬 늦게 완료되었다.왜 이런 일이 일어나는지 알아내기 위해 미 공군은 소프트웨어 엔지니어링 연구소(SEI)의 연구에 자금을 지원했습니다.

전구체

단계적 성숙도 모델을 IT에 처음 적용한 것은 CMU/SEI가 아니라 Richard L. 1973년에 IT조직의 [10]성장모델의 단계를 발표한 Nolan씨.

Watts Humphrey는 [11]IBM에서 27년간 근무한 후반기에 프로세스 성숙도 개념을 개발하기 시작했습니다.

소프트웨어 공학 연구소 개발

1986년 험프리가 IBM에서 은퇴한 후 펜실베니아주 피츠버그의 카네기 멜론 대학에 있는 소프트웨어 엔지니어링 연구소에 입사하면서 미국 국방부 소프트웨어 엔지니어링 연구소(SEI)에 의한 활발한 모델 개발이 시작되었습니다.미 공군의 요청에 따라 그는 계약 체결의 일환으로 미 국방부가 소프트웨어 계약자의 능력을 평가하는 데 도움을 주기 위해 프로세스 성숙도 프레임워크를 공식화하기 시작했습니다.

공군 연구 결과는 군이 소프트웨어 하청업체의 공정 능력 성숙도를 객관적으로 평가하는 모델이었다.Humphrey는 Philip B가 개발한 초기 품질 관리 성숙도 그리드에 기반하고 있습니다. 크로스비는 그의 책 "품질은 자유다"[12]에서.Humphrey의 접근방식은 조직이 프로세스 문제를 특정 순서로 해결함으로써 단계적으로 프로세스를 성숙시킨다는 독특한 통찰력 때문에 달랐습니다.Humphrey는 각각의 개별 개발 프로세스의 성숙도를 개별적으로 측정하는 것이 아니라 조직 내 소프트웨어 개발 관행 시스템의 단계적 진화에 기반을 두고 있습니다.따라서 CMM은 다양한 조직에서 일반적인 비즈니스 프로세스의 성능을 이해하고 개선하기 위한 일반적이고 강력한 도구로 사용되어 왔습니다.

Watts Humphrey의 능력 성숙도 모델(CMM)은 1988년에[13], 1989년에 소프트웨어 프로세스 [14]관리에서 책으로 출판되었습니다.

조직은 원래 소프트웨어 엔지니어링 연구소의 Humphrey와 그의 동료들이 고안한 프로세스 성숙도 설문지와 소프트웨어 능력 평가 방법을 사용하여 평가되었습니다.

기능 성숙도 모델을 5가지 성숙도 수준 각각에서 정의된 프로세스 영역 및 관행 집합으로 완전히 표현하는 것은 1991년에 시작되었으며 버전 1.1은 1993년 [3]1월에 완료되었다.CMM은 1995년 주요 저자인 Mark C에 의해 책으로[15] 출판되었다.폴크, 찰스 5세웨버, 빌 커티스, 메리 베스 크리시스.미국 뉴욕, 미국

능력 성숙도 모델 통합

CMM 모델의 소프트웨어 개발 적용은 때때로 문제가 있었습니다.조직 내 및 조직 전체에 통합되지 않은 여러 모델을 적용하면 교육, 평가 및 개선 활동에 비용이 많이 들 수 있습니다.Compability Matity Model Integration(CMMI) 프로젝트는 소프트웨어 개발 프로세스에 여러 모델을 사용하는 문제를 해결하기 위해 형성되었습니다.따라서 CMMI 모델은 퍼블릭 도메인에서 사용되는 일반적인 이론 프로세스 기능 [16][citation needed][17]모델이지만 CMMI 모델이 CMM 모델을 대체했습니다.

다른 프로세스에 적응

CMM은 원래 계약된 소프트웨어 프로젝트를 수행할 수 있는 정부 청부업자의 능력을 평가하기 위한 도구였습니다.소프트웨어 개발의 영역에서 유래하고 있지만, IS/IT(및 기타) 조직의 프로세스 성숙도(IT 서비스 관리 프로세스 등)의 일반적인 모델로서 지금까지도, 지금까지도, 앞으로도 폭넓게 적용될 수 있습니다.

모델 토픽

성숙도 모델

성숙도 모델은 조직의 행동, 관행 및 프로세스가 얼마나 신뢰할 수 있고 지속적으로 필요한 결과를 도출할 수 있는지를 설명하는 일련의 구조화된 수준으로 볼 수 있습니다.

성숙도 모델은 비교를 위한 벤치마크로, 이해를 돕기 위해 사용할 수 있다. 예를 들어, 비교의 기준으로 사용할 수 있는 공통점이 있는 다른 조직의 비교 평가에 사용할 수 있다.예를 들어 CMM의 경우 비교의 기초는 조직의 소프트웨어 개발 프로세스입니다.

구조.

이 모델에는 다음 5가지 측면이 포함됩니다.

  • 성숙도 레벨: 5레벨의 프로세스 성숙도 연속체.최상위(5번째) 레벨은 프로세스 최적화와 지속적인 프로세스 개선을 조합하여 프로세스를 체계적으로 관리하는 이상적인 상태입니다.
  • 주요 프로세스 영역: 주요 프로세스 영역은 함께 수행함으로써 중요하다고 생각되는 일련의 목표를 달성하는 관련 활동의 클러스터를 식별합니다.
  • 목표: 주요 프로세스 영역의 목표는 해당 핵심 프로세스 영역이 효과적이고 지속적인 방법으로 구현되기 위해 존재해야 하는 상태를 요약합니다.목표를 달성한 정도는 조직이 성숙도 수준에서 얼마나 많은 역량을 구축했는지를 나타내는 지표입니다.목표는 각 주요 프로세스 영역의 범위, 경계 및 의도를 나타냅니다.
  • 공통 기능: 공통 기능에는 주요 프로세스 영역을 구현하고 제도화하는 프랙티스가 포함됩니다.공통 기능에는 5종류가 있습니다.실행 약속, 수행 능력, 수행 활동, 측정 및 분석, 구현 검증입니다.
  • 주요 프랙티스:주요 관행은 지역의 구현 및 제도화에 가장 효과적으로 기여하는 인프라 및 관행의 요소를 설명합니다.

레벨

모델에는 5가지 레벨이 정의되어 있으며 SEI에 따르면 다음과 같습니다.「조직의 소프트웨어 프로세스의 예측 가능성, 효과, 제어는, 조직이 이 5개의 레벨로 올라갈수록 향상한다고 생각됩니다.엄격하지는 않지만, 지금까지의 경험적 증거가 이 믿음을 뒷받침한다."[18]

  1. 초기(혼돈, 애드혹, 개별 영웅) - 신규 또는 문서화되지 않은 반복 프로세스를 사용하기 위한 시작점.
  2. 반복 가능 - 동일한 단계를 반복할 수 있도록 프로세스가 적어도 충분히 문서화되어 있습니다.
  3. 정의 - 프로세스가 표준 비즈니스 프로세스로 정의/확인됨
  4. 능력 - 합의된 메트릭에 따라 프로세스를 정량적으로 관리합니다.
  5. 효율적 - 프로세스 관리에는 의도적인 프로세스 최적화/개선이 포함됩니다.

각 성숙도 수준에는 그 수준을 특징짓는 주요 프로세스 영역이 있으며, 각 영역에는 목표, 약속, 능력, 측정 및 검증의 5가지 요소가 있습니다.이들은 CMM에만 있는 것은 아닙니다.조직이 성숙하기 위해 거쳐야 하는 단계를 나타냅니다.

이 모델은 프로세스 성숙도를 한 수준에서 다음 단계로 점진적으로 개발할 수 있는 이론적 연속체를 제공합니다.수준을 건너뛸 수 없습니다.

레벨 1-초기
이 레벨의 프로세스에서는 (일반적으로) 문서화되어 있지 않고 동적 변경 상태에 있으며 사용자나 이벤트에 의해 임시로 제어되지 않고 반응적으로 구동되는 경향이 있습니다.이는 공정에 혼란스럽거나 불안정한 환경을 제공한다(예: 새로운 수술을 몇 번 수행하는 외과의사 - 음성 결과의 수준은 알 수 없음).
레벨 2-반복 가능
이 성숙도 레벨의 특징은 일부 프로세스가 반복 가능하며 일관된 결과를 얻을 수 있다는 것입니다.프로세스 규율이 엄격할 것 같지는 않지만, 프로세스 규율이 존재하는 경우에는 부하가 높은 기간 동안 기존 프로세스를 유지하는 데 도움이 될 수 있습니다.
레벨 3 - 정의
정의되고 문서화된 일련의 표준 프로세스가 확립되어 있으며 시간이 지남에 따라 어느 정도 개선될 수 있다는 것은 이 수준의 프로세스 특징입니다.이러한 표준 프로세스가 마련되어 있습니다.프로세스가 체계적으로 또는 반복적으로 사용되지 않았을 수 있습니다. 이는 사용자가 역량을 갖추거나 다양한 상황에서 프로세스를 검증하기에 충분합니다.이는 개발 단계로 간주될 수 있으며, 보다 광범위한 조건과 사용자 역량 개발로 프로세스가 다음 단계의 성숙도로 발전할 수 있습니다.
레벨 4 - 관리(대응)
프로세스 메트릭을 사용하여 다양한 운영 조건에 걸쳐 프로세스 목표의 효과적인 달성을 증명할 수 있는 것은 이 수준의 프로세스 특성입니다.여러 환경에서 프로세스의 적합성이 테스트되고 프로세스가 개선 및 조정되었습니다.프로세스 사용자는 프로세스를 여러 가지 다양한 조건에서 경험하여 역량을 입증할 수 있습니다.프로세스 성숙도는 측정 가능한 품질 손실이나 사양 이탈 없이 특정 프로젝트에 적응할 수 있도록 합니다.공정 능력은 이 수준부터 확립됩니다.(예: 의사는 음의 결과가 0에 가까운 상태에서 수백 번 수술을 실시합니다.)
레벨 5 - 최적화(효율적)
이 레벨에서의 프로세스의 특징은 증분 및 혁신적인 기술 변경/개선을 통해 프로세스 성능을 지속적으로 향상시키는 것입니다.성숙도 수준 5에서 공정은 공정 변동의 통계적 공통 원인을 해결하고 공정 성능을 개선하기 위해 공정을 변경하는(예: 공정 성능의 평균을 전환하는) 것과 관련이 있습니다.이는 확립된 양적 프로세스 개선 목표를 달성할 가능성을 유지하는 것과 동시에 이루어질 것이다.

2008년부터 2019년까지 평가의 약 12%가 성숙도 4~[19][20]5등급이었다.

비평

이 모델은 원래 정부 청부업자가 소프트웨어 프로젝트를 수행할 수 있는 능력을 평가하기 위한 것입니다.이러한 목적을 위해 사용되었으며, 이에 적합할 수도 있지만[who?] CMM에 따른 프로세스 성숙도가 반드시 소프트웨어 개발을 성공시키기 위해 필요한 것은 아니라는 지적이 있었습니다.

소프트웨어 프로세스 프레임워크

문서화된 소프트웨어 프로세스 프레임워크는 조직 또는 프로젝트의 주요 프로세스 영역과의 일관성을 평가하고자 하는 사용자를 안내하는 것을 목적으로 합니다.각 성숙도 수준에는 5가지 체크리스트 유형이 있습니다.

유형 묘사
정책. 주요 프로세스 영역에서 권장하는 정책 내용 및 KPA 목표를 설명합니다.
표준. 주요 프로세스 영역에 설명된 특정 작업 제품의 권장 내용을 설명합니다.
과정 주요 프로세스 영역에서 권장하는 프로세스 정보 내용을 설명합니다.이 체크리스트는 다음 항목에 대한 체크리스트로 조정됩니다.
  • 역할, 입력 기준, 입력, 액티비티, 출력, 종료 기준, 리뷰 및 감사, 관리 대상 작업물, 측정, 문서화된 절차, 훈련 및 도구
절차. 주요 프로세스 영역에 설명된 문서화된 절차의 권장 내용을 설명합니다.
레벨의 개요 전체 성숙도 수준의 개요를 제공합니다.이 체크 리스트는, 다음의 체크 리스트로 한층 더 개선되고 있습니다.
  • 주요 프로세스 영역 목적, 목표, 정책 및 표준; 프로세스 설명; 절차; 훈련; 도구; 리뷰 및 감사; 작업 제품; 측정

「 」를 참조해 주세요.

레퍼런스

  1. ^ Nayab, N. (2010-04-27). "The Difference Between CMMI vs CMM". Bright Hub PM. Retrieved 2020-02-15.
  2. ^ Humphrey, W. S. (March 1988). "Characterizing the software process: a maturity framework". IEEE Software. 5 (2): 73–79. doi:10.1109/52.2014. ISSN 0740-7459. S2CID 1008347.
  3. ^ a b Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (February 1993). "Capability Maturity Model for Software (Version 1.1)" (PDF). Technical Report. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. CMU/SEI-93-TR-024 ESC-TR-93-177.
  4. ^ a b McKay, Vivienne. "What is the Capability Maturity Model? (CMM) Process Maturity FAQ". www.selectbs.com. Retrieved 2017-03-20.
  5. ^ White, Sarah K. (2018-03-16). "What is CMMI? A model for optimizing development processes". CIO. Retrieved 2020-06-04.
  6. ^ Yourdon, E. (1989). 1989. Modern Structured Analysis. New York: Prentice Hall. ISBN 978-0135986240.
  7. ^ Weinberg, G. M. (1992). Quality Software Management: Anticipating Change. Vol. 1: Systems Thinking. New York: Dorset House Pub. ISBN 978-0-932633-72-9.
  8. ^ DeMarco, T.; Lister, T. (1997). Waltzing with Bears: Managing Risk on Software Projects. New York: Dorset House Pub. ISBN 978-0-932633-60-6.
  9. ^ "CMMI-Six Sigma, their roots". Process Enhancement Partners, Inc. 2011-01-23. Retrieved 2018-05-11.
  10. ^ Nolan, R. L. (July 1973). "Managing the computer resource: A stage hypothesis". Comm. ACM. 16 (7): 399–405. doi:10.1145/362280.362284. S2CID 14053595.
  11. ^ "People Capability Maturity Model (P-CMM) Version 2.0". resources.sei.cmu.edu. Retrieved 2017-01-17.
  12. ^ Crosby, P. B. (1979). Quality is Free. New York: New American Library. ISBN 0-451-62247-2.
  13. ^ Humphrey, W. S. (March 1988). "Characterizing the software process: A maturity framework" (PDF). IEEE Software. 5 (2): 73–79. doi:10.1109/52.2014. S2CID 1008347.
  14. ^ Humphrey, W. S. (1989). Managing the Software Process. SEI series in software engineering. Reading, Mass.: Addison-Wesley. ISBN 0-201-18095-2.
  15. ^ Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. SEI series in software engineering. Reading, Mass.: Addison-Wesley. ISBN 0-201-54664-7.
  16. ^ Juran (2010-08-26). Juran'S Quality Hb 6E. McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898.
  17. ^ Natarajan, R (2015). Proceedings of the International Conference on Transformations in Engineering Education. Springer.
  18. ^ 이 텍스트의 2001년 사용을 증명하는 미시간주 SDLC 부록은 여기에서 나온 것이 아닙니다.
  19. ^ "CMMI Adoption Trends - 2019 Mid Year Update". CMMI Institute. 2019-10-21.
  20. ^ Fishman, Charles (1996-12-31). "They Write the Right Stuff". Fast Company. Retrieved 2020-02-15.

외부 링크