시스템 엔지니어링 (129)

시스템 설계 및 개발

거동 도메인 솔루션에 대한 주요 요소 

거동 도메인 솔루션은 시스템 거동 반응과 활동을 형성하기 위한 기초를 제공하는 여러 가지 요소로 구성되어 있다. 여기에는 시나리오 자극, 능력, 자원, 제약사항 및 반응을 포함하고 있다. 능력은 최소한 두 가지 또는 그 이상의 시스템 업무로 구성되는 하나 또는 그 이상의 시스템으로 나타낸다. 각 시스템 운용과 업무는 다음 사항을 수행한다.

· 하나 또는 그 이상의 상호작용을 소통한다.
· 최소한 하나 또는 그 이상의 성능 예산과 안전 마진에 의해 구속된다.

· 성능 예산과 안전 마진에 대한 내용은 시스템 분석, 성능예산, 안전 마진 실무에서 상세하게 다루도록 하겠다.

1. 거동 도메인 솔루션의 필요성
왜 우리는 거동 도메인 솔루션을 필요로 하는가? 이는 시스템 개발자가 하나의 인간으로서 어떻게 설계 문제점을 다루어야 하는지에 달려있다. 즉, 사람들은 서로 다른 교육, 지식 및 경험을 지니고 있다. 설계팀 내에서 어떤 사람은 그 시스템이 무엇을 수행하도록 요구하고 있는지 거동을 알고 싶어 하지만,  또 다른 사람은 어떠한 데이터교환 프로토콜을 사용하여야 하며 또는 무슨 소프트웨어 운용시스템 언어를 사용할 것인지, 곧 적용방법을 알아내어 어떻게 그 회로를 설계할 것인가에 초점을 두고 있다는 것이다. 

시스템 엔지니어로서 당신은 리더십을 발휘하여 이러한 다양함과 방황하는 환경을 통제할 수 있어야 한다. 그렇지 않으면, 혼란, 무질서 및 혼돈을 불러일으키게 된다. 따라서 동시에 한 업무에 초점을 맞춘 그룹을 형성하라. 첫째로 그 시스템이 거동 도메인 솔루션을 통해 무슨 기능을 수행해야 할 것인지를 이해토록 하라. 그다음 거동 도메인 솔루션이 성숙해감에 따라 다음 활동인 거동 도메인 솔루션이 물리적 컴포넌트를 어떻게 적용해야 하는지를 나타내는 물리적 도메인 솔루션을 동시적으로 개발토록 하라.

2. 거동 도메인 솔루션 연관성
다중 레벨 거동 도메인 솔루션 연관성은 고도로 반복적인 활동을 통해 이루어진다. 그림 1의 개체 및 품목 시스템엔지니어링 설계 프로세스에서와 같이 요구사항, 운용 및 물리적 도메인 솔루션과 밀접한 협조와 협력을 요구하고 있다.

그림 1. 개체 및 품목 시스템 엔지니어링 설계 흐름도

대상시스템(SOI)이 기술, 비용, 일정, 지원 및 리스크에 대한 수명주기 관점과 전반적인 개발 과정을 통해 최적 상태로 평형을 이룰 때까지 여러 번의 반복이 요구된다.

3. 거동 도메인 솔루션 개발순서
거동 도메인 솔루션은 개체 품목에 대한 리드 시스템 엔지니어에 의해 수행되는 다분야의 훈련된 활동을 통해 이루어진다. 거동 도메인 솔루션은 약간 늦게 개발되긴 했지만 그림 2에서 보는 바와 같이 물리적 도메인 솔루션보다는 앞서지만, 요구사항과 운용 도메인 솔루션과 거의 동시적으로 이루어진다.

그림 2. 시간에 따른 시스템 솔루션 도메인

4. 거동 도메인 솔루션 개발 책임
거동 도메인 솔루션의 책임은 해당 프로그램의 기술이사나 프로젝트 엔지니어에게 달려있다. 그리고 이는 통상 프로그램의 SE 리더에게 연결된다. 리드 시스템 엔지니어는 모든 운용 및 다분야 이해관계자 관심사항이 논리적이고 기능적인 아키텍처와 이에 대한 기술내용에 나타난 사실을 확인하기 위하여 거동 도메인 솔루션 개발을 수행한다. 

