본문으로 이동

기능 모델

위키백과, 우리 모두의 백과사전.

시스템 공학, 소프트웨어 공학 및 컴퓨터 과학 분야에서 기능 모델(Function model)은 모델링된 시스템 또는 주제 영역 내의 기능(활동, 작업, 프로세스, 운영)을 구조적으로 표현한 것이다.[1]

IDEF0 표기법으로 "수리 가능한 예비 부품 유지 관리" 프로세스의 기능 모델 예시.

기능 모델은 활동 모델 또는 프로세스 모델과 유사하게 정의된 범위 내에서 사업의 기능을 그래픽으로 표현한 것이다. 기능 모델의 목적은 기능 및 프로세스를 설명하고, 정보 요구 사항 발견을 돕고, 기회를 식별하며, 제품 및 서비스 비용을 결정하는 기초를 마련하는 것이다.[2]

역사

[편집]

시스템 공학 및 소프트웨어 공학 분야의 기능 모델은 1950년대와 1960년대에 시작되었지만, 조직 활동의 기능 모델링의 기원은 19세기 후반으로 거슬러 올라간다.

19세기 후반에는 비즈니스 활동, 작업, 프로세스 또는 운영을 그림으로 나타내는 최초의 다이어그램이 등장했으며, 20세기 전반에는 비즈니스 프로세스 활동을 문서화하는 최초의 구조화된 방법이 등장했다. 이러한 방법 중 하나는 1921년 프랭크 길브레스가 "프로세스 차트—가장 좋은 방법을 찾는 첫 단계"라는 제목의 발표를 통해 미국 기계 기술자 협회 (ASME) 회원들에게 소개한 흐름 프로세스 차트였다.[3] 길브레스의 도구는 빠르게 산업공학 교육 과정에 도입되었다.

시스템 공학 분야의 등장은 1940년대 벨 전화 연구소로 거슬러 올라간다.[4] 복잡한 공학 프로젝트에서 부분들의 합의 특성과 크게 다를 수 있는 시스템 전체의 속성을 식별하고 조작할 필요성 때문에 다양한 산업에서 이 분야를 적용하게 되었다.[5] 이 분야에서 기능 모델을 처음 정의한 사람 중 한 명은 영국 엔지니어 윌리엄 고슬링이었다. 그는 저서 "공학 시스템의 설계(The design of engineering systems)"(1962, p. 25)에서 다음과 같이 언급했다.

따라서 기능 모델은 유용하려면 두 가지 목표를 달성해야 한다. 첫 번째 및 마지막 처리량 상태, 그리고 중간 상태 중 일부를 완전히 정의할 수 있는 처리량 설명 메커니즘을 제공해야 한다. 또한 이 메커니즘으로 올바르게 설명된 모든 입력을 사용하여 실제 시스템이 해당 입력에 대해 제공했을 출력에 대한 동일하게 올바른 설명을 생성할 수 있는 수단을 제공해야 한다. 기능 모델이 수행할 수 있지만 모든 기능 모델에 필요한 것은 아닌 다른 두 가지 사항도 주목할 수 있다. 따라서 이러한 시스템은 입력 및 출력 외의 시스템 처리량을 설명할 수 있지만 그럴 필요는 없으며, 각 요소가 처리량에 대해 수행하는 작업에 대한 설명을 포함할 수도 있지만 다시 말하지만 이는 필수가 아니다.[6]

최초의 잘 정의된 기능 모델 중 하나는 1950년대 국방 관련 기업인 TRW에서 개발한 기능 흐름 블록 다이어그램(FFBD)이었다.[7] 1960년대에는 NASA에서 우주 시스템 및 비행 임무의 시간 순서 이벤트를 시각화하는 데 사용되었다.[8] 이는 시스템 공학에서 시스템 기능의 실행 순서를 보여주기 위해 널리 사용된다.[9]

기능 모델링 주제

[편집]

기능적 관점

[편집]

