시스템 운용 모델


임무 분석을 통해 사용자와 함께 시스템의 유스 케이스와 시나리오를 식별한다. 다음 수행 단계는 사용자와 함께 그들이 어떻게 그 시스템을 배치하고, 운용하며 지원 및 폐기하는지를 개념적으로 제시하여야 한다. 이러한 개념을 문서화하는 메커니즘 중 하나가 시스템 운용개념(ConOps)이다. 이 절은 ConOps를 개발하기 위한 구조를 제공하는 시스템 운용 모델을 소개한다.
시스템 운용 모델은 시스템이 다음과 같은 사항을 어떻게 작용하는지를 나타내는 상위 레벨 운용 업무흐름을 제공한다. 1) 임무영역을 어떻게 나타내는지, 2) 임무를 어떻게 수행하는지, 3) 임무수행 지원을 어떻게 하는지를 모델구조는 요구규격 또는 시스템 엔지니어링 설계 솔루션으로 전환되는 운용과 업무로 구성된다.
우리가 논의해야 할 사항은 모델의 운용 능력이 장비, 인력 및 설비와 같은 시스템 요소로 할당되고 분할되는지를 나타내는 방법을 제공함에 있다. 그 결과로 이러한 논의 사항은 시스템 임무와 지원 운용에 따른 토픽의 기반을 제공해 준다.

1. 이 장에서 얻고자 하는 내용
· 시스템 운용모델은 무엇인가?
· 운용개념은 무엇인가?
· 시스템 운용 모델의 목적은 무엇인가?
· 시스템 운용 모델을 그래프로 나타내 보라.
· 모델 운용이나 업무의 각 요소를 기술해 보라.
· 강건한 버전으로서의 모델의 차이점을 제시해 보라.
· 시스템 운용 사전이란 무엇인가?

2. 주요 용어 정의
· 운용개념 : 성능 목표를 기반으로 한 임무 수행 전, 수행 중, 수행 후 산출물을 달성하기 위해 필요한 시스템 순서 또는 동시적 운용에 따른 업무흐름을 기술한 것을 말한다.
· 통제 또는 단계 전환점 : go-no go 의사결정 기준을 달성할 때까지 목표 기반 운용에 대한 다음 단계 나아가는 업무흐름의 제한을 제시하는 주요 의사결정 포인트를 말한다.
· 시스템 운용 : 임무 수행 전, 수행 중, 수행 후 단계 목표를 충족시키기 위해 기여하는 다중 레벨 또는 의존적인 활동 세트를 말한다.
· 시스템 운용 사전 : 특정 단계와 운용모드를 지원하기 위해 필요한 시스템 속성 운용관계와 상호관계를 기술하고 그 범위를 나타내는 문서를 말한다. 운용관계와 상호관계는 요구운용능력 세트로 분석되고 전환된다. 이는 각 운용모드를 지원하기 위해 시스템 성능 요구사항으로 전환된다.
· 시스템 운용 모델 : 대부분의 시스템에 대하여 업무흐름과 작동 내용을 식별하기 위해 초기 출발점으로 나타낼 수 있는 일반화된 시스템 운용을 말한다.

시스템 운용개념

한번 시스템의 문제점 영역과 솔루션 영역이 주어지고 나면, 다음 단계는 사용자가 어떻게 솔루션 영역 시스템을 사용할 것인지를 이해하는 단계이다. 대부분의 시스템은 기존의 운용, 설비 및 기술 인프라 구조를 바탕으로 새롭게 형성하기 위하여 요구되는 신기술을 적용한다. 그러나 이는 전례가 없는 새로운 시스템이 생성되지 않는다는 것을 뜻하진 안는다. 여기서 전례가 있거나 없는 시스템에 대한 정보는 시스템 정의를 참조하기 바란다.
만일 문제점-솔루션 영역 개념을 더 확장하려면, 우리의 분석을 통해 일반적으로 시스템 운용 모델로 나타낼 수 있는 작동 세트인 속성 관계를 솔루션 영역 시간적인 상호관계를 보면 된다. 따라서 그 모델은 ConOps를 개발하는 구조를 제공한다. 이는 시스템 임무를 달성하기 위해 요구되는 순차적이거나 동시적인 상위레벨 운용을 기술한다.