거동 도메인 솔루션의 주요요소가 승인되어 배포되면, 형상관리자는 형상관리 위원회(CCB), 시스템의 소프트웨어 형상관리 위원회(CCB) 개별 이해관계자의 지침에 따라 공식적인 형상변경 활동을 수행한다.

거동 아키텍처 개발

시스템이나 개체 운용 아키텍처가 진화하면서 성숙됨에 따라 그다음 단계는 그 시스템과 연관된 개체(UML 행위자)가 다양한 운용자와 외부 시스템 자극과 충격이 어떻게 상호작용하며 반응하는지를 이해함에 있다. 이러한 기초적인 이해는 다음과 같이 시작된다.

· 운용 아키텍처에서 식별된 개체
· 시스템 성능규격(SPS) 또는 개체 개발규격과 같은 규격에 제시된 능력

시스템이나 개체 개발 단계에서 그 개체란 단순하게 추상적으로 나타난다. 이는 추상적인 분석으로서 우리는 이를 가리켜 논리적이거나 연상적인 관계라고 생각한다. 여기서 우리의 도전은 이러한 관계를 표시하는 논리적/기능적 구조를 생성하는 일이다. 우리는 이를 가리켜 논리적 또는 기능적 아키텍처라고 부른다.

1. 논리적 아키텍처 기반
논리적 또는 기능적 아키텍처는 주요 능력, 다중 레벨 논리적 또는 기능적 능력과 운용 도메인 솔루션 요소 사이에 상호관계를 나타낸다. 논리적/기능적 아키텍처는 그 시스템이나 개체가 다양한 임무와 시나리오에 어떻게 주어진 운용환경에 대응하는 거동 상호작용을 표현하기 위한 구조를 제공해 준다. 

그 시스템이나 개체에 입력 프로세스를 수행함에 따라 이는 거동형태와 특성을 나타낸다. 내부적인 프로세스를 수행하기 위하여 시스템이나 개체는 입력 세트를 거동, 제품, 부산물 및 서비스로 전환하기 위하여 하나 또는 그 이상의 능력을 제공하게 된다. 

그 시스템이 주어진 운용환경에서 상호 호의적 또는 적대적 관계를 유지하려고 한다면, 추가적인 능력이 이러한 개체의 상호작용 동안에 생존성이나 상호 운용성 레벨을 확인해야 한다. 

시스템 상호작용에 대한 보다 많은 정보를 위해 운용환경과의 시스템 상호작용과 시스템 인터페이스 분석, 설계 및 통제 실무를 참조하기 바란다.

우리가 이러한 환경을 분석해감에 따라 우리는 그 시스템에 의해 파생되는 거동, 제품, 부산물 또는 서비스를 나타내거나 상호작용하는 버츄얼 및 물리적 시스템 개체 또는 사람, 능력, 운용, 기능, 이벤트, 역할, 제약사항 및 통제와 같은 행위자(UML)가 있다는 사실을 발견하게 된다. 우리는 이러한 사람, 능력, 운용, 기능, 이벤트, 역할, 제약사항 및 통제를 객체, 개체 또는 행위자로 분류한다. 일반적으로 그 행위자, 객체 또는 개체는 사람, 장소, 사물과 같이 명사로 식별된다.

논리적/기능적 아키텍처는 그 임무를 수행하기 위하여 시스템이 수행할 능력에 기여하기 위해 무슨 관계와 상호작용이 요구되는지를 나타낸다. 이러한 특성은 객체와 상호작용이 어떻게 물리적으로 적용되어야 하는지를 나타내진 않는다. 여기서 물리적 도메인 솔루션은 물리적 아키텍처로 어떻게 수행되는 지를 나타내게 된다. 항상 기능이 형태와 적용보다 먼저 주어진다.

2. 논리적/기능적 아키텍처 개발 방법
우리는 논리적/기능적 아키텍처는 그 대상, 개체, 또는 행위자를 나타낸다는 사실을 살펴보았다. 이는 하부시스템인 제품, 아셈부리 그리고 이들 상호간의 관계처럼 주어진 추상적이고 클래스 개체 내에서 존재한다. 그러면 우리가 어떻게 이러한 아키텍처를 개발할 것인가라고 질문해 본다.
하나의 접근방법은 아래와 같은 단계로 구성된 간단한 방법을 적용하는 방법이다.

1 단계 : 논리적 객체 또는 개체를 식별하라.
2 단계 : 각 개체 능력을 식별하라.
3 단계 : 논리적 상호관계 매트릭스를 생성하라.
4 단계 : 논리적/기능적 아키텍처를 생성하라.

