시스템 설계 및 개발

품목과 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. 시스템 엔지니어링 형상과 형상관리 베이스라인 비교

 

형상관리

일반적으로 형상을 관리하기 위한 활동은 형상을 식별하고 이를 통제 및 관리하는 활동으로 이루어져 있다. 따라서 형상 관리는 다음 네 가지의 상호 연관된 활동으로 이루어진다고 할 수 있다.

· 형상식별
· 형상통제
· 형상현황관리
· 형상감사

 또한 형상관리와 직접적으로 연관된 활동으로서는 데이터 관리와 인터페이스 관리가 있다. 형상관리 활동을 계획할 때에는 이상 여섯 가지의 모든 요소를 고려해야 한다.
 
1. 형상식별
형상을 식별하기 위해 다음과 같은 활동을 수행한다. 그리고 이를 공식적으로 승인하는 데 필요한 기준과 규격서를 작성하여 문서화해야 한다.

· 형상품목 선정
· 각각의 형상품목에 대해 필요한 형상문서 형태를 결정
· 각각의 형상품목에 대한 기능과 물리적 특성을 제시
· 인터페이스 관리 절차, 조직 및 문서체계 구축
· 내부 및 외부 인터페이스를 포함한 시스템/형상품목의 형상 구조를 제시하고 고유번호 및 식별방법을 보증
· 형상품목 식별 및 관련 형상문서 배포
 
2. 형상 문서화
 형상 문서화란 품목의 기능과 물리적 특성을 식별하여 정의된 자료를 보관하기 위하여 기술적인 문서로 작성하는 활동을 말한다. 이러한 문서는 개발단계에 따라 분명하게 제시되는 기능, 할당, 제품의 세 가지 기준의 세부 레벨 과정을 통해 개발되고 승인되며 유지된다. 따라서 이러한 형상문서는 세 가지 기준에 따라 작성된 기능, 할당 및 제품 형상 문서화라고 부른다. 이러한 문서는 주어진 개발 시점에서 시스템이나 시스템 컴포넌트에 대한 설명을 보다 분명하게 기술해 주고 있다.
 
3. 형상통제
 형상통제 활동은 형상 기준이 공식적으로 규정된 후에 시스템/형상품목의 모든 변경사항의 체계적인 제안과 심의절차, 우선순위 결정, 평가, 조정통제, 승인, 부인 및 적용에 관한 활동을 말한다. 이는 시스템 및 시스템의 형상품목에 대한 형상을 변경하고 통제하는 과정을 시행하고 통제하는 관리방법이다. 이러한 형상통제는 가시적으로 관리하는 방법을 제공하고, 제안된 변경사항과 관련된 모든 요인을 평가하도록 하며, 불필요한 변경을 미리 예방하고, 변경 우선순위를 결정하게 된다.
정부사업에 대한 형상통제는 모든 증거자료를 공식적으로 문서화하고 변경승인조직을 만들어 수립된 변경절차에 따라 이루어지고 있다. 형상변경과 통제절차는 그림 3에서 보는 바와 같다.

그림 3. 형상 변경과 통제 절차

4. 정부통제 기준으로 사용되고 있는 변경문서
정부의 형상관리기준 통제를 위해 사용되고 있는 문서로서는 엔지니어링 변경 제안서(ECP), 규격 완화 제안서, 규격 면제 제안서 등 세 가지 유형의 변경 제안 문서가 있다. 

· ECP는 형상 변경의 필요성을 식별한 다음 이를 공식적으로 제안하는 문서이다. ECP가 승인되는 경우에 새로운 형상기준이 설정되고 적용된다.
· 규격 완화 또는 규격 면제로 제안하는 경우, 이는 현재의 형상기준으로부터 일시적으로 벗어나는 것을 승인해 줄 것을 제안하는 활동이다. 이는 아직 공식적으로 규정화되지 않은 자료사용을 허용하는 활동이다. 따라서 규격 완화 및 규격 면제에 대한 제안이 승인되어도 설정된 형상기준은 변경되지 않는다.
 
5. 엔지니어링 변경제안서
ECP는 형상기준에 대한 변경사항을 설명하고 제안하는 문서이다. 분명한 변경 목적에 따라 각각 별도의 ECP를 작성 제출한다. 서류작업을 줄이기 위해 미리 통보하여 변경 가능성을 확인해 볼 수 있다. 이를 위해 공식적인 ECP를 제출하기 전에 예비 엔지니어링 변경 제안서 또는 선행 변경 통지서를 사용할 수 있다. 공식적인 승인 과정에 따른 시간과 노력을 줄이기 위해 제시된 예비 변경 제안서는 이를 검토하고 작성하는 정부와 계약업체의 통합팀을 통해 보다 능동적으로 이루어질 수 있다. ECP는 Class I 또는 Class II로 구분된다. I급 변경사례는 다음 표 2와 같다.

