[시스템 인터페이스 분석, 설계 및 통제(2)] 인터페이스 설계방법
[시스템 인터페이스 분석, 설계 및 통제(2)] 인터페이스를 적용한 시스템 능력 구성

인터페이스 설계방법

인터페이스 설계 실무에서 주요 요소는 대부분 적용에 적합한 다음과 같은 다섯 가지 단계로 요약할 수 있다.

· 단계 1 : SOI - 운용환경관계 식별
· 단계 2 : 시스템 또는 품목 아키텍처 개발
· 단계 3 : 아키텍처 논리적 개체관계 제시
· 단계 4 : 운용 인터페이스 유스 케이스 제시
· 단계 5 : 물리적 인터페이스 특성 제시

이제 인터페이스 설계방법의 각 단계를 살펴보도록 하자.

1. SOI - 운용환경관계 식별
방법론의 첫 번째 단계는 대상시스템(SOI)에 상응하는 인터페이스를 나타내는 사용자 운용 환경 내에서 연관 개체를 식별하는 방법이다.

2. 시스템 또는 품목 아키텍처 개발
외부 시스템과의 논리적 또는 물리적 관계를 나타내기 위한 시스템 또는 개체 아키텍처를 개발하는 단계이다.

3. 아키텍처 논리적 개체관계 제시
시스템이나 개체 아키텍처 또는 확인된 사용자 요구분석에 기초하여 인공시스템과 운용환경과 같은 내부 및 외부 개체 사이에 논리적 개체관계를 제시하는 단계이다.
일반적으로 이 단계는 공식화된 인터페이스를 기술하는 단계이다.

4. 운용 인터페이스 유스 케이스 제시
각 시스템이나 개체 인터페이스에 대하여 인터페이스의 주요 운용 특성을 식별하는 단계이다.

· 인터페이스 이해관계자는 누구인가?
· 내용, 힘, 방향 어느 것이 인터페이스 항목으로 교환되어야 하는가?
· 언제 그리고 얼마나 자주 인터페이스가 나타나게 되는가?
· 지속적 또는 중간마다 인터페이스가 제시되어야 할 장소는 어디인가?
· 인터페이스는 어떻게 조정되며, 보안 및 사적 비밀이 유지되는 것인가?
· 무슨 상태에서 인터페이스가 일어나는가?

5. 물리적 인터페이스 특성 제시
운용 인터페이스 속성을 기초로 사용하여 그 인터페이스에 주요 운용 및 물리적 특성을 식별토록 하라.
데이터 교환 인터페이스의 경우, 인터페이스 속성은 connectors, pin-outs, grounding & shielding, protocol, timing & synchronization, data formats, handshakes, addressing, encryption, 그리고 표 1에 제시된 표준을 포함한다.

표 1. 인터페이스 속성 및 내용 기술

6. 인터페이스 설계 솔루션 개발과 문서화
운용, 논리적, 물리적 인터페이스 속성이 식별되고 제시됨에 따라 인터페이스 통제문서(ICD) 또는 인터페이스 설계기술서(IDD)에 대한 결과를 제시하라. 그리고 이를 설계 논리, 절충 결과 등을 문서화하라.

 

시스템 인터페이스 요구사항 구속 및 제시

인터페이스 요구사항을 구속하고 제시하기 전에 어디에 어떻게 인터페이스 요구사항이 문서화되어 있는지를 설정해 보자.
인터페이스 요구사항은 전형적으로 시스템 성능규격(SPS) 또는 품목개발규격, 시스템 인터페이스 절로 제시되어 있다. 어떠한 경우에는 소프트웨어 인터페이스 요구사항이 인터페이스 요구규격(IRS)으로 제시되기도 한다. 

1. 인터페이스 요구규격
IRS란 무엇인가? 미 국방 자료항목기술서(DID) DI-IPSC-81434에 따르면 “인터페이스 요구규격서(IRS)란 하나 또는 여러 시스템, 하부시스템, 이러한 개체 상호간에 하나 또는 여러 인터페이스를 달성하기 위하여 하드웨어 형상품목(HWCI), 소프트웨어 형상품목(CSCI), 매뉴얼 운영, 또는 기타 시스템 컴포넌트에 부과된 요구사항을 기술한 것이다. 

