CMMI-퀵 가이드

프로세스 개선은 지속적인 개선입니다. 우리는 완벽에 도달 할 수 없습니다. 이 튜토리얼에서는 지속적으로 발전하고 개선하는 모델 인 CMM을 배우고 항상 더 나은 일에 초점을 맞 춥니 다. 우리의 범위는 항상 우리의 손아귀를 넘어야합니다.

CMM이란 무엇입니까?

  • CMM은 C능력 M만기 Model.

  • 다양한 지식 기관의 필수 관행 및 프로세스 요소에 중점을 둡니다.

  • 근본적인 새로운 접근 방식이 아닌 상식, 효율적이고 입증 된 비즈니스 수행 방법 (이미 수행해야 함)을 설명합니다.

  • CMM은 조직의 소프트웨어 개발 프로세스의 성숙도를 평가하고 측정하는 방법입니다.

  • CMM은 소프트웨어 개발 프로세스의 성숙도를 1 ~ 5의 척도로 측정합니다.

  • CMM v1.0은 미국 피츠버그에있는 Carnegie Mellon University의 Software Engineering Institute (SEI)에서 개발했습니다.

  • CMM은 원래 소프트웨어 개발 및 유지 관리를 위해 개발되었지만 나중에는-

    • 시스템 공학

    • 공급 업체 소싱

    • 통합 제품 및 프로세스 개발

    • 사람들 CMM

    • 소프트웨어 획득

CMM 예

  • People CMM − 프로젝트 인재를 개발, 동기 부여 및 유지합니다.

  • 소프트웨어 CMM-소프트웨어 중심의 개발 및 유지 관리 기능을 향상시킵니다.

성숙도는 무엇입니까?

정의는 다양하지만 성숙한 프로세스는 일반적으로 다음과 같이 생각됩니다.

  • Well-defined,

  • Repeatable,

  • Measured,

  • Analyzed,

  • 개선 및

  • Effective.

형편 없지만 성숙한 프로세스는 전혀 성숙하지 않은 것만큼이나 나쁩니다!

CMM은 일련의 관행을 정의하고이를 개선하기위한 일반적인 프레임 워크를 제공하여 성숙도 문제를 해결하는 데 도움을줍니다. CMM의 초점은 규율 된 소프트웨어 프로세스를 구성 할 수있는 핵심 프로세스 영역과 모범 사례를 식별하는 데 있습니다.

미성숙 vs 성숙한 조직

미성숙 한 조직은 다음과 같은 특성을 갖습니다.

  • 프로젝트 기간 동안 즉석에서 처리

  • 무시되는 승인 된 프로세스

  • 사전 대응이 아닌 대응

  • 비현실적인 예산 및 일정

  • 일정을 위해 희생 된 품질

  • 객관적인 품질 측정 없음

대조적으로 성숙한 조직의 특성은 다음과 같습니다.

  • 그룹 간 커뮤니케이션 및 조정

  • 계획대로 수행 한 작업

  • 프로세스와 일치하는 관행

  • 필요에 따라 업데이트 된 프로세스

  • 잘 정의 된 역할 / 책임

  • 경영진은 공식적으로 커밋합니다.

CMMI는 무엇입니까?

CMM 통합 프로젝트는 여러 CMM 사용 문제를 해결하기 위해 구성되었습니다. CMMI 제품 팀의 임무는Source Models전사적 프로세스 개선을 추구하는 조직을위한 단일 개선 프레임 워크로. 이 세 가지 소스 모델은-

  • 소프트웨어 용 기능 성숙도 모델 (SW-CMM)-v2.0 초안 C.

  • EIA / IS (Electronic Industries Alliance Interim Standard)-731 시스템 엔지니어링.

  • 통합 제품 개발 기능 성숙도 모델 (IPD-CMM) v0.98.

CMM Integration

  • 통합 모델의 초기 세트를 빌드합니다.

  • 학습 한 내용을 기반으로 소스 모델의 모범 사례를 개선합니다.

  • 미래 모델의 통합을 가능하게하는 프레임 워크를 설정합니다.

CMM과 CMMI의 차이점

CMM은 Systems Engineering CMM, Software CMM, People CMM, Software Acquisition CMM 등과 같은 특정 분야의 성숙한 관행에 대한 참조 모델이지만 필요할 때 통합하기가 어려웠습니다.

CMMI는 CMM의 후속 제품이며보다 성숙한 지침 세트로 발전했으며 CMM (Software CMM, People CMM 등)의 개별 분야의 최고의 구성 요소를 결합하여 구축되었습니다. 제품 제조, 인력 관리, 소프트웨어 개발 등에 적용 할 수 있습니다.

CMM은 소프트웨어 엔지니어링에 대해서만 설명하며 CMM Integrated는 소프트웨어와 시스템 엔지니어링을 모두 설명합니다. CMMI는 또한 통합 프로세스 및 제품 개발과 공급 업체 소싱을 통합합니다.

CMMI 및 비즈니스 목표

CMMI의 목표는 매우 분명합니다. 그들은 다음과 같습니다-

  • Produce quality products or services− CMMI 모델의 프로세스 개선 개념은 Deming, Juran 및 Crosby 품질 패러다임에서 발전했습니다. 품질 제품은 품질 프로세스의 결과입니다. CMMI는 요구 사항 관리, 품질 보증, 검증 및 검증을 포함한 품질 관련 활동에 중점을 둡니다.

  • Create value for the stockholders− 성숙한 조직은 성숙도가 낮은 조직보다 비용 및 수익을 더 잘 추정 한 다음 이러한 추정치에 따라 수행합니다. CMMI는 품질 제품, 예측 가능한 일정 및 효과적인 측정을 지원하여 정확하고 방어 가능한 예측을하는 경영진을 지원합니다. 이러한 프로세스 성숙도는 투자자의 눈에 조직의 가치를 약화시킬 수있는 프로젝트 성능 문제를 방지 할 수 있습니다.

  • Enhance customer satisfaction− 고객의 요구에 따라 검증 된 고품질 제품으로 비용 및 일정 목표를 달성하는 것은 고객 만족을위한 좋은 공식입니다. CMMI는 계획, 모니터링 및 측정에 중점을두고보다 유능한 프로세스와 함께 제공되는 향상된 예측 가능성을 통해 이러한 모든 요소를 ​​해결합니다.

  • Increase market share− 시장 점유율은 양질의 제품 및 서비스, 이름 식별, 가격 및 이미지를 포함한 여러 요인의 결과입니다. 고객은 약속을 지키는 것으로 평판이 좋은 공급 업체와 거래하는 것을 좋아합니다.

  • Gain an industry-wide recognition for excellence− 우수성에 대한 명성을 쌓는 가장 좋은 방법은 프로젝트를 일관되게 잘 수행하고 비용 및 일정 매개 변수 내에서 양질의 제품과 서비스를 제공하는 것입니다. CMMI 요구 사항을 준수하는 프로세스를 보유하면 평판을 높일 수 있습니다.

CMM 통합은 여러 분야 / 지식 본문을 통합 한 모델입니다. 현재 CMMI 모델을 선택할 때 사용할 수있는 4 가지 지식이 있습니다.

시스템 공학

시스템 엔지니어링은 소프트웨어를 포함하거나 포함하지 않을 수있는 완전한 시스템의 개발을 포함합니다. 시스템 엔지니어는 고객의 요구, 기대 및 제약을 제품 솔루션으로 전환하고 제품의 전체 라이프 사이클 동안 이러한 제품 솔루션을 지원하는 데 중점을 둡니다.

소프트웨어 공학

소프트웨어 엔지니어링은 소프트웨어 시스템 개발을 다룹니다. 소프트웨어 엔지니어는 소프트웨어의 개발, 운영 및 유지 관리에 대한 체계적이고 규율 적이며 정량화 가능한 접근 방식을 적용하는 데 중점을 둡니다.

통합 제품 및 프로세스 개발

IPPD (Integrated Product and Process Development)는 고객의 요구, 기대 및 요구 사항을 더 잘 충족시키기 위해 제품 수명 동안 관련 이해 관계자들의 적시 협력을 달성하는 체계적인 접근 방식입니다. IPPD 접근 방식을 지원하는 프로세스는 조직의 다른 프로세스와 통합됩니다.

프로젝트 또는 조직이 IPPD를 선택하면 제품 생산에 사용되는 다른 모범 사례 (예 : 시스템 엔지니어링 관련)와 동시에 IPPD 모범 사례를 수행합니다. 즉, 조직이나 프로젝트에서 IPPD를 사용하려는 경우 IPPD 외에 하나 이상의 분야를 선택해야합니다.

공급 업체 소싱

작업 노력이 더 복잡 해짐에 따라 프로젝트 관리자는 공급자를 사용하여 기능을 수행하거나 프로젝트에 특별히 필요한 제품에 수정을 추가 할 수 있습니다. 이러한 활동이 중요 할 때 프로젝트는 향상된 소스 분석과 제품 인도 전에 공급 업체 활동 모니터링을 통해 이점을 얻습니다. 이러한 상황에서 공급 업체 소싱 규율은 공급 업체로부터 제품을 획득하는 것을 포함합니다.

IPPD 모범 사례와 마찬가지로 공급 업체 소싱 모범 사례는 제품 생산에 사용되는 모범 사례와 함께 선택되어야합니다.

CMMI 분야 선택

분야를 선택하는 것은 어려운 단계 일 수 있으며 조직이 개선하고자하는 사항에 따라 다릅니다.

  • 구성 관리, 측정 및 분석, 조직 프로세스 초점, 프로젝트 모니터링 및 제어, 프로세스 및 제품 품질 보증, 위험 관리, 공급 업체 계약 관리 등과 같은 시스템 엔지니어링 프로세스를 개선하는 경우 시스템 엔지니어링 (SE)을 선택해야합니다. 징계. 시스템 엔지니어링을위한 분야 확대는 특별히 강조됩니다.

  • 통합 팀 구성, 통합을위한 조직 환경과 같은 통합 제품 및 프로세스 개발 프로세스를 개선하는 경우 IPPD를 선택해야합니다. IPPD에 대한 규율 증폭은 특별히 강조됩니다.

  • 통합 공급 업체 관리와 같은 출처 선택 프로세스를 개선하는 경우 공급 업체 소싱 (SS)을 선택해야합니다. 공급 업체 소싱에 대한 규율 확대는 특히 강조됩니다.

  • 여러 분야를 개선하는 경우 해당 분야와 관련된 모든 영역에서 작업하고 해당 분야의 모든 분야 확대에주의를 기울여야합니다.

이후 장에서 CMMI 구현과 관련된 다양한 영역에 대해 설명합니다.

CMMI는 다음과 같이 구성됩니다.

  • 성숙도 수준 (단계적 표현) 또는 역량 수준 (연속적 표현)
  • 공정 영역
  • 목표 : 일반 및 특정
  • 일반적인 특징
  • 관행 : 일반 및 특정

이 장에서는 두 가지 CMMI 표현에 대해 설명하고 나머지 주제는 후속 장에서 다룹니다.

대표를 통해 조직은 다양한 개선 목표를 추구 할 수 있습니다. 조직은 다음 두 가지 개선 경로 중 하나를 선택할 수 있습니다.

단계적 표현

단계별 표현은 소프트웨어 CMM에서 사용되는 접근 방식입니다. 조직의 개선 경로를 정의하기 위해 사전 정의 된 프로세스 영역 세트를 사용하는 접근 방식입니다. 이 개선 경로는 Maturity Level이라는 모델 구성 요소로 설명됩니다. 성숙도는 개선 된 조직 프로세스를 달성하기위한 잘 정의 된 진화 단계입니다.

CMMI 단계적 표현

  • 검증 된 일련의 개선 사항을 제공하며 각 개선 사항은 다음 단계의 기반이됩니다.

  • 성숙도 수준을 사용하여 조직 간 비교를 허용합니다.

  • SW-CMM에서 CMMI로 쉽게 마이그레이션 할 수 있습니다.

  • 평가 결과를 요약하고 조직간에 비교할 수있는 단일 등급을 제공합니다.

따라서 Staged Representation은 입증 된 프로세스 그룹화 및 순서 지정 및 관련 조직 관계를 기반으로 조직 개선을위한 사전 정의 된 로드맵을 제공합니다. 단계 순서에서 전환 할 수 없습니다.

CMMI 단계적 구조

다음 그림은 CMMI 단계적 모델 구조를 보여줍니다.

지속적인 표현

연속 표현은 SECM 및 IPD-CMM에서 사용되는 접근 방식입니다. 이 접근 방식을 통해 조직은 특정 프로세스 영역을 선택하고이를 기반으로 개선 할 수 있습니다. 연속 표현은 기능 수준을 사용하여 개별 프로세스 영역과 관련된 개선을 특성화합니다.

CMMI 연속 표현

  • 조직의 비즈니스 목표를 가장 잘 충족하고 조직의 위험 영역을 완화하는 개선 순서를 선택할 수 있습니다.

  • 프로세스 영역별로 조직 간 비교가 가능합니다.

  • EIA 731 (및 연속 표현이있는 기타 모델)에서 CMMI로 쉽게 마이그레이션 할 수 있습니다.

따라서 지속적인 표현은 조직이 개선을위한 프로세스와 필요한 개선 정도를 선택할 수있는 유연성을 제공합니다.

CMMI 연속 구조

다음 그림은 CMMI 연속 모델 구조를 보여줍니다.

연속적 표현과 단계적 표현

지속적인 표현 단계적 표현

프로세스 영역은 프로세스 영역 범주별로 구성됩니다.

프로세스 영역은 성숙도별로 구성됩니다.

개선은 능력 수준을 사용하여 측정됩니다. 기능 수준은 조직 전체에서 특정 프로세스의 성숙도를 측정합니다. 범위는 0에서 5까지입니다.

성숙도 수준을 사용하여 개선을 측정합니다. 성숙도 수준은 조직 전체의 프로세스 집합의 성숙도를 측정하며 범위는 1에서 5까지입니다.

특정 관행에는 기본 및 고급의 두 가지 유형이 있습니다. 모든 특정 관행은 연속 표현에 나타납니다.

특정 관행에는 한 가지 유형 만 있습니다. 기본 및 고급 사례의 개념은 사용되지 않습니다. 관련된 기본 고급 사례 쌍이 연속 표현에 나타나는 경우를 제외하고 모든 특정 관행은 단계적 표현에 나타납니다.이 경우 고급 사례 만 단계적 표현에 나타납니다.

기능 수준은 일반 사례를 구성하는 데 사용됩니다.

일반적인 기능은 일반적인 관행을 구성하는 데 사용됩니다.

모든 일반 관행은 각 프로세스 영역에 포함됩니다.

수준 2 및 수준 3 일반 사례 만 포함됩니다.

동등한 스테이징을 통해 조직의 성취 프로필에서 성숙도 수준을 결정할 수 있습니다.

각 조직은 단계적 표현을 사용하여 개선 할 사항과 개선 할 사항을 선택할 수 있기 때문에 연속 표현을 뒷받침하는 동등한 메커니즘이 필요하지 않습니다.

어떤 표현이 더 낫습니까?

각 표현은 다른 표현에 비해 장점이 있으며, 일부 조직은 개선 프로그램에서 다양한 시간에 특정 요구 사항을 해결하기 위해 두 표현을 모두 사용합니다.

