파이어맨 이야기

이전에 포스팅한 3부부에 이어 내용을 추가로 번역 하였습니다.  


링크

CMMI for Development, Version 1.3 Part 1 1부 한글 : CMMI 소개 

CMMI for Development, Version 1.3 Part 1 2부 한글 : 프로세스 구성요소

CMMI for Development, Version 1.3 Part 1 3부 한글 : 모두 함께 하기



프로세스 영역 사이의 관계 ( Relationships Among Process Areas)


이 챕터에서는 조직의 프로세스 개선 뷰와 어떻게 프로세스 영역이 다른 프로세스 영역의 구현에 의존하는지에 대해서 알려주기 위해서 프로세스 영역 사이의 중요 관계를 설명합니다.

 

하나의 프로세스 영역에서 다른 영역까지의 정보나 유물의 흐름을 포함하는, 여러 프로세스 영역 사이의 관계는 당신이 프로세스 구현과 개선의 큰 뷰를 볼 수 있도록 도와 줄 것입니다.

 

성공적인 프로세스 개선 계획은 조직의 비즈니스 목표에 의해 시작되어야 합니다. 예를 들면, 일반 비즈니스 목표는 시장에서 상품을 얻는데 걸리는 시간을 줄이는 것입니다. 이 프로세스 개선 목적은 정해진 시간에 인도하기 위한 프로젝트 관리 프로세스를 개선하기 위해서 유래되었습니다. 이러한 개선은 프로젝트 계획(PP)와 프로젝트감시 및 통제(PMC) 프로세스 영역 안에서 우수 프랙티스에 의존합니다.

 

비록 우리가 그 관계의 논의를 단순화 하기 위해서 이 챕터에서 프로세스 영역을 그룹화하지만, 프로세스 영역은 이 그룹, 카테고리 또는 레벨과 상관없는 다른 것과 상호작용을 하거나 영향을 줍니다. 예를 들면, 의사결정분석 및 해결(DAR)프로세스 영역(성숙도 레벨 3의 지원프로세스 영역)은 다른 해결방법으로부터 기술적 해결을 선택하기 위해서 기술적 솔루션(TS)프로세스 영역에서 사용하는 형식적 평가 프로세스에 대한 고유 프랙티스를 포함하고 있습니다.

 

CMMI 프로세스 영역 사이의 중요 관계를 인식하는 것은 유용하고 생산적으로 CMMI를 적용하는 데 도와줍니다. 프로세스 영역 사이의 관계는 각각의 프로세스 영역의 참고와 파트2에서 각 프로세스영역의 관련된 프로세스 영역(Related Process Areas) 부분에서 더 상세하게 설명됩니다. 더 상세한 정보는 파트 2를 참고하세요

 

프로세스 관리 ( Process Management )


프로세스 관리 프로세스 영역은 정의, 계획, 배포, 구현, 모니터링, 제어, 평가, 측정과 프로세스 개선에 관련된 프로젝트 사이의 활동을 포함하고 잇습니다.

 

CMMI-DEV에는 다음과 같은 5개의 프로세스 관리 프로세스 영역이 있습니다.

l  조직 프로세스 정의 (OPD)

l  조직프로세스초점 (OPF)

l  조직성과관리 (OPM)

l  조직 프로세스 성과 (OPP)

l  조직훈련 (OT)

 

기본 프로세스 관리 프로세스 영역

기본 프로세스 관리 프로세스 영역은 우수 프랙티스를 문서화하고 공유하는 능력, 조직의 프로세스 자산 , 조직간의 배우는 것을 조직에 제공합니다.

 

Figure 4.1은 기본 프로세스 관리 프로세스 영역 다른 프로세스의 카테고리 사이의 상호작용에 대한 내용을 한눈에 보여줍니다. Figure 4.1에서 삽화된 것처럼, 조직프로세스초점 ( OPF )프로세스 영역은 조직이 현재 조직의 프로세스와 프로세스 자산의 강점과 약점을 이해를 기반으로 조직프로세스 개선 을 계획, 구현 그리고 배포하는데 도움을 줍니다.



 

조직의 프로세스에 개선 후보는 다양한 소스를 통해서 얻을 수 있습니다. 이 활동은 프로세스 개선 평가, 프로세스 측정, 프로세스 구현하면서 알게 된 내용, 프로세스 평가와 제품 평가활동을 통한 결과를 포함합니다.

 