표 2. I급 변경 사례

Class I 변경사항은 형상을 변경하기 전에 반드시 정부의 승인이 필요한 경우이다. 이러한 변경사항은 기준 요구사항, 안전성, 인터페이스, 운용/서비스 능력, 사전 조정, 숙련도를 포함한 휴먼 인터페이스 또는 교육훈련에 대한 문제로부터 기인할 수 있다.
Class I 변경사항은 또한 이미 제공된 시스템을 개조, 변형 및 이와 유사한 방법을 통해 새로운 형상으로 성능 개량하는 데 주로 사용된다.
또한, Class I ECP는 예를 들면, 형상기준에 직접적인 영향을 주지 않는 계약사항, 즉 비용, 보증, 납품, 또는 데이터 요구사항을 변경하는 경우에도 적용된다. 이러한 Class I ECP는 일반적으로 정부의 사업관리자나 지정 대리인이 운영하는 공식적인 형상통제위원회(CCB)를 통해 사업부서가 승인토록 한다.
Class II 변경사항은 현재의 형상은 그대로 유지하면서 문서를 수정하는 경우를 말한다. 이는 미미한 모순, 오타 및 기타 유지관리에 대한 변경사항을 적용한다. 따라서 Class II는 문서가 변경되었지만, 제품의 형상은 변경되지 않는 경우에 적용된다.
일반적으로 Class II ECP는 정부에서 지명된 대리관리인에 의해 처리된다. 따라서 Class II ECP는 변경이 적절하게 분류되었다는 정부의 동의만이 필요하다. 국방의 경우, 국방계약을 관리하는 계약부서에서 ECP의 구분을 결정할 수 있어 계약업체의 권한이 점차 확대되어 가고 있다.
그림 4는 ECP에 관련된 핵심적인 요소를 표기하는 방법을 나타내고 있다. 

그림 4. ECP 표기방법

1급 또는 2급 분류와 예비 또는 공식 ECP의 형식, 위급, 긴급 및 보통으로 구분된 우선순위와 결함사항을 수정, 안전성, 인터페이스, 호환성, 운용 및 ILS, 비용절감, 가치공학, 생산 중단 및 기록제한 등의 적용코드를 분류하고 있다. 그림 3에 언급된 예비 ECP는 제안된 ECP를 설명하는 공식적인 ECP의 단순 버전이다. 이는 변경에 따른 개략적인 일정과 비용을 제시하고 있다. ECP 개발비용은 예비 ECP의 검토 결과 변경이 불필요하다고 판단되는 경우에는 무시된다. 예비 ECP는 그 형식과 절차 면에서 ECP와 다르다. 예비 ECP 및 선행변경통지서 모두가 이러한 프로세스를 공식화하는 데 사용되고 있다. 그러나 특정 프로그램에 맞도록 만들어진 양식도 함께 사용되고 있다.

6. 형상통제위원회
형상통제위원회(CCB)는 Class I ECP를 검토 및 승인하기 위하여 구성되며, 제안된 변경사항에 대해 승인 또는 거부를 권고한다. 일반적으로 사업관리자가 CCB 의장을 겸하여 최종 결정 권한을 갖고 있다. CCB 위원은 의견을 제시하고 권고는 할 수 있으나 결정 권한은 의장에게만 주어져 있다. 위원은 조달 분야, 프로그램 예산통제 책임자 및 CCB 사무국장인 형상통제 관리자를 포함하되 사용, 교육, ILS, 정비, 기술, 획득, 시험, 안전관리, 형상관리 등 수명주기 8대 주 기능 부서를 고려하여 수행해야 한다.
그림 5는 CCB 프로세스를 나타내고 있다.

그림 5. 형상 통제위원회

CCB 프로세스는 계약업체와 함께 적용된다. ECP 또는 예비 ECP에 대한 계약업체 요청은 정부의 식별된 형상변경을 제시하는 데 필요하다. 부서장의 검토 과정은 CCB의 수락에 앞서 정부의 계약 및 기술검토 적합성을 보장할 수 있도록 반영해야 한다.

