개념: 변경 요청 관리
변경 요청 관리는 변경 관련 사건(incident)의 영향을 최소화하기 위해 표준화된 방법과 프로시저를 효율적으로 사용하여 모든 변경사항을 효율적이고 신속하게 처리되도록 하는 프로세스입니다.
관계
기본 설명

정의

변경 요청(CR) - 프로젝트 라이프사이클 중 발생하는 새 기능, 개선사항 요청, 결함, 변경된 요구사항 및 관련 상태 정보를 포함한 모든 이해 당사자(stakeholder) 요청을 추적하는 데 사용되는, 공식적으로 제출되는 중간 산출물. 모든 변경 히스토리는 모든 상태 변경사항을 포함하여 변경 날짜 및 이유와 함께 변경 요청(CR)으로 유지보수됩니다. 이 정보는 반복 검토와 최종 완료에 사용할 수 있습니다.

변경(또는 형상) 제어 위원회(CCB) - 고객, 개발자 및 사용자를 포함하여 모든 이해 관계자(interested party)들의 대표로 구성되는 변경 프로세스 감시 위원회. 소규모 프로젝트에서는 프로젝트 관리자나 소프트웨어 설계자와 같은 단일 팀 구성원이 이 역할을 수행할 수 있습니다. Rational Unified Process에서는 변경 제어 관리자 역할로 표시됩니다.

CCB 검토 회의 - 이 회의의 기능은 제출된 변경 요청을 검토하는 것입니다. 올바른 요청인지 판별하기 위해 변경 요청 컨텐츠의 초기 검토가 회의에서 수행됩니다. 올바른 요청이면 그룹에서 판별한 우선순위, 스케줄, 자원, 노력 레벨, 위험성, 심각도 및 기타 관련 기준을 기반으로 변경이 현재 릴리스의 범위 안에 있는지 여부를 판별합니다. 이 회의는 일반적으로 1주일마다 한 번 열립니다. 변경 요청 볼륨이 상당히 커지거나 릴리스 주기의 끝이 가까워 옴에 따라, 매일처럼 자주 회의를 열 수 있습니다. CCB 검토 회의의 일반적 구성원은 테스트 관리자, 개발 관리자 및 마케팅 부서 구성원입니다. "필요에 따라" 추가 구성원이 참석해야 할 수도 있습니다.

변경 요청 제출 양식 - 이 양식은 처음 변경 요청을 제출할 때 표시됩니다. 제출자가 채워야 하는 필드만 양식에 표시됩니다.

변경 요청 결합 양식 - 이 양식은 이미 제출된 변경 요청을 검토할 때 표시됩니다. 변경 요청을 설명하는 데 필요한 모든 필드가 들어 있습니다.

다음에 설명되는 변경 요청 프로세스의 개요는 전체 프로세스에서의 변경 요청 상태와 변경 요청 라이프사이클 동안 알려야 하는 사람을 설명합니다. 변경 요청과 연관되는 일반적인 프로세스는  타스크: 변경 제어 프로세스 설정을 참조하십시오.

변경 요청의 관리에 대한 샘플 타스크

다음 예제는 프로젝트가 라이프사이클 동안 변경 요청(CR)을 관리하기 위해 채택할 수 있는 샘플 타스크를 보여줍니다(설명을 보려면 다이어그램에서 해당 항목 클릭).

CR 닫힘 테스트 실패 릴리스 빌드의 변경 확인 CR 닫힘 중복 또는 거부 확인 제출됨 자세한 정보 CR 갱신 제출됨 거부 중복 확인됨 테스트 빌드의 변경 확인 테스트 실패 변경 작성 해결됨 거부 중복 테스트 빌드의 변경 확인 지정됨 작업 지정 및 스케줄 CR 제출 작업 지정 및 스케줄 열림 CR 검토 연기됨 제출됨 변경 요청 변경 제어 위원회 CR 제출 함께 표시된 텍스트에서 설명되는 다이어그램

변경 요청 관리(CRM) 프로세스 타스크 설명 샘플:

타스크 설명 책임
CR 제출 프로젝트의 이해 당사자(stakeholder)가 변경 요청(CR)을 제출할 수 있습니다. 변경 요청은 변경 요청 추적 시스템(예: Rational ClearQuest)에 로그되며 CCB 검토 대기열에 놓입니다(변경 요청 상태가 제출됨으로 설정됨). 제출자
CR 검토 이 타스크의 기능은 제출된 변경 요청을 검토하는 것입니다. 올바른 요청인지 판별하기 위해 변경 요청 컨텐츠의 초기 검토가 CCB 검토 회의에서 수행됩니다. 올바른 요청이면 그룹에서 판별한 우선순위, 스케줄, 자원, 노력 레벨, 위험성, 심각도 및 기타 관련 기준을 기반으로 변경이 현재 릴리스의 범위 안에 있는지 여부를 판별합니다. CCB
중복 또는 거부 확인 변경 요청이 중복되거나 올바르지 않은 요청(예: 운영자 오류, 재생 불가능, 작동 방법 등)으로 거부될 것으로 의심이 갈 경우, CCB 위임이 지정되어 중복 또는 거부된 변경 요청을 확인하고 필요에 따라 제출자로부터 자세한 정보를 수집합니다. CCB 위임
CR 갱신 변경 요청을 평가하기 위해 자세한 정보가 필요하거나(자세한 정보) 프로세스 내의 임의 지점에서 변경 요청이 거부될 경우(예: 중복, 거부 등으로 확인됨), 제출자에게 알려지고 제출자는 새 정보로 변경 요청을 갱신할 수 있습니다. 갱신된 변경 요청이 새 데이터의 고려를 위해 CCB 검토 대기열에 다시 제출됩니다. 제출자
작업 지정 및 스케줄 변경 요청이 열리면, 프로젝트 관리자가 요청 유형(예: 개선사항 요청, 결함, 문서 변경, 테스트 결함 등)에 따라 적절한 팀 구성원에 작업을 지정합니다. 그리고 프로젝트 스케줄에 대해 필요한 갱신을 수행합니다. 프로젝트 관리자
변경 작성 지정된 팀 구성원은 요구사항, 분석 및 디자인, 구현, 사용자 지원 자료 생성 및 디자인 테스트와 같은 적절한 프로세스 섹션 내에 정의된 타스크 세트를 수행하여 요청한 변경을 수행합니다. 이 타스크에는 정상적인 개발 프로세스 내에 설명된 모든 정상적인 검토와 유닛 테스트 타스크가 포함됩니다. 그런 다음 변경 요청은 해결됨으로 표시됩니다. 배정된 팀 구성원
테스트 빌드의 변경 확인 배정된 팀 구성원(분석가, 개발자, 테스터, 전문 기술 작성자 등)이 변경사항을 해결하고 나면, 변경사항은 테스터에 배정되도록 테스트 대기열에 놓이고 제품의 테스트 빌드에서 확인됩니다. 테스터
릴리스 빌드의 변경 확인 해결된 변경사항이 제품의 테스트 빌드에서 확인되고 나면, 변경 요청은 제품의 릴리스 빌드에 대해 확인되도록 릴리스 대기열에 놓이고, 릴리스 노트 등을 생성한 후 변경 요청을 닫습니다. CCB 위임(시스템 통합자)

변경 요청의 상태 및 전이 샘플

다음의 다이어그램 예제는 변경 요청(CR) 라이프사이클 동안의 샘플 상태 및 알려야 하는 사람을 보여줍니다(설명을 보려면 다이어그램에서 해당 항목 클릭).

CCB 검토 회의 자세한 정보 자세한 정보 CR 갱신 CR 갱신 중복 또는 거부 확인 릴리스 빌드의 변경 확인 닫힘 자세한 정보 확인됨 중복 거부 CCB 검토 회의 CR 제출 제출됨 테스트 실패 테스트 빌드의 변경 확인 해결됨 변경 작성 열림 작업 지정 및 스케줄 지정됨 연기됨 변경 요청 함께 표시된 텍스트에서 설명되는 다이어그램

변경 요청 관리(CRM) 상태 설명 샘플:

상태 정의 액세스 제어
제출됨 이 상태는 1) 새 변경 요청 제출, 2) 기존 변경 요청의 갱신 또는 3) 새 릴리스 주기에 대해 연기된 변경 요청의 고려 결과로 발생합니다. 변경 요청은 CCB 검토 대기열에 놓입니다. 이 조치의 결과로 소유자 지정은 발생하지 않습니다. 모든 사용자
연기됨 변경 요청이 올바르지만 현재 릴리스에 대해 "범위 밖"으로 판별되었습니다. 연기됨 상태의 변경 요청은 보류되고 차후 릴리스에서 다시 고려됩니다. 목표 릴리스를 지정함으로써 변경 요청이 제출되어 다시 CCB 검토 대기열에 들어갈 수 있는 시간 프레임을 표시할 수 있습니다. 운영자

프로젝트 관리자

중복 이 상태의 변경 요청은 이미 제출된 다른 변경 요청과 중복되는 것으로 간주됩니다. 변경 요청은 CCB 검토 운영자나 해결을 위해 배정된 팀 구성원에 의해 이 상태에 놓입니다. 변경 요청이 중복 상태가 되면 중복되는 변경 요청 번호가 기록됩니다(ClearQuest의 첨부 탭). 제출자는 변경 요청이 제출되기 전에 초기에 변경 요청 데이터베이스에서 중복 여부를 조회해야 합니다. 그러면 검토 프로세스의 몇몇 단계를 건너뛰어 많은 시간을 절약하게 됩니다. 중복되는 변경 요청의 제출자는 해결에 관한 이후 알림을 받도록 원래 변경 요청의 알림 목록에 추가되어야 합니다. 운영자