시스템 공학 및 소프트웨어 공학에서 기능 모델은 기능적 모델링 관점으로 생성된다. 기능적 관점은 비즈니스 프로세스 모델링에서 가능한 관점 중 하나이며, 다른 관점으로는 행동, 조직 또는 정보적 관점이 있다.[10]

기능적 모델링 관점은 동적 시스템을 설명하는 데 중점을 둔다. 이 모델링 관점의 주요 개념은 프로세스이며, 이는 기능, 변환, 활동, 작업, 태스크 등이 될 수 있다. 이 관점을 사용하는 모델링 언어의 잘 알려진 예시로는 데이터 흐름 다이어그램이 있다.

이 관점은 프로세스를 설명하기 위해 네 가지 기호를 사용한다.

  • 프로세스: 입력에서 출력으로의 변환을 나타낸다.
  • 저장소: 데이터 수집 또는 일종의 재료.
  • 흐름: 프로세스 내 데이터 또는 재료의 이동.
  • 외부 개체: 모델링된 시스템 외부에 있지만 시스템과 상호 작용한다.

이제 이러한 기호를 사용하여 프로세스를 이러한 기호의 네트워크로 표현할 수 있다. 이렇게 분해된 프로세스는 DFD, 즉 데이터 흐름 다이어그램이다.

시스템 분석에서 기능 분해의 예시.

동적 엔터프라이즈 모델링에서는 제어 모델, 기능 모델, 프로세스 모델 및 조직 모델로 구분된다.

기능 분해

[편집]

기능 분해는 넓게는 함수적 관계를 구성 요소로 분해하여 원래 함수를 함수 합성을 통해 재구성할 수 있도록 하는 프로세스를 의미한다. 일반적으로 이 분해 프로세스는 구성 요소의 정체를 파악하거나 전체 함수의 압축된 표현을 얻기 위해 수행되는데, 이는 구성 프로세스가 특정 수준의 모듈성을 가질 때만 가능하다.

기능 분해는 컴퓨터 프로그래밍에서 중요한 역할을 하며, 주요 목표는 프로세스를 가능한 한 최대한 모듈화하는 것이다. 예를 들어, 도서관 관리 시스템은 재고 모듈, 사용자 정보 모듈, 요금 책정 모듈로 분리될 수 있다. 컴퓨터 프로그래밍의 초기 수십 년 동안 이것은 일부 저명한 실무자들이 "서브루틴화의 기술"이라고 불렀던 것으로 나타났다.

공학 시스템의 기능 분해는 공학 시스템을 분석하는 방법이다. 기본 아이디어는 블록 다이어그램의 각 블록을 설명에서 "및" 또는 "또는" 없이 설명할 수 있도록 시스템을 분할하는 것이다.

이 연습은 시스템의 각 부분이 순수한 기능을 갖도록 한다. 시스템이 순수한 기능으로 구성될 때, 그 기능들은 재사용되거나 교체될 수 있다. 일반적인 부작용은 블록 간의 인터페이스가 단순하고 일반적이 된다는 것이다. 인터페이스가 일반적으로 단순해지기 때문에 순수한 기능을 관련 유사한 기능으로 교체하기가 더 쉽다.

기능 모델링 방법

[편집]

기능적 접근 방식은 여러 다이어그램 기술 및 모델링 표기법으로 확장된다. 이 섹션에서는 중요한 기술을 연대순으로 설명한다.

기능 블록 다이어그램

[편집]
제미니 계획 우주선의 자세 제어 및 기동 전자 시스템의 기능 블록 다이어그램. 1962년 6월.

기능 블록 다이어그램은 시스템의 기능과 상호 관계를 설명하는 블록 다이어그램이다. 기능 블록 다이어그램은 다음을 그림으로 나타낼 수 있다.[11]

  • 블록으로 표시된 시스템의 기능
  • 선으로 표시된 블록의 입력
  • 9개 기능 간의 관계
  • 물질 및 신호의 기능적 시퀀스 및 경로[12]

