[시스템 형상 1] 품목-시스템 빌딩블록
[시스템 형상 2] 형상 조합

10. 형상품목 영역
대부분 사람이 믿기 쉽지만, 품목과 형상품목은 물리적으로 그 영역이 분명하게 분할되어 있지 않다는 사실이다. 이는 앞서 논의한 바와 같이 좋은 설계 실무에 위반되는 길이기 때문이다. 일반적으로 CI는 다음과 같다.

· HWCI 요구 규격(HRS) 또는 CSCI 요구 규격(SRS)과 같은 개발 규격에 구속되어 있다.

· 컴퓨터 시스템, PCB 보드, 소프트웨어 애플리케이션 등과 같이 시스템 하부시스템, 아셈부리, 또는 하부아셈부리와 같은 물리적 영역 내부에 놓여있다.

· 각각의 HRS 또는 SRS에 대하여 검증되어야 한다.

이점을 보다 쉽게 이해하기 위하여 다음 예제를 살펴보자. 부정확한 접근방법의 사례로써, 회사는 워드 프로세서 소프트웨어 애플리케이션을 개발하는 계약을 했다고 하자. 잘못된 접근방법을 사용할 경우, 소프트웨어 CSCI는 다음 물리적 품목으로 구성된 CSC로 생각할 수 있다.

· 데스크톱 컴퓨터(HWCI)
· 프린터(HWCI)
· 기타 네트워크에 연관된 HWCI

따라서 만일 CI, HWCI, CSCI가 물리적 품목 내에 포함된 통합품목으로 구속되고 규격화된 독립적인 성능 또는 개발규격을 요구하고 있다면, 여러 HWCI 영역을 넘어섰을 때 하나의 품목으로서 소프트웨어를 어떻게 시험할 수 있는가?

CI는 모든 필수 기능성을 독립적으로 지닌 입력과 출력 블랙박스로 된 독립적인 시험항목으로 시험 되고 검증되어야 한다는 사실을 기억하라. 위에서 제시된 영역의 제약사항에 더하여 데스크톱 컴퓨터와 같은 단일 HWCI 기기로서 CSCI를 시험해야 하는 기대를 해야 한다.

분명히 이는 CSCI의 CSC가 시스템을 넘어 여러 HWCI 기기(데스크톱 컴퓨터, 프린터, 네트워크 등)로 나타내어야 한다. 정확한 접근방법은 각각 기기에 CSCI를 요구하고 있다.

그림 5. 시스템 형상문서

11. 형상식별 책임
잘 알려지고 다중 분야로 구성된 의사결정 프로세스로서의 형상식별은 연관된 이해관계자와의 협력을 요구하고 있다.
믿고 있는 많은 사람과 반대로 주요 의사결정 이해관계자로부터의 입력 없이 공백 상태에서 분명한 관련 당사자를 대표하는 한 사람에 의해 의사결정을 할 수 없다는 것이다.

다중레벨 개체 아키텍처가 진화함에 따라 형상관리자(CM)/소프트웨어 형상관리자(SCM), 리드 시스템 엔지니어 및 기타 시스템 엔지니어들은 시험 시기와 함께 CI와 품목을 식별하기 위해 정확한 접근방법을 선정하기 위해 함께 노력해야 한다. 이를 통해 잘못된 의사결정이 되지 않도록 유의해야 한다.

우리는 이 점에서 형상식별에 대한 기본 논리와 어떻게 다중 레벨 시스템 아키텍처를 적용하고 있는지를 수립할 수 있었다. 이러한 논의는 각 CI, HWCI 및 CSCI에 대한 개발규격을 준비하기 위한 내부 개발 기간에 필요성을 제기했다고 본다. 첫 번째 초도 개발형상은 직선적인 프로세스로 볼 수 있다. 여기에 두 가지 주요 질문이 발생한다.

· 이러한 규격을 새로운 능력과 보완이 형성된 설계에 추가로 부여함에 따라 생산제품에 대한 규격을 어떻게 유지할 수 있는가?
· 이미 야전에 배치되어 재개발되어야 할 시스템이나 제품에 대하여 이러한 영향을 어떻게 반영해야 하는가?

이 문제를 해결하기 위해 우리는 형상의 효율성을 다루어 보도록 하자.

12. 형상 효율성
생산 시스템은 여러 해를 거듭하면서 신규 기술, 능력 및 향상이 시스템의 진화된 설계 솔루션으로 연결되어도 좋다. 이와 같이 물리적 형상이 변경된다. 따라서 다음과 같은 질문이 생긴다. 주어진 CI, HWCI, 또는 CSCI에 대한 형상변경을 어떻게 할 것인가? 형상관리란 형상 효율성에 입각한 개념을 통해 형상을 다루는 것을 의미한다. 

