개념: 라이프사이클 아키텍처 이정표
이 가이드라인은 정제(Elaboration) 단계(Phase)의 끝에서 라이프사이클 아키텍처 이정표에 대한 평가 기준에 대해 설명합니다. 중요한 아티팩트의 상태도 설명합니다.
기본 설명

정제(Elaboration) 단계의 끝에는 두 번째 중요 프로젝트 이정표인 라이프사이클 아키텍처 이정표가 있습니다. 이 시점에서 자세한 시스템 목표 및 범위, 아키텍처 선택사항 및 주요 위험성의 분석을 점검합니다.

평가 기준

  • 제품 비전 및 요구사항이 안정적입니다.
  • 아키텍처가 안정적입니다.
  • 테스트 및 평가에 사용할 주요 접근 방식이 증명됩니다.
  • 실행 가능 프로토타입의 테스트 및 평가는 주요 위험성 요소가 처리되고 확실하게 해결되었음을 보여주었습니다.
  • 구현/구축(Construction) 단계의 반복 계획은 충분히 세부적이고 충실하여 작업을 진행할 수 있도록 허용합니다.
  • 구현/구축 단계의 반복 계획은 신뢰할 수 있는 예상으로 지원됩니다.
  • 모든 이해 당사자(stakeholder)는 현재 아키텍처 상황에서 전체 시스템을 개발하는 데 현재 계획을 실행할 경우 현재 비전에 만족할 수 있다는 데 합의합니다.
  • 계획된 소비에 비해 실제 자원 소비가 허용 가능합니다.

이 이정표에 도달하는 데 실패할 경우 프로젝트가 중단되거나 다시 생각해야 할 수도 있습니다.

아티팩트

중요한 아티팩트(중요성 순서대로) 이정표에서의 상태
프로토타입 중요한 기능과 구조적으로 중요한 시나리오를 탐색하기 위해 하나 이상의 실행 가능 아키텍처 프로토타입이 작성되었습니다. 프로토타입 생성의 역할에 대해서는 아래에 있는 노트를 참조하십시오.
위험성 목록 갱신되고 검토되었습니다. 새 위험성은 사실상 아키텍처 위험성이 되므로, 기본적으로 비기능적 요구사항의 처리에 관련됩니다.
개발 프로세스

프로젝트 가이드라인 및 템플리트를 포함하여, 개발 프로세스가 프로젝트 경험을 기반으로 정제되었으므로, 진행할 구현/구축(Construction) 단계에 대해 효율적으로 정의됩니다.

개발 하부 구조

프로세스에 대한 모든 도구 및 자동화 지원을 포함하여 생성에 대한 개발 환경이 자리 잡혔습니다.

소프트웨어 아키텍처 문서 아키텍처 측면에서 의미있는 유스 케이스에 대한 자세한 설명(유스 케이스 보기), 주요 메커니즘 및 디자인 요소 식별(논리 보기), 그리고 시스템이 배치되거나 동시성 문제로 다뤄야 할 경우 프로세스 보기 및 배치 보기(중간 산출물: 배치 모델)의 정의를 포함하여, 이 문서가 작성되고 기준선에 맞춰졌습니다.
디자인 모델(및 모든 구성 아티팩트) 정의되고 기준선에 맞춰졌습니다. 아키텍처 측면에서 의미있는 시나리오에 대한 디자인 유스 케이스 실현이 정의되고 필수 동작이 적절한 디바인 요소에 할당되었습니다. 컴포넌트가 식별되었고 확신을 가지고 구현/구축(Construction) 단계 비용 및 스케줄을 판별할 수 있을 만큼 제조/구입/재사용 결정을 충분히 이해했습니다. 선택된 아키텍처 컴포넌트는 통합되어 기본 시나리오에 대해 평가를 받습니다. 이와 같은 활동에서 얻은 교훈으로 아키텍처를 다시 디자인하여 요구사항의 대체 디자인이나 재의를 고려할 수 있습니다.
데이터 모델 정의되고 기준선에 맞춰졌습니다. 주요 데이터 모델 요소(예: 중요한 엔티티, 관계, 테이블)가 정의되고 검토되었습니다.
구현 모델(및 구현 요소를 포함하는 모든 구성 아티팩트) 초기 구조가 작성되고 주요 컴포넌트가 프로토타입 생성되었습니다.
비전 단계에서 확보된 새 정보를 기반으로 정제되고, 아키텍처 및 계획 디자인을 파생하는 가장 핵심 유스 케이스에 대한 확실한 이해가 확립됩니다.
소프트웨어 개발 계획 구현/구축(Construction) 및 전이(Transition) 단계를 다루도록 갱신 및 확장되었습니다.
반복 계획 구현/구축 단계에 대한 반복 계획이 완료되고 검토되었습니다.
유스 케이스 모델(액터, 유스 케이스) 유스 케이스 모델(약 80% 완료) - 수반하는 모든 유스 케이스가 유스 케이스 모델 조사에서 식별되고, 수반하는 모든 액터가 식별되며 대부분의 유스 케이스 설명(요구사항 캡처)이 개발되었습니다.
보충 스펙 비기능적 요구사항을 캡처하는 보충 요구사항이 문서화되고 검토되었습니다.
테스트 스위트("스모크 테스트") 정제(Elaboration) 단계에서 작성된 각 실행 가능 릴리스의 빌드 안정성을 확인하기 위해 테스트가 구현되고 실행되었습니다.
 테스트 자동화 아키텍처 기준선에 맞춰진 다양한 메커니즘 및 주요 소프트웨어 요소 컴포지션으로, 테스트 자동화 소프트웨어 시스템의 근본적인 특성을 구체화합니다.
선택적 아티팩트 이정표에서의 상태
비즈니스 사례 아키텍처 조사에서 근본적인 프로젝트 가정을 변경하는 문제를 다루지 않을 경우 갱신되었습니다.
분석 모델 정규 아티팩트로 개발될 수도 있습니다. 종종 공식적으로 유지보수되지 않아서 대신 디자인 모델의 초기 버전으로 전개됩니다.
 사용자 지원 자료 사용자 매뉴얼 및 기타 훈련 자료. 유스 케이스를 기반으로 하는 예비적 초안. 시스템에 강한 사용자 인터페이스 측면이 있는 경우에 필요할 수 있습니다.

프로토타입 생성의 역할

Rational Unified Process는 소프트웨어 설계자 및 프로젝트 관리자에게 위험성 감소 전략으로 몇 가지 유형의 프로토타입을 자유롭게 생성할 수 있는 권한을 부여합니다(개념: 프로토타입 참조). 이 프로토타입 중 일부는 순수하게 탐색 프로토타입일 수 있으므로 나중에 버려집니다. 그러나 아키텍처는 일련의 발전적 프로토타입으로 구성되므로(정제가 진행됨에 따른 다른 문제를 포함함) 정제의 마지막에는 통합된 안정적인 아키텍처 기본이 될 것입니다. 그렇다고 해서 정제 중 프로토타입 생성 노력의 결과로 통합하지 않아도 되는 아키텍처 단편 세트를 생성해야 한다는 의미는 아닙니다.