SE 프로세스 모델

민성기  시스템체계공학원장(ise@seinstitute.co.kr)


개요

만일 당신이 시스템, 제품, 또는 서비스를 개발하면서 어떠한 방법을 적용하고 있는지를 각 조직에 대하여 알아본다면, 대답은 기존에 적용해오던 방법에서 논리적 기반에 의한 방법론에 이르기까지 다양하다고 할 것이다.
인간은 본래 구조화된 일반적인 방법을 사용하면서 스스로 이해 없이 기존 방식을 깨트리기까지는 매우 오랜 기간이 걸렸다. 즉, 1) 왜 그것이 있어야 하는지, 2) 그랬을 때 오는 이득이 얼마나 되는지. 지금 기존의 방법이 단순한 소형 시스템과 제품에 성공적으로 적용되고 있지만 대형 복합 프로그램은 12배 또는 수백 명의 인력을 이 방법으로 통제할 경우 무질서한 혼돈에 빠지게 된다. 따라서 단순한 방법이 모든 사이즈의 프로그램에 잘 적용될 수 있냐는 질문에 빠지게 된다.
이 글의 시작에서 우리는 시스템 개발자가 시스템 성능 규격서(SPS)를 납품 가능한 물리적 시스템으로 전환하기 위해 적용되어야 할 기본적인 업무흐름을 소개했다. 우리는 이를 위해 여섯 가지 프로세스로 업무를 기술했지만, 이러한 업무흐름은 시스템, 제품 또는 서비스를 창출하는 방법을 제시하지는 않는다. 다만 구상단계에서 납품단계에 이르기까지 시간을 두고 진화해 가는 제품 라인과 같은 방법을 제시하고 있다.
시스템 솔루션 도메인 개요에서 요구사항, 운용, 거동, 물리적 도메인 솔루션, 상호간의 순차적인 개발과 상관관계를 살펴보았다. 이러한 시스템 솔루션 도메인은 시스템, 제품 또는 서비스 솔루션의 주요 요소를 기술할 수 있다. 따라서 다음과 같은 사항을 알아보기 위해 어떠한 논리적 방법을 사용해야 하는지를 질문하게 된다.

시스템, 제품 또는 서비스 개발
모든 시스템 개발단계 업무흐름 프로세스 적용

이 장에서는 SE 프로세스 모델에 대한 방법론, 시스템이나 해당 컴포넌트 개발에 있어서 적용 방법을 소개한다. 따라서 SE 프로세스 모델과 방법론에 대한 기술과 그래픽 방법을 먼저 알아본다. 이러한 모델은 고도의 반복과 피드백의 두 가지 특성을 나타내기 때문에 모델의 내부 요소가 어떻게 반복되며 그 모델이 시스템 설계 프로세스 내에서 다중 추상적 레벨에 어떻게 적용되는지를 살펴본다. 우리는 다양한 추상적 레벨에 어떻게 이 모델을 적용하고 있는지 그 사례를 제공토록 한다.
최종적으로 우리는 요구사항, 운용, 거동, 물리적 도메인 솔루션을 바탕으로 한 다중 레벨 시스템 설계 업무흐름 과정을 나타내는 통합 프로그램을 형성하는 방법을 살펴본다. 또한, 컴포넌트의 개별적인 목적에 초점을 둔 결과보다 더 큰 목적을 달성하기 위해 함께 일하는 통합 요소로 이루어진 시스템을 제시한다.

1. 얻고자 하는 내용

· SE 프로세스 모델이란 무엇인가
· SE 프로세스 모델의 주요 요소는 무엇인가
· SE 프로세스 모델의 각 요소는 어떻게 상호 연관되어 있는가
· SE 프로세스 모델 방법의 각 단계는 무엇인가
· 프로세스 모델의 고도로 반복적인 활동의 의미는 무엇인가
· 프로세스 모델의 회귀 특성이란 무엇인가

2. 주요 용어정의

