비즈니스 분석 모델은 비즈니스 시스템 및 비즈니스 작업자의 내부 관점에서 비즈니스 유스 케이스의 실현(realization)을 정의합니다. 모델은 비즈니스 작업을 수행하는 사용자 및 시스템과 이들이 처리하고
사용하는 대상을 서로 연관시켜 원하는 결과를 정적/동적으로 생성하는 방법을 정의합니다. 또한 비즈니스 영역에서 수행되는 역할과 해당 중요 책임을 강조합니다. 모델은 모든 비즈니스 유스 케이스를
실현(realize)하는 데 필요한 모든 협업과, 오브젝트가 인스턴스화되어 해당 역할을 바인드(이행)하는 모든 클래스를 표시합니다.
비즈니스 분석 모델의 핵심 요소는 다음과 같습니다.
-
비즈니스 시스템은 대규모 비즈니스 모델을 상호 종속적인 책임 영역으로 분할합니다. 비즈니스 시스템은 해당 자원을 캡슐화하여, 잘 정의된
인터페이스를 통해 다른 비즈니스 파트에 서비스를 제공합니다.
-
비즈니스 작업자는 비즈니스의 활성 단위입니다. 비즈니스 분석 모델에서는 사람 또는 소프트웨어나 사람, 하드웨어 및 소프트웨어를 포함하는 시스템의
추상까지도 나타냅니다. 이 시스템은 비즈니스 시스템과 달리, 비즈니스 분석 또는 비즈니스 디자인 모델에서 더 이상 분해되지 않습니다. 해당 책임은 비즈니스 분석 모델에 정의됩니다.
-
비즈니스 엔티티는 사용 또는 생성되는 중요한 정보, 인도물 및 자원을 나타냅니다.
-
비즈니스 이벤트는 잠재적으로 다른 비즈니스 프로세스를 트리거하는 일일 비즈니스 작업에서 발생하는 중요한 이벤트를 나타냅니다.
-
비즈니스 규칙은 비즈니스 프로세스를 실행할 때 충족시켜야 하는 정책 또는 조건에 대한 선언문입니다.
-
비즈니스 유스 케이스 실현(realization)은 비즈니스 시스템, 비즈니스 작업자, 비즈니스 엔티티 및 비즈니스 이벤트에서 비즈니스 유스
케이스를 수행하기 위해 협업하는 방법을 보여줍니다. 비즈니스 유스 케이스 실현(realization)은 다음 다이어그램을 참조하십시오.
-
클래스 다이어그램: 참여 비즈니스 시스템, 비즈니스 작업자 및 비즈니스 엔티티를 보여줍니다.
-
활동 다이어그램: 스윔레인은 비즈니스 시스템 또는 비즈니스 작업자의 책임을 나타내고 오브젝트 플로우는 워크플로우에서 비즈니스 엔티티를
사용하는 방법을 보여줍니다.
-
시퀀스 다이어그램 : 비즈니스 유스 케이스를 수행할 때 비즈니스 시스템, 비즈니스 작업자 및 비즈니스 액터 간의 세부 상호작용과, 비즈니스
엔티티를 평가하는 방법을 나타냅니다.
비즈니스 분석 모델은 구조와 동작의 개념을 함께 나타냅니다. 비즈니스 유스 케이스 실현(realization)은 원하는 동작을 지정하는 프로세스 설명(비즈니스 유스 케이스)을 조직 내 구조 요소에 맵핑합니다(아래
글머리표 다음 그림 참조).
다음은 비즈니스 분석 모델의 일부 특성입니다.
-
순수 비즈니스 컨텐츠를 계속 보유하면서 소프트웨어 개발자가 잘 알고 있는 방식으로 비즈니스 관심사항을 나타내는 연결 아티팩트입니다. 또한 오브젝트, 속성 및 책임으로 표현되는 비즈니스 관심사항의 영역에 대해
알고 있는 통합 정보입니다.
-
비즈니스 문제에 대한 생각을 소프트웨어 응용프로그램에 대한 생각으로 전이하는 방식으로 비즈니스 영역의 핵심 지식을 탐색합니다.
-
빌드될 정보 시스템에서 지원 또는 사용할 요구사항을 이러한 방법으로 확정합니다.
-
비즈니스 오브젝트 정의, 오브젝트 간 관계와, 오브젝트 간 관계 및 오브젝트에 대한 이름에 동의하는 프로세스를 사용하여 비즈니스 영역 전문가가 이해하고 해당 유효성을 검증할 수 있는 정확한 방식으로 비즈니스
영역 지식을 나타낼 수 있습니다.
일반적으로 비즈니스 시스템, 비즈니스 작업자, 비즈니스 엔티티 및 비즈니스 이벤트에는 다른 이름과 유사하지 않고 고유한 간단하면서도 설명적인 이름을 지정해야 합니다. 경우에 따라, 특히 미래를 대비하기 위해 보다
광범위한 컨텍스트를 고려할 때 모델 요소의 목적을 설명하고 인식 가능하면서도 고유한 이름을 지정하기 위해 여러 단어를 사용해야 하는 경우도 있습니다.
비즈니스 시스템은 특정 목적을 가진 관련 책임 콜렉션을 제공하며 이름을 지정할 때 해당 목적을 반영해야 합니다. 비즈니스 시스템에는 일반적인 이름 또는 문구(예: 클라이언트 서비스)를 사용할 수도 있지만 해당
용어가 반드시 시스템과 관련이 있고 설명적인 이름이어야 합니다. 일반적으로는 비즈니스 시스템의 목적(예: 고객 관리 또는 대상 인식)에서 참조할 수 있도록 동명사 형태의 동사(예: Shipping,
Invoicing 또는 Selling)를 사용하는 것이 가장 적합합니다. 자세한 정보는 가이드라인: 비즈니스
시스템을 참조하십시오.
비즈니스 작업자에는 해당 책임을 표현하는 이름을 지정해야 합니다. 휴먼 비즈니스 작업자의 경우 기능이 아닌 유스 케이스 실현(realization)에서 비즈니스 작업자가 수행하는 역할에 대해 설명해야 합니다. 이
역할에는 비즈니스 유스 케이스 실현(realization)에서 비즈니스 작업자의 목적이 반영되어야 합니다. 자세한 정보는 가이드라인: 비즈니스
작업자를 참조하십시오.
예를 들어, 특정 비즈니스 작업자가 시스템에 데이터를 입력한 후 두 번째 작업자에 대한 확인 및 데이터 처리 승인이 완료될 때까지 해당 데이터를 보존하는 프로세스를 가정할 수 있습니다(예: 은행 대부
응용프로그램). 데이터를 입력하는 비즈니스 작업자의 이름은 데이터 타이피스트 또는 데이터 입력 직원으로 지정하고 두 번째 비즈니스 작업자의 이름은 확인자, 권한 부여자 또는 릴리스 수행자로 지정할 수 있습니다.
데이터 입력 직원은 실제 사람 이름처럼 들리는 단점이 있고 다른 세 가지 이름은 특정 단계에서 보다 자세히 규정해야 하는 경우도 있습니다. 예를 들어, 은행이 보험 중개 정책을 새로 시작하는 경우 담보 대출
담당자로 지정해야 합니다.
비즈니스 엔티티에는 엔티티가 나타내는 정보를 반영하여 이름을 지정해야 합니다. 일반적으로 정의와 관계는 다른 개념이므로 비즈니스 엔티티는 항상 비즈니스 용어집에 정의해야 합니다. 또한 비즈니스 엔티티 이름에는 해당
상태 또는 특성을 포함해서는 안됩니다. 비즈니스 엔티티 이름은 복수가 아닌 단수 형태를 사용해야 합니다. 자세한 정보는 가이드라인: 비즈니스
엔티티를 참조하십시오.
비즈니스 이벤트에는 이벤트 발생 또는 이벤트가 나타내는 상태 변경을 반영하여 이름을 지정해야 합니다. 또한 이름에서 이벤트 트리거 또는 이벤트 반응에 대해 설명해서는 안됩니다. 이벤트 스펙은 해당 트리거와
다릅니다. 자세한 정보는 가이드라인: 비즈니스
이벤트를 참조하십시오.
서로 다른 비즈니스 유스 케이스에 참여하는 비즈니스 작업자와 비즈니스 엔티티에 대한 학습 과정에서 작업자와 엔티티가 너무나 유사하여 실제로 하나의 클래스인 경우를 여러 번 발견할 수 있습니다. 이러한 클래스는
비즈니스 유스 케이스마다 해당 요구가 다른 경우라도 동일한 단일 현상으로 간주할 수 있을 정도로 유사할 수 있습니다. 이러한 경우에는 유사한 클래스를 단일 클래스로 병합하며 결과적으로, 서로 다른 비즈니스 유스
케이스의 모든 요구를 충족시킬 수 있는 충분한 관계, 속성 및 오퍼레이션을 가진 비즈니스 작업자 또는 비즈니스 엔티티가 생성됩니다. 위의 "설명" 섹션 끝 부분에 있는 다이어그램은 비즈니스 작업자와 비즈니스
엔티티가 서로 다른 비즈니스 유스 케이스 실현(realization)에 참여하는 방법을 보여줍니다.
따라서 여러 비즈니스 유스 케이스에서 동일한 단일 클래스에 대해 아주 다른 요구를 할 수 있습니다. 비즈니스 작업자의 경우, 직원이 설명된 역할 세트의 역할을 수행할 수 있는 경우 해당 직원은 또한 여러 위치에서
작업을 수행할 수 있게 되며 결과적으로 보다 유연한 비즈니스 환경이 제공됩니다.
비즈니스 분석 모델에서 비즈니스 작업자는 비즈니스의 활성 단위가 수행할 역할을 나타내는 반면 비즈니스 엔티티는 해당 활성 단위가 처리할 대상을 나타냅니다. 비즈니스 분석 모델을 사용하면 비즈니스 작업자(상위 레벨의
경우 비즈니스 시스템)가 비즈니스 액터에 대해 원하는 결과를 생성하기 위해 상호작용하는 방법을 정의할 수 있습니다. 비즈니스 작업자가 소프트웨어 시스템의 추상을 나타낸다는 사실은 위에서 설명했습니다.
비즈니스 모델링 컨텍스트를 벗어나는 경우에는 시스템 유스 케이스 모델과 디자인 모델을 사용하여 해당 소프트웨어 시스템을 지정합니다.
비즈니스 모델링과 소프트웨어 모델링은 두 가지 다른 추상 레벨의 다른 문제점 도메인을 처리합니다. 따라서 일반적으로 이 차이점을 고려하여, 소프트웨어 모델링 세부사항이 비즈니스 모델에 영향을 주지 않도록
해야 하며 비즈니스 작업자의 비즈니스 목적에 초점을 맞춰야 합니다.
비즈니스 작업자의 상호작용 및 특성, 특히 작업자(사람)가 수행하는 역할을 '현황(as-is)' 모델에서 점검하는 경우, 자동화 기회를 모색할 때와 같이 비즈니스 이벤트의 발생 및 이용, 비즈니스 엔티티에 대해
수행된 오퍼레이션, 비즈니스 모델링 컨텍스트와 시스템 모델링 컨텍스트 간의 특정 관계 방법을 이용할 수 있습니다. 비즈니스 모델의 링크, 연관 및 속성으로 다음과 같은 자동화 기회를 제안할 수 있습니다.
-
특정 비즈니스 작업자 역할을 수행하는 직원은 정보 시스템의 시스템 액터에 해당합니다. 이 직원은 일반적으로 비즈니스 유스 케이스에서 자신의 모든 작업을 단일 시스템 유스 케이스에서 지원하도록 정보 시스템이
구성될 때 가장 효과적으로 지원됩니다.
-
또는 비즈니스 유스 케이스의 규모가 크거나 수명이 길거나 여러 독립 영역의 작업을 통합하는 경우, 특정 정보 시스템 유스 케이스에서 대신 비즈니스 작업자의 단일 오퍼레이션을 지원할 수 있습니다.
-
비즈니스 작업자가 처리하는 작업은 비즈니스 엔티티로 모델링되며 일반적으로 정보 시스템에 표시됩니다. 정보 시스템의 오브젝트 모델에서는 이러한 비즈니스 엔티티가 엔티티 클래스로 표시됩니다.
-
비즈니스 이벤트의 경우 일반적으로 서비스 지향 아키텍처 소프트웨어 시스템에서는 메시지로 구현되고 워크플로우 자동화 시스템에서는 타스크로 구현됩니다.
-
비즈니스 엔티티 간의 연관과 집계로 인해 종종 디자인 모델의 엔티티 클래스 간 해당 연관 및 집계가 생성됩니다.
-
따라서 정보 시스템 유스 케이스는 지원되는 비즈니스 유스 케이스에서 액세스하는 비즈니스 엔티티를 나타내는 디자인 모델의 엔티티 클래스를 액세스하고 처리합니다.
-
비즈니스 정보 시스템을 직접 사용하는 비즈니스 액터는 또한 시스템 모델링 컨텍스트에서는 정보 시스템의 시스템 액터가 됩니다.
이 관계는 정보 시스템이 비즈니스를 지원하기 위한 요구사항을 식별할 때 유용합니다.
가이드라인: 비즈니스 모델에서 시스템으로 이동에서 자동 비즈니스 작업자에 대한 섹션을 참조하십시오.
때때로 첫 번째 비즈니스에서 한 비즈니스의 직원이 정보 시스템을 사용하여 다른 비즈니스의 직원과 접속할 수 있습니다. 모델링된 비즈니스 관점에서 볼 때 해당 정보 시스템은 비즈니스 액터가 됩니다.
예제:
소프트웨어 개발자가 자신이 개발하는 제품의 문제점을 파악하기 위해 노력하고 있습니다. 이 개발자는 해당 문제점이 자신이 사용하는 프로그래밍 도구로 인한 것인지 여부를 확인하기 위해 공급자의 월드 와이드 웹(WWW)
서버에 접속하여 해당 프로그래밍 도구의 현재 릴리스에서 알려진 문제점의 목록을 확인합니다. 비즈니스 작업자 소프트웨어 개발자는 이러한 방식으로 비즈니스 액터 공급자 WWW 서버와 상호작용합니다.
비즈니스 작업자의 비즈니스 엔티티 처리 방법을 모델링할 때, 일반적으로 컴퓨터 기반의 특정 도구를 사용하여 비즈니스 엔티티에 대해 여러 오퍼레이션을 수행하게 됩니다. 이 시스템을 정보 시스템 또는 기타 시스템으로
명시적으로 모델링하여 비즈니스 작업자가 표시하는지 여부는 비즈니스에서의 해당 중요성에 따라 결정됩니다. 예를 들어, 일반적으로는 워드 프로세스와 스프레드시트 기능이 있는 단순 데스크탑 시스템을 비즈니스 작업자로
모델링하지 않습니다. 반면에 비즈니스 정보 시스템을 고객이 직접 사용하고 이러한 상호작용이 비즈니스 서비스의 핵심 부분인 경우 상업적으로 매우 중요하므로 비즈니스 분석 모델에 표시할 수
있습니다. 텔레 뱅킹 서비스가 이러한 정보 시스템 유형의 좋은 예입니다.
이러한 경우 다음과 같은 절차를 수행할 수 있습니다.
-
정보 시스템을 액터와 상호작용하는 완전 자동화된 비즈니스 작업자로 간주합니다.
-
정보 시스템이 다른 비즈니스 작업자 또는 비즈니스 엔티티와 연결된 경우 이 관계를 링크 또는 연관으로 나타낼 수 있습니다. 시스템은 일반적으로 비즈니스 작업자에게 진행상태를 알려주거나 비즈니스 엔티티에 대한
정보를 사용합니다.
-
비즈니스 분석 모델에서 정보 시스템을 나타내는 서비스 목록과 함께 비즈니스 작업자에 대해 간략하게 설명합니다.
-
정보 시스템 및 해당 환경의 모든 세부사항과 특성을 종속 정보 시스템 모델로 모델링합니다.
-
비즈니스 작업자 중에서 완전 자동 비즈니스 작업자를 쉽게 식별할 수 있는 이름 지정 규칙을 사용합니다. 예를 들어, "자동 <비즈니스 작업자 이름>" 또는 "시스템: <비즈니스 작업자
이름>"과 같은 접두부 또는 접미부를 사용합니다. 특정 아이콘을 사용하여 스테레오타입을 정의할 수도 있습니다.
비즈니스 시스템, 비즈니스 작업자, 비즈니스 엔티티 및 비즈니스 이벤트는 협업을 통해 비즈니스 유스 케이스에서 설명하는 모든 타스크를 추가 또는 누락 없이 수행합니다. 비즈니스 분석 모델은 해당 추상 레벨에서
정확하게 전체 조직 구조를 나타냅니다.
비즈니스 디자인 모델로 전이
비즈니스 디자인 모델은 비즈니스 분석 모델에 실현(realization)을 위한 선택사항 및 관련 근거와, 비즈니스 작업자를 휴먼, 소프트웨어 또는 시스템으로 리팩토링하기 위한 선택사항 및 관련 근거가
추가되어 발전된 모델입니다. 비즈니스 작업자는 일부 또는 모든 휴먼, 소프트웨어 및 하드웨어로 구성됩니다. 비즈니스 디자인 모델은 이 구성을 더 이상 세분화하지 않습니다. 이는 후속 시스템 또는 소프트웨어 개발
노력으로 수행할 타스크입니다.
|