시스템 개발 전략

앞서 논의된 시스템 분석을 기반으로 이제 시스템 설계와 개발 단계를 생각해 보자. 이를 위해 다음 여섯 가지 영역을 다루도록 한다.

· 시스템 개발 전략시스템
· 규격서 작성
· 시스템 설계 및 개발
· 의사결정 지원시스템 검증 및 확인
· 시스템 배치, 운용 및 지원

먼저 더 세부적으로 제시하기 전에 각 영역에 대한 내용을 살펴보면 다음과 같다.

1. 시스템 개발전략 영역
계약으로부터 시스템 수락과 납품까지 성공적으로 시스템을 개발하려면 프로그램을 효율적으로 진행해야 하는데, 이를 위해서는 이미 입증된 방법을 적용한 업무 흐름을 지원하는 한편, 세부적인 전략을 세워야 한다. 시스템 개발전략 영역은 프로그램 전략을 설정하기 위한 구체적인 방법을 제시함에 있다.
앞서 시스템 분석에서 제기된 개념을 검증하고 확인하기 위한 프로그램 설정방법을 제시함으로써, 다중 레벨 규격을 시스템, 제품 또는 서비스를 납품하기 위한 물리적 설계 솔루션으로 전이해 가는 업무 흐름을 만들어야 한다. 이를 위해 우리는 폭포식 개발, 점진적 개발, 진화적 개발, 나선형 개발과 같은 여러 가지 다양한 개발방법을 사용하고 있다. 우리는 검증과 확인이 시스템 통합과 시험단계에서 수행된다고 생각하기 쉽지만, 이는 계약단계로부터 시스템 수락과 납품에 이르기까지 지속적으로 이루어진다.
시스템 개발전략이 마련되면 시스템 설계와 개발은 시스템 규격서를 마련하는 영역으로 진입하게 된다.

2. 시스템 규격서 영역
시스템 개발전략이 수립되면, 사용자 솔루션 영역을 구성하고 있는 기술, 비용, 일정, 지원 및 위험 제약사항을 형성하고 있는 요구사항과 시스템 규격서를 개발하고 도출하는 활동으로 시작된다.
여기에는 규격서 형태, 규격서 분석과 개발방법, 규격서 요구사항 분석, 도출, 개발 및 검토방법을 살펴보아야 한다. 이를 수행한 후 다음 시스템 설계와 개발 단계로 진행된다.

3. 시스템 설계와 개발 영역
시스템 설계와 개발 활동은 개발자가 사용자 요구를 잘 이해하고 기술, 지원, 비용, 일정, 및 위험 등 의사결정 요소에 따른 여러 대안으로부터 솔루션을 선정해야 한다. 다양한 시스템 설계와 개발활동을 기술하고 운용 효용성, 적합성, 효과성, 가용성 요구사항의 이해, 도메인 솔루션 형성, 시스템 아키텍처 선정, 형상식별, 시스템 인터페이스 설계, 표준과 규정, 설계 및 개발 문서화 활동을 포함한다.
시스템 설계와 개발활동은 올바른 시스템 솔루션이 선정되었는지를 결정하기 위하여 적시 데이터를 요구한다. 이후에 다음 의사결정 지원 영역으로 넘어간다.

4. 의사결정 지원 영역
시스템 요소의 통합설계와 개발 세트는 데이터 제공을 위한 분석지원을 요구하며, 기술, 지원, 비용, 일정 및 위험 등을 고려하여 시스템 설계를 최적화해야 한다. 의사결정 지원영역은 적시 데이터를 제공하고 추천하기 위하여 분석활동에서 시제제작과 시연 활동까지 모든 메커니즘을 제시한다.
여기에는 분석, 시스템 설계의 통계 처리, 시스템 성능 예산 및 마진, 시스템 신뢰성, 가용성, 유지보수성, 시스템 모델링 및 시뮬레이션, 대안절충분석 등을 포함하고 있다.
시스템 설계와 개발은 시스템이 바르게 설계되고 있는지 사용자 운용요구를 충족시키고 있는지를 수행 중 통합평가를 요구한다. 이를 위해 시스템 설계 솔루션 통합을 평가하기 위하여 다음 검증과 확인 영역으로 넘어간다.

5. 검증과 확인 영역
시스템 설계와 개발 활동은 다음 두 가지 질문사항을 충족해야 한다. 1) 시스템은 계약 요구사항에 걸맞게 바르게 설계 및 개발되었는가. 2) 시스템은 사용자 운용요구를 충족하고 있는가. 검증과 확인 활동은 계약에서부터 시스템 수락 및 납품 시까지 사용자, 획득자 및 개발자 사이에 상기 두 가지 질문 충족 여부를 제시해 준다.
이러한 검증 및 확인 활동은 시스템 설계 솔루션의 진화와 성숙과정을 검증하고 확인하기 위하여 기술 검토의 중요성 제시, 시스템 통합, 시험과 평가 활동이 검증 및 확인 시 가장 중요한 역할을 수행하고 있음을 기술한다. 검사, 분석, 시험, 데모와 같은 검증 방법을 통해 규격서 요구사항 충족 여부를 검증하게 된다.
이처럼 검증, 확인 및 최종 수락이 되고 나면, 사용자는 시스템이 조직의 임무를 수행토록 한다. 이는 다음 시스템 배치, 운용 및 지원 영역으로 넘어간다.