이러한 각 단계에 대하여 보다 상세하게 살펴보자.

(1) 논리적 객체 또는 개체 식별
논리적 또는 기능적 아키텍처를 개발하기 위한 첫 번째 단계는 시스템이나 개체의 요구능력을 식별하여 목록을 단순하게 생성함에 있다. 그리고 다음 그림 3에서와 같이 유사하게 계층 트리로 목록을 정리하는 일이다.

그림 3. 자동차-운전자 논리적 요소

여기에 나타난 사례는 자동차-운전자 시스템을 보여주고 있다.
(2) 각 개체 능력 식별
한 번 당신이 시스템이나 개체의 주요 능력을 식별하고 나면, 다음 단계는 그 능력 상호간의 관계를 형성함에 있다. 사용되는 기법은 시스템이나 개체의 크기와 복잡도에 달려있다. 만일 당신이 시스템 블록선도, SBD로 시작한다면, 그 방법은 매우 도전적일 수 있다. 당신은 당신이 그 관계만을 정리하는 것뿐만 아니라 그래프로 나타내는 길을 제시하게 된다. 상호 연결하는 선은 그 도표를 불필요하게 복잡하거나 혼돈을 가져오지 않도록 하는 상호 교차하는 길을 알려주는 역할을 하게 된다.
(3) 논리적 상호관계 매트릭스
그러면 우리는 어떻게 시스템의 논리적/기능적 및 상호작용 관계를 모델화 할 것인가? 첫 번째로 우리는 그림 4의 상단 왼쪽에 있는 매트릭스를 생성하여 이를 할 수 있다.

그림 4. 거동 솔루션 능력 상호작용

이러한 N×N 매트릭스는 입력사항인 자극과 출력사항인 반응처럼 하나의 능력을 다름 능력으로 연결해 주는 도표이다. 능력 A는 능력 B로, 능력 B는 능력 C로, 그리고 더 아래로 논리적 개체관계를 보여주고 있다. 대형 복합 시스템에 대하여 요약 매트릭스는 다음 단계에 대한 기반을 조성해 준다.

별도의 단계를 생성하기 위해 나타난다 할지라도 매트릭스는 중요한 분석적 비교 모델로 역할하게 된다. 상호 대응 방법에서 우리는 하나의 요소에 집중하며 매트릭스 줄을 넘은 각 나머지 요소와 함께 개체 관계를 가진다면 그때에 결정하게 된다. 다음 단계는 프레젠테이션 목적을 위해 논리적 아키텍처를 그래프로 전환하는 단계이다. 만일 우리가 다음 단계를 먼저 생성하려고 한다면, 매트릭스의 강점과 N×N 접근방법으로서 모든 상호작용으로 여겨지는 분명한 방법을 무시하고 있게 된다.
(4) 논리적 및 기능적 아키텍처 생성
만일 논리적 상호작용 매트릭스가 형성되고 나면, 그림 4의 오른쪽 하단에 나타난 N×N 도표를 그래프로 전환하게 된다. 각 능력은 기대되는 산출물과 성능레벨을 생산하기 위해 요구되는 활동을 수행하는 다중 레벨의 운용 또는 업무를 나타낸다.
N×N 방법에 대한 대안은 그림 5에 나타난 객체지향(OO) 표기방법이다.

그림 5. 논리적 개체에 대한 객체지향 표기법

이 방법은 각 능력에 대한 이름, 속성, 운용에 대한 내용을 기술한다. 유사한 표기법은 그림 4에 나타난 N×N 도표에 이를 부가하여 사용할 수 있다.
지금까지 우리는 기본적인 논리적/기능적 아키텍처를 어떻게 형성하는가를 소개했다. 여기에서 가장 중요한 점은 시스템이나 개체의 일차 기능을 식별함에 있다. 우리가 이를 어떻게 식별하느냐 하는 것은 그 시스템이 잘 알려졌느냐 또는 잘 알려지지 않으냐에 달려있다. 따라서 기본적인 아키텍처 요소가 알려질 경우에는 불필요한 분석을 하지 않아도 된다.