거동 도메인 솔루션(Behavioral Domain Solution) : 기술적인 설계란, 1) 제안된 논리적이고 기능적인 솔루션을 규격으로 나타낸다, 2) 외부 및 내부 인터페이스 정의를 포함한 속성의 논리적, 기능적 능력 상호간의 속성 관계를 기술한다, 3) 규격 요구사항과 논리적, 기능적 능력 상호간의 추적을 제공한다, 4) 다중 레벨 물리적 도메인 솔루션을 물리적 형상 품목(PCI)으로 추적할 수 있다.
반복특성(Iterative Characteristics) : 하나의 속성 설계 솔루션이 성숙해 감에 따라 SE 프로세스 모델의 각 요소 상호간 서로 작용하는 특성을 말한다.
운용 도메인 솔루션(Operations Domain Solution) : 시스템 개발자가 사용자와 획득자와 협력하여 솔루션 영역의 임무목표와 대상 시스템을 안전하게 기지로 회수하기 위해 시스템의 배치, 운용, 지원, 폐기를 어떻게 다루어야 하는지를 나타내는 고유의 시스템 관점을 말한다.
물리적 도메인 솔루션(Physical Domain Solution) : 1) 제안된 물리적 솔루션을 규격으로 나타낸다. 2) 외부 및 내부 인터페이스를 포함한 소위 시스템의 물리적 컴포넌트로 알려진 계층식 물리적 형상품목(PCI) 속성의 상호관계를 제시한다. 3) 규격 요구사항과 PCI 상호간 추적성을 제공한다. 4) 다중 레벨 거동 설계 솔루션과 기능 형상 품목(FCI) 상호간 추적을 제공한다.
회귀특성(Recursive Characteristic) : 시스템의 추상적 레벨과 관계없이 시스템이나 속성에 적용되는 SE 프로세스 모델의 특성을 말한다.
요구사항 도메인 솔루션(Requirements Domain Solution) : 1) 요구사항과 규격서 트리라고 불리는 규격서 계층구조, 2) 요구사항과 능력과의 연계, 3) 규격서와 각 요구사항 상호간 및 사용자 도출, 또는 소스 요구사항에 대한 수직 및 수평적 연계 추적을 나타내는 고유의 시스템 관점을 말한다.
SE 프로세스 모델(SE Process Model) : 다중 레벨 시스템 설계 회귀를 나타내는 고도의 반복과 문제점 해결 솔루션 개발방법에서 도출된 구조를 말한다.
솔루션 도메인(Solution Domain) : 사용자 요구사항 세트를 납품 시스템, 제품, 서비스로 전환 및 적용하는 데 필요한 다중 레벨 속성이나 형상품목(CI) 개발에 대한 요구사항, 운용, 거동, 또는 물리적 관점을 말한다.

SE 프로세스 모델 목표

SE 프로세스 모델의 목표는 사용자의 추상적 운용요구를 물리적 시스템 설계 솔루션으로 전환하고 진화하기 위한 SE를 말한다. 이를 통해 기술, 기법, 비용, 일정 및 지원 솔루션과 위험에 대한 최적 균형을 나타내게 된다.



1. SE 프로세스의 간략한 배경

제2차 세계대전 이후 다양한 SE 프로세스로 발전하기 시작했다. 미국 국방성(DoD), 전기·전자공학회(IEEE), 전자산업협회(EIA), 국제 시스템엔지니어링협회(INCOSE)와 같은 조직에서 일련의 SE 프로세스 모델을 문서화했다. 최근에 발간된 문서로는 미국 육군 FM 770-78, Mil-Std -499, 상용표준 IEEE 1220-1998, EIA-632, ISO/IEC 15288 등이 있다. 이러한 SE 프로세스 방법들은 개발자가 엔지니어링 실무에 기본으로 고려하는 요소로 되어있다.
비록 SE 프로세스가 SE 실무에서 발전해 왔지만, 어떠한 SE 프로세스도 시스템, 제품 또는 서비스에 실무적인 엔지니어링으로 대표된 것은 없다고 본다. 따라서 현 상태에서 시스템 엔지니어와 조직은 그들이 수행해야 할 업무에 대한 SE 프로세스를 스스로 형성하여 적용하려고 한다. 이 장은 여러 사람의 경험에서 확인된 SE 프로세스 모델을 소개한다. 따라서 프로세스와 모델 두 가지 요소를 주목해야 한다.  
개요에서 우리는 사용자의 추상적 운용요구를 물리적 시스템, 제품 또는 서비스 솔루션으로 전환하는 일반적 업무흐름의 과정을 살펴보았다. 이러한 과정을 프로세스라고 할 수 있다. 그러나 엔지니어 시스템에 요구되는 업무흐름 프로세스 단계는 이전 단계로 피드백하는 고도의 반복적인 루프로 형성되어야 한다. SE 프로세스는 단순하게 보면 처음과 끝까지 순차적인 프로세스라고 할 수 있다. SE 프로세스는 입력과 운용제약사항 세트를 납품 가능한 시스템, 제품 또는 서비스로 전환하는 문제 해결/솔루션 개발모델의 내장된 요소라고 할 수 있다. 따라서 우리는 SE 프로세스 모델을 적용하게 된다.

