[시스템 인터페이스 분석, 설계 및 통제 (1)] 인터페이스 상호작용 식별과 분석
[시스템 인터페이스 분석, 설계 및 통제 (1)] 인터페이스를 적용한 시스템 능력 구성

인터페이스를 적용한 시스템 능력 구성

앞서 논의된 시스템 능력의 세분화에 따라 제시된 시스템 능력 구성은 인터페이스와 같은 시스템 능력을 어떻게 나타내느냐 하는 구조를 말한다.

· 시작
· 제품, 서비스, 또는 활동과 같은 임무수행
· 다시 시작할 때까지 반복된 사이클이나 dormancy를 구상

이러한 활동 수행 시, 인터페이스 능력은 보건과 준비상태를 평가하고 저하된 성능 결정이나 고장상태를 제시하고, 이러한 상태를 보고하며 다시 회복하는 방법을 시도한다.
시스템 요구사항을 도출하기 위해 적합한 추상적 레벨에서 시스템 모델을 생성하는 것이 바람직하다. 이와 같은 모델에는 다음과 같은 몇 가지 사항을 포함해야 한다.

· 시스템이 반드시 지녀야 할 내부 기능성을 제시해야 한다. 설계사항을 구체적으로 다루기 위한 시스템 작동방법을 제시하는 것이 아니라 시스템이 수행해야 할 기능에 대하여 제시해야 한다.
· 시스템을 운용할 환경에서 다른 시스템과 상호운용에 필요한 기능성을 제시한다.
· 사람과 시스템의 상호운용에 필요한 기능성을 제시한다.
· 시스템 운용환경에서의 다른 시스템 위협으로 인한 오작동을 예방할 수 있는 기능성을 제시한다. 이러한 위협은 고의로 발생할 수 있는 사항이 아닌 경우도 있다. 예를 들면, 주변기기에서 방출되는 전자파에 대한 보호 기능이 시스템 환경을 방해하지 않도록 해야 한다. 이러한 유형의 기능성은 기능 상호간에, 그리고 시스템 환경 내에서 다른 요소와의 운용방식을 그림 3과 같이 나타낸다.

그림 3. 시스템 콘텍스트 내에서의 기능성 유형 

시스템 운용환경 내에서 다음과 같은 사항을 시스템 콘텍스트에서 나타내어야 한다. 

· 신규 시스템에 상호운용되어야 할 기존 시스템
· 시스템과 상호운용에 연관된 모든 유형의 사람
· 시스템 방어에 필요한 모든 위협 시스템
· 반드시 예방되어야 할 시스템의 악영향 사항

그리고 기능성은 다음과 같은 몇 가지 방법으로 나타낼 수 있다. 예를 들면 다음과 같다.

· 클래스 다이어그램으로 나타낸 운용 또는 방법
· 매시지 순서 차트
· 상태전이도
· 기능 흐름선도(FFBD: Functional Flow Block Dia-gram)
· 데이터 흐름도(DFD: Data Flow Diagram) 프로세스

실제 필요한 여러 가지 측면을 다루려면 몇 가지 모델을 활용해야 한다. 각 모델은 정의된 유형의 정보를 포함하고 있다. 그리고 각 모델링 기법은 고유의 특성을 나타내는 체계로 되어있다. 어느 모델 정보는 다른 모델 정보와 차이가 있을 수 있다. 또한, 동일한 정보가 하나 이상의 모델에서 나타날 수 있다. 이와 같은 경우, 한 모델 정보가 변경될 때, 다른 모든 모델이 함께 변경되어야 한다. 

이러한 활동은 모델링 도구를 사용하면 자연적으로 이루어진다. 이를 수동적으로 처리할 경우, 변경이 전 모델에 이루어졌는지를 확인하는 데 많은 시간과 노력을 쏟아야 할 것이다.
그림 4의 벤 도표에서 모델 C, D 및 E는 공통정보를, 모델 A와 B는 고립된 정보의 섬을 나타낸다.

그림 4. 시스템 모델 범주