조직적 성숙도는 단계적 표현의 초점이고 프로세스 영역 능력은 연속적 표현의 초점입니다.

조직 성숙도와 프로세스 영역 기능은 유사한 개념입니다. 차이점은 조직의 성숙도가 조직 전체의 프로세스 영역 집합과 관련이있는 반면 프로세스 영역 기능은 단일 프로세스 영역 또는 특정 관행과 관련된 일련의 프로세스를 처리한다는 것입니다.

다음 다이어그램은 두 프레젠테이션을 모두 보여줍니다. 이 다이어그램에서ML 성숙도 수준을 나타내고 PA 공정 영역을 나타냅니다.

성숙도는 성숙 된 소프트웨어 프로세스를 달성하기위한 잘 정의 된 진화 적 정점입니다. 각 성숙도 수준은 지속적인 프로세스 개선을위한 토대를 제공합니다.

단계적 표현이있는 CMMI 모델에는 숫자 1부터 5까지 지정된 5 개의 성숙도 수준이 있습니다.

  • Initial
  • Managed
  • Defined
  • 양적 관리
  • Optimizing

CMMI 단계적 표현 성숙도 수준

다음 이미지는 CMMI 단계적 표현의 성숙도 수준을 보여줍니다.

이제 각 성숙도에 대한 세부 사항을 배웁니다. 다음 섹션에서는 이러한 성숙도 수준과 관련된 모든 프로세스 영역을 나열합니다.

성숙도 세부 사항

성숙도 수준은 사전 정의 된 일련의 프로세스 영역으로 구성됩니다. 성숙도 수준은specificgeneric goals사전 정의 된 각 프로세스 영역 세트에 적용됩니다. 다음 섹션에서는 각 성숙도의 특성을 자세히 설명합니다.

성숙도 레벨 1 이니셜

성숙도 레벨 1에서 프로세스는 일반적으로 임시적이고 혼란 스럽습니다. 조직은 일반적으로 안정적인 환경을 제공하지 않습니다. 이러한 조직에서의 성공은 입증 된 프로세스의 사용이 아니라 조직 내 사람들의 능력과 영웅에 달려 있습니다.

성숙도 레벨 1 조직은 종종 작동하는 제품과 서비스를 생산합니다. 그러나 그들은 종종 프로젝트의 예산과 일정을 초과합니다.

성숙도 수준 1 조직은 과도하게 커밋하고 위기시 프로세스를 포기하고 과거의 성공을 반복 할 수없는 경향이 특징입니다.

성숙도 레벨 2 관리

성숙도 수준 2에서 조직은 모든 specificgeneric goals성숙도 수준 2 프로세스 영역의. 즉, 조직의 프로젝트는 요구 사항이 관리되고 프로세스가 계획, 수행, 측정 및 제어되도록 보장했습니다.

성숙도 레벨 2에 반영된 프로세스 규율은 스트레스를받는 동안 기존 관행을 유지하는 데 도움이됩니다. 이러한 관행이 마련되면 문서화 된 계획에 따라 프로젝트가 수행되고 관리됩니다.

성숙도 레벨 2에서는 요구 사항, 프로세스, 작업 산출물 및 서비스가 관리됩니다. 작업 산출물의 상태와 서비스 제공은 정의 된 지점에서 경영진에게 표시됩니다.

관련 이해 관계자간에 약속이 수립되고 필요에 따라 수정됩니다. 작업 산출물은 이해 관계자와 함께 검토되고 통제됩니다.

작업 제품 및 서비스는 지정된 요구 사항, 표준 및 목표를 충족합니다.

성숙도 레벨 3 정의

성숙도 레벨 3에서 조직은 모든 specificgeneric goals 성숙도 레벨 2와 3에 할당 된 프로세스 영역의

성숙도 레벨 3에서 프로세스는 잘 특성화되고 이해되며 표준, 절차, 도구 및 방법에 설명되어 있습니다.

성숙도 레벨 2와 성숙도 레벨 3의 중요한 차이점은 표준, 프로세스 설명 및 절차의 범위입니다. 성숙도 수준 2에서 표준, 프로세스 설명 및 절차는 프로세스의 각 특정 인스턴스 (예 : 특정 프로젝트)에서 상당히 다를 수 있습니다.

성숙도 레벨 3에서 프로젝트의 표준, 프로세스 설명 및 절차는 특정 프로젝트 또는 조직 단위에 맞게 조직의 표준 프로세스 세트에서 조정됩니다. 조직의 표준 프로세스 세트에는 성숙도 레벨 2와 성숙도 레벨 3에서 다루는 프로세스가 포함됩니다. 결과적으로 조직 전체에서 수행되는 프로세스는 조정 지침에서 허용하는 차이를 제외하고는 일관됩니다.

또 다른 중요한 차이점은 성숙도 레벨 3에서는 프로세스가 일반적으로 성숙도 레벨 2보다 더 자세하고 엄격하게 설명된다는 것입니다. 성숙도 레벨 3에서는 프로세스 활동의 상호 관계에 대한 이해와 프로세스, 작업 제품 및 서비스.

성숙도 레벨 4 양적 관리

성숙도 수준 4에서 조직은 모든 specific goals 성숙도 수준 2, 3, 4에 할당 된 프로세스 영역의 generic goals 성숙도 레벨 2와 3에 할당됩니다.

성숙도 레벨 4에서는 전체 프로세스 성능에 크게 기여하는 하위 프로세스가 선택됩니다. 이러한 선택된 하위 프로세스는 통계 및 기타 정량적 기술을 사용하여 제어됩니다.

품질 및 프로세스 성능에 대한 정량적 목표가 설정되고 프로세스 관리의 기준으로 사용됩니다. 양적 목표는 고객, 최종 사용자, 조직 및 프로세스 구현 자의 요구 사항을 기반으로합니다. 품질 및 프로세스 성능은 통계적 용어로 이해되며 프로세스 수명 동안 관리됩니다.

이러한 프로세스의 경우 프로세스 성능의 세부 측정 값이 수집되고 통계적으로 분석됩니다. 공정 변동의 특수 원인을 식별하고 적절한 경우 특수 원인의 원인을 수정하여 향후 발생을 방지합니다.

품질 및 프로세스 성능 측정은 향후 사실 기반 의사 결정을 지원하기 위해 조직의 측정 저장소에 통합됩니다.

성숙도 레벨 3과 성숙도 레벨 4의 중요한 차이점은 프로세스 성능의 예측 가능성입니다. 성숙도 레벨 4에서 프로세스의 성능은 통계 및 기타 정량적 기술을 사용하여 제어되며 정량적으로 예측 가능합니다. 성숙도 레벨 3에서 프로세스는 질적으로 만 예측 가능합니다.

성숙도 레벨 5 최적화

성숙도 레벨 5에서 ​​조직은 모든 specific goals성숙도 수준 2, 3, 4, 5에 할당 된 프로세스 영역의 generic goals 성숙도 레벨 2와 3에 할당됩니다.

프로세스는 프로세스 고유의 일반적인 변동 원인에 대한 정량적 이해를 기반으로 지속적으로 개선됩니다.

이 수준은 점진적이고 혁신적인 기술 개선을 통해 프로세스 성능을 지속적으로 개선하는 데 중점을 둡니다.

조직의 정량적 프로세스 개선 목표를 설정하고 변화하는 비즈니스 목표를 반영하도록 지속적으로 수정하며 프로세스 개선 관리의 기준으로 사용합니다.

배치 된 프로세스 개선의 효과는 정량적 프로세스 개선 목표에 대해 측정되고 평가됩니다. 정의 된 프로세스와 조직의 표준 프로세스 집합은 모두 측정 가능한 개선 활동의 대상입니다.

민첩하고 혁신적인 프로세스 최적화는 조직의 비즈니스 가치와 목표에 부합하는 권한있는 인력의 참여에 달려 있습니다. 변화와 기회에 신속하게 대응하는 조직의 능력은 학습을 가속화하고 공유하는 방법을 찾음으로써 향상됩니다. 프로세스의 개선은 본질적으로 모든 사람이 수행해야하는 역할이며, 결과적으로 지속적인 개선의주기를 가져옵니다.

성숙도 레벨 4와 성숙도 레벨 5 사이의 중요한 차이점은 처리되는 프로세스 변동의 유형입니다. 성숙도 레벨 4에서 프로세스는 프로세스 변동의 특수 원인을 해결하고 결과의 통계적 예측 가능성을 제공하는 것과 관련됩니다. 프로세스가 예측 가능한 결과를 생성 할 수 있지만 그 결과는 설정된 목표를 달성하기에 충분하지 않을 수 있습니다. 성숙도 레벨 5에서 ​​프로세스는 설정된 정량적 프로세스 개선 목표를 달성하기 위해 프로세스 성능을 개선하기 위해 (통계적 예측 가능성을 유지하면서) 프로세스 변동의 일반적인 원인을 해결하고 프로세스를 변경 (즉, 프로세스 성능의 수단을 이동)하는 것과 관련됩니다. .

성숙도를 건너 뛰면 안 됨

각 성숙도 수준은 다음 수준에서 프로세스를 효과적으로 구현하는 데 필요한 기반을 제공합니다.

  • 높은 수준의 프로세스는 낮은 수준에서 제공하는 규율 없이는 성공 가능성이 적습니다.

  • 혁신의 효과는 시끄러운 프로세스에서 가려 질 수 있습니다.

더 높은 성숙도 수준의 프로세스는 위기에 일관되게 적용되지 않을 위험과 함께 더 낮은 성숙도 수준의 조직에서 수행 할 수 있습니다.

성숙도 및 프로세스 영역

다음은 소프트웨어 조직에 대해 정의 된 모든 해당 프로세스 영역의 목록입니다. 이러한 프로세스 영역은 조직마다 다를 수 있습니다.

이 섹션에서는 관련 프로세스 영역의 이름을 제공합니다. 이러한 프로세스 영역에 대한 자세한 내용은 CMMI 프로세스 영역 장을 참조하십시오.

수평 초점 주요 공정 영역 결과
5

최적화

지속적인 프로세스 개선

조직 혁신 및 배포

인과 관계 분석 및 해결

최고 품질 / 최저 위험
4

양적 관리

양적 관리

조직 프로세스 성능

양적 프로젝트 관리

높은 품질 / 낮은 위험

한정된

프로세스 표준화

요구 사항 개발

기술 솔루션

제품 통합

확인

확인

조직 프로세스 초점

조직 프로세스 정의

조직 교육

통합 프로젝트 관리 (IPPD 추가 포함)

위기 관리

의사 결정 분석 및 해결

통합 팀 구성 (IPPD 만 해당)

조직. 통합 환경 (IPPD 전용)

통합 공급 업체 관리 (SS 만 해당)

중간 품질 / 중간 위험
2

관리

기본 프로젝트 관리

요구 사항 관리

프로젝트 기획

프로젝트 모니터링 및 제어

공급 업체 계약 관리

측정 및 분석

프로세스 및 제품 품질 보증

구성 관리

저품질 / 고위험
1

머리 글자

프로세스는 비공식적이고 임시적입니다.   최저 품질 / 최고 위험

능력 수준은 프로세스 영역과 관련된 조직의 능력을 설명하는 잘 정의 된 진화 적 고원입니다. 능력 수준은 해당 프로세스 영역과 관련된 조직의 프로세스를 개선 할 수있는 프로세스 영역에 대한 관련 특정 및 일반 관행으로 구성됩니다. 각 수준은 지속적인 프로세스 개선을위한 기반의 한 계층입니다.

따라서 능력 수준은 누적됩니다. 즉, 능력 수준이 높을수록 낮은 수준의 속성이 포함됩니다.

연속 표현이있는 CMMI 모델에는 0에서 5까지의 숫자로 지정된 6 개의 기능 수준이 있습니다.

  • 0-불완전
  • 1-수행
  • 2 − 관리
  • 3-정의 됨
  • 4 − 양적 관리
  • 5 − 최적화

각 기능 수준에 대한 간략한 설명은 다음과 같습니다.

기능 수준 0 : 불완전

"불완전한 프로세스"는 수행되지 않거나 부분적으로 수행되는 프로세스입니다. 프로세스 영역의 특정 목표 중 하나 이상이 충족되지 않고 부분적으로 수행 된 프로세스를 제도화 할 이유가 없기 때문에이 수준에 대한 일반적인 목표가 없습니다.

이것은 단계적 표현에서 성숙도 레벨 1에 해당합니다.

기능 수준 1 : 수행됨

기능 수준 1 프로세스는 모든 기능 수준 1 특정 및 일반 관행을 수행 할 것으로 예상되는 프로세스입니다. 성능이 안정적이지 않고 품질, 비용 및 일정과 같은 특정 목표를 충족하지 못할 수 있지만 유용한 작업을 수행 할 수 있습니다. 이것은 프로세스 개선의 시작 또는 아기 단계 일뿐입니다. 그것은 당신이 무언가를하고 있지만 그것이 당신에게 정말로 효과가 있다는 것을 증명할 수 없다는 것을 의미합니다.

기능 수준 2 : 관리

관리되는 프로세스는 주어진 목적을 달성하기 위해 개별 프로젝트, 그룹 또는 독립 실행 형 프로세스에 대해 계획, 수행, 모니터링 및 제어됩니다. 프로세스 관리는 프로세스에 대한 모델 목표와 비용, 일정 및 품질과 같은 다른 목표를 모두 달성합니다. 이 수준의 제목에서 알 수 있듯이 조직에서 작업이 수행되는 방식을 적극적으로 관리하고 있습니다. 지속적으로 수집되고 관리 접근 방식에 적용되는 몇 가지 메트릭이 있습니다.

Note− 측정 항목은 단계적 표현과 연속적 표현 모두에서 CMMI의 모든 수준에서 수집되고 사용됩니다. 조직이 메트릭을 사용하기 위해 능력 수준 4까지 기다릴 수 있다고 생각하는 것은 끔찍한 오류입니다.

기능 수준 3 : 정의 됨

능력 수준 3 프로세스는 "정의 된 프로세스"로 특성화됩니다. 정의 된 프로세스는 조직의 조정 지침에 따라 조직의 표준 프로세스 집합에서 조정 된 관리 (능력 수준 2) 프로세스로, 작업 결과물, 측정 값 및 기타 프로세스 개선 정보를 조직 프로세스 자산에 제공합니다.

기능 수준 4 : 양적 관리

능력 수준 4 프로세스는 "정량적으로 관리되는 프로세스"로 특성화됩니다. 정량적으로 관리되는 프로세스는 통계 및 기타 정량적 기법을 사용하여 제어되는 정의 된 (능력 수준 3) 프로세스입니다. 품질 및 프로세스 성능에 대한 정량적 목표가 설정되고 프로세스 관리 기준으로 사용됩니다. 품질 및 프로세스 성능은 통계적 용어로 이해되며 프로세스 수명 동안 관리됩니다.

기능 수준 5 : 최적화

최적화 프로세스는 프로세스 고유의 프로세스 변동의 일반적인 원인에 대한 이해를 기반으로 개선 된 정량적으로 관리되는 프로세스입니다. 점진적 및 혁신적인 개선을 통해 프로세스 성능을 지속적으로 개선하는 데 중점을 둡니다. 정의 된 프로세스와 조직의 표준 프로세스 집합 모두 개선 활동의 대상입니다.