CI, HWCI, CSCI는 모든 요소로부터 분리하기 위해 고유 식별자를 부여토록 한다. 이는 1) 모델 번호, 2) 일련번호의 두 가지 레벨에서 발생한다. 따라서 해를 거듭하면서 물리적 형상이 변경될 때, 몇몇 회사는 단순하게 일련번호(S/N) XXX로 시작하는 효용성을 제시하고 또 다른 회사는 특정 버전을 관리하기 위해 모델 123456-1과 같은 모델 번호에 대시를 사용하기도 한다. 대부분 회사는 오늘날 버전자동화와 형상추적을 위해 CI, HWCI 및 CSCI에 바코드를 부착하고 있다.

버전을 부여함으로써 시스템 개발자는 여러 옵션을 제공하고 있다. 수명범주를 넘어 제품 라인을 진화적으로 추적하기도 하고 획득자에게 납품된 특정 카스터마이징 관리를 할 수도 있다. 모델 번호와 버전을 제시함에 따라 몇몇 벤더는 품목을 분류하기 위해 계약번호와 일련번호를 제공하기도 한다. 이러한 활동이 왜 중요한지를 시스템 엔지니어에게 확인하기 바란다.

13. 유효성에 입각한 규격서
시스템이나 제품 개발 기간에 다중 분야에 능력 있는 시스템 엔지니어는 개발형상을 나타내는 제품, 하부시스템, HWCI 및 CSCI에 대한 품목개발 규격(IDS)을 준비한다. 역시 비용이 제일 중요한 제약사항이기 때문에 대부분 초도 생산이나 제품은 일정과 기타 제약사항으로 인한 대부분의 비용-효과 솔루션을 대표하진 않는다. 초도 생산이란 단순히 규격 요구사항을 충족하는 솔루션이라고 볼 수 있다. 전형적으로 각 납품되는 제품은 계약/모델 번호와 일련번호가 주어진다. 

만일 시스템이 생산토록 계획된다면, 제품 엔지니어링이 설계향상, 컴포넌트와 원자재 선정과 조달, 제작방법 등을 통한 단위 비용을 감소시키기 위한 노력을 시작한다. 궁극적으로 이러한 향상은 앞서 S/N XXX로 시작되는 효율성을 지닌 수정된 품목 개발 규격을 제시하게 된다. 한 번 생산이 시작되고 나면, CI, HWCI, CSCI는 시간을 두고 진화된다. 초기 생산 기간에 개발형상 규격 보완이 변경이 발생할 때 제기되곤 한다.

따라서 생산품목 변경이 발생할 때, 규격 레벨과 효용성을 수정해야 한다. 이러한 일이 발생할 때, 해당 프로그램은 두 가지 선택이 발생한다. 그 형상에 유일한 신규 규격으로 만들든지 아니면 그 문서 내부에 있는 효용성에 유일한 카버 쪽과 규격 요구사항에 대한 모델 및 일련번호 효용성을 제시하는 길이다.

품목 및 형상품목 규격서 트리에 따라 조정

한 번 형상품목(CI)이 식별되고 나면, 다음과 같은 주요 질문이 생겨난다. 당신은 시스템의 제품구조 내에서 그 형상품목의 위치를 어떻게 알아내는가? 그 답은 CI가 그림 5에 나타난 시스템 아키텍처로부터 도출되는 규격서 트리에서 외적으로 식별된다.
여기서 SEIT는 그림 왼쪽 하단 부분에 있는 시스템 레벨 아키텍처를 생성하기 위해 시스템 성능규격서(SPS)를 분석한다. 이 아키텍처는 제품 A와 B로 구성된다. 품목 B_1에서 B_3까지 이루어진 제품 B는 내부적으로 자체 개발될 것이며 이는 CI로 명명된다. 시스템 아키텍처가 진화되어감에 따라 규격서 트리도 그림 우측 편에 나타난 바와 같이 진화해 간다. CI와 품목 명명에 따라 품목 개발 규격이 식별된다.

· 제품 A는 자체 제품 A 개발규격을 가지고 있다.
· 제품 B는 CI로서 품목 B_1에서 B_3에 이르기까지 요구사항을 포함하고 있는 제품 B 고유 개발규격을 가지고 있다.
· 제품 B_3은 개발에 대한 CI로 명명되므로 그 자체의 품목 B_3 고유 개발규격을 가지고 있다.

<다음호에 계속>

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