조직 프로세스 정의 (OPD) 프로세스 영역은 조직의 표준 프로세스의 집합, 작업 환경 표준, 그리고 프로세스 요구사항과 조직의 목적을 기반으로한 다른 자산들을 확립하고 유지하도록 합니다. 이러한 다른 자산들은 생명주기 모델의 설명, 프로세스에 맞춘 가이드라인, 그리고 문서와 자료에 관련된 프로세스를 포함합니다.

 

프로젝트는 그들의 정의된 프로세스를 성성하기 위해서 조직의 표준 프로세스 집합에 맞추어 만듭니다. 다른 자산은 정의된 프로세스의 구현뿐만 아니라 기술(tailoring)을 지원합니다.

 

정의된 프로세스를 수행한, 특정 데이터를 포함한, 프로세스 설명, 프로세스 구조(process artifacts), 그리고 학습한 것에 대한 경험과 산출물은 조직의 표준프로세스와 다른 자산으로 적절하게 통합됩니다

 

조직훈련(OT)프로세스 영역은 조직의 전략적 훈련 수요뿐만 아니라 프로젝트와 지지하는 그룹 사이의 공통된 전술 훈련 수요까지 식별합니다. 특히 훈련은 개발되거나 조직의 표준 프로세스를 수행하기 위해 요구하는 기술을 개발하기 위해 얻어집니다. 훈련의 주요 구성요소는 관리된 훈련 개발 프로그램, 문서화된 계획, 적절한 지식을 가진 직원, 그리고 훈련 프로그램을 효과적으로 측정하기 위한 메커니즘을 포함합니다.

 

 

발전된 프로세스 관리 프로세스 영역(Advanced Process Management Process Areas)

발전된 프로세스 관리 프로세스(Advanced Process Management) 영역은 품질과 프로세스 성과를 위한 정량적 목적을 달성하기 위한 개선된 능력을 조직이 가지도록 제공합니다.

 

Figure 4.2는 발전된 프로세스 관리 프로세스 영역과 다른 프로세스 영역 카테고리 사이의 상호작용을 보여줍니다각각의 발전된 프로세스 관리 프로세스 영역은 프로세스를 개발하고 배포하고 재산을 지원하는 능력에 달려있습니다. 기본 프로세스 관리 프로세스 영역은 이 능력을 제공합니다.



Figure 4.2에 삽화된 것처럼, 조직 프로세스 성과(OPP)는 조직의 비즈니스 목적으로부터 품질과 프로세스 성과에 대한 정량적 목적을 얻습니다. 그 조직은 공통의 측정, 프로세스 성과 기준, 그리고 프로세스 성과 모델을 가진 프로젝트와 지원 그룹을 제공합니다.

 

이러한 추가 조직 자산은 프로젝트 품질과 프로세스 성과 목적을 달성할 수 있고, 정량적 관리를 지원하는 정의된 프로세스를 구성을 지원합니다. 제품의 품질, 서비스 품질, 조직의 기본 프로세스 집합의 프로세스 성과를 정량적으로 이해하기 위해서, 조직은 정의된 프로세스로부터 수집된 프로세스 성능 데이터를 분석합니다.

 

조직성과관리(OPM)에서, 프로세스 성과 기준과 모델은 비즈니스 목적을 충족시키고 품질과 프로세스 성과 목적을 얻기 위한 조직의 능력을 이해하기 위해 분석됩니다. 이러한 이해를 기반으로, 조직은 조직의 성과를 수치적으로 개선하는 점진적이고 혁신적인 개선을 사전에 선택하고 배포합니다

 

배포하기 위한 개선(improvements)의 선택은 개선후보를 배포함으로 예측된 비용과 이익에 대한 정량적인 이해를 기반으로 합니다. 조직은 비즈니스 목적과 품질과 프로세스 성과 목적을 적절하게 조정할 수 잇습니다.

 

 

프로세스 관리 (Project Management)


프로젝트 관리 프로세스 영역은 프로젝트를 계획, 모니터링 그리고 제어와 관련된 프로젝트관리 활동에 대한 내용입니다.

 

