목적
  • 주기 중에 발생한 승인된 변경사항(결함, 개선사항)을 제품 및 프로세스에 맞추어 조정하는 것입니다.
역할:  프로젝트 관리자 
빈도: 이 활동은 프로젝트 관리자가 권한 부여된 변경이 요구될 때마다 수행합니다. 
단계
입력 결과물:    결과 결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

주기 시작 시 준비된 주기 계획은 해당 시점에 알려진 내용으로부터 만 선택할 수 있습니다. 이것은 요구되는 전체 성능(기능적 및 비기능적 요구사항)에 대한 증분 및 이전 주기로부터 남겨진 변경 요청이 됩니다. 그런 후 프로젝트 관리자는 주기에 대한 자원 및 스케줄을 결정할 수 있습니다. 결함에 대한 허용이 결과물 생성에 할당된 노력으로써 암시적으로 또는 특정 작업 패키지에 명시적으로 주기 계획에 들어가야 합니다. 후자의 방법을 채택하는 것이 바람직합니다. Rational Unified Process에 이를 가능하게 하는 활동이 들어 있습니다.

변경 제어 관리자에 의해 수정 우선순위가 지정되더라도 프로젝트 관리자에게는 수정을 수행해야 하는 시기를 결정할 때 여전히 몇 가지 계획 재량권이 있습니다. 그러나 일반적으로 결함이 발견된 주기에 결함을 정정하는 시도가 행해져야 하며 주기 시작 시 계획한 자원으로 이를 수행할 수 있어야 합니다. 주기 종료 시점에 불가피하게 몇 가지 (발견된) 결함이 수정되지 않은 채 남겨질 수 있습니다(주기가 고정되어 있기 때문에). 그러나 성공으로 간주되는 주기의 경우 이들 다수가 기타 이유로 심각하지 않거나 낮은 우선순위로 지정되어 있습니다.

그러나 예기치 않게 발생하는 사소한 개선 요청을 제외한 다른 사항에 대해 허용을 만들지 않을 수 있습니다. 기본적인 개선사항에 대한 이러한 변경 요청이 현재 주기에 승인되어 있는 경우, 프로젝트 관리자는 몇 가지 계획된 성능을 다른 주기로 연기하거나 변경을 수행할 추가 자원을 찾아서 다시 계획해야 합니다. 보통 이러한 개선 요청은 다음 주기 또는 그 이후의 주기로 연기된 후 정규 주기 계획 사이클의 일부로 들어가게 됩니다.

주기에 변경 요청 할당맨 위 페이지

변경 요청이 조사되고 프로젝트 관리자는 해당 유형, 우선순위 및 심각도에 기초하여 수정해야 하는 주기를 결정합니다. 변경 요청이 나중 주기까지 연기되어야 하는 경우 프로젝트 관리자는 장래 주기를 간단히 재계획하여(소프트웨어 개발 계획에서) 나중에 원치 않는 뜻밖의 상황을 피하기 위해 변경 요청에 대한 영향을 바로 이해하고 가능한 빨리 자원 확보 활동을 시작할 수 있어야 합니다.

책임 지정맨 위 페이지

프로젝트 관리자는 변경 구현을 책임지는 조직의 위치를 결정합니다.

작업 및 예상 결과 설명 맨 위 페이지

변경 요청에는 이미 필요한 변경사항에 대한 개요에 설명이 들어 있습니다(변경 요청이 이미 분석 및 승인되었기 때문에). 이 단계에서는 해당 설명을 수행 완료되고 생성된 사항에 대한 분명한 문장으로 정제합니다.

노력 및 기타 자원 예산 맨 위 페이지

프로젝트 관리자는 변경 요청을 책임지는 개인과 상의하여 변경 요청의 노력 및 기타 자원 추정치를 확정된 계획 추정치(담당하는 개인이 확약할)로 정제합니다.

스케줄 설정 맨 위 페이지

변경 요청을 현재 주기에서 구현해야 하는 경우 프로젝트 관리자는 책임이 지정된 개인과 상의하여 작업의 시작 날짜와 예상 지속 기간을 설정합니다.

재계획맨 위 페이지

필요한 경우 현재 주기 계획을 수정하고 장래 주기에 미치는 영향을 소프트웨어 개발 계획에 반영시켜야 합니다. 재계획의 결과로서 프로젝트 관리자는 활동: 예외 및 문제점 처리를 호출하여 특히 자원 부족 또는 나중 주기로 계획된 성능 지연에 의해 현재 주기가 영향받는 경우 새 계획에 프로젝트 상태를 배열해야 합니다.

작업 명령 내리기 맨 위 페이지

수행할 작업, 스케줄, 책임 등을 정의하는 작업 명령은 프로젝트 관리자에 의해 내려집니다. 노력을 예산하는 작업 패키지(작업 명세 구조에서)는 작업 명령에서 식별됩니다.



Rational Unified Process   2003.06.15