타스크: 비즈니스 유스 케이스 분석(SOA)
이 타스크는 서비스 지향 솔루션의 디자인 요소를 서비스 및 파티션 관점에서 식별하고 해당 서비스의 초기 스펙을 문서화합니다.
목적
  • 서비스 지향 솔루션의 디자인 요소를 서비스 및 파티션 관점에서 식별합니다.
  • 초기 서비스 스펙을 문서화합니다.
  • 초기 종속성과, 서비스 간 통신을 결정합니다.
관계
기본 설명

이 타스크에서는 아티팩트: 비즈니스 유스 케이스 실현(realization)을 입력하고 프로젝트 서비스 포트폴리오에 포함된 후보 서비스 세트를 식별합니다. 이 후보 서비스에는 추가 정제가 필요하지만 여기에 포함된 단계에서는 아티팩트: 서비스 스펙의 초기 세트를 생성하는 효과적인 방법을 제공합니다.

단계
비즈니스 유스 케이스에서 후보 서비스 식별

보다 일반적인 컴포넌트 기반 및 객체 지향 솔루션을 개발하는 경우, 일반적으로 추상 레벨에 변환 세트가 존재하며 유스 케이스에서 시스템 디자인으로 세부사항 레벨을 추가합니다. 이는 특히 가이드라인: 비즈니스 모델에서 시스템으로 이동에서 설명하는 것처럼 비즈니스 유스 케이스를 시작점으로 사용하는 경우에 해당합니다. 이 가이드라인에서는 비즈니스 유스 케이스에서 시스템 유스 케이스로 이동하는 방법을 보여주며 이를 참조하여 실제 디자인 모델을 개발해야 합니다.

또한 다음과 같이 비즈니스 유스 케이스 모델에서 서비스 모델을 도출할 수 있는 방법을 정의하는 데 있어 시스템 유스 케이스로의 이동을 위해 제공된 가이드라인을 참조할 수 있습니다. 일반적인 접근 방식은 아티팩트: 비즈니스 분석 모델에 있는 아티팩트: 비즈니스 작업자에 설명된 각 오퍼레이션의 후보 서비스를 작성하는 것입니다. 프로세스 모델의 개별 타스크가 후보 서비스로서 식별되는 경우, 타스크: 비즈니스 프로세스 분석과 큰 차이가 있습니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

이처럼 비즈니스 분석 모델과 서비스 모델 간의 보다 직접적인 연결을 통해 비즈니스 요구를 지원할 수 있는 서비스뿐만 아니라 비즈니스 요구 표현과 솔루션 간의 변환을 줄여서 비즈니스 유스 케이스 또는 분석 모델의 변경사항에 보다 효과적으로 대응할 수 있습니다. 또 다른 중요 측면은 비즈니스 유스 케이스 모델에는 비즈니스를 이끄는 비즈니스 목적도 포함되므로 서비스와 목적 간 연관성을 실제로 보다 쉽게 식별할 수 있다는 것입니다. 예를 들어, 이제 서비스 스펙이 영향을 주는 모든 비즈니스 목적을 나열할 수 있습니다. 즉, 서비스와 서비스 스펙의 연결에 따라, 비즈니스 목적에 대해 IT 조직이 실제로 배치되고 해당 목적에 기여하는 서비스를 나열할 수 있습니다.

후보 서비스 스펙 정제

경우에 따라 비즈니스 유스 케이스 실현(realization)에 정의된 오퍼레이션 세트는 별개의 서비스 세트보다 단일 서비스와 관련된 관계자 간의 대화를 좀 더 정확하게 반영할 수 있습니다. 이와 같은 경우 오퍼레이션은 단일 서비스 스펙으로 집계 가능합니다(아래 표시 참조). 이러한 접근 방식의 철회란 이 접근 방식을 요구사항으로 식별하는 데 세부사항 분석, 유스 케이스 실현(realization)의 이해 및 작업자의 역할이 필요하다는 것입니다.

대화는 서비스의 실제 완료에 관계자 간의 많은 상호작용이 필요함을 의미합니다. 예를 들어, 'Place Order' 서비스를 점검하는 경우, 다음 다이어그램에서 보다시피 이 서비스가 승인, 배송 통지, 취소(예: 항목이 사용 불가능한 경우)를 포함한 복합적인 상호작용의 세트임을 알게 됩니다.


 

특성
선행
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보