블록 다이어그램은 특정 속성을 보여주기 위해 추가적인 회로 기호를 사용할 수 있다.

특정 기능 블록 다이어그램으로는 고전적인 기능 흐름 블록 다이어그램과 프로그래머블 로직 컨트롤러 설계에 사용되는 기능 블록 다이어그램 (FBD)이 있다.

기능 흐름 블록 다이어그램

[편집]
기능 흐름 블록 다이어그램 형식.[13]

기능 흐름 블록 다이어그램 (FFBD)은 시스템의 기능적 흐름을 다단계, 시간 순서, 단계별로 보여주는 흐름도이다.[14] 이 다이어그램은 1950년대에 개발되어 고전적인 시스템 공학에서 널리 사용된다. 기능 흐름 블록 다이어그램은 기능 흐름 다이어그램, 기능 블록 다이어그램, 기능 흐름이라고도 불린다.[15]

기능 흐름 블록 다이어그램 (FFBD)은 일반적으로 시스템의 상세한 단계별 운영 및 지원 순서를 정의하지만, 시스템을 개발하고 생산하는 프로세스를 정의하는 데도 효과적으로 사용된다. 소프트웨어 개발 프로세스도 FFBD를 광범위하게 사용한다. 시스템 컨텍스트에서 기능 흐름 단계는 하드웨어, 소프트웨어, 인력, 시설 및 절차의 조합을 포함할 수 있다.

FFBD 방식에서 기능은 논리적 실행 순서에 따라 구성되고 묘사된다. 각 기능은 다른 기능의 실행 및 완료와의 논리적 관계와 관련하여 표시된다. 기능 이름이 붙은 노드는 각 기능을 묘사한다. 왼쪽에서 오른쪽으로 향하는 화살표는 기능의 실행 순서를 보여준다. 논리 기호는 기능의 순차적 또는 병렬 실행을 나타낸다.[16]

HIPO 및 IPO

[편집]
확장된 IPO 모델.

HIPO (Hierarchical Input Process Output, 계층적 입력 처리 출력)는 1970년대에 널리 사용된 시스템 분석 설계 보조 및 문서화 기법[17]으로, 시스템의 모듈을 계층으로 나타내고 각 모듈을 문서화하는 데 사용되었다.[18]

이는 요구 사항을 개발하고, 설계를 구축하며, 자동화된 랑데부를 시연하기 위한 전문가 시스템의 구현을 지원하는 데 사용되었다. 설계 및 구현 방법론 때문에 검증이 체계적으로 수행되었다.[19]

시스템의 전체 설계는 HIPO 차트 또는 구조도를 사용하여 문서화된다. 구조 차트는 조직도와 유사한 모양이지만, 추가적인 세부 사항을 보여주기 위해 수정되었다. 구조 차트는 여러 유형의 정보를 표시하는 데 사용될 수 있지만, 주로 자료 구조 또는 코드 구조를 도표화하는 데 사용된다.[18]

N2 차트

[편집]
그림 2. N2 차트 정의.[20]

N2 차트는 행렬 형태로, 시스템 요소 간의 기능적 또는 물리적 인터페이스를 나타낸다. 이는 기능적 및 물리적 인터페이스를 체계적으로 식별, 정의, 표로 작성, 설계 및 분석하는 데 사용된다. 이는 시스템 인터페이스와 하드웨어 및 소프트웨어 인터페이스에 적용된다.[14]

N2 다이어그램은 주로 소프트웨어 영역에서 데이터 인터페이스를 개발하는 데 광범위하게 사용되어 왔다. 그러나 하드웨어 인터페이스를 개발하는 데도 사용될 수 있다. 기본 N2 차트는 그림 2에 나와 있다. 시스템 기능은 대각선에 배치되며, N × N 행렬의 나머지 사각형은 인터페이스 입력 및 출력을 나타낸다. [20]

구조화된 분석 및 설계 기법

[편집]
SADT 기본 요소.

