시스템 문제, 기회 및 해결 영역


문제 영역과 해결 영역을 식별한다는 개념은 가끔 골치 아픈 어휘를 듣는 것과 같다. 그럴듯하지 않은가! 방관자를 모집하자는 것인가! 그러나 만일 당신이 같은 사람에게 해결 영역과 문제점 영역의 차이점을 말해 보라고 하면, 당신은 눈을 깜박거린다든지 또는 머리를 긁으면서 생각할 것이다.
대부분 성공적인 임무는 문제점, 기회 및 해결에 대한 철저한 식별과 이해로서 가능하다. 한 시스템의 문제점 영역은 다른 시스템의 기회 영역이자 약점을 자산화하기를 원하는 바로 그 시점이다.
이 글은 이러한 문제/기회 영역과 이를 해결하는 해결 영역에 관한 개념을 살펴봄에 있다. 자신의 조직에 대한 임무와 역할을 이해하고 나면, 첫 번째 단계는 무엇이 이 조직의 문제점인지를 알고 이를 어떻게 해결할 것인가를 고민하게 된다. 사람들은 시스템 요구사항을 분석하는데 초점을 두고 있지만, 성공적인 시스템 분석, 설계 및 개발은 사용자의 문제/기회 및 해결 영역을 보다 잘 식별하고 이해함에 있다. 가장 나쁜 경우는 잘못된 문제점에 대하여 완전한 요구사항을 작성함에 있다.
이제 문제 영역에 대한 전반적인 개요와 문제점을 기술하는 방법을 알아보자. 계속해서 해결 영역에 대한 전반적인 개요와 문제 영역과의 관계를 생각해 보자. 지형적인 콘텍스트로 해결 영역을 잘못 이해해 왔음을 알아내자. 해결 영역이 능력 기반이긴 하지만 수혜자 능력이 힘의 승수로 크게 확장되거나 예상되는 다른 시스템 능력에 의존할 수 있다. 이는 곧 영향에 대한 원구(Sphere of influence)라고 할 수 있다.

1. 얻고자 하는 내용
· 문제 영역이란 무엇인가?
· 기회 영역이란 무엇인가?
· 문제 영역과 기회 영역의 상호관계는 무엇인가?
· 해결 영역은 무엇인가?
· 문제/기회 영영과 해결 영역의 상호관계는 무엇인가?
· 문제점을 어떻게 기술하는가?
· 문제점을 기술함에 있어서 세 가지 법칙을 식별하라.
· 문제/기회 영역을 어떻게 예측하는가?
· 한 조직에서 문제 영역과 해결 영역 상호 간 갭을 어떻게 풀 수 있는가?

2. 주요 용어 정의
· 기회 영역 : 다음과 같은 기회를 나타내는 시스템, 제품, 또는 서비스 능력에서의 갭과 취약점을 가리킨다. 1) 경쟁자 또는 반대자, 2) 해결해 주는 공급자
· 문제 영역 : 기존 능력에 위협이나 갭을 가져다주는 시스템 운용환경이나 임무 영역 내에서의 추상적인 생각을 말한다. 잠재된 위협은 재정, 보안, 안전, 보건, 또는 감정이나 사용자에게 줄 위험으로 나타나거나 이미 조직과 성취에 부정적인 영향을 주고 있는 경우를 말한다. 하나 또는 그 이상의 하위 레벨 해결 영역에서 시스템, 제품, 또는 서비스로 이 문제를 해결해 준다.
· 문제점 기술 : 문제를 해결하기 위해 요구된 소스나 활동을 모르고 있는 상태에서 원하지 않는 내용을 분명하게 기술하는 간략하고 정확하게 그 내용을 기술한다.
· 상황 평가 : 앞서 조직의 역할, 임무 및 시스템 적용에 대한 장을 참조하라.
· 해결 영역 : 상위 레벨 문제 영역의 모두 또는 일부분을 충족시키기 위한 능력과 성능 레벨을 나타내는 구속된 추상적 개념을 말한다.

운용환경 기회

