[시스템 형상 (2)] 품목과 CI에 대한 소유권 부여
품목과 CI에 대한 소유권 부여
개발규격이 진화함에 따라 CI 개발책임은 통합제품팀(IPT)이나 개발팀과 같은 소유자에게 그 책임을 부여해야 한다. 그림 1은 이러한 사례를 보여주고 있다. 여기서 어떻게 시스템 아키텍처가 제품 구조라인을 따라 분할되는지를 유의하라.
그림 1. CI 소유권과 책임 부여
이는 특별히 운용 단어로서의 ‘제품’에 대한 주요 포인트이다.
통합제품팀을 설정한 프로그램에 대하여 각 IPT는 ‘제품’ 개발에 초점을 두어 자기가 담당하고 있는 제품에 인터페이스가 되어있는 품목을 개발하고 있는 IPT와 상호 인터페이스를 협력하도록 한다. 예를 들면, IPT 1은 상호 인터페이스 설계 쟁점사항을 IPT 2와 협조한다.
한 제품을 개발하는 책임은 오로지 하나의 IPT에 국한된다. 다중 레벨 품목의 사이즈, 복잡도 및 위험 정도에 따라 그림 1에서와 같은 하나 또는 그 이상의 제품에 대한 책임을 부여해도 좋다. 중간 정도의 복잡도와 위험을 지닌 제품 A와 B를 개발하는 책임은 IPT 1에 부여된다. 반대로 제품 C에 대한 책임은 그 자체의 복잡도와 위험에 따라 IPT 2에 부여된다. 이는 우리로 하여금 최종 포인트를 가져다준다.
가끔 시스템 엔지니어가 IPT 조직구조를 개발한 후에 제한된 아키텍처 형상을 식별하기 위해 SEIT가 감독하도록 한 후에 IPT를 떠나기 때문에 문제가 발생되기도 한다. 이러한 경우, IPT에 부여된 책임 아래 제품 A와 B는 물리적 인터페이스와 상관없이 제품이나 하부시스템으로 식별되어 함께 묶어서 다루어진다. 이때 IPT는 전체적인 개발규격을 개발하기 시작한다.
대부분 경우, 제품 A와 B는 관계가 없으며, 따라서 인터페이스가 전혀 없다. 이제까지 IPT는 양 제품을 ‘블랙박스’로 함께 검증하도록 요구된다. 이러한 시스템 형상 식별 의사결정을 수정하고 피하도록 하라. 가끔 이러한 결정이 시스템 아키텍처 개발과 IPT 운영에 대한 부분적인 지식을 가진 ‘영웅’에 의해 결정되어 계약 달성에 심각한 영향을 주기도 한다.
아키텍처 품목 영역 형태 인식
산업혁명은 규모의 경제 이점을 가져오기 위하여 예측 가능한 방법을 사용하여 모듈화와 상호교환 가능한 컴포넌트를 사용하고 표준화하는 새로운 개념을 가져왔다. 시스템, 제품, 하부시스템, 아셈부리, 하부 아셈부리 및 부품에 대한 추상적 레벨에서의 논의가 이러한 개념에서 비롯되고 있다.
모듈화 개념은 모든 품목과 형상품목이 모듈화 박스로서 형성되는 시스템 엔지니어링 사고로 쉽게 리드해 간다. 시스템의 시스템(SOS) 접근방법은 상위레벨 시스템으로 통합된 ‘박스’ 형상품목 사고를 보다 더 강조하고 있다. 그러나 통합이란 전통적인 ‘박스’ 영역을 넘어 일어나고 있는 시스템이다. 일반적으로 시스템은 다음 두 가지 제품/하부시스템 부류로 구성되어 있다.
· 특정 제품/하부시스템 임무
· 특정 제품/하부시스템 임무로 부여된 제품/하부시스템 인프라 구조
그림 2는 이러한 유형의 아키텍처를 보여주고 있다. 다음 예제를 생각해 보자.
그림 2. 상호 연결 CI 품목에 대한 시스템 형상식별
임무 시스템으로서의 오피스 빌딩 시스템은 잘 정의된 아키텍처 영역의 ‘박스’로 구성되어 있다. 계층 구조면에서 우리는 오피스 빌딩 개별 바닥을 하부시스템 레벨 CI로 간주하고 있다. 그러나 모든 바닥과 오피스 영역을 나타내는 배관, 전기, 난방, 통풍 및 냉방(HVAC) 시스템 CI는 어떻게 다루어야 하는가? 우리는 바닥과 오피스를 임무 기준 하부시스템으로 말할 수 있다. HVAC 시스템과 같은 하부시스템 인프라 구조는 각 바닥과 연계된 배관, 전기, 기타 시스템으로 볼 수 있다.
항공기 및 자동차와 같은 시스템은 유사한 형상을 보여주고 있다. 예를 들어 연료 시스템과 전기 시스템은 전체 구조와 연계되어 있다.
1. 시스템 엔지니어링 연계
이제 당신은 왜 이러한 활동이 시스템 엔지니어링과 연계되는지를 아마도 알고 싶어 할 것이다. 무엇보다 먼저 단순하게 이 활동이 시스템 아키텍처를 도출하는 수단이기 때문이다. 이러한 활동의 중요한 점은 시스템 조달단계에서 시스템 비용을 추정해야 한다는 사실이다. 따라서 시스템 엔지니어는 다음과 같은 활동을 수행해야 한다.
· 특정 임무와 CI 품목에 상호 연계된 인프라 구조 시스템의 존재를 인식해야 한다.
· 시스템 형상 영역에 대한 동의를 설정하는 데 필요하며 시스템의 내용 범위를 나타내는 CWBS 사전을 통해 각 요소가 특정 임무와 인프라 구조 영역 내에 포함되었는지를 확인해야 한다.
비용 추정 활동, 요소 활동 성능 벤치마킹, 계획 대비 실제 업무 진도 파악을 하는 데 가장 중요한 점은 계약 업무활동 분해구조(CWBS)이다. 우리가 여러 번 반복해 온 것처럼, 자체 임무 장비 요소로서의 CWBS가 시스템 아키텍처로부터 도출된다는 사실이다. 안타깝게도 대부분의 기관들은 이를 거꾸로 수행하고 있다. 말하자면 위험하게도 먼저 CWBS를 도출한 다음 어설프게 도출된 CWBS에 맞추어 시스템 아키텍처를 맞추려고 하니 얼마나 엉터리인가!
다시 한 번 오피스 빌딩 사례로 돌아가 보자. 당신은 다음 자료를 기초로 어떻게 비용을 산출할 수 있는가?
· 내장된 배관, 전기, HVAC 및 구조적 컴포넌트와 함께 계층 구조적인 방의 범주?
· 계층 구조적인 특정 임무 방 및 분리된 인프라 구조, 전기, 배관 및 HVAC 시스템?
빌딩, 가옥, 항공기와 같은 시스템에 대하여 CWBS 사전은 독자적인 CWBS 비용요소로서의 구조, 전기, 배관, HVAC 및 통
신과 같은 인프라 구조 시스템을 범주로 제시한다. 이는 분야별로 전문화된 계약자가 존재하고 있는 전기, 배관, HVAC, 네트워크 및 시청각 통신요소별로 도출된다.
만일 특정 임무와 인프라 구조 하부시스템을 가옥 구조에다 합산해서 CWBS를 제시한다면 무슨 일이 발생할 것인지를 상상해 보라. 현관 거실, 부엌 및 침실 하부시스템마다 내부 전기, 기계 및 배관요소를 산정해야 할 것이다. 이러한 방법은 검증 관점에서 볼 때, 각 하부시스템은 개별적으로 검사되고 검증되어야 할 것이다. 자 이제 빌딩 검사자에게 오늘은 부엌에 대한 HVAC, 전기, 구조 요소를 ‘검사와 검증’하도록 하고 일주일 후에 거실에 대한 활동을 하도록 한다면, 이 얼마나 우스꽝스러운 일이 되겠는가!
따라서 최소한 당신의 시스템을 개발, 구매, 통합 및 검증하기 위해 상호 의존성을 최소화하도록 제시할 수 있는 논리적, 거동 및 물리적 요소로 형성된 계층구조로 분할해야 한다. 어느 제품/하부시스템은 특정 임무이고 다른 것은 특정 임무 하부시스템을 수행하는 인프라 구조 하부시스템이라는 사실을 인식해야 한다. CWBS는 시스템 아키텍처를 수용할 뿐만 아니라 비용 추정과 계약 수행 노력을 할 수 있도록 구성해야 한다.
부가적으로 이 방법은 해당 분야에 전문화된 벤더와 함께 쉽게 하청계약을 할 수 있도록 인프라 구조 형상품목에 대한 별도의 규격서를 마련하는 것이 바람직하다. 만일 인프라 구조 개체가 특정 임무 형상품목에 내장되어 있다고 하면, 시스템 엔지니어는 인프라 구조 개체에 대한 요구사항을 분할토록 하고 별도의 조당 규격을 생성해야 한다. 부가적인 활동이 필요 없도록 하라!
2. 여러 CI 품목을 사용하는 경우
우리는 시스템의 모든 품목이 유일하리라고 생각하지만, 시스템과 제품은 가끔 시스템 전반에 대하여 단일 CI 품목을 여러 개 사용하는 경우가 있다. 시스템 엔지니어와 SEIT의 역할은 개발비용, 일정, 리스크를 감소해야 한다. 당신은 이를 위해 컴포넌트와 인터페이스를 표준화하기 위한 길을 모색하고 시스템 설계 솔루션을 진화해 가도록 노력해야 한다. 최소한 하나의 일상적인 CI 설계로 충족되는 품목을 별도 설계로 생성하는 어리석은 반복을 하지 않도록 노력하라.
형상 베이스라인
앞서 논의된 바에 따라 시스템 개발은 추상적인 시스템 성능 규격서(SPS) 요구사항을 물리적 솔루션으로 전환하도록 요구하고 있다. 이와 같은 전환은 추상적으로 복잡한 내용을 보다 쉽게 관리할 수 있는 하위레벨로 분할하거나 확장해야 한다. 궁극적으로 세부설계는 도면과 소프트웨어 설계와 같은 설계 요구사항이 시스템의 모든 항목에서 조달, 제작, 코딩을 세부적으로 지원하기 위해 충분한 상태에 이르기까지 성숙해 가야 한다.
상위레벨 의사결정을 정제함으로써 하위레벨 설계 의사결정은 전반적으로 상위레벨 설계 의사결정의 안정을 가져오는데 달려있다. 그렇지 않을 경우, 전체적인 솔루션은 다중 레벨에서 혼란을 가져온다. 따라서 상위레벨 의사결정이 안정화함에 따라 개발형상으로서의 솔루션이 진화되어가는 상태를 추적하고 통제하는 것이 중요하다.
1. 개발형상
개발형상은 다양한 성숙단계에서 시스템 설계 솔루션의 진화과정을 추적하는 일련의 형상 상태를 말한다. 각 형상은 시스템 엔지니어에게 형상 변경을 통제하면서 시스템 설계 솔루션을 진화하고 성숙해 가는 과정을 지적 통제를 통해 유지하도록 한다. 따라서 개발형상 범주는 계약 시점으로부터 시스템이 생산될 때까지 전 기간에 걸쳐 수행된다.
시스템 엔지니어링 관점에서 볼 때, 다양한 개발단계에서 성숙도를 나타내는 여섯 가지 형상 분류 형태를 아래 단계에서 볼 수 있다.
단계 1 : ‘제시된’ 형상
단계 2 : ‘할당된’ 형상
단계 3 : ‘설계된’ 형상
단계 4 : ‘제작된’ 형상
단계 5 : ‘검증된’ 형상
단계 6 : ‘확인된’ 형상
단계 7 : ‘유지된’ 형상
단계 8 : ‘생산된’ 형상
위의 시스템 엔지니어링 형상 형태를 더 자세하게 설명해 보자.
· ‘제시된’ 형상 : 이는 시스템 요구사항 베이스라인을 통해 추적되고 관리되는 SPS와 하위레벨 규격 상태를 말한다.
· ‘할당된’ 형상 : 이는 시스템 요구사항 베이스라인으로부터 품목으로 요구사항을 할당하는 상태를 말한다.
· ‘설계된’ 형상 : “제시된” 형상이나 시스템 요구사항 베이스라인으로부터 도출되어 지금까지 승인된 개발형상 베이스라인을 말한다. “설계된” 형상은 최초로 시스템 설계검토(SDR) 단계에서 제시된 다음 이 베이스라인에 수정 및 변경을 추적하고 관리한다.
· ‘제작된’ 형상 : 이는 공식적인 검증 이전에 어느 추상적 레벨에서의 초도생산을 위한 개발형상 상태를 말한다. 일반적으로
“제작된” 형상은 물리적 시스템을 “설계된” 형상으로 매칭하기 위하여 일련번호 효용성 형상통제기법을 사용한다.
· ‘검증된’ 형상 : 이는 “제시된”, “설계된” 및 “제작된” 형상이 상호간에 일치하고 규격요구사항을 충족하는 공식적인 시스템 검증검토(SVR) 종료단계에서의 물리적 시스템 상태를 말한다.
· ‘확인된’ 형상 : 이는 기술된 야전운용환경과 조건에서의 운용시험평가 기간 중 사용자를 대표하는 독립시험기관(ITA) 또는 사용자에 의해 확인된 물리적 시스템 상태를 말한다.
· ‘유지된’ 형상 : 이는 야전에서 사용자에 의해 운용 및 유지되는 물리적 시스템 형상 상태를 말한다. 시스템 엔지니어링과 형상관리 관점에서 “유지된” 형상문서를 지키는 데 실패할 경우 생산으로 계획된 개발 시스템의 주요 리스크 사항으로 나타난다.
· ‘생산된’ 형상 : 이는 시스템이나 제품의 양산 수량에 맞추어 제작하기 위해 사용된 생산 베이스라인을 말한다.
· ‘유지된’ 형상은 시스템 엔지니어에게 치명적인 요소이다. 이는 야전에 배치된 운용 시스템 형상을 문서화한 것이다. 사용자가 ‘유지된’ 형상 문서화를 유지함에 있어 예산이나 권한이 없어서 LAX가 되지 않도록 하는 것이 바람직하다. 그 결과는 시스템 개발자에게 주요 리스크 요소인 형상문서와 일치하지 않는 물리적 시스템이나 제품이 되고 만다.
2. 개발형상 단계화 또는 통제점
개발형상이 일련의 설계 및 개발단계를 통해 진화함에 따라 시스템 설계 솔루션의 진화와 성숙에 대하여 획득자, 사용자, 시스템 개발자 상호간에 동의를 구하는 것이 매우 중요하다. 계약 형태와 각 이해관계자가 어떠한 의사결정 프로세스에 대한 규정을 적용하느냐에 따라 우리는 이를 단계화 또는 통제점으로 사용하게 된다.
주요 기술검토 이벤트로 구성된 단계화 또는 통제점은 시간이 지남에 따라 더 세부적이고 하위 추상적 레벨로 진행함으로써 진화하고 있는 시스템 설계 솔루션의 성숙도와 단계를 제시하려고 한다. 우리는 이러한 활동을 일련의 형상 베이스라인으로 수행한다.
형상관리 관점에서 볼 때, 네 가지 형상 베이스라인이 있다.
· 시스템 요구사항 또는 기능 베이스라인
· 할당 베이스라인
· 제품 베이스라인
· 생산 베이스라인
진화하고 성숙해 가는 개발형상에서 식별된 두 가지 관점을 유의토록 하라. 1) 시스템 엔지니어링 형상 관점, 2) 형상 관리 관점. 이 두 가지 상호관계는 표 1에 제기되어 있다.
표 1. 시스템 엔지니어링 형상과 형상관리 베이스라인 비교
민성기 박사 _ 시스템체계공학원장 (sungkmin0@gmail.com)
