ewha1

Technical Report

CMMI와 V&V 분석

SPIC-TR-20030728-2-PR-004

2003년 7월 28일

소프트웨어 프로세스 개선 센터

한국과학기술원(KAIST)

대전시 유성구 구성동 373-1

TEL : 042-869-8445

http://spic.kaist.ac.kr

- 1 -

SPIC-20030728-2-PB-004

이 문서는 소프트웨어 프로세스 개선센터의 Technical report로 센터에서 직접 배

포하고 있습니다. (모든 저작권은 SPIC에 있습니다.)

본 연구는 대학IT연구센터(ITRC : Information Technology Research Center)로 지

정되어 정보통신부로부터 지원 받고 있습니다.

CMMI와 V&V 분석

과제 : 제 2 세부과제

소속 : 이화여자대학교

책임자 : 최병주

작성연구원 : 김소영, 이승희, 박유봉, 윤회진

제출일 : 2003년 7월 28일

센터장 : 배두환 (인)

- 2 -

SPIC-20030728-2-PB-004

목 차

I. CMMI의 개요..................................................................................................- 5 -

1. CMMI의 소개..............................................................................................- 5 -

2. CMMI의 모델 컴포넌트.................................................................................- 8 -

3. CMMI의 모델 전문용어............................................................................... - 13 -

4. 단계적 모델(SR)과 계속적 모델(CR) ............................................................ - 17 -

5. CMMI의 프레임웍 상호작용......................................................................... - 29 -

6. CMMI 모델의 사용 .................................................................................... - 39 -

7. Process Areas 요약................................................................................... - 43 -

II. 여러 표준의 V&V 영역.................................................................................. - 49 -

1. CMM의 V&V 영역...................................................................................... - 49 -

2. CMMI의 V&V 영역..................................................................................... - 50 -

3. ISO/IEC 15504 (SPICE)의 V&V 영역............................................................. - 53 -

4. IEEE Std 1012-1998(IEEE Standard for Software Verification and Validation)...... - 55 -

5. ISO/IEC 12207의 V&V 영역 ........................................................................ - 58 -

6. 각 표준의 V&V 영역 간의 비교................................................................... - 61 -

III. V&V와 테스팅 현황과 이슈............................................................................ - 71 -

참고문헌...................................................................................................... - 73 -

- 3 -

SPIC-20030728-2-PB-004

그림 목차

그림 2-1. 단계적 CMMI 모델 컴포넌트.....................................................- 8 -

그림 2-2. 계속적 CMMI 모델 컴포넌트.....................................................- 9 -

그림 5-1. 기본 프로세스 관리 영역........................................................ - 30 -

그림 5-2. 고급 프로세스 관리 영역........................................................ - 31 -

그림 5-3. 기본 프로젝트 관리 프로세스 영역........................................... - 32 -

그림 5-4. 고급 프로젝트 관리 프로세스 영역........................................... - 34 -

그림 5-5. 공학 프로세스 영역 ............................................................... - 35 -

그림 5-6. 기본 지원 프로세스 영역........................................................ - 37 -

그림 5-7. 고급 지원 프로세스 영역........................................................ - 37 -

- 4 -

SPIC-20030728-2-PB-004

표 목차

표 I-2-1. CMMI의 계속적 표현의 능력 수준.................................................. - 12 -

표 I-2-2. CMMI의 단계적 표현의 성숙 수준.................................................. - 12 -

표 I-5-1. 일반 프랙티스와 관련된 프로세스 영역.......................................... - 38 -

표 I-7-1. 각 프로세스 영역의 요약................................................................ - 43 -

표 II-1-1. 동료 검토 핵심 프랙티스 영역 ...................................................... - 49 -

표 II-2-1. 확인 프로세스 영역....................................................................... - 50 -

표 II-2-2. 검증 프로세스 영역....................................................................... - 52 -

표 II-3-1. 확인 프로세스 ............................................................................... - 53 -

표 II-3-2. 검증 프로세스 ............................................................................... - 53 -

표 II-3-3. 합동 검토 프로세스....................................................................... - 53 -

표 II-3-4. 감사 프로세스 ............................................................................... - 54 -

표 II-4-1. 소프트웨어 V&V 개요의 예제....................................................... - 55 -

표 II-5-1. 확인 프로세스 ............................................................................... - 58 -

표 II-5-2. 검증 프로세스 ............................................................................... - 59 -

표 II-5-3. 합동 검토 프로세스....................................................................... - 59 -

표 II-5-4. 감사 프로세스 ............................................................................... - 60 -

표 II-6-1. 각 표준의 V&V 비교.................................................................... - 62 -

표 II-6-2. CMMI의 확인 PA와 CMM의 동료 검토 KPA의 매핑 .................... - 63 -

표 II-6-3. CMMI와 ISO/IEC 15504의 V&V 영역 매핑 결과.......................... - 65 -

표 II-6-4. CMMI와 ISO/IEC 12207의 V&V 영역 매핑 결과.......................... - 67 -

- 5 -

SPIC-20030728-2-PB-004

I. CMMI의 개요

1. CMMI의 소개

여러 CMM 모델과 마찬가지로, CMMI 모델은 개발 프로세스를 위한 안내 지침을 제공한다.

CMMI 모델은 프로세스 자체를 기술하지는 않는다. CMMI 모델의 프로세스 영역들은 특정

조직에서 사용하는 프로세스와 일대일 대응되지 않는다.

CMMI 모델에 대하여 CMM 통합의 목적은 시스템의 개발과 획득, 프로덕트나 서비스의 유지보수를 관리하는 조

직의 프로세스나 개인의 능력을 개선하기 위해서 그 안내 치침을 제공하는 것이다. 조직의

성숙도, 프로세스 영역의 수행능력을 평가하고, 개선이나 개선의 구현을 위한 우선순위를 결

정하도록 돕는다. CMMI Product Suite은 다양한 모델, 관련 훈련, 평가 메터리얼(materials)을

생산하는 능력을 제공하는 프레임웍을 포함하고, CMMI 모델은 시스템 공학, 소프트웨어 공

학, 통합된 산출물과 프로세스 개발(IPPD) 등을 포함한다. CMMI가 제시하는 특수 프랙티스

와 일반 프랙티스들은 조직의 상황에 맞게 해석되어야 한다.

CMMI 모델 선택하기 CMMI 프레임웍으로부터 다양한 모델을 만들어 이용할 수 있다. 조직의 프로세스 개선 요

구에 적합한 최선의 CMMI 모델을 결정해야 하는데, 단계적이거나 계속적인 두 모델 중 하

나를 선택하는 것이 가능하다. 두 모델 중 하나를 선택할 때 고려되는 사항은 다음과 같다.

계속적인(continuous) 모델

• 조직의 비즈니스 목적을 최대한 만족시키고 위험 영역을 없애기 위한 개선을 위하여

• 프로세스 영역에서의 조직을 비교하기 위하여

• EIA/IS 731에서 CMMI로 쉽게 전환하기 위하여

• 프로세스 영역의 구성이 SPICE와 유사하기 때문에, 프로세스 개선에 대해 SPCIE와 쉽

게 비교하기 위하여

단계적(staged) 모델

• 개선의 증명된 순서화(proven sequence of improvements)를 위하여

• 성숙도를 이용한 조직 비교를 위하여

• SW-CMM에서 CMMI로 쉽게 전환하기 위하여

• 평가결과를 간략화하고 조직 사이의 비교를 가능케 하는 단일 레이팅(rating) 위하여

- 6 -

SPIC-20030728-2-PB-004

4개의 지식 바디로 구성된 CMMI System engineering

시스템 공학은 전체 시스템 개발을 커버한다. 고객의 요구와 기대, 프로덕트 솔루션의 제약

사항을 고려하여, 프로덕트 생명에 걸쳐 프로덕트 솔루션을 지원하는데 중점을 둔다.

Software engineering

소프트웨어 시스템의 개발을 커버한다. 소프트웨어의 개발, 운용, 유지보수를 위한 체계적이

고 원칙적이고 정량적인 접근을 적용하는데 중점을 둔다.

Integrated product and process development

고객의 요구를 더욱 만족시키기 위하여 프로덕트의 전 생명에 걸쳐 관련 스테이크홀더

(stakeholder)들의 적정 시기의 협력을 성취하기 위한 체계적인 접근을 제공한다. IPPD를 지원

하기 위해 프로세스들은 조직내의 다른 프로세스들과 통합된다.

Supplier sourcing

더욱 복잡해지는 작업으로 인해 프로젝트가 특별히 요구하는 프로덕트의 추가 수정이나 역

할 수행을 위해 제공된다.

CMMI 계속적 모델의 구성 CMMI 모델의 단계적 모델은 7개의 장과 6개의 부록으로 구성된다.

1장 : CMMI 모델을 개괄한다

2장 : 능력 수준, 목적, 프랙티스를 포함한 모델 컴포넌트에 대해 기술한다

3장 : 특별히 정의되거나 선택된 용어들에 대해 설명한다

4장 : 능력 수준, 일반 목적, 일반 프랙티스들을 정의한다

5장 : 프로세스 관리, 프로젝트 관리, 지원, 공학의 네 가지 프로세스 범주별 상호작용

프레임웍을 제공한다

6장 : 조직이 CMMI 모델을 이용할 수 있는 방법에 대해 설명한다

7장 : 목적, 프랙티스, 서브프랙티스, 전형적 작업 산출물을 포함하는 프로세스 영역들

을 설명한다

부록 A : 문서화된 자원, 보고서, 프로세스 개선 모델, 산업 표준, 책 등을 위치시키는

데 이용할 수 있는 정보를 포함한다

부록 B : CMMI 모델에서 사용하는 두문자어를 정의한다

부록 C : CMMI 모델에서 사용하는 여러 용어들을 정의한다

부록 D : 각 프로세스 영역에서 요구되거나 기대되는 컴포넌트를 포함한다

부록 E : CMMI 프로젝트 관련 참여자의 리스트를 포함한다

부록 F : 계속적인 모델을 이용한 평가가 성숙도 등급으로 어떻게 전환될 수 있는지를

기술한다

- 7 -

SPIC-20030728-2-PB-004

CMMI 단계적 모델의 구성 CMMI 모델의 단계적 모델은 7개의 장과 5개의 부록으로 구성된다.

1장 : CMMI의 개괄을 제공하며, CMMI 모델에 포함되지 않는 다른 정보를 어디서 찾는

지, CMMI 모델 전체에 사용하는 typographical convention의 사용을 제시한다.

2장 : 성숙 단계가 포함하는 모델 컴포넌트, 목적, 프랙티스 들을 설명한다.

3장 : 어떻게 용어가 선택되고 정의되는 지와 같은 CMMI 모델의 용어 사용을 위해 취

하는 접근을 제시한다.

4장 : 프로세스 영역과 관련된 효율적이고, 반복적이며, 지속적인 프로세스의 개선을 보

증하는 공통 특성과 일반적인 프랙티스를 설명한다.

5장 : 프로젝트 관리, 프로세스 관리, 지원, 공학 프로세스 영역을 위한 기본, 고급 프로

세스의 의미를 가지는 통찰(insight)을 제공한다.

6장 : 조직이 CMMI 모델을 사용하는 방법을 설명한다.

7장 : 각 프로세스 영역의 목적, 프랙티스, 서브프랙티스, 전형적인 작업산출물을 제시

한다.

부록 A : 문서화된 자원, 보고서, 프로세스 개선 모델, 산업 표준, 책 등을 위치시키는

데 이용할 수 있는 정보를 포함한다.

부록 B : CMMI 모델에서 사용하는 두문자어를 정의한다.

부록 C : CMMI 모델에서 사용하는 여러 용어들을 정의한다.

부록 D : 각 프로세스 영역에서 요구되거나 기대되는 컴포넌트를 포함한다.

부록 E : CMMI 프로젝트 관련 참여자의 리스트를 포함한다.

목적과 프랙티스들의 넘버링

ex) SP x.y-z (x: 대응되는 특수 목적 번호, y: 같은 특수 목적 아래에 있는 프랙티스들

중 몇 번째, z: 특수 프랙티스의 능력 수준; 능력 수준이 1이면 ‘base

practice’, 1보다 높으면 ‘advanced practice’)

GP x.y (x: 대응되는 일반 목적 번호, 즉 능력 수준 지시, y: 같은 일반 목적 아래에

있는 프랙티스들 중 몇 번째)

- 8 -

SPIC-20030728-2-PB-004

2. CMMI의 모델 컴포넌트 단계적 CMMI 모델(SR)의 구조

그림 2-1. 단계적 CMMI 모델 컴포넌트

CMMI 모델은 프로세스 개선의 분리된 단계를 나타내기 위해 설계되어진다. 성숙 단계는

단계 내의 프로세스 개선에 접근하기 위한 제안된 순서를 제공한다. 그림 2-1와 같이 성숙

단계는 프로세스 영역을 조직한다. 프로세스 영역은 일반/특수 프랙티스 뿐 아니라 일반/ 특

수 목적도 포함한다. 공통 특성은 일반 프랙티스를 가진다.

• 성숙 단계

조직의 성숙 단계는 주어진 규칙이나 규칙의 집합 내 조직의 미래 행동을 예견하는 방법을

제시한다. 성숙 단계는 프로세스 개선을 위한 발전의 방향을 정의한다. 각 성숙 단계는 조직

프로세스의 중요한 파트를 안정시킨다.

• 성숙 단계의 세부

성숙 단계는 프로세스 영역의 미리 정의된 집합으로 구성된다. 성숙 단계는 일반/특수 목적

의 성취에 의해 측정되어진다.

• 성숙 단계 1: 시작(Initial)

프로세스는 보통 임시적이고 혼돈적이다. 조직은 보통 안정된 환경을 제공하지 않는다. 이러

한 조직은 조직 내의 경험이 풍부하고 능력이 뛰어난 사람들에 의존하며, 증명된 프로세스

를 사용하지 않는다.

• 성숙 단계 2: 관리(Managed)

조직은 성숙 단계2의 프로세스 영역의 모든 특수와 일반 목적을 달성해야 한다. 조직의 프

로젝트는 요구 사항들이 관리되며, 프로세스들이 계획되고, 수행되며, 측정되고, 조절됨을 보

장한다.

- 9 -

SPIC-20030728-2-PB-004

• 성숙 단계 3: 정의(Defined)

표준과 절차, 도구, 방법을 설명하는 조직의 프로세스들이 특성화되어 있다. 조직의 표준 프

로세스 집합은 반복적으로 수립되고 개선되어진다. 2 단계와 확실히 구분되어지는 점은 표준,

프로세스 정의, 절차의 범위이다. 또한 다른 특별한 차이점은 프로세스가 2단계보다 더 상세

하고 엄격하게 설명되는 것이다.

• 성숙 단계 4: 정량적인 관리(Quantitatively Managed)

전체 프로세스 수행을 위해 선택되는 서브프로세스들이 통계학적이거나 다른 정량적인 기술

로 제어된다. 3단계와 특별히 구분되는 점은 프로세스 수행을 예측할 수 있다는 것이다.

• 성숙 단계 5: 최적화(Optimizing)

프로세스들은 프로세스 고유의 변화에 대한 공통적인 원인의 정량적 이해에 기반을 두고 지

속적으로 개선된다. 5단계는 혁신적인 기술의 개선을 통해 프로세스 수행의 지속적인 개선에

관심을 둔다. 4단계와 특별히 구분되는 점은 프로세스 변화의 타입을 설명하는 것이다.

• 성숙 단계를 통한 진보

조직은 프로젝트 단계와 가장 개선된 단계의 유지, 조직 전체의 지속적인 프로세스 개선, 결

정을 내리기 위한 양적이고 질적인 데이터의 사용으로 인한 구조적인 성숙으로 진보적인 개

선을 수행할 수 있다.

• 성숙 단계의 생략

단계적 모델은 우수한 문화를 수립하기 위해 발전하는 조직을 통한 성숙 단계를 정의한다.

이는 각 성숙 단계가 어떤 다음 단계를 수행하는 지의 필수적인 기반을 형성하므로 성숙 단

계는 일반적으로 비생산적인 것을 생략하려 할 것이다.

계속적 CMMI 모델(CR)의 구조

그림 2-2. 계속적 CMMI 모델 컴포넌트

- 10 -

SPIC-20030728-2-PB-004

특수 목적과 특수 프랙티스는 각각의 프로세스 영역에서 유일하게 적용되고, 일반 목적과

일반 프랙티스는 모든 프로세스 영역에 적용된다. 능력 수준은 각 프로세스 영역에서 프로

세스 개선을 위한 우선순위를 제공한다. 계속적 모델은 프로세스 영역에서 프로세스를 개선

할 때 조직이 이용할 수 있는 최선의 프랙티스를 제시하는데 중점을 둔다. 프로세스 개선을

위해 CMMI 모델을 이용하기 전에 조직의 프로세스들을 CMMI 프로세스 영역에 대응시켜

야 한다.

• 능력 수준(capability levels)

특정 능력 수준으로 프로세스 영역의 일반, 특수 목적을 만족시킨다면, 그 능력 수준을 획득

할 수 있고 프로세스 개선이라는 이득을 얻을 수 있다. 능력 수준은 프로세스 영역에서 수

행, 제어, 개선하는 조직의 능력을 향상시키는데 중점을 둔다. 능력 수준은 조직의 프로세스

를 추적하고 평가하고 설명하게 해준다. 능력 수준은 각 프로세스별로 측정된다. Incomplete,

Performed, Managed, Defined, Quantitatively Managed, Optimizing의 6단계 능력 수준이 있다.

Required, Expected, Informative Components CMMI 모델의 컴포넌트들은 다음의 세 카테고리로 나누어진다.

• Required : 특수 목적과 일반 목적이 속한다. 이 컴포넌트들은 조직의 계획되고 구현되는

프로세스에 의해 반드시 달성되어야 한다. 프로세스 영역의 달성 정도를 등급화 하는데 필

수적이다. 목적 달성은 프로세스 영역 만족과 조직의 성숙도를 결정하는 평가에 이용된다.

• Expected : 특수 프랙티스와 일반 프랙티스가 이에 속한다. 이 컴포넌트들은 조직이

required 컴포넌트를 달성하기 위해 무엇을 구현해야 하는지를 기술한다. 개선의 구현이나

평가의 수행에 대한 안내 지침이 된다.

• Informative : 서브프랙티스, 전형적 작업 산출물(typical work products), discipline amplification,

일반 프랙티스 세부 사항(elaborations), 목적과 프랙티스 타이틀, 프랙티스 노트, 참조들이 이

에 속한다. 목적과 프랙티스, 그것이 어떻게 달성되는지에 대한 사용자의 이해를 돕는다.

Model Components

• 프로세스 영역

프로세스 영역은 개선을 위해 중요하게 고려되는 목적들을 만족시키고 종합적으로 수행되는

관련 프랙티스들의 모음이다. 계속적 모델에서 프로세스 영역은 카테고리별로 구성된다.

• 특수 목적

그 프로세스 영역을 만족시키기 위해 무엇을 구현해야 하는지에 대한 유일한 기능적 활동의

목적을 나타낸다.

• 특수 프랙티스

관련된 특수 목적을 달성하기 위해 중요하게 고려되는 활동들을 말한다.

- 11 -

SPIC-20030728-2-PB-004

• 공통 특성

각 프로세스 영역의 일반 프랙티스를 구성한다.

• 기본(base) 프랙티스

계속적 모델에서 능력 수준 1인 모든 특수 프랙티스들을 ‘기본 프랙티스’ 라고 부른다.

• 고급(advanced) 프랙티스

계속적 모델에서 능력 수준 2 이상인 모든 특수 프랙티스들을 칭한다.

• 전형적 작업 산출물(Typical work products)

특수 프랙티스나 일반 프랙티스로부터 산출된 결과물의 예제를 제공한다.

• 서브프랙티스(Subpractices)

특수 프랙티스나 일반 프랙티스들을 해석(interpret)하기 위한 안내를 제공하는 상세화 된 기

술이다.

• 일반 목적

각 능력 수준은 그 능력 수준에서 달성해야 하는 조직의 규정화(institutionalization)를 기술하

는 오직 하나의 일반 목적을 가지고 있다. 전체 프로세스 영역에 다섯 가지의 일반 목적이

있다.

• 일반 프랙티스

관련 프로세스 영역을 효율적이고 반복적이며 지속적인 프로세스가 되도록 보장한다. 계속

적 모델에서 각각의 일반 프랙티스들은 하나의 일반 목적에 대응된다.

• 일반 프랙티스 세부 사항(elaborations)

각 프로세스 영역에서의 공통된 일반 프랙티스들을 그 프로세스 영역에 유일하게 적용할 수

있도록 하는 가이드를 제공한다.

