개발단계 데이터를 활용한 무기체계 소프트웨어의 신뢰도 분석 연구
조 현 주†
†국방과학연구소, 함정전투체계개발단
A Study on Reliability Analysis for Weapon System Software using data from development phase
Hyunju Cho
††Naval Combat Systems PMO, Agency for Defense Development, Korea (Received : Mar. 29, 2019, Revised : May. 15, 2019, Accepted : Jun. 19, 2019)
Abstract : Software reliability is one of the most important elements of quality. As the proportion of software in the system increases, the importance of analysis for software reliability is also increasing. In particular, weapon system software in the defense domain requires higher reliability. Therefore, the reliability of software in the development of weapon systems should be strictly analyzed and managed quantitatively However, the conventional reliability analysis of weapon system software is only static analysis at the code level. Therefore, this paper proposes a more systematic and quantitative analysis method for reliability of weapon system software. By showing the actual results applied to OO weapon system development, we can verify the practicality of the analysis model.
Keyword : Weapon System Software, Software Reliability, Reliability Analysis
1. 서 론
1)
소프트웨어 신뢰도는 품질의 가장 중요한 요소 중 하나이다. 시스템에서 차지하는 소프트웨어의 비중이 점차 증가함에 따라, 소프트웨어 신뢰도 분석에 대한 중요성은 날로 증대되고 있다. 특히 국방 도메인에서 의 무기체계 소프트웨어는 보다 높은 신뢰도를 필요로 한다. 그러므로 무기체계 개발과정에서 소프트웨어의 신뢰도는 엄격한 기준에 따라 정량적으로 분석되고 관 리되어야 한다.
그러나 종래의 무기체계 소프트웨어에 대한 신뢰도 분석은 코드레벨에서의 정적/동적 분석에 지나지 않았 다.[1] 따라서 본 논문에서는 보다 체계적이고 정량화
†Corresponding Author 성 명 : 조 현 주
소 속 : 국방과학연구소 함정전투체계개발단 주 소 : 경남 창원시 진해구 충장로 국방과학연구소 전 화 : 055-540-6719
E-mail : [email protected]
된 무기체계 소프트웨어 신뢰도 분석 방법을 제시하고 자 한다. 특히, OO 무기체계 개발 사업에서 실제 적 용된 결과를 확인함으로써 분석 모델에 대한 실용성을 보여준다.
IEEE에서는 소프트웨어 신뢰도를 ‘정해진 시간 동 안 특정한 상태에서 요구된 기능을 올바르게 소프트웨 어나 컴포넌트가 수행되는 능력’으로 정의하고 있다.
소프트웨어 신뢰도를 보증하기 위해 주로 시험단계에 서 버그를 발견하고 수정한다. 하지만 전달된 코드의 신뢰도는 단순 시험단계의 버그에만 관련이 있는 것이 아니라, 모든 개발과정 및 프로세스와 연관을 갖고 있 다. 따라서 소프트웨어 신뢰도를 보증하는 더 나은 방 법은 소프트웨어 생명주기 전 단계에 걸쳐 더 엄격하 고 체계적인 관리 프로세스를 수행하는 것이다.[2]
이를 위해 소프트웨어 개발단계의 신뢰도 데이터 정 량화가 필수적으로 요구된다. 데이터 정량화는 객관적 인 평가를 가능하게 만들기 때문에 올바른 의사 결정 및 분석을 수행하는 데에 필수적이다. 데이터 정량화 기법에는 측량(Measurement)과 계산(Calculation) 이 있다. 측량은 어떤 현상이나 결과, 성질을 숫자로 써 표현하는 활동이며 측량의 결과는 측도(Measure)
라고 불린다. 반면, 계산은 몇 가지 측량된 값을 합치 거나 수학적 공식을 이용하여 정량화 하는 과정을 의 미한다. 계산의 결과를 척도(Metric)라고 부른다. 정 리하자면, 측도는 제품을 정량화한 직접적인 값이며, 척도는 계산을 통해 구한 간접적인 값이다. 소프트웨 어 개발에서 이러한 정량화 기법은 개발 중인 소프트 웨어의 상황을 평가하기 위해 필수적이며, 데이터 수 집 활동은 소프트웨어 생명주기 전체에 걸쳐 수행되어 야 한다. 소프트웨어 측량은 소프트웨어 품질 보증 공 학에 있어서 필수적인 활동이 되었다.
소프트웨어 신뢰도 척도는 소프트웨어 신뢰도 평가 및 보증과 같은 다양한 방법으로 사용된다. 또한 소프 트웨어 신뢰도 관리와 시험 프로세스 감시, 시험 일정 예측 등을 위한 정량적인 지표를 제공한다. 게다가, 소 프트웨어 신뢰도를 평가하고 검증함으로써 비용과 일 정, 신뢰도 간의 trade-off를 분석하는데 사용되기도 한다. 하지만, 모든 소프트웨어에 동일한 신뢰도 척도 를 적용할 수 없기 때문에, 서로 다른 소프트웨어 특성 과 서로 다른 개발 단계의 특성에 따라 어떻게 적절한 척도를 선택할 것인지는 매우 어려운 문제이다. 예를 들어, 임의로 매우 많은 척도를 선택하는 것은 많은 자 원과 업무 부담을 요구 하며, 반대로 적은 수의 척도를 선택하는 것은 소프트웨어 및 개발 특성을 제대로 반영 할 수 없다. 따라서 적절한 척도의 선정이 소프트웨어 신뢰도 시험과 평가를 위해 매우 중요하다.
올바르게 정립된 소프트웨어 신뢰도 척도는 소프트 웨어 개선을 위한 근거를 제시하고 비용-효과 분석을 가능하게 하며, 의사 결정을 위한 기반을 제공한다.
현재 국방 시스템 분야에서는 소프트웨어 신뢰도에 대 한 필요성은 제기되었으나 주로 하드웨어 신뢰도에 집 중이 되어 있으며, 소프트웨어 신뢰도는 코드레벨에서 의 정적/동적 시험에 국한되어 왔다. 국방 분야에서 무기체계의 신뢰도 보증을 위해서는 하드웨어 신뢰도 뿐만 아니라, 소프트웨어 신뢰도역시 중요하게 고려 및 평가되어야 하며 개발 특성에 맞는 평가 척도와 절 차가 필요하다.
본 논문에서는 OO 무기체계 개발 사업에서 연구 및 적용한 소프트웨어 신뢰도 분석 방안을 제시한다.
국방과학연구소에서 개발 중인 OO 무기체계는 은밀성 이 향상되고 있는 적 잠수함 및 수상함에 대한 대응능 력 및 적 전략표적에 대한 장거리 타격능력을 보유하 고, 동시 다발적인 전투 상황 하에서 최고의 전투력을 발휘할 수 있도록 해군의 작전/전술 개념을 반영하여 전략무기의 비닉성이 확보된 대한민국 독자 모델의 무 기체계로 현재 개발 진행 중에 있다. OO 무기체계 역 시 시스템의 신뢰성은 곧 생존성에 직결되는 사항으 로, 하드웨어뿐만 아니라, 소프트웨어의 신뢰도를 체 계적으로 분석하기 위한 연구를 수행하였다.
2. 소프트웨어 신뢰도 모델
대부분의 시스템 및 소프트웨어 개발에서 높은 신뢰 성의 소프트웨어를 개발하기 위해 노력하고 있으나,
개발 중인 소프트웨어의 현재 시점의 신뢰성을 판단하 는 것은 어려운 문제이다. 개발 중인 소프트웨어에서 측정되는 데이터는 주로 소프트웨어 결함 수이다. 그 러나 신뢰성을 보증하기 위해서 중요한 것은 단지 결 함 수만 필요한 것은 아니다. 기존에 발생한 결함 수 를 이용해서 다음번의 결함 수를 예측하거나 남아있는 결함 수를 추정하는 활동이 더욱 중요하다고 할 수 있 다. 이러한 활동들을 가능하게 하는 것이 소프트웨어 신뢰성 모델이다.
소프트웨어 신뢰성 모델은 소프트웨어를 정량적으로 측정하여 신뢰성을 평가하고 품질보증 방안 및 개선 전략을 제시하는 기술이다. 그리고 주어진 운영 환경 또는 조건에서 결함 데이터를 기반으로 소프트웨어 신 뢰성을 추정하고 예측할 수 있는 통계적인 모델로 정 의한다. 소프트웨어 신뢰성 모델은 1970년대부터 현 재까지 약 300여개가 개발되었다. 결함 데이터, 실패 사이의 시간 또는 시간 당 실패 수와 같은 입력 값으 로 확률밀도 등의 통계 함수를 이용하여 신뢰성 측정 치 뿐 아니라 남아있는 결함 수, 실패 밀도 등 다양한 측정치를 결과 값으로 산출한다.
구 분 설계 반영사항
실패 Failure
- 요구되는 기능을 수행하는 어떤 요소의 기능 종료 혹은 미리 지정된 제한 시간 내에서의 수행 불능
결함 Fault
- Failure를 발생시키는 원인으로 소프트웨어에 서 발생하는 모든 문제
- 소프트웨어 개발 과정(SDLC)에서 결함이 삽 입된 단계와 제거된 단계의 동일 여부에 따 라 결함 용어를 에러와 결점으로 분리 에러
Error
- 문제(fault/failure)가 발견된 해당 개발단계에 서 문제의 원인이 삽입된 경우의 결함 예) 설계단계에서 문제의 원인이 삽입되고 설
계 단계에서 문제를 제거했을 경우의 결함
결점 Defect
- 문제가 발견된 이전 단계에서 문제의 원인이 삽입된 경우의 결함
예) 설계단계에서 문제의 원인이 삽입되었으 나, 설계단계에서 발견하지 못하고 설계 이후 구현이나 테스트 단계에서 발견되고 제거된 경우의 결함
- 결점(Defect)이 개발 프로세스 상에서 오래 남아 있을수록 이를 해결하기 위한 비용이 증가된다.
Table. 1. Definition of terms
신뢰성 모델은 소프트웨어 개발 초기 단계에서 소프 트웨어 제품 및 프로세스 특성, 개발 환경과 관련된 요소들을 기반으로 평가하는 소프트웨어 신뢰도 예측 모델(SRPM: Software Reliability Prediction Model)과 소프트웨어 테스팅과 운영 과정에서 수집되 는 결함 데이터를 이용하는 통계적 모델인 소프트웨어 신뢰도 추정 모델(SREM: Software Reliability Estimation Model)로 분류할 수 있다.
먼저, 신뢰도 분석에 앞서 신뢰도 관련 용어 및 결 함 관련 용어를 정의할 필요가 있다. 체계개발 과정에
서 발생하는 실패, 결함, 에러, 결점과 같은 결함관련 용어는 Table 1과 같이 정의한다.
데이터의 정량화에는 두 가지(측정과 계산) 종류가 있다. 이 두 가지는 종종 혼동하여 사용되는데, 본 연 구에서는 이를 명확히 정의하여 용어 사용에 문제가 없도록 한다. 측도는 제품이나 프로세스를 정량화한 값으로 측정에 의한 직접적인 값이고, 척도는 계산에 의한 간접적인 정량화 값으로 그 차이점이 있다. 측정, 측도, 척도는 학자나 문헌에 따라 약간씩 다르게 정의 하고 있는 것이 현실이다. 하지만 다른 정의로 인해 야기되는 혼돈을 피하기 위해 조직 내에서 일관성 있 게 척도와 측도의 의미를 정의하여 사용하여야 한다.
소프트웨어에서의 측도와 척도는 소프트웨어 프로젝 트, 프로세스, 그리고 제품의 상태나 품질을 평가하고 예측하기 위해 활용된다. 소프트웨어 엔지니어는 측도 를 수집하고 지표(Indicator)를 얻을 수 있는 척도를 개발한다. 지표는 소프트웨어 프로세스, 소프트웨어 프로젝트, 또는 소프트웨어 제품 자체를 평가할 수 있 는 척도나 그들의 조합을 말한다.
본 연구에서는 OO 무기체계 사업에 적용하기 위한 소프트웨어 개발 단계의 신뢰도 분석 척도를 정의하였 다. 소프트웨어 신뢰도에 영향을 미칠 수 있는 척도를 식별하고, 정의된 척도들을 바탕으로 소프트웨어 개발 단계별로 어떠한 척도를 적용할 것인지 분석하였다.
OO 무기체계 사업의 개발단계 데이터를 활용한 소프 트웨어 신뢰도 분석을 위해 총 9개의 신뢰성 척도를 마련하였으며, 해당 척도들의 정의와 응용 방안을 다 음과 같이 정리하였다.
2.1 Inspection Fault Density
Inspection Fault Density는 Inspection을 통 해 검출된 결함 수 기반 결함의 양을 정량화한 척도 이다. 이 척도는 미리 정의된 목표 값과의 비교를 통 해 검사 프로세스의 강화 여부를 결정하는데 적용된 다. 해당 척도를 구해 내기 위한 개발단계 데이터는 다음과 같다.
결합의결함의 severity를 나타내는 index (i =1, ... , I) (Minor : 1, Major : 2)
각 단계에서 Inspection을 통해 검출된 전 체 결함의 수
결함의 severity 수준을 고려한 각 severity별 결함의 전체 수
결함의 severity 수준을 고려한 각 severity별 결함의 가중치 (Minor : 0.6, Major : 1.4)
요구사항단계의 SRS명세서의 전체 page수
이를 통해 Inspection Fault Density를 구해낸다.
2.2 Requirement Change Rate
Requirement Change Rate는 요구사항의 변경률 측정하는 척도이다. 요구사항의 변경이 어느 단계에서 많이 발생하는지 요구사항 변경 추이 분석하여 소프트 웨어 신뢰성 평가에 활용한다. 해당 척도를 구해 내기 위한 개발단계 데이터는 다음과 같다.
변경(수정, 삭제, 추가)된 요구사항 수
Baseline 요구사항 수
이를 통해 Requirement Change Rate를 다음과 같이 계산한다.
×
2.3 Fault Distribution
Fault Distribution은 소프트웨어 개발 단계별로 결함의 수와 심각도별 분포에 대하여 분석한다. 즉, 결함의 수 및 심각도별 분포를 분석하여 프로젝트 관 리 차원에서의 결함 방지 방향을 제시한다.
오류명세서 변경(수정, 삭제, 추가)된 요구사 분포(Plot) 항 수각 유형에 따른 분포 작성
2.4 Residual Fault Count
Residual Fault Count는 남아있는 결함 수를 측 정하기 위해 결함수를 기반으로 모델링한다. 다시 말 해, 소프트웨어 무결성(integrity)을 나타내는 지표 이다.
각 severity 수준별로 i번째 실패와 i-1번 째 실패사이의 시간을 측정
각 severity 수준별로 i번째 시간 간격에서 의 실패의 수를 측정
2.5 Failure rate
Failure rate는 소프트웨어 신뢰도와 관계된 실 패율을 측정한다. 비모수 모델의 경우 Nelson 모델 에 의해 추정할 수 있다. 모수 모델은 NHPP(Non -Homogeneous Poisson Process)의 경우 평균함수 를 통해 측정하고, 평균함수의 형태를 고장분포의 하 나로 가정한다면 고장분포의 Hazard rate함수를 통 해 측정한다.
2.6 Phase Containment Effectiveness
Phase Containment Effectiveness는 결함 삽입 단계에서 결함을 발견하는 비율을 측정한다. 특정 단 계에서 발생한 결함(Fault)을 결함 삽입 단계에서 얼 마나 잘 검출하는지 분석하여 각 단계에서 결함 억제 효과를 판단하는 것이다.
i단계에서의 에러(error) 수
에러: 삽입된 단계의 review 동안 발견된 문제
i단계에 대한 총 결점(defect) 수
결점: 삽입된 단계의 review 이후에 발견된 문제
이를 통해 i 단계에서의 Phase Containment Effectiveness를 다음과 같이 구해 낸다.
2.7 Remaining failures
전체 테스트 시간 tt 에서 남아있는 실패의 수를 측 정하기 위한 척도이다. 이를 위해 필요한 개발단계 데 이터는 다음과 같다.
i번째 time interval 에서의 실패 수, 범위 는 [1, ]
시작 시간 s에서의 failure rate β 실패율로부터 유도된 파생 변수
실패 데이터를 이용하기 위한 start 시간
릴리즈를 위한 전체 테스트 시간
시점에서의 Remaining failures는 다음과 같이 구할 수 있다.
exp
2.8 Total test time to achieve specified remaining failures
Total test time to achieve specified remaining failures는 tt시점에서 남아있는 실패를 모두 제거하기 위해 추가되어야 할 테스트 시간을 예 측하는 척도이다. Remaining failures에서 구한 tt시 점에 남아있는 실패의 수 r(tt)를 활용한다.
2.9 Inspection Intensity
Inspection Intensity는 검사한 규모 대비 검사하 는데 걸린 시간의 비율을 측정하는 척도이다. 다시 말 해, 측정값과 목표값을 비교하여 검사의 강도를 분석 한다.
Inspection 검사를 수행한 전체 staff의 시간 Hours
검사대상의 규모
Inspection - 요구사항 단계 규모 (Page수) Object size - 설계 단계 규모 (Page수)
- 구현 단계 규모 (KSLOC) 이를 기반으로 Inspection Fault Density를 구해 낸다.
2.10 신뢰도 분석 프로그램과의 모델 비교
국내 산업계에 적용중인 소프트웨어 신뢰도 분석 프 로그램과 본 연구에서 제시한 9개의 신뢰도 모델 및 척도를 비교하고자 한다. 소프트웨어 신뢰도 분석 프 로그램은 정적 시험 도구와 동적 시험 도구로 나눌 수 있다. 정적 시험 도구는 코드를 실행하지 않고 신뢰성 지침 준수 여부에 대한 분석 결과를 제공한다. 즉 신 뢰성 지침에서 요구하는 코딩규칙준수 여부 혹은 실행 시간 오류에 대한 검증을 주로 수행한다. 대표적인 프 로그램에는 QAC/C++, CodeSonar, VectorCast, LDRA 등이 있다. 동적 시험 도구는 코드를 실행함으 로써 신뢰성 지침 준수 여부에 대한 분석 결과를 제공 하여 코드 실행률을 높인다. 주요 프로그램은 Cantata, VectorCast, LDRA 등이 있다.
그러나 위와 같은 상용프로그램을 이용한 단순 정적 /동적 시험은 소프트웨어의 구현이 끝나고 난 이후에 야 코드 분석을 통한 수행이 가능하다. 즉, 시스템 개 발 단계 중 분석 및 설계 단계에서는 신뢰도 분석 및 예측이 불가능 하다는 단점이 있다. 따라서 본 연구에 서는 시스템 통합 이전의 각 개발 단계에서 소프트웨 어의 신뢰성을 확보할 수 있는 모델을 개발하였다.
3. 개발단계 데이터를 활용한 신뢰도 모델 분석 지금까지 무기체계 소프트웨어의 신뢰도 분석을 위 한 9개의 신뢰도 모델 및 척도를 확인하였다. 다음은 OO 무기체계 사업의 개발 단계에서 수집한 실제 데이 터를 활용하여 해당 척도들을 산출하고, 소프트웨어의 품질을 분석한 결과를 제시한다.
3.1 Inspection Fault Density 분석 결과
Inspection Fault Density는 요구사항 단계의 검 사(Inspection) 수행을 통해 개발 문서의 크기 대비 결함 수의 비율을 정량화하는 척도이다. 이를 통해 여 러 기능에 대한 버전별 척도 값을 비교하여 검사 프로 세스의 강화 여부를 결정지을 수 있다. 척도 값이 너 무 크거나 작은 경우 검사 프로세스의 취약, 혹은 제 품 자체의 결함이 다량 포함되어있는 등 문제 상황이 있을 수 있으므로 다음 검사 프로세스를 강화시키거나 이상 척도 값의 원인을 파악함으로서 목표 값에 도달 할 수 있도록 한다. OO 무기체계 개발 사업에서는 소 프트웨어의 요구사항을 명세한 문서인 SRS(Software Requirement Specification)가 존재한다. 해당 산출 물은 개발이 진행됨에 따라 업데이트 되는 내용을 반 영하여 버전관리를 하였으며, v1a ~ v1.5 까지 총 8 개의 SRS 버전을 대상으로 분석하였다. OO 무기체계 사업의 총 XX개의 소프트웨어 CSCI (Computer Software Configuration Item)에 대하여 분석을 수 행하였다.
Figure 1. Inspection Fault Density of SRS Figure 1은 총 8개 버전 SRS 문서별 평균 Inspection Fault Density를 나타낸다. 본 프로젝트 초기 단계부터 시험 단계까지 프로젝트가 진행되는 과 정에서 SRS v1.1, v1.3 문서의 Inspection 결함 밀 도가 높게 측정되었다. SRS v1.1 문서는 설계 단계 가 시작되면서 결함 밀도가 폭등하는 현상을 보였고, SRS v1.3 문서는 구현 단계가 시작되면서 이전과 유 사한 현상을 반영하고 있음을 분석하였다. SRS v1.4, v1.5 문서에서는 평균 결함 밀도가 매우 낮게 측정되 었으며 확인 결과 실제 요구사항 문서의 결함의 수가 감소하였는데, 이는 무기체계 소프트웨어의 지속적인 보완 및 업데이트로 안정화가 된 것으로 분석하였다.
Figure 2. Inspection Fault Density of SW CSCI Figure 2는 OO 무기체계 소프트웨어 CSCI 에 대 하여 Inspection Fault Density를 분석한 결과이다.
SRS v1.4 기준으로 19번 XX 기능, 37번 AA지원, 41번 BB지원 CSCI가 내부 기준치(개발 목표치) 보 다 높은 결함 밀도를 나타냈다. 이와 같은 분석에 대 한 원인을 분석해 보면, 먼저 19번 XX의 기능의 경 우, 일부 무장 할당에 대한 운영 개념이 개발 중간에 변경됨에 따라 관련 요구사항 변경과 기능 수정이 다 수 발생하였다. 그리고 OO 무기체계의 개발 도중, 체 계 개발 범위가 증가하여 사업 일정에 대한 전반적인 조정이 크게 이루어졌는데, 37번 AA지원과 41번 BB 지원 CSCI 는 당시 이 증가된 개발 범위에 가장 크게 영향을 받는 2가지 SW CSCI였다. 따라서 결함 밀도 가 높게 분석되었음을 알 수 있다.
3.2 Requirement Change Rate 분석 결과
Requirement Change Rate는 Baseline을 기준 으로 요구사항의 변경 정도를 파악하기 위한 것으로 해당 개발 단계에서의 요구사항 변경 추이를 정량화한 척도이다. 이를 이용하여 각 단계별로 어느 단계에서
혹은 어느 기능에서 요구사항의 변경이 많이 발생하는 지에 대한 요구사항 변경 추이를 분석할 수 있다.
Figure 3. Inspection Fault Density of SRS Figure 3은 총 8개 버전의 SRS 문서별 평균 Requirement Change Rate을 나타낸다. OO 무기 체계 개발 초기 단계부터 시험 단계까지 프로젝트가 진행되는 과정에서 v1a, v1.1, v1.3 문서의 요구사항 변경률이 높게 측정되었다. 원인을 분석해 보면, SRS v1a 문서는 요구사항 초기 문서로 높은 요구사항 변 경률을 보였고, v1.1 문서는 소프트웨어 설계 단계가 시작되면서 요구사항 구체화 및 개발 기능 변경 등으 로 인해 가장 높은 요구사항 변경률을 나타냈다. v1.3 문서는 본격적인 소프트웨어 구현 단계가 시작되면서 높은 요구사항 변경률을 보였다. Inspection Fault Density와 유사하게 SRS v1.4 문서 이후로는 변경 률이 감소하여 요구사항 문서의 안정화가 진행된 것으 로 분석하였다.
3.3 Fault Distribution 분석 결과
Fault Distribution은 소프트웨어 개발 라이프 사 이클에서 수집되는 결함 정보의 분포를 확인하는 척도 이다. 분포의 다양한 분석을 통해 프로젝트 관리 차원 에서 결함 방지에 대한 방향을 안내 할 수 있다.
결함 유형 설계 반영사항
표준 미준수 (STD : Incompliance)
요구사항, 설계, 코드가 조직의 표준 또는 양식을 따라서 기술되지 않은 경우
불명확 (UCR : Unclear)
요구사항 및 설계 등이 한가지 이상 으로 해석되거나 의미가 명확하지 않은 경우
불일치 (ICT : Inconsistence)
요구사항, 설계, 코드 관련 문서와 일치해서 기술되어 있지 않거나 중 복되어 기술된 경우
불완전 (ICP : Incompleteness)
누락된 요구사항이 있는 경우, 예를 들어 소프트웨어 요구사항, 보완 요 구사항, 안전 요구사항, 성능 요구사 항, 인터페이스 요구사항 등이 기술 되어 있지 않은 경우
인터페이스 (ITF : Interface)
내부, 외부, 사용자 인터페이스가 잘 못 정의되거나 부정확 또는 불완전 하게 연결되어 있는 경우
Table. 2. Definition of Faults
OO 무기체계 개발 사업에서는 소프트웨어 개발 산 출물에 대한 결함을 2가지 심각도 형태로 구분 짓고 각각에 대한 정의를 마련하였다. 결함 심각도는 Major와 Minor 두 레벨로 나뉜다. Major 결함은 수 정되지 않으면 예상치 못한 결과나 오작동을 초래할 수 있는 작업 산출물 내의 중대한 오류나 누락이다.
예를 들어, 요구사항과 관련되어 잘못된 결과를 내게 하는 원인, 누락되거나 불분명하여 추가되어야 하는 정보, 사용자 요구를 만족하지 못하는 규격상의 문제 등이 해당된다. Minor 결함은 Major 결함으로 분류 되지 않는 나머지 결함들이다. 그리고 총 5가지의 결 함유형을 Table 2와 같이 구분하였다.
위와 같은 기준을 바탕으로 OO 무기체계의 총 XX 개의 소프트웨어 CSCI에 대하여 결함 분포를 분석하 였다.
STD UCR ICT ICP ITF Total SRS v1.3 1 12 166 757 63 999 SRS v1.4 0 2 148 115 36 301 SRS v1.5 2 2 41 97 7 149
Table. 3. Number of Faults by type
Figure 4. Number of Faults by SW CSCI 버전별 결함 수는 SRS v1.3 문서에서 999개, SRS v1.4 문서 301개, SRS v1.5 문서 149개로 분 석하였다. 문서별 결함 수는 지속적으로 감소하고 있 으며, Minor:Major 결함의 비율은 SRS v1.3 문서 73% : 27%, v1.4 문서 88% : 12%, v1.5 문서 89% : 11%로 확인되어 Major 결함의 비율이 감소 하고 있는 것으로 확인되었다. 이는 결함의 관리가 잘 진행되고 있는 것으로 판단되었다.
소프트웨어 CSCI 별 결함 수는 20번 XX화면 기능 과 37번 AA지원 기능에서 많았고, Major 결함 비율 또한 다른 기능에 비해 높은 것으로 확인되었다. 20번 XX화면 기능은, OO 무기체계에서 소프트웨어 그래픽 인터페이스를 담당하는 주 기능으로, 많은 기능들이 XX화면을 통해 실행된다. 따라서 상대적으로 소프트 웨어의 크기가 크고, 많은 기능과 연관됨에 따라 결함 분포가 높게 나타났다. 37번 AA지원 기능은 3.1절에 서 분석한 내용과 같다.
3.4 Phase Containment Effectiveness 분석 결과 PCE척도는 각 단계에서 결함 삽입 억제에 대한 효
과성을 측정하기 위한 척도이다. 결함은 삽입이후 나 중에 발견될수록 수정하는 시간과 비용이 많이 소요되 므로, 결함의 삽입을 미연에 방지하는 것도 중요하지 만 결함이 삽입되었다면 되도록 빠른 시간 내에 발견 해서 결함을 제거하는 것이 시간과 비용을 줄일 수 있 는 중요하다. PCE 척도는 특정 단계에서 발견된 결함 이 발견된 해당 단계에서 삽입되었는지 이전 단계에서 삽입되었는지 분석을 통해 각 단계별 결함 검출 및 제 거 효과를 판단할 수 있으며 개발 단계가 진행되면서 전체적인 프로젝트 관점에서 개발 초기 결함 검출 효 과나 검사 프로세스의 효율성을 확인할 수 있다.
단계 설계 반영사항
RQA 기능(S/W, H/W) 요구분석 단계 (SRS, HRS, 개발 계획서, etc)
PDS 예비/상세 설계단계(SDD) IMP 구현/제작
CIT CI 시험 ex) QT(Qualification Test) CSCI 시험, CSCI 통합시험 SIT 시스템 통합시험, ex) FAT, LBIT
Table. 4. Definition of phase
결함 제거
단계 RQA PDS IMP CIT SIT 해당 단계 1198 1390 156 26 13 이후 단계 2463 2 176 0 0
PCE 0.327 0.999 0.469 1.000 1.000 Table. 5. PCE by phase
Table 5는 본 프로젝트의 산출물인 SRS, SDD 문 서와 시험 단계 (UT, QT, FAT, DT)에서 수집된 결 함 데이터를 기반으로 얻어낸 결함 억제 효과성을 나 타낸다. 결함 데이터 수집 템플릿을 통해 결함 삽입 단계와 제거 단계를 파악하여 각 단계에서 삽입하고 제거한 결함의 수와, 이후 단계에서 제거된 결함의 수 를 계산하였다. PDS 단계는 설계 문서를 기반으로 수 집되었으며, CIT, SIT 이후 단계에는 발견한 결함이 없는 것으로 확인되었다.
PCE 값이 낮다는 것은 많은 결함이 해당 단계에서 제거되지 못한다는 것을 의미한다. 이는 이후 결함 제 거 과정에서 더 큰 비용을 소모하게 하는 원인이 될 수 있다. 따라서 낮은 PCE 값을 갖는 소프트웨어 기 능에 대하여 보다 적극적인 결함 관리가 필요하다.
3.5 Inspection Intensity 분석 결과
Inspection Intensity는 검사를 수행하는 규모와 노 력을 측정하여 정량화하는 척도이다. 이는 Inspection 강도를 측정할 뿐만 아니라 Inspection Fault Density 와 함께 활용하여 현재 단계 이후의 개발 과정에 대한
권고사항을 도출하는 과정에도 이용이 가능하다.
Figure 5. Inspection Intensity by SRS
Figure 5는 문서 8개에 대한 평균 Inspection Intensity를 나타낸다. SRS v1.3 문서 이후 평균 Inspection Intensity는 0.03 이하를 나타내고 있으 며, 이는 1 page 당 0.03시간, 즉 1분 50초 동안 Inspection을 수행한다는 것을 의미한다.
Figure 6. Inspection Intensity by SW CSCI Figure 6의 결과 분석에서 알 수 있듯이, SRS v1.4에서 1번 XX관리 기능과 41번 BB지원 기능 의 Inspection Intensity가 평균 대비 표준편차 2배를 기준값으로 설정했을 때 기준값을 초과하여, 매우 큰 값을 갖는 것으로 나타났다. 1번 XX관리 기능의 경우 1520분 동안 107page의 요구사항 문서를 검토하였 고, 41번 BB지원의 경우 180분 동안 59page의 요 구사항 문서를 검토하였다. SRS v1.5 문서는 44번 YY정보 처리 및 관리 기능에서 240분 동안 50page 의 문서를 검토하였다. 이를 제외한 기능의 평균 Inspection Intensity는 SRS v1.4 문서에서 0.011 로 약 40초 당 1page의 문서를 검토한 것으로 계산 되었다. Requirement Change Rate에서 1번과 41 번 기능은 높은 요구사항 변경률을 보였던 기능들로, 요구사항의 변경이 많이 일어난 기능에 대해 집중적으 로 Inspection을 수행한 것으로 판단된다.
SRS 문서 단계가 진행되는 과정에서 Inspection Intensity가 감소한다는 것은 Inspection을 수행하는 연구원의 요구사항 문서에 대한 숙련도가 증가하여 시 간이 단축된 경우이거나, 요구사항 문서에 대한 Inspection이 충분히 수행되지 않은 경우일 수 있다.
Inspection Intensity가 높지 않음에도 높은 결함 밀 도가 측정되었던 19번과 같은 기능은 내재된 결함이
추가적으로 존재할 수 있기 때문에 강도 높은 Inspection을 수행하여 결함 제거 활동을 수행하는 노력이 필요하다고 분석되었다.
3.6 소프트웨어 신뢰도 추정 모델 분석 결과 남아있는 4개의 신뢰도 척도인 Residual Fault Count, Failure rate, Remaining failures, Total test time to achieve specified remaining failures 는 개발단계의 데이터뿐만 아니라 추가적인 신뢰성 추정이 필요한 척도이다. 따라서 수집된 개발 단계 데이터 중 시험 데이터를 통해 OO 무기체계의 신뢰성을 먼저 추정한 후, 4개 척도들의 값을 산출해 낸다. 신뢰성 추정 모델은 소프트웨어 통합 이후에 적 용할 수 있으므로 FAT 단계 이후에 수집된 결함 데이 터를 활용하여 신뢰성 추정 모델을 수립하였다.
수집된 결함 데이터는 결함 발생 날짜와 결함이 발 생하기까지의 테스트 수행시간이 분단위로 수집되어 있으므로 단위시간을 일 단위로 하는 Failure count 모델과 각 테스트 케이스의 실행 시간을 분 단위로 하 는 Time between failure 모델을 수립할 수 있다.
그러나 테스트 데이터의 분석 결과 Time between failure 데이터에서 동일 날짜에 수행된 테스트 케이 스는 수행된 선 후 관계를 알 수 없고 동일 절차서의 테스트 케이스에 대한 선후 관계 또한 파악하기 어렵 기 때문에 실제 결함 발생 간 시간을 대변한다고 보기 어려워 Failure count 모델로 분석을 수행하였다.
신뢰성 추정 모델 적용 과정은 IEEE 1633 표준 [2] 의 신뢰성 모델 적용 프로세스를 참고 하였으며 Goel, A, L의 연구[7] 에서 제시한 신뢰성 모델 적 용 프로세스 또한 참고 하였다.
Figure 7. Software Reliability Estimation Process Figure 7은 본 연구에서 진행한 신뢰성 추정모델 적용 과정을 나타낸 것이다. 먼저, 결함 데이터는 이미 OO 무기체계 개발단계에서 수집된 상황이므로 모델 선정, 모델 파라미터 추정, 모델의 goodness-of-fit 확인, 모델 파생 값 계산 순으로 프로세스는 진행된다.
추정 모델은 OO 무기체계 선행연구에서 개발하였던 ADDre 도구를 활용하여 진행하였다.
Goodness-of-fit은 추정된 파라미터를 통해 수립된 모델이 실제 데이터와 통계적으로 유사한지 확인하는 것으로 Kolmogorov-Smirnov test (KStest)를 수 행하였다. KStest 결과 통계적 유의성이 있다고 판단 되면 해당 모델이 갖는 가정을 실제 데이터가 유사하 게 따른다고 설명할 수 있다. 통계적 유의 수준은 90%로 설정하였으며 이는 p-value가 0.1 이하일 때 추정 모델과 실제 데이터가 서로 다른 특성을 보인다 고 할 수 있으며 0.1을 초과하면 유사한 특성을 보인 다고 설명할 수 있다. KStest는 실제 수집된 각 단위 시간의 누적 결함의 수와 모델을 통하여 얻어진 각 단
위시간의 누적 결함의 수, 두 데이터에 대한 유사성을 확인하기 위해 수행되었으며 오픈소스 통계 도구인 R 을 사용하여 수행하였다.
먼저, Failure Count 데이터에 대한 신뢰성 추정 모델로 Schneidewind 모델 3종(SM1, 2, 3), 그리 고 Yamada S-Shaped(YS) 모델을 사용하였다. 이 중 SM2와 SM3은 SM1 모델을 변형한 형태로 모델 구성을 위한 가정은 모두 동일하다. 따라서 SM2, SM3 모델 중 가장 높은 적합도(MSE)를 가지는 모 델 하나를 선정하고 이들과는 다른 형태를 보이는 YS 모델을 적용하여 서로 다른 형태의 추정 모델에 대한 분석을 수행한다. SM2, 3 모델은 파라미터 추정 과 정에서 테스트 초기의 데이터를 제외하는 방식으로 추 가 파라미터 s를 필요로 하며, 이는 단위시간 1부터 s 까지의 결함 데이터를 파라미터 추정과정에서 제외하 는 것을 의미한다. SM2 모델은 1부터 s까지의 결함 데이터를 파라미터 추정에서 완전히 제외하는 형태의 모델이며 SM3 모델은 1부터 s까지의 결함을 합하여 하나의 누적 결함 점으로 간주하고 모델의 파라미터를 추정한다. 파라미터 s는 MSE 값을 가장 작게 만드는 s를 찾는 방법으로 설정하였다. 모델의 적합도 MSE 는 Mean Square Error를 의미하며 예측된 값과 실 제 값의 차이를 의미한다. 따라서 MSE가 낮을수록 실제 측정된 값과 모델이 예측한 값의 차이가 작다고 볼 수 있으므로 MSE가 낮은 모델을 더 정확한 모델 로 간주할 수 있다. 그러나 MSE 값의 적정 수준에 대한 절대적 기준이 없으므로 KStest를 통하여 모델 의 통계적 유의성 또한 확인한다.
FAT(Factory Acceptance Test) 단계와 DT (Development Test) 단계의 단위시간 당 결함 수를 모두 수집 하였다. 총 테스트 기간은 FAT와 DT 단계 에서 135일이며 총 발견된 결함의 수는 108개이다.
FAT 단계는 96일 동안 진행되어 107개의 결함이 발 견되었으며 DT 단계는 39일 동안 진행되어 1개의 결 함이 발견되었다.
Figure 8. Cumulative Failures and Estimated model at the FAT phase
Figure 8은 FAT 단계에서 발생한 전체 결함에 대 한 추정모델이다. 분석 결과, 인자 s를 3으로 하는
SM3 모델이 15.5360의 가장 낮은 MSE 값을 보이 는 것으로 나타났다. YS 모델은 24.2734의 MSE 값 을 보였다. 모델의 goodness-of-fit을 확인하기 위하 여 실제 데이터와 예측값 사이의 KStest를 수행하여 통계적 유의성을 검증하였다. SM3 모델에 대한 KStest 결과 p-value는 0.8928로 두 집단이 통계적으로 다 르지 않다는 결론을 내었으며, 즉 예측 모델이 통계적 으로 유의하다고 할 수 있다. YS 모델 또한 0.7928 의 p-value를 보였으므로 통계적으로 유의하다고 할 수 있다.
이제 추정된 신뢰도 모델을 바탕으로 4가지 척도에 대해 분석을 진행한다. Residual Fault Count 척도 를 통해서 Remaining failures를 구해내게 되므로, 본 연구에서는 두 개의 척도로 예측 잔여 결함 수를 구해낸다. Total test time to achieve specified remaining failures 척도에 대해서는 목표로 하는 잔 여 결함수를 따로 정의하지 않았기 때문에 99.99%의 결함이 제거되는 시점을 기준으로 삼아, 전체 예측된 결함 수 중 99.99%의 결함이 제거되는 시점을 계산 하였다. Failure rate 척도는 모델별로 다르게 계산 될 수 있다. 따라서 본 연구에서는 각각의 모델에서 정의하는 방식으로 데이터 수집 종료 시점의 예측 Failure Intensity로 계산하였다.
결함 유형 SM3(s=3) YS MSE 15.5360 24.2734 예측 잔여
결함 수(개) 50.0607 8.8690 99.9%의 결함제거
도달 시점(일) 771 268
예측 Failure Intensity
(Failure/일) 0.5911 0.3050 Table. 6. Reliability Analysis Result (FAT)
Table 6은 각 척도에 대한 분석 결과이다. FAT가 종료된 시점의 예측 잔여 결함 수는 SM3에서 50.0607개 YS에서 8.8690개로 나타났다. 테스트를 지속했을 때 99.99%의 결함이 제거되는 시점은 SM3 에서 771일, YS에서 268일로 나타났다. FAT 종료 시점의 예측 Failure Intensity는 SM3 모델에서 하 루 0.5911개의 결함률로 나타났으며 YS 모델에서는 하루 0.3050개의 결함률이 예측되었다.
다음은 DT 종료시점, 즉 FAT 단계와 DT 단계에 서 발생한 전체 결함에 대하여 분석을 수행하였다. 동 일한 방법으로 결함에 대한 추정모델 분석 결과 YS 모델은 17.4766의 MSE 값을 보였다. 인자 s를 19 로 하는 SM3 모델이 30.2187의 MSE 값을 보이는 것으로 나타났다. 그러나 YS 모델은 KStest 결과 p-value 0.0090으로 예측 모델이 통계적으로 유의미 하지 않은 것으로 나타났으며 SM3 모델은 0.1033으 로 통계적으로 유의미한 것으로 나타났다. 즉, FAT와 DT 단계 전체 결함은 SM3 모델의 경향과 유사한 경 향을 보인다고 분석할 수 있다.
Figure 9. Cumulative Failures and Estimated model at the DT phase
결함 유형 SM3(s=19) YS MSE 30.2187 17.4766 예측 잔여
결함 수(개) 8.2128 1.1389 99.9%의 결함제거
도달 시점(일) 465 241
예측 Failure Intensity
(Failure/일) 0.1597 0.0463 Table. 7. Reliability Analysis Result (DT)
SM3 모델에서는 DT 종료 시점의 예측 잔여 결 함 수를 8.2128개로 예측하였으며 YS 모델에서는 1.1389개 로 예측하였다. 99.99%의 결함이 제거되 는 시점은 SM3 모델에서 465일, YS모델에서 241일 로 분석되었다. DT 종료 시점의 결함률은 SM3 모델 에서 하루 0.1597개의 결함 발생률로 예측되었으며 YS 모델에서는 하루 0.0463개의 결함 발생률이 예측 되었다.이와 같이, 정량화된 4가지 척도를 사용하여 OO 무기체계 개발 사업에서 소프트웨어의 예측 잔여 결함 수, 목표 결함제거까지 걸리는 기간, 예측 결함 밀도 등을 분석하였다. 이는 강도 높은 신뢰도가 요구되는 무기체계 소프트웨어 개발의 중요한 지표로써, 남은 개발 기간 동안 소프트웨어의 신뢰도를 분석하고 높여 나가는 데에 그 기반을 마련하였다.
4. 결론
많은 소프트웨어 및 시스템 개발 조직에서 고 신뢰 도의 소프트웨어를 개발하기 위해 노력하고 있으나, 개발 중인 소프트웨어의 신뢰도를 평가하기는 쉽지 않 다. 개발 중인 소프트웨어에서 측정되는 데이터는 주 로 소프트웨어 결함 수이다. 그러나 신뢰성을 보증하 기 위해서 단지 결함 수만 필요한 것은 아니다. 신뢰
도는 소프트웨어 개발 초기 단계에서 소프트웨어 제품 및 프로세스 특성, 개발 환경과 관련된 요소들을 기반 으로 분석될 수도 있고, 소프트웨어 시험과 운영 과정 에서 수집되는 결함 데이터를 이용하여 통계적 추정 모델로 분석될 수도 있다.
본 연구에서는 실제 개발단계의 데이터를 활용하여 무기체계 소프트웨어의 신뢰도를 분석하는 방안을 제 시하였다. 이를 위해 먼저 소프트웨어 척도에 대한 개 념을 기술하고, 신뢰도 분석에서 중요한 용어인 실패, 결함, 결점, 에러 등의 용어를 명확히 구분 하여 개발 단계에 반영하였다. 이를 바탕으로 소프트웨어 신뢰도 평가를 위해 수집되고 분석해야 하는 정량적 데이터인 소프트웨어 신뢰도 척도를 분석 하였다.
특히 OO 무기체계 개발 사업에서 실제 적용된 결 과를 확인함으로써 분석 모델에 대한 실용성을 확인하 였다. 국방 도메인에서의 무기체계 소프트웨어는 보다 높은 신뢰도를 필요로 한다. 따라서 본 연구에서 제시 한 무기체계 개발과정에서의 체계적이고 정량적인 소 프트웨어의 신뢰도 분석 방안은 타 무기체계 및 소프 트웨어 개발 업무에 좋은 분석 사례가 될 것으로 기대 된다.
참고문헌
01. Ryu In-Su, Park Myung-Hun, Communications of the Korean Institute of Information Scientists and Engineers, Vol. 35, No. 12, pp. 53-60, 2017.
02. IEEE, “IEEE Std 1633 Recommended Practice on Software Reliability”, IEEE-SA Standards Board, Approved 22 September 2016.
03. Yang Gye-Tak, Journal of the Korea Industrial Information Systems Research, Vol. 14, No. 5, pp.
61-73, 2009.
04. Kim Ki-Baek, Lee Jea-Cheon, The Journal of Korean Institute of Communications and Information Sciences, Vol. 36, No. 4, pp. 332-345, 2011.
05. Jang Jin-WooK, Journal of the Korea Academia-Industrial cooperation Society, Vol. 16, No.
1, pp. 691-696, 2015.
06. Park Jung-In, Choi Jin-Tak, The Society of Convergence Knowledge, Vol. 1, No. 1, pp. 91-98, 2013.
07. Goel, Amrit L, IEEE Transactions on software engineering, Vol. 12, pp. 1411-1423, 1985.
08. Ki-Chang Kim, Yong-Hwan Kim, Journal of KISS : Software and Applications, Vol. 38, No. 8, pp.
405-418, 2011.
09. Gye-Tak Yang, Journal of the Korea industrial information systems society, Vol. 14, No. 5, pp.
61-73, 2009.
10. Kwang-Sun Ryu, Journal of the Korea society of computer and information, Vol. 17, No. 12, pp.
187-198, 2012.
