와이즈스톤 와이즈스톤

기술인사이트

기술리포트

무기체계 소프트웨어의 SE 단계별 개발산출물 기술검토 방법
  • 작성자
    와이즈스톤 최윤석 선임연구원
  • 작성일
    2023-08-25

1. 작성 배경

안녕하세요, 오늘의 포스팅 주제는 무기체계 소프트웨어의 SE(System Engineering:체계 공학) 단계별 개발산출물 기술검토 방법입니다. 먼저 무기체계 소프트웨어의 SE에 대한 개념을 설명하고 다음으로 국방 무기체계 소프트웨어의 SE 단계별 개발산출물의 기술검토 방법에 대하여 설명하도록 하겠습니다.

일반적으로 국방 무기체계는 다른 소프트웨어에 비해 개발 기간이 오래 소요되고, 그에 따른 다양한 시험과 복잡한 검증 단계를 거쳐서 무기체계가 각 부대에 실전 배치를 위한 전략화 하는데 수년간의 시간이 소요됩니다. 하지만, 이렇게 어려운 과정을 거쳐 개발된 무기체계가 실전 배치를 위한 전략화 되지 못하거나, 실전 배치가 되었어도 기대했던 요구사항과 성능이 만족하지 못한다면 개발 시간과 비용 등 막대한 손해를 끼치게 됩니다. 그만큼 국방 무기체계의 기술 개발 및 연구는 국가 전략 산업으로 대단히 중요한 부분을 차지하고 있습니다.

국방에서 사용되는 무기에서도 기계 분야가 중심이었던 과거와는 다르게 21세기에 들어서면서 IT 기술발전 등 현대전으로 넘어오면서 아군의 인적 및 물적 장비 등의 피해를 줄이고 적의 인적 및 물적 장비 등을 정밀 타격하여 피해를 극대화 시키기 위해 무기체계에도 소프트웨어가 탑재되기 시작했습니다. 최근 우크라이나와 러시아의 전쟁에서 살펴보면 우크라이나 군이 드론을 통해 공격하여 러시아 군을 정밀 타격해 큰 피해를 줬다는 뉴스를 접해 보셨을 겁니다. 이처럼 무기체계에서 소프트웨어의 탑재는 이제는 선택이 아닌 필수가 되어가고 있으며, 무기체계는 SW의 기술 개발의 발전으로 인하여 점점 진화하고 있습니다.

따라서 오늘 포스팅에서 국방 무기체계의 SE 개념을 설명하고, SE 단계별 개발산출물 기술검토 방법에 대해서 알아보는 시간을 갖도록 하겠습니다.


2. SE(System Engineering : 체계 공학) 개념

체계 공학이란 사용자 요구사항으로부터 요구사항 분석, 설계·제작, 검증·확인, 운용, 폐기에 이르는 모든 단계를 수명주기(Life Cycle) 관점을 고려하여 사용자의 요구사항을 충족하도록 경제적, 균형적으로 체계를 개발하는 방법론입니다.
무기체계의 체계 공학 적용은 연구개발 전체 과정 간 이해관계자들의 다양한 요구사항을 무기체계에 반영하고 확인할 수 있게 합니다. 또한, 비용, 일정, 성능 등 전체 문제를 고려하여 탐색개발, 체계개발, 시험평가, 양산, 배치, 운용, 지원 및 폐기와 관련된 모든 기술적 노력을 효율적으로 통합할 수 있고, 연구개발 사업관리의 의사결정 과정을 지원하여 신뢰성 높은 무기체계를 개발할 수 있습니다.
체계 공학 프로세스는 ISO/IEC 15288(시스템 및 소프트웨어 엔지니어링 – 시스템 수명 주기 프로세스)를 기반으로 기술 프로세스와 기술관리 프로세스로 구분합니다

그림1. 기술 프로세스와 기술관리 프로세스
(출처 : 방위사업청-무기체계 연구개발단계 품질관리 기술지원 가이드북)