기능 수준 4는 프로세스 성능에 대한 기준, 모델 및 측정을 설정하는 데 중점을 둡니다. 기능 레벨 5는 조직 또는 전체 기업의 성능 결과를 연구하고, 작업이 수행되는 방식 (사용 된 프로세스)에서 문제의 일반적인 원인을 찾고 프로세스의 문제를 수정하는 데 중점을 둡니다. 수정에는 오류가 주입 된 위치와 관련된 프로세스 문서 및 교육 업데이트가 포함됩니다.

연속 표현에서 프로세스 영역의 구성

범주 공정 영역
프로젝트 관리
  • 프로젝트 기획
  • 프로젝트 모니터링 및 제어
  • 공급 업체 계약 관리
  • 통합 프로젝트 관리 (IPPD)
  • 통합 공급 업체 관리 (SS)
  • 통합 팀 구성 (IPPD)
  • 리스크 관리 정량적 프로젝트 관리
지원하다
  • 구성 관리
  • 프로세스 및 제품 품질 보증
  • 측정 및 분석 인과 분석 및 해결
  • 의사 결정 분석 및 해결
  • 통합을위한 조직 환경 (IPPD)
공학
  • 요구 사항 관리
  • 요구 사항 개발
  • 기술 솔루션
  • 제품 통합
  • Verification
  • Validation
공정 관리
  • 조직 프로세스 초점
  • 조직 프로세스 정의
  • 조직 교육
  • 조직 프로세스 성능
  • 조직 혁신 및 배포

프로세스 영역은 공동으로 구현 될 때 해당 영역에서 중요한 개선을 이루는 데 중요하다고 간주되는 일련의 목표를 충족하는 영역의 관련 관행의 클러스터입니다. 모든 CMMI 프로세스 영역은 연속 및 단계적 표현 모두에 공통입니다.

지속적인 표현을 통해 조직은 조직과 비즈니스 목표에 가장 큰 도움이되는 프로세스 영역 또는 상호 관련된 프로세스 영역 집합을 선택하여 프로세스 개선 노력의 초점을 선택할 수 있습니다. 프로세스 영역 간의 종속성으로 인해 조직이 선택할 수있는 항목에 제한이 있지만 조직은 선택에있어 상당한 자유를 가지고 있습니다.

프로세스 영역을 선택한 후에는 해당 프로세스 영역과 관련된 프로세스를 개선 할 정도를 선택해야합니다 (즉, 적절한 능력 수준 선택). 기능 수준, 일반적인 목표 및 관행은 개별 프로세스 영역의 프로세스 개선을 지원합니다.

반대로, 단계적 표현은 프로세스 영역이 속한 성숙도 수준의 맥락에서 항상 프로세스 영역을 살펴 보도록 권장합니다. 프로세스 영역은이 개념을 강화하기 위해 성숙도별로 구성됩니다. 프로세스 영역을 사용할 때 전체 프로세스 영역, 즉 모든 목표와 모든 관행을 사용합니다.

CMMI 프로세스 영역 (PA)은 정의 된 수준에 관계없이 상호 작용 및 서로 연결을 이해하기 위해 다음 네 가지 범주로 그룹화 할 수 있습니다.

  • 공정 관리

  • 프로젝트 관리

  • Engineering

  • Support

각 프로세스 영역은 일련의 목표와 관행에 의해 정의됩니다. 목표와 관행에는 두 가지 범주가 있습니다.

  • Generic goals and practices − 모든 공정 영역의 일부입니다.

  • Specific goals and practices − 주어진 공정 영역에 따라 다릅니다.

프로세스 영역은 회사의 프로세스가 해당 프로세스 영역에 대한 모든 일반 및 특정 목표와 관행을 포함 할 때 충족됩니다.

일반적인 목표 및 관행

일반적인 목표와 관행은 모든 프로세스 영역의 일부입니다.

NOTATIONS − GG-> Generic Goals and GP-> Generic Practice

  • GG 1 구체적인 목표 달성

    • GP 1.1 특정 관행 수행

  • GG 2 관리 프로세스를 제도화

    • 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.9 객관적으로 준수 평가

    • GP 2.10 상위 관리로 상태 검토

  • GG 3 정의 된 프로세스 제도화

    • GP 3.1 정의 된 프로세스 수립

    • GP 3.2 개선 정보 수집

  • GG 4 정량적으로 관리되는 프로세스를 제도화

    • GP 4.1 프로세스에 대한 정량적 목표 설정

    • GP 4.2 하위 공정 성능 안정화

  • GG 5 최적화 프로세스 제도화

    • GP 5.1 지속적인 프로세스 개선 보장

    • GP 5.2 문제의 근본 원인 수정

일반적인 특징

공통 기능은 핵심 프로세스 영역의 구현 및 제도화가 효과적이고 반복 가능하며 지속되는지 여부를 나타내는 속성입니다. 다섯 가지 일반적인 기능은 다음과 같습니다.

  • Commitment to Perform− 수행 약속은 프로세스가 확립되고 지속될 수 있도록 조직이 취해야하는 조치를 설명합니다. 수행 약속에는 일반적으로 조직 정책 수립 및 고위 경영진 후원이 포함됩니다.

  • Ability to Perform− 수행 능력은 소프트웨어 프로세스를 유능하게 구현하기 위해 프로젝트 또는 조직에 존재해야하는 전제 조건을 설명합니다. 수행 능력에는 일반적으로 리소스, 조직 구조 및 교육이 포함됩니다.

  • Activities Performed− 수행 된 활동은 핵심 프로세스 영역을 구현하는 데 필요한 역할과 절차를 설명합니다. 수행되는 활동은 일반적으로 계획 및 절차를 수립하고, 작업을 수행하고, 추적하고, 필요에 따라 수정 조치를 취하는 것을 포함합니다.

  • Measurement and Analysis− 측정 및 분석은 프로세스를 측정하고 측정을 분석 할 필요성을 설명합니다. 측정 및 분석에는 일반적으로 수행 된 활동의 상태와 효과를 결정하기 위해 취할 수있는 측정의 예가 포함됩니다.

  • Verifying Implementation− 구현 확인은 설정된 프로세스에 따라 활동이 수행되는지 확인하는 단계를 설명합니다. 검증에는 일반적으로 관리 및 소프트웨어 품질 보증에 의한 검토 및 감사가 포함됩니다.

공통 기능 수행 된 활동의 관행은 프로세스 기능을 설정하기 위해 구현해야하는 사항을 설명합니다. 전체적으로 취한 다른 관행은 조직이 수행 된 활동 공통 기능에 설명 된 관행을 제도화 할 수있는 기반을 형성합니다.

세부 공정 영역

CMMI에는 회사 프로세스에서 다루는 제품 개발 측면을 나타내는 22 개의 프로세스 영역이 있습니다.

인과 관계 분석 및 해결

  • 성숙도 레벨 5의 지원 프로세스 영역입니다.

목적

목적 Causal Analysis and Resolution (CAR)는 결함 및 기타 문제의 원인을 파악하고 향후 발생하지 않도록 조치를 취하는 것입니다.

목표 별 특정 관행

  • SG 1 결함의 원인 결정

    • SP 1.1 분석을위한 결함 데이터 선택

    • SP 1.2 원인 분석

  • SG 2 결함 원인 해결

    • SP 2.1 작업 제안 구현

    • SP 2.2 변경 효과 평가

    • SP 2.3 데이터 기록

구성 관리

  • 성숙도 레벨 2의 지원 프로세스 영역입니다.

목적

목적 Configuration Management (CM)은 구성 식별, 구성 제어, 구성 상태 회계 및 구성 감사를 사용하여 작업 제품의 무결성을 설정하고 유지하는 것입니다.

Specific Practices by Goal

  • SG 1 기준 설정

    • SP 1.1 구성 항목 식별

    • SP 1.2 구성 관리 시스템 설정

    • SP 1.3 기준 생성 또는 릴리스

  • SG 2 추적 및 제어 변경

    • SP 2.1 변경 요청 추적

    • SP 2.2 제어 구성 항목

  • SG 3 무결성 확립

    • SP 3.1 구성 관리 기록 설정

    • SP 3.2 구성 감사 수행

의사 결정 분석 및 해결

  • 성숙도 레벨 3의 지원 프로세스 영역입니다.

목적

목적 Decision Analysis and Resolution (DAR)는 확립 된 기준에 대해 확인 된 대안을 평가하는 공식 평가 프로세스를 사용하여 가능한 결정을 분석하는 것입니다.

목표 별 특정 관행

  • SG 1 대안 평가

    • SP 1.1 의사 결정 분석을위한 지침 수립

    • SP 1.2 평가 기준 설정

    • SP 1.3 대체 솔루션 식별

    • SP 1.4 평가 방법 선택

    • SP 1.5 대안 평가

    • SP 1.6 솔루션 선택

통합 프로젝트 관리 + IPPD

  • 성숙도 레벨 3의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Integrated Project Management + IPPD (IPM)은 조직의 표준 프로세스 집합에 따라 조정 된 통합되고 정의 된 프로세스에 따라 프로젝트 및 관련 이해 관계자의 참여를 설정하고 관리하는 것입니다.

목표 별 특정 관행

  • SG 1 프로젝트의 정의 된 프로세스 사용

    • SP 1.1 프로젝트의 정의 된 프로세스 설정

    • SP 1.2 계획 프로젝트 활동에 조직 프로세스 자산 사용

    • SP 1.3 프로젝트 작업 환경 구축

    • SP 1.4 통합 계획

    • SP 1.5 통합 계획을 사용하여 프로젝트 관리

    • SP 1.6 조직 프로세스 자산에 기여

  • SG 2 관련 이해 관계자와 조정 및 협업

    • SP 2.1 이해 관계자 참여 관리

    • SP 2.2 종속성 관리

    • SP 2.3 조정 문제 해결

IPPD 추가-

  • SG 3 IPPD 원칙 적용

    • SP 3.1 프로젝트의 공유 비전 수립

    • SP 3.2 통합 팀 구조 구축

    • SP 3.3 통합 팀에 요구 사항 할당

    • SP 3.4 통합 팀 구축

    • SP 3.5 인터페이싱 팀 간의 협업 보장

측정 및 분석

성숙도 레벨 2의 지원 프로세스 영역입니다.

목적

목적 Measurement and Analysis (MA)는 관리 정보 요구를 지원하는 데 사용되는 측정 기능을 개발하고 유지하는 것입니다.

목표 별 특정 관행

  • SG 1 측정 및 분석 활동 조정

    • SP 1.1 측정 목표 설정

    • SP 1.2 측정 지정

    • SP 1.3 데이터 수집 및 저장 절차 지정

    • SP 1.4 분석 절차 지정

  • SG 2 측정 결과 제공

    • SP 2.1 측정 데이터 수집

    • SP 2.2 측정 데이터 분석

    • SP 2.3 데이터 및 결과 저장

    • SP 2.4 결과 전달

조직 혁신 및 배포

성숙도 레벨 5의 프로세스 관리 프로세스 영역입니다.

목적

목적 Organizational Innovation and Deployment(OID)는 조직의 프로세스와 기술을 현저하게 개선하는 점진적이고 혁신적인 개선 사항을 선택하고 배포하는 것입니다. 개선 사항은 조직의 비즈니스 목표에서 파생 된 조직의 품질 및 프로세스 성능 목표를 지원합니다.

목표 별 특정 관행

  • SG 1 Select 개선 사항

    • SP 1.1 개선 제안 수집 및 분석

    • SP 1.2 혁신 식별 및 분석

    • SP 1.3 파일럿 개선 사항

    • SP 1.4 배포를위한 개선 사항 선택

  • SG 2 배포 개선

    • SP 2.1 배포 영역 계획

    • SP 2.2 배포 관리

    • SP 2.3 개선 효과 측정

조직 프로세스 정의 + IPPD (OPD)

성숙도 레벨 3의 프로세스 관리 프로세스 영역입니다.

목적

목적 Organizational Process Definition + IPPD (OPD)는 사용 가능한 조직 프로세스 자산 세트를 설정하고 유지하는 것입니다.

목표 별 특정 관행

  • SG 1 조직 프로세스 자산 구축

    • SP 1.1 표준 프로세스 설정

    • SP 1.2 라이프 사이클 모델 설명 설정

    • SP 1.3 조정 기준 및 지침 설정

    • SP 1.4 조직의 측정 저장소 구축

    • SP 1.5 조직의 프로세스 자산 라이브러리 설정

IPPD 추가-

  • SG 2 IPPD 관리 활성화

    • SP 2.1 권한 부여 메커니즘 설정

    • SP 2.2 통합 팀을위한 규칙 및 지침 수립

    • SP 2.3 균형 팀과 가정 조직의 책임

조직 프로세스 초점

성숙도 레벨 3의 프로세스 관리 프로세스 영역입니다.

목적

목적 Organizational Process Focus (OPF)는 조직의 프로세스 및 프로세스 자산의 현재 강점과 약점에 대한 철저한 이해를 바탕으로 조직 프로세스 개선을 계획하고 구현하는 것입니다.

목표 별 특정 관행

  • SG 1 프로세스 개선 기회 결정

    • SP 1.1 조직 프로세스 요구 사항 설정

    • SP 1.2 조직의 프로세스 평가

    • SP 1.3 조직의 프로세스 개선 사항 식별

  • SG 2 프로세스 개선 활동 계획 및 구현

    • SP 2.1 프로세스 실행 계획 수립

    • SP 2.2 프로세스 실행 계획 구현

  • SG 3 조직 프로세스 자산 배포 및 학습 한 교훈 통합

    • SP 3.1 조직 프로세스 자산 배포

    • SP 3.2 표준 프로세스 배포

    • SP 3.3 모니터 구현

    • SP 3.4 프로세스 관련 경험을 조직 프로세스 자산에 통합

조직 프로세스 성능

성숙도 레벨 4의 프로세스 관리 프로세스 영역입니다.

목적

목적 Organizational Process Performance (OPP)는 품질 및 프로세스 성능 목표를 지원하기 위해 조직의 표준 프로세스 집합의 성능에 대한 정량적 이해를 설정 및 유지하고 조직의 프로젝트를 정량적으로 관리하기위한 프로세스 성능 데이터, 기준선 및 모델을 제공하는 것입니다.

목표 별 특정 관행

  • SG 1 성과 기준 및 모델 수립

    • SP 1.1 프로세스 선택

    • SP 1.2 프로세스 성능 측정 설정

    • SP 1.3 품질 및 프로세스 성능 목표 설정

    • SP 1.4 프로세스 성능 기준 설정

    • SP 1.5 프로세스 성능 모델 설정

조직 교육

성숙도 레벨 3의 프로세스 관리 프로세스 영역입니다.

목적

목적 Organizational Training (OT)는 사람들이 자신의 역할을 효과적이고 효율적으로 수행 할 수 있도록 기술과 지식을 개발하는 것입니다.