3. 잘 알려진 시스템의 논리적/기능적 아키텍처 개발
대부분의 인공 시스템은 잘 알려진 시스템이다. 이미 입증된 아키텍처와 기술은 기존 설계를 향상함에 달려있다. 다음 사례를 살펴보자.
잘 알려진 시스템으로 자동차는 새시, 엔진, 등으로 구성되어 있다. 비록 당신이 창의적인 설계 솔루션을 제한하고 ‘주어진 틀 속에서 생각’의 패러다임을 피할 필요가 있지만, 우리는 자동차의 근본적인 설계를 기능적으로, 예를 들면 새시, 엔진, 바디를 생성하기 위해 재설계할 필요는 없다. 우리는 초기단계에서 기존의 자동차 아키텍처를 재사용하면 된다.

가설적으로 만일 당신이 두 개의 통제 그룹과 동일 시스템에 대하여 논리적 아키텍처를 생성하기 위하여 각 개별로 임무를 부여한다면, 그 그래프는 달라져도 좋다. 한 아키텍처는 맞고 다른 아키텍처는 틀린 것인가? 일반적으로 그렇지 않다. 항상 동일한 엔지니어링 문제점을 해결함에 있어서 다양한 접근방법이 있을 수 있다. 우리는 자동차, 컴퓨터, 텔레비전과 같은 상업제품에서 이러한 점을 볼 수 있다. 일반적으로 유사한 마켓 솔루션 영역 가정을 할 수 있다. 예를 들면, 운송, 조향 및 이와 유사한 경우를 생각해 볼 수 있다.

4. ‌잘 알려지지 않은 시스템의 논리적/기능적 아키텍처 개발
상대적으로 잘 알려져 있지 않은 시스템은 시스템의 논리적/기능적 아키텍처를 접근함에 있어서 주어진 태두리 영역 밖에서 생각하는 새로운 방법을 요구하고 있다. 다음 사례를 생각해 보자.

NASA가 이전에 달나라에 무인 비행선에 성공했다 할지라도, 아폴로 달나라 비행은 사람이 타고 달 표면에 내리고 다시 비행하는 첫 번째 설계이다.

NASA의 우주정거장 프로그램은 인간이 무중력 상태에서 연장된 일정 기간에 특정 업무를 수행하기 위한 우주 공간에서의 실험 환경에서 사람이 거주할 수 있는 최초의 환경을 제시했다.

잘 알려지지 않은 시스템이의 경우라면, 개발팀은 가상 임무 또는 과학적 목표로부터 논리적/기능적 아키텍처를 도출함에 있다. 이는 ‘크고 장엄한 과학을 적용하라’는 의미로 볼 수 있다. 이러한 경우에 시스템 엔지니어는 연구 주 책임자와 협력하여 그 시스템의 능력을 도출하고 생성하게 된다. 일부 획득자는 연구계약이나 개념제시계약을 시도하기도 한다. 이는 시스템 능력을 구하기 위해 일련의 점진적인 계약 단계를 통해 수행하기도 한다.

5. 논리적/기능적 아키텍처 모델링
논리적/기능적 아키텍처는 시스템이나 개체의 내장 요소 및 그들의 상호관계를 나타내기 위해 시스템 블록선도(SBDs), 목표 도표, 기타 그래픽 기법으로 모델기반 표기방법으로 사용하고 있다. 그러나 SBDs는 행위자 또는 객체 상호간 발생하는 데이터 교환이나 거동 상호작용의 논리적 순서를 제시하진 않는다. 

따라서 각 후보 아키텍처 솔루션의 전반적인 효과도를 평가하기 위하여 시계열, 성능 예산 및 안전 마진 할당과 연계하여 거동 모델링 도구가 사용된다. 이러한 거동 모델링 도구로서는 N×N 도표, UML 상호작용 도표, 기능흐름선도(FFBD), 통제 및 데이터 흐름선도 등이 사용되고 있다.

당신은 왜 우리가 논리적/기능적 아키텍처 모델을 생성할 필요가 있는지를 질문해 보아야 한다. 논리적/기능적 아키텍처 모델링과 내부능력 처리 프로세스는 다음과 같은 내용에 필수적으로 요구된다.

· 아직 발견되지 않은 요구사항을 도출하고 알아보기 위함
· 시스템이나 개체의 성능 예산과 마진을 설정
· 시스템 성능 최적화를 위한 ‘로드’ 배분
· 요구사항을 하위레벨로 할당과 분할하고 품목 개발규격 제시