● 기술 프로세스와 기술관리 프로세스 구분



3. 무기체계 소프트웨어 개발 프로세스

무기체계의 개발 프로세스는 먼저 주요 검토 항목을 식별하고, 연구개발주관기관의 체계개발 단계의 체계 요구사항 분석을 시작으로 체계 구조설계, 소프트웨어 요구사항 분석, 소프트웨어 구조설계, 소프트웨어 상세설계, 소프트웨어 구현, 소프트웨어
통합 및 시험, 체계통합 및 시험순으로 진행됩니다.

그림2. 무기체계 개발 프로세스
(출처 : 방위사업청- 무기체계 소프트웨어 개발 및 관리 매뉴얼)


4. 체계 요구사항 분석(System Requirements Analysis)

● 개요
체계 요구사항분석 단계에서는 개발하고자 하는 체계의 사용자 요구사항을 분석하여 향후 체계설계에 필요한 체계 요구사항을 도출합니다. 체계 요구사항은 체계 기능과 성능요구사항, 조직 및 사용자 요구사항, 안전 및 보안 요구사항, 인간공학 요구사항, 인터페이스 요구사항, 운영 및 유지보수 요구사항, 하드웨어 요구사항, 설계 제한사항 등을 포함되며, 체계 요구사항은 체계 요구사항 검토 회의(SRR)를 통해 검토 후 확정됩니다.

● 주요 활동
가. 체계 요구사항 정의
나. 체계 요구사항 세부 분석 검토
다. 체계 요구사항 확정
라. 소프트웨어 개발 계획 수립
마. 체계 요구사항 검토 회의(SRR:System Requirement Review)
1) 체계 요구사항을 정의한 내용을 확인하기 위해 수행되는 검토 회의로써. 소요군, 운용요구에 기술된 체계 및 요구사항을 분석, 검토하고 체계 요구사항의 기술 수준이 허용 가능한 수준인지 검토합니다.
2) 탐색개발 단계에서 수행되나 체계개발 단계 초반에 다시 수행될 수 있습니다.
3) 검토 회의를 통해 체계 요구사항 명세서가 확정됩니다.

● 업무절차
그림3. 체계 요구사항 분석단계 업무절차도
(출처 : 방위사업청- 무기체계 소프트웨어 개발 및 관리 매뉴얼)

● 체계 요구사항 분석단계 산출물 및 산출물 검토 시 주요 고려할 사항
가. 체계요구사항명세서(SSRS)
1) 체계 상태 및 모드가 설명되어 있는지 확인
2) 체계 능력 요구사항이 하부체계별로 누락 없이 적절히 제시되어있는지 확인
3) 외부 및 내부 인터페이스 요구사항이 체계 운용개념을 반영하여 적절히 기술되어 있는지 확인
4) 체계 내부자료 요구사항 식별상태를 확인
5) 체계 설치에 필요한 적응(adaptation)요구사항 식별상태를 확인

나. 소프트웨어개발계획서(SDP)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성 가이드 중 “소프트웨어기술문서-01 소프트웨어개발계획서” 서식에 준하여 작성하였는지 확인
2) 무기체계 소프트웨어 개발 및 관리 매뉴얼 부록 3. 개발단계별 산출물 점검표 중 “소프트웨어개발계획서 점검표”를 기준으로 확인
3) 내장형 소프트웨어 분류체계 식별자 관리 및 활용계획이 포함되어 있는지 확인
4) 개발에 적용할 개발절차, 개발방법론, 개발언어 등에 대한 적용계획 및 관리방안에 대해 적용 사유를 포함해 제시된 내용이 적절한지 확인
5) 무기체계 소프트웨어 개발 및 관리 매뉴얼 부록 6. 무기체계 소프트웨어 코딩규칙을 준용한 소스코드 작성 계획이 명시되어 있는지 확인


5. 소프트웨어 구조설계(Software Architectural Design)