6. 시스템 배치, 운용 및 지원 영역
대부분 사람은 시스템 엔지니어링과 분석 활동은 사용자 수락과 시스템이 납품되면 종료된다고 믿는다. 실제 시스템 엔지니어링 활동은 시스템, 제품 또는 서비스 운용수명 전반을 걸쳐 지속된다. 시스템 배치, 운용 및 지원 영역은 기존 시스템의 시정조치 활동뿐만 아니라 미래 시스템과 능력 요구사항에 이르기까지 시스템 분석과 시스템 엔지니어링 활동을 요구하는 시스템과 임무 적용 및 성능에 대한 관찰을 요구한다.
여기에는 운용 사이트 선정, 개발 및 사용을 위한 배치방법, 사이트에서 상위 레벨 시스템으로 통합에 따른 주요 고려요소, 시스템 약점 발견방법, 신규 시스템, 제품 또는 서비스에 대한 획득 요구사항 기반형성, 신규 시스템 규격 요구사항으로 전환되어야 하는 주요 엔지니어링 고려요소 제시방법을 기술한다.

시스템 개발 업무수행 전략

1. 개요
시스템 개발자나 서비스 제공자와 시스템 개발 계약을 하는 활동이 시스템 개발 시작 단계를 의미한다. 이 단계는 모든 개발 조항을 충족시키고, 최종 산출물을 생산하며, 지정된 납품 장소에 산출물을 분배하고 배치하는 모든 활동을 포함한다.
계약 시, 계약 당사자가 제안부서에서 시스템 개발자나 서비스 제공자 조직으로 사업제안서를 제시한다. 이는 계약 조항에 일치하는 제안 시스템을 예산 범위 내에서 적기에 계약당사자가 완전하게 제시해 주기를 요구하고 있다. 이러한 비즈니스 활동을 “가장 좋은 소식은 계약을 따내었다는 것이며, 가장 나쁜 소식은 우리가 무엇을 수행했다는 것인가?”라는 말을 생각해 보면 어떻게 그 활동이 수행되고 있는지를 짐작할 수 있다.
이 단계에서 논의의 초점은 제안 시스템이 어떻게 개발되고 사용자에게 납품되느냐에 달려있다. 우리는 시스템 개발자나 서비스 제공자가 물리적 시스템을 궁극적으로 생산하기 위하여 여러 시스템 개발 단계를 거쳐 사용자 요구사항을 어떻게 충족시켜 나가는지를 지켜본다. 이러한 대상 “시스템”은 국가, 우주선, 우체국, 운송회사, 병원, 또는 심포지엄일 수가 있다. 기억해야 할 중요한 점은 시스템 개발기간이 수주에서 수년까지 걸린다는 사실이다.
여기서 말하는 시스템 개발단계란 시스템 조달단계와 연계해서 최종 시스템이 배치되기 전 여러 번 반복된다는 사실이다.
예를 들면, 어느 도메인의 경우, 시스템 개발자 선정 시스템은 요구사항에 따라 여러 번 시스템 개발단계 계약이 순차적으로 이루어진다. 이는 일차 계약자로부터 하나 또는 둘 이상의 하부 계약자에 이르기까지 내려간다. 이를 가리켜 나선형 식 개발이라고 부른다.
시스템 서비스 제공자에 대한 계약의 경우, 시스템 개발단계는 시스템 운용단계에서 서비스를 지원하거나 주계약자의 임무를 지원하기 위하여 시스템 운용, 프로세스 및 절차를 재사용하거나 개발하기 위하여 준비기간이 필요하다. 예를 들면, 건강보험제공자의 경우, 협력사 보험 프로그램에 대한 “아웃소스” 지원 서비스 제공을 위한 계약을 따내야 한다. 제공 서비스는 그 계약자가 다른 조직을 위하여 행정적으로 지원해야 하는 것과 유사하게 “테일러링” 버전을 사용함도 괜찮다.
당신은 이 장에서 논의된 개념을 이해한 후에 시스템 엔지니어링 프로세스가 어떻게 적용되어야 하며 이러한 적용을 어떻게 관리해야 하는지에 대한 확실하게 신뢰함이 바람직하다.

2. 얻고자 하는 내용

· 시스템 개발 업무단계란 무엇인가?
· 시스템 개발자를 위한 검증 및 확인 전략은 무엇인가?
· 시스템 개발 업무 흐름과 연관된 검증 및 확인 전략은 어떠한가?
· 왜 검증 및 확인 전략은 주요한가?
· 개발형상이란 무엇인가?
· 개발형상은 언제 시작되고 언제 종료되는가?
· 초도 제품이란 무엇인가?
· 개발 시험 및 평가(DT & E)란 무엇인가?
· 개발시험 및 평가는 어떻게 수행되는가?

· 시스템 개발단계에서 언제 개발시험 및 평가 활동이 이루어지는가?
· 개발시험 및 평가 책임은 누가 지는가?
· 운용시험 및 평가란 무엇인가?
· 시스템 개발단계에서 언제 운용시험 및 평가 활동이 이루어지는가?
· 운용시험 및 평가의 목적은 무엇인가?
· 운용시험 및 평가 책임은 누가 지는가?
· 운용시험 및 평가에서 시스템 개발자의 역할은 무엇인가?

3. 주요 용어정의