• 참조(Reference)

관련된 프로세스 영역에 대한 추가적이고 더욱 상세한 정보를 사용자에게 가르쳐준다.

계속적 모델(CR)과 단계적 모델(SR) Incomplete, Performed, Managed, Defined, Quantitatively Managed, Optimizing의 6단계 능력 수

준은 계속적 모델에서 정의하는 능력 단계로 각 프로세스 영역에서 조직의 프로세스 개선

달성을 위해 사용된다.

Initial, Managed, Defined, Quantitatively Managed, Optimizing의 5단계 성숙도 수준은 단계적

모델에서 정의하는 성숙도 단계로 조직의 총체적 성숙도를 측정하기 위해 사용된다.

계속적 모델은 basic, advanced의 두 특수 프랙티스의 타입을 가지기 때문에 더 많은 특수 프

랙티스를 가진다. 단계적 모델에서는 한 가지 타입의 특수 프랙티스만이 있다.

계속적 표현 모델의 능력 단계는 각 프로세스 영역을 위한 조직의 프로세스 개선 수행을 지

원한다. 6개의 능력 단계로 구분되며, 0~5단계를 가진다. 각 능력 단계는 일반 목적과 일반

및 특수 목적 프랙티스의 집합들과 일치한다.

- 12 -

SPIC-20030728-2-PB-004

표 I-2-1. CMMI의 계속적 표현의 능력 수준

Capability Level Continuous Representation Capability Levels

0 Incomplete

1 Performed

2 Managed

3 Defined

4 Quantitatively Managed

5 Optimizing

단계적 표현 모델의 성숙 단계는 조직의 전체 성숙도를 지원한다. 5개의 성숙 단계로 구분되

며, 1~5단계를 가진다. 각 성숙단계는 미리 정의된 프로세스 영역의 집합으로 이루어진다.

표 I-2-2. CMMI의 단계적 표현의 성숙 수준

• 능력 수준 프로필

계속적인 모델에서 능력 수준 프로필은 프로세스 영역과 대응되는 능력 수준의 리스트를 그

내용으로 한다. 이 프로필은 조직에서 프로세스 영역의 능력 수준을 추적하기 위한 방법으

로 사용된다.

• Target staging

조직이 따라야 하는 프로세스 개선의 방향을 기술하는 대상 프로필의 시퀀스다.

Maturity Level Staged Representation Maturity Levels

1 Initial

2 Managed

3 Defined

4 Quantitatively Managed

5 Optimizing

- 13 -

SPIC-20030728-2-PB-004

3. CMMI의 모델 전문용어 전문용어의 형성 CMMI 모델을 개발할 때, 제품 팀은 자원 모델에서 사용하는 전문용어를 가지고 시작한다.

합의에 의해 중립적이고 공정하며 유연성 있는 용어가 전문용어로 결정된다.

특별한 의미를 가진 공통 전문용어 CMMI 모델 내에서만 통용되는 전문용어에 대해 그 의미를 정의한다.

• Adequate, Appropriate, As Needed

이들 단어는 조직의 비즈니스 대상의 관점에서 목적과 프랙티스를 설명하는데 사용된다.

• 고객(Customer)

프로덕트를 받아들이거나 지급을 승인할 책임이 있는 사람, 단체 혹은 집단이다. 프로젝트

내부에 있으나, 반드시 조직 내부에 있진 않다.

• 스테이크홀더(Stakeholder)

맡은 일의 결과를 위한 책임이 있는 어떤 방법에 의해 혹은 그 안에서 영향을 받는 단체나

개인이다. 즉 수행과 관련된 모든 것을 의미한다.

• 관련된 스테이크홀더(relevant stakeholder)

특별한 활동을 개선하기 위해 식별되거나 특별한 계획을 포함하는 스테이크홀더(stakeholder)

를 지시하는데 사용되어지는 것이다.

• 매니저(Manager)

관리 상의 책임자를 말한다.

• 프로젝트 관리자(Project Manager)

프로젝트 계획, 지휘, 제어, 조직, 동기에 책임을 가지는 사람이며, 고객을 만족시키기 위한

책임을 가지는 사람이다.

• 상위 관리자(Senior Manager)

조직적 프로세스의 개선 효용성을 지시할 수 있는 권위를 가진 사람이다.

• Shared Vision

임무, 대상, 기대된 행동, 가치, 마지막 결과를 포함하는 원리 등에 대해 조직, 프로젝트 또

는 팀과 같은 집단에 의해 개발되고 사용되어지는 공통의 이해이다.

• 조직(Organization)

전체의 한 부분이나 그 이상의 프로젝트를 집합적으로 관리하는, 동일 정책 하에서, 상급 관

리자와 프로젝트를 관리하고 운영하는 사람들로 구성된 구조이다.

• 규칙(Discipline)

CMMI 모델을 선택할 때 이용 가능한 지식 파트이다.

- 14 -

SPIC-20030728-2-PB-004

• Project(프로젝트)

고객이나 엔드 유저에게 하나 또는 그 이상 프로덕트를 전달하는 관련된 자원의 관리된 집

합이다. 프로젝트는 프로젝트들의 조립일 수 있다.

• 프로덕트(Product)

고객으로부터 전달되는 작업 프로덕트이다.

• 작업 프로덕트(Work Product)

프로세스에 의해 생성되는 어떤 가공품을 의미하며, 파일, 문서, 프로덕트의 부분, 서비스,

프로세스, 명세, 구매서 등을 포함한다.

• 프로덕트 컴포넌트(Product Component)

CMMI에서 프로덕트 컴포넌트는 프로덕트보다 낮은 수준의 컴포넌트이며, 프로덕트 완성을

위해 통합된다. 고객에게 전달되거나 프로덕트의 제작이나 사용을 지원하는 프로덕트의 한

부분이다.

• 평가(Appraisal)

강도와 약점을 결정하기 위해 하나 혹은 그 이상의 프로세스를 시험하는 것이다.

• 심사(Assessment)

프로세스 개선을 목적으로 자신의 조직을 위해 자체적으로 수행하는 평가이다.

• 테일러링 지침(Tailoring Guidelines)

해당 프로젝트에 적절하게 표준 프로세스를 개선하기 위해 사용한다. 맞춤지침은 수정을 할

수 있는 것과 할 수 없는 것을 기술하며, 수정을 위한 후보 프로세스 컴포넌트를 식별한다.

• 확인(Verification)

특별한 요구사항을 적절하게 반영하는 작업 프로덕트를 입증한다. 즉, 확인은 “올바르게 설

립함”을 보증하는 것이다.

• 검증(Validation)

제공된 프로덕트가 의도된 사용을 수행함을 입증한다. 즉, 검증은 “올바른 것을 설립함”을

보증하는 것이다.

• 품질과 프로세스 수행 대상(Quality and Process-Performance Objectives)

프로덕트 품질, 서비스 품질, 프로세스 수행을 위한 대상과 요구사항을 포함한다.

CMMI 모델에서 사용하는 특수 전문용어 • CMMI Product Suite

CMMI 프레임웍 자체, 모델, 평가 방법론, 평가 메터리얼(materials), CMMI 프레임웍으로부터

산출된 다양한 타입의 트레이닝을 포함한다.

- 15 -

SPIC-20030728-2-PB-004

• CMMI 프레임웍

CMMI 컴포넌트들을 구성하는 기본적 구조

• 동료 검토(Peer Review)

‘작업 산출물 검사(work product inspection)’ 대신에 CMMI Product Suite에서 사용하는 용어가

‘동료 검토(peer review)’이다. 결함을 식별하기 위해, 작업 산출물 개발 중에 동료(peers)에 의

해 수행되는 작업 산출물에 대한 검토를 말한다

• 조직의 표준 프로세스 집합(Organization’s Set of Standard Processes)

조직에서의 모든 액티비티들을 다루는 프로세스들의 정의를 포함한다. 표준 프로세스는 전

조직에 걸쳐 액티비티들을 지속적으로 개발, 유지하게 하고, 오랜 기간동안의 안정성

(stability)과 개선에 필수적으로 요구된다. 기본적인 프로세스 요소(element)들을 기술하고 그

요소들 사이의 관계를 기술한다.

• 프로세스(Process)

CMMI Product Suite에서 사용되는 용어 ‘Process’ 란, CMMI 모델에서 프랙티스들의 구현으로

인지될 수 있는 액티비티들로 구성된다.

• 관리 프로세스(Managed Process)

정책에 따라서 계획되고 실행되는 ‘수행 프로세스(performed process)’를 말한다.

• 정의 프로세스(Defined Process)

조직의 테일러링 지침(tailoring guidelines)을 따라서, 조직의 표준 프로세스 집합으로부터 테

일러된 ‘관리 프로세스(managed process)’를 말한다. 프로젝트의 업무(task), 액티비티를 계획,

수행, 개선하는 기본 원칙을 제공한다.

• 조직의 프로세스 자산(Organizational Process Asset)

프로세스들을 기술, 구현, 개선하는 것과 관련된 산출물들이다. 프로세스 아키텍처

(architecture)와 프로세스 요소들을 포함한 조직의 표준 프로세스 집합, 인증된 생명 주기 모

델의 기술, 조직의 표준 프로세스 집합의 테일러링 지침과 기준(criteria), 조직의 측정값 저장

소(organization’s measurement repository), 조직의 프로세스 자산 라이브러리(organization’s

process asset library)를 기술한다.

• 프로세스 아키텍처(Process Architectures)

표준 프로세스에서의 프로세스 요소들 사이의 순서화(ordering), 인터페이스(interface), 상호의

존성(interdependency), 다른 관련성 등을 기술한다. 또한 프로세스 요소들과 외부 프로세스

사이의 인터페이스, 상호의존성, 다른 관련성 등도 포함한다.

• 프로덕트 생명 주기(Product Life Cycle)

프로덕트에 대한 착상으로부터 시작하여 프로덕트를 더 이상 사용할 수 없을 때까지의 전

기간을 나타낸다. 개념/비전(concept/vision), 실행가능성(feasibility), 설계/개발, 산출(production),

폐기(phase out)로 구성될 수 있다.

• 조직의 측정값 저장소(Organization’s Measurement Repository)

프로세스들과 작업 산출물에 대한 측정 데이터를 수집하고 이용 가능하게 만드는데 사용되

- 16 -

SPIC-20030728-2-PB-004

는 저장소를 말한다. 측정 데이터를 이해하고 분석하는데 필요한 관련 정보와 실제 측정 데

이터를 포함하거나 참조한다.

• 조직의 프로세스 자산 라이브러리(Organization’s Process Asset Library)

조직에서 프로세스를 정의, 구현, 관리하는데 잠재적으로 이용되는 프로세스 자산을 저장하

고 이용 가능하게 만드는데 필요한 정보의 라이브러리를 말한다. 이 라이브러리는 프로세스

를 이용하는 수고를 덜어주는 중요한 자원이다.

• 문서(Document)

문서(document)는 데이터의 모음이다. 종이문서(paper)와 전자적(electronic) 문서를 모두 말한

다.

- 17 -

SPIC-20030728-2-PB-004

4. 단계적 모델(SR)과 계속적 모델(CR) (1) 단계적 모델(SR)의 공통 특성, 일반 목적 및 일반 프랙티스 제도화의 특성 제도화는 프로세스 개선의 결정적인 면이고, 각 성숙 단계내의 중요한 개념이다.

일반 목적 단계적 모델에서, 각 프로세스 영역은 오직 하나의 일반 목적을 가진다. 일반 목적은 그 프

로세스 영역을 만족시키기 위해 어떤 제도가 수행되어야 하는지를 설명한다. 성숙 단계2에

서 각 프로세스 영역은 다음의 일반 목적을 따른다.

• GG2 관리된 프로세스의 제도화: 프로세스는 관리된 프로세스에 의해 제도화.

• GG3 정의된 프로세스의 제도화: 프로세스는 정의된 프로세스에 의해 제도화.

공통 특성 공통 특성은 카테고리내에서 일반 프랙티스의 그룹의 특성을 미리 정의한 것이다. 단계적

CMMI 모델은 4가지 공통 특성을 가지며, 수행을 위한 규약(Commitment for Perform), 수행

능력(Ability to Perform), 구현의 지시(Directing Implementation), 구현의 확인(Verifying

Implementation)이 그것이다. 일반 프랙티스는 이들 공통 특성 카테고리에 의해 분류된다.

공통 특성에 의해 분류된 일반 프랙티스 일반적 프랙티스들은 각 프로세스 영역의 끝에서 나타나며, 일반 목적을 따르며, 공통 특성

에 의해 묶여진다. 일반 프랙티스의 정교화항목(elaboration)은 그 프로세스 영역을 유일하게

지원하기 위한 것이다.

• 수행을 위한 규약

GP 2.1 조직적인 정책의 수립: 프로세스를 계획하고 수행하기 위한 조직적인 정책의 수립과

유지. 프로세스를 위한 조직의 기대 정의.

• 수행 능력 (Ability to Perform) GP 2.2 프로세스 계획한다.

프로세스를 수행하기 위해서 계획을 확립하고 유지한다.

GP 2.3 자원을 제공한다.

프로세스를 수행하고, 작업 산출물을 개발하고, 프로세스 서비스를 제공하기 위해서, 적당

- 18 -

SPIC-20030728-2-PB-004

한 자원을 제공한다.

GP 2.4 책임을 배당한다.

프로세스를 수행하고 작업 산출물을 개발하고, 프로세스 서비스를 제공하기 위해서, 책임

과 권위를 배당한다.

GP 2.5 사람들을 훈련한다.

프로세스를 수행하거나 지원할 때 필요한 사람들을 훈련한다.

GP 3.1 정의된 프로세스를 확립한다.

정의된 프로세스의 기술을 확립하고 유지한다.

• 구현 지시 (Directing Implementation)

GP 2.6 구성을 관리한다.

구성 관리의 적절한 레벨 하에 프로세스의 작업 산출물을 설계한다.

GP 2.7 관련된 스테이크홀더(stakeholder)를 식별하고 수반한다.

계획대로 관련된 스테이크홀더(stakeholder)를 식별하고 수반한다.

GP 2.8 프로세스를 감시하고 제어한다.

프로세스를 수행하기 위한 계획에 대해서 프로세스를 감시하고 제어하고, 적절하게 교정

한다.

GP 3.2 개선 정보를 모은다.

앞으로의 사용을 지원하기 위한 작업 산출물, 측정, 측정 결과, 개선 정보를 모은다.

• 구현 확인 (Verifying Implementation)

GP 2.9 객관적으로 프로세스를 따르는 충실도를 평가한다.

객관적으로 프로세스의 기술, 표준, 과정에 대하여 프로세스를 따르는 충실도를 평가한다.

GP 2.10 높은 레벨의 관리의 상태를 검토한다.

높은 레벨의 관리와 더불어 행동, 상태, 프로세스의 결과를 검토하고 이슈들을 해결한다.

(2) 계속적 모델(CR)의 능력 수준과 일반 모델 컴포넌트 개요 능력 수준과 일반 모델 컴포넌트는 여러 프로세스 영역 안의 프로세스 개선을 추구하는 조

직의 능력을 확립하는데 목적이 있다. 능력 수준, 일반 목적(GG generic goal), 일반 프랙티스

(GP generic practice)를 사용함으로써 사용자는 그들의 프로세스를 개선시킬 수 있을 뿐만 아

니라 그들이 개선시키고자 하는 조직의 프로세스를 기술하거나 평가할 수 있다.

- 19 -

SPIC-20030728-2-PB-004

CMMI 계속적 모델 안에서 사용되는 능력 수준은 각 프로세스 영역의 그 프로세스 개선을

위한 권장 우선순위를 제공하며, 각 프로세스 영역에 대해 관련 있는 특수/일반 프랙티스들

이 제시되어, 이들이 달성될 때 프로세스 성능 개선이라는 목적이 달성된다.

이 섹션에서 “프로세스(the process)”는 프로세스 영역을 구현하는 프로세스나 프로세스들을

의미한다. 7장에서 일반 목적, 일반 프랙티스 그리고 일반 프랙티스 세부 사항(elaboration)을

포함하는 각 프로세스 영역의 섹션에서 프로세스는 이와 같은 의미로 사용된다.

“제도화(institutionalization)”는 각 능력 수준에서 중요한 차원이다. 능력 수준 설명 안에서 언

급되는 제도화는 프로세스가 작업을 수행했다는 것을 의미한다.

CMMI 계속적 모델 안의 특수 목적 이해하기 프로세스 관리, 프로젝트 관리, 지원 카테고리 안의 프로세스 영역에 속하는 특수 프랙티스

들은 모두 능력 수준 1이다. 반면에 다른 영역(예:공학 프로세스 카테고리)은 두 가지 종류

의 특수 프랙티스가 있다. 이 두 가지는 능력 수준 1인 기본 프랙티스와 능력 수준 2 이상

인 높은 능력 수준의 고급 프랙티스이다.

심사에서 계속적 CMMI를 사용할 때 프로세스 영역은 관련 있는 특정 능력 수준으로 등급

매겨진다. 0부터 5까지 여섯 등급의 능력 수준이 있다. 고급 프랙티스를 갖는 프로세스 영역

안에서 고려되는 특정 능력 수준은 특수 목적을 등급매길 때 심사되는 특수 프랙티스의 집

합을 결정한다. 규칙은 아래와 같다.

- 능력 수준 N과 관련 있는 특수 목적을 등급매길 때 특수 목적과 연관된 능력 수

준 N을 통한 모든 특수 프랙티스들은 심사되어야 한다.

능력 수준, 일반 목적 그리고 일반 프랙티스의 설명 안에 있는 “프로세스 영역의 특수 목적

을 만족시키다”라는 구문은 앞에서 언급한 규칙에 입각해 이해되어야 한다.

능력 수준의 달성 프로세스 영역의 능력 수준은 일반 프랙티스 또는 적합한 대체항목의 적용을 통해 이루어진

다. 그들의 적용이 즉각적으로 명백하지 않은 두 가지 방식이 있다.

• 능력 수준 1, 2의 일반 프랙티스의 적용

• 능력 수준 3,4,5의 일반 프랙티스의 적용

프로세스 영역의 능력 수준 1의 달성은 프로세스를 수행했다는 말과 같다. 더 정확히 말하

자면 그 프로세스 영역의 특수 목적을 달성했다는 것을 의미한다.

- 20 -

SPIC-20030728-2-PB-004

프로세스 영역의 능력 수준 2의 달성은 프로세스 영역의 수행을 관리한다는 말과 같다. 즉,

수행할 것을 알려주는 정책이 있고 계획이 있고 제공되는 자원이 있고 할당된 책임이 있고

어떻게 수행할 것인가에 대한 훈련이 있고 통제되는 프로세스 수행으로부터의 선택된 작업

산출물이 있다. 세부적으로 이것이 무엇을 의미하는 가는 프로세스 영역 안에 나타나는 능

력 수준 2의 일반 프랙티스를 위한 일반 프랙티스 세부 사항(elaboration)에 기술되어 있다.

다시 말하자면, 조직적 활동은 어느 프로젝트나 지원 활동과 마찬가지로 계획되고 통제될

수 있다.

프로세스 영역을 위한 능력 수준 3은 특수 목적을 테일러(tailor)할 수 있는 프로세스 영역을

커버하는 조직적인 표준 프로세스가 있다고 가정한다. 여기에는 기억해야 할 두 가지가 있

다.

• 테일러링(tailoring)은 표준 프로세스를 변화시키면 안 된다. 다시 말하자면, 정의

된 프로세스와 표준 프로세스는 동일한 것이다.

• 각 프로세스 영역은 다양한 활동과 반복적으로 수행되는 것들을 커버한다. 새로

운 능력이나 환경을 설명하기 위해 이러한 활동들이 어떻게 수행될 것인가에 대해

tailor하는 것이 필요하다. 예를 들어, 웹을 통한 훈련을 고려하지 않는 조직이 훈련

을 개발하거나 획득하는 표준을 가지고 있다고 할 때, 웹으로 전달되는 코스의 개

발 및 획득을 준비하기 위하여 웹으로 전달되는 훈련의 특별한 어려움과 이익을 설

명하기 위한 표준 프로세스의 테일러(tailor)가 필요하다.

프로세스 영역에서 능력 수준 4 또는 5의 달성은 개념적으로 실현 가능하나 제품 도메인이

매우 안정된 상태를 제외하고 경제적으로 문제가 있다.

능력 수준 0: 불완전(incomplete) 불완전 프로세스는 전혀 수행되지 않거나 부분적으로도 수행되지 않은 프로세스이다. 하나

또는 그 이상의 프로세스 영역의 특수 목적을 만족하지 못한다.