● 개요
소프트웨어 구조설계 단계에서는 소프트웨어 형상항목(CSCI)의 요구사항을 상위 수준의 구조를 나타내는 아키텍처로 변환하고 소프트웨어 구성품(CSC)을 식별하며, 소프트웨어 구성품(CSC)은 최소 빌드 단위로 선정할 수 있습니다.
또한 소프트웨어 형상항목 외부 인터페이스와 소프트웨어 형상항목내 소프트웨어 구성품간 인터페이스를 상위수준으로 식별하고 상위수준의 데이터베이스를 설계합니다. 모든 소프트웨어 형상항목 요구사항이 소프트웨어 구성품으로 할당되어야 하며, 소프트웨어 구조설계 결과는 기본설계검토회의를 통해 검토 후 확정됩니다.

● 주요 활동
가. 소프트웨어 구조정의 및 설계
나. (개략)인터페이스 설계
다. (개략)데이터베이스 설계
라. 소프트웨어 구조설계 확정
마. 기본설계 검토회의(PDR:Preliminary Design Review)
1) 각 소프트웨어 형상항목에 대한 구조설계, 기술적 적합성, 위험(기술, 비용, 일정) 해결 방법 등을 검토합니다.
2) 기본설계검토회의는 소프트웨어설계기술서, 인터페이스설계기술서, 데이터베이스설계기술서에 명시된 소프트웨어 형상항목(CSCI) 구조설계에 대한 공식 검토 활동으로 소프트웨어 형상항목별 요구사항을 기준으로 검토합니다.

● 업무절차
그림4. 소프트웨어 구조설계단계 업무절차도
(출처 : 방위사업청- 무기체계 소프트웨어 개발 및 관리 매뉴얼)

● 소프트웨어 구조설계단계 산출물 및 산출물 검토 시 주요 고려할 사항
가. (개략)소프트웨어설계기술서(SDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-03 소프트웨어설계기술서” 서식에 준해서 작성하였는지 확인
2) 소프트웨어 구조가 체계 구조와 일관성이 있는지 확인
3) 소프트웨어 형상항목(CSCI)의 설계 결정사항이 식별되어 있는지 확인
4) 소프트웨어 형상항목(CSCI)의 구성품(CSC)이 식별되어 있는지 확인
5) 소프트웨어 구성품(CSC)에 대한 실행개념이 상세하게 기술되어 있는지 확인준용한 소스코드 작성 계획이 명시되어 있는지 확인

나. (개략)인터페이스설계기술서(IDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드의 “소프트웨어기술문서-04 인터페이스설계기술서” 서식에 준해서 작성하였는지 확인
2) 소프트웨어 형상항목, 소프트웨어 인터페이스 대상, 소프트웨어 구성요소의 인터페이스특성이 포함되어 있는지 확인
3) 인터페이스에 고유한 식별자를 부여하여 표현하고 인터페이스가 될 실체가 명확히 식별되었는지 확인
4) 알기 쉽게 표현된 내·외부 인터페이스에 대한 관계도가 포함되어 있는지 확인
5) 아래의 인터페이스 특성에 관한 사항들이 포함되어 있는지 확인
- 인터페이스 실체(instance)들이 인터페이스가 되는 우선순위
- 인터페이스 형태(예, 실시간 데이터 전송 등)
- 인터페이스 실체들이 제공/저장/전송/접근/수신해야 할 각 데이터 요소에 대한 특성
- 인터페이스 실체들이 제공/저장/전송/접근/수신해야 할 각 데이터 집합체에 대한 특성
- 인터페이스 실체가 인터페이스에 사용할 통신방식에 관한 특성
- 기타 물리적인 적합성, 전압, 상호 영향을 미치는 요소 등 특성