CMMI-DEV의 다음 7개의 프로젝트 관리 프로세스 영역이 있습니다.  

 

l  통합된 프로젝트 관리 (IPM)

l  프로젝트감시 및 통제 (PMC)

l  프로젝트계획 (PP)

l  정량적 프로젝트 관리 (QPM)

l  요구사항 관리 (REQM)

l  리스크 관리 (RSKM)

l  공급자 계약 관리 (SAM)


기본 프로젝트 관리 프로세스 영역

기본 프로젝트 관리 프로세스 영역은 프로젝트 계획과 약속을 확립 및 유지하고, 계획에 대한 진행사항을 모니터링하고, 정확한 행동을 하는지, 그리고 공급자 동의와 관련된 활동에 대해 고민해서 다루고 있습니다.

 

Figure 4.3 은 기본 프로젝트 관리 프로세스영역과 다른 프로세스 카테고리 사이의 상호작용을 보여줍니다. Figure 4.3의 삽화처럼, 프로젝트 계획 프로세스 영역은 프로젝트 계획을 개발하고, 관련 이해관계자를 포함하고, 계획에 대해 약속하고, 그리고 계획을 유지하는 것을 포함하고 있습니다.



계획은 제품과 프로젝트(Figure 4.3에서 "What to build")를 정의한 요구사항을 가지고 시작합니다. 프로젝트 계획은 프로젝트에 의해 수행될 다양한 프로젝트 관리와 개발활동에 대해 다룹니다. 그 프로젝트는 다양하고 이해당사자로부터 프로젝트에 영향을 주는 다른 계획을 검토하고, 프로젝트에 기여한 이해당사자들과 약속을 합니다. 예를 들면, 이러한 계획은 형상관리(configuration management), 검증 (verification), 그리고 측정과 분석에 대해 다룹니다.

 

프로젝트감시 및 통제 (PMC) 프로세스 영역은 감시와 통제 활동과 시정할 행동에 대한 프랙티스를 포함합니다. 프로젝트 계획은 진행사항을 모니터링하기 위한 방법과 빈번하게 일어나는 진행사항 리뷰에 대해서 구체화합니다. 진행사항은 계획에 프로젝트 상태를 비교함으로써 주로 결정됩니다. 실제 상태가 예상한 상태와 크게 다를 경우, 적절하게 시정 조치를 해야 합니다. 이러한 행동은 프로젝트 계획(PP) 프랙티스를 사용하는 것을 요구하는 다시 계획하기에 포함될 수 있습니다.

 

요구사항 관리 (REQM) 프로세스 영역은 요구사항을 유지합니다. 요구사항 관리 (REQM) 프로세스 영역은 다른 적절한 계획과 데이터가 유지되고 요구사항 변경을 제어하는 활동에 대해서 설명합니다. 그리고 요구사항관리는 고객 요구사항에서 제품 요구사항 및 제품 구성 요구사항까지의 요구사항의 추적성을 제공합니다.

 

요구사항관리(REQM) 는 요구사항에 변경이 프로젝트 계획, 활동, 그리고 산출물까지 반영되도록 합니다. 이 변경 주기는 엔지니어링 프로세스 영역에 영향을 줄 수 잇습니다. 따라서, 요구사항 관리는 역동적이고 종종 이벤트를 순서대로 반복합니다. 요구사항 관리(REQM) 프로세스 영역은 제어 및 훈련된 엔지니어링 프로세스에 필수적입니다.

 

공급자 계약 관리 (SAM) 프로세스 영역은 공급자에 의해 생성된 작업 부분을 요구하는 프로젝트 요구를 다룹니다. 프로젝트 요구사항을 만족시키기 위해 사용되는 제품의 소스는 사전에 식별됩니다. 공급자는 선택되고 공급 계약은 공급자를 관리하기 위해서 확립됩니다.

 

공급자의 진행과 성과는 공급자 계약에 서술된 것처럼 추적되고 공급자 계약은 적절하게 수정됩니다. 승인 리뷰와 테스트는 공급자가 생성한 제품 구성요소에서 실시됩니다.

 

발전된 프로젝트 관리 프로세스 영역 (Advanced Project Management Process Areas )