<예제 1> 우주 셔틀 시스템과 같은 시스템 운용개념은 외계로 페이로드를 운반하고, 배치하며 실험을 수행하고 카고로 돌아와 안전하게 지구로 우주인을 운반해야 하는 운용 순서를 기술한다.

예제 1은 시스템/제품 수명주기에서 사이클 운용을 보여주고 있다. 사람과 같은 살아있는 생명체는 음식, 물, 휴식과 수면이 매일 반복적으로 요구되는 사이클 순환적 특성을 보여주고 있다. 우리는 ConOps를 사용자가 그 시스템을 어떻게 사용할 것인지를 나타내는 다음과 같은 일련의 목표 세트로 보여줄 수 있다.

· 시스템 배치
· 배치하고 운용하기 위해 시스템 사용
· 임무수행 전, 수행 중 및 수행 후 운용을 위한 시스템 준비 점검
· 시스템 자산 적용
· 향후 사용을 위한 청소 및 저장
· 적절한 시기에 시스템 폐기

이러한 목표가 총체적 운용 솔루션으로 통합될 수 있는지를 보다 잘 이해하기 위해 시스템 운용 모델을 살펴보자.

시스템 운용 모델

그림 1에 나타난 시스템 운용 모델은 인공 시스템에 적용될 수 있는 그림을 제시하고 있다. 이 그림에 수많은 요소가 있지만, 어떻게 작동하는지를 더 잘 이해하기 위하여 이 모델을 살펴보자. 첫째, 그래픽에 나타난 용어이다. 

그림 1의 각 박스는 전반적인 임무 목표를 달성하기 위해 필요한 능력과 활동에 근거한 통합된 다중 레벨 시스템 유스 케이스 수집을 나타낸다. 우리는 이러한 능력을 하위 레벨 운용 능력으로 확장하거나 분할할 수 있다. 궁극적으로 이러한 능력과 각 성능레벨은 인력, 장비 및 시설과 같은 하나 또는 그 이상의 시스템 요소로 할당된다.
사다리꼴 모양의 각 의사결정 블록은 통제 또는 단계 전환점이며 이미 결정되어 있는 출구 또는 입구 기준과 함께 관리부서의 go, no-go 결정을 하게 된다. 각 운영 및 통제점은 고유 식별자로 관리된다. 이러한 식별자는 시스템 성능 규격(SPS)이나 운용개념서(OCD)의 세부적인 내용에 포함된 특정 요구사항으로 조정된다.
더 많은 사항을 알아보려면 시스템 성능 규격서에 관한 장에서 ConOps운용 및 능력을 연계시키는 방안을 살펴보기 바란다.
ConOps와 OCD 사용단계를 관찰해 보라. 다양한 부서에서 하나 또는 다른 항목으로 이를 다룬다. 어느 사람에게는 ConOps가 시스템이 어떻게 운용될 것인지를 요약해서 사용하는 한편, OCD는 ConOps의 세항으로 지원하고 있다고 생각한다. 이 중 하나를 선택하여 이를 프로그램 전반에 걸쳐 지속적으로 적용토록 하라.

시스템 운용 모델 기술

그림 1은 대부분의 인공 시스템에 적용되는 시스템 운용 모델을 나타내고 있다. 모델 진입은 시스템/제품 수명주기의 시스템 개발단계(1)로부터 전환될 때 시작한다. 입구기준(2)은 실 임무를 시작하기 위해 시스템 준비 상태를 점검한다. 다음 진행단계를 세부적으로 살펴보자.

1. 작동 3.0 : 시스템 배치
시스템 배치를 위한 작동 3.0은 사용자 요구 장소에 따라 시스템을 운반하고 설치하기 위해 필요한 시스템의 능력과 활동을 말한다. 각 시스템이 생상라인을 지나 성능 요구사항 확인이 이루어지고 나면, 그 시스템은 사용자에게 보내지기 위해 포장되고 운송된다. 이러한 활동으로서는 운송, 싣고 내리고, 포장하고 풀고, 초기 셋업, 설치, 조립하는 일과 상위 레벨 통합을 통한 검증 및 그 레벨에서의 상호운용성 검증이 있다.
작동 3.0의 모든 계획된 일들이 끝나고 나면, 작동 4.0은 시스템/임무 교육훈련 의사결정 단계로 넘어간다.

