당신이 시스템을 개발할 때, 사용자, 획득자, 시스템 개발자에게 대답해주어야 할 네 가지 기본 질문사항이 있다.
첫째, 우리가 시스템과 제품 및 서비스를 개발하기 위해 투자한다면, 그들의 조직 임무달성을 위해 사용자에게 무슨 유용성을 줄 수 있는가?
둘째, 시스템 유용성이 있다면, 사용자 임무 적용에 적합하고 쉽게 그들의 비즈니스 모델로 통합될 수 있는가?
셋째, 시스템이 유용하고 적합하다면, 임무수행 시 운용 가용한가?
넷째, 그 조직에 유용하고, 적용에 적합하며, 요청 시 주어진 임무 수행이 가용하다면, 성공적인 요구레벨에서의 임무수행과 임무목적 달성에 효과적인가?
궁극적으로 시스템과 제품 및 서비스를 시험하는 내용은 사용자 임무수행과 임무목적 수행에 관한 임무와 시스템 효과도이다. 주어진 임무환경 조건과 제약범위 내에서 수행 불가는 사용자, 그들의 조직 및 대중에게 운용, 재정 및 생존 위험을 가져다준다.
시스템 엔지니어에게 가장 큰 시스템 엔지니어링 적용 중의 하나는 운용 및 시스템 효과 목표를 개발자가 이해하고 적용할 수 있도록 뜻있는 능력과 성능 요구사항으로 전환하는 데 있다. 도전해야 할 일은 시스템 엔지니어가 실무수행방법을 이해하기 위해 토픽에 대한 공식적인 교육훈련 부족 여부에 달려있다.
이 장은 시스템 엔지니어에게 가장 긴요한 도전 분야를 제시하고 있다. 사실상, 요구사항 식별, 분석, 할당 및 분할에 대한 훈련이다. 일반적인 실무로 이 분야는 시스템 엔지니어가 부족한 지식으로서 그 직무를 수행해야 하는 전문용어로 채워져 있다. 왜냐하면, 장황하게 나열하면 오히려 그 토픽을 잘 못 이해하게 되어 명료성과 이해도를 찾아내는 데 어려움을 겪을 수 있기 때문이다.
(*운용 가용성은 논의의 한 대상이다. 그러나 가용성은 수학적으로 신뢰성과 유지보수성의 함수임으로 우리는 가용성에 대한 논의를 미루게 된다. 이 토픽은 신뢰성, 가용성 및 유지보수성(RAM) 실무에서 논의하기로 한다.)

‌MOE·MOS·MOP·TPM 상호관계

대부분 엔지니어링 환경에서 시스템 엔지니어는 시스템, 제품 및 하부시스템에 대한 TPM을 식별하는 업무를 다룬다. 시스템 엔지니어들이 힘들어 하면 사업 책임자는 늘 그렇게 단순한 일을 가지고 왜 그렇게 어려워하느냐고 반문한다. 여기에는 두 가지 이유가 있다.
첫째, 대부분의 엔지니어들이 TPM이 무엇인지, 어떻게 구하는지, 그리고 왜 중요한지를 훈련되어 있지 않다는 점이다. 이는 조직 관리와 교육훈련 시스템이 잘 못되어 있기 때문이다.
둘째, 기술 프로그램을 관장하고 있는 시스템 엔지니어 책임자(LSE)와 시스템 엔지니어링 및 통합팀(SEIT)이 치명적인 MOE와 MOS를 하위레벨 TPM으로 연결하는 일을 수행하지 않고 있다는 점이다.
따라서 대부분의 엔지니어에게 TPM은 주어진 개발규격으로부터 전체적인 시스템 성능으로 상응하거나 아닌 요구사항을 임의적으로 선택해 왔다.
MOE, MOS, MOP, TPM이 상호 연계되어야 한다. 불행하게도 이들은 개별문서에 상관없는 정보사항으로 포함되어 있으며 몇몇 검토자가 머리로 연결시켜 생각하고 있다는 것이다. 이러한 상황에서 잠재되어 있는 위험은 시스템 성능규격(SPS) 작성 과정에 따라 필요한 요구사항을 놓치거나 과도하게 제시하기도 한다. 이를 좀 더 자세히 생각해 보자.
MOE, MOS, MOP, TPM 상호관계는 매우 혼돈스러울 수가 있다. 부분적인 어려움은 MOE, MOS, MOP, TPM의 근원을 분명하게 이해하지 못함에서 기인된다. MOE, MOS, MOP, TPM은 운용능력과 요구사항을 도출할 때 치명적인 벤치마크 측정에서 비롯된다. 이 파라미터는 사용자가 확인한 운용요구를 충족하고 획득자의 SPS 요구사항과 완전하게 일치하는 물리적 시스템을 도출하려는 의도와 연계된 추적성을 제공한다.

1. MOE·MOS·MOP·TPM의 연결
그림 1은 MOE, MOS, MOP, TPM 상호간의 관계를 보여주고 있다.

그림 1. MOE, MOS, MOP 및 TPM 관계

