체계공학관리계획서와 Design Review

(Essay #11) 체계공학관리계획서와 Design Review

  

방산업체에서 시스템공학의 적용에 주된 담당자는 시스템엔지니어이다. 저번 에세이에서 기술하였지만 방산업체에서 시스템공학을 체계공학으로 번역해서 사용하므로 앞으로 체계공학이라는 말로 계속 쓰도록 하겠다. 이번 에세이에서는 체계공학 담당자의 주요 역할인 체계공학관리계획서의 작성 내용에 대해 알아보고 지난 수업 시간에 교수님께서 말씀하신 Design Review에 대해서 우리 회사에서 어떤 식으로 일을 진행하는지에 대해 한번 써보려고 한다.

우리 회사의 체계공학 담당자는 체계공학관리계획서(SEMP) 작성, 요구사항 작성, 규격서 작성, 검증 및 입증 문서 작성 등 사업 관련하여 기술 문서의 개발과 기술 검토 회의 준비의 주요 책임을 가지고 있다. 방위사업관리 규정에 3년 이상의 사업은 체계공학관리계획서를 필수로 제출하도록 의무화하고 있는데 이 체계공학관리계획서에 작성되는 주요 내용은 아래와 같다.

1. 개요 1.1 문서개요 본 문서의 목적과 내용을 요약한다.목적은 보통 1~4정도의 문장으로 짧게 기술한다.   1.2 적용분야 본 문서의 적용분야를 기술한다.   1.3 다른 계획과의 관계 다른 프로젝트 관리계획서가 존재하는 경우 본 문서와 다른 프로젝트 관리계획서와의 관계를 기록한다.   2. 참고문서 본 문서에서 참조하는 모든 관련 문서의 문서번호, 제목, 개정판, 발행일을 기술한다.   3. 사업개요 본 문서에서 참조하는 모든 관련 문서의 문서번호, 제목, 개정판, 발행일을 기술한다.   3.1 사업배경 무기체계 소요제기 근거 및 배경, 그리고 사업과 관련된 정황에 대해 기술한다.   3.2 무기체계 개요 및 특성 본 무기체계의 특성을 그림 또는 글로서 간략하게 기술한다. 무기체계의 개략적인 구조 및 운용개념 등이 포함된다.   4. 체계공학 조직통합 및 기술적 권한 4.1 조직구성 사업 참여기관이 다양할 경우 참여하는 각 산학연 단체의 조직구성과 역할분담을 기 술하고 단일 조직내에서 수행될 경우 참여하는 각 부서나 팀의 조직구성과 역할분담을 표현한다.각 담당자의 역할과 책임을 기술한다.   4.2 업무 및 자원할당 각 조직이나 부서에 대한 업무를 명시하고 그에 따른 예산,인력,장비 등의 할당을 기술한다.   5. 체계공학 프로세스 정의   5.1 개요 본 무기체계 획득사업에 적용되는 체계공학 프로세스의 종류와 내용을 간략히 기술한다.   5.1.1 사업 주요 마일스톤 사업의 주요 마일스톤을 그림 또는 문장으로 간략하게 기술한다. 주요 마일스톤의 대표적인 사례는 기술검토, 단계입출력문서 등이 있다.   5.1.2 체계공학 산출물(CDRL포함) 체계공학을 비롯한 주요 공학적 활동을 수행함에 따라 발생하는 산출물 리스트를 기술한다. 여기에는 계약서 상의 납품목록이 포함되어야 한다.   5.1.3 체계공학 프로세스 입력 요소 체계공학을 비롯한 주요 공학적 활동을 수행하기 위해 요구되는 산출물 및 제약사항을 명기한다.   5.1.4 기술적 목표 무기체계의 기술적 목표를 소요군 요구사항 등을 바탕으로 기술한다.   5.1.5 무기체계 기능 아키텍처 무기체계의 기능 아키텍처를 그림 또는 문장으로 표현한다.   5.1.6 교육훈련 무기체계 개발과 소요되는 교육훈련에 대한 내용을 전반적으로 기술한다.   5.2. 체계공학 기술 프로세스   5.2.1 요구사항 개발 사업의 이해당사자로부터 모든 입력사항을 도출하여 기술적 요구사항으로 변환하는 활동에 대한 계획을 기술한다.탐색개발단계에서 요구사항 개발이 수행된 사업의 체계개발인 경우에는 탐색개발단계의 요구사항에 대한 검토의견 및 요구사항이 충분한지 추가 요구사항 개발이 필요한지와 필요한 경우 수행 계획을 기술한다.   5.2.2 기능분석 및 할당 요구사항을 만족하기 위해 각 부체계나 구성품 수준에서 필요한 기능 및 성능 요구사항의 분석 계획을 기술한다.   5.2.3 기술적 솔루션(해결방안)수립 요구사항 개발 및 기능분석의 결과물을 만족하기 위한 무기체계의 설계대안을 검토하고 선정하는 계획에 대해 기술한다.설계대안을 검토하여 최적의 대안을 결정하는 활동과 하드웨어 및 소프트웨어 구성요소의 결합 또는 재구성을 통해 체계 기능 및 성능 요구조건을 충족할 수 있는 최적의 Solution을 개발하는 과정(설계조합,Synthesis)등이 있다. 주요 설계 고려요소 및 업무범위를 기술한다.   5.2.4 구현 무기체계 계층구조 하위에 있는 구성요소를 확보하는 방안에 대해 기술한다.구현방안은 생산,구매,재사용 등이 있다.통합 절차로 이전되기 전에 구현된 체계 구성요소에 대한 시험이 수행되어야 하며,통합 시기와 장소에 따라 포장,처리,보관 등에 대한 대략적인 계획이나 방안이 기술될 수 있다.   5.2.5 체계 통합 및 시험평가 물리적 아키텍처에서 하위 수준의 체계 구성요소를 상위 수준으로 결합하고, 그 결과를 기록하고 확인하는 절차에 대해 기록한다.또한 사업에서 수행하는 전체 시험평가에 대한 간략한 소개 및 계획을 기술하며,시험에 관한 전반적인 내용이 시험평가 종합계획서에서 다루어진다면 "시험 평가 종합 계획서를 참조한다"고 기술할 수 있다.     5.3. 체계공학 기술관리 프로세스 5.3.1 의사결정분석 사업의 방향이나 설계에 대한 선택이 진행하는 단계에서 각종 대안을 평가하고 선택하기 위한 기반을 제공하는 활동의 수행방안을 기록한다.의사결정을 위한 기준 및 분석에 사용될 방법을 기록하고,관련 책임자 승인권자 등을 기록한다.   5.3.2 기술검토계획 및 평가 사업의 기술검토계획이 수행되는 시점과 시작단계,종료단계에 대한 기준,기타 수행계획,평가방안 등을 기술한다.   5.3.3 요구사항 관리 요구사항 개발은 개발단계 초기에 수행되는 업무인데 비해 요구사항 관리는 사업전반에 걸쳐 지속적으로 수행된다.요구사항 관리 담당자,관리 체계,활용 도구 등에 대해 기술한다.   5.3.3 위험 관리 사업의 진행 및 결과물이 사업계획에서 벗어나게 하는 모든 위험을 조사하고 관리하는 활동에 대해 기술한다. (1)위험 계획,(2)위험 평가,(3)위험 핸들링 및 경감전략,(4)위험 감시 접근법 등에 대한 방안이 기술된다. 관리 담당자,관리 체계,활용 도구 등에 대해 기술한다.   5.3.4 형상 관리 사업의 요구사항과 산출물의 속성 및 형상정보간의 일관성이 유지되도록 관리하는 활동에 대해 기술한다. 형상관리는 연구개발 주관기관이 형상을 식별 및 관리하며,통합사업관리팀의 통제를 받는 계약자간의 상호작용이다. 형상관리 활동은 다음과 같은 업무로 구성되어 있다. (1)형상관리의 계획 및 관리 (2)형상 식별 (3)형상 변경 통제 (4)형상 상태 보고 (5)형상 검증 및 감사.본 실무지침에 기술되어 있지 않은 형상관리 활동의 세부내용은 방위사업청의 ‘IPT형상관리 업무지침’을 따른다.   5.3.5 데이터 관리 데이터는 계약 또는 합의에 의해 요구되는 정보를 만들기 위해 의사소통하고,저장 및 처리되는 기술정보,컴퓨터 소프트웨어 문서,관리정보,발표자료,숫자 또는 자료를 의미하며, 기록 형식이나 방법에 구애받지 않는다.데이터 관리는 체계 전 수명주기를 지원하기 위해 기술적 성격의 데이터를 확보,접근,관리,보호 및 사용을 하는 활동에 대해 기술한다. 데이터 관리 업무의 효율을 개선하고, 재사용의 촉진 및 경쟁력 강화를 위해 다음과 같은 기능을 제공하는 체계공학 전산지원도구의 활용이 권장된다. (1)내부전산망 뿐만 아니라 인터넷을 통한 네트워크 접속 및 관리 (2)본 지침에서 제시하는 모든 체계공학 활동 지원 (3)다양한 체계공학 활동에 따른 데이터를 단일한 데이터베이스에서 관리 (4)체계를 표현하고 접속하기 위한 다양한 모델링 기법 제공   5.3.6 인터페이스 관리 체계를 구성하는 구성요소들 간의 인터페이스를 정의하고 일치성을 보증하는 활동에 대해 기술한다. 인터페이스 관리 활동에서는 형상관리 절차에 따라 인터페이스 요구사항 변경 내용을 기록하고, 영향을 받는 모든 형상항목과 의사소통이 되도록 해야 한다.문서화된 인터페이스 관리 요구사항은 체계의 모든 수준에서 핵심적인 기능을 수행한다.   6. 통합된 사업관리 방위사업청의 통합사업관리팀에서 작성되는 체계관리계획서(SEP)의 6장인 사업관리통합 항목을 참조하여 작성한다. 통합된 사업관리를 위한 의사전달체계,회의 및 기타 활동을 기술한다.   7. 핵심기술의 획득 또는 이전 사업 성공에 관여하는 핵심기술을 정의하고 획득 및 활동방안 또는 이전방안을 기술한다.   8. 통합된 체계공학 수행환경 사업 전 조직이 전체 프로세스에 걸쳐 효율적이고 효과적인 체계공학업무를 수행할 수 있도록 지원하는 추가 조직이나 인원,그리고 이를 지원하는 각종 전산지원도구 및 기타 요소에 대한 설명을 추가한다.   9. 추가적인 체계공학 활동 및 지원계획 위에서 기술된 외 추가적인 체계공학업무나 지원계획 및 기타 이벤트가 있는 경우 기술한다.

 

체계공학 담당자들은 계획이 반이라고, 사업 초기에 이 체계공학관리계획서(SEMP)를 작성하고, 이와 관련된 프로세스를 익히는데 대부분의 시간을 보낸다. 하지만 한번 정도 경험을 가지고 있다면 거의 모든 사업에 비슷하게 적용이 되기 때문에 문서를 작성하는 데는 크게 어려움이 없다. 사업별로 기존 작성된 문서들이 대부분 있기 때문이다.

다음으로 Design Review에 대해 잠깐 설명해보고자 한다.  방위 사업에 공식적인 규정하고 있는 Design Review는 다음과 같다. 각각의 Design Review는 길게는 일주일 동안 회사 내에서 이루어지고 있고, 이 시기에 대부분의 이해관계자가 회사에 방문하여 기존에 개발 시 논의되었던 사항들을 확정 짓고, 베이스라인을 긋게 된다.

-       체계요구사항검토(SRR, System Requirement Review)

-       체계기능검토(SFR, System Functional Review)

-       기본설계검토(PDR, Preliminary Design Review)

-       상세설계검토(CDR, Critical Design Review)

-       시험준비상태검토(TRR, Test Readiness Review)

체계요구사항검토(SRR)는 획득하고자 하는 무기체계에 대한 사용자 요구사항이 개발을 위한 기술적 요구사항으로 잘 정의되었는지 여부를 확인하기 위해 수행된다. 구체적으로는 체계요구사항 검토는 연구 개발 중인 체계가 탐색개발 후 체계개발 단계로 진입할 수 있는지와 선행연구 단계에서의 운용요구서(ORD) 초안14) 또는 체계개발 이전에 확정되는 운용요구서 Ⅰ(ORD Ⅰ)15) 으로부터 만들어진 모든 사용자 및 체계 수준의 요구사항들과 성능 요구사항들이 정의되고 비용(사업 예산), 일정, 위험 및 기타 체계 제약조건과 일관성이 있는지를 확인하기 위한 다중분야 기술검토이다. 일반적으로 이 검토에서는 체계요구사항이 체계 규격서와 부합하는 지 여부를 분석하고, 이들 체계요구사항들이 적용되는 체계 개발방향과 더불어 기술개발을 통해 새로이 확보되는 기술이 체계요구사항 구현에 도움이 되며 관련기술이 체계개발 방향과 일치되는 지 여부를 확인해야 한다. 체계요구사항 검토에서 중요한 점은 체계 규격과 체계개발 단계의 체계공학관리계획(SEMP)에 포함되어 있는 사업 고유의 기술적 위험을 이해하고 이를 통제하기 위한 방안을 계획하는 것이 체계요구사항 검토의 핵심이다.

