활동:
|
목적
|
역할: 소프트웨어 아키텍트 |
빈도: 필요에 따라, 일반적으로 구현화 단계에서 시작하여 각 반복당 한 번. |
단계 |
입력물: | 결과물: |
툴 멘토르: |
워크플로우 세부사항: |
소프트웨어 아키텍트는 분석 및 설계할 특정 수의 시나리오 및 유스 케이스를 선택하여 기술적인 내용 및 연속된 반복 순서를 제안합니다. 이 기술적 제안은 전달 가능 항목, 툴 및 COTS 제품의 사용 가능성, 기타 프로젝트 요구사항과 관련하여 개인별 사용 가능성, 고객 요구사항을 기본으로 여러 개발 팀에 의해 완료 및 정제됩니다.
유스 케이스 보기를 구성하는 시나리오 및 유스 케이스의 선택은 아래에 요약된 몇 가지 핵심 도출 요인에 의해 도출됩니다.
동일 컴포넌트를 사용하며 유사한 위험을 해결하는 두 개의 시나리오가 있을 수 있습니다. A를 먼저 구현할 경우에는 B가 구조적으로 중요하지 않습니다. B를 먼저 구현할 경우에는 A가 구조적으로 중요하지 않습니다. 이 속성은 반복 순서에 종속될 수 있으므로, 요구사항 자체가 변경되거나 순서가 변경되면 속성을 다시 평가해야 합니다.
이 도출 요인을 효율적으로 관리하기 위해서는 이를 요구사항의 속성으로 캡처해야 합니다.
이해하기 어렵거나 변경 가능성이 있는 구조적으로 중요한 유스 케이스를 명확히 하고 안정화시키려면 우선순위를 변경해야 합니다.
일부 경우, 이는 요구사항을 구현하기 전에 추가 요구사항 분석을 수행해야 함을 의미합니다.
다른 경우에는 몇몇 프로토타입 양식이 최선일 수 있습니다.
유스 케이스 보기는 소프트웨어 아키텍트 문서의 유스 케이스 보기 섹션에 문서화되어 있습니다. 이 절에는 유스 케이스 모델 내의 각 패키지에 있는 중요 유스 케이스 및 시나리오 목록과 함께 이벤트 플로우에 대한 설명, 관계, 유스 케이스 다이어그램 및 각 유스 케이스에 관련된 특수 요구사항과 같은 중요 특성이 포함되어 있습니다. 유스 케이스 보기가 반복 초기에 개발된 경우, 이 특성 중 일부가 아직 존재하지 않을 수 있음을 유념하십시오.
작업에 올바른 방향으로 진행되고 있는지 확인하려면 이 단계에서 유스 케이스 보기를 확인해야 합니다. 그러나 유스 케이스 보기를 자세히 검토하지는 마십시오. 활동: 구조 검토에서 특히 유스 케이스에 대한 체크포인트를 참조하십시오.
Rational Unified Process
|