능력 수준 1:수행(performed) 능력 수준 1의 프로세스는 “수행된 프로세스(performed process)”가 그 특징이다.

수행된 프로세스는 프로세스 영역의 특수 목적을 만족시킨 프로세스이다. 그리고 식별된 입

력 작업 산출물을 사용해서 식별된 출력 작업 산출물을 생산할 수 있도록 한다.

불완전 프로세스와 수행된 프로세스의 큰 차이점은 수행된 프로세스는 그 프로세스 영역의

모든 세부 목적을 만족한다는 것이다.

- 21 -

SPIC-20030728-2-PB-004

수준 1 일반 목적(GG Generic Goals)

GG 1 세부 목적을 달성

식별할 수 있는 입력 작업 산출물에서 식별할 수 있는 출력 작업 산출물로 변환함

으로써 프로세스는 프로세스 영역의 세부 목적 달성을 지원한다.

수준 1 일반 프랙티스(GP Generic Practices)

GP 1.1 기본 프랙티스를 수행

작업 산출물을 개발하기 위한 프로세스 영역의 기본 프랙티스를 수행하고

프로세스 영역의 세부 목적을 달성하기 위한 서비스를 제공

능력 수준 2:관리(Managed) 능력 수준 2의 프로세스는 “관리된 프로세스(managed process)”가 그 특징이다.

관리된 프로세스는 정책에 따라 계획되고 실행된 수행 프로세스(능력 수준 1)이고 통제되는

산출물을 생산할 수 있도록 적절한 자원을 지닌 훈련된 사람을 필요로 한다. 또한 감시, 통

제, 검토되며 그 프로세스 설명에 부합하는지 평가된다. 프로세스는 각각의 프로젝트, 그룹

또는 조직적 기능에 의해 생성된다. 프로세스의 관리는 프로세스 영역의 제도화와 그 프로

세스를 위해 성립된 비용, 일정, 품질과 같은 다른 세부 목적의 달성과 관계가 있다. 어떻게

관리된 프로세스가 사용되는가에 대한 예는 3장에 있다.

수행된 프로세스와 관리된 프로세스의 큰 차이점은 프로세스가 관리되고 있는가 하는 점이

다. 관리된 프로세스에서는 계획에 따른 프로세스 수행이 관리된다. 실제 결과와 수행이 계

획으로부터 크게 벗어났을 때 정정하는 활동이 이루어진다. 관리된 프로세스는 계획의 목표

를 달성하고 일치된 수행을 제도화한다.

프로세스를 위한 목표는 프로젝트 또는 조직의 특정 필요사항을 이해하는데 기반을 두고 결

정된다. 목표는 정량적일 수도 있고 정성적일 수도 있다.

프로세스의 목표는 각각의 프로세스를 위한 특수 목적일 수도 있고 더 넓은 범위를 위해 정

의될 수도 있다. 이러한 목표들은 프로세스를 위해 수행되는 정정 활동의 일부분으로 변경

될 수 있다.

관리된 프로세스에 의해 제공되는 통제는 설립된 프로세스가 times of stress동안 유지된다는

것을 보장하도록 해준다.

프로세스의 요구 사항과 목표는 세워진다. 작업 산출물과 서비스의 전달 상태는 정의된 시

점(주요 임무 완료 시점)에서 관리될 수 있다. 수행서약은 이러한 작업들 사이에서 세워진다.

- 22 -

SPIC-20030728-2-PB-004

수행 서약은 필요에 따라 수정된다. 작업 산출물은 관련 있는 사람들에 의해 검토되고 통제

되어진다. 작업 산출물과 서비스들은 그들의 특수 요구 사항을 만족시킨다.

관리 프로세스는 다음의 항목들을 함으로써 제도화 된다:

• 조직의 정책을 고수하기

• 세워진 계획과 프로세스 설명을 따르기

• 적절한 자원(펀드, 사람, 도구)을 제공하기

• 프로세스를 수행하는 책임과 권한 할당하기

• 프로세스를 수행하고 지원하는 사람 훈련시키기

• 형상 관리의 적당한 수준에 작업 산출물 위치시키기

• 관련 있는 스테이크홀더(stakeholder)를 식별하기

• 프로세스를 수행하기 위한 계획에 따라 프로세스 수행의 감시 및 통제, 수정 활

동 수행하기

• 프로세스 설명, 표준, 절차를 따르는 프로세스 및 그 작업 산출물, 서비스를 객관

적으로 평가하기

• 더 높은 수준의 관리를 위한 프로세스의 활동과 상태, 결과들을 검토하고 수정

활동 하기

프로세스가 수행되었음을 보장하기 위해서 제도화는 프로세스의 구현 폭과 깊이 그리고 프

로세스가 자리잡는데 걸린 기간이 타당함을 내포하고 있다.


GG 2 관리된 프로세스 제도화

프로세스는 관리된 프로세스로 제도화된다.


GP 2.1 조직 정책 설립

프로세스를 계획하고 수행하기 위한 조직의 정책을 설립하고 유지보수

GP 2.2 프로세스를 계획

프로세스를 수행하기 위한 계획을 확립하고 유지보수

GP 2.3 자원을 제공

프로세스 수행과 작업 산출물의 개발 그리고 프로세스 서비스의 제공을 위

해서 적절한 자원을 제공

- 23 -

SPIC-20030728-2-PB-004

GP 2.4 책임의 할당

프로세스 수행과 작업 산출물 개발 그리고 프로세스 서비스의 제공을 위한

책임과 권한의 할당

GP 2.5 사람의 훈련

필요에 따라 프로세스를 수행하고 지원하는 사람의 훈련

GP 2.6 형상 관리

형상 관리의 적절한 수준에서 프로세스의 지시된 작업 산출물을 위치시키

기

GP 2.7 관련 있는 스테이크홀더(stakeholder)를 식별하고 연관짓기

계획대로 관련 있는 스테이크홀더(stakeholder)를 식별하고 연관짓기

GP 2.8 프로세스의 감시 및 통제

프로세스 수행을 위한 계획에 따라 프로세스를 감시 및 통제하고 적절한

수정 활동 취하기

GP 2.9 충실도(adherence)에 대한 객관적인 평가

프로세스의 설명, 표준, 절차에 따르는 프로세스의 충실도 평가

GP 2.10 더 높은 수준 관리의 상태 검토

더 높은 수준 관리에 대한 프로세스의 활동, 상태, 결과를 검토하고 문제를

해결

능력 수준 3: 정의(Defined)

능력 수준 3 프로세스는 “정의된 프로세스(defined process)”가 그 특징이다.

정의된 프로세스는 조직의 tailoring 지침에 따라 표준 프로세스의 집합으로부터 tailor 된 관

리 프로세스(능력 수준 2)이고 조직의 프로세스 자산에 작업 산출물과 측정치 그리고 다른

프로세스 개선 정보를 제공하는 프로세스이다.

정의된 프로세스의 기본이 되는 조직의 표준 프로세스의 집합은 오랜 기간을 통해 확립되고

개선된다. 표준 프로세스는 정의된 프로세스 안에 기대되는 기초적 프로세스 엘리먼트를 기

술한다. 또한 표준 프로세스는 이러한 프로세스 엘리먼트들 사이의 관계를 설명한다. 조직의

표준 프로세스 집합의 현재와 미래의 사용을 지원하는 조직 수준의 기반은 오랜 기간을 통

- 24 -

SPIC-20030728-2-PB-004

해 확립되고 개선된다.

조직의 프로세스 자산은 프로세스를 기술하고 구현하고 개선시키는 것과 관련 있는 가공물

이다. 이러한 가공물은 그들이 조직의 비즈니스 목표를 충족시키도록 개발 및 획득되었고

현재 및 미래의 비즈니스 가치를 제공할 수 있도록 기대되는 조직에 의해 투자되었기 때문

에 자산이 된다.

정의된 프로세스는 명백하게 다음을 기술한다:

• 목적 (Purpose)

• 입력 (Inputs)

• 입력 범위 (Entry criteria)

• 활동 (Activities)

• 역할 (Roles)

• 측정 (Measures)

• 확인 단계 (Verification steps)

• 출력 (Outputs)

• 출력 범위(Exit criteria)

정의된 프로세스는 다음을 수행함으로써 제도화된다:

• 관리된 프로세스를 제도화하는 항목을 기술

• 정의된 프로세스와 협력하는 계획을 따름

• 조직 프로세스 자산의 사용과 개선을 지원하기 위한 작업 산출물, 측정치, 개선 정보

들의 수집

관리 프로세스와 정의 프로세스의 중요한 차이점은 프로세스 기술과 표준 그리고 절차의 적

용 범위에 있다. 관리 프로세스에 있어서 프로세스의 설명, 표준 그리고 절차는 특정 프로젝

트, 그룹 또는 조직의 기능에 적용 가능하다. 결과적으로 동일 조직 내에서 두 개의 프로젝

트를 위한 관리 프로세스는 매우 다를 수도 있다.

정의된 능력 수준에서 조직은 증명된 그리고 적은 비용과 시간이 드는 표준 프로세스의 배

치에 관심이 있다. 프로세스 설명, 표준 그리고 절차는 조직의 표준 프로세스 집합으로부터

테일러(tailor)되고 조직의 프로세스 자산과 관련 있기 때문에 정의된 프로세스는 적합하게

조직 전체적으로 일관성을 지니게 된다. 또 다른 큰 차이점은 정의 프로세스는 관리 프로세

스보다 더 자세하게 기술되어 있고 더 엄격하게 수행된다는 것이다. 이것은 개선 정보가 더

이해하기 쉽고 분석하기 쉽고 사용하기 쉽다는 것을 의미한다. 마지막으로 정의된 프로세스

의 관리는 프로세스 활동과 프로세스의 자세한 측정, 그것의 작업 산출물, 서비스의 상호 관

- 25 -

SPIC-20030728-2-PB-004

계에 대한 이해에 의해 제공되는 추가적인 통찰에 기반을 두고 있다.


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

프로세스는 정의된 프로세스로 제도화


GP 3.1 정의 프로세스 확립

정의된 프로세스의 설명을 확립하고 유지

GP 3.2 개선 정보 수집

조직 프로세스와 프로세스 자산의 미래 사용과 개선을 지원하기 위해 프로

세스의 계획과 수행으로부터 도출된 작업 산출물, 측정, 측정 결과, 개선

정보를 수집

능력 수준 4:정량적 관리(Quantitatively Managed)

능력 수준 4 프로세스는 “정량적으로 관리되는 프로세스(quantitatively managed process)”가 그

특징이다.

정량적 관리 프로세스는 통계적 기술과 다른 정량적 기술을 사용하여 통제되는 정의 프로세

스이다. 품질과 프로세스 성능을 위한 정량적 목표는 프로세스를 관리하는 기준으로써 확립

되고 사용된다. 품질과 프로세스 성능은 통계적 용어로 이해되며 프로세스의 생명주기를 동

안 관리된다.

정량적 목표는 조직의 표준 프로세스의 집합의 능력과 조직의 사업 목표, 그리고 고객, 사용

자, 조직, 프로세스 구현자의 요구, 가용 자원을 기초로 한다.

프로세스를 수행하는 사람들은 프로세스의 정량적 관리와 직접적으로 연관되어 있다. 정량

적 관리는 프로덕트를 생산하고 서비스를 제공하는 프로세스의 모든 집합에 대해 수행된다.

전체 프로세스 성능에 중요한 기여자인 서브프로세스는 통계적으로 관리된다. 이러한 선택

된 서브프로세스를 위해 프로세스 성능의 자세한 측정값은 수집되고 통계적으로 분석된다.

프로세스 변화의 특별한 원인은 식별되고 적절한 곳에서 특별한 원인은 미래 발생할 일을

예방하기 위해 기술된다.

품질과 프로세스 수행 측정값은 사실에 기반 한 미래의 의사 결정을 지원하기 위한 조직의

측정 보관소에 병합된다.

- 26 -

SPIC-20030728-2-PB-004

정량적으로 관리된 프로세스는 다음을 함으로써 제도화된다:

• 정의 프로세스를 제도화하는 항목을 기술

• 품질과 프로세스 수행을 위한 정량적 목표를 확립하고 유지

• 프로세스 수행에 중요한 서브프로세스의 수행을 안정화

• 품질과 프로세스 수행을 위해 확립된 정량적 목표를 달성하기 위한 프로세스의 능력에 대

한 이해를 확립하고 유지

정의 프로세스와 정량적 관리 프로세스와의 중대한 차이점은 프로세스 수행의 예측성이다.

“정량적 관리”라는 용어는 프로세스의 하나 또는 그 이상의 중요 서브프로세스의 수행을 관

리하기 위한 적절한 통계적 기술과 다른 정량적 기술을 사용하여 그 프로세스의 미래의 수

행이 예측될 수 있도록 한다는 것을 내포한다. 정의 프로세스는 오직 품질에 대한 예측만을

제공한다.

프로세스의 수행을 정량적으로 관리하기 위한 활동들:

• 통계적 관리아래에서 수행되어야 할 서브프로세스의 식별

• 품질과 프로세스 수행에 중요한 기여자인 프로덕트와 프로세스 속성을 식별하고 측정

• 서브프로세스의 변동의 특별한 원인을 식별하고 기술

• 선택된 서브프로세스를 관리

• 확립된 정량적 품질과 프로세스 수행 목표를 만족시키는 프로세스의 능력을 예측

• 확립된 정량적 품질과 프로세스 수행 목표가 만족되지 않았을 때 적절한 수정 활동

위에 기술된 수정 활동은 목표의 변화를 포함하고 또한 관련된 스테이크홀더(stakeholder)가

수행 부족에 대해서 정량적으로 이해하고 있고 그에 대해 동의하고 있음을 보증하는 것을

포함한다.

수준 4 일반 목표(GG Generic Goals)

GG 4 정량적 관리 프로세스의 제도화

프로세스는 정량적 관리 프로세스로 제도화


GP 4.1 프로세스를 위한 정량적 목표 확립

고객의 요구와 사업 목표에 기초를 둔 품질과 프로세스 수행을 기술하는

프로세스를 위한 정량적 목표를 확립하고 유지

GP 4.2 서브프로세스 수행의 안정화

- 27 -

SPIC-20030728-2-PB-004

품질과 프로세스 수행의 정량적 목표를 달성하는 프로세스 능력을 결정하

기 위한 하나 또는 그 이상의 서브프로세스의 수행을 안정화

능력 수준 5:최적화(Optimizing)

능력 수준 5 프로세스는 “최적화 프로세스(optimizing process)”가 그 특징이다.

최적화 프로세스는 관련 있는 현재 사업 목표를 만족시키기 위해 변화되고 받아들여지는 정

량적 관리 프로세스이다. 최적화 프로세스는 계속적으로 프로세스 수행을 개선시키는데 초

점을 두고 있다. 프로세스 변동의 근본 원인을 기술하고 조직의 프로세스를 개선시키는 프

로세스 개선은 식별되고 평가되고 배치된다. 조직에 가해지는 비용 부담은 증가하지만 이러

한 개선은 조직의 프로세스 개선 목표를 달성하기 위해 기대되는 기여의 정량적 이해에 기

반 한다. 조직 프로세스의 수행은 계속적으로 개선된다.

선택된 점진적이고 혁신적인 기술적 프로세스 개선은 조직에 체계적으로 관리되고 배치된다.

프로세스 개선의 노력은 정량적인 프로세스 개선 목표에 대해 측정되고 평가된다.

최적화 프로세스는 다음을 수행함으로써 제도화된다:

• 정량적으로 관리되는 프로세스를 제도화하는 항목을 만족

• 정량적 프로세스 개선 목표를 확립하고 유지

• 계속적으로 프로세스 수행의 범위를 개선시키는 점진적이고 혁신적인 기술 개선을 식별하

고 배치

정량적 관리 프로세스와 최적화 프로세스의 중요한 차이점은 최적화 프로세스는 프로세스

변동의 일반적 원인을 기술함으로써 계속적으로 개선한다는 것이다. 정량적 관리 프로세스

는 프로세스 변동의 특정 원인을 기술하고 그 결과에 대한 통계적 예측을 제공한다. 프로세

스는 예측 가능한 결과를 만들 수 있지만 그 결과는 확립된 목표를 달성하기에는 충분하지

못하다. 최적화된 프로세스 안에서 프로세스 변동의 일반 원인은 의미의 이동을 도출하는

방법으로 또는 그것이 안정할 때 상태로 변동을 감소시키는 방법으로 프로세스를 변경시킴

으로써 기술된다. 이러한 변경은 프로세스 수행을 개선시키고 조직의 프로세스 개선 목표를

달성하기 위해 의도된다.

프로세스 변동의 일반 원인은 프로세스의 일부분으로써 프로세스 전체 수행에 영향을 미치

는 원인이다.


- 28 -

SPIC-20030728-2-PB-004

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

프로세스는 최적화 프로세스로 제도화


GP 5.1 계속적인 프로세스 개선의 보증

관련 있는 조직의 사업 목표를 만족시키는 프로세스의 계속적인 개선 보증

GP 5.2 문제의 근본 원인 수정

프로세스 안의 결점의 근본 원인과 다른 문제들을 식별하고 수정

- 29 -

SPIC-20030728-2-PB-004

5. CMMI의 프레임웍 상호작용

CMMI Product Suite는 다양한 규칙 안에서 최상의 프랙티스를 식별하고 기술함으로써 개발되

었다. 성공적인 프로세스 개선의 시작은 조직의 사업 목표로부터 추진된다.

예를 들면, 일반적 사업 목적은 프로덕트를 얻는 데까지 걸리는 시간을 감소시키는 것이다.

프로세스 개선의 목적은 프로젝트 관리 프로세스를 개선시키기 위해서 나왔고 이러한 것은

프로젝트 계획과 프로젝트 감시 및 통제 프로세스 영역에서 찾을 수 있다.

5장에서는 프로세스 개선의 전체적인 그림을 볼 수 있도록 프로세스 영역사이의 상호 작용

을 기술한다. 여기에서 프로세스 영역은 IPPD와 supplier sourcing(SS)을 포함해서 토의되고

설명된다. 만약 IPPD와 SS를 포함하지 않는 모델을 사용한다면 해당 규칙은 무시해도 된다.

IPPD를 위해 IPM(Integrated Project Management) 프로세스 영역이 언급된다. IPPD를 위한 IPM

의 IT(Integrated Teaming)와 OEI(Organizational Environment for Integration)와의 상호작용이 설명

된다. IT와 OEI는 IPPD를 위해 7장에서 설명되고 ISM(supplier Management)는 SS를 위해 7장

에서 언급된다.

CMMI 프로세스 영역의 네 가지 범주

• 프로세스 관리 (Process Management)

• 프로젝트 관리 (Project management)

• 공학 (Engineering)

• 지원 (Support)

프로세스의 상호작용을 토의하기 위해 네 가지로 나누었지만 프로세스 영역은 그들이 정의

된 그룹과 상관없이 다른 영역에 영향을 미치기도 한다. 예를 들면, 결정 분석과 해결 프로

세스 영역(Decision Analysis and Resolution)은 기술적 해결 프로세스 영역(Technical Solution)에

사용되는 정형적 평가를 기술하는 특정 프랙티스를 제공한다. 기술적 해결 프로세스(TS)는

공학 범주(Engineering)이고 결정 분석과 해결 프로세스(DAR)은 지원 범주(Support)이다. 유용

하고 생산적인 방법으로 모델에 적용시키기 위해서 CMMI 모델 컴포넌트들 사이에 존재하

는 상호작용을 알아야 한다.

프로세스 관리 (Process Management)

1) 프로세스 관리 (Process Management)의 범위

- 30 -

SPIC-20030728-2-PB-004

프로세스 관리 (Process Management) 프로세스 영역은 정의, 계획, 자원할당, 배치, 구현, 감시,

통제, 심사, 측정, 프로세스 개선과 관련된 모든 프로젝트 활동을 포함하며, CMMI의 프로세

스 관리 영역은 다음과 같다:

• 조직의 프로세스 초점 (Organizational Process Focus)

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

• 조직의 훈련 (Organizational Training)

• 조직의 프로세스 수행 (Organizational Process Performance)

• 조직의 혁신과 배치 (Organizational Innovation and Deployment)

2) 기본 프로세스 관리 영역 (Basic Process Management Process Areas)

기본 프로세스 관리 프로세스 영역은 조직에 명세화하고 최선의 프랙티스를 공유하는 기본

능력과 조직의 프로세스 자산, 조직과 교차되는 배움을 제공한다.

그림 5-1. 기본 프로세스 관리 영역

• 조직의 프로세스 초점(OPF) 프로세스 영역은 조직의 프로세스와 프로세스 자산의 현재의

장단점에 대한 이해를 기반으로 조직의 프로세스 개선을 계획하고 구현하도록 조직을 돕는