목표 별 특정 관행

  • SG 1 조직 교육 역량 구축

    • SP 1.1 전략적 교육 요구 사항 설정

    • SP 1.2 조직의 책임 인 교육 요구 사항 결정

    • SP 1.3 조직 훈련 전술 계획 수립

    • SP 1.4 교육 기능 설정

  • SG 2 필요한 교육 제공

    • SP 2.1 교육 제공

    • SP 2.2 교육 기록 수립

    • SP 2.3 교육 효과 평가

제품 통합

성숙도 레벨 3의 엔지니어링 프로세스 영역입니다.

목적

목적 Product Integration (PI)는 제품 구성 요소에서 제품을 조립하고 제품이 통합 된 상태로 제대로 작동하는지 확인하고 제품을 제공하는 것입니다.

목표 별 특정 관행

  • SG 1 제품 통합 준비

    • SP 1.1 통합 순서 결정

    • SP 1.2 제품 통합 환경 설정

    • SP 1.3 제품 통합 절차 및 기준 설정

  • SG 2 인터페이스 호환성 보장

    • SP 2.1 완전성을위한 인터페이스 설명 검토

    • SP 2.2 인터페이스 관리

  • SG 3 제품 구성 요소 조립 및 제품 배송

    • SP 3.1 통합을위한 제품 구성 요소 준비 확인

    • SP 3.2 제품 구성 요소 조립

    • SP 3.3 조립 된 제품 구성 요소 평가

    • SP 3.4 패키지 및 제품 또는 제품 구성 요소 제공

프로젝트 모니터링 및 제어

성숙도 레벨 2의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Project Monitoring and Control (PMC)는 프로젝트의 성과가 계획에서 크게 벗어날 때 적절한 시정 조치를 취할 수 있도록 프로젝트의 진행 상황에 대한 이해를 제공하는 것입니다.

목표 별 특정 관행

  • SG 1 Monitor Project Against Plan

    • SP 1.1 프로젝트 계획 매개 변수 모니터링

    • SP 1.2 모니터 약속

    • SP 1.3 프로젝트 위험 모니터링

    • SP 1.4 모니터 데이터 관리

    • SP 1.5 이해 관계자 참여 모니터링

    • SP 1.6 진행 상황 검토 수행

    • SP 1.7 수행 마일스톤 검토

  • SG 2 폐쇄에 대한 시정 조치 관리

    • SP 2.1 문제 분석

    • SP 2.2 수정 조치 수행

    • SP 2.3 수정 조치 관리

프로젝트 기획

성숙도 레벨 2의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Project Planning (PP)는 프로젝트 활동을 정의하는 계획을 수립하고 유지하는 것입니다.

목표 별 특정 관행

  • SG 1 추정치 설정

    • SP 1.1 프로젝트 범위 추정

    • SP 1.2 작업 산출물 및 작업 속성 추정치 설정

    • SP 1.3 프로젝트 수명주기 정의

    • SP 1.4 노력 및 비용 추정치 결정

  • SG 2 프로젝트 계획 개발

    • SP 2.1 예산 및 일정 수립

    • SP 2.2 프로젝트 위험 식별

    • SP 2.3 데이터 관리 계획

    • 프로젝트 리소스에 대한 SP 2.4 계획

    • 필요한 지식과 기술을위한 SP 2.5 계획

    • SP 2.6 계획 이해 관계자 참여

    • SP 2.7 프로젝트 계획 수립

  • SG 3 계획에 대한 헌신 확보

    • 프로젝트에 영향을 미치는 SP 3.1 검토 계획

    • SP 3.2 작업 및 자원 수준 조정

    • SP 3.3 계획 약정 얻기

프로세스 및 제품 품질 보증

성숙도 레벨 2의 지원 프로세스 영역입니다.

목적

목적 Process and Product Quality Assurance (PPQA)는 직원과 경영진에게 프로세스 및 관련 작업 산출물에 대한 객관적인 통찰력을 제공하는 것입니다.

목표 별 특정 관행

  • SG 1 프로세스 및 작업 제품을 객관적으로 평가

    • SP 1.1 객관적으로 프로세스 평가

    • SP 1.2 작업 제품 및 서비스를 객관적으로 평가

  • SG 2 객관적인 통찰력 제공

    • SP 2.1 비준수 문제에 대한 커뮤니케이션 및 해결 보장

    • SP 2.2 기록 수립

양적 프로젝트 관리

성숙도 레벨 4의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Quantitative Project Management (QPM) 프로세스 영역은 프로젝트의 설정된 품질 및 프로세스 성과 목표를 달성하기 위해 프로젝트에 정의 된 프로세스를 정량적으로 관리하는 것입니다.

목표 별 특정 관행

  • SG 1 프로젝트를 정량적으로 관리

    • SP 1.1 프로젝트의 목표 설정

    • SP 1.2 정의 된 프로세스 구성

    • SP 1.3 통계적으로 관리 할 하위 프로세스 선택

    • SP 1.4 프로젝트 성능 관리

  • SG 2 하위 프로세스 성능을 통계적으로 관리

    • SP 2.1 측정 및 분석 기법 선택

    • SP 2.2 통계적 방법을 적용하여 변동 이해

    • SP 2.3 선택한 하위 프로세스의 성능 모니터링

    • SP 2.4 통계 관리 데이터 기록

요구 사항 개발

성숙도 레벨 3의 엔지니어링 프로세스 영역입니다.

목적

목적 Requirements Development (RD)는 고객, 제품 및 제품 구성 요소 요구 사항을 생성하고 분석하는 것입니다.

목표 별 특정 관행

  • SG 1 고객 요구 사항 개발

    • SP 1.1 요구 사항 유도

    • SP 1.2 고객 요구 사항 개발

  • SG 2 제품 요구 사항 개발

    • SP 2.1 제품 및 제품 구성 요소 요구 사항 설정

    • SP 2.2 제품 구성 요소 요구 사항 할당

    • SP 2.3 인터페이스 요구 사항 식별

  • SG 3 요구 사항 분석 및 검증

    • SP 3.1 운영 개념 및 시나리오 설정

    • SP 3.2 필수 기능의 정의 설정

    • SP 3.3 요구 사항 분석

    • SP 3.4 균형 달성을위한 요구 사항 분석

    • SP 3.5 요구 사항 확인

요구 사항 관리

성숙도 레벨 2의 엔지니어링 프로세스 영역입니다.

목적

목적 Requirements Management (REQM)은 프로젝트 제품 및 제품 구성 요소의 요구 사항을 관리하고 이러한 요구 사항과 프로젝트 계획 및 작업 제품 간의 불일치를 식별하는 것입니다.

목표 별 특정 관행

  • SG 1 관리 요구 사항

    • SP 1.1 요구 사항에 대한 이해 얻기

    • SP 1.2 요구 사항에 대한 약속 확보

    • SP 1.3 요구 사항 변경 관리

    • SP 1.4 요구 사항의 양방향 추적 성 유지

    • SP 1.5 프로젝트 작업과 요구 사항 간의 불일치 식별

위기 관리

성숙도 레벨 3의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Risk Management (RSKM)은 잠재적 인 문제가 발생하기 전에 식별하여 목표 달성에 대한 부정적 영향을 완화하기 위해 제품 또는 프로젝트의 수명 동안 필요에 따라 위험 처리 활동을 계획하고 호출 할 수 있도록합니다.

목표 별 특정 관행

  • SG 1 위험 관리 준비

    • SP 1.1 위험 소스 및 범주 결정

    • SP 1.2 위험 매개 변수 정의

    • SP 1.3 위험 관리 전략 수립

  • SG 2 위험 식별 및 분석

    • SP 2.1 위험 식별

    • SP 2.2 위험 평가, 분류 및 우선 순위 지정

  • SG 3 위험 완화

    • SP 3.1 위험 완화 계획 개발

    • SP 3.2 위험 완화 계획 구현

공급 업체 계약 관리

성숙도 레벨 2의 프로젝트 관리 프로세스 영역입니다.

목적

목적 Supplier Agreement Management (SAM)은 공식 계약이있는 공급 업체로부터 제품을 취득하는 것을 관리하는 것입니다.

목표 별 특정 관행

  • SG 1 공급 업체 계약 수립 M

    • SP 1.1 획득 유형 결정

    • SP 1.2 공급 업체 선택

    • SP 1.3 공급 업체 계약 수립

  • SG 2 공급 업체 계약 충족

    • SP 2.1 공급 업체 계약 실행

    • SP 2.2 선택한 공급 업체 프로세스 모니터링

    • SP 2.3 선택한 공급 업체 작업 산출물 평가

    • SP 2.4 인수 한 제품 수락

    • SP 2.5 전환 제품

기술 솔루션

성숙도 레벨 3의 엔지니어링 프로세스 영역입니다.

목적

목적 Technical Solution(TS)는 요구 사항에 대한 솔루션을 설계, 개발 및 구현하는 것입니다. 솔루션, 설계 및 구현에는 제품, 제품 구성 요소 및 제품 관련 라이프 사이클 프로세스가 단일 또는 적절한 조합으로 포함됩니다.

목표 별 특정 관행

  • SG 1 Select Product-Component Solutions

    • SP 1.1 대체 솔루션 및 선택 기준 개발

    • SP 1.2 제품 구성 요소 솔루션 선택

  • SG 2 디자인 개발

    • SP 2.1 제품 또는 제품 구성 요소 디자인

    • SP 2.2 기술 데이터 패키지 설정

    • SP 2.3 기준을 사용한 디자인 인터페이스

    • SP 2.4 제조, 구매 또는 재사용 분석 수행

  • SG 3 제품 설계 구현

    • SP 3.1 설계 구현

    • SP 3.2 제품 지원 문서 개발

확인

성숙도 레벨 3의 엔지니어링 프로세스 영역입니다.

목적

목적 Validation (VAL)은 제품 또는 제품 구성 요소가 의도 된 환경에 배치 될 때 의도 된 용도를 충족 함을 보여줍니다.

목표 별 특정 관행

  • SG 1 검증 준비

    • SP 1.1 검증 할 제품 선택

    • SP 1.2 유효성 검사 환경 설정

    • SP 1.3 검증 절차 및 기준 설정

  • SG 2 제품 또는 제품 구성 요소 검증

    • SP 2.1 검증 수행

    • SP 2.2 유효성 검사 결과 분석.

확인

성숙도 레벨 3의 엔지니어링 프로세스 영역입니다.

목적

목적 Verification (VER)는 선택한 작업 산출물이 지정된 요구 사항을 충족하는지 확인하는 것입니다.

목표 별 특정 관행

  • SG 1 검증 준비

    • SP 1.1 검증을위한 산출물 선택

    • SP 1.2 확인 환경 설정

    • SP 1.3 검증 절차 및 기준 설정

  • SG 2 피어 리뷰 수행

    • SP 2.1 동료 검토 준비

    • SP 2.2 피어 리뷰 수행

    • SP 2.3 피어 리뷰 데이터 분석

  • SG 3 선택한 산출물 확인

    • SP 3.1 확인 수행

    • SP 3.2 검증 결과 분석

버전 1.2의 변경 사항

여기에서는 프로세스 영역 집합에 대한 변경 사항 만 고려됩니다. 자세한 내용은 SEI 홈페이지를 참조하십시오 .

  • 다음 프로세스 영역이 제거되었습니다 (모두 성숙도 레벨 3)-

    • 통합을위한 조직 환경 (OEI)

    • 통합 팀 구성 (IT)

    • 통합 공급 업체 관리 (ISM)

  • 기존 프로세스 영역 내에 다음이 추가되었습니다.

    • IPM. SG3 및 SG4 제거, 새 SG3 추가 (모든 IPPD PA)

    • OPD. SG가 추가되어 IPPD PA로 전환

    • OPF. 두 개의 SP가 SG에서 추출되고 두 개의 새 SP와 함께 SG3가 생성되었습니다.

    • REQD. SP3.5는 요구 사항 유효성 검사로 이름이 변경되었습니다.

    • SAM. SP2.1이 제거되고 SG2에 두 개의 새로운 SP가 추가됨

    • TS. SP1.2가 제거되었습니다.

    • VER. SP3.2가 검증 결과 분석으로 이름이 변경되었습니다.

CMMI 평가는 조직의 강점과 약점을 결정하기위한 기준으로 평가 참조 모델을 사용하여 훈련 된 전문가 팀이 하나 이상의 프로세스를 검사하는 것입니다.

평가에는 계획이 필요합니다. 조직의 평가를 계획 할 때 조직 단위의 범위, 포함 할 분야, 평가 팀이 조직 내부 또는 외부 구성원으로 구성되는지 여부, 포함 할 프로젝트, 인터뷰 할 개인 및 유형 또는 유형을 결정합니다. 평가 등급이 필요합니다.

평가는 CMMI에 정의 된 모델 구성 요소의 세 가지 범주를 고려합니다-

  • Required − 구체적이고 일반적인 목표 만.

  • Expected − 구체적이고 일반적인 관행 만.

  • Informative − 하위 사례 및 일반적인 작업 산출물을 포함합니다.

SEI는 CMMI 평가를위한 두 가지 지침 문서를 발표했습니다.

  • Appraisal Requirements for CMMI (ARC) − 여기에는 등급 A, 등급 B 및 등급 C의 세 가지 등급의 평가 방법에 대한 요구 사항이 포함되어 있습니다. 이러한 요구 사항은 각 등급의 평가 방법을 정의하는 규칙입니다.

  • Standard CMMI Appraisal Method for Process Improvement (SCAMPI) − MDD (Method Description Document)는 현재 유일하게 승인 된 A 등급 평가 방법입니다.

SCAMPI는 현재 유일하게 승인 된 CMMI 클래스 A 평가 방법입니다. 즉, SCAMPI는 ARC Class A 평가 방법의 모든 요구 사항을 충족하며 SEI의 승인을 받았습니다.

CMMI 평가 방법에는 클래스 A, 클래스 B 및 클래스 C의 세 가지 클래스가 있습니다.

SCAMPI 클래스 A 평가

SCAMPI 클래스 A 평가는 일반적으로 조직이 여러 가지 중요한 프로세스 개선 사항을 구현했으며 CMMI와 관련된 프로세스를 공식적으로 벤치마킹해야 할 때 수행됩니다. SCAMPI A는 CMMI 성숙도 수준 또는 기능 수준 등급을 제공하는 유일한 평가 방법입니다.

SCAMPI A에서 다음과 같은 결과를 기대할 수 있습니다.

  • 성숙도 등급 또는 기능 수준 등급.

  • CMMI와 관련된 조직 프로세스의 강점과 약점을 설명하는 결과.

  • 조직의 주요 프로세스 문제에 대한 합의.

  • 조직이 프로세스 개선 진행 상황을 모니터링하고 향후 평가를 지원하기 위해 계속 사용할 수있는 평가 데이터베이스입니다.

SCAMPI 클래스 B 평가

SCAMPI B는 조직이 목표 CMMI 성숙도 수준을 향한 진행 상황을 평가해야하지만 SCAMPI A보다 낮은 비용으로 평가해야 할 때 필요합니다. SCAMPI B 평가는 상세한 결과를 제공하고 평가 된 사례가 만족스럽게 평가 될 가능성을 나타냅니다. SCAMPI A 평가에서 구현됩니다.