7. 형상통제위원회의 관리방식
CCB 관리절차는 기본적으로 형상을 통제하는 과정이다. 그러나 CCB 의장의 결정은 계약 동의 및 프로그램 기준뿐만 아니라 형상기준에도 영향을 주기 때문에 매우 중요하다. 계약 정책, 프로그램 일정 및 예산에 관한 관심사항은 형상관리, 기술적 쟁점 및 제반 기술 활동 일정에 관련된 관심사항과 상충할 수도 있다. CCB 기술위원 및 의장은 기술적 필요성과 상충한 사항에 대하여 분명한 대안을 제시할 책임이 있다. CCB 의장은 다음과 같은 사항을 보장해야 할 뿐만 아니라 CCB 활동을 충분히 알리고 이를 준비할 책임이 있다.

· 정부/계약업체 기술 실무 그룹은 ECP 및 제반 지원 자료를 분석하고, CCB의 검토를 위한 의견을 준비하며, CCB를 지원할 수 있도록 해야 한다.
· 검토를 위해 모든 관련 정보를 준비해야 한다.
· ECP는 적절한 기능적인 활동을 통해 검토되어야 한다.
· 쟁점사항을 식별하고 제기해야 한다.
 
8. 형상통제위원회 문서
일단, 형상통제위원회(CCB) 의장이 ECP에 관련된 결정을 하고 나면, CCB는 결정 내용을 배포하고 다음과 같은 변경사항 이행과 이와 관련된 주요 정보를 식별할 수 있도록 CCB 에 대한 지침을 알려야 한다. 

· 이행계획(누가 무엇을 언제)
· 1차 및 2차 계약서
· 계약 일자
· 문서(도면, 규격서, 기술 매뉴얼 등), 관련 비용 그리고 일정 완료 일자
· 설계 및 발행되는 지침 또는 순서의 식별
 
9. 규격 변경 또는 규격 완화 제안서
규격 변경은 특정 유닛의 수량이나 특정 시기에 따른 성능 또는 설계 요구사항의 변경을 위하여 품목을 제조하기 전에 인가해 주는 특별 서면 승인 방법이다. 규격 완화는 명시된 요구사항에서 벗어나지만, ‘현재(as is)’ 상태나 또는 이를 수리하여 사용 적합한 형상품목을 허용하기 위한 서면 승인 방법이다. 규격 변경과 규격 완화 제안서는 시스템의 설계 및 성능에 영향을 줄 수 있지만, 이를 일시적으로 해당 기준에서 벗어나는 경우를 말한다. 따라서 기준 내용은 그대로 유지되지만 다른 불일치 형상이 수용 가능한지를 결정하는 활동이다.
이와 같이 수용 가능한 대안은 지원 요소에 영향을 미치지 않고 영향을 받는 시스템이 효과적으로 운용될 수 있으며 아무런 후속 작업이나 수정이 요구되지 않아야 한다. 정부사업의 경우, 불일치된 유닛을 수용할 때 정부 계약상 ‘고려사항’을 별도로 제시해야 한다.
규격 변경 제안서와 규격 완화 제안서의 차이는 규격 변경 요청은 대상 유닛의 최종 조립 이전에 적용되며, 규격 완화 요청은 대상 유닛의 최종 조립 또는 수락시험 완료 후에 적용된다는 점이다.
 
10. 형상 현황 관리
 형상 현황 관리는 형상을 효과적으로 관리하는 데 필요한 정보를 보고하고 기록하는 활동으로써 다음과 같은 내용을 포함하고 있다. 

· 승인된 형상문서 목록
· 형상식별과 관련하여 제안된 변경, 규격 변경 및 규격 완화 현황
· 승인된 변경사항 이행상태
· 운용상의 재고목록을 포함한 모든 유닛의 형상
 
11. 형상 현황 관리의 목적
 형상 현황 관리는 다음과 같은 내용에 의해 형상 관리에서 요구되는 모든 정보를 제공한다.

· 관련 자료의 수집과 기록
 - 기준 형상
 - 제안된 변경사항
 - 승인된 변경사항
· 관련 정보의 배포
 - 승인된 형상
 - 제안된 변경사항의 현황과 영향
 - 승인된 변경사항의 요구사항, 일정, 영향 및 현황
 - 조달된 품목의 최신 형상
 
12. 형상감사
 형상감사는 형상문서와 연관된 시스템과 시스템 요소의 일치성을 검증하는 데 사용된다. 형상감사는 시스템 개발에 있어 중요한 마일스톤이지만, 이는 독립적으로 이루어지지 않는다. 설계의 성숙도를 평가하는 전반적인 프로세스에서 감사가 어떤 역할을 하게 되는지를 다음 장에서 설명하고자 한다.