· 개발시험 및 평가 수행 목적
- ‌다른 개념 및 설계 옵션과 비교하여 운용 잠재력과 기술적 제한사항을 식별
- 식별된 비용·성능 절충을 지원
- 설계 리스크 식별과 기술 지원
- ‌계약 기술 성능과 제작 프로세스 요구사항이 달성되었는지 여부 입증
- ‌운용시험과 평가준비 여부에 대한 의사결정 지원(소스: MIL-HDBK1908, 3절, 정의)
· 개발형상 : 개발 기간에 진화하는 형상품목의 형상을 정의한 계약자의 설계 및 연관된 기술문서를 말한다. 이는 개발하는 계약자의 형상통제 활동으로써 설계 정의와 적용을 기술하고 있다. 형상 품목에 대한 개발 형상은 공식적인 제품 베이스라인 형성 시까지 계약자에 의해 정해진 하드웨어와 소프트웨어 설계도면 및 연관된 기술문서로 구성된다(소스: MIL-STD-973(중지), 형상관리 3.30절).
· 초도제품 : 여기에는 사전 생산모델, 초도 생산 샘플, 시험 샘플, 첫 번 양산 로트, 파일럿 모델 및 파일럿 로트가 포함되어 있다. 그리고 초도 생산계약 단계 또는 그 이전에 주어진 계약 요구사항과 일치여부를 시험평가 활동을 통해 승인하는 사항이 포함된다.
· 기능형상감사(FCA) : 형상품목 개발이 만족하게 완료되고, 그 품목이 기능 또는 할당 형상식별에 제시된 성능과 기능 특성을 충족시키며, 운용 및 지원 문서가 만족스럽게 완료되었는지 검증하기 위해 수행된 감사를 말한다(소스: IEEE 610.12-1990 소프트웨어 엔지니어링 표준 용어집).
· 독립시험기구(ITA) : 운용 효용성, 적합성, 효과성과 같은 영역에서 야전 운용조건에서의 사용자의 확인된 운용 요구를 검증한 시스템이 얼마나 충족시키고 있는지를 평가하기 위하여 획득자에 의해 지정된 사용자 요구를 대변할 수 있는 독립기구를 말한다.
· 운용시험 및 평가(OT&E) : 사용자의 확인된 운용 요구에 근거한 운용 효용성, 적합성, 및 효과성과 같은 영역에서 실제 야전 운용조건에서 수행된 사용자 또는 독립시험기구의 시험평가활동을 말한다. 활동 내용은 교육훈련 효과, 로지스틱스 지원성, 신뢰성 및 유지보수성 시현과 효율성을 포함하고 있다.
· 물리적 형상감사(PCA) : 제작된 형상품목이 이를 정의하고 있는 기술문서와 일치하는지를 검증하기 위해 수행되는 감사활동을 말한다.
· 품질기록서(QR) : 업무 근거 활동 또는 수행된 이벤트를 나타내기 위하여 목적근거로 준비된 메모, 이메일, 보고서, 분석, 회의자료 및 조치사항과 같은 내용 문서를 말한다.

4. 단계별 목적
시스템 개발단계의 일차적인 목적은 계약 및 시스템 규격서(SPS) 요구사항을 다음과 같이 체크된 물리적 산출물로 제시함에 있다.

· 제시된 요구사항
· 검증필요 시 사용자 확인
· 사용자 계약 및 기술 사항으로서 사용자나 획득자에 의해 공식적인 수락

시스템 개발 검증 및 확인 전략

앞서 시스템 개체에 대한 개념을 설명할 때, 시스템 검증과 확인에 대하여 언급한 바가 있다. 검증 및 확인(V&V)은 진화하는 시스템 엔지니어링 설계 솔루션의 통합성을 보증하기 위하여 개념적 전략의 기초를 제공하고 있다. 이 장에서 보다 기술적이고 체계적인 기반을 형성하도록 정의해 보면, 그림 1과 같이 V&V 폐쇄루프 체계에 대한 지침을 제공해 준다.



1. 시스템 정의 및 시스템 조달 단계 V&V
사용자가 운용요구를 식별할 때 사용자는 조달 활동에 대한 계약 및 기술 대행기관으로 획득자 기구를 사용해도 좋다. 이미 임무요구서 (MNS)로 문서화된 운용요구는 획득자에 의해 운용요구서(ORD)로 전환된 다음, 이를 사용자와 협의하여 확인된다. ORD는 시스템 요구서(SRD) 또는 시스템목표서(SOO)를 개발하기 위해 획득자에게 기초 문서가 된다. SRD/SOO는 자격을 갖춘 공개 입찰자에게 일명 사업 제안 요청서(RFP)를 공식적으로 요청하기 위한 기술적 요구사항을 나타낸다.
입찰자는 SRD/SOO를 분석하고 SRD/SOO로부터 시스템 성능규격서(SPS)를 개발하여 제시한다. 그리고 이를 사업제안서의 한 품목으로 제출한다. 획득자가 마지막 업체 선정 시, 시스템 개발협약이 공식적으로 계약체결 시점에 이루어진다.