이 그림은 수직 점선에 의해 두 영역으로 구분되어 있다. 사용자와 획득자 도메인은 왼쪽에, 시스템 개발자 도메인은 오른쪽에 제시되어 있다.
(* 일부 획득자는 SRD 대신에 ORD로부터 SOO를 도출하고 있다. 이 콘텍스트에서는 SOO가 SPS의 요구사항 근원 또는 소스가 된다.)
신규 시스템을 고려할 때, 사용자는 상위레벨 목표기술서(1)를 작성한다. 시스템 엔지니어링 지식과 획득에 익숙하지 않은 사용자는 그들의 시스템 개발 기술과 계약사항을 대신하는 획득자를 사용한다. 획득자는 사용자와 함께 문제 영역을 이해하고 솔루션 영역을 구속하기 위해 상호 협력한다. 이 프로세스의 일환으로 사용자 요구사항이 운용 요구사항 문서(ORD)(2)로 작성된다. 이 ORD는 제안 시스템을 적용함에 초점을 두고 사용자가 어떻게 그들의 조직 임무를 수행하고 임무목표를 달성할 것인지를 기술해야 한다.
ORD(2)는 조직 인무를 성공적으로 수행하기 위하여 요구된 운용 산출물(6)로 구성돼 있다. 각 운용 산출물은 최소 하나 이상의 MOE와 하나 또는 그 이상의 MOS로 구성된다. MOE와 MOS는 운용효과(7)와 직결되어 있다. 여기까지 우리는 사용자가 어떻게 시스템, 제품, 또는 서비스를 운용효과와 성공에 대한 지수로써 MOE와 MOS로 나타내는지에 초점을 두고 있었다는 사실을 기억토록 하라. 획득자 시스템 엔지니어에 대한 도전은 MOE와 MOS를 조달 및 개발에 법적으로 충분한 규격서 요구사항으로 전환하는 것이다.
ORD MOE(8)와 MOS(9)를 성능 요구사항으로 전환하는 일은 시스템 요구서(SRD)(3)로 문서화된다. 보다 명확히 각 ORD MOE(8)와 MOS(9)는 요구사항 세트로 전환된다. 각 요구사항은 SRD MOP(10)로 구속된다.
시스템/제품 수명주기의 시스템 조달기간 중, 시스템 개발자는 SRD 요구사항을 분석한다. 전형적으로 제안자는 시스템 개발 계약의 기술적 기준으로 제시될 시스템 성능규격(SPS)(4)을 제안하기 위해 요구된다. 각 제안자는 SRD와 MOP를 검토하고 계약 업무분해구조(CWBS)(5), SPS 능력 및 성능 요구사항(11), 다중 레벨 시스템 아키텍처(14)로 구성된 제안된 솔루션을 형성한다. SPS MOP(12)는 각 SPS능력을 구속하고 SRD MOP(10)를 추적하게 된다. 제안자는 SPS MOP(12)목록으로부터 추적하기 위해 치명적인 TPM(13) 목록 선정을 요청한다.
계약이 이루어지면 SPS 요구사항은 최소 하나 또는 그 이상의 시스템 아키텍처 요소(14)와 이와 연관된 품목이나 형상품목을 나타내는 다중 레벨 개발규격으로 할당, 분할, 분석된다. 각 개발 규격은 SPS MOP로 역 추적되는 최소 하나 이상의 MOP로 구성된다.
시스템/프로젝트 수명주기의 시스템 개발단계에서 개발자는 분석에 근거한 TPM 예측을 제시한다. TPM은 얼마나 잘 시스템 아키텍처 요소 설계가 개발규격과 SPS 요구사항을 달성할 수 있을 것인지에 대한 결정 기반을 제공한다. TPM 현황은 SRR과 SDR과 같은 주요기술검토 시점에서 항상 검토돼야 한다. 통합 및 시험 단계에서 시제 또는 데모를 통해 실제 TPM 성능 데이터가 가용할 때, 그 데이터를 값으로 제시한다.

2. MOE와 MOP 관계
그림 2는 MOE와 MOP관계를 제시해 준다.

그림 2. 항공 사례

여기 항공사 임무 단계는 운항의 하부단계로 구분된다. 각 하부단계는 유스 케이스에 근거하여 수행돼야 할 일차 및 지원 목표를 지니고 있다.
각 유스 케이스는 운용능력 요구사항으로 전환되고 MOE로 참조된다. 각 MOE는 SPS로 문서화되고 제품, 하부체계 등으로 할당된 MOP로 분할되며 이와 동시에 각 품목 개발 규격(IDS)을 분할하게 된다.

3. MOE를 체계 성능규격서(SPS)로 제시
그림 2 사례를 참조하여 우리는 어떻게 SPS 요구사항을 MOP로 전환할 수 있는가? 운용 각 단계와 하부단계에서 반드시 달성해야 할 특정 효과도 측정(MOE)을 지니고 있다. 이리하여 그림 3에서 나타난바와 같이 시스템 운용단계 SPS 3.1항에 각 MOE에 대한 요약 요구사항을 제시한다.

그림 3. 시스템 효과도를 운용단계 MOE로 맵핑하는 TPM 비교

기술 성능 측정(TPM) 표시방법

한 번 각 품목과 형상품목에 대한 성능측정(MOP)이 설정되면, 다음 단계로 그 MOP를 추적한다. 여기에는 수치로 가치를 보고하는 여러 가지 방법으로 수행된다. 가장 좋은 길은 그림 4에 나타난 시간에 따라 그 값을 그래프로 나타내는 것이다.

그림 4. 기술 성능 측정(TPM) 표시방법

TPM은 다음과 같은 기능을 수행해야 한다.

· 개발팀이나 통합제품팀(IPT)에 의해 주간 단위로 적용 결과를 추적
· 최소한 월간보고
· 각 주요 기술검토 단계에서 검토

마지막 기능에서 각 개발팀이나 IPT가 어떻게 각 기술검토 결과를 나타내어야 하는지를 살펴보자.

· TPM XYZ에 대한 분석에 의해 우리가 예상한 성능레벨
· 오늘까지 우리가 달성한 성능레벨
· 다음 검토 시점에서 우리가 예측하는 성능레벨
· 예상 성능과 수락 통제 제한 선에서의 오늘 성능레벨을 우리가 기대하는 수정 보완활동