체계기능검토(SFR)는 사용자 요구사항 및 체계 요구사항이 무기체계의 기능으로 명확하게 정의되었는지를 확인하기 위해 수행한다. 작전운용성능(ROC), 운용요구서(ORD), 체계규격서 등에 정의된 모든 체계 및 성능 요구사항이 비용, 일정, 위험 및 기타 체계 제약조건에 부합하는지를 검토하고, 체계의 기본설계를 진행할 수 있는지를 보증하기 위해 수행한다. 일반적으로 이 검토는 체계의 기능적 요구사항(기능 기준선)이 체계규격서에 충분히 기술되어 있으며 체계 성능이 하부 체계의 기능으로 세분화되고 정의되었는지를 검토한다.

기본설계검토(PDR)는 해당 체계가 상세설계 단계로 진입할 수 있는지와 비용, 일정, 위험 및 기타 체계 제약사항들 범위 내에서 성능 요구사항들을 만족할 수 있는지를 확인하기 위한 기술검토이다. 일반적으로 PDR시에는 체계 내의 각 형상항목을 위한 성능규격(할당 기준선)들이 포함된 상태로 체계 기본설계를 분석하고, 기능적 요구사항(기능 기준선)으로 설정된 각 기능들이 하나 이상의 체계 형상항목에 할당되었는지 와 각 형상항목의 성능규격을 확정한다. 비용, 일정, 위험 및 기타 체계 제약조건 하에서 체계가 정해진 성능 요구사항을 만족하고, 상세설계로 진행할 수 있는 지 여부를 보증하기 위해 수행한다. 전체 체계가 올바르고 완벽하게 수행되도록 하부체계요구사항을 평가한다. 하부체계요구사항이 전체 체계 설계 요구사항을 따르는지를 확인한다.