다.

• 조직의 프로세스 정의(OPD) 프로세스 영역은 조직의 표준 프로세스 집합과 조직의 프로세

스 요구와 목적에 기반을 둔 자산을 확립하고 유지한다.

- 31 -

SPIC-20030728-2-PB-004

• 조직의 훈련(OT) 프로세스 영역은 프로젝트들과 지원 그룹의 공통된 전술적인 훈련 요구

와 마찬가지로 조직의 전략적인 훈련 요구를 식별한다.

3) 고급 프로세스 관리 영역 (Advanced Process Management Process Areas)

고급 프로세스 관리 프로세스 영역은 품질과 프로세스 수행을 위한 정량적인 목적을 성취하

기 위한 발전된 능력과 함께 조직에 제공한다. 발전 프로세스 관리 프로세스 영역은 프로세

스 개발과 배치하는 능력, 지원되는 자산에 의존적이다.

• 조직의 프로세스 수행(OPP) 프로세스 영역은 조직의 비즈니스 목적으로부터의 품질과 프

로세스 수행을 위한 정량적인 목적을 유도한다.

• 조직의 혁신과 개발(OID) 프로세스 영역은 품질과 프로세스 수행 목적을 충족시키는 조직

의 능력을 개선하는데 증가적이고 혁신적인 개선을 선택하고 제안하여 배치한다.

그림 5-2. 고급 프로세스 관리 영역

프로젝트 관리(Project Management)

1) 프로젝트 관리 (Project Management)의 범위

프로젝트 관리 (Project management) 프로세스 영역은 계획, 감시, 프로젝트 제어와 관련한 프

로젝트 관리 활동들을 취급하며, CMMI의 프로젝트 관리 프로세스 영역은 다음과 같다:

• 프로젝트 계획 (Project Planning)

• 프로젝트 감시와 제어 (Project Monitoring and Control)

• 공급자 동의 관리 (Supplier Agreement Management)

- 32 -

SPIC-20030728-2-PB-004

• IPPD를 위한 통합 프로젝트 (Integrated Project Management for IPPD)

• 위험 관리 (Risk Management)

• 통합된 팀 (Integrated Teaming)

• 통합된 공급자 관리 (Integrated Supplier Management)

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

2) 기본 프로젝트 관리 프로세스 영역 (Basic Project Management Process Areas)

기본 프로젝트 관리 프로세스 영역은 프로젝트 계획을 관리⋅수립하고, 약정을 관리⋅수립하고,

계획⋅정확한 활동⋅공급자의 동의에 대한 감시에 관련한 기본적인 활동을 기술한다. 그림 5-3

은 기본적인 프로세스 관리 영역 내에 있는 프로세스 영역들간의 상호 작용을 나타낸다.

• 프로젝트 계획(PP) 프로세스 영역은 프로젝트 계획 개발, 스테이크홀더 관리, 약정 계획의

달성, 계획 관리들을 포함한다. 계획은 프로젝트와 제품의 요구사항을 정의하는 것부터 시작

한다. 프로젝트 계획은 다양한 프로젝트 관리와 공학 활동들을 취급한다. 예를 들어, 프로세

스 평가, 제품 평가, 형상 관리 등을 취급한다.

• 프로젝트 감시와 제어(PMC) 프로세스 영역은 감시 활동과 정확한 활동들을 포함한다. 프

로젝트 계획은 적절한 프로젝트 관리 수준 명시, 진행상황 검토, 진행상황을 감시하기 위한

방법들을 명시한다. 진행상황은 프로세스 계획과의 비교를 통해 결정된다.

• 공급자 동의 관리(SAM) 프로세스 영역은 공급자들에 의해 생산되는 작업 비율을 효과적

으로 획득하기 위한 프로젝트의 요구사항을 기술한다. 제품 컴포넌트가 식별되고, 생산할 공

급자가 선택되면, 공급자 동의는 수립된 것이다. 공급자의 진행상황과 수행은 감시되어야 한

다. 수락과 테스트는 공급자가 생산한 제품 컴포넌트에 대해 이루어진다.

그림 5-3. 기본 프로젝트 관리 프로세스 영역

- 33 -

SPIC-20030728-2-PB-004

3) 고급 프로젝트 관리 프로세스 영역 (Advanced Project Management Process Areas)

고급 프로젝트 관리 프로세스 영역은 표준 프로세스로부터 조직에 맞게 테일러 된 프로세스

를 정의, 공급자를 포함한 스테이크홀더에 대한 공동 작업, 위험 관리, 프로젝트를 수행하기

위한 팀의 결성과 유지, 정량적으로 프로젝트를 관리하는 활동과 관련된 활동을 기술한다.

그림 5-4는 진보된 프로세스 관리 영역 내에 있는 프로세스 영역들간의 상호 작용을 나타내

며, 기본 프로젝트 관리 프로세스 영역은 이를 지지한다. IPM과 IPM for IPPD 프로세스 영역

은 표준 프로세스로부터 조직에 맞게 테일러 된 프로세스를 정의하고 관리한다.

• IPPD를 위한 통합된 프로젝트 관리(IPM for IPPD) 프로세스 영역은 프로젝트의 Shared

vision을 생성한다. 수직적으로나 수평적으로 조직과 팀의 Shared vision을 일직선으로 맞추는

것이다. 또한 IPPD를 위한 통합된 프로젝트 관리 프로세스 영역은 제품 개발을 수행하기 위

한 통합된 팀의 구조를 구현하며, 이는 통합된 팀 프로세스 영역과 함께 달성된다.

• 위험 식별이 프로젝트 계획이나 프로젝트 감시와 제어 프로세스 영역에서 다루어졌다 하

더라도, 위험 관리(RSKM) 프로세스 영역에서 위험 관리, 위험 요소, 위험 파라미터의 식별

과 같은 활동들이 더 수행되어져야 한다.

• 정량적인 프로젝트 관리(QPM) 프로세스 영역은 프로젝트 수행과 제품 품질을 관리하기

위한 정량적이고 통계적인 기법들을 적용한다. 프로세스 수행은 예측 가능하며, 프로젝트 변

화의 특별한 원인이 식별될 때 정확환 활동이 가능하다. 프로젝트 변화의 특별한 원인은 부

록 C에 보면 나와 있다.

• 통합된 팀(IT) 프로세스 영역은 통합된 각 팀의 형성과 유지를 공급한다.

• 통합된 공급자 관리(ISM) 프로세스 영역은 제품의 요구사항, 공급자의 작업 산출물과 같은

제품의 소스를 식별하며, 공학과 지지 프로세스 영역과 정보를 공유한다.

- 34 -

SPIC-20030728-2-PB-004

그림 5-4. 고급 프로젝트 관리 프로세스 영역

공학 (Engineering)

1) 공학 (Engineering)의 범위

공학 프로세스 영역은 공학 지침(시스템 공학, 소프트웨어 공학)과 관련한 개발과 관리를 취

급하며, CMMI에 있는 공학 프로세스 영역은 다음과 같다:

• 요구사항 개발 (Requirements Development)

• 요구사항 관리 (Requirements Management)

• 기술적 해결 (Technical Solution)

• 제품 통합 (Product Integration)

• 확인 (Verification)

• 검증 (Validation)

2) 공학 프로세스 영역 사이의 상호작용

공학 프로세스 영역은 소프트웨어 공학과 시스템 공학을 제품 중심의 프로세스 개선 시나리

오로 통합했다. 공학 프로세스 영역은 소프트웨어 제품 개발, 하드웨어 제품 개발, 서비스에

적용 가능하며, 그림 5-5는 공학 프로세스 영역간의 상호작용을 나타낸다.

- 35 -

SPIC-20030728-2-PB-004

그림 5-5. 공학 프로세스 영역

• 요구사항 개발(RD) 프로세스 영역은 고객의 요구사항을 식별하고 이를 제품의 요구사항으

로 바꾼다. 제품의 요구사항은 상위레벨에서 개념적으로 분석하고, 이를 제품 컴포넌트 요구

사항으로 할당한다. 제품 컴포넌트 요구사항은 개발자의 이해와 사용에 의해 제품의 수행,

설계 특징, 확인 요구사항 같은 것을 기술한다. 요구사항 개발 프로세스 영역은 요구사항을

기술적 해결 프로세스 영역과 제품 통합 프로세스 영역으로 공급한다.

• 요구사항 관리(REQM) 프로세스 영역은 요구 사항들을 관리한다. 모든 공학 프로세스 영

역에 영향을 미치는 요구사항의 변화 획득과 제어에 관련된 활동들을 설명한다. 또한 고객

으로부터 제품, 제품 컴포넌트로 요구사항의 추적성을 제공한다.

• 기술적 해결(TS) 프로세스 영역은 제품 통합 프로세스 영역에서 사용될 제품 컴포넌트를

위한 기술적인 데이터 패키지를 개발한다.

• 확인(VER) 프로세스 영역은 제품이 명시된 요구사항과 일치하는지를 보장한다. 확인은 점

진적인 프로세스로써 제품 컴포넌트의 확인으로부터 시작하여, 통합된 제품의 확인으로 마

친다.

• 검증(VAL) 프로세스 영역은 제품이 고객의 요구사항과 일치하는지를 검증한다. 검증은 운

영 환경이나 운영을 시뮬레이트한 환경에서 수행되어져야 한다.

- 36 -

SPIC-20030728-2-PB-004

• 프로덕트 통합(PI) 프로세스 영역은 기대되는 통합 절차, 제품 컴포넌트의 통합, 고객에게

제품의 전달과 관련된 프랙티스들을 수립한다. 특히 제품 통합 이전에 인터페이스와 인터페

이스 요구사항의 확인은 필수적이다.

지원 (Support)

1) 지원 (Support)의 범위

지원 프로세스 영역은 제품의 개발과 유지를 지원하기 위한 활동들을 취급하며, CMMI에 있

는 지원 프로세스 영역은 다음과 같다:

• 형상 관리 (Configuration Management)

• 프로세스와 제품의 품질 보증 (Process and Product Quality Assurance)

• 측정과 분석 (Measurement and Analysis)

• 통합을 위한 조직 환경 (Organizational Environment for Integration)

• 결론 분석과 해결 (Decision Analysis and Resolution)

• 원인 분석과 해결 (Causal Analysis and Resolution)

2) 기본 지원 프로세스 영역 (Basic Support Process Areas)

기본 지원 프로세스 영역은 모든 프로세스 영역에 의해 사용되는 기본 지원 기능들을 기술

한다. 기본 지원 프로세스 영역은 일반적인 프랙티스에 의해 취급되는 지원 기능들을 제공

하며, 그림 5-6은 기본 지원 프로세스 영역간의 상호작용을 나타낸다.

• 측정과 분석(MA) 프로세스 영역은 객관적인 결과를 제공할 수 있는 측정 결과를 이끌어

내는 특정 프랙티스(Specific practices)에 의해 제공받는 모든 프로세스 영역을 지지한다.

• 프로세스와 제품 품질 보장(PPQA) 프로세스 영역은 적용 가능한 프로세스 설명, 표준, 절

차에 대하여 수행된 프로세스, 작업 산출물, 서비스를 객관적으로 평가하기 위한 특정 프랙

티스들에 의해 제공되는 모든 프로세스 영역을 지지한다.

• 형상 관리(CM) 프로세스 영역은 형상 식별, 형상 제어, 형상 감사를 이용한 작업 산출물

의 무결성을 수립하고 유지하는 모든 프로세스 영역을 지지한다.

- 37 -

SPIC-20030728-2-PB-004

그림 5-6. 기본 지원 프로세스 영역

3) 고급 지원 프로세스 영역 (Advanced Support Process Areas)

고급 지원 프로세스 영역은 고급의 지원을 프로젝트와 조직에게 제공하며, 그림 5-7에서는

고급 지원 프로세스 영역간의 상호작용을 나타낸다.

• 원인 분석과 해결(CAR) 프로세스 영역은 프로세스 변화의 공통 원인을 이해하고 프로젝트

프로세스로부터 이를 제거한다.

• 결론 분석과 해결(DAR) 프로세스 영역은 정형적 평가 프로세스에 의해 제공받는 모든 프

로세스 영역을 지원한다.

• 통합을 위한 조직 환경(OEI) 프로세스 영역은 IPPD의 구현을 위한 환경과 접근 방안을 수

립한다.

그림 5-7. 고급 지원 프로세스 영역

- 38 -

SPIC-20030728-2-PB-004

일반 프랙티스를 프로세스 영역에의 적용 (Applying Generic Practices to Process Areas) 일반 프랙티스는 단계적 표현과 계속적 표현에 모두 나와있다. 일반 프랙티스는 사용자가

한 일이 맞는지에 대한 확인을 목적으로 제공하는 것이다. 예를 들어, 프로젝트 계획 프로세

스 영역의 특수 목적을 달성하고자 할 때, 프로젝트 계획 프로세스 영역에 적용 가능한 일

반 프랙티스 중 하나는 “프로젝트 계획 프로세스를 수행하기 위한 계획을 수립한다”이며,

일반 프랙티스는 프로젝트 계획을 위해 수행하는 사용자의 접근 방법을 보장한다.

일반 목적과 일반 프랙티스는 조직 프로세스와 활동을 통하여 약정과 일관성을 제공한다.

약정과 일관성은 “제도화”로 결론 짓는다.

계속적 표현에서, 5개의 일반 목적 아래에 존재하는 일반 프랙티스는 모든 프로세스 영역에

다 나와있다. 일반 목적과 일반 프랙티스는 “일반(Generic)”이라는 단어 뒤에 나온다.

1) 프로세스 영역과 일반 프랙티스의 관계

프로세스 영역과 일반 프랙티스의 관계는 표 1과 같으며, 몇몇 프로세스 관리 프로세스 영

역과 일반 프랙티스는 중첩되어있다.

표 I-5-1. 일반 프랙티스와 관련된 프로세스 영역

일반 프랙티스 일반 프랙티스를 가능하게 하는(혹은 부분적으로 포함되는)

프로세스 영역

능력 수준 3의 일반 프랙티스 조직 프로세스 정의(OPD)에 의해 가능하다. (Enable)

통합된 프로젝트 관리(IPM)에 의해 부분적으로 포함된다.

(Subsume)

능력 수준 4의 일반 프랙티스 조직 프로세스 수행(OPP)에 의해 가능하다. (Enable)

정량적 프로젝트 관리(QPM)에 의해 부분적으로 포함된다.

(Subsume)

지속적인 프로세스 개선을 보

장하는 능력 수준 5의 일반 프

랙티스

조직 혁신과 배치(OID)에 의해 가능하며, 부분적으로 포함

된다.(Enable, Subsume)

문제의 근본 원인 수정하는 능

력 수준 5의 일반 프랙티스

원인 분석과 해결(CAR)에 의해 부분적으로 포함된다.

(Subsume)

- 39 -

SPIC-20030728-2-PB-004

6. CMMI 모델의 사용 Interpreting CMMI Models CMMI 모델은 조직의 특성을 설명하는데 있어 적용 가능한 기준을 제공하며, 이러한 기준

들은 조직의 제품과 서비스를 개발, 획득, 유지하기 위한 프로세스를 향상시키는데 사용된다.

프랙티스를 번역하기 위해서는, 프랙티스들이 프로세스 영역의 목적을 만족하기 위해 사용

되고 결정되는 총괄적인 상황을 고려하는 것이 중요하다.

CMMI 모델은 조직이나 프로젝트에 어떤 프로세스들이 적합한가에 대한 것은 포함하지 않

는다. 대신 비즈니스 목표에 기반 한 개선을 위해 조직에 의해 선택되는 프로세스를 계획하

고 구현하는데 필요한 최소한의 기준을 제공한다.

Appraisals and Benchmarking 프로세스 평가는 개선 시기를 식별하는데 초점을 둔다. 평가 팀은 조직의 개선 목표와 프로

세스들을 식별하고 우선순위를 매기는데 있어 CMMI 모델을 사용한다.

많은 조직은 프로세스 개선에 있어 내부 조직 목표와 외부 고객과 공급자들을 위하여 진행

상황을 벤치마킹하기 위한 값을 발견한다. CMMI 모델을 사용하여 벤치마크하기 위한 레이

팅(rating)에 적합하도록 고려된 방안이 SCAMPI이다.

CMMI 평가 원칙은 다음과 같다.

• 선임자-관리 후원

• 조직의 비즈니스 목표에 초점

• 인터뷰를 받는 사람들을 위한 신용

• 문서화된 평가 방안의 사용

• 기본으로 CMMI와 같은 프로세스 참조 모델의 사용

• 협동적인 팀 접근

• 프로세스 개선을 위한 활동에 초점

CMMI 평가에 대한 사항은 Standard CMMI Appraisal Method for Process Improvement(SCAMPI)

에 나와있으며, 자세한 사항은 http://www.sei.cmu.edu/cmmi/products/assess.html에 나와있다.

1) CMMI를 위한 평가 요구사항

CMMI를 위한 평가 요구사항(Appraisal Requirements for CMMI : ARC)은 CMMI 제품에 기반

한 개발, 정의, 평가 방안을 위한 기준을 포함하며, 다양한 타입의 평가 방안을 위한 요구사

항을 제공한다. 반면, CMM 평가 프레임웍(CMM Appraisal Framework : CAF) 버전 1.0은 소프

트웨어 전용인 CMM과 관련된 평가 방안을 기술한다.

- 40 -

SPIC-20030728-2-PB-004

ARC 문서는 다양한 지침과 평가 방안에 대하여 일관성을 제공하기 위해 설계되었으며, 더

자세한 사항은 SEI 홈페이지에 나와있다.

2) ISO/IEC TR 15504와의 적합성과 순응성

CMMI는 ISO/IEC TR 15504와의 적합성과 순응성을 위해 설계 되었다. ISO/IEC TR 15504의

1998년도 버전과의 고려해야 할 순응성 측면은 두 가지가 있다: 모델 적합성과 평가 순응성

ISO/IEC TR 15504가 2003년도에 나온다면, 아마도 고려사항은 좀 더 달라질 수 있다.

CMMI로의 전이(Transition) 이 섹션에서는 3개의 전이 시나리오를 간략히 설명한다. 처음 2개는 소프트웨어 CMM이나

EIA/IS 731(Electronic Industries Alliance Interim Standard)를 사용해서 개선 활동을 이미 시작한

조직을 가정한다. 세 번째 시나리오는 현재 개선을 위해 특별한 참조 모델을 사용하지 않는

조직을 가정한다.

1) 소프트웨어 CMM을 사용한 조직

이미 높은 성숙도 레벨을 달성한 조직들은 CMMI로 전이하는데 있어 CMMI와의 공통점이

많기 때문에, 많은 이점을 가지며 빠른 전이를 수행할 수 있다. 특히 CMMI에서는 소프트웨

어 CMM과 비교하여 공학, 위험 관리, 측정과 분석 프로세스가 개선되었다.

2) EIA/IS 731을 사용한 조직

EIA/IS 731은 (1) 특수 목적(Specific goal)과 특수 프로세스 영역(Specific Area) 아래에 있는 특

수 프랙티스(Specific Practices)의 재조직 (2) Informative material의 추가와 관련이 있다. 따라서

CMMI로 전이하기 위해서는 CMMI 모델에서 기대되는 것과 EIA/IS 731을 비교해야 한다.

3) CMMI 타입 모델을 사용한 조직

CMM이나 EIA/IS 731같은 것을 사용하지 않는 조직은 CMMI를 이용하는 것이 좋다. 이때

단계적 표현과 계속적 표현 중 어느 쪽을 사용할 것인지 결정하는 것이 중요한데, 단계적

표현과 계속적 표현 중 어느 것이 자신의 조직에 더 적합한지 찾아보는 접근법을

IDEAL(Initiating, Diagnosing, Establishing, Acting, Learning)이라고 하며 이와 관련된 자세한 사

항은 http://www.sei.cmu.edu/ideal/ideal.html을 참조한다.

4) 훈련(Training)

훈련은 조직이 CMMI를 채택하기 위한 핵심 요소이다.

모델(Model) 테일러링(Tailoring)

- 41 -

SPIC-20030728-2-PB-004

1)모델 테일러링 관점

CMMI 모델을 테일러링 하는 두 가지 관점은 다음과 같다.

• 프로세스 개선을 위한 모델의 사용과 관련된 모델 테일러링

• 벤치마킹을 위한 모델의 사용과 관련된 모델 테일러링

2) 내부 프로세스 개선을 위한 모델 테일러링 기준

테일러링은 도메인에 맞는 규칙, 프로세스 영역, 성숙도 수준, 능력 수준을 기술할 수 있어

야 한다. 특히 조직의 비즈니스 요구와 목표에 맞는 프로세스 영역과 프랙티스를 식별해야