2. 작동 4.0 : 시스템/임무 교육훈련 의사결정 수행
시스템/임무 교육훈련의 의사결정 통제점은 시스템 배치 즉시 실 임무를 수행하거나 운용자 교육훈련 또는 데모를 위해 대기토록 한다.

· 시스템/임무 교육훈련 의사결정이 yes 또는 true로 나타나면, 업무흐름은 작동 17.0 시스템 교육훈련 수행으로 진행된다.
· 시스템/임무 교육훈련 의사결정이 no 또는 false로 나타나면, 업무흐름은 작동 5.0 임무경고 대기 의사결정으로 진행된다.

3. 작동 5.0 : 임무경고 의사결정
임무경고를 위한 의사결정 통제점은 임무수행 준비를 위해 기다려야 한다. 시스템과 애플리케이션에 따라 작동 4.0과 5.0은 상위 레벨 부서에서 임무수행 지시가 이루어질 때까지 순환적인 시스템 대기상태가 효과적으로 이루어져야 한다.

· 임무경고 의사결정이 yes 또는 true로 나타나면, 업무흐름은 작동 6.0 임무 시스템 적용으로 진행된다.
· 시스템/임무 교육훈련 의사결정이 no 또는 false로 나타나면, 업무흐름은 작동 4.0 시스템/임무 교육훈련 수행 의사결정으로 되돌아간다.

4. 작동 6.0 : 임무 시스템 적용
임무 시스템 적용은 요구된 임무를 시스템에서 수행하기 위하여 준비하고 적용하는 시스템 능력과 활동을 포함하고 있다.
임무지시가 있으면, 그 시스템은 임무를 수행하기 위해 적용되고 지원된다. 작동 활동에는 임무수행 전 활동계획, 물리적인 하드웨어와 소프트웨어 변경, 개인 교육훈련 및 연료 재공급이 이루어진다. 시스템 적용과 해제 활동은 다음과 같은 시스템 요소의 조화를 위한 동기화에 달려있다.

① 인력 : 운용자, 관리자 등
② 절차수행 데이터 : 운용절차, 미디어 등
③ 인공 시스템 인터페이스 : 우호적, 협력적인 시스템
④ 지원시스템 : 할당된 임무 활동과 목표를 달성하기 위해 미리 계획되고 동시적 운용에 초점을 둔 미디어, 교관, 공급자 유지보수자 등

이러한 활동이 종료되고 나면, 시스템이 다음과 같이 임무 적용이 적합한지를 보는 시스템 검증활동이 이루어진다.

· 시스템 검증이 성공적이면, 업무흐름은 작동 7.0 작동임무 준비평가 단계로 넘어간다.
· 시스템 결함이나 오작동이 발생되면, 업무흐름은 작동 20.0 시스템 정비 수행단계로 넘어간다.

5. 작동 7.0 : 작동임무 준비평가
작동임무 준비평가에는 부여된 임무를 수행하기 위하여 전반적인 준비상태를 검토하기 위한 시스템 능력과 활동을 포함하고 있다. 시스템이 그 임무를 적용해보고 모든 시스템 요소 자원이 전체적으로 잘 통합되고 작동 가능한 후에 임무작동 준비 상태가 평가된다. 이러한 평가에는 부여된 임무를 수행하기 위하여 장비, 인력 및 설비와 같은 시스템 요소 통합 세트에 대한 준비상태를 평가한다.
만일 준비평가가 no이라면, 그 시스템은 빨강 또는 노란 태그로 작동상의 결함을 표시한다. 임무영향 위험 평가 의사결정은 임무중지 보증 결함이나 백업 시스템으로 시스템/요소 교체를 결정하기 위해 수행된다.

· 시스템의 유지보수가 요구되면, 업무흐름은 작동 20.0 시스템 유지보수 수행단계로 넘어간다.
· 임무 지원을 위해 필요한 능력을 제공하기로 한다면, 업무흐름은 작동 9.0 임무전진 단계 대기로 넘어간다.

이 장의 후속적인 논의를 위해 작동 8.0, 11.0, 12.0 및 19.0이 그림 1에는 사용되지 않고 있으며, 이는 다음 토픽에서 다루어진다.

6. 작동 9.0 : 임무 전진 의사결정
임무전진 의사결정 통제점은 다음과 같은 임무수행 지시가 있을 때 일어난다.