6. 소결론
논리적 개체 관계는 우리로 하여금 확인된 운용 요구에 근거하여 둘 또는 그 이상의 논리적 개체상의 연합이나 연계성을 알아보기 위해 사용된다. 이는 필요성에 입각한 상호관계이기 때문에 다음 사항이 강조되어야 한다.

· 누가 누구와 상호 작용하고 있는가.
· 무슨 사항이 상호작용하거나 소통되어야 하는가.
· 언제 그 거동 상호작용이 일어나는가.
· 어떤 상태에서 일어나는가.

이러한 논의에 근거하여 거동 도메인 솔루션을 개발하기 위해 사용되는 기본 방법을 기술해 보자. 이러한 방법을 당신의 비즈니스 요구에 적합하도록 적용해 보라.

지금까지 우리는 거동 도메인 솔루션에 대한 구조로서 나타나는 논리적/기능적 아키텍처를 생성하는 방법을 기술해 보았다. 이제 우리는 그 초점을 시스템이나 개체의 전반적인 거동 도메인 솔루션을 생성하기 위한 방법을 알아보도록 하자.

 

거동 도메인 솔루션 개발방법

거동용 도메인 솔루션은 SE 프로세스 모델의 주요요소로 개발된다. 거동 도메인은 요구도메인, 운용 도메인, 물리적 도메인과 긴밀한 협조와 반복적인 방법으로 개발된다. 이는 매우 혼란스럽고 많은 혼선을 가져다준다.
우리는 거동 도메인 솔루션을 개발하기 위하여 우리가 할 수 있는 최대의 반복적 방법을 적용하여 혼돈과 혼란을 최소화할 수 있다. 

이 방법은 거동 도메인 솔루션을 개발하기 위한 여러 접근방법 중의 하나이다. 이러한 단계를 한 사례로 보고 이를 당신의 비즈니스 도메인과 시스템 적용에 적합하도록 테일러링하면 된다. 그 방법은 다음 단계로 구성되어 있다.

1단계 : 다중 모드 논리적 아키텍처 설정
2단계 : 모델 모드-기반 시스템 상호작용
3단계 : 개체 성능 예산과 설계 안전 마진 할당
4단계 : 시스템 고장모드와 영향분석
5단계 : 시스템 거동 성능 평가와 최적화
6단계 : 치명적인 운용과 기술 쟁점사항(COIs/CTIs) 해소
7단계 : 거동 도메인 솔루션 검증과 확인
8단계 : 개체 거동 솔루션 베이스라인 설정

(1) 다중 모드 논리적 아키텍처 설정
거동 도메인 솔루션 개발 첫 번째 단계는 시스템 능력 상호간의 개체 관계를 이해함에 있다. 그 관계와 연계된 상호작용은 논리적/기능적 아키텍처로서 연계된 구조를 형성하는 기초를 제공함에 있다. 임 무시스템, 지원시스템, 운용환경 상호관계에 기초하여 모드-기반 능력, 거동, 상호작용을 통합한 논리적 아키텍처를 형성하라.

만일 적합하다면, 여러 논리적 아키텍처를 식별하여 모델화, 시뮬레이션, 평가 및 일련의 아키텍처 세트에 대한 절충 분석을 수행하라. 모든 운용 모드에 대하여 시스템 성능을 적절하게 균형화한 가장 좋은 논리적 아키텍처를 선택하라. 그림 6은 시스템 능력 상호간 연합된 관계를 나타낸 논리적 아키텍처의 상위레벨 사례를 제공해 준다.

그림 6. 규격서 개발에 아키텍처 기반 접근방법

(2) 모델 모드-기반 시스템 상호작용
기본적으로 상위레벨 상호작용을 고려하여 단계별 기능과 운용 모드로서의 임무시스템의 상호작용을 나타내도록 하라. 각 모드의 유스 케이스에 기초하여 그림 7에서와 같은 시스템 능력과 같이 입력으로부터 출력으로 거동의 상호작용을 모델화 하라.

그림 7. 능력 상호작용 관계

(3) 개체 성능 예산과 설계 안전 마진 할당
각 단계, 모드, 유스 케이스, 운용 시나리오에 대하여 임무 이벤트 시계열(MET)과 같은 시간에 제약된 성능에 대한 능력 상호관계와 성능을 연결해 보라. 그리고 각 논리적 개체에 대하여 성능 예산과 설계 안전 마진을 할당해 보라. 그림 8에서와 같이 임무 이벤트 시계열(MET)로부터 도출된 시간-성능 할당을 포함토록 하라.