구조화된 분석 및 설계 기법 (SADT)은 시스템을 기능의 계층으로 설명하기 위한 소프트웨어 공학 방법론으로, 소프트웨어 응용 프로그램의 스케치를 구성하기 위한 다이어그램 표기법이다. 이는 개체와 활동을 나타내는 구성 블록과 상자를 연결하는 다양한 화살표를 제공한다. 이러한 상자와 화살표는 연관된 비공식적 의미론을 갖는다.[21] SADT는 연속적인 세부 수준을 사용하여 주어진 프로세스의 기능 분석 도구로 사용될 수 있다. SADT 방법은 산업 정보 시스템에서 사용되는 IT 개발에 대한 사용자 요구 사항을 정의할 수 있을 뿐만 아니라 활동의 제조 프로세스, 절차를 설명하고 제시할 수 있다.[22]

SADT는 회사 내의 기능과 그 관계를 설명함으로써 어떤 기업이든 특정 기능적 관점을 제공한다. 이러한 기능은 판매, 주문 계획, 제품 설계, 부품 제조, 인적 자원 관리와 같은 회사의 목표를 달성한다. SADT는 간단한 기능적 관계를 나타낼 수 있으며, 서로 다른 기능 간의 데이터 및 제어 흐름 관계를 반영할 수 있다. IDEF0 형식은 더글러스 T. 로스가 1985년에 개발한 SADT를 기반으로 한다.[23]

IDEF0

[편집]
IDEF0 다이어그램 예시

IDEF0는 제조업 기능을 설명하기 위한 기능 모델링 방법론으로, 정보 시스템, 비즈니스 프로세스 또는 소프트웨어 공학 분석을 위한 기능적 모델링 언어를 제공한다.[24] 이는 소프트웨어 공학 분야의 IDEF 모델링 언어 계열의 일부이며, SADT를 기반으로 구축되었다.

IDEF0 기능 모델링 방법은 조직 또는 시스템의 결정, 행동 및 활동을 모델링하도록 설계되었다.[25] 이는 더글러스 T. 로스와 SofTech, Inc.가 개발한 기존의 그래픽 모델링 언어인 구조화된 분석 및 설계 기법 (SADT)에서 파생되었다. 원래 형태로 IDEF0는 그래픽 모델링 언어의 정의(통사론 및 의미론)와 모델 개발을 위한 포괄적인 방법론에 대한 설명을 모두 포함한다.[1] 미국 공군은 SADT 개발자들에게 시스템의 기능적 관점을 분석하고 전달하기 위한 기능 모델 방법을 개발하도록 의뢰했다. IDEF0는 시스템 분석을 체계화하고 단순화된 그래픽 장치를 통해 분석가와 고객 간의 효과적인 의사소통을 촉진하는 데 도움이 되어야 한다.[25]

공리적 설계

[편집]

공리적 설계는 제품, 정보 시스템, 비즈니스 프로세스 또는 소프트웨어 공학 솔루션의 분석, 개발, 재공학 및 통합을 위한 솔루션 합성 프레임워크로 사용되는 하향식 계층적 기능 분해 프로세스이다.[26] 그 구조는 잠재적 기능 솔루션 모델의 아키텍처 견고성을 최적화하기 위해 기능 간의 결합을 수학적으로 분석하는 데 적합하다.

관련 모델 유형

[편집]

시스템 및 소프트웨어 공학 분야에서는 수많은 특정 기능 및 기능 모델과 밀접하게 관련된 모델이 정의되었다. 여기서는 몇 가지 일반적인 유형만 설명한다.

비즈니스 기능 모델

[편집]