조직 관점에서의 인공 시스템은 기회를 만들고 위협도 함께 가져온다. 조직은 회사 설립자나 경영자의 위협을 완화시키거나 기회를 자산화하는 비전을 달성하기 위해 재정, 시장 배당, 의료 혜택과 같은 임무와 성과 목표를 부여한다.
생존 기회와 위협 제거는 운용환경 측면에서 동일하다. 사고 방법에 따라 이를 ‘시스템의 자연적인 순서’라고 본다. 아프리카 평원에 있는 동물 천국은 한 예제이다. 한 동물의 염원, 곧 기회가 위협에서 탈출이라는 기도로 생각할 수 있다. 다음 예제를 살펴보자. <예제 1> 하나의 공격 집단에서 창업 비즈니스를 창업회사의 약점을 착취하거나 자산화할 수 있는 기회로써 구상한다고 하자. 차례로 더 큰 회사는 생존 위협으로 창업 비즈니스를 생각하게 된다.

1. 시스템 기회 유형
일반적으로 기회는 ① 시간 중심(적확한 대기 시간)과 ② 위치 중심(대여 장소 대기) 두 가지 기본 유형을 하고 있다.

① 시간 중심 기회 : 시간 중심 기회는 가끔 또는 주기적으로 발생할 수 있다. 불시에 나타나는 기회는 가끔 ‘요행’이라고 부른다. 주기적으로 나타나는 기회는 도전 시스템이 취약 상태에서 자산화할 수 있도록 주기적이거나 반복적인 거동 형태로 나타난다.
② 위치 중심 기회 : 그 이름에서 나타나듯이 위치 중심 기회란 적기에 적소에서 시작한다는 말이다. 성공적인 비즈니스 세계에서 ‘위치, 위치, 위치’라고 소리 지른다. 분명히 좋은 위치만 가지고 성공할 수는 없다. 그러나 위치는 성공적인 임무수행에 비즈니스를 정해 준다.

문제 영역

시스템 엔지니어링의 첫 단계는 사용자가 해결하고자 하는 문제가 무엇인지를 식별함에 있다. 문제 영역이란 이러한 관점에서 매우 실제적이다. 상용시장이나 군사장비 방산업체 간에 경쟁을 유발하라. 한 조직이 문제 영역으로서 경쟁자 관점이나 그들의 운용 도메인을 제시해도 좋다. 이론적으로 경쟁자나 반대자에게 물어본다면 그들 자신이 문제를 가지고 있을 경우, 그들 답변의 ‘예’ 또는 ‘아니요’에 대한 신뢰성이 떨어진다. 따라서 문제 영역의 콘텍스트 그들의 상황을 이해하고 있는 자들의 마음과 생각에 달려 있다. 때로 한 국가의 공역 침범이나 경쟁회사 비즈니스 인수와 같은 피아 행동에 대한 결정적인 증거에 의심을 갖지 않는 경우도 많다.
문제라는 영역에 두 가지 콘텍스트가 있다. ① 사용자-획득자 관점 및 ② 시스템 개발자 관점이 있다. 사용자-획득자 사이의 문제 영역은 시스템 개발자에게 기회와 해결 영역을 제시해 준다. 차례로 설계 해결에 대한 시스템 개발자의 문제 영역은 해결해야 할 하부계약자, 벤더 및 컨설턴트에게 기회 영역을 제공해 준다.

1. 기회와 문제
기술적인 면에서 문제는 잠재된 위험으로 인한 사고가 발생할 때까지 존재하지 않는다. 그때 실제 당신은 문제를 가지는 것 아닌가! 아폴로 13의 Jim Loveel 대장의 ‘어 휴스톤, 문제가 나타났어...’라고 한 그 말이 여기에서 사용된 콘텍스트에 대한 실제 가장 좋은 사례이다.
고도의 경쟁시장, 그리고 수많은 적, 여러 조직 속에서의 생존해야 하는 환경에서 시스템에 대한 취약점을 최소화하는 활동이 매우 중요하다. 기회를 인식하고 있는 조직은 향후 문제가 될 수 있는 사고나 내일의 토픽으로 나올 수 있는 뉴스를 미리 방지하기 위하여 위험 완화 활동을 시작한다. 반대로 늦장을 부리는 자는 잠재적인 사고를 완화하는 노력을 하지 않고 요행을 기다리면서 문제를 해결하기 위해 앞으로 나가지 않고 끝내 사고를 내고 만다. 문제 영역이란 공통적으로 다루고 있는 사항이며 시스템 엔지니어는 문제 영역에 초점을 두고 다루어 나가야 한다.

