목적
  • 현재 반복에서 분석될 시나리오 및 유스 케이스 세트 선택에 대한 입력을 정의합니다.
  • 몇몇 중요하고 기본적인 기능성을 나타내는 시나리오 및 유스 케이스 세트를 정의합니다.
  • 실질적인 구조적 범위(여러 구조 요소를 연습함)를 갖고 있거나 구조의 특정, 중복 지점을 강조하거나 보여주는 시나리오 및 유스 케이스 세트를 정의합니다.
 
역할:  소프트웨어 아키텍트 
빈도: 필요에 따라, 일반적으로 구현화 단계에서 시작하여 각 반복당 한 번.
단계  
자세한 정보: 
입력물:    결과물:   
툴 멘토르:   

워크플로우 세부사항:   

유스 케이스 및 시나리오 우선순위 결정 페이지 맨 위

소프트웨어 아키텍트는 분석 및 설계할 특정 수의 시나리오 및 유스 케이스를 선택하여 기술적인 내용 및 연속된 반복 순서를 제안합니다. 이 기술적 제안은 전달 가능 항목, 툴 및 COTS 제품의 사용 가능성, 기타 프로젝트 요구사항과 관련하여 개인별 사용 가능성, 고객 요구사항을 기본으로 여러 개발 팀에 의해 완료 및 정제됩니다.

유스 케이스 보기를 구성하는 시나리오 및 유스 케이스의 선택은 아래에 요약된 몇 가지 핵심 도출 요인에 의해 도출됩니다.

  • 스테이크홀더에 대한 시나리오의 장점: 심각, 중요, 유용.
  • 시나리오의 구조적 영향: 없음, 확장, 수정. 구조에 영향을 거의 영향을 미치지 않거나 적게 미치는 중요한 유스 케이스 및 큰 영향을 미치는 장점이 적은 유스 케이스가 있습니다. 많은 구조적 영향을 미치는 장점이 적은 유스 케이스는 범위를 줄일 수 있도록 프로젝트 관리자가 검토해야 합니다.
  • 위험 완화(성능, 제품의 사용 가능성 및 컴포넌트의 적합성).
  • 아키텍처 범위의 완성(구현화 단계의 끝에서 개발된 소프트웨어의 모든 부분이 구현 보기에서 홈을 찾았음을 확인하여).
  • 기타 전략적 목적 또는 제한사항: 일반 사용자에 대한 데모 등.

동일 컴포넌트를 사용하며 유사한 위험을 해결하는 두 개의 시나리오가 있을 수 있습니다. A를 먼저 구현할 경우에는 B가 구조적으로 중요하지 않습니다. B를 먼저 구현할 경우에는 A가 구조적으로 중요하지 않습니다. 이 속성은 반복 순서에 종속될 수 있으므로, 요구사항 자체가 변경되거나 순서가 변경되면 속성을 다시 평가해야 합니다.

이 도출 요인을 효율적으로 관리하기 위해서는 이를 요구사항의 속성으로 캡처해야 합니다.

이해하기 어렵거나 변경 가능성이 있는 구조적으로 중요한 유스 케이스를 명확히 하고 안정화시키려면 우선순위를 변경해야 합니다. 일부 경우, 이는 요구사항을 구현하기 전에 추가 요구사항 분석을 수행해야 함을 의미합니다. 다른 경우에는 몇몇 프로토타입 양식이 최선일 수 있습니다.

유스 케이스 보기 문서 페이지 맨 위

유스 케이스 보기는 소프트웨어 아키텍트 문서의 유스 케이스 보기 섹션에 문서화되어 있습니다. 이 절에는 유스 케이스 모델 내의 각 패키지에 있는 중요 유스 케이스 및 시나리오 목록과 함께 이벤트 플로우에 대한 설명, 관계, 유스 케이스 다이어그램 및 각 유스 케이스에 관련된 특수 요구사항과 같은 중요 특성이 포함되어 있습니다. 유스 케이스 보기가 반복 초기에 개발된 경우, 이 특성 중 일부가 아직 존재하지 않을 수 있음을 유념하십시오.

 

결과 평가 페이지 맨 위

작업에 올바른 방향으로 진행되고 있는지 확인하려면 이 단계에서 유스 케이스 보기를 확인해야 합니다. 그러나 유스 케이스 보기를 자세히 검토하지는 마십시오. 활동: 구조 검토에서 특히 유스 케이스에 대한 체크포인트를 참조하십시오.



Rational Unified Process   2003.06.15