2. 입력 기준

SE 프로세스의 입력 기준은 SE 프로세스를 적용하는 시스템/제품 수명주기 단계에 의해 형성된다. 시스템 개발 단계의 경우, SE 프로세스 모델은 각 속성 또는 형상품목(CI) SE 설계로 시작하게 된다. 여기에는 시스템, 제품, 하부체계, 아셈부리, 부품 레벨을 포함하고 있다.

SE 프로세스 모델 방법론

우리는 앞서 요구사항, 운용, 거동, 물리적 도메인 솔루션으로 구성된 시스템 솔루션 도메인을 살펴보았다. 비록 도메인 솔루션이 여러 속성 중 하나 또는 시스템 특성을 개별적으로 나타내는 하나의 유용한 수단을 제공하지만, 이는 전체적인 시스템 솔루션을 나타내는 데 도움을 주진 않는다. 그러면 우리는 이를 어떻게 해야 하나?
우리는 이를 해결하기 위하여 사용자의 비전을 보다 나은 솔루션으로 전환할 수 있는 시스템 개발 모델을 만들어 간다. 그러나 이러한 도메인 솔루션은 두 가지 중요한 요소를 간과하고 있다.
1) 기회 및 문제영역의 이해와 솔루션 영역의 관계
2) 임무목표를 달성하기 위하여 도메인 솔루션의 최적화
만일 우리가 시스템 솔루션 도메인의 순서에 따라 누락된 요소를 통합한다면, 추상적 레벨과 관계없이 어느 속성에도 적용할 수 있는 방법론을 구상할 수 있다. 이러한 방법론의 단계는 다음과 같다.

· 1단계 : 속성의 기회/문제 및 솔루션 영역을 이해
· 2단계 : 속성의 요구사항 도메인 솔루션 개발
· 3단계 : 속성의 운용 도메인 솔루션 개발
· 4단계 : 속성의 거동 도메인 솔루션 개발
· 5단계 : 속성의 물리적 도메인 솔루션 개발
· 6단계 : 속성의 전반적인 설계 솔루션 평가 및 최적화

우리가 이러한 단계, 초기 순서 및 상관관계를 그래프로 나타내면 그림 1과 같다.



우리는 이를 가리켜 SE 프로세스 모델이라고 부른다.
SE 프로세스 모델을 기술하기 전에 다음과 같은 몇 가지 주요 사항을 논의해 보자.
1) 제품, 하부체계, 아셈부리, 하부 아셈부리, 부품과 같은 논리적·기능적 능력 또는 물리적 품목을 나타내기 위하여 속성이라는 용어를 사용한다. 당신은 컴포넌트라는 용어를 사용할 수 있다. 그러나 물리적 컴포넌트가 설계 프로세스에서 늦게까지 일치되지 않는 예측 곤란한 시스템이어도 된다. 따라서 속성이라는 용어를 사용한다.
2) 문제 영역을 하위 레벨 솔루션 영역으로 분할하는 활동은 SE에서 전통적으로 분할이라고 한다. 이러한 분할은 여러 가지 의미를 지니고 있기 때문에 어떤 사람은 확장이라는 용어를 사용하기도 한다.
3) 대상 모델이 어떠한 추상적 레벨에도 적용되기 때문에 획득자, 사용자, 시스템 개발자와 같은 역할에 따른 용어가 상황적이다. 예를 들면, 시스템 획득자는 시스템 개발자와 계약을 형성한다. 시스템 개발자 입장에서 볼 때, 프로그램 조직에서 획득자 입장에서의 제품레벨 팀은 하부체계를 개발하고 납품한다. 획득자 입장에서 하부체계 개발팀은 시스템 개발자 입장에서 다양한 벤더로부터 하부체계 컴포넌트를 획득해도 좋다.
4) 단순하게 보면 시스템, 제품 또는 서비스의 일회성 획득으로 설명할 수 있다. 복합 시스템 개발 노력은 일련의 나선형식 개발 산출물 또는 계약으로 구성해도 좋다. 이러한 경우에 요구사항은 요구사항을 최종 시스템 개발을 위해 필요 충분한 레벨까지 성숙화하기 위해 초기 불완전한 요구사항을 필요한 단계에 이르기까지 진화해가야 한다. 이리하여 SE 프로세스 모델은 나선형으로 매번 반복을 통해 모든 추상적 레벨을 재적용해 간다. 이러한 접근방법은 시스템 개발에 다른 위험을 감소시켜 준다.