2. 문제 해결 또는 징조 해결
조직은 자주 자기네들 스스로 알든지 아니면 상부 요원이 문제 해결을 하고 있다고 알게 된다. 여러 경우에 일명 문제 해결은 실제로 징조 해결이다. 이러한 질문은 사용자, 획득자 및 시스템 개발자에게 ‘이는 해결해야 할 바로 그 문제인지 또는 기문제의 하위 단계 징조인가’라고 물어보는 치명적인 질문사항이다.

3. 문제 영역의 동력
대부분의 조직 시스템에 대하여 문제 영역은 유동적이고 진화적이다. 이는 수많은 방법으로 시시때때로 진화해 간다. 몇 가지는 일시적으로 또는 천재지변 이벤트로 나타나는가 하면, 예를 들면 지구 환경의 오존층처럼 수년간에 걸쳐서 일어나기도 한다. 이러한 원인은 다음 여러 가지 잠재된 소스로부터 시스템 능력과 성능에 문제 영역을 제기하고 있다.

· 시스템에서 무시
· 부적합한 예측이나 정비
· 사용자 운용 요원에 대한 비효율적인 교육훈련
· 예산의 제약

조직적으로 관리자는 문제 영역을 추적해야 할 의무가 있다. 문제는 관리자가 문제 영역을 문제가 발생할 때까지 늦도록 추적하는 것을 싫어한다는 점이다. 다른 경우, 적합한 조치를 제공하지 못하여 ‘맨땅에 헤딩’하듯이 문제 영역에서 헤어나지 못한다는 사실이다. 이러한 경우가 발생하면, 다음 네 가지 경우가 발생할 수 있다.

① 문제 영역의 소스가 없어져 버린다.
② 조직 관리자가 다른 우선순위에 매달려 이를 보지 못하게 된다.
③ 조직 목표가 변경된다.
④ 재해와 같은 사고가 발생할 우려가 있다.

일반적으로 사람들은 문제 영역을 동적으로 보지 못하고 정적 사항으로 다룬다. 사실상, 문제 영역의 일차적인 이슈는 이를 구속시키는 지속적인 동적 요소로 다루어야 한다.

4. 문제 영역 예측
대부분 조직의 도전은 어느 정도의 신뢰로 시스템 능력을 갖춘 문제 영역을 어떻게 예측하느냐에 달려 있다. 그 답은 그 조직의 전략 계획서, 전술 계획서, 시스템 목표 및 임무에서 볼 수 있다.
조직의 전략과 전술 계획서는 현재 능력 대비 계획 능력에 대한 참조 구조로 표현된다. 이러한 목표를 근간으로 상황과 갭 분석을 통해 기존 상태와 경쟁자의 예측 능력과 성능에 대한 원하는 시스템 능력과 성능에 대해 비교를 할 수 있다. 그 결과는 잠재적인 능력의 갭과 성능 레벨을 제시해 준다. 갭의 식별은 조직의 문제 영역에 대한 기초를 형성하고 동적인 갭을 통해 시간에 따라 빨리 또는 천천히 진화해 간다.

5. 언제 갭은 문제로 나타나는가?
이는 예측이라는 관점에서 볼 때 매우 어려운 질문이다. 분명히 당신은 기능 고장으로 나타날 때 문제라고 인식하게 된다. 한 가지 접근방법은 위험 레벨을 지닌 잠재적인 하자가 밖으로 나타나 그 결과로 수용 여부를 결정함에 있다. 사실상 문제 심각성 정도를 평가하기 위하여 레벨이나 한계치를 제시할 필요가 있다.

6. 문제 도메인 영역 설정
개념적으로 우리는 문제 영역의 그 주변을 심벌로 나타낸 실선으로 예시한다. 잔디밭과 같은 경우, 재산 영역은 소유 책임으로 분명하게 정의된다. 대부분의 경우, 영역이란 애매모호하다. 사람들이 비슷한 옷을 입고 서로 말을 사용할 경우, 그 국가의 전쟁 상황인지 사회혁명인지를 구분하기가 어렵다. 어떻게 적과 아군을 구별할 수 있을 것인가? 그 중의 어느 날로 생각할 수 있는가?
아이디어, 정치 및 종교와 같은 가상 라인으로 그어진 선은 모호하고 불분명하게 정의된다. 이를 이해하기 위하여 그림 1을 생각해 보자. 이 그림은 문제 도메인 영역을 회색으로 나타내고 있다. 그 중심은 희미한 외곽과 달리 더 어두운 색상을 나타낸다. 어떠한 경우 문제 영역은 서로 영향을 가져다주는 다른 문제 영역으로 연결된다. 이러한 모호한 사실은 정적인 상태가 아니라 구름이나 번개처럼 변화되어 간다.