상세설계검토(CDR)은 체계 및 구성품에 대한 시제제작 및 구현을 착수할 준비가 되어있는지 확인하기 위한 것으로 각 형상항목에 대한 제품 기준선(Product Baseline)을 분석하고 설계 내용을 검토하기 위해 수행한다. CDR은 시제제작에 착수하기 이전에 품목의 상세설계에 대한 검증과 설계 반영사항에 대한 사용자와 연구개발주관업체 간 상호 이해를 통한 공식화가 필요하다. CDR은 상세설계 내용이 정확한지, 문서화가 제대로 되어 있는지를 검증하고, 모든 하드웨어 및 소프트웨어 형상항목 평가를 위해 수행한다.

시험준비상태검토(TRR)는 체계 및 주요 부체계에 대한 공식적인 시험평가를 착수할 준비가 되어있는지 확인하기 위한 것으로 시험목적, 시험방법 및 절차, 시험항목 및 기준, 시험 범위 및 안전성을 평가하기 위해 수행한다. 또한 시험에 필요한 시설 및 장비, 시험인력 등 시험자원이 계획된 시험을 수행하기 위해 적절하게 식별되었고 관련부서 간 협조가 완료되어 있는지를 확인한다. TRR은 소프트웨어 형상항목(CSCI)의 검토를 위한 절차로서 개발되었지만 하드웨어와 소프트웨어 품목 모두에 적용되며, TRR이 완료되면 공식 시험평가가 시작된다.체계가 탐색개발 후 체계개발 단계로 진입할 수 있는지와 선행연구 단계에서의 운용요구서(ORD) 초안14) 또는 체계개발 이전에 확정되는 운용요구서 Ⅰ(ORD Ⅰ)15) 으로부터 만들어진 모든 사용자 및 체계 수준의 요구사항들과 성능 요구사항들이 정의되고 비용(사업 예산), 일정, 위험 및 기타 체계 제약조건과 일관성이 있는지를 확인하기 위한 다중분야 기술검토이다. 일반적으로 이 검토에서는 체계요구사항이 체계 규격서와 부합하는 지 여부를 분석하고, 이들 체계요구사항들이 적용되는 체계 개발방향과 더불어 기술개발을 통해 새로이 확보되는 기술이 체계요구사항 구현에 도움이 되며 관련기술이 체계개발 방향과 일치되는 지 여부를 확인해야 한다. 체계요구사항 검토에서 중요한 점은 체계 규격과 체계개발 단계의 체계공학관리계획(SEMP)에 포함되어 있는 사업 고유의 기술적 위험을 이해하고 이를 통제하기 위한 방안을 계획하는 것이 체계요구사항 검토의 핵심이다.