발전된 프로젝트 관리 프로세스 영역은 정의된 프로세스를 확립과 같은 활동을 다룹니다. 정의된 프로세스는 조직의 표준 프로세스의 집합으로 맞춰지고, 조직의 작업환경 표준에 프로젝트 작업환경을 확립하고, 적절한 이해관계자와 조정 및 협업을 하고, 프로젝트 활동을 통해 팀을 형성하고 유지시키며, 정량적으로 프로젝트를 관리하고, 그리고 위험도 관리하는 것입니다

 

Figure 4.4는 발전된 프로젝트 관리 프로세스 영역과 다른 프로세스 영역 카테고리 사이에 상호작용을 보여줍니다. 각각 발전된 프로젝트 관리 프로세스는 프로젝트를 계획, 모니터, 그리고 제어하는 능력에 달려있습니다. 기본 프로젝트 관리 프로세스 영역은 이 능력을 제공합니다.

 



통합된 프로젝트 관리 (IPM) 프로세스 영역은 프로젝트의 정의된 프로세스를 확립하고 유지하는 것입니다. 그 프로젝트의 정의된 프로세스는 조직의 표준 프로세스의 집합(조직 프로세스 정의(OPD))으로부터 맞춰집니다. 프로젝트는 그 프로젝트의 정의된 프로세스를 사용하여 관리됩니다.

 

프로젝트는 조직의 프로세스 자산을 사용하고 기여합니다. 프로젝트의 작업환경은 조직의 작업환경 표준으로부터 확립되고 유지됩니다. 그리고 팀은 조직의 규칙과 가이드라인을 사용하여 확립됩니다. 프로젝트의 적절한 이해관계자는 식별, 협상, 중요한 의존관계 추적, 그리고 조정 이슈를 해결을 통해 그들의 노력을 통합합니다.

 

비록 위험 식별 과 모니터링은 프로젝트 계획 (PP)와 프로젝트감시 및 통제 (PMC) 프로세스 영역에 포함되지만, 리스트 관리 (RSKM)프로세스 영역은 위험요소 식별, 위험 평가, 위험 완화를 포함한 활동을 통해 위험 관리에 미래 지향적인 접근방식을 가져야 합니다.

 

정량적 프로젝트 관리 (QPM) 프로세스영역은 품질과 프로세스 성과를 위한 목적을 확립하고, 이러한 목적을 달성하기 위한 정의된 프로세스를 구성하고, 그리고 정량적으로 프로젝트를 관리합니다. 프로젝트의 품질과 프로세스 성과 목적은 조직과 고객에 의해 확립된 목적이 기반이 됩니다.

 

프로젝트의 정의된 프로세스는 통계 및 다른 정량적 기술을 사용하여 구성됩니다. 이 같은 분석은 프로젝트를 그 품질과 프로세스 성과 목표을 달성할지 못할지 예측 할 수 있게 합니다.

 

예측을 기반으로, 프로젝트는 정의된 프로세스를 조정하거나 품질과 프로세스 성과 목적에 대한 변경사항을 협상할 수 있습니다. 프로젝트 진행하면서, 선택된 하위 프로세스의 성과는 프로젝트가 그 목적을 달성하기에 적합한지 아닌지를 평가하기 위해서 주의 깊게 모니터링 됩니다.

 

Engineering 

엔지니어링 프로세스 영역은 엔지니어링 훈련으로 공유된 개발과 유지보수 활동을 다룹니다. 엔지니어링 프로세스 영역은 일반적인 엔지니어링 용어를 사용하여 쓰여졌습니다. 이 엔지니어링 용어는 프로세스 개선을 위해 사용될 수 있는 상품 개발 프로세스(: 소프트웨어 공학, 기계 공학)에 포함되는 기술 용어입니다.

 

엔지니어링 프로세스 영역은 다른 엔지니어링 훈련에 관계된 프로세스들을 하나의 상품 개발 프로세스로 통합합니다. 그리고 프로세스 개선 전략에 중점을 둔 상품을 지원합니다. 이 같은 전략은 특별한 기술 훈련보다는 필수적인 비즈니스 목적을 대상으로 합니다. 이 프로세스에 대한 접근법은 조직의 “stovepipe” 정신으로의 경향을 피하게 합니다.

 