7. 문제 영역 통제
문제 원인에 대한 소스나 근원, 당신의 시스템에 대한 위험 정도 또는 목표에 따라 대부분 조직의 자연스러운 경향은 통제, 자원, 영향의 원구 내에서 나타난 문제를 제거함에 있다. 그러나 실상은 그 문제 영역을 제거하기가 어렵다. 최선으로 그것을 관리하고 통제할 수 있다. 즉, 균형과 체크를 통해 이루어간다. 다음 예제를 생각해 보라.



<예제 2> 잡초는 잔디밭의 지속적인 문제로써 매년 여러 가지 이유로 반복적으로 나타난다. 잡초를 제거하는 방법은 여러 가지가 있다, 예를 들면, 환경, 보건, 적용, 및 비용에 대한 고려 요소로써 보다 좋은 방법을 구상하게 된다. 당신은 잡초가 심어진 방법(바람, 물, 새 등)에 따라 스스로 통제할 방법이 제한됨으로 ① 잡초와 함께 지내든지, ② 잡초를 제거하기 위해 별도 계약을 하든지 선택을 해야 한다.

8. 정의된 문제 기술
이제까지 우리는 문제영역을 추상적인 입장에서 초점을 두었다. 이제 실질적인 질문을 해 보면 다음과 같다. 사용자는 무슨 문제를 해결하려고 하는가? 해결 분석이 이루어지기 전에 당신과 당신 개발팀에서는 사용자와 협력하여 사용자가 무슨 문제를 해결하려고 하는지를 파악하여 분명하게 문서화해야 한다. 궁극적으로 이는 어떻게 문제점을 기술할 것인지에 대한 질문을 하게 된다. 문제 상태를 개발함에 있어 여러 가지 방법이 있지마는 다음과 같은 일반적인 지침을 사용하는 것이 바람직하다.

· 문제의 소스나 근원을 식별하는 것을 피하라.
· 어떠한 상태에서 문제가 발생하는지 운용 시나리오 또는 운용조건을 식별하라.
· 외적 또는 내적 해결을 기술하는 것을 피하라.

다음 예제를 생각해 보라.
<예제 3> 컴퓨터 바이러스가 우리 네트워크에 속한 데스크톱 컴퓨터에 영향을 주고 있다.

이 내용은 바이러스가 어디에서 발생하였는지 문제의 소스와 근원이 어디인지, 무슨 영향을 가져오는지 그리고 그 문제를 어떻게 해결해 주는지를 말해 주지 않는 예제이다.

9. 문제 영역 분할
문제에 대한 이해가 성숙해 감에 따라 첫 번째 단계는 하나 또는 그 이상의 해결 영역으로 분할하게 된다. 복잡한 문제 영역을 보다 관리 가능한 해결 영역으로 분할하기 위하여 시스템 이해관계자와 함께 협의하라. 하나 또는 그 이상의 해결 영역을 식별하는 것은 고도의 반복적인 협의, 분석, 의사결정 과정을 통해 가능하다. 그림 1의 왼쪽 편에서 나타난 바와 같이 모호한 문제 영역을 분할하기 위하여 시도해 보는 과정을 생각해 보라. 분할 과정을 통해 우리의 목표는 궁극적인 해결을 가져다주는 문제의 주요 성질과 특성을 분리시켜 준다.
문제해결은 시작단계로 개념적 해결을 설정하도록 요구한다. 이러한 해결은 프로세스를 통해 진화하고 종료 시 이를 인식하지 못해도 좋다. 어떤 사람은 시작 단계에서 개념화 하는 활동을 매우 비효율적이라고 주장한다. 한 가지 접근방법은 문제 영역에 대한 사실을 수집하고 초안 상태의 해결영역을 생성하게 된다. 그리고 분석이 진행됨에 따라 해결 영역을 성숙하게 안정적으로 결정할 때까지 영역을 조정한다. 주요 포인트는 몇 가지 문제 영역은 동적인 관점에서 효율적으로 해결하지 못하고 골칫거리로 기술된다. 일반적으로 당신은 선택하게 된다.

① 추상적으로 계속해서 헤맨다. 또는
② 의사결정을 하고 다음 단계로 넘어간다. 그리고 다시 생각하고 첫 번 의사결정 사항이 필요할 때 수정토록 한다.

