타스크: 변경 제어 프로세스 설정
이 타스크는 변경 제어 프로세스 작성 방법을 정의합니다.
원칙: 형상 및 변경 관리
목적

문서화된 표준 변경 제어 프로세스가 있으면 프로젝트 내에서 일관성 있게 변경이 이뤄지며, 해당 이해 당사자(stakeholder)에게 제품의 상태, 제품에 대한 변경사항 및 변경이 비용 및 스케줄에 미치는 영향을 알릴 수 있습니다.

관계
단계
변경 요청 프로세스 설정
목적: 변경 제어 프로시저는 제안된 시스템 변경사항이 일관된 제어 방식으로 평가되고 적용되도록 합니다. 
하위 단계
도구 사용 도움말
자세한 정보: 개념: 변경 요청 관리 

변경 요청 처리를 위한 일반적인 프로시저는 다음 활동 다이어그램에 표시되어 있습니다. 다이어그램의 아무 위치나 클릭하면 자세한 설명이 있는 개념: 변경 요청 관리로 이동합니다.

CR 관리에 대한 샘플 타스크 페이지 맨 위로

개념: 변경 요청 관리 제출자, CCB, 지정된 작업자 및 테스터 간의 CR 프로세스 플로우

변경 요청 양식 완료 페이지 맨 위로

변경 요청 양식은 새 기능, 개선사항 요청, 결함, 변경된 요구사항 등을 포함한 모든 요청을 추적하는 데 사용되는 공식적으로 제출된 아티팩트입니다. 여기에는 프로젝트 라이프사이클 전반에 걸친 관련 상태 정보가 포함되어야 합니다. 모든 변경 히스토리는 변경 날짜 및 이유와 함께 모든 상태 변경사항을 포함하며 CR로 유지보수됩니다. 이 정보는 반복 검토와 최종 완료에 사용할 수 있습니다. 변경 요청 양식 예제는 중간 산출물: 변경 요청을 참조하십시오.

변경 요청이 통과할 수 있는 일반적인 상태는 다음 상태 다이어그램에 표시되어 있습니다. 다이어그램의 아무 위치나 클릭하면 자세한 설명이 있는 개념: 변경 요청 관리로 이동합니다.

CR에 대한 샘플 상태 및 전이 페이지 맨 위로

개념: 변경 요청 관리 새 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

변경 제어 위원회 수립
목적 기준이 되는 형상 항목에 대한 모든 변경사항을 승인할 '변경 제어 위원회(CCB)'를 수립합니다. 이 팀은 제안된 모든 변경사항이 적절한 기술 분석과 검토를 받은 후 추적 및 감사를 위해 이들을 문서화하는 것을 목적으로 합니다.  
하위 단계

CCB는 정기적으로 그리고 필요한 경우에 모임을 소집합니다.

CCB의 기본 임무는 제품 기준선을 선언하고, 기준선 변경사항을 검토하며, 변경사항 구현을 승인, 거부, 지연하는 것입니다.

구성원 선택 페이지 맨 위로

이 단계의 목적은 동료들 중에서 실제 권한을 가지고 있으며 현명하지 못하거나 비용이 많이 드는 변경사항을 방지할 수 있는 전문 지식을 갖춘 '적임자'로 구성된 CCB를 수립하는 것입니다. CCB는 영향을 받는 모든 조직이나 이해 당사자(stakeholder)로부터 선출된 대표로 구성되어야 합니다. 예를 들면 다음과 같은 사람들로 구성되어야 합니다.

  • 사용자
  • 개발자
  • 테스트 그룹
  • 프로젝트 관리

CCB 회장 지명 페이지 맨 위로

CCB의 회장은 프로젝트 관리 사무실에서 선출해야 하며, 팀 내의 갈등을 명확하게 해결하고 프로젝트에 대한 팀 결정사항을 시행할 수 있어야 합니다.

CCB에서는 가능하면 항상 동의를 통해 결론을 도출해야 합니다. 개발 프로젝트의 협업적 특성이 그룹을 이끄는 원동력이 됩니다. 회장의 역할은 이러한 협업적 비전을 육성하고 필요한 경우 독자적인 조치를 취하는 것입니다.

변경 제안사항 평가를 위한 미팅 페이지 맨 위로

변경 제안사항을 검토하고 시기 적절한 방식으로 처리하기 위해 CCB는 정기적으로 그리고 필요한 경우에 모임을 가져야 합니다. 개발 팀에서는 이 그룹을 프로젝트 진행을 교착 상태에 빠뜨릴 수 있는 문제를 해결하는 신뢰할 수 있는 단체로 간주해야 합니다.

변경 검토 알림 프로토콜 정의
목적 변경 검토 알림 프로토콜의 목적은 변경 요청이 제출되었을 때 담당자에게 이를 알리기 위한 것입니다.
여러 가지 중간 산출물을 검토해야 할 담당자를 결정하십시오.  
도구 사용 도움말  Rational ClearQuest를 사용하여 변경 및 검토 알림 정의

이 단계에서는 프로젝트 진행 중에 개발될 중간 산출물의 목록을 제공해야 합니다.

구성원은 제품 관련 중간 산출물을 검토함으로써 이들이 정의된 프로젝트 품질 표준을 충족하여 다음 개발 단계로 전달될 수 있는지 여부를 결정해야 합니다. 제품이 검토 단계를 통과하지 못할 경우 재작업, 변경 또는 재검토 대상이 됩니다.

'효과적인' 검토를 위해서는 제안된 변경사항이나 개선사항의 범위와 영향을 이해하고 있는 적임자가 제품을 평가해야 합니다. 또한 주요 구현자와 통합자가 '미치는 영향이 미미한' 결함을 만드는 데 시간을 소모하지 않도록 검토를 '비용 효율적'으로 수행해야 합니다.

검토에 참여해야 하는 구성원은 '제품' 생산자, 수신자 및 관리 측에서 선출된 대표여야 합니다. 이는 제품 품질에 지대한 관심을 갖고 있는 모든 이해 당사자가 제품을 다음 개발 레벨로 이전할 수 있는지 여부를 결정할 수 있게 하기 위한 것입니다.

팀 환경에서 전체 프로젝트는 활동으로 세분화되며, 활동은 구현 및 통합 담당자에게 할당됩니다. 예를 들어, 전체 시스템은 하위 시스템으로 구분되고, 하위 시스템은 다시 개별 패키지로 구분됩니다. 패키지 구현을 담당하는 팀 구성원은 서브시스템 내에 있는 동료와 변경의 영향을 받을 수 있는 다른 서브시스템에 있는 다른 동료에게 패키지 변경사항을 검토하게 해야 합니다.

검토 및 변경 알림의 원칙은 동료, 팀 리더 및 제안된 변경사항의 수신인이 커뮤니케이션하고, 이들에게 제안 사항을 검토하고 이에 대한 의견을 제시할 수 있는 기회를 제공하는 것입니다.

이 주제에 대한 자세한 내용은 개념: 변경 요청 관리를 참조하십시오.


 

자세한 정보