한다.

3) 벤치마킹을 위한 모델 테일러링 기준

• 해당하는 CR의 수행 능력 단계와 SR의 성숙도 단계의 범위를 벗어나는 프로세스 영

역들을 빠뜨리지 말아야 한다.

• CMMI에 있는 다른 모델 컴포넌트들도 다 포함되어야 한다.

• 프로세스 영역은 평가 범위를 벗어나거나, 데이터가 충분하지 않으면, “not rated”를 주

게 설계 되었으며, 프로세스 영역이 “not rated’로 되어있으면 성숙도 수준은 결정될 수

없다.

• 특수 프랙티스와 일반 프랙티스는 구현되어져야 한다.

• 어떤 영역에서는 적용되지 않는 프로세스 영역이 있다.

4) 작은 프로젝트를 위한 모델 테일러링

CMMI를 작은 프로젝트(3-6개월짜리)와 조직에 이용하기 위해서는 테일러링 해야 한다. 대

개 모든 프로젝트에서는 조직, 자원, 훈련, 관리자, 품질 보증에 대한 사항은 모두 명시되어

야 한다. 또 프로젝트 계획에 있어서도, 스케줄, 작업, 자원은 명시되어야 한다.

작은 조직이나 프로젝트에서는 회의가 자주 있게 되며, 적은 시간이 걸리고, 또 자세한 내용

을 취급하게 된다. 회의 스케줄은 매일 하는 것에 맞추고, 주간 미팅을 통해 수행한 활동을

감시해야 한다. 또 고객은 프로젝트를 수행하는 팀원들을 잘 알기 때문에, 비공식적으로 이

야기하게 되는 경우가 많은데 이러한 것도 문서화 해야 한다.

5) 평가 테일러링

• 평가 받아야 할 조직, 조사되어야 하는 프로세스 영역, 평가 되어야 하는 레벨 등을

포함한 평가 범위를 수립한다.

• 평가 방안을 선택한다.

• 평가 팀 구성원을 선택한다.

- 42 -

SPIC-20030728-2-PB-004

• 평가 산출물을 수립한다.

• 시간과 같은 평가 제약사항을 수립한다.

- 43 -

SPIC-20030728-2-PB-004

7. Process Areas 요약 표 I-7-1. 각 프로세스 영역의 요약

범주

(Category)

프로세스 영역

(Process Area) 목적

특수 목적과 특수 프랙티스

(특수 목적과 특수 프랙티스는 CR의 표현을 이용)

Organizational

Process Focus

조직의 프로세스와

프로세스 자산의 현

재의 장단점을 이해

하는 것을 기반으로

조직의 프로세스 개

선을 계획하고 구현

하기 위함

SG 1 프로세스 개선 시기 결정 SP 1.1-1 조직의 프로세스 요구 확립 SP 1.2-1 조직의 프로세스 평가 SP 1.3-1 조직의 프로세스 개선 식별

SG 2 프로세스 개선 행동 계획과 구현 SP 2.1-1 프로세스 행동 계획 확립 SP 2.2-1 프로세스 행동 계획 구현 SP 2.3-1 조직의 프로세스 자산 배치 SP 2.4-1 조직의 프로세스 자산 프로세스-

관련 경험들 통합

Organizational

Process Definition

조직의 프로세스 자

산을 사용 가능한 집

합을 확립하고 유지

하기 위함

SG 1 조직의 프로세스 자산 확립 SP 1.1-1 조직의 표준 프로세스 확립 SP 1.2-1 생명 주기 모델 description 확립 SP 1.3-1 테일러링 기준과 지침 확립 SP 1.4-1 조직의 측정값 저장소 확립 SP 1.5-1 조직의 프로세스 자산 라이브러리

확립

Organizational

Training

자신의 역할을 효과

적이고 효율적으로

수행할 수 있도록 사

람들의 기술과 지식

을 개발하기 위함

SG 1 조직의 훈련 능력 확립 SP 1.1-1 전략적 훈련 요구 확립 SP 1.2-1 어떤 훈련 요구가 조직의 책임인

지를 결정 SP 1.3-1 조직의 훈련 전술적인 계획 확립 SP 1.4-1 훈련 능력 확립

SG 2 필요한 훈련 제공 SP 2.1-1 훈련 인도 SP 2.2-1 훈련 기록 확립 SP 2.3-1 훈련 유효성 심사

Organizational

Process

Performance

품질과 프로세스 수

행 목적의 지원 하에

조직의 표준 프로세

스의 집합 수행의 정

량적인 이해를 확립

하고 유지하기 위함

SG 1 수행 기준선과 모델 확립 SP 1.1-1 프로세스 선택 SP 1.2-1 프로세스 수행 측정값 확립 SP 1.3-1 품질과 프로세스 수행 목적 확립 SP 1.4-1 프로세스 수행 기준선 확립 SP 1.5-1 프로세스 수행 모델 확립

Process

Management

Organizational

Innovation and

Deployment

조직의 프로세스와

기술이 측정 가능하

게 개선되도록 점진

적이고 혁신적인 개

선을 선택하기 위함

SG 1 개선 선택 SP 1.1-1 개선 제안을 모으고 분석 SP 1.2-1 혁신들을 식별하고 분석 SP 1.3-1 개선을 안내 SP 1.3-1 배치를 위한 개선 선택

SG 2 개선 배치 SP 2.1-1 배치 계획 SP 2.2-1 배치 관리 SP 2.3-1 배치 측정

- 44 -

SPIC-20030728-2-PB-004

Project Planning

프로젝트 액티비티들

을 정의하는 계획을

확립, 유지하기 위함

SG 1 평가 확립 SP 1.1-1 프로젝트 범위 측정 SP 1.2-1 작업 산출물과 업무 속성의 평가

확립 SP 1.3-1 프로젝트 생명 주기 정의 SP 1.4-1 노력과 비용 측정 결정

SG 2 프로젝트 계획 개발 SP 2.1-1 경비와 일정 확립 SP 2.2-1 프로젝트 위험 식별 SP 2.3-1 데이터 관리 계획 SP 2.4-1 프로젝트 자원 계획 SP 2.5-1 필요한 지식, 기술 계획 SP 2.6-1 스테이크홀더 관련 계획 SP 2.7-1 프로젝트 계획 확립

SG 3 계획 위임(commitment) 획득 SP 3.1-1 프로젝트에 영향을 미치는 계획 검

토 SP 3.2-1 작업과 자원 등급 일치화 SP 3.3-1 계획 위임 획득

Project Monitoring

and Control

프로젝트의 진행사항

에 대한 이해를 제공

하기 위함

SG 1 계획을 고려한 프로젝트 모니터 SP 1.1-1 프로젝트 계획 파라미터 모니터 SP 1.2-1 위임 모니터 SP 1.3-1 프로젝트 위험 모니터 SP 1.4-1 데이터 관리 모니터 SP 1.5-1 스테이크홀더 관련 모니터 SP 1.6-1 진행사항 검토 수행 SP 1.7-1 이정표 검토 수행

SG 2 종료할 교정적인(corrective) 액션 관리 SP 2.1-1 이슈 분석 SP 2.2-1 교정적인 액션 취함 SP 2.3-1 교정적인 액션 관리

Project

Management

Supplier

Agreement

Management

공급자의 산출물 획

득을 관리하기 위함

SG 1 공급자 합의 확립 SP 1.1-1 획득 타입 결정 SP 1.2-1 공급자 선택 SP 1.3-1 공급자 합의 확립

SG 2 공급자 합의 만족 SP 2.1-1 상용(COTS) 산출물 검토 SP 2.2-1 공급자 합의 실행 SP 2.3-1 획득 산출물 수용 SP 2.4-1 산출물 변환

- 45 -

SPIC-20030728-2-PB-004

Integrated Project

Management for

IPPD

조직의 표준 프로세

스 집합으로부터 테

일러 된 통합, 정의된

프로세스에 따라서

관계 있는 스테이크

홀더의 관련과 프로

젝트를 확립, 관리하

기 위함

SG 1 프로젝트의 정의된 프로세스 이용 SP 1.1-1 프로젝트의 정의된 프로세스 확립

SP 1.2-1 프로젝트 액티비티 계획을 위한 조직의 프로세스 자산 이용

SP 1.3-1 계획 통합 SP 1.4-1 통합된 계획을 이용한 프로젝트

관리 SP 1.5-1 조직의 프로세스 자산에 기여

SG 2 관련 스테이크홀더s의 조정과 협력 SP 2.1-1 스테이크홀더 관련 관리 SP 2.2-1 의존성 관리 SP 2.3-1 조정 이슈 해결

SG 3 IPPD를 위한 프로젝트의 shared vision 이용 SP 3.1-1 프로젝트의 shared vision 환경 정의 SP 3.2-1 프로젝트의 shared vision 확립 SG 4 IPPD를 위한 통합팀 조직 SP 4.1-1 프로젝트의 통합팀 구조 결정 SP 4.2-1 통합팀에게로의 요구사항 예비 분

배 개발 SP 4.3-1 통합팀 확립

Risk Management

위험이 발생하기 전

에 잠재적인 문제를

식별하기 위함

SG 1 위험 관리를 준비 SP 1.1-1 위험 소스와 카테고리 결정 SP 1.2-1 위험 파라미터 정의 SP 1.3-1 위험 관리 전략 수립

SG 2 위험 식별 및 분석 SP 2.1-1 위험 식별 SP 2.2-1 위험의 평가, 카테고리화, 우선 순

위화 SG 3 위험 완화

SP 3.1-1 위험 완화 계획 개발 SP 3.2-1 위험 완화 계획 구현

Integrated Teaming

작업 산출물의 개발

을 위하여 팀을 조성

하고 유지하기 위함

SG 1 팀 구성 수립 SP 1.1-1 팀의 작업 식별 SP 1.2-1 요구되는 지식과 기술 식별 SP 1.3-1 적적한 팀 구성원 할당

SG 2 팀 운영 결정 SP 2.1-1 shared vision 수립 SP 2.2-1 팀의 허가서 수립 SP 2.3-1 역할과 책임 정의 SP 2.4-1 운영 절차 수립 SP 2.5-1 팀 인터페이스 사이의 협력

Integrated Supplier

Management

프로젝트의 요구사항

을 만족하고, 선택된

공급자들을 관리하는

데 사용되는 프로덕

트의 소스들을 식별

하기 위함

SG 1 제품의 소스를 분석 및 선택 SP 1.1-1 제품의 잠재적인 자원 분석 SP 1.2-1 제품의 자원을 평가 및 결정

SG 2 공급자와 작업 재조정 SP 2.1-1 선택된 공급자 프로세스를 감시 SP 2.2-1 선택된 공금자의 작업 산출물 평

가 SP 2.3-1 공급자 동의나 관계 변경

- 46 -

SPIC-20030728-2-PB-004

Quantitative

Project

Management

프로젝트가 추구하고

는 품질과 프로세스-

수행 목적을 달성하

기 위하여, 정의된 프

로세스를 정량적으로

취급하기 위함

SG 1 프로젝트를 정량적으로 관리 SP 1.1-1 프로젝트의 목적 수립 SP 1.1-2 정의된 프로세스 작성 SP 1.3-1 통계적으로 관리될 서브프로세스

선택 SP 1.4-1 프로젝트 수행 관리

SG 2 서브프로세스 수행을 통계적으로 관리 SP 2.1-1 측정과 분석 기법 선택 SP 2.2-1 변화량에 대하여 통계적인 방안을

적용 SP 2.3-1 선택된 서브프로세스의 수행을 감

시 SP 2.4-1 통계적인 관리 데이터를 기록

Requirements

Management

프로젝트의 제품, 제

품의 컴포넌트에 대

한 요구사항을 취급

하고, 요구사항, 프로

젝트 계획, 작업 산출

물들 사이의 불일치

를 식별하기 위함

SG 1 요구사항 관리 SP 1.1-1 요구사항의 이해 획득 SP 1.1-2 약정을 요구사항으로 획득 SP 1.3-1 요구사항 변화 관리 SP 1.4-1 프로젝트 수행 관리 SP 1.5-1 프로젝트 산출물과 요구사항 사이

의 불일치 식별

Requirements

Development

고객과 제품의 요구

사항을 생산하고 분

석하기 위함

SG 1 고객의 요구사항 개발 SP 1.1-1 스테이크홀더의 요구 수집 SP 1.1-2 요구 알아내기 SP 1.2-1 고객의 요구사항 개발

SG 2 제품의 요구사항 개발 SP 2.1-1 제품과 제품 컴포넌트의 요구사항

수립 SP 2.2-1 제품 요구사항의 할당 SP 2.3-1 인터페이스 요구사항의 식별

SG 3 요구사항의 분석과 검증 SP 3.1-1 운영 개념과 시나리오 수립 SP 3.2-1 요구된 기능의 정의 수립 SP 3.3-1 요구사항 분석 SP 3.4-3 균형을 맞추기 위한 요구사항 분

석 SP 3.5-1 요구사항 검증 SP 3.5-2 포괄적인 방안으로 요구사항 검증

Engineering

Technical Solution

요구 사항에 대한 해

결책을 설계, 개발,

구현하기 위함

SG 1 프로덕트 컴포넌트 해결책 선택 SP 1.1-1 대안과 선택 기준 개발 SP 1.1-2 자세한 대안과 선택 기준 개발 SP 1.2-2 작동 개념과 시나리오 도출 SP 1.3-1 프로덕트 컴포넌트 해결책 선택

SG 2 설계 개발 SP 2.1-1 프로덕트 또는 프로덕트 컴포넌트

설계 SP 2.2-3 기술적 데이터 패키지 확립 SP 2.3-1 인터페이스 설명 확립 SP 2.3-3 기준을 사용하는 인터페이스 설계

SP 2.4-3 생성, 구매 또는 재사용 분석을 수행 SG 3 프로덕트 설계를 구현

SP 3.1-1 설계를 구현 SP 3.2-1 프로덕트 지원 문서 개발

- 47 -

SPIC-20030728-2-PB-004

Product Integration

프로덕트 컴포넌트로

부터 프로덕트를 조

립하고 그 프로덕트

의 기능이 적합하게

통합되었는지 보증하

고 인도하기 위함

SG 1 프로덕트 통합을 준비 SP 1.1-1 통합 순서를 결정 SP 1.2-2 프로덕트 통합 환경을 확립 SP 1.3-3 프로덕트 통합 절차와 기준 확립

SG 2 인터페이스 적합성 보증 SP 2.1-1 완전성을 위한 인터페이스 설명을

검토 SP 2.2-1 인터페이스 관리

SG 3 프로덕트 컴포넌트 조립과 프로덕트 인

도 SP 3.1-1 통합을 위한 프로덕트 컴포넌트의

준비 확인 SP 3.2-1 프로덕트 컴포넌트 조립 SP 3.3-1 조립된 프로덕트 컴포넌트 평가 SP 3.4-1 프로덕트 또는 프로덕트 컴포넌트

를 포장 및 인도

Verification

구체적인 요구 사항

을 만족시키는 선택

된 작업 산출물을 보

증하기 위함

SG 1 확인을 준비 SP 1.1-1 확인을 위해 작업 산출물을 선택 SP 1.2-2 확인 환경 확립 SP 1.3-3 확인 절차와 기준 확립

SG 2 동료검토를 수행 SP 2.1-1 동료검토를 준비 SP 2.2-1 동료검토를 수행 SP 2.3-2 동료검토 데이터 분석

SG 3 선택된 작업 산출물 확인 SP 3.1-1 확인 수행 SP 3.2-2 확인 결과 분석 및 수정 활동 식

별

Validation

프로덕트 또는 프로

덕트 컴포넌트가 의

도된 환경에 놓였을

때 그것의 의도된 사

용을 만족하는가를

증명하기 위함

SG 1 검증 준비 SP 1.1-1 검증을 위한 프로덕트 선택 SP 1.2-2 검증 환경 확립 SP 1.3-3 검증 절차와 기준 확립

SG 2 프로덕트 또는 프로덕트 컴포넌트 검증

SP 2.1-1 검증 수행 SP 2.2-1 검증 결과 분석

Support

Configuration

Management

형상 식별, 형상 제

어, 형상 상태 기술,

형상 감사에 사용하

는 작업 제품의 무결

성을 수립하고 유지

하기 위함

SG 1 Baseline 확립 SP 1.1-1 형상 아이템 식별 SP 1.2-2 형상 관리 시스템 확립 SP 1.3-3 베이스라인 생성 또는 해제

SG 2 변화 추적과 제어 SP 2.1-1 변화 요청 추적 SP 2.2-1 형상 아이템 제어

SG 3 무결성 확립 SP 3.1-1 형상 관리 보고 확립 SP 3.2-1 형상 감사 수행

- 48 -

SPIC-20030728-2-PB-004

Process and

Product Quality

Assurance

프로세스와 관련 작

업 산출물에 대한 객

관적 식견을 관리자

에게 제공하기 위함

SG 1 프로세스와 작업 산출물을 객관적으로 평가

SP 1.1-1 프로세스를 객관적으로 평가 SP 1.2-1 작업 산출물과 서비스를 객관적으

로 평가 SG 2 객관적 식견 제공

SP 2.1-1 Noncompliance Issue의 해결책을 보

증 SP 2.2-1 기록을 확립

Measurement and

Analysis

관리 정보 요구들을

지원하는데 사용하는

측정 능력을 개발하

고 유지하기 위함

SG 1 측정치 정렬과 활동 분석 SP 1.1-1 측정 대상 확립 SP 1.2-1 측정 지정 SP 1.3-1 데이터 수집과 저장 절차 지정 SP 1.4-1 분석 절차 지정

SG 2 변화 추적과 제어 SP 2.1-1 측정 데이터 수집 SP 2.2-1 측정 데이터 분석 SP 2.3-1 데이터와 결과의 저장 SP 2.4-1 결과 전달

Decision Analysis

and Resolution

정형화된 평가 프로

세스는 수립된 기준

들에 대하여 식별된

대안들을 평가하는데

이 정형화된 평가 프

로세스를 사용하여

가능한 결정들을 분

석하기 위함

SG 1 선택적인 것의 평가 SP 1.1-1 결정 분석을 위한 지침 확립 SP 1.2-1 평가 기준 확립 SP 1.3-1 선택적인 해결 식별 SP 1.4-1 평가 방법 선택 SP 1.5-1 선택적인 것의 평가 SP 1.6-1 해결 선택

Organizational

Environment for

Integration

통합된 제품과 프로

세스 개발 기반을 제

공하고 통합을 위한

인적 자원을 관리하

기 위함

SG 1 IPPD 기반을 제공 SP 1.1-1 조직의 공유 비전 확립 SP 1.2-1 통합된 작업 환경 확립 SP 1.3-1 IPPD-유일 기술 요구사항 식별

SG 2 통합을 위한 사람 관리 SP 2.1-1 지도 메커니즘 확립 SP 2.2-1 통합을 위한 동기 확립 SP 2.3-1 팀과 가정 조직 책임 균형을 위한

메커니즘 확립

Causal Analysis

and Resolution

결점과 다른 문제점

들의 원인을 식별하

고 미래에 발생되는

것으로부터 예방하기

위한 조치를 취하기

위함

SG 1 문제점의 원인 결정 SP 1.1-1 분석을 위한 문제 데이터 선택 SP 1.2-1 원인 분석

SG 2 통합을 위한 사람 관리 SP 2.1-1 활동 제안 구현 SP 2.2-1 변화의 영향 평가 SP 2.3-1 데이터 기록

- 49 -

SPIC-20030728-2-PB-004

II. 여러 표준의 V&V 영역

1. CMM의 V&V 영역

CMM은 조직의 소프트웨어 프로세스 성숙 수준을 평가하고, 그 수준을 향상시키기 위하여

수행하여야 할 주요활동을 정의한다.

CMM(SW-CMM)의 경우, Level 3: Define의 동료 검토(peer reviews)라는 핵심 프랙티스 영역에

서 소프트웨어 V&V를 제시한다.

동료 검토(Peer Reviews)

표 II-1-1. 동료 검토 핵심 프랙티스 영역

목적 (Purpose)

초기에 효율적으로 소프트웨어 작업 프로덕트의 결함을 제거하기 위함

활동 (Practices)

Goal 1 동료 검토 액티비티는 계획된다 목적 (Goals)

Goal 2 소프트웨어 작업 산출물 안의 결함은 식별되고 제거된다

Commitment to

perform Commitment 1

프로젝트는 동료 검토를 수행하기 위한 조직의 정책을 따른다

Ability 1 적절한 자원과 펀드는 각각의 소프트웨어 작업 산출물의 동료

검토를 수행하기 위해 제공된다