TPM 값이 어떻게 달성과 연관된 위험레벨을 지닌 CDR에서의 분석적인 예상치로 구성되어 있는지를 주목하라. CDR과 TRR사이에 물리적 컴포넌트는 시스템 통합과 시험을 위해 가용하다. 이와 같은 경우, 실제치는 측정되고 최종 TPM 추적 결과가 된다.
시스템 컴포넌트 성능은 중량 특성, 제조 공차 등에 따라 다르다. 이는 정상적인 TPM 값이 정상분포곡선의 중간 값이다. 주어진 TPM 값에 대한 시스템 엔지니어의 도전은 전체적인 시스템 성능을 감소하지 않는 주어진 제품이나 하부체계에 대한 상위 및 하위 통제 허용한계가 얼마인가 하는 점이다. 이러한 의사결정 결과에 따라 +3편차와 -3편차 또는 기타 적용 한계치가 다중 레벨 위험품목과 완화계획에 따라 설정돼야 한다. 각 +3편차와 -3편차 한계치 내에서 설계안전 마진이 설정돼야 한다. 이를 잘 나타내기 위하여 설계 마진영역을 황색으로, +3편차와 -3편차 밖은 적색으로 표시한다.

[유의사항] 어느 요구사항은 “초과하지 않아야 한다” 또는 “이보다 작아서는 안 된다”와 같이 단일 한계치로 나타난다. 이와 같이 TPM 점에서 상위 또는 하위 통제 제한점으로 반영된다. 개발단계를 따라 TPM은 개발팀이나 IPT가 분석된 예상치를 달성할 수 없다면 특별히 잠재적인 위험으로 나타낸다. 이러한 일이 발생할 때, 각 TPM은 위험 품목을 추적하는 위험 한계치를 가지도록 요구된다. 만일 위험 정도가 심각하면, 위험 품목 완화계획이 시간에 걸쳐 위험 감소 프로파일을 제공하기 위하여 요구되고 규격 요구사항과 동일한 선상으로 수렴된다.
프로그램 위험 관리계획에 이러한 프로세스와 위험 품목을 추적하고 완화하는 계획에 대한 한계치 기준 판단을 세우게 된다.

1. TPM 선정
TPM은 특히 보고서 작성 목적에 대하여 매우 시간을 많이 들여야 하는 활동이다. 모든 규격서의 MOP가 추적될 수는 없다. 따라서 당신은 치명적인 TPM을 선정해야 한다.
시스템 엔지니어 책임자와 SEIT는 임무와 시스템 목표 달성에 영향을 주는 주요 시스템 레벨 MOE와 MOP를 결정해야 한다. 이때 SPS레벨 MOE를 추적하는 각 개발규격으로부터 넷에서 여섯 개 TPM을 각 팀과 함께 협력해야 한다.

‌TPM 도전사항

1. 보수적인 측정 추적
TPM은 두 레벨에서 치명성을 지니고 있다. 첫째, TPM은 제품통합팀(IPT)이나 개발자로 하여금 잠재된 기술 위험요소를 경고하기 위한 볼 수 있는 지표로 사용돼야 한다. IPT팀은 이를 분명하게 이해할 필요가 있다. 그렇지 않으면, 획득자에게 영향을 가져다주는 보수적인 측정 추적에 불과하다고 인식된다.
둘째, 시스템 엔지니어, 프로젝트 엔지니어 또는 기술이사로써 해당 시스템이 규격화되고 설계된 대로 수행하고자 하는 신뢰성 레벨을 제공하기 위한 지표를 일찍이 필요로 한다. 그렇지 않으면, 일찍이 수정활동을 미리 충분하게 알 필요가 있다.

2. TPM을 현명하게 선정
IPT는 종종 측정업무를 수행하는 데 몇 개의 TPM만 관리하려고 한다. 당성하기 쉬운 TPM을 설정하면, 당신이 시스템 개발에 성공하고 있다고 믿기가 쉽다. 가장 어렵고 잠재적으로 알기 어려운 TPM을 선정하게 되면, 추적성을 제공하고 가장 치명적인 위험 영역을 다루게 되어 미리 처방할 수 있는 길을 모색할 수 있다.

3. 실제적인 TPM 데이터를 보유
하나의 IPT가 위험 품목이 되면, IPT는 기술적 위험으로 된 실 데이터의 현실을 피하기 위해 분석에 의한 예측을 계속해 간다. 잔재주를 부리지 말라! 시스템 엔지니어의 책무는 진실된 기존 데이터를 제시함에 있다. 만약 당신이 정치적 문제가 발생한다면, 다른 방법을 강구해야 한다. 만약 당신이 지금 그 성능레벨을 충족시키지 못한다면, 그리고 잠재된 주요 문제점을 무시하려 한다면, 수정 비용이 매우 비쌀 경우, 기술, 프로그램, 집행 관리에 관한 문제를 설명할 때까지 기다려라.
역으로 사업관리자가 건설적인 행동으로 보고하는 목적을 잘 인식해야 한다. 전달자를 처벌하는 일을 피하도록 하라. 성공으로 이끄는 건설적인 기술 솔루션에 초점을 두라. 설계자/개발자의 성공은 프로그램 관리를 성공으로 이끌어 간다.

4. TPM ‘보존기간’
TPM은 특히 하위레벨에서 보존기간을 지니고 있다. 설계와 시스템 통합, 시험평가 단계 초기에 하위레벨 TPM은 전반적인 시스템 성능과 효과도에 영향을 주는 치명적인 성능 지표이다. 한 번 TPM 요구사항이 검증되고 나면, TPM을 추적할 필요성이 시스템 내에서 실패가 나타나지 않는 한 부질없게 된다.
하위레벨 MOP는 상위레벨 MOP로부터 도출된다. 하위레벨 MOP가 검증되고 형상품목이나 품목이 자체 TPM을 가진 다음 상위레벨로 통합되었다면, 당신은 MOP를 더 이상 추적할 필요가 없다. 예외가 있을 수 있다. 이때 가지고 있는 정보를 사용하도록 하라.