IRS는 어떠한 인터페이스라도 대상으로 하고 있으며……IRS는 시스템/하부시스템규격(SSS)의 보충자료로도 사용될 수 있다……그리고 소프트웨어 요구규격서(SRS) ……시스템과 CSCI의 설계 및 자격시험에 대한 기초자료로 사용된다.” [출처 : DoD Data Item Description (DID) DI- IPSC-81434, p.1]

가끔 사람들은 인터페이스 요구사항이 SPS 또는 품목개발규격에 기술된다면, 왜 별도의 인터페이스 규격을 작성해야 하는지를 묻곤 한다. 다음에 두 가지 그 이유가 있다.

· 시스템 외부 인터페이스
· 대상시스템 내부 인터페이스

이상적으로는 시스템 인터페이스 요구사항은 SPS 또는 형상품목(CI)에 대한 하위 레벨 품목개발규격(IDS)으로 단일화된 요구규격으로 작성되어야 한다. 이러한 질문에 대한 답변은 다음과 같다.

· 당신의 계약에서 무엇을 요구하는지.
· 계약 규격, 지적 자산, 고유 데이터, 보안과 같은 시스템 개발자에게 민감한 데이터를 보호하는 데 필요한 다른 요인은 없는지.

2. 인터페이스 규격에 대한 계약 요구사항
인터페이스 규격 요구사항에 관하여 사업제안서(RFP)와 계약 자료 요구 목록(CDRL)을 읽어보고 있다면 보다 면밀하게 검토해 보라. 만일 IRS CDRL이 보이지 않으면, SPS 또는 품목개발 규격에 나타난 인터페이스 요구사항을 애플리케이션에 따라 살펴봄으로써 다음과 같은 경우를 피해야 한다.

· SPS/IDS와 인터페이스 규격에 관한 두 가지 별도 문서를 유지하고 검증하기 위해 별도의 시간과 지출
· 별도의 검토와 승인에 대한 노력

· 시스템 관점에서 다음 문서와 함께 하나의 규격을 사용하는 개체로서 시스템 검증하기를 원한다.

· 수락시험절차(ATP) 한 세트
· 요구검증 매트릭스(RVM)
· ATP 데이터 한 세트

두 가지 별개의 규격서에 나타난 요구사항을 검증하기 위해 업무 수행, 자료 작성 및 협조를 동시에 수행해야 한다. 당신은 두 가지 규격서와 함께 ATP한 세트와 그 결과를 다루어야 한다. 이는 사실이지만, 당신은 여전히 이러한 별개의 복합된 결과를 어떻게 추적할 것인가에 대한 문제를 지니고 있다. 

만일 인터페이스 규격을 별도의 문서로 작성하지 않을 경우, 한 문서에 모든 시스템이나 개체 인터페이스 요구사항을 함께 작성하지 못하는 이유를 이해할 수 있다. 이를 보다 단순하게 다루도록 하라!

3. IRS는 내부 문서인가?
아니다. 사실상 많은 프로그램의 공통된 문제점은 “모든 내부 및 외부 인터페이스에 대한 하나의 IRS”를 개발하도록 사업을 제안하는 잘못된 정보를 제공하는 의사결정자가 있다는 사실이다. 이로 인해 비용을 낭비하고 불필요한 일을 하게 된다는 사실을 잊지 말아야 한다.

여기에는 별개의 IRS에 대하여 요구사항의 용량, 데이터 보안 분류 및 조달해야 할 별도의 이유가 발생하게 된다. 디폴트로 인터페이스 요구사항을 SPS나 품목개발규격에 정의토록 하라. 이때 만일 전체 인터페이스 요구사항 세트를 분리해서 작성해야 할 이유가 있다면, 그야말로 별도의 IRS를 작성토록 하면 된다. 

4. IRS를 외부에서 개발해야 할 필요가 있는가?
IRS는 사용자 조직과 하부계약자와 함께 계약관계를 도와줄 수 있다. 이럴 때 IRS는 인터페이스 관계에 있는 이해관계자의 일치된 의견을 나타내는 원칙적인 요구사항 세트를 기꺼이 별개로 다루게 된다. 궁극적으로 IRS 요구사항은 하드웨어 ICD와 소프트웨어 IDD로 문서화된 인터페이스 솔루션으로 진화한다.

5. 표준 IRS 템플릿
DoD는 데이터 요구사항을 나타내기 위하여 데이터 항목 기술(DID)을 적용하고 있다. DID DI-IPSC-81434는 하드웨어 형상품목(HWCI) 및 소프트웨어가 주된 시스템에 대한 소프트웨어 형상품목(CSCI)을 제시하고 있다.
우리는 인터페이스 요구사항을 어떻게 기술할 것인가를 알아보았으며 이제 인터페이스 소유와 책임에 대하여 살펴보기로 하자.