Ability 2 동료 검토 리더는 동료 검토를 어떻게 수행해야 하는가에 대한

훈련을 받는다 Ability to perform

Ability 3 동료 검토에 참가하는 검토자는 동료 검토의 목적, 원칙, 방법

론에 대한 필수 트레이닝을 받는다

Activity 1 동료 검토는 계획되고 그 계획은 문서화된다

Activity 2 동료 검토는 문서화된 절차에 따라 수행된다 Activities

performed Activity 3 수행된 데이터와 동료 검토 결과는 기록된다

Measurement and

analysis Measurement 1

측정과 분석은 동료 검토 활동의 상태를 결정하는데 사용된다

Verifying

implementation Verification 1

SQA 그룹은 동료 검토를 위한 액티비티와 작업산출물을 검토

및 감사하고 결과를 보고한다

- 50 -

SPIC-20030728-2-PB-004

2. CMMI의 V&V 영역

CMMI는 확인(verification)과 검증(validation)이라는 두 프로세스 영역을 아래와 같이 제시한

다. 두 PA는 CMMI 단계적 모델의 Level 3: Defined에 속하고, 연속적 모델의 공학

(engineering) 카테고리에 속한다.

Verification (계속적(Continuous) 모델의 ‘공학(Engineering)’ 카테고리 내)

표 II-2-1. 확인 프로세스 영역

목적 (Purpose)

구체적인 요구 사항을 만족시키는 선택된 작업 산출물을 보증하기 위함

활동 (Practices)

특수 목적 (SG) 특수 프랙티스 (SP) 서브프랙티스 (Subpractices)

SP 1.1-1 확인을 위해 작업 산출

물을 선택

1. 확인을 위한 작업 산출물을 식별 2. 각 선택된 작업에 의해 만족되어질 요구사항 식별 3. 사용 가능한 확인 방법 식별 4. 각 선택된 작업 산출물을 위해 사용될 확인 방법 정의 5. 확인될 작업 산출물의 식별과 만족되어질 요구사

항 그리고 사용될 방법을 통합

SP 1.2-2 확인 환경 확립

1. 확인 환경 요구사항 식별 2. 재사용과 수정 가능한 확인 리소스 식별 3. 확인을 위한 도구 식별 4. 테스트 도구나 소프트웨어와 같은 확인 지원 도구

나 환경을 획득

SG 1 확인을 준

비

SP 1.3-3 확인 절차와 기준 확립

1. 통합된 확인 절차의 집합을 생성 2. 확인 기준을 개발하고 정제 3. 예상되는 결과, 허가되는 견고성, 요구사항을 만족

시키는 다른 기준을 식별 4. 확인을 지원하기 위해 요구되는 도구나 환경 컴포

넌트를 식별

- 51 -

SPIC-20030728-2-PB-004

SP 2.1-1 동료검토를 준비

1. 어떤 종류의 동료 검토가 수행될 것인지 결정 2. 동료 검토동안 데이터를 수집하기 위한 요구사항 정의 3. 동료 검토를 위한 입력과 출력을 확립하고 유지보

수 4. 다른 동료 검토를 요구하는 기준을 확립하교 유지

보수 5. 작업 산출물이 일치성을 가지고 검토되고 있음을 보증하기 위한 체크리스트를 확립하고 유지보수 6. 동료 검토 훈련 날짜 등의 자세한 동료 검토 일정

을 개발 7. 작업 산출물이 동료 검토 입력 기준을 만족하는가

를 보증 8. 참여자가 적절하게 동료 검토를 준비할 수 있도록 검토될 작업 산출물과 그것과 연관된 정보들을 참여

자에게 분배 9. 적합하게 동료 검토를 위한 역할을 할당 10. 동료 검토를 수행하기에 앞서 작업 산출물을 검

토함으로써 동료 검토를 준비

SP 2.2-1 동료검토를 수행

1. 동료 검토에서 할당 받은 역할을 수행 2. 작업 산출물에서의 결함과 다른 이슈들을 식별하

고 문서화 3. 활동 항목을 포함하는 동료 검토의 결과를 기록 4. 동료 검토 데이터를 수집 5. 활동 항목을 식별하고 relevant stakeholder에게 이슈

에 대해 논의 6. 더 필요하다면 추가적인 동료 검토를 수행 7. 동료 검토를 위한 출력 기준이 만족됨을 보증

SG 2 동료검토를

수행

SP 2.3-2 동료검토 데이터 분석

1. 동료 검토의 준비, 수행, 결과와 관련된 데이터를 기록 2. 앞으로 참조와 분석을 위한 데이터를 저장 3. 동료 검토 데이터가 부적절하게 사용되지 않았음

을 보증하기 위해서 데이터를 보호 4. 동료 검토 데이터 분석

SP 3.1-1 확인 수행

1. 그들의 요구사항에 대해 선택된 작업 산출물의 확

인을 수행 2. 확인 활동의 결과를 기록 3. 작업 산출물의 확인으로부터 나오는 활동 항목을 식별 4. 가능한 방법과 절차들로부터 실제 수행되는 확인 방법과 편차를 문서화

SG 3 선택된 작

업 산출물 확인

SP 3.2-2 확인 결과 분석 및 수

정 활동 식별

1. 예상되는 결과와 실제 결과를 비교 2. 확립된 확인 기준에 근거하여 요구 사항을 만족시

키지 못하는 프로덕트를 식별하고 방법, 절차, 기준, 확인 환경의 문제점을 식별 3. 결함에 대한 확인 데이터를 분석 4. 보고서 안의 분석의 모든 결과를 기록 5. 실제 측정 및 수행과 기술적 수행 파라미터들을 비교하기 위해 확인 결과를 사용 6. 얼마나 결함이 해결되는지에 대한 정보를 제공하

고 그것을 계획 안에서 정형화

- 52 -

SPIC-20030728-2-PB-004

Validation (계속적(Continuous) 모델의 ‘공학(Engineering)’ 카테고리 내)

표 II-2-2. 검증 프로세스 영역

목적 (Purpose)

프로덕트 또는 프로덕트 컴포넌트가 예정된 환경에 놓였을 때 그것의 의도된 사용을 만족하는가를

증명하기 위함

활동 (Practices)

특수 목적 (SG) 특수 프랙티스 (SP) 서브프랙티스 (Subpractices)

SP 1.1-1 검증을 위한 프로덕트

선택

1. 프로젝트 생명을 통해 프로덕트나 프로덕트-컴포

넌트 검증을 위한 주요 원칙, 특성, 단계를 식별 2. 검증될 사용자 요구(운용적, 유지보수, 트레이닝, 지원)의 카테고리 결정 3. 검증될 프로덕트와 프로덕트 컴포넌트 선택 4. 프로덕트나 프로덕트-컴포넌트 검증을 위한 평가 메소드(method) 선택 5. 관련된 스테이크홀더와 함께 검증 선택, 제약사항, 메소드 검토

SP 1.2-2 검증 환경 확립

1. 검증 환경 요구사항 식별 2. 고객-공급 프로덕트 식별 3. 재사용 아이템 식별 4. 테스트 장치와 도구 식별 5. 재사용과 수정을 위해 이용 가능한 검증 자원 식

별 6. 상세한 자원의 이용가능성 계획

SG 1 검증 준비

SP 1.3-3 검증 절차와 기준 확립

1. 프로덕트나 프로덕트 컴포넌트의 검증에 영향을 미치는 이슈들이 식별되고 결정되는 것을 보장하기 위해 프로덕트 요구사항을 검토 2. 선택된 프로덕트나 프로덕트 컴포넌트의 검증을 위한 환경, 운용적 시나리오, 절차, 입출력물, 기준의 문서화 3. 검증 이슈를 식별하기 위해 검증 환경의 맥락에서 성숙되는 디자인 심사

SP 2.1-1 검증 수행

SG 2 프로덕트

또는 프로덕트

컴포넌트 검증 SP 2.2-1 검증 결과 분석

1. 예상 결과와 실제 결과 비교 2. 확립된 검증 기준에 기반해서, 예정된 운용 환경

에서 적합하게 수행되지 않는 프로덕트와 프로덕트 컴포넌트를 식별하거나 메소드, 기준, 환경이 가진 문제를 식별 3. 결함을 위한 검증 데이터 분석 4. 분석 결과 기록과 이슈 식별 5. 예정된 사용이나 운용적 요구사항과 실제 측정, 수행을 비교하기 위해 검증 결과 사용

- 53 -

SPIC-20030728-2-PB-004

3. ISO/IEC 15504 (SPICE)의 V&V 영역

ISO/IEC 15504(SPICE)는 소프트웨어 프로세스 심사를 위한 프레임웍을 제공하며, 소프트웨어

를 획득(acquisition), 공급(supply), 개발(development), 운용(operation), 유지보수(maintenance) 및

지원(support)하는 조직에 사용될 수 있다.

ISO/IEC 15504(SPICE)는 소프트웨어 생명주기의 다른 프로세스들에 의해 고용되는 프로세스

들로 구성된 지원(support) 프로세스 카테고리 내 아래의 프로세스들에서 소프트웨어 V&V를

제시하고 있다.

확인(verification) 프로세스

표 II-3-1. 확인 프로세스

목적

확인 프로세스의 목적은 각 소프트웨어 제품과/이나 서비스가 명시된 요구사항을 적절히 반영한

다는 것을 입증하는 것이다

기반 프랙티스 (Base Practices)

SUP.4.BP1 확인 전략을 개발한다

SUP.4.BP2 확인을 수행한다

SUP.4.BP3 확인 결과에 따른 조치를 결정한다

SUP.4.BP4 확인 결과에 따른 조치를 추적한다

검증(validation) 프로세스

표 II-3-2. 검증 프로세스

목적

검증프로세스의 목적은 소프트웨어 제품의 의도된 사용을 위한 요구사항을 만족시켰다는 것을 입

증하는 것이다


SUP.5.BP1 검증 전략을 개발한다

SUP.5.BP2 검증을 수행한다

SUP.5.BP3 검증 결과에 따라 조치를 결정한다

SUP.5.BP4 검증 결과에 따라 조치를 추적한다

합동 검토(joint review) 프로세스

표 II-3-3. 합동 검토 프로세스

목적

합동 검토 프로세스의 목적은 계약의 목적을 달성하기 위한 진행상황에 대한 고객의 일반적인 이

해를 유지하는 것이다

- 54 -

SPIC-20030728-2-PB-004


SUP.6.BP1 합동 검토를 준비한다

SUP.6.BP2 검토 기준을 결정한다

SUP.6.BP3 합동 관리 검토를 수행한다

SUP.6.BP4 합동 기술 검토를 수행한다

SUP.6.BP5 합동 프로세스 검토를 수행한다

SUP.6.BP6 합동 시스템 승인 검토를 수행한다

SUP.6.BP7 검토 결과에 따라 조치를 결정한다

SUP.6.BP8 검토 결과에 따른 조치를 추적한다

감사(audit) 프로세스

표 II-3-4. 감사 프로세스

목적

감사 프로세스의 목적은 선택된 제품과 프로세스가 요구, 계획, 계약과 일치하는지 독립적으로 결

정하는 것이다


SUP.7.BP1 감사 전략을 개발하고 실행한다

SUP.7.BP2 감사를 계획한다

SUP.7.BP3 소프트웨어 개발 활동을 감사한다

SUP.7.BP4 관리 활동을 감사한다

SUP.7.BP5 프로세스 성능을 감사한다

SUP.7.BP6 최종 제품과 시스템을 감사한다

SUP.7.BP7 감사보고에 따라 교정 행위를 식별한다

SUP.7.BP8 감사 보고에 따른 행위를 추적한다

- 55 -

SPIC-20030728-2-PB-004

4. IEEE Std 1012-1998(IEEE Standard for Software Verification and Validation)

IEEE 표준 1012에 따르면, 소프트웨어 V&V 프로세스는 어떤 액티비티의 개발 프로덕트가

그 액티비티 요구사항에 부응하는지, 그 소프트웨어가 예정된 사용과 사용자 요구를 만족시

키는지를 측정한다. 이 측정은 소프트웨어 프로덕트와 프로세스의 분석, 평가(evaluation), 검

토(review), 검사(inspection), 심사(assessment), 테스팅을 포함한다. V&V 프로세스는 운용적 환

경, 하드웨어, 인터페이싱 소프트웨어, 운용자, 사용자를 포함하는 시스템 환경에서의 소프트

웨어를 평가한다.

이 V&V 표준은 획득, 공급, 개발, 운용, 유지보수를 포함하는 모든 소프트웨어 생명 주기

프로세스들에 걸친 프로세스 표준이다. 아래의 표는 IEEE 표준 1012가 제시하는 소프트웨어

V&V 개요의 예제이다.

An example of software V&V overview

표 II-4-1. 소프트웨어 V&V 개요의 예제

V&V

Activities V&V inputs V&V tasks V&V outputs

획득

프로

세스

획득 지원

(1) 시스템 전제조건 기술 (2) 요구사항의 기술 (3) RFP or Tender (4) 시스템 통합 레벨 계획 (5) SVVP (6) 계약서 (7) 공급자 개발 계획과 일정 (8) 사용자 요구사항

(1) V&V Effort에 대한 범위 잡기 (2) V&V Effort와 발주자 사이

의 인터페이스 계획 (3) 시스템의 요구사항 검토

(1) SVVP와 업데이트 (2) 작업 보고서 (3) 변칙 보고서

공급

프로

세스

계획

(1) SVVP (2) 계약서 (3) 공급자 개발 계획과 일정 (4) RFP or Tender (5) 사용자 요구사항

(1) V&V Effort 와 발주자 사

이의 인터페이스를 계획 (2) 계약 확인

(1) 갱신된 SVVP (2) 작업보고서 (3) 변칙보고서

개발

프로

세스

구상

(concept)

(1) 구상 문서 (2) 공급자 개발 계획과 일정 (3) 사용자 요구사항 (4) 획득 요구사항 (5) 개발자 통합 레벨 지정 (6) 위험도 분석보고서 (7) V&V 작업 결과

(1) 개념 문서 평가 (2) 민감도 분석 (3) 하드웨어/소프트웨어/사용

자 요구사항 할당 분석 (4) 추적성 분석 (5) 위험도 분석 (6) 위험 가능성 분석

(1) 작업보고서 (2) 변칙보고서

- 56 -

SPIC-20030728-2-PB-004

요구사항

(1) 구상 문서 (2) SRS (3) IRS (4) 민감도 작업보고서 (5) 사용자 문서 (6) 시스템 테스트 계획 (7) 인수 테스트 계획 (8) 소프트웨어 형상관리 프로

세스 문서 (9) 위험도 분석보고서 (10) 공급자 개발 계획과 일정 (11) V&V 작업 결과

(1)추적성 분석 (2) 소프트웨어 요구사항 평

가 (3) 인터페이스 분석 (4) 민감도 분석 (위험도 분

석) (5) 시스템 확인&검증 테스

트 계획 생성과 확인 (6) 인수 V&V 테스트 계획 생성과 확인 (7) 형상 관리 평가 (8) 위험도 분석 (9) 위험가능성 분석

(1) 작업보고서 (2) 변칙보고서 (3) V&V 테스트 계획

-시스템 -인수

설계

(1) SRS (2) SDD (3) IRS (4) IDD (5) 설계 표준 (6) 구상 문서 (7) 민감도 작업 보고서 (8) 테스트 계획과 설계 (9) 사용자 문서 (10) 위험도 분석 보고서 (11) 공급자 개발 계획과 일정 (12) V&V 작업 결과

(1) 추적성 분석 (2) 소프트웨어 설계 평가 (3) 인터페이스 분석 (4) 민감도 분석 (5) 컴포넌트 확인 검증 테

스트 계획 작성 및 확인

(6) 통합 V&V 테스트 계획 및 확인 (7) V&V 테스트 디자인 작성 및 확인 (8) 위험도 분석 (9) 위험가능성 분석.

(1) 작업보고서 (2) 변칙보고서 (3) V&V 테스트 계획

-컴포넌트 -통합

(4) V&V 테스트 설계 -컴포넌트 -통합 -시스템 -인수

구현

(1) SDD (2) IDD (3) 소스코드 (4) 코딩 표준 (5) 사용자 문서 (6) 구상 문서 (7) 민감도 작업 보고서 (8) 테스트 계획/케이스 (9) 테스트 프로시저 (10) 컴포넌트 테스트 결과 (11) 위험도 분석 보고서 (12) 공급자 개발 계획과 일정 (13) V&V 작업 결과

(1) 추적성 분석 (2) 소스코드와 소스코드 문

서화 평가 (3) 인터페이스 분석 (4) 민감도 분석 (5) V & V 테스트 케이스 생

성 및 확인 (6) V&V 테스트 절차 생성과 확인 (7) 컴포넌트 V&V 테스트 수

행과 확인 (8) 위험도 분석 (9) 위험가능성 분석

(1) 작업보고서 (2) 변칙보고서 (3) V&V 테스트 케이스

-컴포넌트 -통합 -시스템 -인수

(4) V&V 테스트 프로시저 -컴포넌트 -통합 -시스템

테스트

(1) 테스트 계획, 설계, 케이

스, 프로시저 (2) SDD (3) IDD (4) 소스와 실행 가능한 코드 (5) 사용자 문서 (6) 작업 결과 (7) 위험도 분석 보고서 (8) 공급자 개발 계획과 일정 (9) V&V 작업 결과

(1) 추적성 분석 (2) 인수 V&V 테스트 절차 작성과 확인 (3) 통합 V&V 테스트 수행과 확인 (4) 시스템 V&V 테스트 수행 and 확인 (5) 인수 V&V 테스트 수행과 확인 (6) 위험성 분석 (7) 위험가능성 분석

(1) 작업보고서 (2) 변칙보고서 (3) V&V 테스트 프로시

저 -인수

- 57 -

SPIC-20030728-2-PB-004

설치 & 체

크아웃

(1) 설치 패키지 (2) 사용자 문서 (3) 위험도 분석 보고서 (4) 공급자 개발 계획과 일정 (5) V&V 작업 결과 (6) V&V 액티비티 요약 보고

서

(1) 설치 형상 검토 (2) 설치 체크아웃 (3) 위험도 분석 (4) 위험가능성 분석 (5) V&V 최종보고서 생성

(1) 작업보고서 (2) 변칙보고서 (3) V&V 최종보고서

운용

프로

세스

운용

(1) SVVP (2) 새 제약사항 (3) 제안된 변동 (4) 설치 패키지 (5) 운용 프로시저 (6) 사용자 문서 (7) 구상 문서 (8) 위험도 분석 보고서 (9) 공급자 개발 계획과 일정 (10) 운용적 문제 보고서 (11) V&V 작업 결과

(1) 새로운 제약사항의 평가

(2) 제안된 변동 심사 (3) 운용 프로시저 평가 (4) 위험도 분석 (5) 위험가능성 분석

(1) 작업보고서 (2) 변칙보고서

유지

보수

프로

세스

유지보수

(1) SVVP (2) 인증된 변동 (3) 설치 패키지 (4) 공급자 개발 계획과 일정 (5) 제안된 변동 (6) 변칙 보고서 (7) 유지보수자 통합 레벨 (8) 위험도 분석 보고서 (9) 공급자 개발 계획과 일정 (10) 운용적 문제 보고서 (11) V&V 작업 결과

(1) SVVP 개정 (2) 제안된 변동 심차 (3) 변치 평가 (4) 민감도 분석 (5) 이동 심사 (6) 폐기 심사 (7) 위험도 분석 (8) 위험가능성 분석 (9) 작업 반복

(1) 갱신된 SVVP (2) 작업보고서 (3) 변칙보고서

V&V 액티비티의

관리 (모든 단계의

V&V 프로세스와

병렬적으로 수행

됨)

(1) 모든 V&V 입력물 (2) 모든 V&V 출력물

(1) SVVP 생성 (2) 베이스라인 변경 심사 (3) V&V의 관리 검토 (4) 관리와 기술적 검토 지원

(5) 조직적 프로세스와 지원 프로세스와의 인터페이스

(1) SVVP와 갱신 (2) 작업 보고서 (3) 변칙 보고서 (4) V&V 액티비티 요약 보고서 (5) V&V 최종 보고서 권

장

- 58 -

SPIC-20030728-2-PB-004

5. ISO/IEC 12207의 V&V 영역

ISO/IEC 12207은 소프트웨어 산업체에서 참고할 수 있는 소프트웨어 생명주기 공정들에

대한 공통의 프레임웍을 제공하며, 소프트웨어를 포함한 시스템, 단독형(stand alone) 소프

트웨어 제품 및 서비스의 획득 동안에, 그리고 소프트웨어 제품의 공급, 개발, 운영 및 유지