세 가지 SEI 평가 방법 중 하나 인 SCAMPI 클래스 B 평가는 조직이 CMMI와 관련된 소프트웨어 및 시스템 엔지니어링 프로세스의 상태를 비교적 높은 수준의 신뢰도로 이해하는 데 도움이됩니다. SCAMPI B는 조직이 목표 CMMI 성숙도 수준에 대한 진행 상황을 정확하게 평가해야 할 때 종종 수행됩니다.

SCAMPI B에서 다음과 같은 결과를 기대할 수 있습니다.

  • CMMI와 관련된 조직 프로세스의 강점과 약점을 설명하는 자세한 결과.

  • 조사 된 관행이 목표를 충족하고 CMMI의 의도를 충족 할 가능성을 나타내는 연습 특성화.

  • 조직의 주요 프로세스 문제에 대한 합의.

  • 조직이 프로세스 개선 진행 상황을 모니터링하고 향후 평가를 지원하기 위해 계속 사용할 수있는 FIDO 데이터베이스입니다.

SCAMPI 클래스 C 평가

SCAMPI C 평가는 SCAMPI A 및 B 평가보다 짧고 유연하며 빠른 격차 분석에서 SCAMPI A에 대한 조직의 준비 상태 결정에 이르기까지 다양한 특수 요구 사항을 해결하기 위해 수행됩니다.

SEI의 평가 방법 제품군 중 가장 덜 공식적인 SCAMPI 클래스 C 평가는 매우 유연하며 다양한 요구 사항을 해결하기 위해 수행 할 수 있습니다. 일반적으로 클래스 A 및 B 평가보다 기간이 훨씬 짧으며 SCAMPI C 평가는 종종 다음과 같은 이유로 수행됩니다.

  • CMMI와 관련된 조직의 프로세스에 대한 빠른 차이 분석을 제공합니다.

  • 구현하기 전에 새 프로세스의 적절성을 평가하십시오.

  • 프로세스 구현을 모니터링합니다.

  • SCAMPI A에 대한 조직의 준비 상태를 결정합니다.

  • 공급 업체 선정을 지원합니다.

SCAMPI C에서 다음과 같은 결과를 기대할 수 있습니다.

  • 평가 된 프로세스의 강점과 약점을 설명하는 결과. 평가 범위 및 전략에 따라 결과가 관련 CMMI 구성 요소에 매핑 될 수 있습니다.

  • CMMI에 대해 평가 된 프로세스의 적절성을 요약하는 특성화.

  • 권장되는 프로세스 개선 조치.

  • 조직이 프로세스 개선 진행 상황을 모니터링하고 향후 평가를 지원하기 위해 계속 사용할 수있는 FIDO 데이터베이스입니다.

평가 클래스 특성

각 클래스는 메서드 적용과 관련된 엄격한 정도로 구분됩니다. Class A는 가장 엄격하고 Class B는 약간 덜 엄격하며 Class C는 가장 덜 엄격합니다. 다음 표는 각 클래스의 메서드간에 예상되는 차이점에 대한 아이디어를 제공합니다.

형질 클래스 A 클래스 B 클래스 C
수집 된 객관적인 증거의 양 높은 매질 낮은
평가 생성 아니 아니
자원 요구 높은 매질 낮은
팀 규모 매질 작은
데이터 소스 (악기, 인터뷰 및 문서) 세 가지 데이터 소스 모두 필요 2 개의 데이터 소스 만 필요 (하나는 인터뷰 여야 함) 하나의 데이터 소스 만 필요
평가 팀 리더 요구 사항 공인 리드 평가자 공인 리드 평가자 또는 교육을 받고 경험이있는 사람 훈련 및 경험이있는 사람

SCAMPI 기초

SCAMPI는 Standard CMMI Appraisal Method for Process Improvement의 약자입니다. SCAMPI 평가는 SEI 공인 SCAMPI 리드 평가자가 주도해야합니다. SCAMPI는 SCAMPI 방법 설명, 성숙도 설문지, 작업 보조 도구 및 템플릿을 포함하는 SCAMPI 제품 스위트에서 지원됩니다.

현재 SCAMPI는 등급을 제공 할 수있는 유일한 방법이며 SEI에서 인정하는 유일한 방법이며 조직이 가장 관심을 갖는 방법입니다.

SCAMPI는 다음을 포함한 이전 방법의 경험을 기반으로합니다.

  • CBA IPI − 내부 프로세스 개선을위한 CMM 기반 평가.

  • SCE − 소프트웨어 기능 평가.

  • EIA/IS 732.2 − 시스템 엔지니어링 평가 방법이라는 임시 국제 표준.

  • SDCE − 소프트웨어 개발 능력 평가.

  • FAA 평가 방법.

이 장에서는 프로세스 개선 노력과 관련된 주요 플레이어에 대해 설명합니다. 그러나 조직에 더 많거나 적은 그룹이 필요할 수 있습니다.

조직의 규모와 프로세스 개선 (PI) 노력의 복잡성에 따라 한 사람이 이러한 역할을 동시에 또는 순차적으로 수행 할 수 있습니다.

프로세스 개선

프로세스 개선 노력에는 일반적으로 다음과 같은 개인 및 그룹이 필요합니다.

  • PI Sponsor− 전체 PI 작업을 감독 할 책임이있는 조직의 사람. 이 사람은 일반적으로 자금과 인력을 할당 할 권한이 있습니다. 이 사람은 일반적으로 이사 수준 이상입니다.

  • PI Champion− 이것은 EPG 리드 역할을 할 수도 있고하지 않을 수도있는 PI 노력의 홍보 담당자입니다. 이 사람은 PI의 아이디어, 접근 방식 및 결과를 마케팅합니다.

  • Engineering Process Group (EPG) Lead−이 사람은 프로세스를 검토하는 그룹을 이끌고 있습니다. 이 사람은 EPG 구성원에게 작업을 할당하고 그들의 노력을 모니터링하며 EPG의 일상 업무를 계획합니다.

  • EPG Members−이 개인은 EPG에서위원회 위원으로 활동합니다. 그들은 프로세스 개선 문서를 작성하고 따라야 할 책임이 있습니다. 또한 프로세스 개선 프로세스를 추적하기위한 메트릭 생성을 담당합니다. 그들은 PAT를 이끌고 있습니다.

  • Process Action Teams (PATs) −이 팀은 프로세스 개선 문서, 정책, 프로세스, 절차, 헌장 및 실행 계획을 생성합니다.

  • Transition Partner− 일반적으로 조직 프로세스 개선 과정을 설정, 계획, 주도 및 모니터링하기 위해 외부 컨설턴트 인 한두 명을 데려옵니다. 이 개인은 다른 여러 조직 및 산업에서 프로세스 개선을 수행 한 경험을 제공합니다.

이 튜토리얼은 다음 구성 요소로 구성된 CMMI의 구조를 다루었습니다.

  • 성숙도 수준 (단계적 표현) 또는 역량 수준 (연속적 표현)
  • 공정 영역
  • 목표 : 일반 및 특정
  • 일반적인 특징
  • 관행 : 일반 및 특정

우리는 모든 성숙도 수준과 역량 수준을 다루었습니다. 또한 모든 주요 프로세스 영역 및 관련 일반 목표, 특정 목표, 공통 기능 및 관행에 대해 논의했습니다.

나중에 CMMI Appraisals에 대한 간략한 소개와 다양한 Appraisal Class를 소개했습니다.

다음은 무엇입니까?

SEI CMMI는 작은 튜토리얼로는 설명 할 수없는 큰 주제입니다. 따라서 다른 CMMI 리소스를 살펴보고이 주제에 대한 자세한 정보를 수집하는 것이 좋습니다. 이러한 리소스는 CMMI 리소스 장에 나열되어 있습니다.

[email protected]으로 피드백을 보내주세요.

이자형 에프 H 나는 제이 케이
미디엄 영형 아르 자형 에스 V
W 엑스 와이

Ability to perform − 프로젝트 및 / 또는 조직이 필요한 리소스를 보유하고 있는지 확인하는 것과 관련된 일반적인 관행을 그룹화하는 단계적 표현이있는 CMMI 모델 프로세스 영역의 공통 기능.

Acceptance criteria − 제품 또는 제품 구성 요소가 사용자, 고객 또는 기타 권한있는 법인이 수락하기 위해 충족해야하는 기준.

Acceptance testing − 사용자, 고객 또는 기타 승인 된 주체가 제품 또는 제품 구성 요소를 수락할지 여부를 결정할 수 있도록 수행 된 공식 테스트.

Achievement profile − 연속적 표현에서, 능력 수준을 진행하면서 각 프로세스 영역에 대한 조직의 진행 상황을 나타내는 프로세스 영역 및 해당 능력 수준의 목록.

Acquisition − 계약을 통해 제품 및 서비스를 획득하기 위해 투자하기로 약속 한 인수 주체의 개별 조치 또는 제안 된 조치를 획득하는 프로세스.

Acquisition strategy − 공급 출처, 취득 방법, 요구 사항 사양 유형, 계약 또는 계약 유형 및 관련 취득 위험을 고려하여 제품 및 서비스를 취득하는 구체적인 접근 방식.

Adequate− CMMI에 적절하고 적절하며 필요에 따라 모든 수준의 관리자와 실무자가 조직의 비즈니스 목표에 비추어 구체적이고 일반적인 목표와 관행을 해석 할 수 있습니다. 예를 들어, 위험 관리 프로세스 영역에 대한 일반 관행은 "위험 관리 프로세스를 수행하고, 작업 제품을 개발하고, 프로세스 서비스를 제공하기위한 적절한 자원을 제공하십시오."라고 말합니다. 인원수, 위험을 모니터링해야하는 사람 등으로 충분할 수 있습니다.

Advanced practices − 연속 표현에서 능력 수준이 2 이상인 모든 특정 관행.

Agreement/contract requirements − 인수와 관련된 모든 기술적 및 비 기술적 요구 사항.

Allocated requirement − 하위 수준의 아키텍처 요소 또는 설계 구성 요소에 대한 상위 수준 요구 사항의 성능 및 기능의 전부 또는 일부를 부과하는 요구 사항.

Alternative practice− CMMI 모델에 포함 된 하나 이상의 일반 또는 특정 관행을 대체하는 관행으로, 모델 관행과 관련된 일반 또는 특정 목표를 충족하는 데 동등한 효과를 얻습니다. 대체 관행이 반드시 일반 관행 또는 특정 관행을 일대일로 대체하는 것은 아닙니다.

Appraisal − 평가는 강점과 약점을 결정하기위한 기준으로 평가 참조 모델을 사용하여 훈련 된 전문가 팀이 하나 이상의 프로세스를 검사하는 것입니다.

Appraisal findings− 평가 범위 내에서 가장 중요한 문제, 문제 또는 기회를 식별하는 평가의 결론. 여기에는 최소한 유효한 관찰을 기반으로 한 강점과 약점이 포함됩니다.

Appraisal participants − 평가 중 정보 제공에 참여하는 조직 단위의 구성원.

Appraisal rating− CMMI 평가 자료에 사용 된대로, 평가 팀이 (1) CMMI 목표 또는 프로세스 영역, (2) 프로세스 영역의 능력 수준 또는 (3) 조직 단위의 성숙도 수준에 할당 한 값. 등급은 사용되는 평가 방법에 대해 정의 된 등급 프로세스를 제정하여 결정됩니다.

Appraisal reference model − CMMI 평가 자료에 사용 된 CMMI 모델은 평가 팀이 구현 된 프로세스 활동을 상호 연관시킵니다.

Appraisal scope − 조직 한계 및 CMMI 모델 한계를 포함하는 평가 경계의 정의.

Appraisal team leader − 평가 활동을 이끌고 평가 방법에 정의 된 경험, 지식 및 기술에 대한 자격 기준을 충족 한 사람.

Appropriate − Adequate에 대한 정의를 참조하십시오.

As needed − Adequate에 대한 정의를 참조하십시오.

Assessment − 평가는 조직이 프로세스 개선을 위해 자체적으로 수행하는 평가입니다.

Assignable cause of process variation− CMMI에서는 일관성을 보장하기 위해 "공정 변동의 할당 가능한 원인"대신 "공정 변동의 특수 원인"이라는 용어가 사용됩니다. 두 용어 모두 동일하게 정의됩니다.

Audit − 요구 사항이 충족되는지 여부를 결정하기 위해 작업 산출물 또는 일련의 산출물에 대한 독립적 인 검사.

Base measure − 개체의 고유 한 속성 또는 특성 및이를 정량화하는 방법.

Base practices − 연속 표현에서 능력 수준이 1 인 모든 특정 사례.

Baseline− 기준선이라는 용어는 일반적으로 이러한 기준점을 나타내는 데 사용됩니다. 기준선은 개발 수명주기의 적절한 지점에서 승인 된 시스템 스냅 샷입니다. 기준선은 후속 변경을 정의하기위한 공식 기반을 설정합니다. 이 선이나 기준점이 없으면 변화의 개념은 의미가 없습니다.

Business objectives − 조직의 지속적인 존재를 보장하고 수익성, 시장 점유율 및 조직의 성공에 영향을 미치는 기타 요인을 향상 시키도록 설계된 고위 경영진이 개발 한 전략.

Capability evaluation− 공급 업체 선택, 계약 모니터링 또는 인센티브를 위해 차별 자로 사용되는 숙련 된 전문가 팀의 평가. 평가는 의사 결정자가 더 나은 인수 결정을 내리고 하청 업체 성과를 개선하며 구매 조직에 통찰력을 제공하는 데 사용됩니다.

Capability level− 개별 프로세스 영역 내에서 프로세스 개선 달성. 능력 수준은 프로세스 영역에 대한 적절한 구체적이고 일반적인 관행에 의해 정의됩니다.

Capability level profile− 연속 표현에서 프로세스 영역 및 해당 능력 수준 목록. 프로필은 역량 수준을 통해 발전하면서 각 프로세스 영역에 대한 조직의 진행 상황을 나타낼 때 성취 프로필이 될 수 있습니다. 또는 프로파일이 프로세스 개선의 목표를 나타내는 경우 대상 프로파일이 될 수 있습니다.

Capability maturity model− CMM (Capability 성숙도 모델)에는 하나 이상의 분야에 대한 효과적인 프로세스의 필수 요소가 포함되어 있습니다. 또한 미성숙 한 임시 프로세스에서 품질과 효율성이 개선 된 체계적이고 성숙한 프로세스로 진화하는 개선 경로를 설명합니다.

Capable process − 지정된 제품 품질, 서비스 품질 및 프로세스 성능 목표를 충족 할 수있는 프로세스.

Causal analysis − 원인을 파악하기위한 결함 분석.

Change management − 제품 또는 서비스에 대한 변경 또는 제안 된 변경을 적용하기위한 수단의 합당한 사용.

CMMI appraisal tailoring− 특정 사례에서 사용하기위한 평가 방법 내 옵션 선택. 평가 조정의 목적은 조직이 비즈니스 목표에 따라 방법을 적용 할 수 있도록 지원하는 것입니다.

CMMI model component− CMMI 모델을 구성하는 모든 주요 아키텍처 요소. CMMI 모델의 주요 요소에는 특정 관행, 일반 관행, 특정 목표, 일반 목표, 프로세스 영역, 기능 수준 및 성숙도 수준이 포함됩니다.