다. (개략)데이터베이스설계기술서(DBDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-05 데이터베이스설계기술서” 서식에 준해서 작성하였는지 확인
2) 내부적인 구현 내용이 아닌 사용자의 관점에서 사용자의 요구사항을 만족하기 위해 데이터베이스가 어떻게 작동할 것인지에 관한 사항을 확인
3) 다음 사항들에 대한 내용이 포함되어 있는지 확인
- 데이터베이스가 허용하는 입력 및 생성할 출력과 관련된 설계결정사항
- 데이터베이스 입력 또는 조건에 대응되는 작동, 선정한 방정식/알고리즘/법칙, 입력 및 조건과 관련된 설계 결정사항
- 사용자에게 데이터베이스가 어떻게 보여 질 것인가에 대한 설계 결정사항
- 사용될 데이터베이스관리시스템(DBMS) 및 요구사항 변경에 대응하기 위해
데이터베이스에 구현되어야 하는 융통성의 유형에 대한 설계 결정사항
- 데이터베이스가 제공하여야하는 가용성, 보안성 및 연속성의 수준과 유형에 대한 설계 결정사항
- 데이터베이스의 분산 및 유지에 관한 설계 결정사항
- 자료의 백업과 복원에 관한 설계 결정사항
- 정렬, 인덱싱, 동기화 및 일관성에 관한 설계 결정사항
- 개념적, 논리적 데이터베이스 설계 내용


6. 소프트웨어 상세설계(Software Detailed Design)

● 개요
소프트웨어 상세설계단계에서는 소프트웨어 구조설계단계에서 식별된 각 소프트웨어 구성품(CSC)을 상세히 설계합니다. 개발할 단위 소프트웨어(CSU)를 식별하고 단위 소프트웨어(CSU)의 최소단위는 파일 혹은 클래스로 선정할 수 있으며, 각 단위 소프트웨어의 외부 인터페이스, 단위 소프트웨어 내부의 처리 작업을 상세하게 설계합니다.
소프트웨어 구성품은 코딩할 수 있고, 컴파일 할 수 있고, 시험할 수 있는 단위 소프트웨어 수준으로 세분화 되어야 하며, 모든 소프트웨어 요구사항은 소프트웨어 구성품으로부터 단위 소프트웨어로 할당되어야 합니다. 소프트웨어 상세설계결과는 상세설계검토회의를 통해 검토 후 확정됩니다.

● 주요 활동
가. 소프트웨어 구성요소 상세설계
나. 인터페이스 상세설계
다. 데이터베이스 상세설계
라. 소프트웨어 상세설계 확정
마. 소프트웨어 단위시험 계획 수립
바. 소프트웨어 통합시험 계획 수립
사. 상세설계검토회의(CDR : Critical Design Review)
1) 각 소프트웨어 형상항목(CSCI)의 구성품(CSC)에 대한 상세설계 결과가 성능과 공학적 특수 요구사항을 충족하는지를 결정하기 위해 상세설계 완료시 수행되는 검토회의입니다.
2) 상세설계검토회의(CDR)는 소프트웨어 구성품(CSC)으로부터 단위 소프트웨어(CSU)를 식별하고, 단위 소프트웨어 간의 인터페이스, 단위 소프트웨어 내부의 처리 작업을 상세하게 설계하는 소프트웨어 상세설계 단계에 대한 공식적인 검토회의입니다.

● 업무절차
그림5. 소프트웨어 상세설계단계 업무절차도
(출처 : 방위사업청- 무기체계 소프트웨어 개발 및 관리 매뉴얼)


● 소프트웨어 상세설계단계 산출물 및 산출물 검토 시 주요 고려할 사항
가. (상세)소프트웨어설계기술서(SDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-03 소프트웨어설계기술서” 서식에 준하여 작성하였는지 확인
2) 기체계 소프트웨어 개발 및 관리 매뉴얼 부록 3. 개발단계별 산출물 점검표 중 “소프트웨어설계기술서 점검표”를 기준으로 확인
3) 소프트웨어 분류체계 식별자가 본 매뉴얼을 준수하여 소프트웨어 구성품(CSC) 단위로 작성되었는지 확인한다. 이때, 분류체계 식별자는 4영역까지 작성되어있는지 확인
4) 단위 소프트웨어(CSU) 알고리즘은 인지 가능하게 기술되어 있는지 검토
5) 상위수준 소프트웨어설계기술서를 토대로 상세설계 결과를 구체화했는지 확인