보수 동안에 적용될 수 있는 공정(process), 활동(activity) 및 세부업무(task)를 포함한다.

ISO/IEC 12207은 소프트웨어 생명주기의 다른 프로세스들을 지원하고, 품질 향상에 공헌하

는 프로세스들로 구성된 지원(support) 프로세스 카테고리 내 아래의 프로세스들에서 소프

트웨어 V&V를 제시하고 있다.

확인(verification) 프로세스

표 II-5-1. 확인 프로세스

활동(activities) 세부 업무(tasks)

6.4.1.1 확인 작업 및 독립성 필요 결정

6.4.1.2 확인공정 설정

6.4.1.3 독립된 확인조직의 선정과 독립성 및 권한 보장

6.4.1.4 확인 활동 대상 및 관련 업무 선정

6.4.1.5 확인 계획서 작성

6.4.1 공정구현

6.4.1.6 확인계획서 실행

6.4.2.1 계약 확인 a) 공급자가 요구사항을 만족시킬 수 있는 능력을 갖고 있는지 확인 b) 요구사항이 사용자 요구를 커버하는지 확인 c) 요구사항 변경을 통제하기 위한 적합한 절차가 보장되는지 확인 d) 소유권, 보증, 저작권 문제 e) 인수 범위가 요구사항에 따라 보장되는지 확인

6.4.2.2 프로세스 확인 a) 프로젝트 계획 요구사항이 적절한지 확인 b) 프로젝트를 위해 선택된 프로세스가 적합하고 구현가능하고 계약에

따라 실행가능한지 확인 c) 프로젝트의 프로세스를 위한 표준, 절차, 환경이 적합한지 확인 d) 프로젝트가 계약에 따라 훈련된 스텝에 의해 수행되는지 확인

6.4.2.3 요구사항 확인 a) 시스템 요구사항의 일치성, 실현가능성, 테스트 가능성 b) 설계에 따라 시스템 요구사항을 적절하게 배치 c) 시스템 요구사항을 반영하는 소프트웨어 요구사항 d) 안전성, 보안성과 관련 있는 소프트웨어 요구사항

6.4.2 확인

6.4.2.4 설계 확인 a) 요구사항과 일치하는지 추적가능한지 확인 b) 설계는 이벤트, 입출력, 인터페이스 등의 적절한 순서를 구현 c) 선택된 설계는 요구사항으로부터 도출 가능 d) 설계는 안전성, 보안성을 고려해서 구현

- 59 -

SPIC-20030728-2-PB-004

6.4.2.5 코드 확인 a) 코드는 설계, 요구사항을 추적 가능해야 하고 요구사항과 코딩 표준

을 순응 b) 코드는 이벤트 순서, 일치하는 인터페이스, 정확한 데이터와 제어흐

름 등을 구현 c) 선택된 코드는 설계와 요구사항으로부터 도출 가능 d) 코드는 안전성, 보안성을 고려해서 구현

6.4.2.6 통합 확인 a) 소프트웨어 컴포넌트와 각 소프트웨어 아이템의 단위가 완전하고

정확하게 소프트웨어 아이템으로 통합되었는지 확인 b) 하드웨어 아이템, 소프트웨어 아이템, 시스템의 수동 조작이 완전하

고 정확하게 시스템으로 통합되었는지 확인 c) 통합 임무는 통합계획에 따라 수행

6.4.2.7 문서화 확인 a) 문서화가 적절하고 완전하고 일관성 있게 되었는가 확인 b) 문서화 준비가 적절한가 확인 c) 문서의 형상관리가 명세 된 절차를 따르는가 확인

검증(validation) 프로세스

표 II-5-2. 검증 프로세스


6.5.1.1 검증 작업 및 독립성 필요 결정

6.5.1.2 검증공정 설정

6.5.1.3 독립 검증 조직의 선정

6.5.1.4 검증계획서 작성 (다음 사항은 포함 내용) a) 검증대상 b) 수행될 검증 세부 업무 c) 검증을 위한 자원, 책임, 스케줄 d) 획득자와 다른 참여자에게 줄 검증보고서를 위한 절차

6.5.1 공정구현

6.5.1.5 검증계획서 실행

6.5.2.1 테스트 명세서 준비(선정된 테스트 요구사항, 테스트 케이스, 테스트

명세를 준비)

6.5.2.2 테스트 요구사항, 사례, 명세서의 용도 보장

6.5.2.3 6.5.2.1과 6.5.2.2을 따라 테스트 수행 a) 스트레스, 경계, 단일 입력을 가지고 테스팅 수행 b) 에러의 영향을 최소화하기 위해 소프트웨어 프로덕트를 테스팅 c) 사용자가 소프트웨어 프로덕트를 이용하여 성공적으로 그들의 의도

한 업무를 달성할 수 있는지 테스팅

6.5.2.4 소프트웨어 프로덕트가 의도된 사용을 만족하는지 검증

6.5.2 검증

6.5.2.5 선택된 목표 환경 아래에서 소프트웨어 프로덕트가 적합한지 테스팅

합동 검토(joint review) 프로세스

표 II-5-3. 합동 검토 프로세스

- 60 -

SPIC-20030728-2-PB-004


6.6.1.1 일정에 따른 주기적 검토

6.6.1.2 필요 자원 동의

6.6.1.3 검토 항목 동의

6.6.1.4 발견된 문제의 기록 및 처리

6.6.1.5 검토 결과의 문서화 및 배포

6.6.1 공정구현

6.6.1.6 검토 결과, 책임 및 마감 기준 동의

6.6.2 프로젝트 관

리 검토

6.6.2.1 프로젝트 상태 평가 및 검토 결과의 내용

6.6.3 기술적 검토 6.6.3.1 기술적 검토의 목적 및 검토 내용

감사(audit) 프로세스

표 II-5-4. 감사 프로세스


6.7.1.1 일정에 따른 감사

6.7.1.2 감사요원의 독립성

6.7.1.3 감사자원 합의

6.7.1.4 감사내용 합의

6.7.1.5 발견된 문제 기록 및 처리

6.7.1.6 감사 결과의 문서화/제공/수령통보

6.7.1 공정구현

6.7.1.7 감사 결과, 책임 및 종료 기준 합의

6.7.2 감사

6.7.2.1 다음의 사항들을 보증하기 위해 감사를 수행 a) 코딩 된 소프트웨어 프로덕트가 설계 문서를 반영하는지 보증 b) 인수 검토와 문서에 기술되어진 테스팅 요구사항이 소프트웨어 프

로덕트의 인수를 위해 적합한지 보증 c) 테스트 데이터가 명세를 따르는지 보증 d) 소프트웨어 프로덕트들이 성공적으로 테스트되고 그들의 명세를 만

족하는지를 보증 e) 테스트 보고서가 정확하고 실제와 예상되는 결과 사이의 불일치가

해결되었는지를 보증 f) 사용자 문서가 명세 된 표준과 일치하는지 보증 g) 액티비티들이 적용 가능한 요구사항, 계획, 계약에 따라 수행되었는

지를 보증 h) 비용과 스케줄이 설립된 계획을 준수했는지를 보증

- 61 -

SPIC-20030728-2-PB-004

6. 각 표준의 V&V 영역 간의 비교

본 연구에서는 CMM(SW-CMM), CMMI, ISO/IEC 15504, ISO/IEC 12207, IEEE Std 1012의 V&V

관련 영역을 일반적인 관점에서 비교/분석하고, CMMI의 V&V 활동을 CMM, ISO/IEC 15504,

ISO/IEC 12207의 각 V&V 활동과 매핑을 한다.

6.1 일반적인 관점에서의 분석과 비교

분석 대상인 CMM(SW-CMM), CMMI, ISO/IEC 15504, ISO/IEC 12207, IEEE Std 1012의 V&V 영

역은 해당 영역, 접근 방법, 목적, 카테고리, 평가 대상, 구조 등에 따라 그 비교가 가능하다.

프로세스 평가나 개선을 목적으로 하는 프로세스 평가 방법론인 CMM, CMMI, ISO/IEC 15504

와 소프트웨어 개발 프로세스 방법론인 ISO/IEC 12207, 소프트웨어 전 생명 주기에 걸친

V&V 프로세스 방법론인 IEEE Std 1012는 다음의 해당 영역에서 소프트웨어 V&V 활동을 제

시하고 있다.

CMM의 V&V 관련 핵심 프랙티스 영역 (KPA) : 동료 검토(Peer Reviews)

CMMI의 V&V 관련 프로세스 영역 (PA) : 확인(Verification), 검증(Validation)

ISO/IEC 15504의 V&V 관련 프로세스 : 확인(Verification), 검증(Validation), 합동 검토

(Joint review), 감사(Audit)

ISO/IEC 12207의 V&V 관련 프로세스 : 확인(Verification), 검증(Validation), 합동 검토

(Joint review), 감사(Audit)

IEEE Std 1012 V&V : 획득, 공급, 개발, 운용, 유지보수의 전 생명주기에 걸친 V&V

활동

CMM의 ‘동료검토(peer reviews)’라는 핵심 프랙티스 영역은 조직 프로세스의 성숙도 단계인

Level 3: Defined (정의된 프로세스)에 속하고, 목적과 공통 특성별 프랙티스로 소프트웨어

V&V 활동을 정의하고 있다. CMMI는 CMM의 핵심 프랙티스 영역을 확장해 ‘확인

(verification)’과 ‘검증(validation)’이라는 두 프로세스 영역에서 V&V 활동을 정의하는데, 이

두 영역은 CMMI의 단계적 모델에서는 조직 프로세스 성숙도 단계인 Level 3: Defined(정의된

프로세스)에 속하고, 계속적 모델에서는 공학(engineering) 카테고리 내에 속한다. CMM,

CMMI 두 표준 모두 확인(verification)의 방법론으로 동료 검토(peer review) 형식을 제시한다.

ISO/IEC 15504와 12207의 V&V 관련 프로세스는 ‘확인(verification)’, ‘검증(validation)’, ‘합동검

토(joint review)’, ‘감사(audit)’ 프로세스로 그 내용이 유사하다. ISO/IEC 15504의 전체 프로세스

카테고리와 프로세스들이 12207에서 정의된 프로세스 카테고리와 프로세스들을 유사하게 따

- 62 -

SPIC-20030728-2-PB-004

르고 있기 때문이다. 이 4 가지 프로세스는 모두 지원 생명 주기 프로세스에 속하는 것으로,

15504의 프랙티스들은 목적과 기반 프랙티스로 나열되고 별도로 해당 프로세스 능력 평가의

지침이 되는 관리 프랙티스가 정의되며, 12207는 목적과 그 프로세스를 구현하는 액티비티의

리스트로 V&V 활동을 정의한다.

IEEE Std 1012는 획득, 공급, 개발, 운용, 유지보수를 포함하는 소프트웨어 전체 생명 주기에

걸쳐 필수적 V&V 활동을 정의하는 소프트웨어 V&V를 위한 프로세스이다. 어떤 액티비티

의 개발 프로덕트가 그 액티비티 요구사항에 부응하는지, 그 소프트웨어가 예정된 사용과

사용자 요구를 만족시키는지를 측정하는 이 표준은 에러-프리한 소프트웨어 개발에 그 목적

을 둔다. ISO/IEC 12207의 생명주기를 따라 소프트웨어 개발의 각 단계에서 필수적으로 수행

되어야 하는 V&V 액티비티를 제시하는데, 각 개발 단계의 V&V 태스크, V&V 입력물, V&V

출력물이 그 내용이다.

아래의 표에서 CMM(SW-CMM), CMMI, ISO/IEC 15504, ISO/IEC 12207, IEEE Std 1012의 V&V

영역을 각 항목에 따라 종합적으로 비교한다.

표 II-6-1. 각 표준의 V&V 비교

CMM의 V&V 관련

핵심 프랙티스 영역

(KPA)

CMMI의 V&V 관련

프로세스 영역 (PA)

ISO/IEC 15504의

V&V 관련 프로세스

ISO/IEC 12207의

V&V 관련 프로세스

IEEE Std 1012

V&V

해당

영역 Peer Reviews

Verification

Validation

Verification

Validation

Joint review

Audit

Verification

Validation

Joint review

Audit

접근

방법 평가방법론 평가방법론 평가방법론 프로세스 방법론 프로세스 방법론

목적 프로세스 평가, 개선 프로세스 평가, 개선 프로세스 평가, 개선

소프트웨어 생명주

기 프로세스의 공통

프레임웍 제공

error-free S/W 개발

레벨 3: Defined (SR) 카테

고리 레벨 3: Defined

공학(engineering) (CR)

지원(support) 프로세

스

지원(support) 생명

주기 프로세스

획득, 공급, 개발,

운용, 유지보수

Staged (조직 프로세스

의 성숙도) 평가

대상

Staged (조직 프로세

스의 성숙도) Continuous (프로세스

의 능력 수준)

프로세스의 능력 차

원

ㅡ

ISO/IEC 12207의 생

명주기를 따른 각

단계의 V&V 대상

구조 - 목적과 공통특성

- 공통특성별 핵심

- SG, SP

- 공통특성별 GG, GP

목적

기반 프랙티스(BP)

목적

액티비티

액티비티

태스크

- 63 -

SPIC-20030728-2-PB-004

프랙티스 - SG, SP

- 수행능력단계별

GG, GP

프로세스 속성 별 관

리 프랙티스(MP)

태스크 입출력

(deliverables)

6.2 표준들의 매핑

CMMI의 V&V 활동을 CMM, ISO/IEC 15504, ISO/IEC 12207의 각 V&V 활동과 매핑을 한다.

6.2.1 CMMI와 CMM의 매핑 결과

아래 표는 CMMI의 ‘확인’ 프로세스 영역에 대하여 CMM의 유사한 V&V 영역인 ‘동료검토’

핵심 프랙티스 영역의 일치 정도를 분석한 것이다. 표의 네 번째 열은 일치하는 CMM 프랙

티스의 이름이고, 일치 정도에 따라 None/Partial/Full로 내용의 유사성 정도를 다섯 번째 열

에 나타내었으며, 표의 마지막 열에 일치의 근거나 기타 의견을 언급하였다.

표 II-6-2. CMMI의 확인 PA와 CMM의 동료 검토 KPA의 매핑

CMMI의 확인 프로세스 영역

특수 목

적 (SG)

특수 프랙티스

(SP) 서브프랙티스 (Subpractices)

CMM 일치정도 근거나 의견

SP 1.1-1 확인을

위해 작업 산

출물을 선택

1. 확인을 위한 작업 산출물을 식별 2. 각 선택된 작업에 의해 만족되어질 요구사항 식

별 3. 사용 가능한 확인 방법 식별 4. 각 선택된 작업 산출물을 위해 사용될 확인 방

법 정의 5. 확인될 작업 산출물의 식별과 만족되어질 요구

사항 그리고 사용될 방법을 통합

None

CMM에는 확인

을 위한 작업 산

출물을 선택하는

항목에 대한 구

체적인 언급이

없다

SP 1.2-2 확인

환경 확립

1. 확인 환경 요구사항 식별 2. 재사용과 수정 가능한 확인 리소스 식별 3. 확인을 위한 도구 식별 4. 테스트 도구나 소프트웨어와 같은 확인 지원 도구나 환경을 획득

Ability1 Partial

CMM에는 동료

검토 수행을 위

한 적절한 자원

과 펀드 제공의

항목이 있다

SG 1 확

인을 준

비

SP 1.3-3 확인

절차와 기준

확립

1. 통합된 확인 절차의 집합을 생성 2. 확인 기준을 개발하고 정제 3. 예상되는 결과, 허가되는 견고성, 요구사항을 만족시키는 다른 기준을 식별 4. 확인을 지원하기 위해 요구되는 도구나 환경 컴포넌트를 식별

None

CMM에는 확인

절차와 기준 확

립에 대한 구체

적인 항목이 없

다

- 64 -

SPIC-20030728-2-PB-004

SP 2.1-1 동료

검토를 준비

1. 어떤 종류의 동료 검토가 수행될 것인지 결정 2. 동료 검토동안 데이터를 수집하기 위한 요구사

항 정의 3. 동료 검토를 위한 입력과 출력을 확립하고 유

지보수 4. 다른 동료 검토를 요구하는 기준을 확립하교 유지보수 5. 작업 산출물이 일치성을 가지고 검토되고 있음

을 보증하기 위한 체크리스트를 확립하고 유지보

수 6. 동료 검토 훈련 날짜 등의 자세한 동료 검토 일정을 개발 7. 작업 산출물이 동료 검토 입력 기준을 만족하는

가를 보증 8. 참여자가 적절하게 동료 검토를 준비할 수 있

도록 검토될 작업 산출물과 그것과 연관된 정보들

을 참여자에게 분배 9. 적합하게 동료 검토를 위한 역할을 할당 10. 동료 검토를 수행하기에 앞서 작업 산출물을 검토함으로써 동료 검토를 준비

Activity1 Full

CMM에는 동료

검토 계획이라는

항목이 구체화되

어 있다

SP 2.2-1 동료

검토를 수행

1. 동료 검토에서 할당 받은 역할을 수행 2. 작업 산출물에서의 결함과 다른 이슈들을 식별

하고 문서화 3. 활동 항목을 포함하는 동료 검토의 결과를 기

록 4. 동료 검토 데이터를 수집 5. 활동 항목을 식별하고 relevant stakeholder에게 이슈에 대해 논의 6. 더 필요하다면 추가적인 동료 검토를 수행 7. 동료 검토를 위한 출력 기준이 만족됨을 보증

Acivity2 Full

CMM에는 동료

검토 수행이라는

항목이 구체화되

어 있다

SG 2 동

료 검토

를 수행

SP 2.3-2 동료

검토 데이터

분석

1. 동료 검토의 준비, 수행, 결과와 관련된 데이터

를 기록 2. 앞으로 참조와 분석을 위한 데이터를 저장 3. 동료 검토 데이터가 부적절하게 사용되지 않았

음을 보증하기 위해서 데이터를 보호 4. 동료 검토 데이터 분석

Measurement1 Full

CMM에는 동료

검토 수행 결과

에 대한 측정과

분석 항목이 구

체화되어 있다

SP 3.1-1 확인

수행

1. 그들의 요구사항에 대해 선택된 작업 산출물의 확인을 수행 2. 확인 활동의 결과를 기록 3. 작업 산출물의 확인으로부터 나오는 활동 항목

을 식별 4. 가능한 방법과 절차들로부터 실제 수행되는 확

인 방법과 편차를 문서화

Activity3 Full

CMM에는 동료

검토 수행 데이

터와 결과의 기

록이라는 항목이

구체화되어 있다

SG 3 선

택된 작

업 산출

물 확인 SP 3.2-2 확인

결과 분석 및

수정 활동 식

별

1. 예상되는 결과와 실제 결과를 비교 2. 확립된 확인 기준에 근거하여 요구 사항을 만

족시키지 못하는 프로덕트를 식별하고 방법, 절차, 기준, 확인 환경의 문제점을 식별 3. 결함에 대한 확인 데이터를 분석 4. 보고서 안의 분석의 모든 결과를 기록 5. 실제 측정 및 수행과 기술적 수행 파라미터들

을 비교하기 위해 확인 결과를 사용 6. 얼마나 결함이 해결되는지에 대한 정보를 제공

하고 그것을 계획 안에서 정형화

Verification1 Partial

CMM에는 동료

검토를 위한 액

티비티와 작업산

출물의 검토/감

사/보고라는 항

목이 있다

- 65 -

SPIC-20030728-2-PB-004

6.2.2 CMMI와 ISO/IEC 15504의 매핑 결과

아래 표는 CMMI의 ‘확인’과 ‘검증’ 프로세스 영역에 대하여 ISO/IEC 15504의 유사한 V&V

영역들의 일치 정도를 분석한 것이다. 표의 네 번째 열은 일치하는 ISO/IEC 15504 프랙티스

의 이름이고, 일치 정도에 따라 None/Partial/Full로 내용의 유사성 정도를 다섯 번째 열에 나

타내었으며, 표의 마지막 열에 일치의 근거나 기타 의견을 언급하였다.

표 II-6-3. CMMI와 ISO/IEC 15504의 V&V 영역 매핑 결과


특수 목

적 (SG)

특수 프랙티스


ISO/IEC

15504 일치정도 근거나 의견

SP 1.1-1 확인을

위해 작업 산출

물을 선택


별 3. 사용 가능한 확인 방법 식별 4. 각 선택된 작업 산출물을 위해 사용될 확인 방법 정의 5. 확인될 작업 산출물의 식별과 만족되어질 요구


None

SPICE에는 확인

을 위한 작업산

출물 선택에 대

한 구체적인 언

급이 없다

SP 1.2-2 확인

환경 확립