CMMI model tailoring− 특정 애플리케이션에 적합하게 만들기위한 목적으로 CMMI 모델의 하위 집합 사용. 모델 조정의 목적은 조직이 비즈니스 목표에 맞게 모델을 적용 할 수 있도록 지원하는 것입니다.

CMMI Product Suite −이 용어는 완전한 CMMI 프레임 워크에 사용되었습니다.

Commitment to perform − 정책 생성 및 후원 확보와 관련된 일반적인 관행을 그룹화하는 단계적 표현이있는 CMMI 모델 프로세스 영역의 공통 기능.

Common cause of process variation − 공정 구성 요소 간의 정상 및 예상 상호 작용으로 인해 존재하는 공정의 변동.

Concept of operations − 법인이 사용되거나 운영되는 방식에 대한 일반적인 설명.

Configuration audit − 구성 항목이 지정된 표준 또는 요구 사항을 준수하는지 확인하기 위해 수행되는 감사.

Configuration baseline− 제품 또는 제품 구성 요소의 수명 중 특정 시간에 공식적으로 지정된 구성 정보. 구성 기준과 해당 기준에서 승인 된 변경 사항이 현재 구성 정보를 구성합니다.

Configuration control − 구성 식별을 공식적으로 설정 한 후 구성 항목에 대한 평가, 조정, 승인 또는 비 승인 및 변경 구현으로 구성된 구성 관리 요소.

Configuration control board − 구성 항목에 대해 제안 된 변경 사항을 평가 및 승인 또는 비 승인하고 승인 된 변경 사항을 구현할 책임이있는 사람 그룹.

Configuration identification − 제품의 구성 항목을 선택하고 고유 한 식별자를 할당하며 기술 문서에 기능 및 물리적 특성을 기록하는 것으로 구성된 구성 관리 요소.

Configuration item − 구성 관리를 위해 지정되고 구성 관리 프로세스에서 단일 개체로 취급되는 작업 산출물의 집합.

Configuration management− (1) 구성 항목의 기능 및 물리적 특성을 식별 및 문서화하고, (2) 해당 특성에 대한 변경을 제어하고, (3) 변경 처리 및 구현 상태를 기록하고보고하고, (1) 기술 및 관리 방향과 감시를 적용하는 분야 4) 지정된 요구 사항을 준수하는지 확인합니다. [IEEE Std 610.1990]

CMMI Model− CMMI 프레임 워크는이를 사용하는 조직의 필요에 따라 다른 모델을 생성 할 수 있으므로 여러 CMMI 모델이 있습니다. 따라서 "CMMI MODEL"이라는 문구는 많은 정보 모음 중 하나가 될 수 있습니다. "CMMI 모델"이라는 문구는 CMMI 프레임 워크에서 생성 할 수있는 하나, 일부 또는 전체 가능한 모델 모음을 나타냅니다.

Configuration status accounting− 구성을 효과적으로 관리하는 데 필요한 정보의 기록 및보고로 구성된 구성 관리의 요소. 이 정보에는 승인 된 구성 식별 목록, 구성에 대해 제안 된 변경 사항의 상태 및 승인 된 변경 사항의 구현 상태가 포함됩니다.

Continuous representation − 능력 수준이 각 지정된 프로세스 영역 내에서 프로세스 개선에 접근하기위한 권장 순서를 제공하는 능력 성숙도 모델 구조.

Corrective action − 상황을 해결하고 오류를 제거하거나 조건을 조정하는 데 사용되는 행위 또는 행동.

COTS − 상업용 공급 업체에서 구입할 수있는 항목.

Customer− 고객은 제품을 수락하거나 지불을 승인 할 책임이있는 개인, 프로젝트, 조직, 그룹 등입니다. 고객은 프로젝트 외부에 있지만 반드시 조직 외부에있는 것은 아닙니다. 고객이라는 용어는 요구 사항 수집 또는 추출을 논의 할 때 변수 역할도합니다.

Data management − 데이터 공유 및 관리를위한 원칙, 프로세스 및 시스템.

Defect density − 제품 크기 단위당 결함 수 (예 : 코드 1000 줄당 문제 보고서).

Defined process − 개선의 일부로 따라야 할 정의 된 일련의 단계.

Derived measures − 두 개 이상의 기본 측정 값의 수학적 함수로 인한 데이터.

Derived requirements− 고객 요구 사항에 명시되지 않았지만 (1) 상황 별 요구 사항 (예 : 적용 가능한 표준, 법률, 정책, 공통 관행 및 관리 결정)에서 유추 된 요구 사항 또는 (2) 제품을 지정하는 데 필요한 요구 사항에서 유추 된 요구 사항 구성 요소. 파생 된 요구 사항은 제품 또는 시스템 구성 요소의 분석 및 설계 중에 발생할 수도 있습니다.

Design review − 설계 요구 사항과 이러한 요구 사항을 충족하는 설계 기능을 평가하고 문제를 식별하고 솔루션을 제안하기위한 설계에 대한 공식적이고 문서화 된 포괄적이고 체계적인 검사.

Development− CMMI 전체에서 사용되는 개발은 유지 관리 활동과 개발 활동을 의미합니다. 경험에 따르면 조직이 엔지니어링 우수성을 추구하는 경우 개발 및 유지 관리 프로젝트 모두에 모범 사례를 적용해야합니다.

Developmental plan − 하나 이상의 제품의 설계 및 개발을 안내, 구현 및 제어하기위한 계획.

Directing implementation − CMMI 모델 프로세스 영역의 공통 기능은 프로세스의 성능 관리, 작업 제품의 무결성 관리 및 관련 이해 관계자와 관련된 일반적인 관행을 그룹화하는 단계적 표현을 사용합니다.

Discipline amplification− 특정 분야 (예 : 시스템 엔지니어링 또는 소프트웨어 엔지니어링)에 대한 모델 정보를 해석하기위한 지침을 제공하는 모델 구성 요소를 "DISCIPLINE AMPLIFICATIONS"라고합니다. 분야 증폭은 필요한 경우 다른 모델 구성 요소에 추가됩니다. 이들은 페이지 오른쪽에 나타나고 해당 분야를 나타내는 제목이 있기 때문에 쉽게 찾을 수 있습니다 (예 : "For Software Engineering").

Document− 문서는 기록 된 매체에 관계없이 데이터의 모음입니다. 일반적으로 영구성이 있으며 사람이나 기계가 읽을 수 있습니다. 문서에는 종이 문서와 전자 문서가 모두 포함됩니다.

Enterprise − Enterprise는 고객이 다른 여러 위치에있는 많은 조직으로 구성된 초대형 회사를 지칭하는 데 사용됩니다.

Entry criteria − 노력이 성공적으로 시작되기 전에 존재해야하는 존재 상태.

Equivalent staging − 등가 스테이징은 대상 스테이징을 사용한 결과를 단계별 표현의 성숙도 수준과 비교할 수 있도록 정의 된 연속 표현을 사용하여 생성 된 대상 스테이징입니다.

Exit criteria − 노력이 성공적으로 종료되기 전에 존재해야하는 존재 상태.

Expected CMMI components− 필수 CMMI 구성 요소를 충족하기 위해 수행 할 수있는 작업을 설명하는 CMMI 구성 요소. 모델 사용자는 예상되는 구성 요소를 명시 적으로 구현하거나 이러한 구성 요소에 대해 동등한 대체 방법을 구현할 수 있습니다. 구체적이고 일반적인 관행은 예상되는 모델 구성 요소입니다.

Finding − 평가 결과를 참조하십시오.

Formal evaluation process − 의사 결정 분석 및 해결 프로세스 영역에서 소개 노트의 "공식 평가 프로세스"정의를 참조하십시오.

Functional analysis− 해당 기능을 수행하는 데 필요한 모든 하위 기능을 식별하기위한 정의 된 기능 검사 기능적 관계 및 인터페이스 (내부 및 외부) 식별 및 기능 아키텍처에서이를 캡처 그리고 상위 수준의 성능 요구 사항의 흐름과 이러한 요구 사항을 하위 수준의 하위 기능에 할당합니다.

Functional architecture − 기능의 계층 적 배열, 내부 및 외부 (집계 자체의 외부) 기능 인터페이스 및 외부 물리적 인터페이스, 각각의 기능 및 성능 요구 사항, 디자인 제약.

Generic goal− GENERIC GOALS는 동일한 목표 설명이 여러 프로세스 영역에 나타나기 때문에 "일반"이라고합니다. 단계별 표현에서 각 프로세스 영역에는 하나의 일반 목표 만 있습니다. 프로세스 영역에서 일반적인 목표를 달성한다는 것은 해당 프로세스 영역과 관련된 프로세스를 계획하고 구현하는 데있어 향상된 제어를 의미하므로 이러한 프로세스가 효과적이고 반복 가능하며 지속될 수 있는지 여부를 나타냅니다. 일반 목표는 필수 모델 구성 요소이며 프로세스 영역이 충족되는지 여부를 결정하기 위해 평가에 사용됩니다.

Generic practice− 일반 관행은 프로세스 영역과 관련된 프로세스가 효과적이고 반복 가능하며 지속될 수 있도록 제도화를 제공합니다. 일반 관행은 일반 목표와 공통 기능으로 분류되며 CMMI 모델에서 예상되는 구성 요소입니다. (일반 진료 제목, 진술 및 상세 정보 만 프로세스 영역에 나타납니다.)

Generic practice elaboration− 특정 관행 후에는 프로세스 영역에 적용되는 일반 관행 제목 및 설명이 나타납니다. 각각의 일반 실무 진술 후에는 "정교화"라는 제목과 함께 일반 텍스트로 정교화가 나타날 수 있습니다. GENERIC PRACTICE ELABORATION은 프로세스 영역에 대해 일반 관행을 해석하는 방법에 대한 정보를 제공합니다. 정교함이없는 경우 정교함없이 일반적인 관행의 적용이 분명합니다.

Goal− "목표"는 일반적인 목표 또는 특정 목표가 될 수있는 필수 CMMI 구성 요소입니다. CMMI 모델에서 "목표"라는 단어는 항상 모델 구성 요소 (예 : 일반 목표, 특정 목표)를 나타냅니다.

Incomplete process− 수행되지 않거나 부분적으로 만 수행되는 프로세스 (능력 수준 0이라고도 함). 프로세스 영역의 특정 목표 중 하나 이상이 충족되지 않습니다.

Independent group − 프로세스 및 제품 품질 보증 프로세스 영역에서 소개 노트의 "독립적 인 그룹"에 대한 설명을 참조하십시오.

Informative CMMI components− 모델 사용자가 모델의 필수 구성 요소와 예상 구성 요소를 이해하는 데 도움이되는 CMMI 구성 요소. 이러한 구성 요소에는 예, 자세한 설명 또는 기타 유용한 정보가 포함될 수 있습니다. 하위 연습, 메모, 참조, 목표 제목, 연습 제목, 소스, 일반적인 작업 산출물, 규율 확대 및 일반 연습 정교화는 정보를 제공하는 모델 구성 요소입니다.

Institutionalization − 조직이 기업 문화의 일부로 일상적으로 따르는 비즈니스 수행 방식.

Integrated Product and Process Development − 고객의 요구를보다 잘 충족시키기 위해 제품 수명주기 전반에 걸쳐 관련 이해 관계자들의 적시 협력을 달성하는 제품 개발에 대한 체계적인 접근 방식.

Integrated team− 적시에 협력하여 특정 작업 제품을 제공하기 위해 노력하는 보완 기술과 전문 지식을 갖춘 사람들의 그룹. 통합 된 팀 구성원은 작업 산출물의 모든 단계에 적합한 기술과 옹호를 제공하고 지정된대로 산출물을 제공 할 공동 책임을집니다. 통합 팀에는 작업 제품의 성공에 영향을 미치는 조직, 분야 및 기능의 권한을 부여받은 대표가 포함되어야합니다.

Interface control− 구성 관리에서 (1) 하나 이상의 조직에서 제공하는 둘 이상의 구성 항목의 인터페이스와 관련된 모든 기능 및 물리적 특성을 식별하고 (2) 이러한 특성에 대해 제안 된 변경 사항을 평가하고 승인하도록 보장하는 프로세스 구현하기 전에. [IEEE 828-1983].

Lead appraiser − CMMI Product Suite에서 사용되는 바와 같이, 특정 평가 방법에 대한 평가 팀 리더로 수행 할 권한을 부여하는 기관으로부터 인정을받은 사람.

Life-cycle model − 제품 수명을 프로젝트가 고객의 요구 사항을 식별하는 단계부터 제품 폐기까지 안내하는 단계로 분할.

Manager− 프로젝트 관리자는 프로젝트를 계획, 지시, 통제, 구조화 및 동기를 부여 할 책임이있는 사람입니다. 그 또는 그녀는 자신의 책임 영역 내에서 프로젝트 작업이나 활동을 수행하는 사람들에게 기술 및 관리 방향과 통제를 모두 제공 할 수 있습니다. 프로젝트 관리자는 궁극적으로 고객에 대한 책임이 있습니다.

Maturity level − 세트 내의 모든 목표가 달성되는 사전 정의 된 프로세스 영역 세트에 대한 프로세스 개선 정도.

Memorandum of agreement − 둘 이상의 당사자 간의 이해 또는 합의에 대한 구속력있는 문서.

Natural bounds− 때때로 "프로세스의 목소리"라고도하는 프로세스 성능 측정에 반영된 고유 프로세스. 관리도, 신뢰 구간 및 예측 구간과 같은 기법을 사용하여 변동이 공통 원인 (예 : 공정이 예측 가능한지 또는 "안정적"인지)으로 인한 것인지 아니면 식별 할 수 있고 식별해야하는 특수 원인으로 인한 것인지 확인합니다. 제거되었습니다.

Non-developmental item− 취득 또는 개발 프로세스에서 현재 사용되기 전에 개발 된 공급 품목. 이러한 항목은 현재 의도 된 용도의 요구 사항을 충족하기 위해 약간의 수정이 필요할 수 있습니다.

Nontechnical requirements− 제품 또는 서비스를 획득하는 방법에 영향을 미치는 계약 조항, 약속, 조건 및 조건. 예를 들어 배달 할 제품, 배달 된 상용 (COTS) 비 개발 품목 (NDI)에 대한 데이터 권한, 배달 날짜 및 종료 기준이있는 이정표가 있습니다. 기타 비 기술적 요구 사항에는 교육 요구 사항, 사이트 요구 사항 및 배포 일정이 포함됩니다.

Objective− 목표라는 용어는 CMMI에서 일상적인 의미로 사용됩니다. 이것이 우리의 목표 또는 목표입니다.

Objective evidence − CMMI 평가 자료, 정 성적 또는 정량적 정보, 기록 또는 항목이나 서비스의 특성 또는 관찰, 측정 또는 테스트를 기반으로하는 프로세스 요소의 존재 및 구현과 관련된 사실 진술에 사용됩니다. 확인할 수 있습니다.

Objectively evaluate− 검토 자의 주관성과 편견을 최소화하는 기준에 따라 활동 및 작업 산출물을 검토합니다. 객관적인 평가의 예로는 독립적 인 품질 보증 기능에 의한 요구 사항, 표준 또는 절차에 대한 감사가 있습니다.

