주제

정의 페이지 맨 위

변경 요청(CR) - 프로젝트 라이프사이클 전체에서 관련된 상태 정보와 함께 모든 스테이크홀더 요청(새 기능, 향상 요청, 결함, 변경된 요구사항 등)을 추적하는 데 사용되는 공식적으로 제출된 결과물입니다. 변경 날짜 및 이유와 함께 모든 상태 변경사항을 포함하여 모든 변경 이력은 변경 요청과 함께 유지보수됩니다. 이 정보는 모든 반복 검토 및 최종 종료에 사용 가능합니다.

변경(또는 형상) 제어 보드(CCB) - 고객, 개발자 및 사용자를 포함한 모든 이해 관계자의 대표로 구성되어 변경 프로세스를 감시하는 보드. 소규모 프로젝트에서 프로젝트 관리자 또는 소프트웨어 아키텍트와 같은 단일 팀 구성원이 이 역할을 담당할 수 있습니다. RUP(Rational Unified Process)에서는 변경 제어 관리자 역할로 표시됩니다.

CCB 검토 회의 - 이 회의의 기능은 제출된 변경 요청을 검토하는 것입니다. 이 회의에서 변경 요청 컨텐츠를 처음 검토하여 올바른 요청인지 판별합니다. 올바른 요청으로 판별되면 우선순위, 스케줄, 자원, 노력 레벨, 위험, 심각도 및 그룹에서 결정된 기타 관련 기준에 따라 변경이 현재 릴리즈 범위에 속하거나 범위에서 벗어나는지를 판별합니다. 일반적으로 이 회의는 일주일에 한 번 열립니다. 변경 요청 볼륨이 상당히 증가하거나 릴리즈 주기의 끝에 도달한 경우에는 회의가 매일 열릴 수도 있습니다. 일반적인 CCB 검토 회의 구성원은 테스트 관리자, 개발 관리자 및 영업부 구성원입니다. 구성원이 "필요"에 따라 추가 참가자가 필요하다고 생각할 수 있습니다.

변경 요청 제출 양식 - 변경 요청이 처음으로 제출될 때 이 양식이 표시됩니다. 제출자가 완료해야 할 필드만 양식에 표시됩니다.

변경 요청 결합 양식 - 이미 제출된 변경 요청을 검토 중일 때 이 양식이 표시됩니다. 변경 요청을 설명하는 데 필요한 모든 필드가 포함됩니다.

다음 변경 요청 프로세스 개요는 전체 프로세스를 통한 변경 요청의 상태 및 변경 요청 라이프사이클 동안의 통지 대상을 설명합니다.

변경 요청 관리에 대한 샘플 활동 페이지 맨 위

다음 예는 프로젝트가 라이프사이클 전체에서 변경 요청(CR)을 관리하기 위해 채택할 수 있는 샘플 활동을 표시하고 있습니다(설명을 보려면 다이어그램에서 항목을 누르십시오).

CR 닫힘 테스트 실패 릴리즈 빌드 중 변경사항 확인 CR 닫힘 중복 또는 거부 확인 제출됨 자세한 정보 CR 갱신 제출됨 거부 중복 확인됨 테스트 빌드 중 변경사항 확인 테스트 실패 변경사항 작성 해결됨 거부 중복 테스트 빌드 중 변경사항 확인 지정됨 작업 지정 및 스케줄 CR 제출 작업 지정 및 스케줄 열림 CR 검토 연기됨 제출됨 변경 요청 변경 제어 보드(CCB) CR 제출 위의 캡션에 설명된 다이어그램

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

활동 설명 책임
CR 제출 프로젝트의 모든 스테이크홀더는 변경 요청(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 또는 개발자 관리자가 즉시 주목해야 합니다. 이 시점에서 긴급 CCB 검토 회의를 소집하거나 단순하게 변경 요청을 즉시 해결 큐로 열도록 결정할 수 있습니다. 관리자

프로젝트 관리자

개발 관리자

QE 부서

지정됨 변경 요청 유형에 따라 작업을 지정하고 해당되는 경우 스케줄을 갱신하기 위해 미해결 변경 요청이 프로젝트 관리자의 책임이 됩니다. 프로젝트 관리자
해결됨 이 변경 요청 해결이 완료되어 확인할 준비가 되어 있음을 의미합니다. 제출자가 QE 부서의 구성원이면 자동으로 소유자가 제출한 QE 구성원으로 변경됩니다. 그렇지 않으면 수동 재지정을 위해 QE 관리자로 변경됩니다. 관리자

프로젝트 관리자

개발 관리자

QE 관리자

개발 부서

테스트 실패 테스트 빌드 또는 릴리즈 빌드에서 테스팅에 실패한 변경 요청이 이 상태에 놓입니다. 자동으로 소유자가 변경 요청을 해결한 팀 구성원으로 변경됩니다. 관리자

QE 부서

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

QE 부서

닫힘 더 이상 변경 요청에 주의를 기울이지 않아도 됩니다. 이 상태는 변경 요청이 지정될 수 있는 최종 상태입니다. CCB 검토 관리자만이 변경 요청을 닫을 수 있는 권한이 있습니다. 변경 요청이 닫히면 제출자는 변경 요청의 최종 배치가 포함된 전자 우편 통지를 받게 됩니다. 다음 경우에 변경 요청이 닫힐 수 있습니다. 1) 확인된 해결이 릴리즈 빌드에서 검증된 후 2) 거부 상태가 확인될 때 또는 3) 기존 변경 요청과 중복된 것으로 확인될 때입니다. 마지막 경우에 제출자는 중복 변경 요청에 대해 통지를 받고 나중에 통지를 받을 수 있도록 해당 변경 요청에 추가됩니다(자세한 정보는 "거부" 및 "중복" 상태 정의 참조). 제출자가 닫기에 이의를 제기하려면 변경 요청이 갱신되어야 하고 CCB 검토를 위해 다시 제출되어야 합니다. 관리자

상태 '태그'는 변경 요청 통계 보고(연령, 분포 또는 경향)에 대한 기초를 제공합니다.

아래 캡션에 설명된 다이어그램

CM 큐브 컨텍스트의 변경 요청 상태



Rational Unified Process   2003.06.15