프로젝트 관리자

QE 관리자

개발

거부 이 상태의 변경 요청은 CCB 검토 회의에서 또는 배정된 팀 구성원에 의해 올바르지 않은 요청이거나 제출자의 자세한 정보가 필요하다고 판별됩니다. 이미 지정된 경우(열림), 변경 요청은 분석 대기열에서 제거되고 재검토됩니다. CCB의 지정된 권한이 확인을 위해 지정됩니다. 필요하다고 생각(변경 요청 상태가 자세한 정보로 변경됨)되지 않는 한 제출자의 조치가 필요하지 않습니다. 변경 요청은 CCB 검토 회의에서 새 정보를 고려하여 재검토됩니다. 올바르지 않은 것으로 확인되면, 변경 요청은 CCB에 의해 닫히고 제출자에게 알려집니다. 운영자

프로젝트 관리자

개발 관리자

테스트 관리자

자세한 정보 거부 또는 중복 변경 요청의 유효성을 확인하기에는 데이터가 부족합니다. 소유자는 자동으로 자세한 데이터를 제공하라는 알림을 받는 제출자로 변경됩니다. 운영자
열림 이 상태의 변경 요청은 현재 릴리스의 "범위 내"에 있는 것으로 판별되었으며 분석을 기다립니다. 다가오는 목표 이정표 전에 분석하도록 예정되어 있습니다. 이와 같은 변경 요청은 "지정 대기열"에 있는 것으로 정의됩니다. 회의 구성원만 변경 요청을 분석 대기열에 넣어 열 수 있는 권한을 가지고 있습니다. 우선순위가 2 이상인 변경 요청이 발견되면, QE 또는 개발 관리자 즉시 그 변경 요청에 주의를 기울여야 합니다. 이 시점에서 QE 또는 개발 관리자는 긴급 CCB 검토 회의를 소집하거나 단순히 변경 요청을 임시로 분석 대기열에 넣어 열 것을 결정할 수 있습니다. 운영자

프로젝트 관리자

개발 관리자

QE 부서

지정됨 열림 상태의 변경 요청은 프로젝트 관리자가 변경 요청의 유형에 따라 작업을 지정하고 적절하게 스케줄을 갱신해야 합니다. 프로젝트 관리자
해결됨 이 변경 요청의 분석이 완료되어 이제 확인 준비가 되었음을 의미합니다. 제출자가 QE 부서의 구성원인 경우, 소유자는 자동으로 제출하는 QE 구성원으로 변경됩니다. 그렇지 않으면 수동 재지정을 수행할 QE 관리자로 변경됩니다. 운영자

프로젝트 관리자

개발 관리자

QE 관리자

개발 부서

테스트 실패 테스트 빌드나 릴리스 빌드에서 테스트에 실패하는 변경 요청은 이 상태가 됩니다. 소유자는 자동으로 변경 요청을 분석한 팀 구성원으로 변경됩니다. 운영자

QE 부서

확인됨 이 상태의 변경 요청은 테스트 빌드에서 확인되어 릴리스에 포함될 준비가 되어 있습니다. 운영자

QE 부서

닫힘 더 이상 변경 요청에 주의하지 않아도 됩니다. 이 상태는 지정할 수 있는 변경 요청의 최종 상태입니다. CCB 검토 운영자만 변경 요청을 닫을 수 있는 권한을 가지고 있습니다. 변경 요청이 닫히면(C), 제출자는 변경 요청의 최종 처리에 대한 전자 우편 알림을 수신합니다. 변경 요청은 1) 확인된 분석이 릴리스 빌드에서 유효성이 검증된 후에 2) 거부 상태가 확인된 경우 또는 3) 기존 변경 요청의 중복으로 확인된 경우에 닫힙니다. 마지막의 경우, 제출자가 중복 변경 요청에 대한 알림을 받고 차후 알림을 위해 해당 변경 요청에 추가됩니다(세부사항은 상태 "거부" 및 "중복"의 정의 참조). 제출자가 닫는 것에 이의를 제기할 경우, CCB 검토를 위해 변경 요청을 갱신하고 다시 제출해야 합니다. 운영자

상태 '태그'는 보고하는 변경 요청(추이 분석, 분포 또는 상태동향) 통계의 기초를 제공합니다.

다이어그램은 아래의 캡션에 설명되어 있습니다.

CM Cube 컨텍스트에서의 변경 요청 상태