 |
이 타스크는 구성 식별 사례, 기준선 작성 사례, 아카이브 사례, 구성 보고 요구사항이 포함된 CM 정책을 개발하는 방법을 설명합니다. |
원칙: 형상 및 변경 관리 |
|
목적
이 타스크의 목적은 프로젝트 형상 관리 정책을 구현하여 프로젝트 자산을 모니터하여 보호하고 소프트웨어 개발 사례를 적용하는 것입니다. 프로젝트 정책은 팀 구성원 사이의 통신을 원활하게 하고 작업 통합 시에 발생하는
문제점을 최소화할 수 있어야 합니다.
|
관계
역할 | 기본 수행자:
| 추가 수행자:
|
입력 | 필수:
| 선택사항:
|
출력 |
|
프로세스 사용법 |
|
단계
구성 식별 사례 정의
구성 식별은 형상 관리의 중심 요소로서 IEEE에 의해 "시스템용 형상 항목을 선택하고 이들 항목의 기능적 특성 및 물리적 특성을 기술 문서에 기록하는 작업으로 구성된 형상 관리의 요소"로 정의됩니다. 소프트웨어
형상 관리 측면에서 볼 때 구성 식별이란 올바른 버전의 프로젝트 중간 산출물을 쉽고 빠르게 찾아서 식별할 수 있는 기능을 말합니다. 구성 식별 시스템이 비효율적인 경우 시간과 품질면에서 손실이 발생할 수 있습니다.
레이블은 중간 산출물의 특정 버전을 식별합니다. 한 버전의 서브시스템을 구성하는 중간 산출물 세트는 특정 버전 및 레이블을 통해 집합적 또는 개별적으로 식별 가능합니다. 따라서 레이블은 버전이 있는 중간 산출물의
원래 세트를 재사용하거나 참조할 때 유용합니다.
다음은 제품 디렉토리 구조의 경로 및 중간 산출물에 레이블을 붙일 때 유용하게 사용할 수 있는 제품 레벨의 중간 산출물 레이블 지정 규칙에 대한 몇 가지
제안입니다.
<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]
<SYSTEM> 시스템을 식별합니다.
<A> 세 글자로 된 두문자어(TLA!)입니다. 시스템 작성에 사용된 다양한 유형의 중간 산출물에 사용됩니다. 예를 들면 다음과 같습니다.
PLN
|
프로젝트 계획
|
REQ
|
요구사항 파일
|
USC
|
유스 케이스
|
MOD
|
모델 파일
|
SRC
|
소스 코드 파일
|
INT
|
공용 인터페이스
|
TST
|
테스트 스크립트 및 결과
|
DOC
|
문서(사용자, 릴리스 정보)
|
BIN
|
실행 파일
|
<SUBSYSTEM> 서브시스템을 식별합니다.
<A> 서브시스템 작성에 사용된 다양한 유형의 중간 산출물을 나타내는 세 글자로 된 두문자어입니다. 위의 표를 따릅니다.
R|A|B
|
릴리스, 알파, 베타를 나타냅니다.
|
<X>
|
정수로, 주요 릴리스(예: 1)를 나타냅니다.
|
<Y>
|
정수(선택사항)로, 부차적 릴리스를 나타냅니다.
|
<Z>
|
정수(선택사항)로, 대체 릴리스(패치, 포트 등)를 나타냅니다.
|
BL
|
기본 레벨(내부 릴리스)을 나타냅니다.
|
#
|
정수로, 내부 릴리스를 나타냅니다.
|
다음은 몇 가지 예제입니다.
T2K_R1.0
|
Thorn 2000 시스템 릴리스 1
|
T2K_GUI_R2.0.BL5
|
릴리스 2에서 전달하기 위한 GUI 시스템의 내부 릴리스
|
T2K_B1.1
|
Thorn 2000 시스템 베타 릴리스 1.1
|
T2K_R2.0.BL16
|
릴리스 2를 작성하기 위한 Thorn 2000의 내부 시스템 기준 #16
|
T2K_R1.0.5
|
Thorn 2000의 유지보수 릴리스
|
|
기준선 사례 정의
기준선은 안정된 지점으로 프로젝트 중간 산출물의 스냅샷을 제공합니다. 개념: 기준선 작성에서는 프로젝트
라이프사이클 기준선 작성 시기에 대해 설명합니다. 이 단계에서는 사례에 대한 상세한 안내를 제공합니다.
기준선은 파일 및 디렉토리 버전의 고정된 세트를 식별하며 프로젝트 이정표의 특정 시점에서 작성됩니다. 서브시스템 또는 전체 시스템에 대해 기준선을 작성할 수 있습니다. 기준선은 앞의 프로세스 단계(중간 산출물
레이블 지정 규칙 정의)에서 설명한 구조에 따라 정의되어야 합니다.
기준선 작성 시에 다음 중 무엇을 작성할 것인지를 반드시 밝혀야 합니다.
-
서브시스템 내에서 수정된 파일 및 디렉토리의 모든 버전이 포함된 '서브시스템 기준선'
-
모든 서브시스템 내의 모든 파일 및 디렉토리의 단일 버전이 포함된 '시스템 기준선'
일반적인 가이드라인은 프로젝트 이정표 내의 주요 및 부차적인 시점에서는 시스템 기준선을 작성하고 이보다 더 자주 또는 필요 시에 서브시스템 기준선을 작성하면 쉽게 릴리스를 관리할 수 있다는 것입니다. 대략적으로
서브시스템에서 30%의 요소가 변경될 경우 기준선을 작성하는 것이 좋습니다.
|
아카이브 사례 정의
이 단계의 목적은 프로젝트 소프트웨어 및 관련 자산(마스터 문서)을 백업하고 카탈로그를 작성하여 지정된 저장영역 사이트에 전송하는 것입니다. 아카이브는 재사용 또는 재해 시에 값을 표시합니다. 따라서 이정표의 주요
및 부차적 시점에서, 그리고 정기적으로 아카이브를 수행해야 합니다.
아카이브 레이블을 작성할 경우 앞의 '중간 산출물 레이블 지정 규칙' 프로세스 단계에서 설명한 레이블 지정 가이드라인을 사용할 수 있습니다. 그러나 실제 매체를 저장해야 하는 경우에는 추가 정보가 필요할 수도
있습니다. 예제:
일련 번호
|
123456789
|
볼륨
|
1/3
|
저장실
|
B5
|
저장 날짜
|
99-06-21
|
모든 제품 관련 정보는 릴리스 및 재사용이 편리하도록 데이터베이스를 사용하여 유지보수해야 합니다.
|
형상 상태 보고 요구사항 정의
목적
|
변경 활동은 프로젝트 상태 및 동향을 확실하게 나타냅니다. 이 프로세스 단계의 목적은 프로젝트 관리자가 보고해야 할 제품 관련 변경 데이터, 보고자, 보고 빈도를 정의하는 것입니다.
|
하위 단계:
|
도구 사용 도움말:
|
형상 상태 보고가 사용된 경우, 여기서는 형상 상태 보고 작성에 사용할 수 있는 다양한 원본에 대해 설명합니다.
여기서는 프로젝트에 제출된 변경 요청에서 파생될 수 있는 보고서를 선택해야 합니다. 유용한 변경 요청 기본 보고서가 많이 있습니다.
'추이' 카테고리에서는 다음 기준에 따라 한 주 또는 한 달 동안의 변경 요청
수에 대한 보고를 요청할 수 있습니다.
상태별로 문제점을 열거하면 프로젝트 완료에 얼마나 근접했는지 파악하는 데 도움이 됩니다. 예를 들면, 대부분의 문제점이 해결된 경우 대부분의 문제점이 제출된 상태에 있는 경우보다 완료에 더 근접한 것입니다.
'분포' 카테고리에서는 다음 유형의 질문에 응답하기 위해 보고를 요청할 수 있습니다.
-
누가 프로젝트의 어떤 시점에서 어떤 유형의 결함을 찾고 있습니까?
-
문제가 누구에게 지정되었습니까?
-
지정된 엔지니어에 대해 얼마나 많은 문제점이 해결되지 않고 있습니까?
-
발견된 결함이 얼마나 심각합니까?
-
프로세스의 어떤 과정에서 문제점의 원인(근본 원인)이 발생하였습니까?
-
문제점 해결 시기는?
-
결함 수는?
-
결함이 얼마나 심각합니까?
이 메트릭은 워크로드, 가장 심각한 문제점을 처리하고 있는 사람, 문제 해결 속도를 분석하는 데 도움이 됩니다.
'동향' 카테고리에서는 다음 유형의 질문에 응답하기 위해 보고를 요청할 수 있습니다.
-
오늘, 이번 주 또는 이번 달에 발생한 결함은 몇 개입니까?
-
오늘, 이번 주 또는 이번 달에 해결된 결함은 몇 개입니까?
이 데이터는 복구 비율을 평가하는 데 유용하며 엔지니어링 효율성에 대한 지표가 될 수 있습니다.
의사 결정에 유용한 참조 자료가 되려면 보고서를 적절한 빈도로 제공해야 합니다. 다음과 같은 빈도로 보고서를 요청할 수 있습니다.
-
매일 - 이렇게 자주 보고서를 요청할 필요는 없을 것입니다.
-
매주 - 동향, 분포 및 계수 보고서, 빌드 보고서
-
매월 - 동향, 분포 및 계수 보고서, 빌드 보고서
-
반복할 때마다 - 동향, 분포 및 계수 보고서, 빌드 보고서, 버전 설명
-
단계별 - 동향, 분포 및 계수 보고서, 감사, 빌드 보고서, 버전 설명
-
프로젝트 종료 시 - 동향, 분포 및 계수 보고서, 감사, 빌드 보고서, 버전 설명
|
|
자세한 정보
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|