엔지니어링 프로세스 영역은 개발 도메인(:소프트웨어 상품, 하드웨어 상품, 서비스, 프로세스)에서 어떤 상품 또는 서비스의 개발에 적용합니다.

 

CMMI-DEV에는 다음과 같은 5가지 엔지니어링 프로세스 영역이 있습니다.

l  제품통합 (PI)

l  요구사항개발 (RD)

l  기술적 솔루션 (TS)

l  확인 (VAL)

l  검증 (VER)

Figure 4.5 6개의 엔지니어링 프로세스 영역 사이의 상호작용에 대한 조감도를 제공합니다.



요구사항개발 (RD) 프로세스 영역은 고객의 요구사항을 식별하고 이 요구사항을 제품 요구사항으로 번역합니다. 제품의 요구사항의 집합은 높은 레벨의 개념의 해결책을 만들기 위해서 분석됩니다. 이러한 요구사항의 집합은 초기 제품의 구성요소 요구사항의 집합에 확립하기 위해서 할당됩니다.

 

제품을 정의하는데 도움이 되는 다른 요구사항들은 제품 구성요소에 할당되고 파생됩니다. 이 상품과 상품 구성요소 요구사항의 집합은 개발자가 이해하고 사용할 수 있는 용어로 상품의 성능, 품질 특성, 디자인 특징, 검증 요구사항 등에 대해 설명됩니다.

 

요구사항개발 (RD) 프로세스 영역은 기술적 솔루션 (TS) 프로세스 영역으로 요구사항을 공급합니다. 기술적 솔루션 (TS)에서 그 요구사항을 제품 아키텍처, 제품 구성요소 디자인, 제품 구성요소로 변환합니다. 요구사항은 제품통합 (PI)프로세스 영역으로 공급됩니다. 제품통합 (PI)에서 제품 구성요소는 합쳐지고 요구사항개발 (RD) 에서 제공된 인터페이스 요구사항이 충족되는지 인터페이스를 검증합니다.

 

기술적 솔루션 (TS) 프로세스 영역은 제품통합 (PI)과 공급자 계약 관리 (SAM)에 사용될 제품 구성요소를 위한 기술적 데이터 패키지를 개발 합니다. 다른 해결책은 확립된 기준을 기반으로 최적의 디자인을 선택하기 위해서 검사되는 것입니다. 이러한 기준은 제품타입, 동작환경, 성능 요구사항, 지원 요구사항, 그리고 비용이나 배포 스케줄에 따라 제품간에 큰 차이가 있을 수 있습니다. 마지막 해결책을 선택하는 업무는 의사결정분석 및 해결 (DAR)의 고유 프랙티스를 사용하게 하는 것입니다.

 

그 기술적 솔루션 (TS) 프로세스 영역은 디자인을 검증, 마지막 빌드 전에 동료리뷰를 수행하는 검증 (VER) 프로세스 영역의 고유 프랙티스에 의존합니다.

 

검증 (VER) 프로세스 영역은 선택된 산출물이 상세한 요구사항을 만족하는지를 확인합니다. 검증 (VER) 프로세스 영역은 산출물을 선택하고 요구사항에 대한 산출물을 검증할 검증 방법을 선택합니다. 검증은 제품 구성요소검증에서 시작하여 일반적인 전체 제품의 검증까지 일반적으로 점증적인 프로세스 입니다.

 

검증 (VER)은 또한 동료 리뷰를 다룹니다. 동료리뷰는 초기에 결함을 제고하기 위한 검증된 방법이며, 가치있는 통찰력을 제품에 제공하고, 그리고 제품 구성요소가 개발되고 유지되도록 합니다.

 

확인 (VAL)프로세스 영역은 고객의 요구사항에 대해서 제품을 점진적으로 검사하는 것입니다. 확인 (VAL)은 운영 환경이나 시뮬레이션된 운영환경에서 수행됩니다. 확인 요구사항에 대한 고객과의 수정은 프로세스 영역에서 중요한 요소입니다.

 

확인 (VAL) 프로세스 영역의 범위는 제품, 제품의 구성요소, 선택된 중간산출물, 그리고 프로세스의 확인(validation)을 포함합니다. 이러한 확인된(validated) 요소는 종종 재검증(reverification)이나 재확인(revalidation)을 요구할 수 있습니다. 확인 (validation)하는 동안 발견된 이슈는 요구사항개발 (RD)이나 기술적 솔루션 (TS) 프로세스 영역에서 일반적으로 해결됩니다.

 