1. 개체의 기회/문제 및 솔루션 영역의 이해

SE 프로세스 모델의 첫 단계는 개체의 기회/문제 및 솔루션 도메인을 단순하게 이해함에 있다. 시스템 분석가와 시스템 엔지니어는 상위레벨 임무목표를 달성하기 위한 개체로 어떤 기대를 할 수 있는가와, 사용자가 시스템을 어떻게 사용하려고 하는지를 이해하고 확인해야 한다. 이를 이해하기 위한 요구는 다음과 같다.
사용자의 레벨 0 시스템이나 납품될 시스템, 제품, 하부체계, 하부 아셈부리, 기타 레벨과 같이 차 상위 레벨 솔루션 영역의 개체 상황적 역할
유스 케이스, 시나리오와 같이 사용자가 시스템을 배치, 운용, 지원 및 폐기하는 방법
인공, 자연 및 유도 환경과 같은 운용환경에서 외부 시스템과의 시스템 인터페이스
시계열 시스템 임무 이벤트(MET) 또는 할당
운용환경에서의 시스템 상호작용을 통해 기대되는 산출물
이러한 산출물을 이행하는 데 필요한 시스템 출력으로 나타나는 제품 및 부산물과 서비스



2. 개체의 요구사항 도메인 솔루션 개발

개체의 기회/문제 및 솔루션 영역에 대한 이해가 성숙해짐에 따라 다음 단계는 요구사항 도메인 솔루션을 개발하는 단계이다. 개체 솔루션 영역을 제시하고 특징을 나타내는 요구사항은 획득자의 시스템 요구능력과 목표기술(SOO) 또는 시스템 성능규격(SPS)으로 문서화된다. 시스템 개발자 프로그램에서 하위 레벨 제품, 하부체계, 아셈부리, 또는 하부 아셈부리 품목개발규격(IDS), 가능하다면 개체에 대한 요구사항을 제시해 준다.
그림 1에 나타난 바와 같이 개체 요구사항 도메인 솔루션은 다음과 같은 역할을 수행한다.

· 운용, 거동 및 물리적 도메인 솔루션을 도출하는 참조 프레임으로 그 역할을 수행한다.
· 기회/문제 및 솔루션 영역에 대한 이해를 반복적으로 수행한다.
· 운용, 거동 및 물리적 도메인 솔루션을 반복 수행한다.
· 상위 레벨 사용자, 시스템, 제품, 아셈부리 등을 통합하고 레벨 요구사항 도메인 솔루션 참조(그림 6 참조).



· 최소한 두 개 또는 그 이상의 하위 레벨 개체 요구사항 도메인 솔루션으로 확장 또는 분할되어도 좋다. 그리고 이는 개발규격으로 문서화 된다.
· 설계 일치 여부를 평가하기 위하여 시스템 설계 솔루션을 평가 및 최적화에 따라 사용되는 의사결정 기준을 제공한다(예를 들면, 검증, 일관성, 추적성).
요구사항 도메인 솔루션은 전형적으로 계약 시스템 성능 규격(SPS)에 포함된 사용자 소스 또는 요구사항 근원으로부터 도출된 요구사항의 계층 세트로 구성된다. 이는 다음과 같은 요구사항을 말한다.

너무 추상적이고 광범위한 경우
적용과 검증이 너무 복잡한 경우, 이는 둘 또는 그 이상으로 하위 레벨 도출 요구사항으로 분할한다.

도출된 요구사항은 보다 명백하게 무엇을 요구하고 있는지 그리고 얼마나 잘 수행하는지를 정의한다. 이리하여 다양한 해석 가능성을 배제하고 다루기에 쉽도록 관리해야 한다. 그 결과로 각 도출 요구사항은 단순화되고 상위 요구사항의 일부분을 충족하기 위해 무엇을 수행해야 하는지를 명료하게 한다.
요구사항이란 최소한 각 개체에 대한 수락을 위해 사용자의 기대를 나타내기 때문에 각 요구사항은 검사, 분석, 데모 또는 시험과 같은 검증 방법을 부여해야 한다. 특정 요구사항을 검증하는 레벨과 검증 조건과 같은 부가적인 검증 기준이 추가되어야 한다. 수락 기준으로 사용되는 검증 방법, 레벨 및 기준에 관한 세트는 개체 규격의 주요 요소로 문서화되어야 한다.

3. 개체 운용 도메인 솔루션 개발