· 작동 9.0 임무전진 의사결정이 yes 또는 true이라면, 업무흐름은 작동 10.0 임무수행으로 넘어간다.
· 작동 9.0 임무전진 의사결정이 no 또는 false이라면, 시스템 준비상태를 주기적으로 체크하여 작동 7.0 운용임무 준비평가 단계로 돌아간다.

7. 작동 10.0 : 시스템 임무수행
시스템 임무수행은 그 시스템의 일차 및 이차 임무를 수행하기 위하여 필요한 시스템 능력과 활동을 포함한다. 이러한 활동 중에 그 시스템은 일차 및 이차 시스템 임무 목표를 수행함에 따라 위협과 기회를 함께 가져온다.
만일 시스템 임무 수행 중에 유지보수가 필요하면, 작동 16.0 시스템 자원 보충이나 작동 20.0 시스템 유지보수 수행 단계가 실제적으로 이루어진다.

<예 2> 전투기는 운용임무를 수행하는 기간 중에 연료보충을 필요로 한다.

임무 종료 후, 업무흐름은 작동 13.0 임무 및 시스템 성능 평가 단계로 진입한다.

8. 작동 13.0 : 임무 및 시스템 성능 평가
임무 및 시스템 성능 평가는 성공적인 일차 및 이차 목표와 시스템 성능 기여에 기준한 임무 성공 레벨을 검토하기 위해 필요한 시스템 능력과 활동을 포함한다.
활동은 임무수행 이후 데이터, 목표영향평가, 강점 및 약점, 위협, 임무관측 및 교훈, 임무충족 사항이다. 이러한 작동은 사람의 성과, 임무수행에 따른 강점과 약점을 검토하는 기회를 제공해 준다. 작동 13.0 임무시스템 성능평가 단계 종료 후, 업무흐름은 작동 14.0 시스템 수행중지 여부를 결정하게 된다.

9. 작동 14.0 : 임무수행 중지 여부 결정
임무수행 중지 여부 결정 통제점은 그 시스템이 계속해서 현재 작동을 계속한다면, 업그레이드하거나, 실 작동을 중지하는지 여부를 결정해야 한다. 이러한 의사결정은 그 시스템에 설정되어 있는 출구기준(15)에 따른다.

· 시스템 폐기 상태가 yes 또는 true라면, 업무흐름은 작동 21.0 시스템 폐기 상태로 넘어간다.
· 시스템 폐기 상태가 no 또는 false라면, 업무흐름은 작동 16.0 시스템 자원보충 상태로 넘어간다.

10. 작동 16.0 : 시스템 자원보충
시스템 자원보충 단계는 인력, 연료 및 공급품목과 같은 시스템 자원을 보충하거나 재충전에 필요한 시스템 능력과 활동을 포함한다. 만일 결핍이 그 시스템에 나타난다면, 그 시스템은 작동 20.0 시스템 유지보수 단계로 넘어간다. 작동 16.0 시스템 자원보충이 종료되면, 업무흐름은 작동 18.0 시스템 재배치 의사결정 단계로 넘어간다.

11. 작동 17.0 : 시스템/임무 교육훈련 수행
시스템 교육훈련 수행은 사용자나 시스템 운용자가 어떻게 그 시스템을 잘 사용할 수 있을 것인지에 대한 능력과 활동을 포함한다. 대형복합 시스템의 경우, 초기 운용교육이 야전으로 대상 시스템을 배치하기 전, 시스템 개발자 기관에서 때때로 수행되고 있다. 시스템이 이미 야전에 투입된 후에 예방조치 기술교육이 수행되기도 한다.
작동 17.0 시스템 교육훈련 수행 기간 중에 신규 시스템 운용자가 그 시스템에 대하여 안전하고 적절한 사용교육이 이루어져야 한다. 경험이 있는 운용자는 경쟁위협에 따른 이전 임무 또는 신규 전술로부터 얻어진 교훈에 부가하여 예방조치, 숙련도 또는 스킬을 습득해도 좋다.
교육훈련이 종료되고 나면, 업무흐름은 작동 16.0 시스템 자원보충 단계로 넘어간다. 만일 시스템이 훈련 도중에 유지보수가 필요하다면, 작동 20.0 시스템 유지보수 활동이 수행된다.

12. 작동 18.0 : 시스템 재배치 의사결정
시스템 재배치를 위한 의사결정 통제점은 조직적 임무목표를 지원하기 위하여 신규 사용자 지점에 그 물리적 시스템의 재배치 여부를 결정하게 된다.