체계기능검토(SFR)는 사용자 요구사항 및 체계 요구사항이 무기체계의 기능으로 명확하게 정의되었는지를 확인하기 위해 수행한다. 작전운용성능(ROC), 운용요구서(ORD), 체계규격서 등에 정의된 모든 체계 및 성능 요구사항이 비용, 일정, 위험 및 기타 체계 제약조건에 부합하는지를 검토하고, 체계의 기본설계를 진행할 수 있는지를 보증하기 위해 수행한다. 일반적으로 이 검토는 체계의 기능적 요구사항(기능 기준선)이 체계규격서에 충분히 기술되어 있으며 체계 성능이 하부 체계의 기능으로 세분화되고 정의되었는지를 검토한다.

기본설계검토(PDR)는 해당 체계가 상세설계 단계로 진입할 수 있는지와 비용, 일정, 위험 및 기타 체계 제약사항들 범위 내에서 성능 요구사항들을 만족할 수 있는지를 확인하기 위한 기술검토이다. 일반적으로 PDR시에는 체계 내의 각 형상항목을 위한 성능규격(할당 기준선)들이 포함된 상태로 체계 기본설계를 분석하고, 기능적 요구사항(기능 기준선)으로 설정된 각 기능들이 하나 이상의 체계 형상항목에 할당되었는지 와 각 형상항목의 성능규격을 확정한다. 비용, 일정, 위험 및 기타 체계 제약조건 하에서 체계가 정해진 성능 요구사항을 만족하고, 상세설계로 진행할 수 있는 지 여부를 보증하기 위해 수행한다. 전체 체계가 올바르고 완벽하게 수행되도록 하부체계요구사항을 평가한다. 하부체계요구사항이 전체 체계 설계 요구사항을 따르는지를 확인한다.