그림 8. 능력 ‘스레드’ 시간 성능 할당

(4) 시스템 고장모드와 영향 분석
임무가 치명적이며 장비, 인력, 공중 또는 환경에 피해를 가져다주는 시스템에 대하여 고장 모드 및 영향 분석(FMEA)을 수행한다. 리스크가 높은 위험을 수반하는 치명적인 임무 요소에 대하여 FMEA 분석은 고장모드, 영향, 치명적인 분석(FMECA)까지 확장된다. 이전의 Mil-Std-1629A 고장모드, 영향, 치명도 분석을 위한 군사표준절차에서 그 지침을 제공받을 수 있다.

(5) 시스템 거동 성능 평가와 최적화
SPS 또는 각 개체의 품목개발 규격 요구사항에 관한 거동 도메인 솔루션 성능을 평가하고 최적화하라. 각 단계와 운용모드에 대하여 각 모드 능력과 성능 상호작용이 기술, 기법, 비용, 일정 제약사항에 관한 유사하거나 가장 나쁜 시나리오를 유지하면서 생존할 수 있음을 확인하라.

(6) 치명적인 운용과 기술위험과 제약사항 해소
거동 도메인 솔루션이 진화됨에 따라 치명적인 운용 및 기술적 쟁점사항 (COIs/CTIs)과 리스크를 식별하고, 분별하며 해소토록 하라. 그 쟁점사항과 리스크를 적합한 CWBS 요소와 규격서 요구사항으로 연결토록 하라. 적합한 시기와 장소에서 COIs/CTIs를 계약사항에 따라 해소하기 위하여 획득자와 사용자와 함께 협력토록 하라.

(7) 거동 도메인 솔루션 검증과 확인
거동 도메인 솔루션 개발을 통해 솔루션이 진화되면서 문서검토, 기술검토, 시제품, 기술데모, 모델링과 시뮬레이션을 통해 완전성과 통합성을 지속적으로 검증하고 확인토록 하라.
거동 도메인 솔루션의 모든 관점은 공식적인 사업제안 요청 또는 계약단계에서 시스템 계층구조 규격 트리에 따라 시스템 요구문서(SRD)에 문서화된 소스 또는 기초 요구사항으로 추적하면서 이를 검증토록 하라.

(8) 개체 거동 솔루션 베이스라인 설정과 유지
시스템과 각 개체 거동 도메인 솔루션이 승인되면, 요구할당과 분할, 미래 기술 의사결정, 변경통제에 대한 기조로 사용할 공식적인 베이스라인을 설정하라. 거동 도메인 솔루션과 업데이트를 개발형상으로 진화해 가라.

 

거동 도메인 솔루션 개발 도전활동

운용 도메인 솔루션이 개발될 때 사용자, 획득자 및 시스템 개발자가 논의해야 할 여러 가지 사항이 있다. 예를 들면, 다음과 같은 사항이 필요하다.

도전 1 : 요구사항 추적성
도전 2 : 이해관계자 협동
도전 3 : 이해관계자 검토
도전 4 : 치명적 쟁점사항 리스크 통합
도전 5 : 베이스라인 관리
도전 6 : 실 상황
도전 7 : 거동 솔루션 시스템 기술
도전 8 : CWBS 추적성

주요 질문사항을 알아보고 거동 도메인 솔루션을 다음 개발 활동을 살펴보라.

(1) 요구사항 추적
거동 도메인 솔루션은 다음 사항을 추적하고 있는가?
· 성능규격(SPS)과 개발규격에 문서화된 요구도메인 솔루션 시스템
· 시스템 운용개념서(ConOps), 임무 이벤트 시계열(METs) 시스템 단계 및 운용모드 등에 문서화된 운용 도메인 솔루션
· 물리적 시스템 아키텍처, 자재규격(BOMs) 등으로 문서화된 물리적 도메인 솔루션
(2) 이해관계자 협동
당신은 거동 도메인 솔루션을 개발함에 있어 주요 이해관계자와 협의하고 협력하고 있는가?
(3) 이해관계자 검토
주요 이해관계자가 일부 또는 모든 거동 솔루션에 대하여 적절하게 검토하고 승인하였는가?
(4) 치명적 쟁점사항 리스크 완화
모든 치명적인 운용, 기술, 지원, 비용, 일정 리스크가 식별되고 완화되었는가?
(5) 베이스라인 관리
거동 도메인 솔루션 연관제품이 진화하고 있는 개발형상 베이스라인으로 연계되어 있는가?
(6) 실 상황
거동 도메인 솔루션 적용이 가용한 비용 및 일정 범위 내에서 수락 가능한 리스크 레벨로 물리적 컴포넌트와 기술로 실제 달성 가능한가?
(7) 거동 솔루션 시스템 기술
거동 도메인 솔루션이 시스템/하부시스템 설계서(SDD) 또는 인터페이스 설계서(IDD)를 시스템이나 개체의 획득, 또는 개발 및 유지보수를 허용하는 세부레벨로 적절하게 문서화 되어 있는가?
(8) CWBS 추적성
거동 도메인 솔루션 요소가 계약 업무분해구조 요소로 추적 가능한가?