1. 확인 환경 요구사항 식별 2. 재사용과 수정 가능한 확인 리소스 식별 3. 확인을 위한 도구 식별 4. 테스트 도구나 소프트웨어와 같은 확인 지원 도

구나 환경을 획득

None

SPICE에는 확인

환경 확립에 대


급이 없다

SG 1 확

인을 준

비

SP 1.3-3 확인


립

1. 통합된 확인 절차의 집합을 생성 2. 확인 기준을 개발하고 정제 3. 예상되는 결과, 허가되는 견고성, 요구사항을 만

족시키는 다른 기준을 식별 4. 확인을 지원하기 위해 요구되는 도구나 환경 컴

포넌트를 식별

SUP.4.BP1 Partial

SPICE에는 확인

전략 개발이라는

항목이 있다

SG 2 동

료검토

를 수행

SP 2.1-1 동료검

토를 준비

1. 어떤 종류의 동료 검토가 수행될 것인지 결정 2. 동료 검토동안 데이터를 수집하기 위한 요구사항 정의 3. 동료 검토를 위한 입력과 출력을 확립하고 유지

보수 4. 다른 동료 검토를 요구하는 기준을 확립하교 유

지보수 5. 작업 산출물이 일치성을 가지고 검토되고 있음

을 보증하기 위한 체크리스트를 확립하고 유지보수

6. 동료 검토 훈련 날짜 등의 자세한 동료 검토 일

정을 개발 7. 작업 산출물이 동료 검토 입력 기준을 만족하는

가를 보증 8. 참여자가 적절하게 동료 검토를 준비할 수 있도

록 검토될 작업 산출물과 그것과 연관된 정보들을 참여자에게 분배 9. 적합하게 동료 검토를 위한 역할을 할당 10. 동료 검토를 수행하기에 앞서 작업 산출물을 검토함으로써 동료 검토를 준비

SUP.6.BP1SUP.6.BP2

Full Full

SPICE에는 합동

검토 준비와 기

준 결정이라는

구체적인 항목이

있다

- 66 -

SPIC-20030728-2-PB-004

SP 2.2-1 동료검

토를 수행


하고 문서화 3. 활동 항목을 포함하는 동료 검토의 결과를 기록 4. 동료 검토 데이터를 수집 5. 활동 항목을 식별하고 relevant stakeholder에게 이

슈에 대해 논의 6. 더 필요하다면 추가적인 동료 검토를 수행 7. 동료 검토를 위한 출력 기준이 만족됨을 보증

SUP.6.BP3SUP.6.BP4SUP.6.BP5SUP.6.BP6

Partial Partial Partial Partial

SPICE에는 합동

관리 검토, 합동

기술 검토, 합동

프로세스 검토,

합동 시스템 승

인 검토 수행이

라는 항목이 있

다

SP 2.3-2 동료

검토 데이터 분

석

1. 동료 검토의 준비, 수행, 결과와 관련된 데이터를 기록 2. 앞으로 참조와 분석을 위한 데이터를 저장 3. 동료 검토 데이터가 부적절하게 사용되지 않았음

을 보증하기 위해서 데이터를 보호 4. 동료 검토 데이터 분석

None

SPICE에는 데이

터 분석에 대한

구체적인 언급이

없다

SP 3.1-1 확인

수행




SUP.4.BP2 Full

SPICE에는 확인

수행이라는 구체

적인 항목이 있

다

SG 3 선

택된 작

업 산출

물 확인 SP 3.2-2 확인

결과 분석 및

수정 활동 식별

1. 예상되는 결과와 실제 결과를 비교 2. 확립된 확인 기준에 근거하여 요구 사항을 만족

시키지 못하는 프로덕트를 식별하고 방법, 절차, 기

준, 확인 환경의 문제점을 식별 3. 결함에 대한 확인 데이터를 분석 4. 보고서 안의 분석의 모든 결과를 기록 5. 실제 측정 및 수행과 기술적 수행 파라미터들을 비교하기 위해 확인 결과를 사용 6. 얼마나 결함이 해결되는지에 대한 정보를 제공하

고 그것을 계획 안에서 정형화

SUP.4.BP3SUP.4.BP4

Partial Partial

SPICE에는 확인

결과에 따른 조

치를 결정/추적하

는 항목이 있다

CMMI의 검증 프로세스 영역

특수 목

적 (SG)

특수 프랙티스


ISO/IEC


SP 1.1-1 검증을

위한 프로덕트

선택

1. 프로젝트 생명을 통해 프로덕트나 프로덕트-컴포

넌트 검증을 위한 주요 원칙, 특성, 단계를 식별 2. 검증될 사용자 요구(운용적, 유지보수, 트레이닝, 지원)의 카테고리 결정 3. 검증될 프로덕트와 프로덕트 컴포넌트 선택 4. 프로덕트나 프로덕트-컴포넌트 검증을 위한 평가 메소드(method) 선택 5. 관련된 스테이크홀더와 함께 검증 선택, 제약사

항, 메소드 검토

None

SPICE에는 검증

을 위한 프로덕

트 선택에 대한

구체적인 언급이

없다 SG 1 검

증 준비

SP 1.2-2 검증

환경 확립

1. 검증 환경 요구사항 식별 2. 고객-공급 프로덕트 식별 3. 재사용 아이템 식별 4. 테스트 장치와 도구 식별 5. 재사용과 수정을 위해 이용 가능한 검증 자원 식별 6. 상세한 자원의 이용가능성 계획

None

SPICE에는 검증

환경 확립에 대


급이 없다

- 67 -

SPIC-20030728-2-PB-004

SP 1.3-3 검증


립

1. 프로덕트나 프로덕트 컴포넌트의 검증에 영향을 미치는 이슈들이 식별되고 결정되는 것을 보장하기 위해 프로덕트 요구사항을 검토 2. 선택된 프로덕트나 프로덕트 컴포넌트의 검증을 위한 환경, 운용적 시나리오, 절차, 입출력물, 기준

의 문서화 3. 검증 이슈를 식별하기 위해 검증 환경의 맥락에

서 성숙되는 디자인 심사

SUP.5.BP1 Partial

SPICE에는 검증

전략 개발이라는

항목이 있다

SP 2.1-1 검증

수행

SUP.5.BP2 Full

SPICE의 검증 수

행 항목과 일치

한다 SG 2 프

로덕트

또는 프

로덕트

컴포넌

트 검증

SP 2.2-1 검증

결과 분석

1. 예상 결과와 실제 결과 비교 2. 확립된 검증 기준에 기반해서, 예정된 운용 환경

에서 적합하게 수행되지 않는 프로덕트와 프로덕트 컴포넌트를 식별하거나 메소드, 기준, 환경이 가진 문제를 식별 3. 결함을 위한 검증 데이터 분석 4. 분석 결과 기록과 이슈 식별 5. 예정된 사용이나 운용적 요구사항과 실제 측정, 수행을 비교하기 위해 검증 결과 사용

SUP.5.BP3SUP.5.BP4

Partial Partial

SPICE에는 검증

결과에 따른 조

치의 결정/추적이

라는 항목이 있

다

6.2.3 CMMI와 ISO/IEC 12207의 매핑 결과

CMMI의 ‘확인’ 및 ‘검증’ 프로세스 영역과 ISO/IEC 12207의 관련 있는 프로세스 영역에 대

한 일치 정도를 아래의 표가 보여주고 있다. 표의 네 번째 열은 일치하는 ISO/IEC 12207의

프로세스 영역의 세부업무(task) 이름이고, 일치 정도에 따라 None/Partial/Full로 내용의 유사

성 정도를 다섯 번째 열에 나타내었으며, 표의 마지막 열에 일치의 근거나 기타 의견을 언

급하였다.

표 II-6-4. CMMI와 ISO/IEC 12207의 V&V 영역 매핑 결과


특수 목

적 (SG)

특수 프랙티스


ISO/IEC


SG 1 확인

을 준비

SP 1.1-1 확인을

위해 작업 산출

물을 선택


별 3. 사용 가능한 확인 방법 식별 4. 각 선택된 작업 산출물을 위해 사용될 확인 방

법 정의 5. 확인될 작업 산출물의 식별과 만족되어질 요구


6.4.1.1 6.4.1.2 6.4.1.4 6.4.2.1

Partial Partial Partial Partial

이 네 항목은

CMMI의 확인 프

로세스 영역의

서브프랙티스 내

용의 일부를 포

함한다

- 68 -

SPIC-20030728-2-PB-004

SP 1.2-2 확인 환

경 확립

1. 확인 환경 요구사항 식별 2. 재사용과 수정 가능한 확인 리소스 식별 3. 확인을 위한 도구 식별 4. 테스트 도구나 소프트웨어와 같은 확인 지원 도

구나 환경을 획득

6.4.1.4 6.4.2.2

Partial Partial

이 두 항목은

CMMI의 확인 프

로세스 영역의

확인 환경 확립

특수 프랙티스의

서브프랙티스 일

부분을 포함한다

SP 1.3-3 확인 절

차와 기준 확립

1. 통합된 확인 절차의 집합을 생성 2. 확인 기준을 개발하고 정제 3. 예상되는 결과, 허가되는 견고성, 요구사항을 만

족시키는 다른 기준을 식별 4. 확인을 지원하기 위해 요구되는 도구나 환경 컴

포넌트를 식별

6.4.1.5 6.4.1.6

Partial Partial

확인 계획서 작

성과 확인 계획

서 실행은 특수

프랙티스 1.3-3의

내용을 일부분

포함한다

SP 2.1-1 동료 검

토를 준비

1. 어떤 종류의 동료 검토가 수행될 것인지 결정 2. 동료 검토동안 데이터를 수집하기 위한 요구사

항 정의 3. 동료 검토를 위한 입력과 출력을 확립하고 유지

보수 4. 다른 동료 검토를 요구하는 기준을 확립하교 유

지보수 5. 작업 산출물이 일치성을 가지고 검토되고 있음

을 보증하기 위한 체크리스트를 확립하고 유지보

수 6. 동료 검토 훈련 날짜 등의 자세한 동료 검토 일

정을 개발 7. 작업 산출물이 동료 검토 입력 기준을 만족하는

가를 보증 8. 참여자가 적절하게 동료 검토를 준비할 수 있도

록 검토될 작업 산출물과 그것과 연관된 정보들을 참여자에게 분배 9. 적합하게 동료 검토를 위한 역할을 할당 10. 동료 검토를 수행하기에 앞서 작업 산출물을 검토함으로써 동료 검토를 준비

6.6.1.1 6.6.1.2 6.6.1.3

Partial Partial Partial

ISO/IEC 12207의

합동 검토 프로

세스의 이 세가

지 활동은 CMMI

의 동료 검토 준

비 특수 프랙티

스의 서브프랙티

스 일부분을 포

함한다

SP 2.2-1 동료 검

토를 수행


하고 문서화 3. 활동 항목을 포함하는 동료 검토의 결과를 기록

4. 동료 검토 데이터를 수집 5. 활동 항목을 식별하고 relevant stakeholder에게 이슈에 대해 논의 6. 더 필요하다면 추가적인 동료 검토를 수행 7. 동료 검토를 위한 출력 기준이 만족됨을 보증

6.6.1.4 Partial

6.6.1.4는 동료 검

토의 결과를 기

록하는 CMMI의

동료검토 수행

특수 프랙티스의

서브프랙티스 내

용을 포함한다

SG 2 동료

검토를 수

행

SP 2.3-2 동료 검

토 데이터를 분

석

1. 동료 검토의 준비, 수행, 결과와 관련된 데이터

를 기록 2. 앞으로 참조와 분석을 위한 데이터를 저장 3. 동료 검토 데이터가 부적절하게 사용되지 않았

음을 보증하기 위해서 데이터를 보호 4. 동료 검토 데이터 분석

6.6.1.5 6.6.1.6

Partial Partial

동료 검토의 결

과를 문서화한다

- 69 -

SPIC-20030728-2-PB-004

SP 3.1-1 확인 수

행




6.4.2.3 6.4.2.4 6.4.2.5 6.4.2.6 6.4.2.7

Full Full Full Full Full

이 다섯 항목은

확인을 수행하는

서브프랙티스의

내용과 일치한다

SG 3 선택

된 작업

산출물 확

인 SP 3.2-2 확인 결

과 분석 및 수정

활동 식별

1. 예상되는 결과와 실제 결과를 비교 2. 확립된 확인 기준에 근거하여 요구 사항을 만족

시키지 못하는 프로덕트를 식별하고 방법, 절차, 기준, 확인 환경의 문제점을 식별 3. 결함에 대한 확인 데이터를 분석 4. 보고서 안의 분석의 모든 결과를 기록 5. 실제 측정 및 수행과 기술적 수행 파라미터들을 비교하기 위해 확인 결과를 사용 6. 얼마나 결함이 해결되는지에 대한 정보를 제공

하고 그것을 계획 안에서 정형화

None

ISO/IEC 12207의

확인공정에는 확

인 결과를 분석

하고 수정 활동

을 식별하는 내

용이 없다

CMMI의 검증 프로세스 영역

특수 목

적 (SG)

특수 프랙티스


ISO/IEC


SP 1.1-1 검증을

위한 프로덕트

선택

1. 프로젝트 생명을 통해 프로덕트나 프로덕트-컴포넌트 검증을 위한 주요 원칙, 특성, 단계를 식별

2. 검증될 사용자 요구(운용적, 유지보수, 트레이

닝, 지원)의 카테고리 결정 3. 검증될 프로덕트와 프로덕트 컴포넌트 선택 4. 프로덕트나 프로덕트-컴포넌트 검증을 위한 평

가 메소드(method) 선택 5. 관련된 스테이크홀더와 함께 검증 선택, 제약사

항, 메소드 검토

6.5.1.1 6.5.1.2 6.5.1.4

Partial Partial Partial

이 세 항목은 검

증을 위한 대상

설정을 하는 특

수 프랙티스의

서브프랙티스 일

부분을 포함한다

SP 1.2-2 검증 환

경 확립

1. 검증 환경 요구사항 식별 2. 고객-공급 프로덕트 식별 3. 재사용 아이템 식별 4. 테스트 장치와 도구 식별 5. 재사용과 수정을 위해 이용 가능한 검증 자원 식별 6. 상세한 자원의 이용가능성 계획

6.5.1.4 Partial

검증 대상, 검증

세부업무를 포함

하는 검증 계획

서 작성은 검증

환경 확립 프랙

티스의 일부분을

포함한다

SG 1 검증

준비

SP 1.3-3 검증 절

차와 기준 확립

1. 프로덕트나 프로덕트 컴포넌트의 검증에 영향을 미치는 이슈들이 식별되고 결정되는 것을 보장하

기 위해 프로덕트 요구사항을 검토 2. 선택된 프로덕트나 프로덕트 컴포넌트의 검증을 위한 환경, 운용적 시나리오, 절차, 입출력물, 기준

의 문서화 3. 검증 이슈를 식별하기 위해 검증 환경의 맥락에

서 성숙되는 디자인 심사

6.5.2.1 Partial

테스트 명세서를

준비하는 것은

검증을 준비하는

것으로 간주할

수 있다

SG 2 프로

덕트 또는

프로덕트

SP 2.1-1 검증 수

행

6.5.2.3 6.5.2.4 6.5.2.5 6.7.2.1

Full Full Full

Partial

테스트와 감사를

수행하는 것은

검증을 수행하는

것으로 간주할

수 있다

- 70 -

SPIC-20030728-2-PB-004

컴포넌트

검증

SP 2.2-1 검증 결

과 분석

1. 예상 결과와 실제 결과 비교 2. 확립된 검증 기준에 기반해서, 예정된 운용 환

경에서 적합하게 수행되지 않는 프로덕트와 프로

덕트 컴포넌트를 식별하거나 메소드, 기준, 환경이 가진 문제를 식별 3. 결함을 위한 검증 데이터 분석 4. 분석 결과 기록과 이슈 식별 5. 예정된 사용이나 운용적 요구사항과 실제 측정, 수행을 비교하기 위해 검증 결과 사용

None

검증 결과에 대

한 분석은

ISO/IEC 12207에

명시되어 있지

않다

- 71 -

SPIC-20030728-2-PB-004

III. V&V와 테스팅 현황과 이슈

소프트웨어 품질보증은 소프트웨어의 품질이 일정한 기준에 부합되는지를 확인하는 것으

로써 요구사항에 대한 적합성이 높음을 보여주는 것이다. 소프트웨어 품질보증은 유지보수

에 필요한 비용을 줄이고 고품질의 소프트웨어를 개발하기 위해서 반드시 필요하다. 즉, 소

프트웨어의 생산성을 높일 수 있을 뿐만 아니라 신뢰성 향상, 유지보수에 대한 효율성을 보

장한다는 측면에서 매우 중요하다. 특히, 결함 하나로 회사의 명성에 치명타가 될 수 있을

뿐만 아니라 이로 인해 고객까지 잃을 수도 있기 때문에 제품 결합률, 프로젝트 납기준수율,

소프트에어 재사용률, 고객만족도를 위해 소프트웨어 품질 보증은 필요한 것이다.

해외 SW 산업계의 경우 품질보증에 대한 인식이 잘 되어 있으며 민간 차원의 소프트웨어

품질에 대한 시험 인증서비스가 활성화되어 있다. 합리적인 사고방식과 문서화 및 계량화

된 측정결과를 중시하는 문화적 성격을 고려하더라도 기술적 요소와 프로세스, 조직을 유기

적으로 조합, 고객서비스를 제공하는 예를 어렵지 않게 볼 수가 있다. 또한 소프트웨어 품질

인증을 뒷받침할 시험기술과 지원도구를 개발하고 실용적인 평가체계를 구축함으로써 자국

의 소프트웨어 해외경쟁력을 끌어올리기 위해 노력하고 있다.

반면에 품질보증에 대한 국내 SW 산업계를 살펴보면, 아직도 갈 길이 멀다. 우리나라가

소프트웨어 산업의 경쟁력을 높여 수출을 증대시키기 위해서는 무엇보다도 소프트웨어의 품

질을 획기적으로 향상시켜야 한다. 실제로 소프트웨어 개발 프로젝트에 있어서는 품질 능력

이 뒷받침되지 않아 발생하는 일정 지연, 비용 증대, 낮은 생산성 등의 문제가 빈번하며 때

로는 프로젝트 자체가 실패로 돌아가는 경우도 있다 이런 문제를 제대로 해결하지 못하고서

선진 업체간의 경쟁이 치열한 세계시장에서 대형 프로젝트에 참여할 수 있는 기회를 얻는다

는 것은 불가능한 일이다. 그나마 몇몇 대기업을 중심으로 소프트웨어 품질보증을 위한 노

력이 소프트웨어 개발 프로세스 평가 모델인 CMM(Capability Maturity Model)과

SPICE(software Process Improvement Capability dEterminatin)의 레벨 달성으로 드러나고 있으나

내수시장의 포화로 해외에 눈을 돌려야 하는 국내 중소 소프트웨어 회사들에는 그 노력이

미흡한 상황이다. 국내 중소 소프트웨어 회사들의 품질 보증에 대한 인식이 부족할 뿐만 아

니라 테스트 환경이 열악하고 테스팅 전문인력이 부족하여 수작업이나 자사의 제품과 솔루

션 테스팅을 제3자에게 의뢰하는 경우가 대부분이며 이러한 난관을 헤치고 소프트웨어의 품

질 보증을 수행하려고 보면 국내 현실에 맞는 V&V와 테스팅 모델이 없어 또 다른 벽에 부

딪히게 된다.

따라서 국내 소프트웨어 산업계가 개발하는 소프트웨어의 품질 향상 도모를 위한 현실

적인 V&V와 테스팅 모델이 제시될 필요가 있으며 품질의 중요성에 대한 기업의 마인드

- 72 -

SPIC-20030728-2-PB-004

전환이 필요한 시점이다. 또한 국내 산업계의 문제들을 극복할 수 있는 실용적인 품질 평

가 시스템의 도입을 위한 연구가 이루어져야 하며 정부 차원에서 V&V와 테스팅 전문가를

양성하기 위한 노력을 기울여야 할 때이다.

- 73 -

SPIC-20030728-2-PB-004

참고문헌

[1] CMM: Capability Maturity Model for Software, V1.1, February, 1993.

[2] CMMI: Capability Maturity Model Integration for System Engineering, Software

Engineering, Integrated product and process Development, and Supplier Sourcing,

March, 2002.

[3] ISO/IEC TR 15504 Information Technology – Software Process Assessment,

International Organization for Standardization, International Electrotechnical

Commission, 1998.

[4] IEEE Standard for Software Verification and Validation, IEEE Std 1012-1998.

[5] ISO/IEC 12207 Information Technology – Software life cycle processes, 1995

ewha1

Documents

Transcript of ewha1