중간 산출물 (아티팩트): 변경 요청
이러한 아티팩트는 제품에 대한 변경 요청을 문서화하고 추적하는 데 사용됩니다. 결정 레코드가 제공되며 적절한 평가 프로세스를 거쳐 요청에 대한 변경 영향을 고려합니다.
목적
  • 변경 및 결함 공식화 및 추적
설명
기본 설명

변경 필요성은 초기 작성 중에 서서히 대두되며 작동 환경의 매일 작업에서 계속 사용 및 유지보수되므로 소프트웨어 시스템 개발의 고유 속성입니다. 변경 요청에서는 결정 레코드를 제공하며 적절한 평가 프로세스를 거쳐 요청에 대한 변경 영향을 고려합니다.

 변경 요청은 CR, 결함, 버그, 사건(incident), 향상 요청과 같이 다양한 이름으로도 알려져 있습니다. 이러한 요청을 적절하게 파악하고 관리하면 시스템이 제어된 방식으로 변경되어 시스템에서 해당 변경 결과를 예측할 수 있습니다. 변경 요청의 일부 가져오기 유형에는 다음이 포함됩니다.

향상 요청은 여러 이해 당사자(stakeholder)가 제품에 포함시킬 기능을 요청하는 데 사용됩니다. 이러한 요청은 이해 당사자 요구사항에 대한 정보를 파악하고 표현하는 이해 당사자(stakeholder) 요청 유형입니다.

결함은 전달된 중간 산출물의 비정상적 작동 및 장애에 대한 보고서입니다. 결함에는 초기 라이프사이클 단계 중에 발견된 누락 및 결함 또는 소프트웨어에서 분리 및 정정해야 하는 결함(장애) 증상과 같은 것이 포함됩니다. 또한 결함에는 마땅히 예상되는 소프트웨어 작동과 벗어나는 작동도 포함될 수 있습니다(예: 사용성 문제).

결함의 목적은 문제의 세부사항을 커뮤니케이션하여 정정 조치, 해결책 및 추적을 수행하는 것입니다. 다음과 같은 사람들이 CR을 사용합니다.

  • 역할 세트: 분석가는 CR를 사용하여 상위 레벨 요구사항에 대한 주요 변경사항을 정의하고 향상 요청으로 식별된 CR의 요구사항을 판별합니다.
  • 역할 세트: 관리자는 CR를 사용하여 작업 지정을 관리하고 제어합니다
  • 역할 세트: 테스터는 CR를 사용하여 소프트웨어 테스트 중에 발견된 실패(결함), 누락 및 품질 문제에 대해 설명합니다.
  • 역할 세트: 개발자는 결함 CR를 사용하여 실패를 분석하고 내재된 결함 또는 실패의 원인을 찾아서 CR를 해결합니다.
  • 역할: 테스트 분석가는 CR를 사용하여 해결된 CR를 확인하는 테스트를 계획하고 결함 세트 분석을 통해 테스트 노력을 평가하여 소프트웨어 및 소프트웨어 엔지니어링 프로세스의 품질 상태동향을 판단합니다.
간략한 아웃라인

샘플 변경 요청 양식

  1. 식별

  • 프로젝트:
  • 변경 요청 번호:
  • 변경 요청 유형: (문제점 또는 개선사항)
  • 제목:
  • 제출한 날짜:
  • 제안자:
  • 변경 요청 우선순위:
  1. 현재 문제점

  • 현재 문제점 설명:
  • 주요 실패:
  • 불편사항:
  • 개선사항:
  • 새 요구사항:
  • 문제점이 관찰된 조건:
  • 현재 환경: 하드웨어
  • 운영 체제 컴파일러:
  • 현재 문제점 소스:
  • 현재 문제점의 손실 또는 절감 효과:
  1. 제안된 변경(제안자)

  • 제안된 변경 설명:
  • 제안된 변경 구현의 예상 비용:
  1. 제안된 변경(변경 검토 팀)

  • 조치:
  • 승인됨:
  • 거부됨:
  • 연기됨:
  • 제안된 변경 설명:
  • 영향받는 형상 항목:
  • 카테고리:
  • 오류 수정사항:
  • 개선사항:
  • 새 기능:
  • 기타:

  1. 해결책

  • 제안된 변경 구현의 예상 비용:
  • 구현자:
  • 변경 구현에 소요되는 실제 시간:
  • 분석:
  • 구현:
  • 테스트:
  • 문서:
  • 영향받는 코드 행 수:
  1. 평가

  • 테스트 방법
  • 검수
  • 분석
  • 시연
  • 테스트
  • 테스트 플랫폼
  • 테스트 케이스
  1. 변경 검토 팀 배치

  • 승인되어 적용된 변경
특성
선택사항
계획됨Yes
사용자 조정
표시 옵션

결함을 정확히 식별하고 설명하며 추적하는 데 필요한 실제 필드 및 데이터는 다양하며 구현되는 표준, 가이드라인 및 변경 제어 시스템에 따라 달라집니다.

일반적으로 변경 요청은 손쉬운 관리(예: 우선순위별 정렬, 지정 및 완료 상태 추적 등)를 위해 데이터베이스 또는 변경 요청 관리 시스템에 저장하는 것이 좋습니다. 소규모 프로젝트에서는 스프레드시트만으로도 충분할 수 있습니다.

소규모 프로젝트에서는 결함을 단순한 목록으로 관리할 수 있습니다. 또한 변경 요청의 각 속성에 대한 별도의 열이 있는 스프레드시트를 사용할 수도 있습니다. 이것은 소규모 시스템에서만 관리할 수 있습니다. 관련된 사람 수와 결함 수가 적절한 수준 이상으로 늘어나면 더 융통성 있는 결함 추적 시스템을 사용해야 합니다.



자세한 정보