목적: 변경 제어 프로시저는 제안된 시스템 변경사항이 일관된 제어 방식으로 평가되고 적용되도록 합니다.
|
하위 단계
|
도구 사용 도움말
|
자세한 정보: 개념: 변경 요청 관리
|
변경 요청 처리를 위한 일반적인 프로시저는 다음 활동 다이어그램에 표시되어 있습니다. 다이어그램의 아무 위치나 클릭하면 자세한 설명이 있는 개념: 변경 요청 관리로 이동합니다.
변경 요청 양식은 새 기능, 개선사항 요청, 결함, 변경된 요구사항 등을 포함한 모든 요청을 추적하는 데 사용되는 공식적으로 제출된 아티팩트입니다. 여기에는 프로젝트 라이프사이클 전반에 걸친 관련 상태 정보가
포함되어야 합니다. 모든 변경 히스토리는 변경 날짜 및 이유와 함께 모든 상태 변경사항을 포함하며 CR로 유지보수됩니다. 이 정보는 반복 검토와 최종 완료에 사용할 수 있습니다. 변경 요청 양식 예제는 중간 산출물: 변경 요청을 참조하십시오.
변경 요청이 통과할 수 있는 일반적인 상태는 다음 상태 다이어그램에 표시되어 있습니다. 다이어그램의 아무 위치나 클릭하면 자세한 설명이 있는 개념: 변경 요청
관리로 이동합니다.
변경 요청이 제출되면 분석 과정을 통해 해당 변경 요청이 실제로 타당한지, 유효성 평가를 위해 담당 기술자와 관리자가가 해당 변경 요청을 검토해야 하는지 확인합니다. 변경 요청은 개발 팀 내의 다양한 레벨에서
검토해야 합니다. 팀 리더는 대개 팀원이 제출한 변경 요청을 검토하고 승인합니다. 그러나 변경 범위가 팀 권한 밖일 경우 변경 요청이 검토를 위해 다음 레벨로 넘어갑니다. 변경이 다른 여러 개발 팀에도 영향을
미치게 될 경우에는 변경 제어 위원회에서 변경 요청을 검토합니다. RUP(Rational Unified Process)에서 변경 제어 관리자 역할은 변경 제어 위원회(CCB)의 역할을 나타내는 데 사용됩니다.
때로 시스템 구현과 관련된 것보다는 사용법으로 인해 발생한 시스템 오작동이 보고되기도 합니다. '문제점'이 이미 보고되어 해결 중인 경우도 여기에 해당합니다.
분석 단계에서 현재 프로젝트 비전이나 지침에 따라 변경 요청이 올바르지 않거나, 중복되거나, '범위를 벗어났다'는지 판단하여 승인 또는 거부할 수 있습니다.
변경이 올바를 경우, 다음 단계는 변경이 전체 시스템에 미치는 영향과 변경을 얼마나 쉽게 구현할 수 있는지를 기준으로 변경을 평가하고 변경 비용을 산정하는 것입니다.
비용 책정 단계에서 제공한 정보가 평가를 위해 CCB에 제공됩니다. CCB에서는 변경 요청과 변경 요청이 미치는 영향을 전략적, 조직적 및 기술적 관점에서 검토한 후 변경 요청을 경제적으로 정당화할 수 있는지
여부를 결정해야 합니다.
변경 요청이 승인된 후에는 변경 요청을 소프트웨어에 적용할 수 있습니다. 수정된 소프트웨어는 프로젝트에서 채택한 사례에 따라 변경이 이루어졌는지 그리고 변경이 기존 소프트웨어의 다른 부분에 나쁜 영향을 미치지
않는지 확인하기 위해 품질 보증 검사를 거칩니다.
변경이 이뤄진 후에는 제품의 테스트 빌드에서 새 소프트웨어 버전이 확인된 후 전체 소프트웨어의 '릴리스' 버전으로 통합되고 확인됩니다.
소프트웨어를 변경할 경우 모든 변경사항에 대한 레코드를 유지보수하는 것이 중요합니다.
변경 히스토리는 각 소프트웨어 컴포넌트의 시작 부분과 변경 요청 내에 유지보수하는 것이 가정 효과적입니다.
컴포넌트 헤더에서 유지보수할 변경 데이터의 종류에 대한 예는 다음과 같습니다.
수정 히스토리
버전 수정자 날짜 변경 이유
1.1 Bruce Bogtrotter 98.05.01 테스트 범위 CR#232
1.2 Maria Mussolini 98.06.02 요구사항 CR#454
|