제품통합 (PI) 프로세스 영역은 통합전략 생성, 상품 구성요소 통합, 그리고 상품을 고객에게 배포와 관련된 고유한 프랙티스를 포함하고 잇습니다.

 

제품통합 (PI)은 제품 통합 프로세스를 구현함으로써 검증(Verification)과 확인(Validation)에 고유한 프랙티스를 사용합니다. 검증(Verification) 프랙티스는 제품을 통합하기 전에 제품 구성요소의 인터페이스와 인터페이스 요구사항을 확인합니다. 인터페이스 검증(verification)은 통합 프로세스에서 필수적인 사건입니다. 운영환경에 제품을 통합하는 동안, 확인(Validation)프로세스 영역의 고유한 프랙티스가 사용됩니다.

 

엔지니어링 프로세스의 재귀와 반복(Recursion and Iteration of Engineering Processes)

대부분의 프로세스 표준은 프로세스를 적용에 2가지 방법이 있습니다. 이 두가지 방법은 재귀와 반복입니다.

 

재귀는 프로세스가 시스템 구조 안에서 시스템 요소의 연속적인 레벨이 적용될 때 발생합니다. 하나의 애플리케이션의 결과는 시스템 구조에서 다음레벨의 입력 값으로 사용됩니다. 예를 들면, 검증 프로세스는 전체 조립 상품, 주요 상품 구성요소, 그리고 구성요소의 구성요소를 적용하기 위해 디자인되었습니다. 당신이 적용하려는 검증 프로세스가 얼마나 멀리 있는 지는 최종 제품의 크기와 복잡성에 달려있습니다.

 

반복은 프로세스가 같은 시스템 레벨에서 반복될 때 일어납니다. 새로운 정보가 하나의 프로세스의 구현에 의해서 생성됩니다. 그 하나의 프로세스는 그 정보를 관련 프로세스로 줍니다. 이 새로운 정보는 일반적으로 프로세스가 완료되기 전에 해결해야 하는 문제를 발생시킵니다.

 

예를 들면, 반복이 요구사항 개발 (RD)과 기술적 솔루션 (TS) 사이에서 발생합니다. 프로세스의 재 적용은 일어난 문제를 해결할 수 있습니다. 반복은 다음 프로세스 적용하기 전에 품질을 보장할 수 있습니다.

 

엔지니어링 프로세스 (: 요구사항 개발, 검증.)는 고객에게 전달하기 전에 이러한 엔지니어링 프로세스가 적절한지를 확인하기 위해서 반복적으로 구현됩니다. 또한, 엔지니어링 프로세스는 제품의 구성요소에 적용됩니다.

 

예를 들면, 검증(Verification)과 확인(Validation) 프로세스 영역과 관련된 프로세스에 의해 발생한 여러 문제가 요구사항 개발 (RD)이나 제품통합 (PI)프로세스 영역과 관련된 프로세스에 의해 해결될 수 있습니다. 이러한 프로세스들의 재귀와 반복은 제품이 고객에게 전달되기 전에 프로젝트가 제품의 모든 구성요소의 품질을 확인할 수 있게 합니다.

 

프로젝트 관리 프로세스 영역은 때때로 프로젝트가 프로젝트 안에 중첩될 수 있기 때문에 순환될 수 있습니다.

 

지원 (Support)

지원 프로세스 영역은 제품 개발과 유지보수를 지원하는 활동을 포함하고 있습니다. 이 지원 프로세스 영역은 다른 프로세스를 수행에 사용되는 프로세스를 다룹니다. 일반적으로 지원 프로세스 영역은 프로젝트에 선택된 프로세스를 다루거나 조직에 보다 일반적으로 적용할 프로세스를 다룰 수 있습니다.

 

예를 들면, 프로세스 및 제품 품질 보증 (PPQA) 는 모든 프로세스영역에서 설명된 산출물과 프로세스 객관적인 평가를 제공하기 위해서 모든 프로세스 영역에서 사용될 수 있습니다.

 

CMMI-DEV에는 다음 5가지 지원 프로세스 영역이 있습니다.