또한, 그림 4는 어느 모델에도 반영되어 있지 않은 외부 시스템 정보가 있을 수 있음을 보여준다.

1. 기본적인 기능성
기본적인 기능성이 시스템 요구사항을 생성하면서 가장 중요하다. 이는 향후 시스템이 해야 할 일을 나타내는 가장 중요한 요소이기 때문이다. 시스템 요구사항을 생성하기 위하여 이에 해당하는 시스템 구조 또는 모델을 형성할 필요가 있다. 이 모델은 하부시스템이나 모듈과 같은 상위 컴포넌트로 분할하여 구현할 수 있어야 한다. 

‘모듈’ 또는 ‘컴포넌트’라 하면 개발자는 규격사항이라기보다 시스템 구현 품목으로 생각하기 쉽다. 이와 같은 생각을 바꾸어야 한다. 특히 소프트웨어 기반 시스템은 더욱더 중요하다. 일반 시스템의 경우에는 보다 더 실체적 모델에 더욱 치중하게 된다. 왜냐하면, 이는 애플리케이션 도메인이 보다 물리적 특성을 더 많이 지니고 있기 때문이다. 

시스템 구현에 너무 빨리 들어가지 않게 하기 위하여 ‘객체(object)’라는 용어를 하나의 분할 요소로 사용하는 것이 바람직하다. 특히 소프트웨어 기반 시스템에는 더욱더 그렇다. 이는 문제점 도메인에서 객체를 이용해서 나타낼 수 있기 때문이다. 이와 같이 용어를 다르게 사용하면 솔루션 도메인과 구별될 수 있다. 

이제 기능을 객체 프로세스 또는 객체의 작동 및 객체의 상호작용으로 표현할 수 있다. 이러한 객체지향 접근방법을 사용함으로써 시스템 요구사항으로부터 이해관계자 요구사항 추적을 보다 쉽게 해 준다. 왜냐하면, 문제점 도메인과 솔루션 도메인에서 동일한 객체를 쉽게 알아볼 수 있기 때문이다. 

대상시스템이 무엇을 해야 하는지를 명확하게 기술한 다음, 추가적으로 시스템 거동에 대한 모델을 나타내는 시스템 모델을 제시할 수 있어야 한다. 이러한 유형의 정보를 나타내기 위한 방법은 여러 가지가 있다. 일반적으로 이러한 모델을 활용해서 동시에 상호작용하는 활성 행위자가 다수 존재한다는 사실을 볼 수 있다. 이를 나타내는 도표로서 매시지 순서도, 거동 도표 등이 있다.

매시지 순서도는 통신 분야에서 오랫동안 사용해 오고 있다. 1970년대 미국 탄도 미사일의 조기경보 시스템에 사용되어 온 거동 도표는 Ascent Logic사의 RDD-100과 Vitech사의 CORE와 같은 컴퓨터 응용 도구로 구현되고 있다. 또한, 상태전이도와 상태차트를 활용해서 시스템 거동 상태를 모형화할 수 있다. 

상태전이도는 순서의 연속적 상태를 모형화할 수 있으며, 또한 모형화 항목이 각 상태의 한 시점으로 나타내어야 하는 제약이 있다. 또한, 상태전이도는 계층구조로 상태를 나타낼 수 없다. 계층별 각 단계에서 별도 도표를 사용해야 한다. 그리고 어떤 경우에는 특정 시점에 활성 도표가 여러 개 있을 수 있다. 이러한 경우의 도표는 이해하기 어려운 경우가 많다. 따라서 이와 같은 어려움을 피하기 위해 상태차트를 사용하는 것이 바람직하다. 상태차트는 상태의 계층구조를 나타내기 위하여 개발되었다. 또한, 상태차트를 활용하면 병행 상태를 쉽게 다룰 수 있다.