2. 시스템 개발단계 V&V
SPS는 시스템 엔지니어링과 개발 활동을 통해 산출되는 시스템이나 제품을 개발하기 위한 기술적 기준을 제공하고 있다. 요구사항의 숙성에 따라 시스템 개발자는 시스템 설계 솔루션을 얻기 위해 나선형식 개발 또는 다른 개발 전략을 적용해도 좋다. 시스템엔지니어링 활동을 지원함에 있어서 의사결정지원 활동은 여러 유사 활동 중에서 요구사항 적용 확인 활동과 같은 사용자 피드백으로부터 제공된 입력사항과 예비 평가와 함께 분석 및 절충 활동을 수행한다.
시스템 엔지니어링 설계가 진화함에 따라 시스템 검증 방법은 요구사항 할당, 배분, 설계를 제품, 하부체계, 아셈부리, 하부 아셈부리, 부품과 같은 모든 추상 레벨에서 지속적으로 평가해 나가도록 한다.
설계 검증 활동은 개발시험과 평가(DT&E) 및 주요 기술검토와 추적 감사 활동이 수행된다. 이러한 검증 활동의 목적은 시스템 엔지니어링 설계 솔루션에 대한 진도, 성숙도, 위험을 모니터링하고 평가함에 있다. 진화하는 개발형상에 대한 의사결정을 위한 공식적인 베이스라인을 설정하도록 치명적인 단계 또는 통제점에서 기술검토 활동을 통해 기준을 설정하게 된다.
그림 1의 확인 활동에서 구체적으로 제시되어 있지 않았지만, 이는 시스템 개발자의 사업관리 조직에서 지속적으로 수행된다. 소유자는 문서화된 유스케이스 기반 요구사항으로 하위레벨 설계 솔루션 적용을 확인한다. 최종 설계검토(CDR)단계에 설정된 설계 요구사항은 컴포넌트를 개발하고 획득하는 데 기반을 제공해 준다. 각 컴포넌트가 완성됨에 따라 그 품목은 현재 설계 요구사항과의 일치여부를 검증토록 한다. 컴포넌트의 순차적인 레벨은 시스템 통합, 시험 및 평가(SITE) 활동 레벨을 통해 나아가고 각 품목개발규격(IDSs)에 따라 검증된다. 다양한 통합레벨에서 시험준비 검토 단계의 모든 형상 및 시험환경에서 낮은 위험정도로 시험할 수 있는 준비가 되어 있는지를 검증 활동을 수행한다.
시스템 레벨 통합에서 SPS 검증 준비가 되었을 때, 시스템 검증 시험(SVT)이 수행된다. SVT에서 “시스템이나 제품이 바르게 제작되었는가”를 SPS 요구사항에 따라 검증되어야 한다.
SVT가 이루어지면, 기능형상 감사(FCA) 활동이 SVT 결과를 증명하기 위하여 수행된다. 이는 SPS 요구사항과 일치여부를 입증한 품질기록(QRs)이 되어야 한다. FCA 다음으로 각 설계 요구사항에 대한 품목의 일치여부를 나타낸 물리적 측정을 입증하기 위해 물리적 형상감사(PCA) 활동이 이루어진다. FCA와 PCA를 완료한 후, 시스템 검증 검토(SVR)가 FCA와 PCA 결과를 인증하기 위해 수행된다.
계약 체결 시, 시스템 개발협약의 조항과 조건(T&Cs)에 따라 SVR 종료는 사용자를 대신한 획득자의 최종 시스템이나 제품 납품 및 수락의 전제사항이 된다. 운용시험 및 평가에서의 몇 가지 협의가 요구되기도 한다. OT&E를 준비함에 있어서 사용자와 사용자 입장을 대변하는 별도시험기구(ITA)는 실제 또는 유사 운용환경 조건에서 시스템 또는 제품을 사용하여 시나리오 기반 야전 시험을 수행해야 한다.
OT&E 기간 중 획득자 시스템 확인 활동을 통해 ORD와 SOO문서에 따라 “원하는 시스템 또는 제품을 획득 했는가”를 확인토록 한다. 계약 범위에 따라 수정조치 활동이 설계결함, 결점사항, 설계변경 등이 잘 이루어졌는지를 OT&E를 통해 입증되어야 한다. OT&E이 끝나면, ITA는 평가 및 추천사항을 제시한다.
시스템 개발계약이 종료되었다 할지라도 시스템 수명주기에 따라 시스템 개발 및 시스템 운용 및 지원(O&S) 활동을 통해 지속적인 검증 및 확인 활동을 사용자가 수행한다. V&V 활동은 연관된 조직과 시스템 임무와 연계하여 수행한다. 운용환경에서의 경쟁과 위협이 바뀌어 가고 유지비용이 증가해 가면 기존 능력으로 조직과 임무를 달성함에 있어서 ‘갭’이 발생된다. 이러한 갭을 해소하기 위하여 기존 능력 업그레이드 또는 차세대 시스템 개발 또는 제품 개발이 수행되게 된다.
이제 시스템 개발의 V&V 전략이 수립되고 나면, 이를 얼마나 잘 적용할 수 있느냐는 질문이 생긴다. 이를 위해 시스템 개발 단계 적용이라는 다음 토픽을 알아보자.

시스템 개발단계 적용

시스템 개발단계의 업무흐름은 그림 2와 같이 다섯 개의 순차적 업무 프로세스로 이루어져 있다. 그 내용은 다음과 같다.



· 시스템 설계 프로세스
· 컴포넌트 조달 및 개발 프로세스
· 시스템 통합, 시험 및 평가(SITE) 프로세스
· 운용 시험 및 평가(OT&E) 프로세스

일반적인 업무 절차는 순차적으로 이루어지지만 이는 다음 절차로 진입하기 전에 여러 번의 반복적인 피드백 루프를 이루고 있다.
시스템 개발단계는 계약 체결에서 시작되며 획득자와 사용자의 산출물 수락 시까지 계속된다. 이 기간에 시스템 개발자 또는 용역 제공자가 획득자로 하여금 해당 조직이 계약을 이행하는 접근방법을 적용하게 된다.
잘 체계화되고 성실한 조직과 고도의 효율로 잘 훈련된 수행 팀은 문제없이 계약을 잘 이행할 수 있다는 교훈을 기억도록 하라.
시스템 개발 단계는 계약 당시 성능 규격을 물리적 시스템 솔루션으로 전환하기 위해 요구되는 모든 기술 활동을 포함하고 있다. 우리는 이러한 초기 시스템을 개발 형상으로 된 초도품이라고 부른다.
이 단계를 통해 시스템 설계 솔루션은 성숙 단계로 진행하면서 반복적으로 진화해 간다. 전형적인 성숙단계란 분석, 시제품 및 기술적 데모로 나타낸 입구와 출구 기준으로 구성된 일련의 설계검토 활동으로 구성되어 있다. 검토란 진화되고 있는 개발형상을 볼 수 있는 설계 기준을 나타낸다. 시스템 설계 솔루션이 최종설계검토(CDR)에서 공식적으로 승인될 때, 개발형상은 컴포넌트 조달 및 개발에 대한 기반을 제공해 준다.
조달 및 개발된 컴포넌트는 다양한 통합 레벨에서 각각의 설계 요구사항-도면-성능규격에 따라 검사, 통합 및 검증된다. 검증이란 요구규격에 따라 “그 시스템을 바르게 개발했는가?”라는 질문에 대한 답을 말한다. 통합이란 시스템 성능 규격(SPS)에 대한 시스템 검증시험(SVT)으로 완료된다. 시스템 개발단계는 시스템, 제품 또는 서비스 개발에 초점을 두고 있으므로 SVT를 통한 시험이란 개발시험 및 평가(DT&E)활동으로 나타난다.
개발형상에 따른 초도 시스템의 SPS 요구사항 충족 여부를 검증할 때, 계약 요구사항에 따라 다음 두 가지 옵션 중 하나로 나타난다. 다음 두 가지 중 하나로 배치되어도 좋다.

