결과물:
|
![]() |
변경 요청은 제품에 대한 변경 요청을 문서화하고 추적하는 데 사용됩니다. 판단 레코드를 제공하며 적절한 평가 프로세스를 거쳐 요청에 대한 변경 영향을 고려합니다. |
---|---|
역할: | 변경 제어 관리자 |
선택 가능성/발생 시기: | 필수사항. 필요할 때마다 여러 번 발생합니다. |
템플리트 및 보고서: |
|
예: |
|
UML 표시: | 해당사항 없음. |
자세한 정보: |
활동 정보: | 활동 결과: |
변경에 대한 필요성은 초기 작성 중에 서서히 대두되어 작동 환경의 매일 작업에서 계속 사용 및 유지보수되므로 소프트웨어 시스템 개발의 고유 속성입니다. 변경 요청은 또한 CR, 결함, 버그, 사건, 개선 요청 등과 같은 여러 가지 이름으로 알려져 있습니다. 이러한 요청을 적절하게 파악하고 관리하면 시스템이 제어된 방식으로 변경되어 시스템에서 해당 변경 결과를 예측할 수 있습니다. 변경 요청의 몇 가지 반입 유형에는 다음이 포함됩니다.
개선 요청은 여러 스테이크홀더가 자신이 원하는 장래 기능이 프로젝트에 포함되도록 요청하는 데 사용됩니다. 이것은 스테이크홀더 요구사항에 대한 정보를 파악하고 표현하는 스테이크홀더 요청 유형입니다.
결함은 인도된 작업 제품의 예외 및 실패에 대한 보고서입니다. 결함에는 초기 라이프사이클 단계 중에 발견된 누락 및 결함 또는 소프트웨어에서 분리 및 정정해야 하는 결함 증상과 같은 것이 포함됩니다. 또한 결함에는 마땅히 예상되는 소프트웨어 작동과 벗어나는 작동도 포함될 수 있습니다(예: 사용성 문제).
결함 목적은 문제의 세부사항을 전달하여 정정 조치, 해결책 및 추적을 수행하는 것입니다. 다음과 같은 사람들이 CR을 사용합니다.
프로젝트:
변경 요청 번호:
변경 요청 유형: (문제점 또는 개선사항)
제목:
제출한 날짜:
제안자:
변경 요청 우선순위:
현재 문제점 설명:
치명적 결함:
사소한 결함:
개선사항:
새 요구사항:
문제점이 관찰된 조건:
현재 환경: 하드웨어
운영 체제
컴파일러
현재 문제점 소스:
현재 문제점의 비용 또는 복구 효과:
제안된 변경 설명:
제안된 변경 구현에 드는 예상 비용:
조치:
승인:
거부:
연기:
제안된 변경 설명:
영향받는 형상 항목:
카테고리:
오류 수정사항:
개선사항:
새 기능:
기타:
제안된 변경 구현에 드는 예상 비용:
구현자:
변경 구현에 소요되는 실제 시간:
분석:
구현:
테스트:
문서:
영향받는 코드 행 수:
테스트 방법:
검사
분석
시연
테스트:
테스트 플랫폼:
테스트 케이스:
승인된 변경:
다음 속성은 제안된 CR에 대한 판별시 유용합니다.
변경 크기
- 변경해야 하는 기존 작업의 크기
- 추가해야 하는 새 작업의 크기
대안
- 존재 여부
복잡도
- 제안된 변경의 실행 난이도
- 변경 수행시 여러 가지 세부 가능성
심각도
- 요청 비구현시 결과
- 작업 또는 데이터 손실 여부
- 개선 요청 여부
- 사소한 결함 여부
스케줄
- 변경 필요 시기
- 실행 가능성
영향
- 변경 수행 결과
- 변경 미수행 결과
비용
- 변경 수행의 복구 비용
기타 변경과의 관계
- 기타 변경 대체 또는 무효화 또는 기타 변경에 종속 여부
테스트
- 변경 성공 여부를 검증하기 위해 수행해야 하는 특수 테스트 존재 여부
변경 관리 사례는 보통 프로젝트 라이프사이클 초기에 규정 및 설정됩니다. 변경 프로세스에 필수적인 CR은 프로젝트 과정 중 언제든지 제안할 수 있습니다.
주로 결함은 테스트(통합, 시스템 및 성능) 실행의 결과로부터 얻습니다. 그러나 결함은 소프트웨어 개발 중 언제든지 나타날 수 있고 누락되었거나 불완전한 유스 케이스, 테스트 케이스 또는 문서를 식별하는 것도 범위에 포함됩니다.
프로젝트 인력은 누구든지 변경 요청를 제기할 수 있어야 합니다. 그러나 소프트웨어 프로젝트 상황에 적절한 방식으로 연관된 해결 작업에 대해 검토 및 승인되어야 합니다. 대규모 팀이나 보다 형식적인 문화에서는 일반적으로 변경 요청을 제안하는 사람의 상급자가 승인을 수행합니다. 많은 경우 변경 요청의 최종 중재는 변경 제어 보드(CCB)와 같은 검토 팀에서 수행합니다.
변경 제어 관리자 역할은 다음 사항을 확인하여 변경 요청의 무결성을 책임집니다.
일반적으로 변경 제어 관리자 역할이 이러한 요청 관리를 책임지고 개선 요청의 경우에는 변경 제어 관리자이 시스템 분석가 및 아키텍트 역할과 공동으로 변경을 평가합니다.
결함을 정확히 식별하고 설명하며 추적하는 데 필요한 실제 필드 및 데이터는 다양하며 구현되는 표준, 가이드라인 및 변경 제어 시스템에 따라 달라집니다.
일반적으로 변경 요청을 쉽게 관리할 수 있도록 데이터베이스 또는 변경 요청 관리 시스템에 저장하는 것이 보다 효과적입니다(예: 우선순위, 지정 및 완료 상태별로 추적). 소형 프로젝트에서는 스프레드시트만으로도 충분할 수 있습니다.
소형 프로젝트에서는 변경 요청을 추적해야 하는 각 속성별로 별도의 열을 지정한 간단한 목록(예: 원하는 스프레드시트 사용)으로 결함을 관리할 수 있습니다. 이것은 소형 시스템인 경우에만 관리 가능하므로 관련된 사람 수와 결함 수가 늘어나면 보다 유용한 결함 추적 시스템을 사용해야 합니다.
Rational Unified Process
|