· 만일 작동 18.0 시스템 재배치 단계가 yes 또는 true로 나타난다면, 업무흐름은 그 시스템을 배치하는 작동 3.0 단계로 돌아간다.
· 만일 작동 18.0 시스템 재배치 단계가 no 또는 false로 나타난다면, 업무흐름은 작동 4.0 시스템/임무 교육훈련 의사결정 수행단계로 넘어가고 작동 18.0 시스템 재배치 단계로 반복적으로 돌아간다.

13. 작동 20.0 : 시스템 유지보수 수행
시스템 유지보수 수행은 예방 또는 수시 유지보수 활동을 통해 시스템 결함을 수정하거나 시스템 능력을 업그레이드하기 위하여 필요한 시스템 능력과 활동을 포함한다. 시스템은 임무수행에 영향을 주는 고장이나 결함을 수정하기 위해 필요한 수시 또는 예방정비 활동을 표시하기 위하여 빨강 또는 노랑과 같은 쉽게 인식 가능한 칼라 인식표를 달아둔다.
성공적인 시스템 유지보수가 종료된 후에 그 시스템은 실 임무상태로 돌아가고 유지보수 요구가 제기되기 전까지 다음 단계인 작동 6.0 시스템 임무적용, 작동 7.0 운용임무 준비평가, 작동 10.0 임무수행, 작동 16.0 시스템 자원보충이나 작동 17.0 시스템/임무 교육훈련 수행 단계로 넘어간다.

14. 작동 21.0 : 폐기 시스템
폐기 시스템은 시스템을 실 임무수행에서 제외시켜 시스템을 저장 및 창고에 보관하거나 이를 분해하여 각 컴포넌트와 요소를 적절하게 폐기하기 위해 필요한 시스템 능력과 활동을 포함한다. 몇몇 시스템은 향후 기존 시스템으로 지원 불가능한 임무수행에 필요할 때까지 저장해 둔다. 활동을 중지한 상태에서 그 시스템은 시스템 수명주기의 폐기단계(22)로 넘어간다.

15. 시스템 운용 사전
팀이 운용개념을 그래프로 나타내도록 동의하는 것이 일차적인 단계이다. 대형복합 시스템 개발 팀일 경우, 이 레벨에서의 도표는 팀원들 상호간에 적절한 이해를 돕기 위해 각 성과에 대한 정의를 제시할 필요가 있다. 예를 들면, 당신과 당신 팀은 시스템 적용환경에 따라 다른 비즈니스 도메인 운용팀으로부터 상이한 특정 운용능력을 정의할 필요가 있다.
한 가지 해결 방법은 시스템 운용 사전을 만드는 것이다. 이전 시스템 운용 모델로 기술된 것과 유사한 각 능력을 정의하고 범위를 설정한 사전을 시스템 수명주기 전반을 통해 유지하는 길이다.

16. 최종 정리
시스템 운용 모델은 시스템, 제품, 조직, 서비스 등을 정의하기 위해 사용된다. 우리는 자동차, 우주선, 항공라인, 병원, 비즈니스, 소방 및 구급차 서비스와 같은 모든 인공 시스템에 대하여 초기 시작점으로서 이 모델을 적용할 수 있다.
각 모델의 운용은 개별적 또는 종합적으로 대부분의 시스템에 적합한 일반적인 모습을 제시해 주고 있다. 시스템 엔지니어로서, 계약, 규정상의 요구사항에 대한 제약범위 내에서 그 필요성을 반영하고 있는 시스템 운용 모델을 테일러링하기 위하여 사용자와 협력해야 한다. 각 운용활동은 시스템 운용 사전에 의해 범주와 제약사항을 제시해야 한다. 이는 모든 획득자와 사용자 요원과 시스템 개발팀 요원이 함께 이해함으로써 특정 운용활동의 포함 여부를 분명하게 제시해야 한다. 이는 나중에 가서 혼선을 예방하는 길이다.
개인적인 관점에서 시스템 운용 모델은 매우 간단하게 나타난다. 그러나 자세히 들여다보면 단순한 시스템이라 할지라도 작동순서를 적합하게 정의하기 위하여 앞을 내다보아야 한다. 이를 확인하려면 다음과 같은 사항을 고려해야 한다.

