중간 산출물: 비즈니스 분석 모델
비즈니스 분석 모델은 비즈니스 시스템, 비즈니스 작업자 및 비즈니스 엔티티의 상호작용을 통해 비즈니스 유스 케이스의 실현(realization)에 대해 설명합니다. 이 모델은 비즈니스 시스템, 비즈니스 작업자 및 비즈니스 엔티티의 연관 방식과 비즈니스 유스 케이스를 수행하기 위한 협업 방식을 추상적으로 나타냅니다. 이 모델은 또한 비즈니스 유스 케이스 수행 시 비즈니스 액터가 호출하는 외부 비즈니스 서비스를 정의합니다.
목적

비즈니스 분석 모델의 목적은 비즈니스 유스 케이스의 수행 방식을 설명하는 것입니다. 비즈니스 유스 케이스 모델은 비즈니스 액터와 비즈니스 간에 발생한 내용에 대해 설명하며 비즈니스 구조 또는 비즈니스 유스 케이스의 실현 방법에 대해서는 가정하지 않습니다. 반면에 비즈니스 분석 모델은 비즈니스에서 제공하는 서비스(비즈니스 유스 케이스 수행 시 비즈니스 액터가 호출)를 구체적으로 정의하고 내부 비즈니스 작업자와 해당 작업자가 사용하는 정보(비즈니스 엔티티)를 정의하며 독립 단위(비즈니스 시스템)로의 구조 조직에 대해 설명하고 비즈니스 유스 케이스에서 설명하는 동작을 실현하기 위한 상호작용 방법을 정의합니다.

비즈니스 분석 모델은 비즈니스 작업자 및 비즈니스 엔티티에 대한 디자인 선택사항을 작업자(사람) 또는 자동 시스템에 대한 역할 바인딩 관점에서 규정하지 않고 내부 구조 및 상호작용에 대해 설명합니다.  이는 비즈니스 디자인 모델의 목적입니다. 비즈니스 분석 모델은 자동화 및 리팩토링 옵션 탐색에 따라 이 모델로 발전됩니다.

비즈니스 분석 모델은 이해 당사자(stakeholder) 및 비즈니스 프로세스 분석가가 현재 비즈니스 수행 방식(현황(as-is) 양식)을 이해하고 비즈니스 변경사항에 따른 영향(목표(to-be) 양식)을 분석하는 데 사용됩니다. 비즈니스 프로세스 분석가는 모델의 구조 및 무결성을 담당하고 비즈니스 디자이너는 모델 요소를 세부화합니다. 이 모델은 또한 시스템 분석가가 자동 시스템, 즉 일반적으로 소프트웨어 집약적인 자동 비즈니스 작업자를 비즈니스 프로세스의 일부로 사용하는 방법을 기반으로 시스템 요구사항을 도출하는 데 사용됩니다. 소프트웨어 설계자는 이 모델을 사용하여 조직에 최적화된 소프트웨어 아키텍처를 정의하고 소프트웨어 분석 및 다지인 모델에서 클래스를 식별합니다.

관계
역할책임이 있음: 수정자:
입력 대상필수: 선택사항:
  • 없음
외부:
  • 없음
산출 지점
특성
선택사항
계획됨Yes
예시
사용자 조정
부재에 따른 영향

비즈니스 분석 모델은 비즈니스에서 비즈니스 기능을 수행하기 위한 내부 작업 방식에 대해 설명하므로 비즈니스 프로세스 또는 조직에 대한 변경사항(구조, 역할 및 책임)을 고려할 때 반드시 필요합니다. 이 모델을 사용하지 않는 경우 해당 변경사항에 대해 논리적으로 설명할 수 없습니다.

필요 없는 이유

비즈니스 모델링 노력의 목표가 단순히 비즈니스 유스 케이스를 통해 필요한 동작을 지정하거나 비즈니스 비전을 공식화하는 것인 경우에는 비즈니스 분석 모델이 필요하지 않습니다.

예를 들어, 해당 목표가 비즈니스 성능의 특정 측면을 개선하여 자동화 도입을 통해 비즈니스 구조 또는 비즈니스 프로세스를 변경하는 것인 경우 비즈니스 작업자에 대한 역할 바인딩(인적 자원, 소프트웨어, 시스템)을 선택하여 비즈니스 분석 모델을 비즈니스 디자인 모델로 발전시킬 수 있습니다.   

두 모델(비즈니스 분석 모델 및 비즈니스 디자인 모델)을 유지할지 여부를 판단하려면 여러가지 사항을 고려해야 합니다. 예를 들어, 비즈니스 분석 모델을 유지하고 활용하려면 비즈니스 디자인 모델을 함께 유지해야 하지만 이에 따른 비용이 높습니다. 비즈니스가 안정적인 경우에는 보다 추상적인 비즈니스 구조에 영향을 주지 않는 기술 결정사항을 보다 쉽게 재검토할 수 있다는 측면에서 비즈니스 분석 모델이 유용합니다. 구조적 또는 기능적으로 큰 변화가 있는 경우에는 비즈니스의 본질이 변화하고 새 비즈니스 분석 모델이 필요하므로 이 모델이 유용하지 않을 수 있습니다.

표시 옵션

UML 표시: 모델(<<비즈니스 분석>>으로 스테레오타입화됨)