(1) 사용자 또는 사용자를 대변하는 독립시험기관(ITA)의 확인시험을 위한 다른 장소
(2) 사용자의 레벨 0 시스템으로 설치, 체크, 통합 및 최종 수락을 위한 사용자가 지정한 야전 사이트

운용시험 및 평가(OT&E)인 확인 시험은 사용자로 하여금 확인하고자 하는 운용 요구를 충족시키는 원하는 시스템을 획득할 수 있는지를 결정하기 위하여 수행되는 시험이다. 불일치 사항이 발생되면 불일치 보고서(DRs)를 작성한 후, 계약사항의 항목과 조건(Ts&Cs)에 따라 해결해야 한다.
초기 시스템 운용 기간에 설계 미숙, 에러 및 결함과 같은 하자를 수정하고 시스템 운용을 확인하기 위한 야전 데이터를 수집하기 위하여 야전에서 사용한 후, 가능하다면 시스템 생산단계 진입여부를 결정하게 된다.
만일 사용자가 시스템이나 제품 생산을 허락한다면, 획득자는 시스템을 납품한 다음 시스템 운용 및 지원(O&S) 단계로 진입하게 된다.

1. 기술관리 프로세스
시스템 개발단계에서 기술적인 노력은 기술관리 프로세스를 따라 한다. 이 프로세스의 목적은 기술, 비용, 일정 및 위험에 대한 제약조건 아래 주어진 품목에 대한 납품에 초점을 둔 제품 기반팀 활동을 계획, 인력관리, 통제하는 활동을 수행한다.

2. 의사결정 지원 프로세스
의사결정 지원 프로세스는 시스템 개발단계 프로세스에서의 모든 의사결정 활동을 지원한다. 이는 각 업무 흐름 프로세스에서 발생하는 의사결정 업무를 지원하기 위하여 우선순위를 제공하고 모델을 확인하기 위하여 데이터 수집을 위한 분석, 절충연구, 모델링, 시뮬레이션, 시험 및 기술 데모를 수행하는 활동을 포함하고 있다.

3. 시스템 생산단계 또는 시스템 배치단계
시스템 개발단계가 종료될 때, 업무활동은 시스템 생산단계 또는 배치단계로 진행된다.
다음은 시스템 개발단계 업무 프로세스에 따라 V&V 전략이 어떻게 업무 진도에 따라 통합되는지를 살펴보아야 한다.

시스템 개발 업무에 V&V 활동 적용

지금까지 시스템 개발단계 프로세스를 살펴보고 단계적인 업무 흐름 순서를 기술했다. 이러한 각 프로세스 단계는 시스템 개발자로 하여금 다음과 같은 특정 목적을 수행하도록 도와준다.

· 대안 비교 분석에 대한 후보 솔루션 세트로부터 설계를 진행하면서 대안을 선정하라.
· 부품 레벨 컴포넌트를 획득, 조립, 제작 및 시험토록 하라.
· 다중 레벨 시스템 통합, 시험 및 평가를 수행하라.
· 가능하다면, 사용자 운용요구를 충족시키는 통합 시스템 여부를 확인토록 하라.

시스템이 획득자가 수락하고 납품될 때까지 다양한 설계 기준을 지닌 개발형상이 항상 진화해 가도록 한다. 따라서 잠재된 결함, 하자, 에러 및 유사한 문제점을 수정하기 위하여 재설계나 재보수를 요구해도 좋다. 그러면 이러한 결함을 어떻게 하면 줄여나갈 수 있을까? 바로 이것이 통합 검증 및 확인 전략의 필요성을 요구하게 된다. 이를 설명하기 위하여 그림 3을 참조토록 하라.



1. 체계 성능 규격서(SPS) V&V 절차
시스템 조달 기간 중 사용자와 획득자에 의해 식별된 운용 필요성은 체계 성능 규격서(SPS)로 문서화 된다. 이는 매우 중요한 단계이다. 왜냐하면, 사용자와 함께 협력하여 획득자가 바로 이 시점에서 조직의 문제 영역을 하나 또는 그 이상의 솔루션 영역으로 구별해 내어야 하기 때문이다.
각 솔루션 영역은 SPS에 명시된 요구사항으로 구속된다. 만일 전술적 또는 엔지니어링 판단에 에러가 발생될 경우, SPS에 문서화된 요구사항 자체가 명백하게 드러난다. 따라서 획득자, 사용자 및 궁극적으로 시스템 개발자가 다음 질문을 하게 된다. 우리는 하나 또는 그 이상의 운용 요구사항을 충족시키기 위하여 솔루션 영역에서 원하는 시스템을 구현하였느냐는 질문에 바르게 답해야 한다.
SPS 요구사항은 원하는 솔루션 영역에서의 시스템이 SPS에 따라 분명하고 정확하게 구현되었는지를 확인하기 위하여 운용 필요성에 대한 요구사항 확인을 수행해야 한다.
체계 성능 규격(SPS) 요구사항 확인에 관한 사용자와 조달자 간 협의가 민감하고 전문적으로 수행되어야 한다. 사실상 획득자가 그들의 업무를 잘 수행하고 있는지를 확인하는 활동이다. 한편으로 이러한 확인활동을 통해 잠재된 결함을 미리 알게 해 준 것에 대하여 감사하게 생각해야 한다. 거꾸로 당신은 이를 방어만 하고 있지 않은가. 따라서 매우 잘 이해하고 전문가다운 모습으로 진행하도록 함이 바람직하다.