· 자동차와 운전자 상호간의 시스템 운용 모델을 생각해 보라.
· 그리고 유사한 경우에 대하여 운용 모델에 익숙지 않은 세 사람의 동료에게 이를 수행해 보라. 다양한 동료의 의견을 만나게 될 것이다.
· 최종 도표를 얻기 위하여 팀을 구성하여 간단하고 협조적인 결과에 초점을 두고 이를 반복해 보라.

이제 더 많은 이해관계자가 존재하는 보다 복잡한 시스템 정의를 요구하는 시스템 운용 모델 경우를 생각해 보자. 만일 이전의 자동차와 운전자 경우를 생각해 보면, 특정 시스템에 대한 시스템 운용 모델에 동의상태에 도달하기 위하여 다양한 분야의 입장, 정치적 상황, 그리고 조직부서의 다양한 사람들로부터 함께 논의해야 한다.
당신은 엔지니어들이 시스템 운용 모델을 ‘교과서적인 재료’를 바탕으로 만들고 있다는 사실을 알게 될 것이다.

① 그들은 이러한 개념을 만들기 위해 필요한 시간을 투입하게 된다.
② 그들은 레지스터, 케페시터, 데이터 사용률, C++언어 및 운용 시스템과 같은 물리적 하드웨어와 소프트웨어 설계에 즉응적인 자연스러운 경향을 지니고 있다.
③ 그들은 레지스터, 코딩 등 시간적인 초점을 둔 필요성에 대한 관리를 이행한다.

17. 주의
만일 당신의 프로그램, 고객 및 사용자 커뮤니티가 이러한 최상위 레벨 개념과 하위 레벨 분할을 동의하지 않는다면, 시스템 개발 문제점을 더 이상 아래로 내려가기 전에 기본 개념과 이를 맞추어 보아야 할 것이다.
가장 나쁜 경우, 의도하는 목적에 대하여 고객의 확인활동이 되지 않은 시스템을 야전에 배치했을 때 기술적인 문제뿐만 아니라 회사조직의 평판이 어려워지는 환경에 처하게 될 것이다.

· 획득자와 사용자 커뮤니티의 동의를 구하도록 하여라. 그리고 시스템 개발을 위해 필요한 자원을 투입토록 하여라. 조직의 임무목표를 달성하기 위하여 계획된 시스템을 어떻게 운용할 것인지를 살펴보라. 이와 같은 의사결정이 승인되고 하드웨어와 소프트웨어 규격으로 분할되며 할당될 때까지 미 성숙된 하드웨어와 소프트웨어 개발노력을 피하도록 하여라.
· 시스템 운용 모델을 시스템 성능규격(SPS) 요구사항으로 전환될 수 있는 운용 능력을 식별하고 규정하기 위한 인프라 구조로 사용토록 하여라.
· 다른 사람에 의해 준비된 규격서를 검토하고 분석할 때, 시스템 운용에 대한 완전성을 검토하고 상위 레벨 시스템 성능 요구사항을 평가하기 위해 시스템 운용 모델을 사용하라.

더욱 강건한 시스템 운용 모델 개발방안

앞에서 논의된 시스템 운용 모델은 시스템이 운용자에게 어떻게 적용되는지를 이해하기 위한 기초를 제공해 주었다. 상위 레벨 모델일수록 보다 유용한 논리적 목적을 제시해 준다. 그러나 그 모델은 광범위한 시스템 애플리케이션을 수용하기 위해 보강될 필요가 있는 몇 가지 분야를 지니고 있다. 그림 2는 확장된 시스템 운용 모델을 보여주고 있다. 이전 모델과 연장선상에서 살펴보기 위해 같은 숫자를 사용하면서 몇 가지 다음과 같은 작동 순서를 첨가하였다.

· 작동 8.0 : 임무준비 의사결정
· 작동 11.0 : 임무 전반과 지원 제공
· 작동 12.0 : 임무종료 의사결정
· 작동 19.0 : 사이트 복원 및 보완

일반적인 시스템 운용모델의 중요성

시스템 운용 모델은 시간에 따른 일정계획에 맞추어 시스템의 통합성을 이루는 상위 레벨 구조로 사용된다. 모델에서의 작동은 시스템 요소(장비, 인력, 설비 등)의 하나 이상 요소로 수행된다. 시스템 요소에 이러한 작동을 연계시키는 것은 다음 여러 가지 관점에서 유익하다.

