CMM이란
최근 국무원에서 발표한 "소프트웨어 산업 및 집적 회로 산업 발전 촉진을 위한 여러 정책" 제17조에 따르면 소프트웨어에 대한 CMM 인증은 다음과 같습니다. 수출 지향 기업은 수수료가 적절하게 지원되어야 하는데 CMM이란 무엇입니까? CMM은 역량 성숙도 모델(capabilityMaturityModel)의 약자로, 소프트웨어 계약 역량을 평가하고 소프트웨어 품질 개선에 도움을 주는 방법으로, 소프트웨어 개발 프로세스 관리와 엔지니어링 역량 개선 및 평가에 중점을 두고 있습니다. CMM은 5가지 레벨로 구분됩니다. 레벨 1은 초기 레벨, 레벨 2는 반복 가능한 레벨, 레벨 3은 정의된 레벨, 레벨 4는 관리 레벨, 레벨 5는 최적화 레벨입니다. CMM은 1987년 미국 카네기멜론대학교 소프트웨어공학연구소에서 성공적으로 개발되었습니다. 현재 전 세계에서 가장 대중적이고 실용적인 소프트웨어 생산 프로세스 표준이자 소프트웨어 기업 성숙도 수준 인증 표준입니다. 현재 우리나라에는 CMM 표준 인증을 통과한 소프트웨어 회사가 있습니다.
********************************************* *** *
CMM은 소프트웨어 프로세스 능력 성숙도 모델(Capacity Maturity Model)
그러나 이것은 csdn 매거진 지난호 기사에서 멸시를 받았습니다.
CMM 소개
CMM은 Software Process Capability Maturity Model(Capacity Maturity Model)의 약자로 미국 연방정부 평가를 충족시키기 위해 설립된 카네기멜론대학교 소프트웨어 공학연구소이다. 소프트웨어 공급업체 역량의 요구 사항을 충족하기 위해 우리는 1986년에 모델을 연구하기 시작했으며 1991년에 공식적으로 CMM 버전 1.0을 출시했습니다. CMM은 창립 이래 많은 주목을 받았으며 일부 선진국 및 지역에서 널리 사용되었습니다. 이는 소프트웨어 회사의 소프트웨어 개발 관리 수준을 측정하는 중요한 참조 요소이자 소프트웨어 프로세스 개선을 위한 사실상의 업계 표준이 되었습니다. 미국, 인도, 일본 및 기타 국가의 수십 개 회사가 다양한 수준의 CMM 인증을 통과한 것으로 알려져 있습니다.
1986년 11월 SEI는 미국 연방 정부의 요청에 따라 Miter의 도움을 받아 1987년 9월 소프트웨어 기능 성숙도 프레임워크와 소프트웨어 성숙도 설문지를 개발했습니다. 소프트웨어 공급업체의 기능을 평가하기 위해 . 이는 소프트웨어 프로세스의 성숙도를 탐색하는 데 사용되는 최초의 도구 중 하나입니다.
4년 뒤인 1991년 SEI는 스스로 CMM 성숙도 프레임워크의 실무 경험과 성숙도 설문지 첫 번째 버전을 정리하고, 이를 바탕으로 민간용 CMM 버전 1.0을 출시했다.
CMM 버전 1.0이 사용된 지 2년 후인 1992년 4월 SEI는 약 200명의 숙련된 소프트웨어 전문가가 참석한 가운데 CMM 세미나를 개최했습니다. SEI는 그들의 의견을 충분히 청취한 후 1993년에 CMM1.1 버전을 출시했습니다. 이는 또한 세계에서 가장 인기 있고 일반적인 CMM 버전입니다.
이 작업은 10년 넘게 진행되어 왔습니다. SEI의 원래 계획에 따르면 CMM 개선 버전 2.0은 1997년 11월에 완성되고, 버전 2.0에 대한 실질적인 피드백을 받은 후 준CMM 2.0 버전이 1999년에 완성되어야 한다. 그러나 미 국방부는 SEI에 CMM2.0 버전 출시를 연기하고 보다 시급한 프로젝트인 CMMI를 먼저 완료해 줄 것을 요청했다.
CMMI(Capability Maturity Model Integration)는 능력 성숙도 모델 통합(Capability Maturity Model Integration)입니다. 이는 현재 개발 중인 모든 능력 성숙도 모델을 통합하려는 미 국방부의 아이디어입니다. 프레임으로. 이 프레임워크에는 두 가지 기능이 있습니다. 첫째, 소프트웨어 획득 방법의 개혁, 둘째, 통합 제품 및 프로세스 개발의 관점에서 시작하여 건전한 시스템 개발 원칙을 포함하는 프로세스 개선의 확립입니다.
CMM에 대한 사람들의 연구가 계속 심화됨에 따라 다른 분야에서도 이 시스템의 특성을 기반으로 자체 CMM 모델을 출시했습니다. 예를 들어 인적자원 역량 성숙도 모델, 시스템 엔지니어링 역량 성숙도 모델 등이 있다. 차이점을 보여주기 위해 국내외 많은 자료에서는 CMM SW-CMM이라고 부릅니다.
소프트웨어 프로세스 성숙도 향상은 점진적인 과정이며 이를 보장하기 위해 장기적이고 지속 가능한 개발 프로세스가 필요합니다. 지속적인 프로세스 개선을 위한 기반과 문화를 구축하기 위해 일부 소프트웨어 회사는 많은 에너지와 시간을 소비해야 할 수도 있습니다. 하지만 이런 노력은 어느 소프트웨어 회사에나 매우 필요합니다.
CMM은 현재 소프트웨어 개발에 대한 접근 방식과 소프트웨어 프로세스 기능을 향상시키는 방법을 나타냅니다. 몇 가지 단점이 있지만. 예를 들어, 성숙도 수준, 주요 프로세스 영역, 회사 특성 및 주요 관행은 소프트웨어 산업에서 여전히 심층적인 논의와 수정이 필요하지만 소프트웨어 산업 발전을 위한 좋은 프레임워크를 제공하며 소프트웨어에 중점을 두고 있습니다. 프로세스 기능 개선에 유용한 도구입니다.
우리나라 소프트웨어 기업의 경쟁력을 높이고 국내 소프트웨어 수준을 높이는 것은 중국인들의 공통된 염원이다. 그러나 현재 우리나라 소프트웨어 수준, 특히 소프트웨어 개발능력과 소프트웨어 생산능력은 여전히 매우 열악합니다. 이것은 또한 부인할 수 없는 사실입니다. 그렇다면 우리나라의 소프트웨어 개발 및 생산 능력을 향상시켜 소프트웨어의 전반적인 수준을 향상시키는 방법은 무엇일까요? 이는 소프트웨어 회사가 CMM을 구현하는 효과적인 방법일 수 있습니다.
기업의 소프트웨어 역량은 기업의 프로세스 역량, 특히 소프트웨어 개발 및 생산의 성숙도에 더 많이 의존합니다. 프로세스 능력이 성숙할수록 회사의 소프트웨어 생산 능력은 더욱 보장됩니다. 현재 우리나라의 일부 소프트웨어 회사에서는 CMM을 구현하려고 노력하고 있습니다.
물론 CMM이 만병통치약은 아니며 모든 소프트웨어 회사에 반드시 적합한 것은 아닙니다. CMM을 구현하는 회사에도 실패 사례가 있습니다. 본 칼럼을 통해 더 많은 기업들이 CMM을 이해하고, 하루빨리 자사에 적합한 발전의 길을 찾아 중국 소프트웨어 기업의 경쟁력을 높일 수 있기를 바랍니다.
********************************************* *** ***
그림 그리기: (CMM의 5층 구조도)
---------------
p >/ 최적화 수준 /
/ (5) /
---------------
↑
| 지속적인 개선 과정
---------------
/ 관리 가능 수준 /
/ (4) /
---------------
↑
| 예측 가능한 프로세스
|
------------------
/ 결정된 수준 /
/ (3) /
------------------
↑
| 표준화되고 일관된 프로세스
------------------
/ 반복 가능 레벨 /
/ (2) /
---------------
↑
| 엄격한 프로세스
|
------------------
/ 초기 수준 /
/ (1) /
------------------
* ******* **************************************
CMM은 역량 성숙도(Capability Maturity)를 나타냅니다. 모델은 중국어로 역량 성숙도 모델(Capability Maturity Model)로 번역되며 소프트웨어 엔지니어링 연구에서 중요한 이정표입니다.
CMM에 대한 연구는 1986년 11월부터 시작됐다. 당시 미국 연방정부가 소프트웨어 공급업체의 역량을 평가해야 하는 요구사항을 충족시키기 위해 미국 카네기멜론대학교 소프트웨어공학연구소(SEI)가 주도권을 잡았다. , Mitre Corporation의 도움으로 1년도 채 안 되어 1987년 9월에 역량 성숙도 프레임워크(Capability Maturity Framework)와 성숙도 설문지(Maturity Questionnaire) 세트가 출시되었습니다.
많은 사람들이 이렇게 생각합니다. 이 설문지 세트는 실제로 CMM 모델을 나타내며 소프트웨어 프로세스의 성숙도를 탐색하는 데 사용되는 도구일 뿐입니다. 실제 모델은 4년 후에 나타날 것입니다. SEI는 1987년 이후 성숙도 프레임워크와 첫 번째 버전의 성숙도 설문지의 실제 경험을 요약하고 이를 기반으로 CMM1.0 버전을 출시했습니다. 1991년 출시된 이 CMM1.0은 4년간의 소프트웨어 기업 평가 경험과 광범위한 사용자 피드백을 바탕으로 성숙도 프레임워크를 기반으로 사용 가능한 모델을 구축했으며, 이 모델은 소프트웨어 기업이 프로세스 개선 계획을 수립하고 구현하는 데 보다 효과적으로 도움을 줄 수 있습니다.
CMM 버전 1.0을 사용한 지 2년 후인 1992년 4월 약 200명의 숙련된 소프트웨어 전문가가 참석한 가운데 세미나가 열렸습니다. SEI는 피드백을 광범위하게 청취한 후 1993년에 CMM 버전 1.1을 출시했습니다. 최근 몇 년 동안 CMM은 버전 2.0을 출시하고 동시에 ISO/IEC15504 또는 SPICE라고 하는 ISO 시스템에 진입했으며 1995년부터 SPICE가 현장 테스트 단계에 진입했으며 2001년에 출시될 수 있습니다.
CMM은 소프트웨어 개발 프로세스의 관리와 엔지니어링 역량의 개선 및 평가에 전념하고 있습니다. 이 모델은 미국과 북미에서 널리 사용되었으며 유럽, 아시아 및 기타 국가의 점점 더 많은 대형 정보 기술 회사에서 채택되고 있습니다. 실제로 소프트웨어 개발 프로세스 개선 및 평가를 위한 사실상의 산업 표준이 되었습니다. .
CMM은 소프트웨어 프로세스의 성숙도를 5단계로 구분합니다. 다음은 소프트웨어 조직의 5단계 특징입니다.
(1) 초기 단계(초기) 작업이 무질서합니다. 프로젝트 과정에서 원래 계획이 포기되는 경우가 많습니다. 관리가 체계적이지 않고 건전한 관리 시스템이 부족합니다. 개발 프로젝트의 결과는 불안정합니다. 우수한 관리자의 관리 방법은 효과적일 수 있지만 일단 떠나면 작업 순서는 개인의 능력과 행동에 따라 완전히 달라집니다.
(2) 반복가능수준(Repeatable) 관리가 제도화되어 기본적인 관리체계와 절차가 확립되어 있으며, 관리업무에 따라야 할 규칙이 있다. 표준화는 초기에 달성되었으며 개발 작업에서 표준이 잘 구현되었습니다. 변경은 법률에 따라 이루어지며 기준이 적용됩니다. 안정적이고 추적 가능한 새로운 프로젝트의 계획 및 관리는 과거의 실제 경험을 바탕으로 하며 이전의 성공적인 프로젝트를 반복할 수 있는 환경과 조건을 갖추고 있습니다.
(3) 기술 작업 및 관리 작업을 포함하여 정의된 개발 프로세스가 표준화되고 문서화되었습니다. 완전한 교육 시스템과 전문가 검토 시스템이 구축되어 있습니다. 진행 중인 프로젝트의 프로세스, 위치 및 책임에 대한 공통된 이해가 있습니다.
(4) 관리되는 제품과 프로세스는 정량적 품질 목표를 확립했습니다. 프로세스 내 활동의 생산성과 품질을 측정할 수 있습니다. 프로세스 데이터베이스가 구축되었습니다. 프로젝트 제품 및 프로세스에 대한 통제가 달성되었습니다. 편차와 같은 프로세스 및 제품 품질 추세를 적시에 예측하고 수정할 수 있습니다.
(5) 최적화 수준은 프로세스 개선에 집중하고 새로운 기술과 방법을 채택할 수 있습니다. 결함을 예방하고, 취약한 부분을 파악하여 개선할 수 있는 수단을 갖습니다. 프로세스의 효율성에 대한 통계 데이터를 얻고 분석하여 최상의 접근 방식을 찾을 수 있습니다.
소프트웨어 대국인 인도는 소프트웨어 개발 프로세스 관리와 관련 이론 및 표준 개발을 매우 중요하게 여긴다.
통계에 따르면 인도의 2,000개 이상의 소프트웨어 회사 중 75개 소프트웨어 회사가 ISO9000 인증을 통과했으며 60개 이상의 소프트웨어 회사가 CMM 인증을 통과했습니다. 그 중 1개는 CMM 레벨 5에 도달했고 3개는 레벨 4에 도달했으며 4개는 CMM 인증을 통과했습니다. 레벨 3에 도달했습니다.
CMM과 ISO9000의 주요 차이점은 다음과 같습니다.
1. CMM은 특히 소프트웨어 제품 개발 및 서비스를 목표로 하는 반면 ISO9000은 훨씬 더 넓은 범위를 갖습니다.
2.CMM은 소프트웨어 개발 프로세스의 성숙도, 즉 프로세스의 지속적인 개선과 개선을 강조하는 반면 ISO9000은 허용 가능한 품질 시스템의 최소 표준만을 설명합니다.
3. CMM 레벨 3의 적용 범위는 ISO9000의 적용 범위보다 넓습니다.
CMM 도입의 중요성:
1. p>
소프트웨어 개발 관리 역량 향상: CMM은 소프트웨어 기업에 자체 평가 방법 및 자기 개선 방법을 제공합니다.
소프트웨어 생산성 향상
소프트웨어 생산의 국제 경쟁력 강화< /p >
2. 소프트웨어 프로젝트 아웃소싱 부서 및 소프트웨어 사용자의 경우:
소프트웨어 개발자의 개발 및 관리 수준을 평가하는 수단을 제공하며 이는 소프트웨어 개발 프로젝트의 위험 식별에 도움이 됩니다.
********************************************* *** ****
사람들이 CMM에 대한 연구를 계속 심화함에 따라 다른 분야에서도 이 시스템의 특성을 기반으로 자체 CMM 모델을 출시했습니다. 예를 들어 인적자원 역량 성숙도 모델, 시스템 엔지니어링 역량 성숙도 모델 등:
(1) SW-CMM(소프트웨어 CMM) 소프트웨어 CMM
(2) SE-CMM (시스템 엔지니어링 CMM) 시스템 엔지니어링 CMM
(3) SA-CMM(소프트웨어 획득 CMM) 소프트웨어 획득 CMM
(4) IPT-CMM(통합 제품 팀 CMM) 통합 제품 그룹 CMM
(5) P-CMM(People CMM) 인사역량 성숙도 모델
이를 구별하기 위해 국내외 많은 자료에서 CMM SW-CMM이라고 부르고 있다. SEI의 원래 계획에 따르면 CMM 개선 버전 2.0은 1997년 11월에 완성되고, 버전 2.0에 대한 실질적인 피드백을 받은 후 준CMM 2.0 버전이 1999년에 완성되어야 한다. 그러나 미 국방부는 SEI에 CMM2.0 버전 출시를 연기하고 보다 시급한 프로젝트인 CMMI를 먼저 완료해 줄 것을 요청했다.
CMMI(Capability Maturity Model Integration)는 능력 성숙도 통합 모델(Capability Maturity Integration Model)이며, 이는 현재 개발될 다양한 능력 성숙도 모델을 모두 통합하려는 미국 국방부의 아이디어이기도 합니다. . 이 프레임워크에는 두 가지 기능이 있습니다. 첫째, 소프트웨어 조달 방식의 개혁, 둘째, 통합 제품 및 프로세스 개발의 관점에서 시작하여 건전한 시스템 개발 원칙을 포함하는 프로세스 개선을 확립하는 것입니다. 소프트웨어에 관한 한 CMMI는 SW-CMM의 개정판입니다. SW-CMM 2.0 버전 C 초안과 SPA의 보다 합리적이고 과학적이고 철저한 장점을 통합합니다. SEI는 CMMI-SE/SW 버전 1.0을 출시했을 때 CMM에서 CMMI로의 전환을 완료하는 데 약 2년이 걸릴 것이라고 발표했습니다.
CMMI 프로젝트는 업계 및 정부 부서에 통합 제품 세트를 제공합니다. 주요 목적은 서로 다른 모델 간의 불일치와 중복을 제거하고 모델 기반 개선 비용을 줄이는 것입니다.
CMMI는 조직이 소프트웨어 프로세스를 개선하고 제품 및 서비스의 개발, 획득 및 유지 관리 기능을 향상하도록 안내하기 위해 보다 체계적이고 일관된 프레임워크를 사용할 것입니다.
**************** **** *****************************
CMM 개발 과정
1984년 미국 국방부는 조달 위험을 줄이기 위해 카네기 멜론 대학의 소프트웨어 공학 연구소(SEI)에 SEI SW-CMM이라고도 알려진 소프트웨어 프로세스 개선 및 평가 모델 개발을 의뢰했습니다. 이 모델은 1991년에 공식적으로 출시되었으며 대다수의 소프트웨어 회사와 고객으로부터 빠르게 인식되었습니다. 1987년 SEI가 출시한 SW-CMM 프레임워크를 시작으로 1991년 CMM 버전 1.0, 1993년 CMM 버전 1.1, 2000년 CMMI-SE/SW 버전 1.0이 출시됐다. 우리나라도 2001년 4월에 "SJ/T 11234-2001 소프트웨어 프로세스 능력 평가 모델"과 "SJ/T 11235-2001 소프트웨어 능력 성숙도 모델"이라는 두 가지 표준을 발표했습니다. 우리 정부는 2000년 6월 국무원에서 발표한 "문서 18호" 제5장 17조에서 소프트웨어 수출 지향 기업의 통과를 장려해야 한다고 항상 소프트웨어 산업의 표준화와 발전을 중시해 왔습니다. ISO9000 시리즈 품질 보증 시스템 인증 및 CMM 인증 비용은 중앙 대외 무역 발전 기금을 통해 적절하게 지원됩니다. 현재 모든 성, 시, 첨단기술지구, 소프트웨어단지는 CMM을 통과한 기업에 금전적 보상을 제공하는 시스템을 갖추고 있다.
********************************************* *** ***
CMM의 의미와 역할
CMM은 Capability Maturity Model for Software의 약자로 중국어로 "Software Capability Maturity Model"이라고 합니다. 조직의 소프트웨어 프로세스 기능에 대한 설명입니다. CMM의 핵심은 소프트웨어 개발을 프로세스로 간주하고 이 원칙을 기반으로 소프트웨어 개발 및 유지 관리에 대한 프로세스 모니터링과 연구를 수행하여 이를 보다 과학적이고 표준화함으로써 기업이 비즈니스 목표를 더 잘 달성할 수 있도록 하는 것입니다. 소프트웨어 프로세스 개발 관리와 소프트웨어 엔지니어링 역량의 개선 및 평가에 중점을 두고 있습니다. 따라서 CMM은 소프트웨어 계약자의 역량을 평가하고 조직이 소프트웨어 프로세스 품질을 향상시키는 데 사용됩니다. 현재 가장 인기 있고 실용적인 소프트웨어 프로세스 개선입니다. 모델은 오늘날 대규모 소프트웨어 제작에 종사하는 기업에게 없어서는 안 될 콘텐츠가 되었습니다. CMM의 목적은 소프트웨어 회사가 소프트웨어 엔지니어링 프로세스를 관리 및 개선하고 개발 및 개선 기능을 향상시켜 시간과 예산 내에서 고품질 소프트웨어를 개발할 수 있도록 돕는 것입니다. CMM 모델의 기업 구현 및 평가는 기업에 다음과 같은 이점을 가져올 수 있습니다. 소프트웨어 개발 관리 기능을 향상하도록 소프트웨어 계약자 및 구매자의 위험을 줄입니다. 소프트웨어의 프로세스 및 핵심 관행은 소프트웨어 회사가 CMM의 더 높은 성숙도 수준에 도달하는 데 필요한 핵심 관행을 식별하여 소프트웨어 회사의 국제 경쟁력을 높이는 데 도움이 됩니다.
********************************************* *** ***
CMM의 핵심은 무엇인가요? 이는 소프트웨어 엔지니어링 및 프로세스 개선에 관심이 있는 사람들 사이에서 오랫동안 존재해 온 질문입니다. 저는 이 문제를 생생하고 간단하게 설명하기 위해 CMM 교육 중에 사례를 준비했습니다. 여기에서 여러분과 더 많은 질문을 하실 수 있기를 바랍니다. 재인쇄를 원하시면 JennyLi@netease.com으로 이메일을 보내주세요. 감사합니다. 사례 배경: 집에 사람이 몇 개 있고, 컵과 주전자, 물을 끓이는 기구 등이 있는데, 모두가 끓인 물을 마셔야 합니다.
CMM 레벨 1: 프로세스: 물을 마실 컵과 주전자를 찾습니다. 문제: 컵을 찾을 수 없고 마실 물이 없습니다. 주전자를 찾을 수 없고 마실 물이 없습니다. 주전자에 물이 없습니다. 무엇을 해야 할지 모르겠습니다. 하루에 물을 얼마나 마셔야 할까요? 물 한 잔을 따르는 데 시간이 얼마나 걸리나요? 모두가 매일 물을 따르는 데 얼마나 많은 시간을 소비합니까? 정수기를 구입하면 문제가 해결될 수 있나요? CMM 레벨 2: 프로세스: 컵을 커피 테이블 위에 올려 놓습니다. 주전자에 물이 없으면 주방에서 물을 끓인 후 커피 테이블 위에 다시 놓습니다. 훈련: 부엌에서 물을 끓이고, 컵을 청소하십시오. 하루에 몇 개의 냄비를 끓여야 하는지 측정하십시오. 물, 각 사람이 매일 물을 붓는 데 시간이 얼마나 걸립니까? 컵을 사용한 후 식탁으로 돌려보내기.관리자는 이러한 활동의 실행 상태와 효율성에 주의를 기울입니다.문제:물을 끓이는 데 너무 많은 시간이 걸립니다.물이 차가울 때 마시는 물의 효율성. 불안정합니다. 매일 20분 동안 물을 붓는 사람도 있고, 80분 동안 생각하는 사람도 있습니다. 정수기를 구입하는 것이 도움이 될까요? CMM 레벨 3: 과정: 먼저 모든 사람이 커피 테이블에서 컵을 들고 식탁으로 가서 물을 붓습니다. 큰 컵을 사용하여 한 번에 두 컵씩 물을 붓고 다른 사람들과 공유합니다. 정기적으로 물을 끓여 차가운 주전자에 담을 사람. 정기적으로 컵을 수거하고 청소하는 방법 질문: 어떻게 하면 더 잘할 수 있습니까? 생각하기: 정수기를 구입하는 것이 비용 효율적인가요? CMM 레벨 4: 프로세스: 평가 모델 수립: 1분 절약 = 1위안 절약 각 사람이 하루에 1분을 절약하면 100명이 1개월(30일)에 3,000위안을 절약할 수 있습니다. 3,000위안을 초과하면 정량적 관리 목표를 정의하기 위한 새로운 프로세스를 시도할 수 있습니다. 즉, 3개월 이내에 1인당 매일 물을 붓는 데 소요되는 시간을 2분으로 줄입니다. 오늘 1인당 매일 물을 붓는 데 소요되는 시간을 기준으로 기준선을 설정합니다. 평균 10분, 최소 5분, 최대 20분. 각 사람은 자신을 위해 평균보다 나은 목표를 설정합니다. 매일 물을 붓는 데 6분을 넘지 않습니다. 측정하고 모니터링합니다. 6분을 초과하면 근본 원인을 분석하고 조정 조치를 공식화합니다. 최종 결과는 8분으로 미리 정해진 목표를 초과하지만 3개월 후에는 기준을 조정합니다. 평균 8분, 최소 4분. 분, 최대 15분 문제: 개선 없이는 작동하지 않습니다! 생각: 정수기를 구입하는 것이 최선의 해결책일까요? CMM 레벨 5: 프로세스: 문제의 근본 원인 발견: 물을 붓는 시간을 줄일 수 없는 이유는 방이 너무 크고, 식탁까지 걸어가는 것이 너무 멀기 때문입니다. 근본 원인을 파악하고 평가 모델을 활용하여 A 방법을 평가 및 선정하고 개선 목표를 설정합니다. 정수기 10개를 구입하여 거실에 설치하면 하루 1인당 2분씩 절약됩니다. 해당 프로세스 개발: 물을 구입하는 경우. 정기적으로 생수를 주문하고 정수기의 배출구를 정기적으로 확인해야 합니다. 청소 및 소독을 수행하고 제때에 빈 물통을 교체하도록 요청하십시오. 시범 과정: 몇 사람을 찾아 시험해 보십시오. 촉진: 모든 사람이 정수기를 사용하여 다른 근본 원인을 계속 발견하도록 하십시오... 질문: 더 많은 근본 원인을 발견하는 방법 더 많은 새로운 사고 방식을 도입하는 방법: 물보다 더 좋은 방법이 있습니까? 냉각기?
비유 2:
레벨 1: 훈련도 없고 경험도 없는 사람들이 물에 들어간 후 떠다니는 사람도 있고 가라앉는 사람도 있습니다. 이것이 첫 번째 수준의 무질서이고 그 결과는 두 번째 수준의 미지입니다. 모든 사람이 수영장이나 작은 연못에 여러 번 들어가 본 적이 있으며 기본적으로 그러한 조건에서는 아무 일도 일어나지 않습니다. 하지만 개가 할퀴는 것과 이름을 알 수 없는 움직임 등 움직임이 지저분하다. 즉, 레벨 2는 이전의 성공적인 경험을 반복할 수 있습니다. 레벨 3: 연구 후에 몇 가지 표준 수영 스타일이 결정되었으며 자유형이 가장 빠르고 평영이 가장 노동 집약적이라는 것이 알려져 있습니다. 이것이 레벨 3입니다. 표준 프로세스를 통해 레벨 4가 정의됩니다. 모든 사람이 표준 동작을 숙달한 후 결과를 서로 비교할 수 있습니다. 모든 사람의 수영 실력(물론 서로 다른 수영 스타일의 결과는 분리되어야 함), 근력 등을 측정하고 특히 좋은 결과와 나쁜 결과를 분석하고 좋은 결과와 나쁜 결과의 이유를 찾아냄으로써 모든 사람의 기술 수준이 지속적으로 향상됩니다. . 이것은 정량적 통제의 네 번째 수준으로, 데이터를 사용하여 관리하고 개선하는 다섯 번째 수준입니다. 모든 사람의 기술 수준이 매우 높고 움직임이 완벽합니다. 우리는 새로운 수영 스타일을 창조하고, 새로운 수영복과 기타 혁신을 도입함으로써 경기력을 향상시킵니다.
이것이 다섯 번째 수준의 지속적인 개선입니다.
**************************************** * **********
CMM의 구조
SW-CMM은 소프트웨어 회사의 프로세스 역량에 대한 단계별 진화 프레임워크를 제공합니다. 단계는 레벨 5입니다. . 첫 번째 수준은 실제로 시작점입니다. CMM에 따라 질적 발전을 준비하는 모든 기업은 일반적으로 이 시작점에 있으며 이 시작점을 통해 두 번째 수준으로 이동합니다. 첫 번째 수준을 제외하고 각 수준에는 일련의 목표가 있습니다. 이 목표 집합이 달성되면 해당 성숙도 수준에 도달했으며 다음 수준으로 이동할 수 있음을 나타냅니다. CMM 시스템은 두 번째 수준부터 시작하는 각각의 낮은 수준 구현이 더 높은 수준 구현의 기초이기 때문에 수준 간 진화를 옹호하지 않습니다.
SW-CMM은 단계별 진화 프레임워크를 제공합니다
1. 초기 수준 초기 수준의 소프트웨어 프로세스는 정의되지 않은 무작위 프로세스이며 프로젝트 실행은 무작위이거나 심지어 혼란스럽습니다. . 아마도 일부 회사에서는 일부 소프트웨어 엔지니어링 사양을 개발했지만 이러한 사양이 기본 핵심 프로세스 요구 사항을 충족하지 못하고 정책, 리소스 등으로 구현이 보장되지 않는 경우 여전히 초기 수준으로 간주됩니다.
2. 레벨 조정 가능 수년간의 경험과 교훈을 바탕으로 사람들은 소프트웨어 개발의 주요 문제는 기술적인 문제가 아니라 관리 문제라는 결론을 내렸습니다. 따라서 두 번째 수준의 초점은 소프트웨어 관리 프로세스에 있습니다. 관리 가능한 프로세스는 확장 가능한 프로세스이며, 확장 가능한 프로세스는 점차적으로 발전하고 성숙해질 수 있습니다. 2단계 관리 프로세스에는 수요 관리, 프로젝트 관리, 품질 관리, 구성 관리, 하도급 관리 등 5가지 측면이 포함됩니다. 프로젝트 관리는 계획 프로세스와 추적 및 모니터링 프로세스의 두 가지 프로세스로 구분됩니다. 이러한 프로세스를 구현함으로써 관리 관점에서는 계획대로 실행되고 제어 가능한 단계를 갖춘 소프트웨어 개발 프로세스를 볼 수 있습니다.
3. 정의 수준 두 번째 수준에서는 관리의 기본 프로세스만 정의하고 실행 단계 기준은 정의하지 않습니다. 세 번째 수준에서는 전사적 엔지니어링 표준이 개발되어야 하며 관리 및 엔지니어링 개발 모두 문서화된 표준 세트가 필요하며 이러한 표준은 엔터프라이즈 소프트웨어 개발 표준 프로세스에 통합됩니다. 개발된 모든 프로젝트는 이 표준 프로세스에 따라 프로젝트 프로세스를 맞춤화하고 이러한 프로세스를 실행해야 합니다. 프로세스 조정은 임의적이지 않으며 사용하기 전에 기업 관련 담당자의 승인을 받아야 합니다.
4. 관리 수준 관리의 네 번째 수준은 정량적 관리입니다. 모든 프로세스는 상응하는 측정 방법을 확립해야 하며, 모든 제품(작업 제품 및 사용자에게 제출된 제품 포함)의 품질에는 명확한 측정 지표가 있어야 합니다. 이러한 측정은 상세해야 하며 소프트웨어 프로세스와 제품을 이해하고 제어하는 데 사용될 수 있습니다. 정량적 제어는 소프트웨어 개발을 실제로 산업 생산 활동으로 전환시킵니다.
5. 최적화 수준 다섯 번째 수준의 목표는 지속적인 개선 상태에 도달하는 것입니다. 소위 지속적인 개선이란 프로세스 실행에서 얻은 피드백 정보를 기반으로 다음 실행 단계, 즉 실행 단계를 최적화할 수 있음을 의미합니다. 기업이 이 수준에 도달하면 기업은 실제 프로젝트 성격, 기술 및 기타 요소를 기반으로 최고의 성과를 달성하기 위해 소프트웨어 생산 프로세스를 지속적으로 조정할 수 있음을 의미합니다.
효과 측면에서 보면 위에서 언급한 여러 단계에서 소프트웨어 개발 및 생산의 성숙도가 소프트웨어 회사에 완전히 다른 효과를 가져왔습니다. 1단계부터 5단계까지, 소프트웨어 개발 및 생산의 계획 정확도는 점점 높아지고, 각 단위 프로젝트의 생산 주기는 점점 짧아지고, 각 단위 프로젝트의 비용은 점점 낮아지고 있습니다.
핵심 프로세스 영역(KPA)
첫 번째 레벨을 제외하고 SW-CMM의 각 레벨은 완전히 동일한 구조로 구성됩니다. 각 수준에는 이 수준의 목표를 달성하기 위한 여러 핵심 프로세스 영역(KPA)이 포함되어 있습니다. 또한 각 KPA에는 여러 핵심 구현 활동(KP)이 포함되어 있으며, 각 KPA의 구현 활동은 5가지 회사 속성에 따라 통합됩니다. 즉, 각 KPA에는 5가지 유형의 KP가 포함되어 있습니다.
1. 목표 각 KPA는 일련의 목표를 결정합니다. 모든 프로젝트에서 이러한 목표를 달성할 수 있다면 이는 회사가 KPA의 요구 사항을 충족했음을 의미합니다.
한 수준에 대한 모든 KPA 요구 사항이 충족되면 해당 수준에 필요한 기능이 달성되었음을 나타냅니다.
2. 이행 보증 이행 보증은 기업이 해당 KPA를 수립하고 이행하기 위해 수행해야 하는 활동이며, 이러한 활동에는 주로 전사적 정책 수립과 최고 경영진의 책임이 포함됩니다.
3. 구현 능력 구현 능력은 기업이 KPA를 구현하기 위한 전제 조건입니다. 기업은 조치를 취해야 하며 이러한 조건을 충족한 후에만 인민군 집행 활동을 수행할 수 있습니다. 구현 능력에는 일반적으로 자원 확보, 인력 교육 등이 포함됩니다.
4. 실행 활동 실행 프로세스에서는 KPA를 실행하는 데 필요한 역할과 단계를 설명합니다. 기업의 5가지 속성 중 실행활동은 프로젝트 수행과 관련된 유일한 속성이고, 나머지 4가지 속성은 전사적 CMM 역량 인프라 구축과 관련된다. 실행 활동에는 일반적으로 계획, 작업 실행, 작업 실행 추적 등이 포함됩니다.
5. 지표 분석 지표 분석은 프로세스의 측정 및 측정 분석 요구 사항을 설명합니다. 메트릭 및 메트릭 분석에 대한 일반적인 요구 사항은 실행 활동의 상태와 실행 활동의 효율성을 결정하는 것입니다.
6. 구현 검증 구현 검증은 실행 활동이 확립된 프로세스와 일치하는지 확인하는 것입니다. 구현 검증에는 경영 검토, 감사, 품질 보증 활동이 포함됩니다.
CMM 구현 시 기업 소프트웨어 프로세스의 다양한 문제 정도에 따라 KPA 구현 순서를 결정할 수 있으며, 그런 다음 결정된 순서에 따라 해당 프로세스를 점진적으로 구축하여 구현할 수 있습니다. 특정 KPA를 실행하면 대상 그룹도 점차적으로 만족될 수 있습니다. 프로세스 발전과 점진적인 성숙은 CMM 시스템의 목적입니다.