5. TPM 보고
당신의 계약은 획득자가 보고하기를 당신에게 요구하는 무슨 TPM인지를 제시해야 한다. 당신이 내부적으로 추적해야 할 다른 TPM이 있을 수 있다.
획득 조직 내부에서의 관계와 성숙도에 따라 몇 시스템 개발자는 검토 대상으로 모든 TPM을 다룬다. 이를 행할 때 주의를 기울여야 한다. 몇 획득 조직은 널리 공개적으로 다른 사람보다 성숙한 경우가 있다. 

[주의사항] TPM 달성이 조금 모자라거나 주요 사항이 쟁점이 될 정치적 사항이 아닐 경우에는 당신은 모두 공개적으로 제시하여야 한다. 모든 사항은 정치적인 문제점임을 인식토록 하라!

요소 측정

1. 요소 측정관리
요소 측정이란 시간에 따라 측정 요소의 양적 변화를 관찰함으로써 전체적인 프로젝트 진행 상항과 진도를 파악하기 위한 목적으로 수집된 측정 대상을 말한다. 일반적으로 기술 활동을 관리함 데 세 가지 측정 요소 유형을 사용하고 있다. 
첫째, 제품개발을 추적하기 위한 제품 측정 요소
둘째, 계획 일정과 비용의 일치성을 추적하기 위한 획득 가치 측정 요소
셋째, 관리활동을 추적하기 위한 관리 프로세스 측정 요소
 추적을 제공하기 위해 측정 요소를 측정하고 평가하며 통제하는 활동은 주기적인 보고체계를 수립하여 수행된다. 이러한 활동은 측정 요소에 대하여 적절하게 측정과 평가되었는지 필요한 결과 데이터가 무엇인지를 포함하여 미리 식별되고 이를 측정 및 통제하는 계획이 수립되어야 한다.
 
2. 제품 측정 요소
제품 측정 요소란 고객 요구사항 충족 여부를 관리하기 위하여 추적하고 진도를 관리해야 할 주요 설계 속성 요소를 말한다. 이러한 제품 측정 요소는 요구사항의 세 가지 기본 유형을 반영하고 있다. 이는 운용성능, 수명주기 적합성 및 수용성을 말한다. 이를 바탕으로 시스템 엔지니어링 측면에서 사용하고 있는 핵심적인 제품 측정 요소는 기술 성능 측정(TPM)이다.
TPM은 고객 성능 요구사항 충족 여부를 관리하기 위하여 설계 진도를 추적하고 관리하는 제품 측정 요소를 말한다. 이러한 TPM은 설계단계 활동에서 운용 요구사항에 대한 추적성을 직접적으로 지원하기 때문에 시스템 엔지니어링 프로세스와 밀접한 관계가 있다. TPM은 시스템 요구사항을 반영하고 있는 성능척도(MOP)로부터 도출된다. 이러한 MOP는 운용 성능 요구사항을 반영한 효과도 척도(MOE)로부터 도출된다.
모든 측정 요소는 정량적으로 측정할 수 있는 데이터이어야 한다. 만일 설계단계 형상품목 레벨에서 이를 측정할 수 있다면 측정 요소에 대한 데이터의 효용성은 매우 커진다. 예를 들면, 중량 TPM은 업무분해구조(WBS)의 모든 레벨에서 예측돼야 한다. 반면에 속도 TPM은 매우 중요한 운용 파라미터이다. 그러나 업무 분해구조 모든 레벨에 배분될 수는 없다. 이러한 속도 TPM은 시스템 분석과 시뮬레이션 활동을 제외하고는 통합제품이 이루어지기 전까지는 측정할 수 없다.
중량은 속도를 달성하기 위한 중요한 요소이다. 따라서 시스템이 개발되는 모든 단계에서 다양하게 측정될 수 있는 중량이 속도를 측정하는 요소로 사용되는 최선의 측정 요소가 된다. 이와 같이 속도에 직접적인 영향을 주는 중량 요소로 운용조건을 추적한다. 더욱 중요한 것은 중량이 WBS의 각 레벨을 통해 형상품목에 계속해서 할당할 수 있기 때문에 이와 같이 할당된 중량 목표 달성여부를 파악하여 제품개발 진도를 추적할 수 있다는 사실이다.

3. 효과성과 적합성 측정
제품운용상의 효과성과 적합성의 정도를 측정하기 위한 기준으로 효과성 척도(MOE)와 적합성 척도(MOS)를 사용하고 있다. 이는 시스템 레벨에서 주어진 임무와 목적을 충족시키기 위해 필요한 성과 측면에서 가장 치명적인 요구사항을 식별하여 이를 운용요구서에 중요 운용요소로 반영해야 한다. 운용 효과성이란 전체적인 운용환경을 고려하여 성공적으로 임무를 달성하기 위한 전반적인 시스템 능력 정도를 말한다. 예를 들면, 무기체계 효과성은 운용 조직, 교리, 전술, 생존성, 취약성 및 위협과 같은 환경적 특성요소를 고려해야 한다. 한편 적합성이란 대상시스템이 운용환경에 잘 적용될 수 있는 통합범위를 말한다. 이는 지원 가능성, 인간 인터페이스 수용성 가능성 및 정비 가능성 등의 주요사항을 측정해야 한다.
 
4. 성능 측정
성능 척도 MOP는 임무 또는 기능 수행과 관련된 물리적 또는 기능적 속성을 나타낸다. 이러한 성능 척도는 효과도 척도 MOE와 적합성 척도 MOS로부터 정량적으로 도출된 직접적인 기술이나 성능 요구사항을 말한다. 따라서 MOP는 MOE 또는 MOS의 변화를 MOP 변화와 연관시켜 관리해야 한다. 기본적으로 MOP는 시스템 규격서의 중요한 성능 요구사항을 반영해야 한다. 이러한 MOP는 설계단계 활동과 프로세스 개발의 기반이 될 수 있는 주요 성능 요구사항을 도출, 개발, 지원 및 검증하는 활동에 사용된다. MOP는 또한 TPM을 통해 추적돼야 할 치명적인 기술 파라미터를 식별해야 한다.

 5. 기술 성능 측정