비즈니스 기능 모델(BFM)은 조직의 임무를 수행하기 위해 일상적으로 수행되는 운영의 일반적인 설명 또는 범주이다. 이는 "일반적인 비즈니스 기능을 식별하기 위한 개념적 구조를 제공한다".[27] 이는 비즈니스 영역 기능의 맥락에서 중요한 비즈니스 프로세스를 보여줄 수 있다. 비즈니스 기능 모델의 프로세스는 가치 사슬 모델의 프로세스와 일치해야 한다. 프로세스는 최종 제품을 생산하거나 서비스를 제공하기 위해 수행되는 관련 비즈니스 활동 그룹이다. 지속적으로 수행되는 비즈니스 기능과 달리 프로세스는 특정 시작점과 원하는 출력이 제공되는 종료점을 특징으로 한다. 오른쪽 그림은 비즈니스 프로세스, 비즈니스 기능 및 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낸다.[28]

비즈니스 프로세스 모델 및 표기법

[편집]
비즈니스 프로세스 모델링 표기법 예시.

비즈니스 프로세스 모델 및 표기법 (BPMN)은 워크플로에서 비즈니스 프로세스를 지정하기 위한 그래픽 표현이다. BPMN은 비즈니스 프로세스 관리 이니셔티브 (BPMI)에 의해 개발되었으며, 2005년에 두 조직이 합병한 이후 현재 객체 관리 그룹에서 유지 관리하고 있다. BPMN의 현재 버전은 2.0이다.[29]

비즈니스 프로세스 모델 및 표기법(BPMN) 사양은 비즈니스 프로세스 다이어그램(BPD)에서 비즈니스 프로세스를 지정하기 위한 그래픽 표기법을 제공한다.[30] BPMN의 목표는 비즈니스 사용자에게 직관적이면서도 복잡한 프로세스 의미를 나타낼 수 있는 표기법을 제공함으로써 기술 사용자 및 비즈니스 사용자 모두를 위한 비즈니스 프로세스 관리를 지원하는 것이다. BPMN 사양은 또한 표기법의 그래픽과 실행 언어의 기본 구성 요소, 특히 BPEL4WS 간의 매핑을 제공한다.[31]

비즈니스 참조 모델

[편집]
이 FEA 비즈니스 참조 모델은 비즈니스 프로세스, 비즈니스 기능 및 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낸다.

비즈니스 참조 모델은 기업, 서비스 조직 또는 관청의 핵심 비즈니스의 기능적 및 조직적 측면에 중점을 둔 참조 모델이다. 기업 공학에서 비즈니스 참조 모델은 엔터프라이즈 아키텍처 프레임워크 또는 아키텍처 프레임워크의 일부이며, 이는 엔터프라이즈 아키텍처와 관련된 구조 및 뷰를 구성하는 방법을 정의한다.

일반적인 참조 모델은 어떤 것의 기본 목표나 아이디어를 구현하고 다양한 목적으로 참조될 수 있는 모델이다. 비즈니스 참조 모델은 조직의 조직 구조와 독립적으로 비즈니스 운영을 설명하는 수단이다. 다른 유형의 비즈니스 참조 모델은 비즈니스 프로세스, 비즈니스 기능, 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낼 수도 있다. 이러한 참조 모델은 계층으로 구성될 수 있으며, 서비스 구성 요소, 기술, 데이터 및 성능 분석의 기초를 제공한다.

운영자 기능 모델

[편집]

운영자 기능 모델(OFM)은 인적 요인 엔지니어가 사용하는 전통적인 과업 분석 기술의 대안으로 제안되었다. 운영자 기능 모델은 운영자가 복잡한 시스템을 더 간단한 부분으로 분해하고 제어 동작 및 시스템 구성을 조정하여 허용 가능한 전체 시스템 성능을 달성하는 방법을 수학적 형태로 표현하려고 시도한다. 이 모델은 복잡한 시스템의 지식 표현, 정보 흐름 및 의사결정의 기본 문제를 나타낸다. 밀러(1985)는 네트워크 구조가 시스템에 대한 운영자의 내부 모델과 운영자 제어 기능을 구성하는 결정 문제를 해결하는 데 모델이 어떻게 사용되는지를 지정하는 제어 구조의 가능한 표현으로 간주될 수 있다고 제안한다.[32]

같이 보기