각 개체의 요구사항 도메인 솔루션이 성숙해 감에 따라 시스템 개발자는 운용 도메인 솔루션을 형성하고 숙성해 간다. 운용 개념은 분석되어 개체의 운용개념서(ConOps) 또는 운용이론으로 문서화된다. 운용개념서란 다음과 같다.

· 임무시스템과 지원시스템을 포함한 사용자의 레벨 0 운용 아키텍처를 식별한다.
· 시스템과 연관된 운용환경에서 우호적, 배타적 및 적군 시스템과 위협을 식별한다.
· 임무를 달성하는 데 필요한 시스템 운용 및 업무를 식별한다.
· 임무 이벤트 시계열 또는 할당에 따른 업무를 조화시킨다.
· 임무 산출물을 달성하기 위해 필요한 제품, 부산물 또는 서비스를 식별한다.

그림 1에서와 같이 개체 운용 도메인 솔루션은 다음과 같은 역할을 수행한다.

개체 요구사항 도메인 솔루션으로부터 도출되고 할당된 요구사항에 적용된다.
개체 거동 도메인 솔루션을 도출하면서 입력으로 사용되는 산출물을 문서화한다.
상위 레벨 사용자, 시스템, 제품, 아셈부리, 하부 아셈부리, 운용 도메인 솔루션을 통합한다(그림 6 참조).
최소 두 개 또는 그 이상의 하위 레벨 개체 운용 도메인 솔루션으로 확장 또는 분할된다(그림 6 참조).
완전성, 일관성, 추적성을 위해 요구사항 및 거동 도메인 솔루션으로 반복한다.
시스템 설계 솔루션을 평가와 최적화하기 위해 완전성, 일치성, 성능을 평가한다.

4. 개체 거동 도메인 솔루션 개발

각 개체의 운용 도메인 솔루션이 숙성해감에 따라 시스템 개발자는 거동 도메인 솔루션을 형성하여 성숙해 간다. 거동 도메인 솔루션은 원하는 산출물을 생산하는 데 필요한 업무 또는 순차적 절차를 형성하고 논리적 상호관계를 위해 무엇이 필요한지를 기술한다. 여기에는 다음과 같은 활동이 포함된다.

요구능력을 기능과 성능으로 식별
대상 시스템이 운용환경으로부터 다양한 외적 영향에 대하여 어떻게 반응하는지를 나타내기 위해 시스템 상호관계 및 순서 도표를 형성
MET와 함께 상호관계, 제품, 부산물 및 서비스 조화
요구사항 일치 여부 및 균형된 성능 할당을 확인하기 위해 순차적인 능력과 성능 분석, 모델링 및 반응 분석

그림 1을 참조하여 개체 도메인 솔루션은 다음과 같은 역할을 한다.

· 개체 요구사항 도메인의 요구사항을 할당하고 추적
· 물리적 솔루션 도메인 개발을 위한 입력사항으로서 나타낸 관련 산출물을 문서화
· 상위 레벨 사용자, 시스템, 제품, 아셈부리, 하부 아셈부리 거동 도메인 솔루션을 통합(그림 6 참조)
· 최소 두 개 또는 그 이상의 하위 레벨 개체 거동 도메인 솔루션으로 확장 또는 분할(그림 6 참조)
· 운용 및 물리적 도메인 솔루션으로 반복
· 시스템 설계 솔루션 평가 및 최적화에 의해 일관성, 일치성 및 성능을 평가

5. 물리적 도메인 솔루션 개발

개체 거동 도메인 솔루션이 숙성해 감에 따라 시스템 개발자는 물리적 도메인 솔루션을 형성하고 진화해 간다. 이 솔루션은 거동 도메인 솔루션이 어떻게 다중 레벨 물리적 컴포넌트를 적용해 가는지를 기술한다. 여기에는 다음과 같은 활동을 포함하고 있다.

개체를 위해 다양한 대안 아키텍처를 형성
이미 정의된 의사결정 기준에 따른 각 아키텍처의 장점을 개량화하고 평가하기 위하여 분석과 절충연구를 수행
여러 가지 대안 중 선호 아키텍처를 선정
안전 마진을 보장하는 성과 예산을 설정
아키텍처 내에서 식별된 개체 충족을 위한 컴포넌트 선정
물리적 아키텍처를 아셈부리 도면, 도형, 블록선도, 소프트웨어 설계와 같은 세부 설계로 전환
개체 운용 환경에서 외부 시스템과의 적합성 및 상호운용성 평가