시스템마다 다루어야 할 정보가 있는지를 검토할 필요가 있다. 예를 들면, 보험 시스템과 같은 경우, 보험회사에서 관련 보험정보를 수집하고 활용하기 위해 여러 해 동안 관련 정보를 지속적으로 관리해야 한다. 또한, 항공교통 통제를 위한 레이더 자료처리 시스템의 경우, 오랜 수명을 지닌 정보가 관리되어야 한다. 항공운항계획이 이와 같은 정보라면, 현 비행 위치는 그 자체가 하나의 과거 정보가 되어버린다. 이와 같이 정보와 연관된 요구사항을 정리해서 다음과 같은 사항을 확인해야 한다.

· 정보 보존 기간 : 해당 정보의 유효기간과 정보 보존 기간이 얼마라야 하는지?
· 새로운 정보 유효기간 : 얼마나 최신(초, 분 또는 시간) 정보라야 하는지?

연관된 정보의 양이 얼마나 되는지를 아는 것 또한 매우 중요하다. 이는 시스템 설계에 엄청난 영향을 가져온다.

2. 인터페이스 기능성
대상시스템과 외부적으로 상호 연관된 특성을 제시해야 한다. 상호 연관된 요소는 시스템 상호간의 정보나 자재의 상관성을 포함할 수 있다. 상관성은 한 방향 또는 양방향일 수 있으며, 전달 능력에 한계가 있을 수 있다. 지연 항목은 임시 저장소(예를 들면, 데이터 버퍼, 리파지토리)에 보관할 수 있도록 처리해야 한다. 하나의 시스템이 다른 시스템으로부터의 반응시간에 대한 요구사항을 제시해야 할 경우도 있다.

인터페이스 특성은 매우 다양하다. 따라서 각 요소에서 수행하거나 제공해야 할 인터페이스 기준이 설정되어야 하고, 인터페이스 설계 시, 이 기준을 반드시 참고해야 한다. 이러한 사항은 인터페이스 통제문서(ICD: Interface Control Document)에 의무사항으로 기록되어야 한다. 국가표준이나 국제표준으로 이를 통제할 경우, 바로 적용표준 자체가 모든 관련자가 지켜야 할 인터페이스 통제문서가 된다.

이와 같이 인터페이스가 미리 잘 정의되지 않은 경우, 반드시 인터페이스 요구사항으로 관련자와 협의하여 이를 기록해야 한다. 그리고 인터페이스 통제 권한이 분명하게 부여받은 조직이 없을 경우, 인터페이스 통제는 매우 어렵게 된다. 인터페이스와 연관된 기관이나 부서는 자체로 수행하는 활동만을 문서화하려 하는 폐단이 있다. 보다 더 큰 문제는 자체의 이익에 따라 인터페이스 항목을 해석하여 이를 연관부서와 협의 없이 자체적으로 구현하려고 하는 것이다.

따라서 상호 연관된 두 개의 기관이나 부서의 상위 시스템 조직이 인터페이스 통제문서를 관장하는 것이 바람직하다. 신규 시스템을 개발하는 조직에서 인터페이스를 규정하기란 그리 만만하지 않다. 현재 추진 중인 대상시스템 개발을 너무 서두르다 보면 미쳐 인터페이스 내용을 구체화하거나 문서화 하지 않은 경우가 많다. 

이에 따라 고객이 대상시스템을 인도한 다음에는 획득자가 더는 인터페이스에 대한 책임을 지지 않는 경우가 허다하다. 따라서 적합한 시기에 모든 인터페이스 관련 요구사항이 도출되어 이를 의무조항으로 반영하고 있는지 그리고 인터페이스에 대한 통제권한을 분명하게 정의하고 있는지를 미리 확인해야 한다.

3. 사람과 시스템의 상호기능성
시스템과 사람과의 인터페이스는 어떠한 상호관계가 필요한지를 미리 파악함에 있다. 또한, 사용자의 운용환경도 매우 중요하다. 이는 사용자의 시스템 운용방식에 영향을 가져오기 때문이다. 예를 들면, 일반적인 사무실 환경에서의 사용자는 보온장갑이 없어도 지장 없이 업무를 수행할 수 있다. 

그러나 극한 온도의 운용환경에서의 사용자는 보온 된 복장이 없이는 시스템 운용이 어려울 것이다. 이와 같은 위험한 환경에서의 컴퓨터 디스플레이와 키보드는 특수 설계를 해야 할 것이다.