나. (상세)인터페이스설계기술서(IDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-04 인터페이스 설계기술서” 서식에 준하여 작성하였는지 확인
2) 구조설계에서 작성한 인터페이스설계기술서 내용 중 상세설계 단계에서 변경된 사항이 있는지 확인
3) 상위수준 인터페이스설계기술서를 토대로 상세설계 결과를 구체화했는지 확인
4) 인터페이스 설계 결정사항을 식별, 제시하였는지 확인
5) 인터페이스 식별자 부여규칙의 적절성을 확인

다. (상세)데이터베이스설계기술서(DBDD)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-05 데이터베이스 설계기술서” 서식에 준하여 작성하였는지 확인
2) 구조설계에서 작성한 데이터베이스설계기술서 내용 중 상세설계 단계에서 변경된 사항이 있는지 확인
3) 상위수준 인터페이스설계기술서를 토대로 상세설계 결과를 구체화했는지 확인
4) 데이터베이스 설계에 영향을 주는 결정사항들을 식별, 제시하였는지 확인
- 데이터베이스 보안(자료보안, 접속보안, 접근제어)
- 사용될 DBMS 정보, 백업/복구 방안
- 성능관련 설계 결정사항(반정규화, 테이블 및 인덱스 설계 관련) 등
5) 데이터베이스 구성요소에 대한 명명규칙의 적절성을 확인

라. 소프트웨어통합시험계획서(STP)
1) 무기체계 소프트웨어 개발 및 관리 매뉴얼 별책 : 무기체계 소프트웨어 기술문서 작성가이드 중 “소프트웨어기술문서-06 소프트웨어통합시험계획서” 서식에 준하여 작성하였는지 확인
2) 소프트웨어 통합을 위한 방법, 일정 등 계획이 작성되어있는지 검토
3) 소프트웨어 신뢰성 및 보안성(전장관리정보체계) 시험 계획이 구체적으로 제시되어 있는지 검토
4) 소프트웨어 통합시험 계획이 구체적으로 제시되어있는지 확인
5) 모든 소프트웨어 요구사항에 대해 시험계획이 작성되었는지 확인

마. 인터페이스통제문서(ICD)
1) 연동사항 식별상태를 확인
- 연동개념
- 연동방식
- 연동 책임 범위
2) 연동 대상 정보가 구체적으로 식별되어 있는지 확인
3) 물리적 연동 방법의 구체성을 확인
- 논리적, 물리적 접점
- 물리적 연동규격 등



7. SE(System Engineering:체계 공학) 단계별 개발산출물 기술검토 수행 방법

SE 단계별 개발산출물 기술검토 시 수행 방법을 설명하겠습니다. 4가지의 방법을 통해 SE 단계별 개발산출물의 기술검토를 수행합니다.

그림6. SE(System Engineering : 체계 공학) 단계별 개발산출물 기술검토 수행 전략

첫 번째로는, SE 단계별 산출물의 기술검토 시 Check List를 활용하는 방법입니다.
각 SE 단계에서 생산되는 개발산출물에 대한 검토 시 고려사항을 바탕으로 Check List를 구성하여 개발산출물별 점검항목을 관리하고 평가하는 목적으로 활용합니다.

그림7. 개발산출물 검토 시 Check List 예시

두 번째로는, SE 단계별 작성자와 인터뷰 진행을 하는 것입니다.
작성자와 인터뷰를 진행하여 해당 무기체계의 소프트웨어 기능을 식별하고, SE 단계별 개발산출물에 관한 내용을 파악하는 것을 목적으로 인터뷰를 진행합니다. 또한, Check List를 활용해 개발산출물의 기술검토 시 발생한 이슈 사항 등을 공유하여 개발산출물의 개선사항 제시를 통해 SE 단계별 개발산출물의 품질향상을 목표로 합니다.