그림 1을 참조하여 각 개체의 물리적 도메인 솔루션은 다음과 같은 역할을 수행한다.

개체 요구사항 도메인으로부터 요구사항을 할당하고 추적
상위 레벨 사용자, 시스템, 제품, 아셈부리, 하부 아셈부리 물리적 도메인 솔루션으로 통합(그림 6 참조)
최소 두 개 또는 그 이상의 하위 레벨 개체 물리적 도메인 솔루션으로 확장 또는 분할(그림 6 참조)
시스템 설계 솔루션 평가와 최적화에 의해 일관성, 일치성, 성능을 평가

6. 개체 전체 설계 솔루션 평가 및 최적화

물리적 도메인 솔루션이 진화하고 숙성해 감에 따라 다음 단계는 시스템 설계 솔루션을 평가하고 최적화하는 단계이다. 이 단계의 목적은 개체 요구사항, 운용, 거동 및 물리적 도메인 솔루션을 검증하고 확인함에 있다.

· 서로 일치하는가.
· 요구사항 도메인 솔루션과 완전히 일치하며 추적 가능한가.

·이러한 목적은 다음과 같은 활동을 통해 달성된다.

· 기술 검토
· 기술 감사
· 시제 개발
· 모델링 및 시뮬레이션
· 개념 입증 또는 기술 데모

다양한 운용 시나리오 및 조건에 대하여 시스템을 최적화할 수 없는 대상 요원을 만나게 되는데 이는 단지 최선의 조건임을 설명하게 된다. 이 두 가지의 차이점을 알아보자.
이미 설정된 운용조건과 우선순위에 대하여 논리적으로 시스템을 최적화할 수 있다. 이러한 조건은 운용환경에서 통계적으로 드물게 나타나고 독립적으로 나타난다. 따라서 시스템 성능의 다양한 변수를 다룰 때 최적으로 나타낸다.
대부분 사람은 자신의 목적을 끌어내리는 경향을 가지고 있다. 그때 실질적 목표가 다르다고 인식하게 된다. 당신이 달성하고자 하는 것은 무엇을 달성하려고 하는가에 달려있다. 따라서 6단계 시스템 설계 솔루션 평가 및 최적화에서와 같이 무엇을 달성하려고 하는지에 관한 최적화를 사용하게 된다.
주어진 목표 달성 성과 이력에서 단순한 최적은 요구하는 최적과 달리 상대적으로 부족한 산출물로 나타나게 된다.

SE 프로세스 모델에 대한 의사결정 지원

분석, 절충연구, 시제, 데모, 모델 및 시뮬레이션 등과 같은 의사결정 지원 실무는 요구사항 도메인 솔루션 일치성과 같은 시스템 솔루션 영역을 구속하는 기술적 의사결정 추천을 제공한다.

출구 기준

SE 프로세스 모델은 고도로 반복적이기 때문에 개발기간 제약에 대한 개체, 출구 기준은 다음 사항에 의해 결정된다.

필요한 개체 설계 및 규격, 설계, 검증절차 등과 같은 요구 문서의 성숙도 레벨
요구사항 규격과 비용 및 일정 제약사항에 관한 검증 데이터 상호간의 불일치를 실무적으로 보완하기 위한 치명도 레벨   

‌산출물과 품질보고서

SE 프로세스 모델은 다양한 시스템·제품 수명주기 단계의 산출물과 품질보고서 개발을 지원한다. 특정 단계 프로세스에 적용할 때, SE 프로세스는 각 개체에 대한 산출물의 네 가지 영역을 다룬다.
1) 요구사항 도메인 솔루션
2) 운용 도메인 솔루션
3) 거동 도메인 솔루션
4) 물리적 도메인 솔루션
산출물과 품질보고서에 관한 일반적인 내용은 규격서, 규격서 트리, 아키텍처, 분석, 절충연구, 도면, 기술보고서, 검증보고서, 회의록 등을 포함하고 있다.
사람들은 SE 프로세스의 목적을 혼동하게 된다. SE 프로세스는 문서 생성을 위해 사용된다고 혼돈하고 있다. SE 프로세스 모델의 목적은 문제점을 해결하기 위한 방법론을 설정하고 기술, 비용, 일정, 테크닉 및 위험요소에 대한 제약 아래 계약 요구사항을 충족시키는 최적의 솔루션을 산출함에 있다. 산출물과 품질보고서는 일차적인 것이 아니라 부수적으로 최종 단계에서 수집되는 프로세스이다. 만일 당신이 문서 생성에 초점을 두고 있다면, 요구사항을 충족 또는 미충족되는 문서와 설계 솔루션을 가질 수 있음을 기억하라!
만일 당신이 SE 프로세스 모델을 사용하여 설계 솔루션을 얻는 데 목적을 지니고 있다면, 그 솔루션의 통합과 확인을 입증하는 문서에 입각한 요구사항을 충족시키는 설계 솔루션에 도달하게 된다.

 SE 프로세스 모델 특징