4. 보호 기능성
대상시스템의 운용환경이 안전과 보안에 연관된 경우, 이는 시스템에 큰 영향을 초래한다. 예를 들면, 금융 시스템의 경우, 은행 이용에 대한 인증이 없는 사람에게는 관련 정보나 돈이 인출되지 않아야 한다. 자동차 시스템의 경우, 제동장치 페달을 밟게 되면 자동차가 확실하게 멈추어야 한다.

향후 대상시스템이 출시한 다음에 이 시스템과 경쟁 대상시스템이 시장에 나타날 수도 있다. 예를 들면, 온라인 은행업무처럼 사업적인 시장경쟁일 수도 있다. 이러한 경우, 더욱 빨리 대상시스템 기능을 발전시키는 것이 바람직하다.
또 다른 경쟁 시스템의 경우, 시스템 작동을 방해하는 경우도 있다. 예를 들면, 통신시스템의 송수신 주파수를 교란하거나 과부하를 주어 대상시스템 작동을 방해하는 경우이다. 이와 같은 예로써 운항 중인 항공기에 이동전화 사용은 항공 운항 시스템에 무선간섭을 일으킬 수도 있다.

5. 시스템 트랜잭션
대상시스템의 트랜잭션을 알아보기 위해 이해관계자가 시스템 개발을 위해 만든 운용시나리오 또는 없을 경우, 연관된 운용시나리오를 생성하여 이를 검토하는 일이 중요하다. 시스템이 구체화 되어감에 따라 운용시나리오 적용 여부를 확인하기 위해 그림 5와 같은 시스템 모델을 사용하는 것이 바람직하다.

그림 5. 시스템 트랜잭션

이와 같은 시스템 트랜잭션에 따라 작업하게 되면 객체모델링 또는 기능 분할에서 시스템의 빠진 기능을 찾아내는 데 매우 큰 효과를 볼 수 있다.
그림 5에서 사용자 시스템 트랜잭션은 관련 운용시나리오로부터 도출된다. 또한, 개발 중인 시스템이 외부시스템과 반드시 수행되어야 하는 다른 트랜잭션 사항도 있을 수 있다는 것을 보여주고 있다.  

시스템 엔지니어는 시스템 트랜잭션을 활용하여 시스템 전체에 대한 내용을 한눈에 볼 수 있다. 물론 상세한 부분까지는 볼 수 없지만, 상세한 부분들이 어떻게 함께 작동해야 하는지 그 목표를 전체적으로 알 수 있다. 

6. 시스템 운용형태
운용 환경에 따라 서로 다른 기능을 추가 요구할 수 있다. 예를 들어, 정보기반 시스템의 경우, 직원 교육훈련 시 데이터의 무결성을 훼손하지 않도록 해야 한다. 다른 경우로서는 대상시스템의 고장 발생 이후 이를 피드백해서 운용하는 형태도 있으며, 군용시스템의 경우, 시스템 경계영역에 따라 운용형태를 달리할 수도 있다. 이러한 운용형태는 이해관계자 요구사항에 따라 운용 시나리오에 반영되어야 한다.

7. 추가적인 제약조건
앞에서 이미 언급된 제약사항에 추가하여 제시되어야 할 조건이 발생한다. 가장 중요한 사례로서는 안전과 검증에 관한 사항을 들 수 있다. 이로 인한 추가 요구사항이 도출될 수 있으며, 이는 나아가 품질인증 방식에 영향을 가져오게 된다. 대상시스템 관련 획득 부서에서는 시스템 운영 및 배치단계에서 안전성을 요구하게 된다, 

예를 들어, 항공기 사업의 경우, 대상시스템의 안전항공기준 이행 자격증을 제시하여야 한다. 또 다른 제약조건 추가 사례로써, 시스템 생산단계에서 생산 원가를 줄이기 위해 기존 설비 활용조건이나 설계를 변경하는 조건을 제시할 수 있다.

민성기 원장 _ 시스템체계공학원