인터페이스 소유와 책임

개인이나 통합제품팀(IPT)과 같은 개발팀에게 분담된 시스템 요소나 개체와 달리 인터페이스에 대한 분담은 어떻게 해야 할까? 여기에는 다음과 같은 여러 가지 방법이 있다.

· 위원회
· 구조분석 접근방법

1. 인터페이스 소유에 대한 위원회 운영방식
기술이사와 프로젝트 엔지니어들은 “관련 당사자끼리 해결”하는 방식으로 인터페이스가 되는 두 파트에게 소유권을 부여하는 방법이다. 주어진 상황과 사람의 특성에 따라 이 방법은 어떤 경우에는 매우 효과적이나 다른 경우에는 비효과적인 경우가 발생한다. 이 방법에서 발생 가능한 잠재 문제점은 다음과 같다.

· 인터페이스 당사자 간 그 인터페이스를 어떻게 해결할 것인지에 대한 견해 차이로 마찰이 발생할 수 있다.
· 상대적으로 우월한 사람이 너무 지나치게 주장하게 될 경우, 주장하는 파트에 혜택을 주는 기술, 비용 또는 일정에 차선책을 가져오게 된다.

이러한 경우가 계속될 경우, 우월한 파트가 대상시스템을 차선책으로 결정할 가능성이 커진다. 그러나 위원회 운영으로 발생하는 문제점을 해결할 수 있는 인터페이스 소유 및 통제를 위한 더 좋은 방법이 있다.

2. 구조적 인터페이스 소유와 통제
위원회 운영방식에 따른 문제점을 해결하기 위하여 시스템 성능규격서(SPS) 또는 품목개발규격서 및 이와 연관된 아키텍처에 대한 개인이나 개발팀에게 인터페이스 소유 및 통제권을 주는 방법이다. 인터페이스 당사자는 주어진 아키텍처 내에서 하나의 요소가 된다.

어떤 시스템은 조직 상호간에 기술과 프로그램 솔루션 둘 다 요구하는 외부 인터페이스를 지니고 있다. 이러한 경우 다음 토픽인 인터페이스 통제 실무그룹(ICWG)을 운영하는 방법이 있다.

3. 인터페이스 통제 실무그룹
인터페이스 통제 실무그룹(ICWG)은 시스템 또는 요소의 인터페이스 설계를 담당하는 요원 상호간에 공식적인 의사전달 링크를 구축하기 위해 만들어진 전형적인 그룹을 말한다. 특히 통합제품 및 프로세스개발(IPPD) 절차를 적용하는 ICWG는 인터페이스 설계 IPT 상호간에 연결을 구현하는 통합팀이나 시스템-레벨 엔지니어링 실무 그룹을 함께 통합하여 운영한다. ICWG 또는 이와 유사한 통합팀의 구성원은 각 계약업체, 계약부서 그리고 참여하는 정부기관 요원들로 구성된다. 외부 및 선정된 최상위 레벨 인터페이스를 주관하는 조달 프로그램 조직이나 내부 인터페이스를 다루는 주계약업체가 보통 ICWG 위원장을 지명한다. 

한 번 이해관계자가 인터페이스 요구사항과 적용에 동의하고 나면, 그들은 인터페이스 변경이 발생하면 어떻게 이를 통제하게 되는가? 이를 위해 몇몇 기관은 형상통제위원회(CCB)를 운영하거나 CCB에 추천 안을 건의하는 인터페이스 통제 실무그룹(ICWG)을 활용한다. 일반적으로 ICWG가 사용자 환경과 외부시스템을 포함한 전형적인 외부시스템 인터페이스를 설정한다. 계약 규모에 따라 ICWG와 CCB는 동일한 이해관계자로 구성되어도 좋다. 다른 경우에 ICWG는 사용자 및 계약조직으로부터 추천된 기술대표들로 구성된다.

하나의 조직 부서로서 ICWG는 하드웨어 ICD 또는 소프트웨어 IDD에 운용, 거동/논리적, 물리적 인터페이스 특성을 정의하고 이를 문서화한다. 인터페이스 이해관계자는 ICD 또는 IDD 문서를 검토한 다음 인터페이스 소유자의 승인을 받기 위해 차상위 레벨 팀에게 추천 안을 제출한다. 