[편집]
위키미디어 공용에 기능 모델 주제와 관련된 미디어 분류가 있습니다.

각주

[편집]

 이 문서는 다음을 포함합니다: 퍼블릭 도메인 자료 - National Institute of Standards and Technology 웹사이트 https://www.nist.gov.

 이 문서는 다음을 포함합니다: 퍼블릭 도메인 자료 - Federal Aviation Administration 문서 "Operator Function Model (OFM)".

  1. ↑ 가 나 FIPS Publication 183 보관됨 2009-02-27 - 웨이백 머신 released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
  2. ↑ Reader's Guide to IDEF0 Function Models. Accessed 27 Nov 2008.
  3. ↑ Ben B. Graham (2002). Detail Process Charting. p.2.
  4. ↑ Schlager, J. (July 1956). 《Systems engineering: key to modern development》. 《IRE Transactions》 EM–3. 64–66쪽. doi:10.1109/IRET-EM.1956.5007383. S2CID 51635376. 
  5. ↑ Arthur D. Hall (1962). 《A Methodology for Systems Engineering》. Van Nostrand Reinhold. ISBN 0-442-03046-0. 
  6. ↑ William Gosling (1962) The design of engineering systems. p. 23
  7. ↑ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design. Page 287.
  8. ↑ Harold Chestnut (1967). Systems Engineering Methods. Page 254.
  9. ↑ Thomas Dufresne & James Martin (2003). "Process Modeling for E-Business" 보관됨 12월 20, 2006 - 웨이백 머신. INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
  10. ↑ Process perspectives. In: Metamodeling and method engineering, Minna Koskinen, 2000.
  11. ↑ James Perozzo (1994) The complete guide to electronics troubleshooting. p. 72
  12. ↑ William H. Von Alven (1964) Reliability engineering explains: "Functional block diagrams show functional sequences and signal paths, and items which are wired in parallel are drawn in parallel" (p. 286)
  13. ↑ Systems Engineering Fundamentals. 보관됨 9월 27, 2007 - 웨이백 머신 Defense Acquisition University Press, 2001
  14. ↑ 가 나 The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  15. ↑ Task Analysis Tools Used Throughout Development. FAA 2008. Retrieved 25 Sept 2008.
  16. ↑ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  17. ↑ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique, Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
  18. ↑ 가 나 Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques, and Methodologies 보관됨 2009-08-25 - 웨이백 머신 SANDIA REPORTS 85–2348qUC–32
  19. ↑ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT. NASA paper N88-17234.
  20. ↑ 가 나 NASA (1995). "Techniques of Functional Analysis". In: NASA Systems Engineering Handbook 보관됨 2008-12-17 - 웨이백 머신 June 1995. p.142.
  21. ↑ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
  22. ↑ SADT at Free-logistics.com. Retrieved 21 Sep 2008.
  23. ↑ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  24. ↑ Systems Engineering Fundamentals. 보관됨 9월 27, 2007 - 웨이백 머신 Defense Acquisition University Press, 1999.
  25. ↑ 가 나 바룬 그로버, 윌리엄 J. 케팅어 (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
  26. ↑ Suh (1999). Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4
  27. ↑ Paul Grefen (2010) Mastering e-Business. p. 5-10
  28. ↑ US Department of Interior (2000–2008) Analyze the Business and Define the Target Business Environment. Accessed 27 Nov 2008.
  29. ↑ “BPMN Information”. 2008년 12월 18일에 원본 문서에서 보존된 문서. 2008년 11월 2일에 확인함. 
  30. ↑ Richard C. Simpson (2004). An XML Representation for Crew Procedures. Final Report NASA Faculty Fellowship Program – 2004. Johnson Space Center.
  31. ↑ S.A. White, "Business Process Modeling Notation (BPMN)," In: Business Process Management Initiative (BPMI) 3 May 2004.
  32. ↑ Operator Function Model (OFM) 보관됨 2009-01-21 - 웨이백 머신. Accessed 27 Nov 2008.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=기능_모델&oldid=40250047"