세 번째로는, Check List를 활용한 개발산출물 기술검토 후 검토자 간 동료 검토를 수행하는 것입니다.
동료 검토는 소프트웨어 개발단계에서 생성되는 여러 가지 작업 산출물들에 잠재된 오류 및 결함들을 동료의 도움을 받아서 발견, 제거할 목적으로 수행하는 검토 활동을 말합니다. 동료 검토를 수행하는 이유는 소프트웨어 개발단계에서 생성되는 개발산출물들의 잠재적인 오류 및 결함 제거를 통해 개발산출물의 품질을 향상시키고, 이러한 과정으로 인해 일어날 수 있는 수정 재작업을 최소화할 수 있기 때문입니다. 따라서 SE 단계별 개발산출물 검토 간 발생 가능한 잠재된 오류 및 결함을 제거하기 위해 동료 검토를 수행하여 SE 단계별 개발산출물 검토의 품질향상과 수정 재 작업의 최소화를 목적을 두고 있습니다.

마지막 네 번째로는, 내실 있는 검토의견서를 작성하는 것입니다.
Check List를 활용한 일관성 있는 기술검토, 작성자와 인터뷰를 결과를 통해 무기체계 소프트웨어 기능 식별 및 개발산출물의 내용 파악과 기술검토 시 이슈 사항을 공유하여 개발산출물의 개선사항 제시 등의 기술검토 활동으로 내실 있는 검토의견서를 작성합니다. 각 SE 단계별 검토회의(체계요구사항 검토회의(SRR), 기본설계 검토회의(PDR), 상세설계 검토회의(CDR)) 진행 시 활용하여 해당 무기체계의 품질향상을 제고 할 수 있도록 합니다. 검토의견서에는 개발산출물의 검토 활동에 대한 내역과 검출된 결함에 대한 정보를 기록하고, 개발산출물별 결함의 조치사항 확인 등의 내용이 작성되어야 합니다.

그림8. 개발산출물 검토의견서 예시


8. 마무리하며

지금까지 본 포스팅으로 체계 공학의 개념과 SE 단계별 개발산출물의 기술검토 시 고려사항과 기술검토 방안에 대해 알아보는 시간을 가졌습니다. 무기체계 소프트웨어도 마찬가지로 일반적인 소프트웨어와 비슷한 개발 프로세스를 따르고 있으며, 개발산출물의 내용만 다를 뿐 소프트웨어의 요구사항 파악, 소프트웨어의 기본설계, 소프트웨어의 상세설계 등 동일한 절차로 수행되고 있습니다. 따라서 Check List 활용, 작성자와 인터뷰, 동료 검토, 검토의견서 작성 등 소프트웨어 산출물의 정적 분석에서 활용되는 방법들을 통해 SE 단계별 개발산출물의 기술검토를 수행합니다.

향후 IT 및 SW의 기술발전에 따라 국방 무기체계 소프트웨어는 더욱 다양해지고 고도화 될 것으로 기대됩니다. 또, 인공지능 기술이 적용된 무기체계 소프트웨어가 등장할 것으로 예상되며, 무기체계의 부품 국산화에 따른 SE 단계별 개발산출물 검토 프로세스 또한 고도화될 것으로 생각합니다. 따라서 무기체계 소프트웨어의 기술발전으로 인한 SE 단계별 기술검토 방안의 고도화 및 무기체계 소프트웨어의 기술 동향 파악 등으로 무기체계 소프트웨어의 지속적인 관심을 가져야겠습니다.

다음 포스팅에서는 ‘무기체계 소프트웨어의 통합시험 개발산출물 검토’에 대하여 알아보도록 하겠습니다.
감사합니다.


[참고문헌]
방위사업청 : 무기체계 소프트웨어 개발 및 관리 매뉴얼
방위사업청 : 무기체계 연구개발단계 품질관리 기술지원 가이드북
프리렉 : 소프트웨어 품질관리 실무 가이드