2. SE 설계 V&V 절차
SPS 요구사항이 확인되고 나면, SPS는 시스템 설계의 원류 또는 소스 요구사항이 된다. 시스템 설계 기간 중 중간 살계검증 할당된 요구사항을 SPS에 의해 역으로 추적함으로써 시스템 설계 솔루션으로 진화해 가며, 실제 설계 분야에서 위험 완화 및 치명적인 운용 또는 기술문제(COI/CTI: Critical Operational or Technical Issue)를 해결해 간다. 설계확인 활동은 사용자와 사용자의 기술 대리인인 획득자는 진화해 가는 시스템 설계 솔루션이 그들의 요구를 충족시키고 있는지를 확정해야 한다.
중간 설계 검증과 중간 설계 확인 또는 설계 검증과 확인은 시스템이 계약에 따라 사용자와 획득자에 의해 검증, 확인 및 법적으로 수락될 때 완료된다고 볼 수 있다.
설계 검증과 확인은 SE 설계 프로세스를 통해 이루어진다. 확인은 기술검토(예를 들면, SDR, SSR, PDR 및 CDR), 기술 데모를 통해 수행된다. 개념도, 스케치, 도면, 프리젠테이션, 기술데모 및 시제품과 같은 미디어는 그 적합성을 살펴보기 위해 획득자 및 사용자 확인 수락과 승인을 하기 위해 사용된다. 시스템 레벨에서의 CDR을 종료한 후 업무 흐름은 컴포넌트 조달 및 개발 절차로 진행된다.

3. 컴포넌트 조달 및 개발 V&V 절차
컴포넌트 조달 및 개발 기간 중, 시스템 설계로부터 설계 요구사항은 시스템 컴포넌트에 대한 조달, 제작, 코딩, 조립의 기초로 사용된다.
각 컴포넌트는 설계 요구사항에 대한 컴포넌트 검증이 수행된다. 컴포넌트가 검증됨에 따라 업무 흐름은 시스템 통합, 시험 및 평가(SITE) 단계로 진행된다.

4. 시스템 통합, 시험, 및 평가(SITE) V&V 절차
컴포넌트 검증이 끝나면, 시스템 통합, 시험 및 평가단계로 진입한다. 이 프로세스 기간 중에 수행된 활동은 개발시험 및 평가(DT&E) 활동으로 나타난다. DT&E는 시스템 설계로부터 SITE를 통한 전반적인 시스템 개발 단계에 속한다. 이 상황에서의 DT&E 활동 목적은 시스템과 내장된 하부 시스템, HWCIs/CSCIs, 아셈부리, 부품이 시스템 외부 인터페이스와 내부 인터페이스에서 상호 적합하게 운용되는지를 확인함에 있다.
SITE 절차를 수행하기 위하여 SPS와 다중 레벨 품목 개발 규격(IDSs)에서 정의된 검증 방법과 요구사항은 검증 절차를 개발하는 데 사용된다. 검사, 분석, 시험, 데모 및 유사도로 구성된 검증 방법은 요구사항별 SPS에 정의되고 검증 일치성을 보기 위한 기초자료로 사용된다. 운용환경(초기 및 동적), 데이터 입력, 시험 기대 결과와 같은 시험환경 형상을 나타내는 하나 또는 그 이상의 세부 시험절차는 각 검증방법을 지원해 준다.
SITE 활동기간 중, 시스템 개발자는 공식적으로 획득자와 사용자를 대표하는 증인으로서 시스템을 시험하게 된다. 다중 레벨 시스템 검증활동은 적절한 체계통합 점에서 시험 데이터와 검증절차에 따른 결과 및 적합한 개발규격에 나타난 기대치를 검토한다.
시스템이 SITE 수행을 마치게 될 때, 공식적인 시스템 검증시험(SVT)결과와 SPS에 대한 시스템 능력과 성능을 비교 검증한다.

5. 시스템 베이스라인 검증 V&V 절차-일차 통과
SVT가 종료되면, 업무 흐름은 시스템 베이스라인 검증을 수행한다. 수행절차는 계약 요구사항에 따라 상이한 시기에 두 번의 검증절차에 따라 수행된다. 첫 번째 절차는 기능 형상 감사이다. 이는 기본적으로 SPS와 기타 개발규격 요구사항을 사용하여 SPS 기능 및 성능 요구사항과 완전 일치 여부를 잘 검증하고 SVT를 완료했는지를 보기 위해 설계, 제작, 검증 결과를 검토하는 활동이다. FCA는 SITE 절차 중 다양한 IP 레벨에서 수행된다.
FCA가 성공적으로 잘 마치게 되면 시스템은 사용자 시험장소나 사이트로 옮겨 운용 시험평가를 수행하게 된다. 운용 시험평가 완료 후 그 시스템은 다음 시스템 베이스라인 검증 단계로 넘어가게 된다.