기능 형상감사(FCA) 및 시스템 검증검토(SVR)는 생산단계 및 개발단계의 생산준비와 소량 초도생산(LRIP) 시기에 수행된다. FCA는 형상품목의 실질적인 성능이 규격요구에 부합하는지를 검증함에 그 목적이 있다. SVR은 FCA를 수행한 후 시스템-레벨에서의 감사 역할을 수행한다. 일반적으로 물리적 형상감사(PCA)는 초안 수준의 기술데이터 패키지(생산기준문서)에 대한 대표적인 생산 유닛의 공식적 검사활동으로써 시험생산 및 개발단계에서 수행된다.
FCA 또는 PCA 활동을 통한 오늘날 대부분의 감사는 최종적인 FCA 또는 PCA가 프로그램 개발의 정상적인 흐름에 대하여 부담이나 방해되지 않도록 품목을 점진적으로 감사하는 일련의 연속적인 검토 형태로 발전하고 있다.

 

‌원칙

앞서 논의된 사항을 요약해 보면, 시스템 형상 식별 실무를 통제하고 있는 원칙을 설정하는 기준을 제공하고 있다고 볼 수 있다.

· 원칙 1 : 시스템의 모든 컴포넌트는 품목이다. 그중 일부는 자체 개발을 위한 형상품목(CI)이며 기타는 외부 구매를 위한 상용품목(COTS), 또는 기개발 품목(NDI)이다.
· 원칙 2 : 형상품목(CI)개발은 모든 COTS/NDI 품목으로서 충족되지 않거나, 비용 효과적이 아니거나 기술, 비용 및 일정 요구사항을 충족하지 못할 때 고려하는 방법이다.
· 원칙 3 : 모든 시스템/개체는 일곱 가지 설계형상(제시된, 설계된, 제작된, 검증된, 확인된, 유지된, 생산된)을 지니고 있다. 이는 실제적이며 일치되어야 한다.
· 원칙 4 : 모든 시스템은 세 가지 예비 개발형상 베이스라인을 지니고 있다. 1) 시스템 요구사항 또는 기능 베이스라인, 2) 할당 베이스라인, 3) 제품 베이스라인. 생산되고 있는 시스템은 생산 베이스라인을 가지고 있다.
· 원칙 5: 계약 요소에 따라 획득자는 시스템 성능규격(SPS)을 소유하고 통제한다. 시스템 개발자는 SPS를 획득자 계약담당자(ACO)에 의해 제공되고 승인된 계약방침에 따라 유지토록 한다.
 ‌

요약

시스템 형상식별 논의를 통해 우리는 다양한 장비 요소가 어떻게 명명되는지를 살펴보았다.
이들은 시스템 엔지니어들이 일반적으로 사용하고 있는 용어들이다. 이는 각 애플리케이션의 콘텍스트를 이해하기 위해 제시하고 있다.

1. 일반적 예제
(1) 개요에서 식별된 질문사항으로부터 우리가 배워야 할 점에 대하여 답하도록 하라.
(2) 이전 장의 일반적 예제 또는 신규 시스템을 선정한 후 이 장에서 나온 사항을 적용해 보자. 특별히 다음 사항을 적용해 보라
   (a) 다중레벨 시스템 아키텍처 분석을 통해 형상품목 대상 품목을 제시해 보라.
   (b) 어느 품목을 COTS 또는 NDI로 획득할 것인가?

2. 조직중심예제
(1) 당신 조직의 지휘체계를 살펴보고 어떤 요구사항이 CI, HWCI, COTS, NDI로 분류될 것인지를 식별해 보라.
(2) 내부 계약 프로그램을 선정한 다음 품목이 어떻게 CI, HWCI, CSCI, NDI 품목으로 선택했는지를 질문해 보라.
   (a) 계약사항에 CI 선정기준이 제시되어 있는가?
   (b) CI, HWCI, CSCI를 규격서 트리와 비교해 보라.
   (c) 발견한 사항을 기록해 보라
(3) 위 계약 프로그램에서 펌웨어가 어떻게 개발, 관리 및 통제되고 있는가?
(4) 다른 조직에서는 CI, HWCI, CSCI, COTS, NDI 및 펌웨어를 어떻게 제시하고 있는지를 인터넷 사이트로 검색해 보라.

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