기술 성능 측정 척도인 TPM은 직접적으로 MOP로부터 도출된다. 또한, 주기적인 검토와 통제 관점에서 치명적인 요소를 TPM 요소로 선택하게 된다. 이러한 TPM은 설계 진도에 따라 WBS의 요구사항이 잘 적용될 수 있도록 도와주고 나아가 기술적인 위험을 추적하고 통제하는 데 사용된다. 또한, TPM은 미달된 요소와 이를 회복하기 위한 요소를 식별하고 비용-성능 민감도 평가를 지원하기 위한 정보제공에 사용된다. 이러한 TPM에는 거리, 정확도, 중량, 크기, 가용성, 최종 전력, 요구 전력, 프로세스 기간 및 시스템 운용에 관련된 기타 제품 요구 특성을 포함할 수 있다.
여러 TPM 중 WBS 요소에 따라 추적 가능한 TPM이 우선적으로 고려되어야 한다. 이는 시스템 전체적인 요소뿐만 아니라 시스템에 포함된 세부적인 요소도 함께 추적하여 통제할 수 있기 때문이다. 필수 TPM 중에 시스템 또는 하부 시스템에서 제한되는 경우가 많다. 예를 들면, 엔진의 연료 소모량을 나타내는 연비는 엔진 개발기간 중 필수적인 TPM임에도 불구하고 이를 하부레벨 WBS에 할당할 수가 없다. 왜냐하면 연비는 전반적인 엔진 성능을 반영하는 하나의 데이터 항목이기 때문이다. 이러한 경우 측정 요소는 요구된 성능과 일치된 설계방법으로 나타난다. 따라서 이러한 TPM은 설계단계에 따라 설계 목표 충족을 조기에 경고해 주는 방법으로 사용할 수는 없다.
 
6. 측정 척도 사례
· MOE : 자동차는 서울부터 부산까지 한 개의 연료탱크로 운행할 수 있어야 한다.
· MOP : 자동차는 2,000키로 미터 이상 운행 가능해야 한다.
· TPM : 연비, 자동차 중량, 연료탱크 부피, 공기 저항력, 타이어 마찰력 등

7. 제품 효과도 측정 요소
이는 총 시스템 가치와 연관되어 있으며 이는 그림 5에 나타나 있다.

그림 5. 총 시스템 가치와 효과도 측정 요소

시스템 가치는 경제적 요소와 기술적 요소로 대별된다. 경제적 요소에는 매출액과 총 순기 비용으로 구분되며, 기술적 요소는 각종 대상시스템의 성능과 신뢰성, 유지보수성, 인간공학적 요소, 안전성, 로지스틱스, 품질 등 제품의 설계품질 사항으로 대별된다. 이러한 두 가지 요소를 비교하여 상호간의 균형을 판단하게 된다.
이러한 평가 방법 중의 하나가 기술적 및 경제적 요소를 종합한 효과도 측정방법이다. 이는 효과도를 시스템 효과특성에 따라 효과도 지수 곧, FOM(Figure of Merit)을 측정하는 방법으로써 몇 가지 사례를 제시하면 다음과 같다. 사례 1은 총순기비용(Total LCC) 대 대상시스템의 가용 성능 효과를 측정하는 경우이다. 사례 2는 순이익 대 시스템 능력 효과를 측정하고, 사례 3은 설비 공간 기준 면적당 총순기비용 효과지수를 나타낸다. 그리고 사례 4는 총순기비용 대 대상시스템의 지원 효과를 나타내는 지수이다. 

· 사례 1 : 효과도 FOM #1=(성능×가용성)/총 순기비용
· 사례 2 : 효과도 FOM #2=시스템 능력/(매출액-비용)
· 사례 3 : 효과도 FOM #3=총순기비용/설비공간
· 사례 4 : 효과도 FOM #4=지원가능성/총 순기비용
 
등을 들 수 있다. 경제요소에 관해서는 매출과 비용이 함께 고려된다. 여기서 비용은 통상 연구개발비, 생산비, 운용유지비를 포함한 총순기비용을 다룬다. 
 
8. 제품 적합성 측정 요소
제품의 운용 적합성 및 기타 수명주기와 관련된 측정요소는 시스템 설계통합 단계에서 진도를 추적하는 것이 적절하다. 운용 적합성은 가용성, 호환성, 수송가능성, 호환성, 신뢰성, 사용빈도, 유지보수성, 안전성, 인적 요소, 문서화, 교육훈련, 인력, 지원성, 로지스틱스 및 환경적 영향을 고려하여 대상시스템이 운용측면에서 만족스럽게 작동할 수 있는 정도를 말한다.
이와 같은 적합성 파라미터는 대상시스템이 적합하게 운용할 수 있도록 도출된 제품 측정 요소를 말한다. 예를 들면, 설계상 자동화 수준을 나타내는 요소는 운용인력의 양적 질적 요구사항을 반영해야 한다. 일반적으로 TPM과 제품 적합성 측정 요소는 일치한다. 예를 들면, 평균 고장시간(MBTF)은 효과성과 적합성을 함께 반영하고 있다. 또한, 적합성 측정 요소는 생산성, 시험 가능성, 설계 단순도, 그리고 강건 설계 정도 등 성능 향상을 나타내는 측정 요소를 포함해도 좋다. 예를 들면, 부품, 유사 부품 및 마모 부품 수량에 대한 추적은 생산성, 유지보수성 및 설계 단순도의 지표로 사용된다.
 