Observation− CMMI 평가 자료에 사용 된대로, 평가 데이터 수집 활동 중에 보거나들은 정보에 대한 평가 팀 구성원의 이해를 나타내는 서면 기록. 서면 기록은 진술의 형태를 취하거나 정보 내용이 보존되는 한 대체 형식을 취할 수 있습니다.

Operational concept − 법인이 사용되거나 운영되는 방식에 대한 일반적인 설명.

Operational scenario− 제품 구성 요소 간의 상호 작용뿐 아니라 제품과 환경 및 사용자 간의 상호 작용을 포함하는 상상 된 일련의 이벤트에 대한 설명. 운영 시나리오는 시스템의 요구 사항과 설계를 평가하고 시스템을 확인 및 검증하는 데 사용됩니다.

Optimizing process− 공정에 내재 된 변동의 일반적인 원인에 대한 이해를 기반으로 개선 된 정량적으로 관리되는 공정. 점진적 및 혁신적인 개선을 통해 프로세스 성능의 범위를 지속적으로 개선하는 데 초점을 맞춘 프로세스입니다.

Organization − 조직은 사람들이 하나 이상의 프로젝트를 전체적으로 관리하고 해당 프로젝트가 고위 관리자를 공유하고 동일한 정책에 따라 운영되는 구조입니다.

Organization's business objectives − 조직의 지속적인 존재를 보장하고 수익성, 시장 점유율 및 조직의 성공에 영향을 미치는 기타 요인을 향상시키기 위해 고위 경영진이 개발 한 전략.

Organizational maturity− 조직이 문서화, 관리, 측정, 제어 및 지속적으로 개선되는 프로세스를 명시적이고 일관되게 배포 한 정도. 조직의 성숙도는 평가를 통해 측정 할 수 있습니다.

Organizational policy − 결정에 영향을 미치고 결정하기 위해 조직이 채택한 고위 경영진이 일반적으로 수립 한 지침 원칙.

Organizational unit− 평가 대상이되는 조직의 부분 (평가의 조직 범위라고도 함) 조직 단위는 일관된 프로세스 컨텍스트를 갖고 일관된 비즈니스 목표 내에서 작동하는 하나 이상의 프로세스를 배포합니다. 조직 단위는 일반적으로 더 큰 조직의 일부이지만 소규모 조직에서는 조직 단위가 전체 조직 일 수 있습니다.

Outsourcing − 계약을 통해 제품 및 서비스를 획득하기 위해 투자하기로 약속 한 인수 주체의 개별 조치 또는 제안 된 조치를 획득하는 프로세스.

Peer review − 결과물의 결함을 찾기 위해 동료가 수행 한 검토.

Performance parameters − 점진적 개발을 안내하고 통제하는 데 사용되는 효과 측정 및 기타 주요 측정.

Performed process− 식별 된 입력 작업 산출물 (역량 수준 1이라고도 함)을 사용하여 식별 된 산출물 산출물을 생산하는 데 필요한 작업을 수행하는 프로세스. 프로세스 영역의 특정 목표가 충족됩니다.

Planned process− 설명과 계획으로 문서화 된 프로세스. 설명과 계획은 조정되어야하며 계획에는 표준, 요구 사항, 목표, 자원, 할당 등이 포함되어야합니다.

Process − 사람들이 시스템 및 관련 제품을 개발하고 유지하는 데 사용하는 일련의 활동, 방법, 관행 및 변형.

Process action plan − 조직 프로세스 초점 프로세스 영역에서 소개 노트의 "프로세스 실행 계획"정의를 참조하십시오.

Process action team − 프로세스 개선 실행 계획에 문서화 된대로 조직을위한 프로세스 개선 활동을 개발하고 구현할 책임이있는 팀.

Process and technology improvements − 조직 혁신 및 배포 프로세스 영역에서 소개 노트의 "프로세스 및 기술 개선"에 대한 설명을 참조하십시오.

Process area− 프로세스 영역은 집단적으로 수행 될 때 해당 영역에서 중요한 개선을 이루는 데 중요하다고 간주되는 일련의 목표를 충족하는 영역의 관련 관행의 클러스터입니다. 모든 CMMI 프로세스 영역은 연속 및 단계적 표현 모두에 공통입니다. 단계적 표현에서 프로세스 영역은 성숙도별로 구성됩니다.

Process asset − 조직이 프로세스 영역의 목표를 달성하는 데 유용하다고 생각하는 모든 것.

Process asset library − 조직 또는 프로젝트에서 사용할 수있는 프로세스 자산 보유의 모음.

Process attribute − 모든 공정에 적용 할 수있는 공정 능력의 측정 가능한 특성.

Process capability − 프로세스를 따라 달성 할 수있는 예상 결과의 범위.

Process context− 평가 입력에 문서화 된 일련의 요소로 평가 등급의 판단 및 비교 가능성에 영향을 미칩니다. 여기에는 평가할 조직 단위의 규모가 포함되지만 이에 국한되지는 않습니다. 조직 단위의 인구 통계; 제품 또는 서비스의 적용 분야; 제품 또는 서비스의 크기, 중요도 및 복잡성 제품 또는 서비스의 품질 특성.

Process definition− 프로세스를 정의하고 설명하는 행위. 프로세스 정의의 결과는 프로세스 설명입니다.

Process description− 프로세스의 주요 구성 요소에 대한 운영 정의를 제공하는 주어진 목적을 달성하기 위해 수행 된 일련의 활동에 대한 문서화 된 표현. 문서는 프로세스의 요구 사항, 설계, 동작 또는 기타 특성을 완전하고 정확하며 검증 가능한 방식으로 지정합니다. 또한 이러한 조항이 충족되었는지 여부를 결정하는 절차가 포함될 수 있습니다. 프로세스 설명은 활동, 프로젝트 또는 조직 수준에서 찾을 수 있습니다.

Process element− 프로세스의 기본 단위. 프로세스는 하위 프로세스 또는 프로세스 요소의 관점에서 정의 될 수 있습니다. 하위 프로세스는 추가로 분해 될 수 있습니다. 프로세스 요소는 할 수 없습니다. 각 프로세스 요소는 밀접하게 관련된 일련의 활동을 다룹니다 (예 : 추정 요소, 피어 리뷰 요소). 프로세스 요소는 완성 할 템플릿, 정제 할 추상화 또는 수정하거나 사용할 설명을 사용하여 묘사 할 수 있습니다. 프로세스 요소는 활동 또는 작업이 될 수 있습니다.

Process group − 조직에서 사용하는 프로세스의 정의, 유지 관리 및 개선을 용이하게하는 전문가 모음.

Process improvement − 조직 프로세스의 성능과 성숙도 및 그러한 프로그램의 결과를 개선하기 위해 설계된 활동 프로그램.

Process-improvement objectives − 결과 제품 특성 (예 : 품질, 성능, 표준 준수 등) 측면에서 또는 프로세스가 진행되는 방식에서 특정 측정 가능한 방식으로 기존 프로세스를 개선하려는 노력을 안내하기 위해 설정된 목표 특성 세트 실행 됨 (예 : 중복 프로세스 단계 제거, 프로세스 단계 결합,주기 시간 개선 등)

Process-improvement plan − 조직 프로세스 초점 프로세스 영역에서 소개 노트의 "프로세스 개선 계획"정의를 참조하십시오.

Process measurement − 프로세스를 특성화하고 이해하기 위해 프로세스 및 그 결과 제품을 측정하는 데 사용되는 정의, 방법 및 활동 세트.

Process owner− 프로세스 정의 및 유지를 담당하는 사람 (또는 팀). 조직 수준에서 프로세스 소유자는 표준 프로세스 설명을 담당하는 사람 (또는 팀)입니다. 프로젝트 수준에서 프로세스 소유자는 정의 된 프로세스의 설명을 담당하는 사람 (또는 팀)입니다. 따라서 프로세스에는 서로 다른 책임 수준에서 여러 소유자가있을 수 있습니다.

Process performance− 프로세스에 따라 달성 된 실제 결과의 척도. 프로세스 측정 (예 : 노력,주기 시간 및 결함 제거 효율성)과 제품 측정 (예 : 신뢰성, 결함 밀도 및 응답 시간)이 특징입니다.

Process performance baseline − 실제 프로세스 성능과 예상 프로세스 성능을 비교하기위한 벤치 마크로 사용되는 프로세스를 따라 달성 한 실제 결과의 문서화 된 특성화.

Process performance model − 과거 프로세스 성능 데이터에서 개발되고 프로젝트에서 수집 된 프로세스 및 제품 측정을 사용하여 보정되고 프로세스를 따라 달성 할 결과를 예측하는 데 사용되는 프로세스 및 작업 제품의 속성 간의 관계에 대한 설명.

Process tailoring− 특정 목적에 대한 프로세스 설명을 작성, 변경 또는 조정합니다. 예를 들어, 프로젝트는 조직의 표준 프로세스 집합에서 정의 된 프로세스를 조정하여 프로젝트의 목표, 제약 조건 및 환경을 충족합니다.

Product− 제품은 프로세스를 따른 결과이며 고객 또는 최종 사용자에게 제공하기위한 모든 유형의 산출물 또는 서비스로 간주 될 수 있습니다. 제품은 계약에 따라 고객에게 전달되는 모든 작업 제품 일 수도 있습니다.

Product component− 제품 구성 요소는 일반적으로 제품의 하위 수준 구성 요소이며 제품을 "구축"하기 위해 통합됩니다. 제품 구성 요소는 고객에게 제공되는 제품의 일부이거나 제품의 제조 또는 사용에 사용될 수 있습니다. 예를 들어, 휴대폰 배터리를 제조하는 회사의 경우 휴대폰 배터리가 제품입니다. 휴대폰을 제작하고 제공하는 회사의 경우 배터리는 제품 구성 요소입니다.

Product baseline − 구성 관리에서 초기 승인 된 기술 데이터 패키지 (소프트웨어의 경우 소스 코드 목록 포함)는 해당 수명주기의 생산, 운영, 유지 관리 및 물류 지원 중에 구성 항목을 정의합니다.

Product-component requirements − 제품 구성 요소 요구 사항은 적합성, 형태, 기능, 성능 및 기타 요구 사항을 포함하여 제품 구성 요소의 완전한 사양을 제공합니다.

Product life cycle− 작업 산출물은 라이프 사이클 프로세스에 의해 생성 된 모든 산출물이며 라이프 사이클 작업 산출물이라고도합니다. 수명주기 작업 제품에는 요구 사항 사양, 인터페이스 사양, 아키텍처 사양, 프로젝트 계획, 설계 문서, 단위 테스트 계획, 통합 및 시스템 테스트 계획, 제조 제품 조립 프로세스와 같은 프로세스가 포함될 수 있습니다.

Project− 프로젝트는 고객이나 최종 사용자에게 하나 이상의 제품을 제공하는 관리되는 상호 관련된 리소스 집합입니다. 자원 세트에는 명확한 시작과 끝이 있으며 계획에 따라 작동합니다.

Product line − 선택한 시장 또는 임무의 특정 요구를 충족하는 공통 관리 기능 세트를 공유하는 제품 그룹.

Product-related life-cycle processes − 제조 및 지원 프로세스와 같이 제품 수명의 하나 이상의 단계 (예 : 구상부터 폐기까지)에 걸쳐 제품과 관련된 프로세스.

Product requirements − 고객 요구 사항을 개발자의 언어로 구체화하여 암시 적 요구 사항을 명시 적으로 파생 된 요구 사항으로 만듭니다.

Program− (1) 프로젝트. (2) 목표, 방법, 활동, 계획 및 성공 척도를 포함하여 관련 프로젝트 및이를 지원하는 인프라 모음.

Project manager− 프로젝트 관리자는 프로젝트를 계획, 지시, 통제, 구조화 및 동기를 부여 할 책임이있는 사람입니다. 그 또는 그녀는 자신의 책임 영역 내에서 프로젝트 작업이나 활동을 수행하는 사람들에게 기술 및 관리 방향과 통제를 모두 제공 할 수 있습니다. 프로젝트 관리자는 궁극적으로 고객에 대한 책임이 있습니다. 프로젝트 관리자는 프로젝트의 규모, 다양성 및 복잡성이 변경됨에 따라 다양한 역할과 책임을 맡습니다.

Project progress and performance − 노력, 비용, 일정 및 기술 성과를 포함하여 프로젝트 계획 실행과 관련하여 프로젝트가 달성하는 것.

Project's defined process − 통합 프로젝트 관리 프로세스 영역에서 소개 노트 및 프로젝트 정의 프로세스 설정 특정 사례의 "프로젝트 정의 프로세스"정의를 참조하십시오.

Prototype − 이후 단계 또는 제품의 최종 완성 버전에 대한 모델 역할을하는 제품 또는 제품 구성 요소의 예비 유형, 형태 또는 인스턴스.

Quality − 고객의 요구 사항을 충족하기위한 제품, 제품 구성 요소 또는 프로세스의 고유 한 특성 집합의 능력.

Quality assurance − 프로세스의 표준, 관행, 절차 및 방법을 정의한 경영진을 보장하기위한 계획되고 체계적인 수단.

Quality control − 품질 요구 사항을 충족하는 데 사용되는 운영 기술 및 활동.

Quantitative objective − 정량적 측정으로 표현 된 원하는 목표 값.

Quantitatively managed process− 통계적 및 기타 정량적 기법을 사용하여 제어되는 정의 된 프로세스. 제품 품질, 서비스 품질 및 프로세스 성능 속성은 프로젝트 전체에서 측정 및 제어됩니다.

Reference mode − 일부 속성을 측정하기위한 벤치 마크로 사용되는 모델.

Relevant stakeholder − 관련 이해 관계자는 특정 활동에 참여하도록 식별되고 프로젝트 계획과 같은 적절한 계획에 포함 된 이해 관계자를 지정하는 데 사용됩니다.

Required CMMI components− 주어진 프로세스 영역에서 프로세스 개선을 달성하는 데 필수적인 CMMI 구성 요소. 이러한 구성 요소는 공정 능력을 결정하기 위해 평가에 사용됩니다. 특정 목표와 일반적인 목표는 필수 모델 구성 요소입니다.

Requirement− (1) 사용자가 문제를 해결하거나 목표를 달성하는 데 필요한 조건 또는 기능. (2) 계약, 표준, 사양 또는 기타 공식적으로 부과 된 문서를 충족하기 위해 제품 또는 제품 구성 요소가 충족하거나 소유해야하는 조건 또는 기능. (3) (1) 또는 (2)에서와 같은 조건 또는 능력의 문서화 된 표현.

Requirements analysis− 고객의 요구, 기대 및 제약 분석을 기반으로 한 제품 별 성능 및 기능적 특성 결정 운영 개념; 사람, 제품 및 프로세스에 대한 예상 활용 환경; 및 효과 측정.

Requirements elicitation − 프로토 타입 및 구조화 된 설문 조사와 같은 체계적인 기술을 사용하여 고객 및 최종 사용자 요구를 사전에 식별하고 문서화합니다.

Requirements management − 기술 및 비 기술적 요구 사항과 조직이 프로젝트에 부과하는 요구 사항을 포함하여 프로젝트에서 받거나 생성 한 모든 요구 사항의 관리.