SE 프로세스 모델은 고도로 반복되고 회귀 되는 특성을 지니고 있다. 이러한 특성을 보다 잘 이해하기 위하여 다음 사항을 살펴보자.

1. 고도의 반복적인 특성
시스템의 추상적 레벨 내에서 특정 개체에 적용되는 SE 프로세스 모델은 그림 2에 나타난 고도의 반복활동으로 특징된다.
방법론에서 각 다중 레벨 단계가 순차적인 업무흐름으로 진행된다면 각 단계는 단계 진행에서 피드백되고 업무흐름에서 불일치 사항이 생길 때마다 해당 사항을 재평가해야 한다. 이러한 피드백 루프에서 그림 3과 같은 고도의 반복 활동을 이행하게 된다.

2. 회귀 특성
그림 2에서 SE 프로세스 모델은 모든 추상적 레벨에서 적용된다는 사실을 주목하라. 우리는 이를 회귀 특성이라고 부른다. 이리하여 시스템 레벨에서의 SE 모델이 하부체계에도 동일하게 적용된다. 이러한 내용을 보다 상세하게 살펴보자.
우리는 그림 3을 그림 4에서와 같이 단순하게 표현할 수 있다.






모든 시스템 개발 프로그램은 시스템 성능 규격서(SPS)로부터 시작되며 모두 네 가지의 솔루션 도메인을 통하여 진화한다.
회색으로 나타낸 사분원과 R은 요구사항, O는 운용, B는 거동, P는 물리적 심볼, 구성된 ROBP는 시스템 설계 실무에서 다루어질 네 가지 솔루션 도메인을 나타내는 아이콘으로 사용된다.

3. 시스템 개발에 SE 프로세스 모델 적용

이제 우리는 그림 5에 나타난 시스템을 대상으로 한다고 가정하자.



이 시스템은 제품 1과 2로 구성되어 있다. 대형복합설계로 구성된 제품 1은 하부체계 1과 2로 되어있다. 단순 설계로 되어있는 제품 2는 하드웨어 형상품목(HWCI) 21과 컴퓨터 소프트웨어 형상품목(CSCI) 21로 구성된다. 우리는 SE 프로세스 모델을 박스로 예시된 각 개체에 적용한다. 각 개체에 SE 프로세스 모델 적용은 SE 설계가 성숙되고 생산으로 준비 완료될 때까지 계속된다. 그림 6은 종료 시 시스템 설계 솔루션 상태를 보여주고 있다.
여기서 우리는 시간에 따른 수평 업무흐름 진행을 나타내는 다중 레벨 구조를 볼 수 있다. 수직적인 요구사항, 운용, 거동 및 물리적 도메인 솔루션은 다양한 추상적 레벨로 분할된다. 그 구조는 그래픽으로 시스템을 나타내며, 정의에 따르면 개별 능력보다 큰 상위 레벨 목적으로 다중 능력 레벨을 통합하고 있다.

시스템 솔루션 전개와 검토

고도의 반복성과 회귀적 특성을 기반으로 시스템 개발자는 SPS로부터 시스템 설계 솔루션이 초기에 완료될 때까지 각 추상적 레벨을 통하여 일련의 업무흐름을 진행하는 시간 축으로 시스템 설계 솔루션을 진화해 간다. 그림 7은 전반적인 시스템 설계 솔루션이 각 추상적 레벨의 도메인 솔루션을 통해 어떻게 진화하여 최종 설계검토(CDR)에 이르는지를 보여주고 있다.



나선형 모형의 내부 루프는 CDR이 수행될 때까지 세부 레벨을 증가해 가는 과정을 그림으로 보여주고 있다. 나선형 모형의 각 루프는 다음 세부 레벨로 진행하기 위한 치명적인 단계 또는 통제 점으로 나타내는 기술검토 활동이다. 각 루프는 이전 레벨의 변경을 처리하고 지속적인 진화와 CDR까지 상위 레벨 솔루션을 성숙해 가는 전환점을 포함하고 있다.
그림 7의 전반적인 상황은 계약에서부터 전체적인 설계 솔루션이 컴포넌트 획득과 개발을 위해 승인되고 적용될 때 수행하는 CDR까지의 기간을 다룬다. 그러나 시스템 설계 솔루션은 초도생산 시스템이나 제품이 통합, 시험, 검증, 확인, 획득자 또는 사용자에 의해 수락될 때 비로소 마무리된다.