6. 시스템 확인 프로세스 V&V 절차
지금까지 그 시스템은 SPS 요구사항 충족 여부를 확인하기 위하여 SVT 검증과 FCA 감사로 검증해왔다. 다음 단계는 설계, 제작 및 검증 시스템이 운용 시험평가 활동의 일환으로서 사용자 운용 필요성을 충족하고 있는지를 확인하는 활동이다.
시스템 확인 활동은 배치된 시스템이 얼마나 잘 초기 사용자가 제시한 운용환경에서 주어진 임무를 잘 수행하는지를 확인하는 활동이다. 시스템 확인 활동 기간 중 발생된 결함사항은 필요 시 보완요구 사항을 하자 보고서에 기록한 다음 해당 조직에 제출한다.
시스템 확인 기간 중 식별된 결함사항이 초기 계약자 SPS 범주 내에 속하는지 여부를 결정해야 한다. 바로 이것이 치명적인 쟁점사항이 된다. 예를 들면, 사용자와 획득자가 운용요구에 나타낸 특정 능력을 과장했거나 SPS에 문서화를 하지 않았거나 하는 경우이다. 따라서 시스템 수락 기간 중에 이러한 문제를 회피하기 위해 계약 전후로 요구사항 확인 활동을 다시 한 번 점검해 볼 것을 권장한다. 만일 결함이 계약 범위 밖이라면 획득자는 계약 내용을 수정하거나 추가적인 설계 노력을 통해 주어진 결함을 보완하기 위하여 추가 예산을 투입해야 한다.

7. 시스템 베이스라인 검증 V&V 절차-이차 통과
시스템 베이스라인 검증 2차 통과 기간 중, 설계, 제작 및 검증된 형상 시스템은 물리적 형상 감사 활동으로 진입한다. PCA는 설계, 제작 및 검증 물리적 시스템이 설계도면과 부품목록과 같은 설계 요구사항과 완전 일치 여부를 결정하기 위하여 수행된다. PCA의 성공적인 완료를 위한 시스템 검증 검토(SVR)는 다음과 같이 수행된다.

· FCA와 PCA 결과를 인증하라.
· 그 결과에 따른 중요한 PCA/FCA 쟁점사항을 해소하라.
· 의사결정 준비상태를 평가해 보라.

성공적인 운용시험 평가 프로세스를 완료한 후, 검증 및 확인 시스템은 획득자에 의한 공식적인 수락과 사용자 납품준비가 준비되어야 한다.
시스템 개발 단계 업무흐름에 따라 V&V 절차를 통합하는 일은 진화해 가는 개발형상에 따라 계획을 수립하는 과정을 기술한다.
그러나 계획을 수립하는 일은 시스템이 주어진 기간과 예산으로 사업을 순조롭게 종료할 수 있다는 보장을 해 주는 것은 아니다. 특히 대형 복합과제에 대한 개발은 하나 또는 그 이상의 위험요소를 지니고 있는 치명적인 운용과 기술적인 쟁점사항을 해소해야만 한다. 그래서 어떻게 이 위험을 감소시킬 수 있을까? 바로 이 토픽이 개발시험 평가(DT&E)와 운용시험 평가(OT&E)의 역할을 통한 다음 주제로 주어진다.

DT&E와 OT&E를 통한 위험감소 방안

시스템 개발을 성공적으로 종료하는 길은 앞서 논의된 모든 V&V절차의 강건한 설정을 요구한다. 우리는 앞서 모든 업무흐름이 순차적으로 되어 있다 할지라도 각 프로세스는 그림 4와 같이 반복적인 피드백 루프로 구성되어 있음을 이해해야 한다. 이를 수행하기 위하여 시스템 개발 단계에서 두 가지 시험 형태를 지니고 있다.

1. 개발 시험 평가(DT&E)
개발 시험(DT)은 모든 컴포넌트를 포함한 진화 하고 있는 시스템 설계 솔루션이 체계 성능 규격(SPS) 요구사항과의 일치성 여부를 확인하기 위한 위험감소 접근방법으로 사용된다. 따라서 DT는 다음 두 가지에 초점을 두고 있다.

(1) SPS와 일치하는 가장 좋은 방법으로 우리는 시스템이나 제품을 바르게 개발하고 있는가?
(2) 주어진 기술, 비용, 기법 및 일정 제약 상황에서 수용 가능한 위험 솔루션을 나타내는 설계 솔루션을 지니고 있는가?

DSMC T&E 관리 지침서는 DT&E의 목적을 다음과 같이 나타내고 있다.

· 잠재된 운용 및 기술 능력과 추구하는 대안개념과 설계 옵션에 대한 제약사항을 식별하라.
· 대안에 대한 능력과 제약사항 분석에 따라 비용효과 절충을 식별하여 지원하라.
· 기술적인 설계 위험요소 식별과 기술을 지원하라.
· 치명적인 운용 쟁점사항(COIs), 획득 기술적 위험 완화, 제작 프로세스 요구사항과 시스템 성숙 달성을 향해 진행토록 하라.
· 대안 비교 분석(AOA)을 통한 가정 사항과 결론에 대한 확인을 수행하라.
· 운용시험 평가를 위한 시스템 준비상태를 결정하기 위하여 필요한 데이터와 분석을 수행하라.
· 자동화 정보 시스템의 경우, 기밀 또는 민감한 데이터를 다루기 전에 정보 시스템 보안 인증을 지원하고 표준 인증을 받도록 하라.
*(소스: DSMC 시험 평가 관리 지침서 부록 B 6 페이지)

개발 시험 평가는 시스템 설계 프로세스, 컴포넌트 및 조달 프로세스, SITE 프로세스를 통해 수행된다. 각 프로세스 활동은 진화하고 성숙해 가는 시스템이나 제품 설계 솔루션-개발형상이 SPS 요구사항과 일치 여부를 검증하는 활동이다. 이는 검토, 원칙에 대한 입증, 데모를 통한 개념 입증, 기술 데모, 엔지니어링 모델, 시뮬레이션, 브라스 보드, 시제품을 통해 수행된다.
검증 종료 시, 물리적 시스템이나 제품은 사용자에 의해 문서화된 운용요구를 확인하기 위하여 OT&E 단계로 진입하게 된다.