9. 제품 가용성 측정 요소
추정 생산단가 또한 기술 성능측정 TPM 관리와 유사하게 설계단계에서 추적된다. 이는 현 설계단계에서 진행되고 있는 각각의 형상품목에 대한 TPM 요소 보고체계와 동일하게 이루어진다. 이러한 추정은 하부 시스템 추정비용과 시스템 추정비용을 제공하기 위하여 상위 WBS 레벨에서 통합된다. 이러한 추정을 통하여 추정 생산단가 자료 추적, 설계 목표비용(DTC) 추적 및 생산비용과 연관된 설계 문제점을 분리시키는 방법을 제공해 준다.
수명주기 가용성은 특정 시스템의 파라미터 추정방법에 의한 수명주기비용 산정에 포함된 주요요소를 통해 추적 가능하다. 예를 들면, 대부분 수송 시스템의 수명주기 비용을 반영한 두 가지 요소는 연비와 중량이다. 이 두 가지 모두가 수명주기에 따라 추적 가능한 측정 요소이다.
 
10. 시기
제품 측정 요소는 설계 프로세스와 직접적으로 연동되어 있다. 측정 요소 식별, 보고 및 분석을 위한 제반 계획은 개념 형성단계 초기에 이루어진다. 초기에 작성되는 시스템 엔지니어링 계획은 관리 절차를 정의하고, 측정하고 추적해야 할 성능이나 특성을 식별하며, 식별된 성능이나 특성의 예상치를 예측하고 그 평가 시기와 평가 목적을 설정해야 한다. 이러한 계획을 실행하기 위한 적용은 기능 기준 개발로부터 시작된다.
이 기간 중 시스템 엔지니어링 계획은 주요 기술 파라미터, 허용오차와 한계치를 시기별로 계획된 프로파일, 주어진 프로파일을 달성하기 위한 검토, 감사, 종속 이벤트 또는 치명도와 추정방법을 식별해야 한다. 기능 기준에서 제품 기준으로 설계활동이 진행되면서 수립된 계획은 시스템 엔지니어링 프로세스를 적용하여 업데이트된다. 이를 지원하기 위해 계약 내용에 계약업체로 하여금 측정, 분석 및 보고를 위한 조항이 포함되어야 한다. 제품 측정 요소를 추적하기 위한 요구사항은 일반적으로 생산단계에서 제품 기준을 설정함으로써 종료된다.
 
11. 제품측정요소에 대한 국방 및 민수산업 정책
국방규정에 의하면, “분석과 통제 활동은 기술개발과 설계, 계획 대 실적 및 시스템 요구사항 충족 여부를 측정하기 위해 성능 측정 요소를 포함해야 한다”고 규정돼 있다. EIA IS-632 표준 3장 민수산업규정에 의하면, “수행해야 할 활동은 지정된 기술 파라미터 값을 충족시키기 위해 시스템 능력에 영향을 주는 결함을 식별하고 설계 솔루션의 적합성 평가를 위해 TPM을 설정하여 적용토록 한다”고 정의되어 있다.
IEEE 1220 표준 6장 민수산업규정에 의하면, “수행해야 할 활동은 시스템 성능의 핵심 지표인 기술 성능 측정(TPM)을 정의함에 있다. 만약, 프로젝트의 비용, 일정 또는 성능 위험을 충족하지 못한다면, 이 활동은 먼저 치명적인 성능 척도(MOP)에 제한되어야 한다”고 규정되어 있다.

기술 성능 측정 관리
 
기술 성능 측정(TPM)은 다음과 같은 목적을 위해 사용되는 분석 및 통제 기법을 말한다. 1) 일정기간 동안 선정된 기술 파라미터의 예상 성능을 예측함 에 있다. 2) 선정된 파라미터에 대하여 관측된 실제 성능을 관리하고 보고함에 있다. 3) 계획 성능과 실제 성능 상호간의 비교를 통해 의사결정을 돕기 위해 사용된다. 잘 계획된 성능 측정 요소는 기술적 문제점에 대한 조기 경고를 해주고, 운용 요구사항 충족 여부를 평가할 뿐만 아니라 시스템 성능 변화에 따른 영향을 평가해 준다. 일반적으로 TPM은 그래픽으로 표현하는 것과 서술적 설명 형태로 표현해 주고 있다. 
그림 6은 선정된 파라미터의 시간에 따른 계획 목표를 제시하고 그 시기에 실제로 관측된 값을 제시함으로써 계획곡선에서 벗어난 편차를 평가할 수 있다.

그림 6. 기술 성능 측정(TPM) 기본 개념