1. 규격서 개발 관점
규격서 개발 관점에서의 시스템 운용 모델 형성은 시스템 요구사항을 알아내고 체계화하며 결정하기 위하여 고객과 사용자가 함께 협조하기 위한 인프라 구조를 제공해 준다. 이러한 인프라 구조로부터 분할되고 도출되는 운용능력과 성능은 시스템 또는 하위 레벨 규격서를 형성하는 텍스트 요구사항으로 전환될 수 있다.
운용 능력을 규격서 요구사항으로 전환하기 위한 보다 많은 정보는 규격서 개발 프락티스를 별도로 참조하기 바란다.

2. 규격서 분석가 관점
시스템 분석가 관점에서의 시스템 운용 모델 형성은 특정한 요구 작동에 대하여 기존 규격서 요구사항으로 나타내기 위한 하나의 인프라 구조로 사용될 수 있다. 만일 각 시스템 운용 모델 작동이 하위 작동 계층 레벨로 분할된다면, 시스템 분석가는 누락된 요구사항을 발견하거나 그 필요성을 명료하게 하는데 사용될 수 있다.
시스템(제품, 조직, 서비스 등)을 개발하는 사람들과 잘 훈련된 시스템 엔지니어는 그 시스템이 어떻게 사용될 것인지에 대한 시스템 능력, 거동, 성능에 관하여 획득자와 사용자의 기대사항을 알아내는 것이 매우 중요하다는 사실을 이해하고 함께 노력해야 한다.
추상적인 상위 레벨 시스템으로서의 시스템 운용 모델은 그 시스템이 상위 레벨에서 어떻게 사용될 것인지에 대한 사항을 정의한 상위 레벨 인프라 구조로 활용된다. 이러한 모델을 하나의 기본 구조로 사용함으로써 시스템 운용능력과 성능이 쉽게 정해질 수 있다. 시스템 운용분석은 우리로 하여금 시스템 수명주기 작동에 대한 각 요소를 지속적으로 하나의 특정 시스템 능력, 거동 및 성능으로 나타내는 하위 레벨 업무와 활동으로 분할해 갈 수 있도록 해준다.
규격서 작성자로 훈련된 많은 사람들은 절대적으로 작동 10.0 임무수행에 초점을 둔다. 잘 못되는 경우가 있다 할지라도, 그들은 작동 10.0에 대한 시스템 형태를 정함에 따라 형태를 근거로 한 접근방법을 활용한다. 전기, 기계, 소프트웨어 전문가들에 의해 만들어진 인공 시스템에 종사하는 엔지니어들은 그들이 잘 알고 있는 익숙한 물리적 시스템 하드웨어와 소프트웨어 요구사항과 솔루션으로 구성된 ‘comfort zone’에 초점을 두고 있다.
그 결과 가끔 그 규격서는 작동 3.0, 13.0, 16.0에서 19.0에 이르는 임무 요구사항이 잘 반영되지 않은 상태로 완결된 요구사항 범주를 제시하기 쉽다. 작동 10.0 임무수행 내에서도 이러한 작성자는 유스 케이스와 시나리오를 사용할 때 시스템 단계, 모드 및 상태를 고려하지 않고 특정 물리적 형태에만 초점을 두고 있다. 그 결과, 수많은 요구사항이 누락되거나 잘 못 제시된다.

① 앞서 제시된 주의사항을 반영하기 위하여, 표준 시스템 규격서를 제시하고 규격서 작성자로 하여금 설계 및 제작 제약사항과 같은 영역에서 최소한의 누락된 단계(작동 3.0-13.0 및 16.0-19.0)만이라도 고려할 수 있도록 구 표준 MIL-STD-490A에서 제시하고 있다.
② 우리의 경험에서 유능한 시스템 엔지니어는 시스템 운용 모델이나 시스템 애플리케이션과 사용자 필요성을 별도로 테일러링한 버전을 사용하여 먼저 시스템 분석 작업을 시작한다. 바로 이러한 활동이 시스템 엔지니어로서의 훈련과 성숙레벨을 나타내는 지수로 사용된다. 시스템 운용 모델 적용은 당신으로 하여금 프로그램의 직책과 연계된 위험 레벨을 감수하기 위해 적합한 시스템 엔지니어를 가려내는 데 사용될 수 있다.