2. 운용 시험 평가(OT&E)
운용 시험 평가(OT&E) 활동은 전형적으로 항공기와 군사 목적 획득 시스템과 같은 대형 복합 시스템에서 이루어진다. OT&E의 목적은 우리의 운용 요구에 적합하게 시스템이나 제품이 바르게 획득되고 있는가에 달려있다.
OT&E는 사용자 조직에서의 운용자로 하여금 실제 야전 운용 환경에 시험 품목을 사용하도록 구성된다. 획득자 또는 사용자에 의해 지명된 독립 시험부서(ITA)가 전형적으로 이 시험을 수행한다.
독립성을 보장하고 이해관계에서의 충돌을 피하기 위하여 계약 당사자는 OT&E에 시스템 개발자를 참여토록 한다. 그러나 시스템 개발자는 필요 시 정비지원을 수행토록 함에 있다.
OT&E의 목적은 개발된 신규 시스템 또는 제품으로 얼마나 잘 시스템 사용자가 수행할 수 있는가에 달려있기 때문에 시스템 시험평가기관(ITA)이나 시스템 개발자는 운용인력이 그 시스템을 잘 작동할 수 있도록 사전에 교육해야 한다. 이를 통해 시스템 배치 이전 시스템 검증시험(SVT)이나 운용시험평가 사이트 도착 전에 이행되는 것이 바람직하다.
운용시험 평가기간 중 시험평가기관(ITA)은 운용인력으로 하여금 실제 운용환경 조건에서의 다양한 운용 유스케이스와 시나리오 수행방법을 훈련토록 한다. 이러한 유스케이스와 시나리오는 시스템의 운용 유틸리티, 적합성, 가용성 및 효과도를 평가하기 위하여 제시된다.
ITA 인력은 시스템이 사람과 시스템의 인터페이스와 반응을 관찰하고 기록하기 위하여 계측장비를 설치한다. 상호관계에 대한 결과는 기록, 요약 및 추천사항과 함께 제시해야 한다. 개발시험, 운용시험 및 중간 시스템 베이스라인 프로세스, 검증과 확인된 시스템이나 제품의 성공적인 수행결과는 최종 수락을 위해 획득자나 사용자에게 넘겨진다.

지침

앞서 제시된 모든 자료는 시스템 개발 업무흐름 실무전략을 나타내는 지침을 설정하기 위한 기반을 제공하고 있다.
[원칙 1] 시스템 개발전략은 다음 세 가지 요소로 구성된다.

· 계약으로부터 시스템 수락 및 납품에 이르기까지 점진적인 검증 및 확인 활동에 대한 전략 기반 로드맵
· 전략 이행 활동계획
· 계약 수행에 따른 각종 산출물 품질기록문서에 대한 목적 입증

[원칙 2] 시스템 검증과 확인은 계약단계에서 시작하여 시스템 납품 및 수락에 이르기까지 수행되는 모든 제품개발 업무흐름 단계에 적용된다.
[원칙 3] 개발 시험 평가는 시스템 개발자가 개발형상 위험을 완화하기 위해 수행된다면, 사용자는 운용시험 평가 활동을 통해 그들이 요구하는 시스템을 제대로 획득하고 있는지를 결정하게 된다.

요약

시스템개발전략 업무흐름을 통해 우리는 시스템 개발단계 프로세스를 살펴보았다. 시스템 개발단계 프로세스는 다음 사항을 포함하고 있다.

시스템 설계
컴포넌트 획득 및 개발
시스템 통합, 시험, 및 평가(SITE)
시스템 베이스라인 입증
운용시험 평가(OT&E)

시스템 개발단계 프로세스를 기반으로 검증 및 확인을 위한 전반적인 업무흐름 전략을 기술했다. 이 전략은 사용자의 확인된 운용요구를 납품할 시스템, 제품, 또는 서비스로 전환하기 위한 상위레벨 구조를 제공하고 있다.
개발시험평가 및 운용시험평가 개념을 소개했다. 개발시험과 운용시험이 어떻게 주요 검증 및 확인 활동과 시스템 개발 업무흐름 전략과 연관되어 있는지를 보여주고 있다.

1. 일반적 질문사항

서론에서 제시된 본 장에 대한 질문사항을 한 번 점검해 보라. 그리고 무엇을 이해했는지 답변해 보라.
표 1에 제시된 시스템을 사용하여 전반적인 V&V 전략으로 통합될 각 시스템 개발 단계 프로세스 활동을 기술해 보라.

2. 조직중심 질문사항
1) SE 관점에서 시스템 개발단계 적용 시, 당신 조직 지침과 방향을 검토해 보라.

· 어떠한 요구사항이 SE에 기여하고 있는가?
· 어떠한 전반적인 프로세스가 SE 적용을 위해 필요한가?
· 어떠한 SE 산출물과 품질기록이 필요한가?
· 어떠한 검증 및 확인 활동이 필요한가?

2) 당신 조직 내에서 소형, 중형 및 대형 프로그램 수행자와 의논하여 다음 정보를 수집하기 위하여 기술본부장이나 사업관리자와 인터뷰토록 하라.

· 자체 개발 전략을 그래픽으로 나타내기 위한 요원을 협조하라.
· 적용 전략을 구상하기 위해 무슨 요소를 고려해야 하는지를 제시해 보라.
· 이 접근방법을 적용하기 위해 교훈을 제시해 보라.
· V&V 전략을 적용해 본 소감을 말해보라.

민성기 시스템체계공학원장(ise@seinstitute.co.kr)