지침

앞선 논의 내용에서 SE 프로세스 모델의 적용 원칙을 설정하는 기준을 제시했다.
· 지침 1 : 문제해결 및 솔루션 개발은 최적 설계 솔루션으로 유도함에 달려있다. 유일한 포인트로 나타내는 설계 솔루션은 문제해결 방향을 항상 제시해 주진 않는다.
· 지침 2 : 개체의 설계 솔루션은 요구사항, 운용, 거동, 물리적 등 네 가지 도메인 솔루션으로 구성된다.
· 지침 3 : 업무흐름으로써 시스템 설계는 개체 요구사항을 운용, 거동, 물리적 적용으로 전환함에 있어서 다중 레벨에 걸쳐 고도의 반복적인 활동이다.

요약

이 장에서는 SE 프로세스 모델과 이에 대한 구조를 소개했다. 우리는 이 모델이 모든 추상적 레벨에서 개체 설계에 적용될 수 있는 고도의 반복적 구조로 요구사항, 운용, 거동, 물리적 도메인 솔루션을 어떻게 통합하는지를 기술했다. SE 프로세스 모델의 다중 레벨 적용을 위한 속성은 회귀 특성과 연관되어 있다는 사실을 주목하기 바란다.
모델의 첫 번째 단계는 각 개체에 할당된 요구사항 콘텍스트를 위한 기회/문제 도메인 솔루션 영역을 이해함에 있다. 고도의 반복적인 모델로서 우리는 이 모델이 요구사항 도메인에서 운용 도메인, 거동 도메인, 물리적 도메인으로 어떻게 업무흐름이 진행되는지를 기술했다.
또한, 설계 솔루션이 개체 규격서로 문서화되어 감에 따라 요구사항 할당에 의해 추적 가능해야 하므로 우리는 요구사항 도메인 솔루션이 운용, 거동, 물리적 도메인 솔루션으로 어떻게 연결되는지를 보여주었다.
마지막으로, 모든 설계 솔루션은 평가되고 최적화되어야 하므로 우리는 개체 설계 솔루션 활동의 평가 및 최적화가 운용, 거동, 물리적 도메인 솔루션을 어떻게 지원하는지를 보여주었다. 

1. 일반적 예제

1) 이 장의 개요에서 우리가 이해해야 할 질문에 대하여 한 번 생각해 보아라.
2) 앞 장에서 논의했던 시스템 또는 신규 시스템에 대하여 이 장에서 제시한 내용으로 적용해 보아라. SE 프로세스 모델이 어떻게 다음 사항을 식별함에 있어서 적용되는지를 기술해 보아라.
· 시스템의 기회/문제 영역 및 솔루션 영역
· 요구사항 도메인 솔루션
· 운용 도메인 솔루션
· 거동 도메인 솔루션
· 물리적 도메인 솔루션

2. 조직 중심 예제

1) SE 프로세스 요구사항을 위하여 당신의 조직에 대하여 답해 보아라.
· 조직은 표준 SE 프로세스를 가지고 있는가?
· SE 프로세스 적용을 위하여 잘 훈련된 조직 내에서 SE 활동을 어떻게 하고 있는가?
· 조직의 SE 프로세스와 여기에 기술된 프로세스를 비교해 보라.
· 다분야 시스템 엔지니어를 이 프로세스 적용을 위해 어떻게 훈련하고 있는가?
2) 다년간 사용해 온 다음과 같은 SE 프로세스를 연구해 보라. 각 SE 프로세스를 기록해 보고, 그 차이점을 비교 검토해 보라. 시간이 지나면서 진화적으로 변경됨으로 당신의 경험으로 이를 비교해 보라.
· 미 육군 FM-770-78
· MIL-STD-499
· IEEE 1220-1998
· 국제 시스템엔지니어링 협회 (INCOSE)
· ANSI/EIA 632
3) 당신 조직 내의 기술 프로그램을 선택하고 시스템이나 제품을 개발하기 위해 적용되고 있는 SE 프로세스 또는 방법론에 관해서 구성 요원들을 인터뷰해보라. 그리고 그 결과를 종합해 보라.