승인되고 나면, ICWG 위원장은 IRS와 같은 인터페이스 문서에 기준을 제시하고 사용자에게 이를 공식적으로 제시하기 위해 프로그램의 형상관리자를 임명하게 된다. 베이스라인 후에 부가적인 변경이 요구되면, ICWG는 변경사항을 검토하고 프로그램 형상관리위원회(CCB) 승인을 위해 추천 안을 제시한다.

 

인터페이스 설계문서

인터페이스 설계는 시스템 블록선도(SBD), 개체관계도(ERD), 도식화된 와이어링, 시간 도표, 테이블, 기술서와 같은 다양한 방법으로 문서화한다. 대형 시스템일 경우, 이는 개별적으로 통제하는 수백 페이지 문서로 구성되어 있다. 이것을 어떻게 합리적으로 다룰 수 있을까?
시스템 엔지니어는 인터페이스 기술서를 작성하고 통제하기 위해 다양한 문서를 활용하고 있다. 이러한 문서로서는 다음과 같다.

· H/W 인터페이스에 대한 인터페이스 통제문서(ICD)
· S/W 인터페이스에 대한 인터페이스 설계기술서(IDD)

소규모 프로그램일 경우, 시스템/분야 설계기술서(SSDD) 또는 소프트웨어 설계기술서(SDD)가 별도의 ICD/IDD 문서를 가지는 것보다 인터페이스 정의를 문서화하기가 더욱 쉽다. 이러한 문서는 세부적인 인터페이스 설계를 발견하기 위해 단일 위치로 나타나게 된다. 비용을 절감하고 개발자에게 형상통제를 포함하고 있는 다양한 문서를 최소화하기 위해 적합한 문서를 사용토록 하라.

1. 인터페이스 설계기술서
소프트웨어에 적용하기 위해 인터페이스를 인터페이스 설계기술서(IDD)에 문서화한다. 이 방법은 별도 문서로 CSCI 특정 인터페이스 설계기술서를 고립시킬 필요가 있는 CSCI 소프트웨어에 대하여 자주 사용된다.

2. 인터페이스 통제문서
인터페이스 통제문서(ICD)는 인터페이스 통제도면, 인터페이스 요구규격서, 관련되거나 연동된 시스템이나 컴포넌트 상호간의 물리적 및 기능적 인터페이스를 나타내는 모든 문서를 포함한다. ICD는 ICWG나 유사 통합팀의 산출물이며, 이러한 통제문서를 활용하는 목적은 인터페이스 시스템 또는 요소들 상호간의 호환성을 구현하고 유지하기 위함에 있다. 

인터페이스를 문서화하기 위해 흔히 쓰는 일반적인 방법은 인터페이스 통제문서를 사용하는 길이다. 일반적인 법칙으로 ICD는 하드웨어 인터페이스를 문서화하고 있다. 여기에는 다음과 같은 사항이 포함되어 있다.

· 단일 또는 여러 페이지 길이의 문서로 제시된다. 예를 들면, 도면통제, 컴퓨터 목록화 또는 수십 장의 세부사항으로 제시
· SPS, 품목개발규격 또는 IRS 요구사항에 대응한 세부 설계 솔루션으로 사용
· 전기, 기계 또는 광학 분야 인터페이스 특성 문서화
· 운용기술, 전선도식 도표, 아셈부리 도면 및 핀-아웃을 포함한 커넥터 세부도면 포함 제시
· 산업표준으로 설정되거나 계약으로 제시된 표준 그래픽 심벌 사용

· 모든 인터페이스 이해관계자가 ICD 내용을 동의하고 나면, 모든 관련 문서를 승인, 베이스라인 설정, 형상통제 및 공식적인 의사결정에 따라 제시된다. ICD는 형상통제위원회 또는 ICWG에 파견하여 통제된다.

3. 인터페이스 통제문서 개요
ICD는 계약이나 조직부서에서 특정 포맷을 제시하지 않는 한, 자유롭게 작성된다. ICD를 구조화하는 데에는 애플리케이션에 따라 다양한 방법이 있다. 가장 중요한 개요 부분은 다음과 같은 특정 전통적인 규격 형태로 작성된다.

· 1.0 서론
· 2.0 참조문서
· 3.0 요구사항

기본적인 구조를 넘어 기계, 전기 및 광학과 같은 인터페이스의 물리적 특성을 나타내는 3.0 요구사항 절에 주의를 기울여야 한다.