보고서상에 나타난 서술 부분은 도표를 설명한 다음 계획곡선에서 벗어난 편차의 원인을 설명하고 있다. 또한, 편차의 문제점을 평가하고 이를 보완하기 위한 방안을 설명해야 한다. 필요 시 주어진 현재 상황으로부터 미래에 달성 가능한 성능을 계획하도록 한다.
여기에서 현 달성치란 표시된 마일스톤 일정계획과 비교한 현재 측정값을 말한다. 목표치란 계약 종료 시 예상되는 기술 파라미터 값을 말한다. 현 계획치는 현시점에서 계획된 기술 파라미터의 예상치를 말한다. 계획곡선이란 시간에 따른 예상 계획치를 나타낸 곡선을 말한다. 허용 편차범위란 관리적인 측면에서 예상 오류 편차의 한계범위를 나타낸다. 한계치란 통상 계약상에 나타난 허용 한계치를 말한다. 편차란 계획치와 분석, 시험, 시연방법으로 제시된 달성치의 차이를 말한다.
특히 정부사업의 경우, 추적해야 할 대상 파라미터는 정부와 계약업체 상호간에 합의된 사항을 기초로 해야 한다. 정부사업관리부서는 프로그램의 비용 위험요인이 되거나 개발계획 최단 경로에 놓여 있어서 고위험 항목으로 선정된 주요 WBS 요소를 일차 기술 성능 측정 요소로 분류하도록 해야 한다.
정부에 제시하도록 선정된 TPMs는 운용자 필요성에 대한 추적이 가능하도록 해야 한다. 일반적으로 계약업체가 정부 사업부서에서 요구하는 항목보다 보다 더 상세한 레벨의 정보를 수집해야 하기 때문에 계약업체는 정부에 보고하는 TPMs보다 더 많은 항목을 추적해야 한다. 정부에 보고하는 TPMs는 계약과 연관된 문제이다. 따라서 정부에 제시해야 할 보고서에 포함될 TPMs는 계약자료 요구목록(CDRL)으로 정의되어야 한다. 보고 대상으로 선정되는 모든 파라미터는 수많은 쟁점사항, TPMs요소를 측정하기 위해 필요한 자원, 이를 검토하고 분석하기 위해 가용한 인적자원, 대상시스템의 복잡성, 개발단계 및 과거 유사 시스템에 대한 계약자의 경험 등을 고려하여 이루어진다.
전형적인 TPM 그래프는 앞에서 본 것과 유사한 형태로 제시된다. 실제 예상 성능 프로파일 형태와 오차범위 제시 여부는 선정된 파라미터의 기능 특성과 사업관리부서 요구에 따른다. 또 다른 주요 고려사항 중의 하나는 TPM 프로그램과 위험관리 사이의 연관관계이다.
일반적으로 추적하도록 선정된 파라미터는 프로그램 상의 위험영역과 연관되어 있어야 한다. 만약 특별한 설계요소가 위험영역으로 식별되면, 파라미터는 위험영역 범위 내에서 사업관리자가 진도를 추적할 수 있도록 선정돼야 한다. 예를 들면, 순항거리 달성이 치명적인 위험대상 범위로 선정된다면, 추적해야 할 파라미터는 항공기 중량, 연비 및 항력 등이 된다. 나아가 일반적으로 TPM 요소가 치명적인 시험항목으로 식별된 파라미터로 제한되어 있지 않지만 TPMs과 공식적인 시험과 관련된 치명적인 기술 파라미터 사이에 일치성이 있어야 한다. 정부 검토와 후속 TMPs관리는 계약업체가 TPM을 제출할 때 주기적으로 수행된다. 또한 기술검토, 시험 수행 및 사업관리검토와 같은 주요 기술검토 시 수행된다.
사용자의 필요성을 추적할 수 있는 TPMs인 경우, 이는 추적 및 예측대상 기술 파라미터로 구체화돼야 한다. 예를 들면, 운용자는 전투 상황에서 생존성에 대한 요구사항을 갖고 있어야 한다. 생존성이란 본질적으로 저절로 측정 가능한 파라미터가 아니다. 그러나 레이더 단면적이나 추적속도와 같은 항목은 생존성을 결정하는 주요 기술 파라미터이다. 따라서 기술 관리자는 TPM 보고를 위한 요소로서 RCS와 속도를 선정하여 추적할 수 있다. TPM 추적대상 파라미터를 선정하기 위한 의사결정은 파라미터 특성을 예측할 수 있는 영역과 실제로 측정 가능 여부를 고려해야 한다. 만약 파라미터의 프로파일을 알 수 없거나 이를 측정할 수 없고 프로그램 성공에 중요하지 않는 요소라면 일반적으로 정부는 TPM 추적 대상 파라미터로 이를 선정하지 말아야 한다.
기술 성능 측정이란 시스템 엔지니어링 관리에 있어서 시스템 분석과 통제업무를 수행하는 주요활동 중의 하나이다. 이는 형상품목(CI)이 시스템 요구 성능 규격사항과 어떻게 일치하는지를 나타내는 수단이다. 이는 기술적인 성과를 나타내는 지표이기 때문에 반드시 정량적으로 측정 가능해야 한다. 또한, 사업 진도에 따라 계속적으로 유지 관리되어야 한다. 따라서 설계단계에서 요구 성능보다 부족하거나 과도한 경우가 없는지를 측정하여 시스템 요구사항을 충족할 수 있도록 유도해 가야 한다.
주요 기술요소로 선정되는 판단기준으로 먼저 중량, 컴퓨터 용량, 편류량 등 품질 측면에서 전체 시스템에 미치는 영향이 매우 큰 경우이다. 그리고 계약 당사자 간에 측정이 가능해야 한다. 예를 들면, 엔진 마력, 신뢰도, 반응시간, 속도 등을 들 수 있다. 나아가 이러한 TPM 요소들은 기존의 데이터베이스, 시험계획, 계약 요구사항으로부터 나타나기 시작한다. 이러한 기술 측정 요소들은 그림 7과 같이 시간이 경과함에 따라 변하는 것과 그렇지 않는 것이 있다.

그림 7. TPM 변화 유형

시간에 따라 일정한 값을 유지하는 경우는 기사용 중이거나 이미 개발된 기술을 말한다. 그러나 시스템 특성에 따라 시간이 경과하면 변하는 특성으로 거리, 속도, 적재량, 경도, 엔진마력, MTBF 등이 있다. 그리고 감소하는 경우는 목표 설계비용(DTC), 반응 시간, 부품 중량, 편차 오류, 예비 컴퓨터 사용률, 기억 용량 등이 있다. 
한편 대상시스템의 WBS 구조에 따라 그림 8과 같이 계층별로 TPM 파라미터를 추적 하도록 고려하는 것이 아주 중요하다.

그림 8. 함상 사격 통제 시스템 TPM 사례

 함상통제 하부시스템은 전력밀도, 편류 시간, CWI 및 TI 안테나 사이드 로브, AM 및 FM 노이즈, 각도 및 거리 분해능, 탐지거리, 중량, 전력, MTBF, MTTR 등의 TPM이 있다.