10. 문제영역 긴급 정도
문제 영역의 전부 또는 일부분에 대한 긴급 정도와 위험 레벨은 예산이나 기술이 제약된 경우에 특별히 해결 영역 의사결정에 영향을 초래한다. 그 결과는 해결 영역 내에서 능력 레벨과 해결 영역의 의사결정에 대한 우선순위를 제시하게 된다.
시스템을 납품하거나 수락할 때 초기운용능력(IOC)을 설점함으로써 이와 같은 도전을 하게 된다. 그 당시 예산과 기술이 허용하는 범위 내에서 IOC는 전반적인 능력을 충족시키기 위한 점진적 개발을 시리즈로 추진하게 된다. 결국, 제작을 통해 통합이 성숙되어 전반적인 능력을 충족시키는 완전운용능력(FOC)을 달성할 수 있다. 문제 영역을 해결 영역으로 분할한 예로써 그림 2를 참조해 보라.
우리는 대형 박스로 나타낸 문제 영역으로 시작한다. 다음은 이 박스를 다섯 가지 해결 영역으로 분할하고 각 박스는 해결 영역에 할당된 문제 영역 능력과 성능 요구사항 세트를 충족시키는데 초점을 두고 있다. 초기에 우리는 일반적으로 넷 또는 여섯 해결 영역으로 시작한다. 분석을 통해 우리는 다섯 가지 해결 영역을 결정한다. 이는 시스템 개발과 어떠한 관계가 있는가? 대형 박스는 전반적인 시스템 해결을 나타낸다. 우리는 시스템 해결의 복잡성을 제품 레벨 또는 하부 시스템 레벨 해결 영역으로 분할한다. 이 사항을 좀 더 세밀하게 살펴보자.

11. 문제 영역 분할과 할당
시스템 엔지니어가 문제 영역을 다룰 때 그림 3에 나타난 다중 레벨 분할 또는 근접 절차에 따라 사례를 수행한다. 우리가 본 그림의 좌상 부분에 나타난 높은 레벨 문제 영역으로부터 시작한다.
그리고 문제 영역을 1에서 4까지 네 가지 해결 영역으로 분할한다. 해결 영역 3은 다음 하위레벨에 대한 문제 영역 3이 된다. 그리고 3.1에서 3.4까지 분할된다. 분할 절차는 차 하위레벨로 계속된다. 이처럼 좁혀가는 절차는 이 그림의 오른쪽 위에서 볼 수 있다.
문제 영역에 대한 기초와 해결 영역과의 관계를 이해했다면 다음 해결 영역에 대한 개발단계로 진입할 수 있다.



해결 영역 이해

해결 영역은 다양한 영역조건으로 분류된다.

· 분명하고 견고한 영역
· 애매모호한 영역
· 중복 또는 마찰 영역

해결 영역이 충족되는 정도는 요구능력, 우선순위, 문제 영역 ‘구역’에 할당된 자원에 의해 결정된다. 계약이나 조직 면에서 상위 시스템은 해결 정도의 제한을 가져올 자원과 운용 제약 시스템 요소를 부과한다. 다음 예제를 생각해 보라.

<예제 4> 예산과 자금이 감소함에 따라 가정의 쓰레기 수거를 한 주에 두 번에서 한 번으로 줄인다.
<예제 5> 두 도시 사이에 운항되는 항공사에 정상적으로 충족되어야 할 해결 영역은 비수기에 주당 3회에서 1회로 줄인다.

1. 문제-해결 영역 갭 제거
시스템이나 제품 능력에 있어 갭이 식별되었을 때, 일반적으로 만일 시스템 개발이 포함되어 있다면, 이를 이행할 수 있는 시간을 가져야 한다. 갭이 방어적 상태라면, 시스템이나 제품은 경쟁자의 공역에 비해 취약하다. 만일 공역적인 입장에서 결함이 있다면, 시스템 능력과 성능을 업그레이딩하면서 그 갭을 줄여야 한다. 시스템이나 제품의 적용에 따라 유인, 기만, 운용 형태와 같은 운용 전술은 신규 시스템, 제품, 또는 서비스가 가능할 때까지 갭을 보완해 가야 한다.