기본원칙

앞에서 논의된 사항을 요약해 보면 시스템 운용 모델 개발과 연관된 기본원칙을 수립하는데 기초를 제공해 주고 있다.

· 원칙 1 : 모든 인공 시스템은 사용자가 원하는 임무 시스템을 어떻게 배치, 운용, 지원 및 폐기하는지를 나타내는 고유의 시스템 운용 모델을 가지고 있다.
· 원칙 2 : 각 임무 시스템 작동이나 업무 그리고 지원 시스템 요소는 단계별 성과를 달성하기 위하여 가치를 주거나 기여를 하고 있다. 만일 아니라면, 이를 폐기하여야 한다.
· 원칙 3 : 모든 시스템 운용 모델 작동이나 업무는 성과를 기반으로 한 임무 이벤트 시계열(MET)로 조정하라.
· 원칙 4 : 모든 시스템 운용 모델 작동이나 업무는 시스템 유스 케이스를 활용한다. 각 유스 케이스는 하나 또는 그 이상의 일어날 수 있는 운용환경 시나리오를 고려하여 정의된 산출물을 가져다주는 능력을 나타낸다.

요약

앞에서 논의된 사항은 사용자가 어떻게 그 시스템을 사용하는지에 대한 논리적이고 개념적인 관점을 나타내고 있다. 작동은 외형적인 시스템 레벨 능력과 성능 요구사항으로 전환될 수 있다. 이러한 요구사항은 궁극적으로 장비, 인력, 설비 등 시스템 요소로 할당될 수 있다. 다음에서 논의될 내용은 매우 큰 레벨의 작동을 세부적인 시스템 단계, 모드, 상태로 분할하게 된다. 우리는 ConOps 운용 업무를 지원하기 위하여 각 시스템 요소에 요구된 시스템 능력과 성능을 보다 구체적으로 제시하고 명료하게 제한하게 될 것이다.
일찍이 살펴본 바와 같이 모든 시스템에 대하여 고려되는 애플리케이션을 예시하는 것은 바람직하지 않다. 앞에서 논의된 모든 사항은 당신의 사고하는 프로세스를 도와주는 기본적인 절차를 제공하고, 나아가 당신 스스로 이러한 접근방법을 당시 자신의 비즈니스 도메인 시스템에 적요할 수 있도록 도와준다.

1. 일반적 예제
① 개요에서 제시된 이 장에서 무엇을 배울 것인가에 대한 답을 해보라.
② 앞서 생각해 보았던 시스템이나 또는 새로운 시스템을 선정하여 본 장에서 제시된 내용을 다음과 같이 적용해 보라.

· 무슨 작동을 부여해야 하는지를 선정된 시스템에 대하여 시스템 운용 모델로 제시해 보라.
· 그 모델에 포함되지 않은 작동을 그 시스템에서 요구하고 있는가?
· 시작점에서 시스템 운용 모델을 사용하여 그 시스템과 애플리케이션을 그 모델에 적용할 수 있는지 테일러링해 보라.
· 각 유스 케이스를 시스템 운용 모델 작동으로 맞추어 보라. 유스 케이스로 제시되지 않은 작동에 대하여 유스 케이스 세트가 부족한가를 살펴보라. 만일 사용자가 자원의 제약사항이 없다면 사용자의 부족사항을 어떻게 제시할 수 있는가?

2. 조직 중심 예제
① 당신 조직에서의 시스템 운용개념(ConOps)이나 운용개념서(OCD) 개발을 위한 지침이나 규정에 관한 사항을 살펴보라.

· 무슨 요구사항이 ConOps 또는 OCD 개발 사항으로 제시되어 있는가?
· 언제 이러한 문서가 작성되도록 요구되어 있는가?

② 당시 조직에서 소형, 중형 및 대형 계약 프로그램을 살펴보라.

· 그 계약은 ConOps 또는 OCD를 개발하도록 요구되어 있는가?
· 그 프로그램은 ConOps 또는 OCD를 가지고 있는가? 만일 없다면, 그 이유는?
· 그렇다면 이러한 ConOps 또는 OCD가 그 프로그램에 어떠한 유익을 가져다주고 있는가?
· ConOps 또는 OCD 개발에 기초하여 다음 프로그램을 할 경우 어떻게 달리 접근하고자 하는가?

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