1. 거동 도메인 솔루션 연관제품
거동 도메인 솔루션의 주요 연관제품은 다음과 같다.

· 다중 레벨 시스템 능력에 대한 상호작용 도표
· 능력을 처리하는 UML 순서도
· 논리적 또는 기능 아키텍처-FFBD와 ERD
· 시간에 따른 성능능력
· 시간-기반 성능을 그 능력을 적용하기 위해 요구되는 운용 및 업무로 할당

 

원칙

요약해서 앞서 논의된 내용은 하나의 개체에 대한 거동 도메인 솔루션 실무 개발과 연관된 원칙을 설정하기 위한 기본지침을 제공함에 있다.

· 원칙 1 : 거동 도메인 솔루션은 운용 도메인 솔루션에서 비롯되며 물리적 도메인 솔루션 개발을 위한 기조를 제공해 준다.
· 원칙 2 : 거동 도메인 솔루션은 요구사항, 운용 및 물리적 도메인 솔루션과 일관되며, 추적해야 한다.

 

요약

거동 도메인 솔루션에 대한 논의는 거동 도메인 솔루션과 이에 따른 논리적 아키텍처의 필요성과 진화를 주로 다루었다. 우리는 주로 다음과 같은 사항에 대한 중요성을 다루고 있다.

· 시스템 능력을 제공하는 논리적 개체를 식별
· 논리적 실체가 무슨 능력을 제공하고자 하는지 이해
· 논리적 개체가 어떻게 연계되고 상호작용하고 있는지 표현
· 논리적 성능을 시스템 성능 매트릭스로 연결

다른 전형적인 솔루션과 같이 이 솔루션도 시간이 지나면서 더욱 성숙해져 간다. 이는 요구사항, 운용 및 물리적 도메인 솔루션과 함께 상호협력 및 협조와 협상에 의해 달성된다.

1. 유의사항
UML은 객체관리 그룹(OMG)의 등록 상표이다.

2. 일반적 예제
서론에서 제시된 이 장에서 알아두어야 할 사항에 대하여 답변토록 하라. 앞서 제시된 시스템, 일반적 예제나 신규선정 시스템에 대하여 이 장에서 논의된 사항을 적용해 보라. 시스템 선정에 대하여 당신은 획득자의 조언을 들어도 좋다.

(a) 시스템 거동 도메인 솔루션의 행위자를 식별토록 하라
(b) 시스템의 논리적 또는 기능적 아키텍처를 개발하라.
(c) 논리적 개체 관계와 상호작용을 알아내기 위해 매트릭스를 생성해 보라.
(d) 상위레벨 상호작용 도표와 행위자의 상호연계를 나타내는 순서도를 개발하라.

3. 조직중심 예제
(1) 당신 조직의 지휘체계를 알아보라. 거동 도메인 솔루션을 개발하기 위하여 무슨 지침과 원칙을 제시하고 있는가? 그 결과를 문서화하고 보고하라.
(2) 당신 조직 내에서의 계약 프로그램을 적용하라. 그리고 리드 시스템 엔지니어와 인터뷰하고 프로그램을 어떻게 진행할 것인지를 연구하라.
· 거동 도메인 솔루션을 형성하라.
· 거동 도메인 솔루션을 문서화하라.
· 거동 도메인 솔루션을 요구사항, 운용 및 물리적 도메인 솔루션을 생성하라.
(3) 당신 조직부서의 한 시스템 규격을 선정하라. 그리고 상위레벨 거동 도메인 솔루션을 생성하라.

민성기 시스템체계공학원장 (sungkmin0@gmail.com)