Requirements traceability − 요구 사항과 소스 요구 사항, 구현 및 검증 간의 연관성에 대한 증거.

Return on investment − 생산 (제품)에서 생산 비용에 대한 수익의 비율. 조직이 무언가를 생산하기위한 조치를 수행함으로써 이익을 얻었는지 여부를 결정합니다.

Risk analysis − 위험의 평가, 분류 및 우선 순위 지정.

Risk identification − 목표 달성에있어 가능성이 있거나 현실적인 위험을 찾기위한 체계적이고 철저한 접근 방식.

Risk management − 위해 또는 손실을 유발할 수있는 요소를 식별하고 (위험 식별), 식별 된 위험을 평가 및 정량화하고, 심각한 위해를 초래할 수있는 위험 원인을 예방 또는 처리하기위한 적절한 접근 방식을 개발하고 구현하기위한 체계적인 분석 프로세스 또는 손실.

Risk management strategy− 위해 또는 손실을 유발할 수있는 요소를 식별하고 (위험 식별), 식별 된 위험을 평가 및 정량화하고, 심각한 위해 또는 손실을 초래할 수있는 위험 원인을 예방 또는 처리하기위한 적절한 접근법을 개발하고 필요한 경우 구현하기위한 체계적이고 기술적 접근 방식 . 일반적으로 위험 관리는 프로젝트, 조직 또는 제품 개발 조직 단위에 대해 수행됩니다.

Root cause − 근본 원인은 결함이 제거되면 결함이 감소하거나 제거되는 결함의 원인입니다.

Senior manager− CMMI에서 사용되는 고위 관리자라는 용어는 사람의 주된 초점이 단기 프로젝트가 아닌 조직의 장기적인 건강과 성공 인 조직에서 충분히 높은 수준의 관리 역할을 의미합니다. 계약상의 우려와 압력. 선임 관리자는 프로젝트 관리자가 관리하는 많은 프로젝트를 포함 할 수있는 프로그램을 감독 할 책임이 있습니다.

Software engineering− (1) 소프트웨어의 개발, 운영 및 유지 관리에 대한 체계적이고 규율 적이며 정량화 가능한 접근 방식의 적용. (2) (1)과 같은 접근법 연구.

Solicitation − 모집 패키지를 준비하고 공급 업체 (계약자)를 선택하는 프로세스.

Solicitation package− 입찰 초대 (입찰) 및 제안 요청 (제안)에 대한 제안을 요청하거나 기능 설명 및 가격 견적 (견적)을 요청하는 데 사용되는 기술적 및 비 기술적 요구 사항을 설명하는 공식 문서. 그렇지 않으면 제품 또는 서비스를 제공하기 위해 공급처를 선택하는 기준으로 사용됩니다.

Special cause of process variation − 공정의 고유 한 부분이 아니라 일부 일시적인 상황에 특정한 결함의 원인.

Specific goal− SPECIFIC GOALS는 프로세스 영역에 적용되며 프로세스 영역을 충족하기 위해 구현해야하는 사항을 설명하는 고유 한 특성을 다룹니다. 특정 목표는 필수 모델 구성 요소이며 프로세스 영역이 충족되는지 여부를 결정하는 데 도움이되는 평가에 사용됩니다.

Specific practice− SPECIFIC PRACTICE는 관련 특정 목표를 달성하는 데 중요하다고 간주되는 활동입니다. 특정 관행은 프로세스 영역의 특정 목표를 달성 할 것으로 예상되는 활동을 설명합니다. 특정 사례는 예상되는 모델 구성 요소입니다.

Stable process − 공정 변동의 모든 특수 원인이 제거되고 재발이 방지되어 공정 변동의 일반적인 원인 만 남아있는 상태.

Staged representation-일련의 프로세스 영역의 목표를 달성하면 성숙도 수준이 설정되는 모델 구조 각 레벨은 후속 레벨의 기초를 구축합니다.

Stakeholder − 이해 관계자는 프로젝트의 결과에 영향을 받거나 프로젝트의 활동 또는 결과에 영향을 미칠 수있는 그룹 또는 개인입니다.

Standard process− 조직의 공통 프로세스 설정을 안내하는 기본 프로세스의 운영 정의. 표준 프로세스는 정의 된 프로세스에 통합 될 것으로 예상되는 기본 프로세스 요소를 설명합니다. 또한 이러한 프로세스 요소 간의 관계 (예 : 순서 및 인터페이스)를 설명합니다.

Statement of work − 프로젝트를 완료하는 데 필요한 계약 작업에 대한 설명.

Statistical predictability − 통계적 및 기타 정량적 기법을 사용하여 제어되는 정량적 프로세스의 성능.

Statistical process control − 통계 기반의 공정 분석 및 공정 성능 측정, 공정 성능 변동의 공통 및 특수 원인을 식별하고 한계 내에서 공정 성능을 유지합니다.

Statistical techniques − 통계적 방법을 사용하는 분석 기법 (예 : 통계적 공정 제어, 신뢰 구간, 예측 구간).

Statistically managed process − 프로세스를 분석하고 프로세스 변동의 특수 원인을 식별하며 성능이 잘 정의 된 한계 내에 포함되는 통계 기반 기술로 관리되는 프로세스.

Strength − CMMI 평가 자료에 사용 된 CMMI 모델 관행의 모범적이거나 주목할만한 구현.

Sub-process − 더 큰 프로세스의 일부인 프로세스.

Supplier− (1) 인수중인 제품을 제공하거나 서비스를 수행하는 기업. (2) 계약 (계약) 조건에 따라 품목의 설계, 개발, 제조, 유지, 수정 또는 공급을 위해 인수와 계약 (계약) 한 개인, 파트너쉽, 회사, 법인, 협회 또는 기타 서비스 ).

Sustainment− 최종 사용자 또는 고객이 제품을 운영 적으로 활용할 수 있도록하는 데 사용되는 프로세스. Sustainment는 고객 또는 최종 사용자가 제품을 사용하는지 여부에 관계없이 제품이 작동 가능한 상태에 있도록 유지 관리가 수행되도록합니다.

Systems engineering− 일련의 고객 요구, 기대 및 제약을 제품 솔루션으로 변환하고 제품 수명 내내 해당 솔루션을 지원하는 데 필요한 전체 기술 및 관리 노력을 관리하는 학제 간 접근 방식. 여기에는 기술 성능 측정의 정의, 제품 아키텍처 구축을위한 엔지니어링 전문 분야의 통합, 비용, 성능 및 일정 목표 간의 균형을 유지하는 지원 수명주기 프로세스의 정의가 포함됩니다.

Tailoring guidelines− 프로세스 조정은 특정 프로젝트에 사용하기 위해 일반적으로 조직 수준에서 설명되는 프로세스 설명을 작성, 변경 또는 조정합니다. 대부분의 조직에서 하나의 조직 프로세스 정의는 모든 프로젝트에 대해 100 % 따를 수 없거나 따르지 않을 것입니다. 일반적으로 약간의 적응이 필요합니다. 조정 가이드 라인은 수정 될 수있는 것과 수정 될 수없는 것을 설명하고 수정 가능한 후보가되는 프로세스 구성 요소를 식별합니다.

Target profile − 연속 표현에서 프로세스 개선의 목표를 나타내는 프로세스 영역 및 해당 능력 수준의 목록.

Target staging − 연속 표현에서 조직이 따라야 할 프로세스 개선 경로를 설명하는 일련의 대상 프로필.

Technical data package − 해당 정보가 제품 유형 및 제품 구성 요소에 적합한 경우 다음을 포함 할 수있는 항목 모음.

Technical requirements − 취득 또는 개발할 제품 또는 서비스의 속성 (속성).

Test procedure − 주어진 테스트에 대한 결과의 설정, 실행 및 평가에 대한 자세한 지침.

Trade study − 결정된 목표를 달성하기위한 최상의 대안을 선택하기 위해 기준 및 체계적인 분석을 기반으로 한 대안 평가.

Training− 조직 교육 프로세스 영역에서 .training의 정의를 참조하십시오. 소개 노트에서.

Unit testing − 개별 하드웨어 또는 소프트웨어 장치 또는 관련 장치 그룹 테스트.

Validation− 검증은 제공된 제품 (또는 제공 될 제품)이 운영 환경에서 의도 된 용도를 충족 함을 입증합니다. 검증은 "당신이 올바른 것을 만들었습니다."

Verification− 검증에는 고객, 제품 및 제품 구성 요소 요구 사항을 포함하여 선택된 모든 요구 사항에 대한 제품 및 중간 작업 제품의 검증이 포함됩니다. 검증은 본질적으로 증분 프로세스입니다. 요구 사항의 확인으로 시작하여 진화하는 작업 제품의 확인을 거쳐 완성 된 제품의 확인으로 끝납니다. 검증은 작업 산출물이 지정된 요구 사항을 적절히 반영하는지 여부를 다룹니다. 검증을 통해 "당신이 올바르게 구축했습니다."

Verifying implementation − CMMI 모델 프로세스 영역의 공통 기능은 상위 수준 관리에 의한 검토와 관련된 일반 관행을 그룹화하고 프로세스 설명, 절차 및 표준에 대한 적합성의 객관적인 평가를 그룹화하는 단계적 표현을 사용합니다.

Version control − 기준선의 설정 및 유지, 이전 기준선으로 돌아갈 수 있도록하는 기준선의 변경 확인.

Weakness − CMMI 평가 자료에 사용 된 바와 같이 하나 이상의 CMMI 모델 관행의 비 효과적 또는 구현 부족.

Work breakdown structure − 작업 요소의 배열 및 서로간에 그리고 최종 제품에 대한 관계.

Work product− WORK PRODUCT라는 용어는 CMMI Product Suite 전체에서 프로세스에 의해 생성 된 아티팩트를 의미하는 데 사용됩니다. 이러한 아티팩트에는 파일, 문서, 제품의 일부, 서비스, 프로세스, 사양 및 송장이 포함될 수 있습니다. 작업 제품으로 간주되는 프로세스의 예로는 제품에 대한 제조 프로세스, 교육 프로세스 및 폐기 프로세스가 있습니다. 작업 제품과 제품 구성 요소의 주요 차이점은 작업 제품을 엔지니어링하거나 최종 제품의 일부일 필요가 없다는 것입니다.

Work product and task attributes− 프로젝트 작업을 추정하는 데 사용되는 제품, 서비스 및 프로젝트 작업의 특성. 이러한 특성에는 크기, 복잡성, 무게, 형태, 적합 또는 기능과 같은 항목이 포함됩니다. 일반적으로 다른 프로젝트 및 리소스 견적 (예 : 노력, 비용, 일정)을 도출하기위한 하나의 입력으로 사용됩니다.

다음은 알파벳 순서로 정렬 된 모든 CMMI 약어 목록입니다.

두문자어 확장 된 양식
CMMI에 대한 평가 요건
CAF CMM 평가 프레임 워크
인과 관계 분석 및 해결 (프로세스 영역)
CAU Cockpit Avionics 업그레이드
CBA IPI 내부 프로세스 개선을위한 CMM 기반 평가
CBT 컴퓨터 기반 교육
CCB 구성 제어 보드
센티미터 구성 관리 (프로세스 영역)
CMM 기능 성숙도 모델
CMMI 능력 성숙도 모델 통합
CMMI-SE / SW 시스템 엔지니어링 및 소프트웨어 엔지니어링을위한 기능 성숙도 모델 통합
CMMI-SE / SW / IPPD 시스템 엔지니어링, 소프트웨어 엔지니어링, 통합 제품 및 프로세스 개발을위한 기능 성숙도 모델 통합
CMMI-SE / SW / IPPD / SS 시스템 엔지니어링, 소프트웨어 엔지니어링, 통합 제품 및 프로세스 개발, 공급 업체 소싱을위한 기능 성숙도 모델 통합
간이 침대 선반에서 상업용
CPM 중요 경로 방법
DAR 의사 결정 분석 및 해결 (프로세스 영역)
EIA 전자 산업 연합
EIA / IS Electronic Industries Alliance 임시 표준
FAA 미국 연방 항공국
FAA-iCMM 연방 항공국 통합 기능 성숙 모델
GG 일반적인 목표
GP 일반 관행
이상 시작, 진단, 확립, 행동, 학습
IEEE 전기 전자 공학회
INCOSE 시스템 공학에 관한 국제 협의회
IPD-CMM 통합 제품 개발 기능 성숙도 모델
IPM 통합 프로젝트 관리 (프로세스 영역)
IPPD 통합 제품 및 프로세스 개발
IPT 통합 제품 팀
주의 통합 공급 업체 관리 (공정 영역)
ISO 국제 표준화기구
ISO / IEC 국제 표준화기구 및 국제 전기 기술위원회
그것 통합 팀 구성 (프로세스 영역)
KSLOC 수천 개의 소스 코드 라인
엄마 측정 및 분석 (공정 영역)
MOA 양해 각서
NDI 비 발달 항목
NDIA 국방 산업 협회
OEI 통합을위한 조직 환경 (프로세스 영역)
OID 조직 혁신 및 배포 (프로세스 영역)
OPD 조직 프로세스 정의 (프로세스 영역)
OPF 조직 프로세스 초점 (프로세스 영역)
OPP 조직 프로세스 성능 (프로세스 영역)
OT 조직 교육 (프로세스 영역)
OUSD / AT & L 국방, 인수, 기술 및 물류 담당 차관실
P-CMM 사람 기능 성숙 모델
아빠 공정 영역
PAIS 프로세스 평가 정보 시스템
통과하다 기본 항공 전자 소프트웨어 시스템
건방진 프로그램 평가 및 검토 기법
PI 제품 통합 (공정 영역)
PMC 프로젝트 모니터링 및 제어 (공정 영역)
PP 프로젝트 계획 (프로세스 영역)
PPQA 공정 및 제품 품질 보증 (공정 영역)
QFD 품질 기능 배포
QPM 정량적 프로젝트 관리 (프로세스 영역)
RD 요구 사항 개발 (프로세스 영역)
REQM 요구 사항 관리 (프로세스 영역)
RSKM 리스크 관리 (프로세스 영역)
SA-CMM 소프트웨어 획득 기능 성숙도 모델
SAM 공급자 계약 관리 (프로세스 영역)
사기 프로세스 개선을위한 표준 CMMI 평가 방법
SDMP 소프트웨어 개발 관리 계획
SE 시스템 공학
SE-CMM 시스템 엔지니어링 기능 성숙도 모델
비서 소프트웨어 집행위원회
SECAM 시스템 엔지니어링 능력 평가 모델
SECM 시스템 엔지니어링 기능 모델
SEI 소프트웨어 공학 연구소
SE / SW 시스템 공학 및 소프트웨어 공학
SEPG 소프트웨어 엔지니어링 프로세스 그룹
SG 구체적인 목표
SP 특정 관행
SPMN 소프트웨어 프로그램 관리자 네트워크
SS 공급 업체 소싱
STSC 소프트웨어 기술 지원 센터
SW 소프트웨어 공학
SW-CMM 소프트웨어 용 기능 성숙도 모델
TS 기술 솔루션 (공정 영역)
검증 (공정 영역)
VER 검증 (공정 영역)
WBS 작업 분할 구조