l  원인분석 및 해결 (CAR)

l  형상관리(CM)

l  의사결정분석 및 해결 (DAR)

l  측정 및 분석 (MA)

l  프로세스 및 제품 품질 보증 (PPQA)

  

기본 지원 프로세스 영역

기본 지원 프로세스 영역은 모든 프로세스 영역에 사용되는 기본 지원 기능을 다룹니다. 비록 모든 지원 프로세스 영역은 다른 프로세스의 입력 값에 의존하지만, 기본 프로세스 영역은 몇몇 일반 프랙티스를 구현에 도움이 되는 지원 기능을 제공합니다.

 

Figure 4.6은 기본 지원 프로세스 영역과 다른 모든 프로세스 영역사이의 상호작용을 보여줍니다.

 



 

측정 및 분석 (MA) 프로세스 영역은 고유 프랙티스를 제공함으로써 모든 프로세스 영역을 지원합니다. 이 고유 프랙티스는 관리 정보 요구사항을 지원하기 위해서 사용되는 측정 방법을 가지고 측정 요구와 목적을 정리하여 프로젝트와 조직을 안내 합니다. 그 결과는 좋은 결정을 하거나 적절한 수정 행동을 할 때 사용됩니다.

 

프로세스 및 제품 품질 보증 (PPQA)는 적용할 수 있는 프로세스 설명, 표준 및 절차에 대한 서비스, 산출물, 수행된 프로세스를 평가하기 위하여 고유 프랙티스를 제공함으로써 모든 프로세스 영역을 지원합니다. 그리고 이러한 리뷰로부터 발생하는 이슈를 확인하는 것이 다루어 집니다.

 

프로세스 및 제품 품질 보증 (PPQA)는 제품을 생명주기을 거쳐 관련된 산출물, 프로세스, 피드팩, 그리고 적절한 가시성을 가지고 모든 레벨의 관리와 프로젝트 직원을 제공함으로써 높은 품질의 상품과 서비스를 제공하는 것을 지원합니다.

 

형상관리(CM) 프로세스 영역은 형상 식별(configuration identification), 형상 제어(configuration control), 형상 현황 관리(configuration status accounting), 형상 감사 (configuration audits)를 사용하여 산출물 통합을 확립하고 유지함으로써 모든 프로세스를 지원합니다. 형상관리에 있는 산출물은 고객에게 전달된 제품, 내부 산출물, 획득한 제품, 도구, 그리고 이러한 산출물을 생성하고 설명하는데 사용되는 항목들을 포함합니다.

 

형상관리에 있는 산출물의 예는 계획, 프로세스 설명, 요구사항, 설계 데이터, 도면, 제품 사양, 코드, 컴파일러, 제품 데이터 파일, 제품 기술 문서를 포함합니다.

 

발전된 지원 프로세스 영역 (Advanced Support Process Areas)

발전된 지원 프로세스 영역은 개선된 지원 능력을 가진 프로젝트와 조직을 제공합니다. 각각의 이러한 프로세스 영역은 다른 프로세스 영역으로부터 고유 입력이나 프랙티스에 의존합니다.

 

Figure 4.7은 발전된 지원 프로세스 영역과 모든 다른 프로세스 영역 사이의 상호작용을 보여줍니다.

 



 

원인분석 및 해결 (CAR) 프로세스 영역을 사용하여, 프로젝트 멤버는 선택한 결과의 원인을 식별하고 미래에 일어날 부정적인 결과를 예방하고 긍정적인 결과를 활용합니다. 프로젝트의 정의된 프로세스가 근본 원인 분석과 행동 계획을 위한 초기 목표지만, 효과적인 프로세스 변경은 조직의 표준프로세스 집합에서 승인된 프로세스 개선 제안에 의해 발생합니다.

 

의사결정분석 및 해결 (DAR) 프로세스 영역은 어떤 이슈가 공식 평가 프로세스에 대상이 되는지 결정하고 공식 평가 프로세스에 적용되게 함으로써 모든 프로세스 영역을 지원합니다.

 

% 오타 및 잘못된 내용이 있으면 말씀 부탁드립니다. 


출처 : http://www.sei.cmu.edu/reports/10tr033.pdf




공유하기

facebook twitter kakaoTalk kakaostory naver band