비즈니스 분석 모델특성은 다음과 같습니다.

  • 소개: 모델에 대한 간략한 소개를 제공하는 텍스트 설명
  • 비즈니스 시스템: 계층 구조를 나타내는 모델의 컴포넌트*
  • 비즈니스 작업자: 비즈니스 시스템이 소유하는 모델의 비즈니스 작업자 클래스
  • 비즈니스 엔티티: 비즈니스 시스템이 소유하는 모델의 비즈니스 엔티티 클래스
  • 비즈니스 이벤트: 비즈니스 시스템이 소유하는 모델의 비즈니스 이벤트 클래스
  • 비즈니스 규칙: 모델에서 캡처한 비즈니스 규칙. 이 규칙은 별도 아티팩트의 문서 양식으로 캡처된 비즈니스 규칙이 아닙니다.
  • 관계: 비즈니스 시스템이 소유하는 모델의 관계
  • 비즈니스 유스 케이스 실현(realization): 비즈니스 시스템이 소유하는 모델의 비즈니스 유스 케이스 실현(realization)
  • 비즈니스 컨텍스트 협업: 비즈니스와 비즈니스 액터 간의 상호작용에 대한 외부 실현(realization)으로서, 최상위 레벨 비즈니스 시스템(즉, 비즈니스 자체)에서 제공하는 서비스, 이러한 서비스의 인터페이스, 비즈니스 액터 연결 및 비즈니스 엔티티 입력 및 산출물을 나타냅니다.
  • 다이어그램: 비즈니스 시스템이 소유하는 모델의 다이어그램

*비즈니스 자체는 최상위 레벨 컴포넌트(비즈니스 시스템)이므로 비즈니스 작업자, 비즈니스 엔티티 등을 직접 캡슐화할 수 있습니다.

비즈니스 분석 모델은 책임, 인도물 및 협업 동작 관점에서 비즈니스 프로세스를 표현합니다. 새 소프트웨어 시스템이 개발 또는 배치되는 경우 비즈니스 수행 방식에 대한 시스템 영향을 평가하기 위해 비즈니스 분석 모델을 반드시 작성해야 합니다. 새 소프트웨어 배치에 따른 조직 변경사항은 일반적으로 간과되어 비즈니스 유스 케이스에서 제외되지만 이러한 경우 결과적으로 작업 소프트웨어 시스템을 사용할 수 없게 됩니다.

비즈니스 분석 모델을 생성하지 않는다는 것은 소프트웨어 개발자가 비즈니스 수행 방식에 표면적으로만 주의를 기울이게 되는 위험성을 감수하게 됨을 의미합니다. 이러한 경우 개발자가 최선을 다하더라도 비즈니스 프로세스 정보가 없는 상태에서 소프트웨어를 디자인하고 작성하게 되며 결과적으로 비즈니스 요구를 지원하지 않는 소프트웨어 시스템이 빌드됩니다. 

비즈니스 분석 모델을 사용자 조정하기 위해 식별한 네 가지 기본 변형은 다음과 같습니다. 

또한 가이드라인: 대상 조직 평가를 참조하십시오. 

도메인 모델링

비즈니스 도메인에 중요한 "내용"과 제품에만 초점을 맞추고 "불완전한" 비즈니스 분석 모델을 개발할 수 있습니다. 이러한 모델에는 사람이 수행할 책임은 포함되지 않고 조직의 정보 컨텐츠에 대해서만 설명합니다. 이러한 모델을 도메인 모델이라고 합니다. 이러한 모델의 스테레오타입은 <<비즈니스 분석>>이 아닌 <<도메인 모델>>로 지정됩니다. 도메인 모델은 개념을 명시하고 정의하기 위한 공통 기반을 제공하는 데 매우 유용합니다. 자세한 정보는 개념: 도메인 디자인을 참조하십시오.

현황(As-Is) 및 목표(To-Be) 모델

비즈니스 모델링 노력의 목적이 비즈니스 (리)엔지니어링 수행인 경우 비즈니스 분석 모델의 두 가지 변형(현재 상황을 보여주는 모델 및 계획된 새 프로세스(대상 상황)를 보여주는 모델)의 빌드를 고려해야 합니다. 

비즈니스 분석 모델의 현재 버전은 단지 비즈니스 유스 케이스 실현(realization)의 인벤토리이며 비즈니스 분석 모델의 요소에 대해 세부적으로 설명하지 않습니다. 일반적으로 간략한 설명만으로도 충분합니다. 비즈니스 유스 케이스 실현(realization)은 비즈니스 분석 모델 요소를 스윔레인으로 표시하는 간단한 활동 다이어그램으로 문서화할 수 있습니다. 비즈니스 분석 모델의 대상 버전에는 대부분의 작업이 필요합니다. 현재 프로세스 및 구조를 다시 고려하여 비즈니스 전략 및 목적에 맞게 수정해야 합니다.

목표(To-Be) 모델

비즈니스 작성(예: 조직 또는 비즈니스의 새로운 분야)을 위해 비즈니스 모델링을 수행하는 경우 현황(as-is) 모델을 작성할 기존 비즈니스 프레임워크가 없습니다. 대상 모델의 작성에 필요한 참조 비즈니스 아키텍처 및 프로세스를 탐색해야 합니다.

비즈니스 분석 모델 제외

모든 이해 당사자(stakeholder)와 프로젝트 팀이 비즈니스 분석을 잘 이해하는 경우 비즈니스 분석 모델 개발에 따른 이점이 현저히 감소합니다. 이러한 경우 비즈니스 분석 모델을 모두 생략할 수도 있습니다. 그러나 일반적으로는 비즈니스 수행 방식에 대한 이해 당사자의 이해를 돕기 위해 적어도 최소 수준의 비즈니스 분석 모델을 개발해야 합니다. 

자세한 정보