목적
  • 요구사항의 결과가 시스템에 대한 고객의 관점에 적합한지를 공식적으로 확인합니다.
역할:  기술 검토자 
빈도: 필요에 따라, 일반적으로 초기 단계에서 시작하여 각 반복당 여러 번.
단계
자세한 정보: 
입력물:    결과물:   
툴 강좌:   

워크플로우 세부사항:   

일반 권장사항 페이지 맨 위

목적 각 검토에 대한 일반 권장사항.

다음 가이드라인이 요구사항 결과를 검토할 때 도움이 됩니다.

  • 회의 참석자가 혼자서 검토를 준비할 수도 있지만 항상 회의 형식으로 검토를 실시합니다.
  • 가능한 한 제품 품질을 높이기 위해 생성된 것을 지속적으로 확인합니다. 이 목적으로 체크포인트가 제공됩니다. 각 분석 활동의 체크포인트를 참조하십시오. 비공식 검토 회의 또는 일별 작업에 이를 사용할 수 있습니다.

비즈니스 또는 기술 도메인에 대한 약간의 필수 지식과, 적용된 촉진 및 모델링 기법에 대해 자세한 지식을가진 역할이 검토 회의에 참여합니다.

단계의 시작 또는 종료와 같은 이정표에서는 다음과 같은 역할이 검토 회의에 참석하는 것으로 간주해야 합니다.

원하는 검토 참석자를 포함시키는 것과 검토를 관리하기 쉽고 생산적으로 유지하는 것 사이에 적당한 균형 지점을 찾아내는 것이 중요합니다. 검토 목적을 달성하는 데 기여할 참석자만 포함시키도록 주의해야 합니다. 다수가 관련된 한 번의 검토 회의를 개최하는 것보다는 소수의 참석자가 참여하는 다방면에 초점을 둔 검토 세션이 일반적으로 보다 생산적입니다.

권장 검토 회의 페이지 맨 위

목적 검토 범위 및 목표를 정의합니다.
각 특정 범위/목표 조합에 사용되는 방법을 정의합니다.  

일반적으로 검토를 다음과 같은 회의로 나누어야 합니다.

동일한 회의에서 모든 내용을 검토할 수 있지만 처음에 결론을 승인받지 못할 수 있습니다. 유스 케이스 모델의 새로운 각 버전에 대해 새로운 검토를 수행하도록 준비하십시오.

초기구현 단계에서 반복당 하나의 유스 케이스 모델 검토를 계획하도록 권장합니다. 이 때 진행 중인 작업을 검토합니다. 이 작업은 초기에 수행되며 유스 케이스를 자세히 개발하기 전에 사용자가 종료합니다. 또한 올바르지 않은 유스 케이스를 개발하는 데 자원을 낭비하지 않게 하는 매우 중요한 이정표입니다. 그런 다음, 구현 단계의 끝에 자세한 유스 케이스 모델 검토를 계획해야 합니다. 구현 단계의 끝에는 유스 케이스 모델 및 80% 정도 완료된 용어집을 나타내는 도메인 모델도 있어야 함을 유념하십시오. 유스 케이스 모델을 정제할 때마다 구축전이 단계에서 반복당 한 번 유스 케이스 모델 검토 계획을 세워야 합니다. 반복을 위해 개발 중인 유스 케이스 모델 부분을 집중적으로 검토해야 합니다.

검토 기록 및 결함 문서 준비 페이지 맨 위

목적 검토 결과를 문서화합니다.
식별된 결함이 문서화되었는지 확인합니다.  

각 검토 회의 이후, 회의 결과는 검토 기록에 문서화됩니다. 또한 모든 결함은 프로젝트의 변경 관리 프로세스에 따라 문서화됩니다.

자세히 읽기 페이지 맨 위

참조: [BIT03] 제 11장.



Rational Unified Process   2003.06.15