2. 해결 능력 승수
대부분 사람들은 해결영역을 지형적인 영역 콘텍스트에서 생각하려고 한다. 그림 3에 나타난 마치 부동산 위치를 나타낸 것과 흡사하다. 다시 한번 문제/해결 영역은 능력을 기준으로 하고 있음을 기억하라. 그렇다면 이는 무엇을 말하고 있는가? 능력 기반 해결이란 목표 임무를 달성해야 할 힘, 용량 및 신뢰성과 같은 내용을 말한다.

① 힘 : 특정 도전 임무 형태를 수락할 수 있는 능력
② 용량 : 정의된 범위를 넘어서도록 능력을 증가시켜 연장
③ 신뢰성 : 특정 운용환경에서 주어진 기간에 그 임무를 완료할 수 있는 확률

당신은 획기적으로 영향 영역을 변경하기 위하여 다른 시스템의 능력을 시너지적으로 활용함으로써 시스템의 해결 능력을 연장할 수 있다. 다음 예제를 살펴보자.
투광조명을 이용하여 그림자를 가까운 벽에 투시하는 어린이 게임을 생각해 보자. 몸이 움직일 때마다 투광조명은 실제보다 더 크게 그림자를 벽면에 나타낸다. 따라서 어린이에게 더 큰 사람으로 인식하게 한다.
따라서 우리도 우리의 개인적인 능력을 넘어선 능력을 나타내는 대상 위치와 빛을 지형학적으로 나타낼 수가 있다. 실제가 아닌 가상적인 운용전술이나 조직에서 나타낼 수 있음을 볼 수 있다.
중요한 점은 당신은 X평방 마일을 커버하는 매우 비싼 비행기를 제작할 필요는 없다는 사실이다. 당신이 필요로 하는 것은 10 평방마일 내에서 운용되는 프로젝트를 얼마나 싸게 제작할 것인지 그 방법을 찾는 데 있다. 그 영역 외에는 다른 시스템에서 커버하도록 하면 된다. 다음 예제를 생각해 보자.

<예제 6> 전투기는 연료 중량 때문에 제한된 전투영역을 지니고 있다. 그러나 공중에서 급유하는 능력 덕분에 전투기의 작전반경은 더 넓어질 수 있다.

우리는 시스템의 속성, 특성 및 성질에 따라 시스템은 참조 구조와 운용 도메인을 가지고 있다는 사실을 생각해 보자. 예를 들어, 항공기는 홈 기지- 또는 참조 구조-를 가지고 있다. 그리고 운용범위-또는 도메인-를 가지고 있으며, 이는 연료소비와 유지보수 고려사항에 따라 제한된다. ‘탱커’ 항공기를 사용함에 따라 연료 공급을 할 수 있어 유효 운용 범위를 연장할 수 있다.



3. 해결 영역에서 해결 대안 설정과 선정
각 해결 영역은 기법, 기술, 지원, 비용 및 일정 제약에 따라 구속된다. 도전해야 활 방법은 기술적 요구사항을 충족시키는 여러 가지 대안을 식별하고 평가하며, 최적 해결방안을 추천하게 된다.
이와 같은 선정은 추천 해결방안을 선정하기 위해 절충 분석하는 사전에 정의되고 목표기준을 설정할 필요가 있다. 이제 이를 좀 더 상세하게 살펴보기로 하자.

문제-해결 영역 인식

당신 조직에 속한 모든 사람은 당시 s 조직의 기회-해결 영역을 이해하고 인식해야 한다. 불행하게도 출장 예산, 사용자 요구 및 조직인력 수용 능력이 일차적으로 어떻게 그 시스템을 개발하여 납품, 운용 및 지원해야 할지 보는 관점을 흐리게 하고 있다는 점이다. 과학적 영역에서 관찰이란 시스템 엔지니어의 치명적인 기술에 속한다. 사용하고 있는 기존 시스템을 보고, 만지고, 느끼고, 운용하고, 듣고 공부하는 일은 시스템 개발을 통해 시스템 엔지니어에게 심오한 영향을 가져다준다. 다음 예제를 살펴보자.

<예제 7> 대형 컴퓨터의 부품을 설계해야 할 회사가 있다고 하자. 한 가지 고려해야 할 사항은 장비를 현관을 통해 운반할 수 있어야 하기 때문에 비즈니스 개발인력은 현관과 방으로 운반하는 복도 크기를 기술한다. 엔지니어는 설비 사이트 조사 수행 기회가 주어지지 않았다.