4. ICD/IDD 문서 수량
인터페이스를 식별하는데 먼저 알아야 할 점은 얼마나 많은 ICD/IDD 문서가 필요한지를 결정하는 일이다. 각 제품에 대하여 추상적 레벨과 관계없이 다음과 같은 그림 1에 나타난 옵션을 고려해야 한다.

· 옵션 A : 제품 A의 모든 인터페이스를 정의하기 위해 하나의 ICD를 생성하는가?
· 옵션 B : 각 제품 A 내부 인터페이스에 대하여 개별 ICD를 생성하는가? 예를 들면, A1~A2 ICD, A2~A3 ICD, 또는 A1~A3 ICD를 들 수 있다.

이러한 질문의 답에는 여러 가지 방법이 있다. 첫째, 당신이 제시한 각 문서는 유지하기 위해 비용이 증가한다. 일반적인 법칙으로 다음과 같은 경우가 아니면, 별도의 ICD/IDD 문서를 작성하지 마라.

· 정보의 양이 대형 페이지를 지니게 되면 다루기가 힘들게 된다.
· 지적 재산, 고유 데이터 그리고 안보적인 이유로 세부 내용을 별도로 취급할 수 있다. 이를 판단하기 위해 특정 인터페이스에 대한 접근을 인가된 사람에게만 부여하게 된다.

제품 레벨 및 그 하위레벨에서 그 품목의 모든 내부 인터페이스에 대하여 단일의 ICD로 시작하도록 하라. 왜 외부적인 인터페이스가 없느냐는 질문을 해 보아도 좋다. 여기에는 두 가지 이유가 있다. 첫째, 한 품목의 외부 인터페이스가 대상품목이 한 요소가 되는 아키텍처 일부분으로 차 상위 레벨 팀에 의해 통제되고 소유된다. SEIT가 제품 A의 외부 인터페이스를 소유하고 통제하도록 한다. 둘째, 한 품목의 인터페이스를 단일 문서로 제시하게 되면 그 문서가 크지 않을 경우, 독자에게 매우 편리하다.

5. 왜 유일한 ICD와 IDD로 작성되는가
앞서 ICD에 대한 논의는 왜 각 인터페이스에 대하여 별도의 ICD와 IDD 문서가 필요한지에 대한 새로운 의문이 발생한다.
첫째, 하드웨어 ICD와 소프트웨어 IDD 세부자료를 다 커버하는 단일 인터페이스 문서는 가질 수 없다는 것이 일반적인 법칙이다. 잠재력이 있는 리더는 여러 가지 문서를 연구하거나 추정할 필요 없이 한 문서에 단일 인터페이스에 대한 모든 세부사항을 제시하는 길이 합리적일 수 있다.

일반적으로 두 개의 문서를 다루는 것보다 하나의 문서를 다루는 것이 작성하고 유지하는 비용이 덜 든다는 사실을 생각해야 한다. 그러나 변경사항과 관계있든 없든 간에 모든 인터페이스 승인 이해관계자에게 변경사항을 나누어주는 일이 성가시고 비용도 많이 들게 된다는 사실이다. ICD/IDD 사용자는 무엇이라고 말하는가?

· 소프트웨어 엔지니어와 프로그래머는 전기 도식, 전선 도표 및 기계도면에 무관심하다.
· 하드웨어 엔지니어는 소프트웨어 데이터에 대한 도표 목록을 보는 데 관심이 없다.

 

따라서 다음과 같은 질문에 답해야 한다.

· 모든 품목의 인터페이스를 식별하고 있는가?
· 이해관계자와 협력하여 특히, 제품통합팀(IPT)과 함께 일하고 있는가?
· 유일한 ICD/IDD 또는 통합된 ICD/IDD에 대한 효용성을 구분하라.
해당 품목이 하드웨어와 소프트웨어 인터페이스를 요구한다는 결정이 내려지면, 모든 하드웨어 또는 소프트웨어 인터페이스가 하나 또는 여러 개의 ICD/IDD 문서로 작성되어야 하는지를 결정해야 한다.

지금까지 우리가 관심을 둔 초점은 개별적인 인터페이스에 있었다. 이는 비용과 리스크를 증가시키는 모든 고유의 인터페이스에 대한 잠재를 고려하지 않고 있다. 이제 우리는 그 초점을 이러한 두 가지 요인을 최소화하기 위한 인터페이스 표준화를 다루어 보기로 하자.

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