상세설계검토(CDR)은 체계 및 구성품에 대한 시제제작 및 구현을 착수할 준비가 되어있는지 확인하기 위한 것으로 각 형상항목에 대한 제품 기준선(Product Baseline)을 분석하고 설계 내용을 검토하기 위해 수행한다. CDR은 시제제작에 착수하기 이전에 품목의 상세설계에 대한 검증과 설계 반영사항에 대한 사용자와 연구개발주관업체 간 상호 이해를 통한 공식화가 필요하다. CDR은 상세설계 내용이 정확한지, 문서화가 제대로 되어 있는지를 검증하고, 모든 하드웨어 및 소프트웨어 형상항목 평가를 위해 수행한다.

시험준비상태검토(TRR)는 체계 및 주요 부체계에 대한 공식적인 시험평가를 착수할 준비가 되어있는지 확인하기 위한 것으로 시험목적, 시험방법 및 절차, 시험항목 및 기준, 시험 범위 및 안전성을 평가하기 위해 수행한다. 또한 시험에 필요한 시설 및 장비, 시험인력 등 시험자원이 계획된 시험을 수행하기 위해 적절하게 식별되었고 관련부서 간 협조가 완료되어 있는지를 확인한다. TRR은 소프트웨어 형상항목(CSCI)의 검토를 위한 절차로서 개발되었지만 하드웨어와 소프트웨어 품목 모두에 적용되며, TRR이 완료되면 공식 시험평가가 시작된다.