만일 좁은 현관을 통해 케비넷을 운반해야 함을 먼저 알았더라면, 엔지니어는 이를 고려해서 설계했을 것이다. 시스템을 납품했을 때, 설치팀은 문제점을 알게 된다. 그 케비넷은 문을 90도 각도로 돌려서 겨우 복도를 지나 문에 도달할 수 있음을 알게 되었다. 여기 우리는 기회 문제와 해결 영역을 이해하고, 분석하며 문서화하기 위해 시스템 엔지니어가 비즈니스 개발인력을 대동하여 직접 방문을 통해 항상 이루어져야 한다는 사실을 알게 된다.

1. 최종 고려사항
문제-해결 영역을 이해하기 위하여 운용환경의 동적 요인으로 인한 지속적인 평가가 이루어져야 한다. 시스템 엔지니어는 가끔 해결 영역이란 신규 시스템, 제품, 또는 서비스를 개발하여 납품하는 활동이 전부라고 믿고 있다. 과학적인 관련법에 따라 사용자의 모든 활동은 긍정적인 의견과 함께 경쟁자의 반대 의견도 고려해야 한다. 따라서 해결 영역을 제시할 때 다음과 같은 절차를 고려해야 한다.

① 경쟁자의 잠재된 반응
② 신규 시스템, 제품 또는 서비스가 제기된 위협에 따라 최소 기간 중 그 취약점을 최소화하는 방법을 제시

적용 원칙

요약해서, 지금까지 논의한 사항은 시스템의 문제점, 기회 및 해결 영역을 이해하고 적용하기 위한 원칙을 설정하는 기초를 제공하고 있다.

원칙 1 : 시스템 분석은 실제, 추구, 예상과 같은 세 가지 사용자 운용요구 형태에 대한 인식과 확인을 요구하고 있다.
원칙 2 : 한 시스템의 문제 영역은 경쟁 시스템의 기회 영역이 된다.
원칙 3 : 문제 영역의 복잡도는 해결 가능한 하나 또는 그 이상의 해결 영역으로 분할 관리토록 한다.
원칙 4 : 해경 영역을 구상할 때, 해결 영역 능력을 이해하기 위하여 연관된 경쟁자의 반응을 살펴보라.
원칙 5 : 두 가지 해결 개발 활동으로서는 문제 해결과 징조 해결이 있다. 그 차이를 인식하도록 하라.

요약

우리가 살펴본 문제와 해결 영역은 여러 가지 이유로 인해 시스템 엔지니어링 개념을 제공해 주고 있다.

· 문제 해결은 문제 영역과 이에 따른 제약사항을 이해하고 구속하면서 시작된다.
· 여기서 논의한 기본적인 개념은 시스템 엔지니어링 프로세스 모델의 주요 요소이다.
· 해결 영역을 충족하는 대안 개념과 해결 방안은 평가와 의사결정을 위한 대안 시스템 해결을 위한 기반을 제공해 준다.

이제 문제 영역과 해결 영역 개념을 이해하고 나면, 사용자가 어떻게 시스템, 제품 또는 서비스를 시스템 임무와 조직을 수행토록 할 수 있는지를 모색해야 한다. 이는 다음 시스템 운용 환경과의 상호관계라는 토픽에서 살펴보도록하자.

1. 일반 연습 과제
① 개요에서 제시된 본 장의 질문사항으로부터 무엇을 배웠는지 답해 보라.
② 앞 장에서 사용한 시스템이나 새로운 시스템을 한 가지 선정해서 이 장에서 논의된 사항을 제시해 보라. 특별히 다음 사항을 식별해 보라.
· 문제 영역
· 기화 영역
· 해결 영역
③ 집주인이 잔디밭을 가꾸기 위한 시간, 자원 및 기술을 사용해서 할 수 있는 다양한 해결 도구를 제시해 보라.
④ 다른 시스템 능력을 고려하여 영향 반경을 예상하고 넓힐 수 있는 두 가지 인공 시스템과 두 가지 자연 시스템을 제시해 보라.

2. 조직에 중심을 둔 예제
① 당시 조직의 시스템, 제품, 또는 서비스와 연관해서 다음 사항을 식별 기술해 보라.
· 문제 영역
· 기화 영역
· 해결 영역
② 당시 조직의 계약 프로젝트를 살펴보고 사용자 조직의 임무와 당신이 제공해야 할 시스템, 제품 또는 서비스에 대하여 다음 사항을 제시해 보라.
· 문제 영역
· 기화 영역
· 해결 영역

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