이를 하위 컴포넌트인 CW 트랜스미터에 AM 및 FM노이즈, 방사전력 및 MTBF를 할당하고 데이터 프로세서에 MTBF, MTTR, 기억 용량, 프로세서 속도를 할당한다. 그리고 안테나 시스템에 편류 시간, CWI 및 TI 사이드 로브, 빔의 폭과 MTTR을 할당한다. 이러한 주요 기술 요인은 시스템 성능에 높은 영향을 주는 요소 및 안전, 비용, 일정에 영향을 주는 요소 또는 주요 임무계약 시 인센티브 성능에 영향을 주는 치명적인 요소 등을 고려하여 선정된다.
이러한 TPM 측정계획은 시스템 기획단계에서 수립된다. 계약자는 시스템 엔지니어링 관리계획서(SEMP)를 작성할 때 TPM을 도출하여 제시해야 한다. 사업관리자는 TPM 선정, 계획 기준 및 허용 기준, 측정, 검토 및 감사에 대한 제반 기준을 제시하고 계약자는 이에 따라 계획, 측정, 분석 및 결과보고를 한다. 최종 확정은 물리적 형상감사(PCA)에서 이루어진다. 특히 측정 횟수는 시스템의 복잡성, 보고 주기, 계약자수, 사업관리 조직의 규모, 계약자 실적, 정책 입장, 계약 형태에 따라 결정된다.
TPM의 역할은 기본 성능을 계량화하여 개발 진도에 따라 비교 측정한 다음 설계 면에서 부족 또는 과도 여부를 판단하여 시스템 성능을 종합 관리하는 기법으로 사용된다. 이는 사업 책임자의 주요 월간 보고사항으로서 전반적인 시스템 성능의 주요 품질 요소를 측정하여 계획치와 실제치를 비교 분석하고 치명적 요소에 대한 문제점을 관리토록 한다. 이렇게 함으로써 사업관리자와 계약자 상호간에 활동내용을 계량적으로 정립 운용할 수 있다.
이러한 TPM 관리보고 사례를 도식해 보면 그림 9와 같다.

그림 9. 단계별 TPM 측정

그림 9는 MTBF에 대한 개념 설계 이후 현재 분석된 달성치와 허용범위 내에서의 목표치를 비교 제시해 줌으로써 향후 예비 설계, 상세 설계 및 사후 운용 시 목표치를 어떻게 관리할 것인가를 추적하여 목표치를 달성하기 위한 관리를 하게 된다. 사업관리자가 선정한 모든 TPM은 반드시 공식적인 기술 검토시기에 함께 보고되고 그 대책을 관리해야 한다.
그림 10에서 보면, 프로그램의 시스템 설계 검토 단계에서 가용성, 수명주기 비용, MMH/OH, MTBF, 중량에 대한 달성치를 나타내 주고 있다.

그림 10. 프로그램 단계별 TPM 관리 보고 사례

아직까지 허용범위 수준에 미치지 못하고 있다는 사실을 볼 수 있다. 사업 책임자는 이를 다음 설계 검토 시점까지 허용범위 내로 달성하는 것이 중요한 관리 목표가 된다. 
기술적 성능 달성과 연관하여 위험을 반영한 획득 가치 산정 방법으로 획득 가치 관리와 TPMs을 함께 연계하려고 노력해 오고 있다. 사용되고 있는 접근방법은 계획 대비 실제 성능에 대한 통계적 분석을 기초로 TPM에서 계획된 성능 수준 달성 가능 확률을 통계적으로 다루고 있다. 보다 많은 정보는 인터넷 http.www.acq.osd.mil/api/tpm/을 이용할 수 있다.
요약하면 TPMs은 사업 책임자의 시스템 분석과 통제 수단 중에서 중요한 도구로 사용되고 있다. 또한, TPMs은 주요 기술 파라미터의 편차에 대한 조기경고를 제공해 준다. 이러한 활동이 제대로 이루어지지 않는다면, TPMs은 사용자 요구 충족을 고려한 시스템 성공 여부에 영향을 미칠 수 있다. TPM은 기술 검토와 사업관리 검토 요소로 반영될 뿐만 아니라 주기적인 프로그램 보고와 관리 활동에 함께 통합 제시되어야 한다. TPM 프로그램을 효과적으로 운용함에 따라 사업관리자는 사업 진도 측면에서 편차가 발생했을 때 기술적 근거유무에 관계없이 시스템 기술 성능에 대한 논리적인 판단을 제공할 수 있고 계약자의 계획에 따라 사업을 진행할 수 있다.

원칙

요약해서 앞서 우리는 운용 유용성, 적합성 및 효과성에 대한 실무지침을 설정하는 기본을 제시했다.

[원칙 #1] 최소 하나 또는 둘 이상의 성능 측정(MOP)을 가진 효과도 또는 적합성(MOE/MOS) 측정을 계량적으로 제시하라.
[원칙 #2] 차 상위레벨 시스템-시스템, 제품, 하부체계 등에 대한 주요 기여 요소와 성능 영향인자를 지닌 특정 품목에 대한 TPM을 선정하라.

요약

시스템 엔지니어로써 당신은 시스템 효과도가 어떻게 결정되며 여러 다양한 요구사항 문서로 작성되는 성능 측정(MOP)과 함께 효과도 측정(MOE)과 적합성 측정(MOS)으로 분할된다.
우리는 TPM이 어떻게 계획 대 실제 MOP TPM값을 추적하고 위험 품목을 나타내는 한계치의 중요성과 이와 연관된 위험 완화 계획(RMP)을 위해 사용되는지를 알아보았다.
사람들은 TPM을 형성하고 추적하는 일이 너무나 성가신 일이라고들 한다.
만약 그렇다면, 당신과 당신 조직은 어떻게 이를 실제 다루지 않고 사용자 운용 요구를 충족시키는 시스템, 제품, 또는 서비스를 제공할 수가 있는가를 생각해 보아야 한다. 

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