보고서 전문검색

Page1
중견연구자지원사업(핵심연구) 최종보고서양식A101① 부처사업명(대) 기초연구사업 보안등급(보안, 일반) 일반② 사 업 명(중) 중견연구자지원사업 공개가능여부(공개, 비공개) 공개③ 세부사업명(소) 핵심연구(개인)④ 과제성격(기초, 응용, 개발) 기초 ④-1 실용화 대상여부(실용화, 비실용화) 실용화국 문 고객 신뢰성 목표 기반 내장형 소프트웨어 신뢰성 측정 및 개선 방안⑤ 과 제 명 Embedded Software Reliability Measurements and Improvements 영 문 based on Customer Reliability Goal⑥ 주관연구기관 한국과학기술원 (KAIST) ⑦ 협동연구기관 성 명 백 종 문 직급(직위)⑧ 주관연구책임자 소속부서 전산학과 전 공 ⑨ 연구개발비 및 참여연구원수 (단위: 천원, M․Y) 기업체부담금 정부외 상대국년 도 정부출연금 합계 참여 (A) 현금 현물 소계 출연금 부담금(B) (F) G=(A+B+E) 연구원수(C) (D) E=(C+D)1차년도 98000 0 98,000 72차년도 98000 0 98,000 53차년도 98000 0 98,000 74차년도 0 05차년도 0 0합계 294,000 0 0 0 0 0 294,000 19⑩ 총연구기간 2010. 05. 01 - 2013. 04. 30 (36개월)⑪ 다년도협약연구기간 2010. 05. 01 - 2013. 04. 30 (36개월)⑫ 당해연도연구기간 2012. 05. 01 - 2013. 04. 30 (12개월)중소기업수 대기업수 기타 계⑬ 참여기업 0상대국연구기관수 상대국연구개발비 상대국연구책임자수⑭ 국제공동연구 관계규정과 모든 지시사항을 준수하면서 이 연구개발사업을 성실히 수행하였으며 아래와 같이 최종보고서를 제출합니다. 2013 년 3 월 28 일 주관연구책임자 : 백 종 문 (인) 주관연구기관장 : 강 성 모 (직인)교 육 과 학 기 술 부 장 관 귀하 - 1 -

Page1

중견연구자지원사업(핵심연구) 최종보고서양식A101① 부처사업명(대) 기초연구사업 보안등급(보안, 일반) 일반② 사 업 명(중) 중견연구자지원사업 공개가능여부(공개, 비공개) 공개③ 세부사업명(소) 핵심연구(개인)④ 과제성격(기초, 응용, 개발) 기초 ④-1 실용화 대상여부(실용화, 비실용화) 실용화국 문 고객 신뢰성 목표 기반 내장형 소프트웨어 신뢰성 측정 및 개선 방안⑤ 과 제 명 Embedded Software Reliability Measurements and Improvements 영 문 based on Customer Reliability Goal⑥ 주관연구기관 한국과학기술원 (KAIST) ⑦ 협동연구기관 성 명 백 종 문 직급(직위)⑧ 주관연구책임자 소속부서 전산학과 전 공 ⑨ 연구개발비 및 참여연구원수 (단위: 천원, M․Y) 기업체부담금 정부외 상대국년 도 정부출연금 합계 참여 (A) 현금 현물 소계 출연금 부담금(B) (F) G=(A+B+E) 연구원수(C) (D) E=(C+D)1차년도 98000 0 98,000 72차년도 98000 0 98,000 53차년도 98000 0 98,000 74차년도 0 05차년도 0 0합계 294,000 0 0 0 0 0 294,000 19⑩ 총연구기간 2010. 05. 01 - 2013. 04. 30 (36개월)⑪ 다년도협약연구기간 2010. 05. 01 - 2013. 04. 30 (36개월)⑫ 당해연도연구기간 2012. 05. 01 - 2013. 04. 30 (12개월)중소기업수 대기업수 기타 계⑬ 참여기업 0상대국연구기관수 상대국연구개발비 상대국연구책임자수⑭ 국제공동연구 관계규정과 모든 지시사항을 준수하면서 이 연구개발사업을 성실히 수행하였으며 아래와 같이 최종보고서를 제출합니다. 2013 년 3 월 28 일 주관연구책임자 : 백 종 문 (인) 주관연구기관장 : 강 성 모 (직인)교 육 과 학 기 술 부 장 관 귀하 - 1 -

Page3
양식A201고객 신뢰성 요구 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선방안에 관한 연구는 첫째, IT 융합을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 신뢰성 관리 미흡 및 신뢰성 향상을 위한 체계적 소프트웨어 공학 기법의 미적용 문제해결을 연구의 위해 (1)산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정, (2) 내장형 소프트웨어 신목적 및 내용 뢰성 보증을 위한 신뢰성 프로세스 개발, (3) 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용, (4)산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발, (5)내장형 소프트웨어 개발 조직의 성숙도 개선 방안, 그리고 마지막으로 (6) 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구 개발과 같은 목표를 갖는다.본 연구의 주요한 내용으로는 자동차, 국방/항공, 의료 등 산업별 도메인 분석: 전통 산업과 융합된 내장형 소프트웨어가 각 분야별 요구되는 신뢰성 수준에 관해 분석한다. 고객 신뢰성 요구 설정 기법 연구 및 고객 신뢰성 요구 목표 설정: 신뢰성 목표는 대상 소프트웨어에 대한 정량적인 성능레벨로 정의하고, 이를 위한 각종 측도, 척도를 결정하고 산업별 요구되는 신뢰수준을 바탕으로 고객이 요구하는 신뢰성 목표를 설정한다. 신뢰성 프로세스 개발 및 활동 요소 정의, 측도 개발, 척도의 정의: 내장형 소프트웨어의 특징에 따라 신뢰성 프로세스 활동 요소를 정의하고, 이에 필요한 측도/척도를 개발한다. 블랙박스 신뢰성 모델 기반 신뢰성 프로세스 개발: 국제표준에 근거한 신뢰성 프로세스, 즉 기존 블랙박스 신뢰성 모델을 기반으로 하는 신뢰성 프로세스를 개발하고 이것이 실연구결과 제 소프트웨어 개발 프로세스와의 연계방안을 개발한다. 고객 신뢰성 요구 목표 기반 화이트박스 신뢰성 모델 개발: 고객 신뢰성 요구 목표를 만족시키기 위해 내장형 소프트웨어의 구조를 모델링하고, 이를 바탕으로 화이트박스 신뢰성 모델을 개발/적용한다. 내장형 소프트웨어 신뢰성 모델 및 개발 조직 성숙도 개선 가이드라인 개발: 연구 결과가 실제 산업현장에서 활용될 수 있도록, 구체적인 적용 사례연구 및 활용 기술, 그리고 활용 절차들이 포함된 내장형 소프트웨어 신뢰성 모델 및 개발 조직 성숙도 개선 가이드라인을 개발한다.그리고 이러한 연구내용들을 효과적으로 수행할 수 있도록 내장형 소프트웨어 신뢰성 모증을 위한 프로세스 지원 도구를 구현하여 효과를 입증하도록 한다.본 연구의 기대효과로는 첫째, 내장형 소프트웨어를 개발하는 중소기업간 클러스터 구성이 가능하여, 국내 시장에서의 국산 내장형 소프트웨어 보급률 향상 및 해외시장 진출을 모색하는 기반 기술로서의 역할을 기대할 수 있으며, 둘째 내장형 소프트웨어를 개발하는 중소기업의 품질 관리 체계 확립을 위한 기반 기술 확보, 아울러 내장형 소프트웨어 신뢰성 확 연구결과의 보 및 내장형 소프트웨어 기반 공정 관리 시스템의 생산성 향상을 기대할 수 있다. 그리고 활용계획 마지막으로 신뢰성 개선 및 측정방안의 확립, 그리고 내장형 소프트웨어 신뢰성 평가 방안 지침서 작성을 통해 세부 방법론을 확립/적용할 수 있을 것으로 기대된다. 또한 작성된 지침서를 활용한 내장형 소프트웨어 신뢰성 개선 및 측정 시범 적용을 통해 다양한 산업 도메인에 독립적이고 표준화된 산업 인프라로서의 역할을 할 수 있을 것으로 기대한다. 고객 신뢰성 요구 목표 내장형 소프트웨어 내장형 소프트웨어 신뢰성 측정 중심어 신뢰성 평가 프로세스 화이트박스 신뢰성 모델 신뢰성 개선을 위한 가이드라인블랙박스 신뢰성 모델 소프트웨어 개발 조직 성숙도 IT융합 내장형 소프트웨어 - 3 -

Page3

양식A201고객 신뢰성 요구 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선방안에 관한 연구는 첫째, IT 융합을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 신뢰성 관리 미흡 및 신뢰성 향상을 위한 체계적 소프트웨어 공학 기법의 미적용 문제해결을 연구의 위해 (1)산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정, (2) 내장형 소프트웨어 신목적 및 내용 뢰성 보증을 위한 신뢰성 프로세스 개발, (3) 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용, (4)산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발, (5)내장형 소프트웨어 개발 조직의 성숙도 개선 방안, 그리고 마지막으로 (6) 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구 개발과 같은 목표를 갖는다.본 연구의 주요한 내용으로는 자동차, 국방/항공, 의료 등 산업별 도메인 분석: 전통 산업과 융합된 내장형 소프트웨어가 각 분야별 요구되는 신뢰성 수준에 관해 분석한다. 고객 신뢰성 요구 설정 기법 연구 및 고객 신뢰성 요구 목표 설정: 신뢰성 목표는 대상 소프트웨어에 대한 정량적인 성능레벨로 정의하고, 이를 위한 각종 측도, 척도를 결정하고 산업별 요구되는 신뢰수준을 바탕으로 고객이 요구하는 신뢰성 목표를 설정한다. 신뢰성 프로세스 개발 및 활동 요소 정의, 측도 개발, 척도의 정의: 내장형 소프트웨어의 특징에 따라 신뢰성 프로세스 활동 요소를 정의하고, 이에 필요한 측도/척도를 개발한다. 블랙박스 신뢰성 모델 기반 신뢰성 프로세스 개발: 국제표준에 근거한 신뢰성 프로세스, 즉 기존 블랙박스 신뢰성 모델을 기반으로 하는 신뢰성 프로세스를 개발하고 이것이 실연구결과 제 소프트웨어 개발 프로세스와의 연계방안을 개발한다. 고객 신뢰성 요구 목표 기반 화이트박스 신뢰성 모델 개발: 고객 신뢰성 요구 목표를 만족시키기 위해 내장형 소프트웨어의 구조를 모델링하고, 이를 바탕으로 화이트박스 신뢰성 모델을 개발/적용한다. 내장형 소프트웨어 신뢰성 모델 및 개발 조직 성숙도 개선 가이드라인 개발: 연구 결과가 실제 산업현장에서 활용될 수 있도록, 구체적인 적용 사례연구 및 활용 기술, 그리고 활용 절차들이 포함된 내장형 소프트웨어 신뢰성 모델 및 개발 조직 성숙도 개선 가이드라인을 개발한다.그리고 이러한 연구내용들을 효과적으로 수행할 수 있도록 내장형 소프트웨어 신뢰성 모증을 위한 프로세스 지원 도구를 구현하여 효과를 입증하도록 한다.본 연구의 기대효과로는 첫째, 내장형 소프트웨어를 개발하는 중소기업간 클러스터 구성이 가능하여, 국내 시장에서의 국산 내장형 소프트웨어 보급률 향상 및 해외시장 진출을 모색하는 기반 기술로서의 역할을 기대할 수 있으며, 둘째 내장형 소프트웨어를 개발하는 중소기업의 품질 관리 체계 확립을 위한 기반 기술 확보, 아울러 내장형 소프트웨어 신뢰성 확 연구결과의 보 및 내장형 소프트웨어 기반 공정 관리 시스템의 생산성 향상을 기대할 수 있다. 그리고 활용계획 마지막으로 신뢰성 개선 및 측정방안의 확립, 그리고 내장형 소프트웨어 신뢰성 평가 방안 지침서 작성을 통해 세부 방법론을 확립/적용할 수 있을 것으로 기대된다. 또한 작성된 지침서를 활용한 내장형 소프트웨어 신뢰성 개선 및 측정 시범 적용을 통해 다양한 산업 도메인에 독립적이고 표준화된 산업 인프라로서의 역할을 할 수 있을 것으로 기대한다. 고객 신뢰성 요구 목표 내장형 소프트웨어 내장형 소프트웨어 신뢰성 측정 중심어 신뢰성 평가 프로세스 화이트박스 신뢰성 모델 신뢰성 개선을 위한 가이드라인블랙박스 신뢰성 모델 소프트웨어 개발 조직 성숙도 IT융합 내장형 소프트웨어 - 3 -

Page4
양식A202고객 신뢰성 요구 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선방안에 관한 연구는 첫째, IT 융합을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 신뢰성 관리 미흡 및 신뢰성 향상을 위한 체계적 소프트웨어 공학 기법의 미적용 문연구의 제해결을 위해 (1)산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정, (2) 내장형 소목적 및 내용 프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발, (3) 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용, (4)산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발, (5)내장형 소프트웨어 개발 조직의 성숙도 개선 방안, 그리고 마지막으로 (6) 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구의 개발을 수행한다.본 연구는 총 3년의 연구기간을 두고 위 6가지 연구 목표들에 초점을 맞추어 진행되었다. (1) 개발 초기 단계에서 정량적 소프트웨어 신뢰성 목표 설정 방법(COCOMO II와 COQUALMO모델 기반)및 각 모듈별 신뢰성 목표 할당 방법(유전 알고리즘 기반)을 제안한 결과, 사례 연구를 통해 그 효용성을 입증하였다. 신뢰성 목표 설정과 연관 한 개발 비용의 추정을 위해서는 MND-SCEMP라는 국방 도메인에 적합한 프로세스를 제시하여 100여개의 국내 무기관련 프로젝트에 대한 Empirical study를 수행한 결과, 기존의 부정확한 예측을 개선함을 증명하였다. (2) 기존의 소프트웨어 개발 프로세스와 유기적으로 상호 연결되는 신뢰성 평가 프로세스(SRAP)를 제안하고 이를 산업체에 적용하였다. (3) 하드웨어와 소프트웨어의 상호작용 실패를 고려하는 신뢰성 분석을 위해 마르코프 연구결과 체인을 이용한 모델링 방법과 NHPP기반의 모델이 제안되었으며 내장형 소프트웨어에는 상호작용 실패를 고려한 신뢰성 모델이 적합함을 보였다. 구현 이전 단계에서는 UML 모델을 활용한 신뢰성 분석 방법과 SMC(Statical Model Checking)를 이용한 신뢰성 검증 방법을 제시하여 사례 연구를 통해 결과의 우수성을 입증하였다. (4) 신뢰성 보증 활동 가이드라인은 각 활동에 대한 선행 조건, 수행 활동, 완료 조건을 기술하는 형식으로 개발되어 산업체에 보급 및 적용되었다. (5) 품질 평가 모델인 COQUALMO와 DAM을 통합하여 COPQ평가를 수행하였고 이는 개발 조직들이 소프트웨어 품질 향상 전략을 설립하는데 기반을 다질 수 있게 하였다. (6) M&A(Measurement & Analysis) 도구와 내장형 소프트웨어 신뢰성 분석 지원 도구를 개발하여 소프트웨어 신뢰성 보증을 위한 프로세스를 지원하도록 하였다. 본 연구 개발의 결과는 국내 내장형 소프트웨어의 신뢰성 측정/분석/평가/보증 방안 및 신뢰성 관점의 조직 체계를 확립하고 이를 보급함으로써 내장형 소프트웨어를 개발하는 기 연구결과의 업의 시장 경쟁력 강화에 도움을 주고 나아가 중소기업간 클러스터 구성이 가능하도록 지 활용계획 원할 계획이다. 앞으로의 연구에서는 이를 실제 소프트웨어 분야에 활용할 수 있도록 신뢰성 척도 데이터 수집 및 분석 자동화 연구를 바탕으로 대규모 시스템에서의 아키텍처 기반 소프트웨어 신뢰성 자동 평가 방안에 대한 연구까지 연구 범위를 확장할 예정이다. 고객 신뢰성 요구 목표 내장형 소프트웨어 내장형 소프트웨어 신뢰성 측정 중심어 신뢰성 평가 프로세스 화이트박스 신뢰성 모델 신뢰성 개선을 위한 가이드라인 블랙박스 신뢰성 모델 소프트웨어 개발 조직 성숙도 IT융합 내장형 소프트웨어 - 4 -

Page4

양식A202고객 신뢰성 요구 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선방안에 관한 연구는 첫째, IT 융합을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 신뢰성 관리 미흡 및 신뢰성 향상을 위한 체계적 소프트웨어 공학 기법의 미적용 문연구의 제해결을 위해 (1)산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정, (2) 내장형 소목적 및 내용 프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발, (3) 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용, (4)산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발, (5)내장형 소프트웨어 개발 조직의 성숙도 개선 방안, 그리고 마지막으로 (6) 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구의 개발을 수행한다.본 연구는 총 3년의 연구기간을 두고 위 6가지 연구 목표들에 초점을 맞추어 진행되었다. (1) 개발 초기 단계에서 정량적 소프트웨어 신뢰성 목표 설정 방법(COCOMO II와 COQUALMO모델 기반)및 각 모듈별 신뢰성 목표 할당 방법(유전 알고리즘 기반)을 제안한 결과, 사례 연구를 통해 그 효용성을 입증하였다. 신뢰성 목표 설정과 연관 한 개발 비용의 추정을 위해서는 MND-SCEMP라는 국방 도메인에 적합한 프로세스를 제시하여 100여개의 국내 무기관련 프로젝트에 대한 Empirical study를 수행한 결과, 기존의 부정확한 예측을 개선함을 증명하였다. (2) 기존의 소프트웨어 개발 프로세스와 유기적으로 상호 연결되는 신뢰성 평가 프로세스(SRAP)를 제안하고 이를 산업체에 적용하였다. (3) 하드웨어와 소프트웨어의 상호작용 실패를 고려하는 신뢰성 분석을 위해 마르코프 연구결과 체인을 이용한 모델링 방법과 NHPP기반의 모델이 제안되었으며 내장형 소프트웨어에는 상호작용 실패를 고려한 신뢰성 모델이 적합함을 보였다. 구현 이전 단계에서는 UML 모델을 활용한 신뢰성 분석 방법과 SMC(Statical Model Checking)를 이용한 신뢰성 검증 방법을 제시하여 사례 연구를 통해 결과의 우수성을 입증하였다. (4) 신뢰성 보증 활동 가이드라인은 각 활동에 대한 선행 조건, 수행 활동, 완료 조건을 기술하는 형식으로 개발되어 산업체에 보급 및 적용되었다. (5) 품질 평가 모델인 COQUALMO와 DAM을 통합하여 COPQ평가를 수행하였고 이는 개발 조직들이 소프트웨어 품질 향상 전략을 설립하는데 기반을 다질 수 있게 하였다. (6) M&A(Measurement & Analysis) 도구와 내장형 소프트웨어 신뢰성 분석 지원 도구를 개발하여 소프트웨어 신뢰성 보증을 위한 프로세스를 지원하도록 하였다. 본 연구 개발의 결과는 국내 내장형 소프트웨어의 신뢰성 측정/분석/평가/보증 방안 및 신뢰성 관점의 조직 체계를 확립하고 이를 보급함으로써 내장형 소프트웨어를 개발하는 기 연구결과의 업의 시장 경쟁력 강화에 도움을 주고 나아가 중소기업간 클러스터 구성이 가능하도록 지 활용계획 원할 계획이다. 앞으로의 연구에서는 이를 실제 소프트웨어 분야에 활용할 수 있도록 신뢰성 척도 데이터 수집 및 분석 자동화 연구를 바탕으로 대규모 시스템에서의 아키텍처 기반 소프트웨어 신뢰성 자동 평가 방안에 대한 연구까지 연구 범위를 확장할 예정이다. 고객 신뢰성 요구 목표 내장형 소프트웨어 내장형 소프트웨어 신뢰성 측정 중심어 신뢰성 평가 프로세스 화이트박스 신뢰성 모델 신뢰성 개선을 위한 가이드라인 블랙박스 신뢰성 모델 소프트웨어 개발 조직 성숙도 IT융합 내장형 소프트웨어 - 4 -

Page6
1. 연구개발과제의 개요 가. 연구의 필요성자동차, 국방/항공, 의료, 건설과 같은 8대 전략 산업 분야별 내장형 소프트웨어 신뢰성 측정 및 확보를 위 한 객관적인 신뢰성 목표가 제시되지 못하기 때문에 내장형 소프트웨어 개발자는 일관적이지 못한 신뢰성 관 점을 갖게 되고, 나아가 산업 분야별 내장형 소프트웨어의 설계 및 구현에 필요한 의사결정이 올바르게 이루 어지지 못함으로 인해 소프트웨어 운영 시, 내장형 소프트웨어가 본래 기능을 올바르게 수행하지 못하는 결과 를 초래할 수 있다. 이러한 초기 신뢰성 목표가 명확하게 제시되지 못해 발생되는 고장 및 결함에 대한 복구 (재작업) 비용은 시간이 경과할수록 비용 규모가 증가하게 되는 문제가 발생한다. 또한 신뢰성 목표가 명확하 게 기술되지 못해 발생하는 구체적인 신뢰성 확보 방안을 마련하기 어려운 상황을 야기하기도 한다. 이러한 문제를 해결하기 위해 최근 국제 학술대회에서 외국 전문가들의 경험에 근거한 산업 분야별 신뢰성 목표(자동 차: 10-7, 국방/항공: <10-9, 의료: <10-7)가 제시되기도 하였다. 그러나 이러한 외국 전문가들의 경험에 근 거한 신뢰성 목표는 국내 산업의 특성과 국내 내장형 소프트웨어 개발 조직의 특성을 제대로 반영하지 못해, 국내 실정에 맞는 내장형 소프트웨어 신뢰성 측정 방법 개발 및 적절한 평가 방안을 마련하는데 걸림돌로 작 용하고 있다. 또한 내장형 소프트웨어에서 발생하는 고장 및 결함에 대한 복구(재작업) 비용의 절감을 위해 개발 초기 단계, 즉 요구사항 분석 및 기본 설계 단계부터 신뢰성을 고려한 요구사항 분석, 그리고 분석 결과 를 이용한 설계가 이루어져야 함에도 불구하고, 이에 관한 연구는 거의 존재하지 않은 실정이다. 즉, 산업 분 야별 특성을 고려한 고객의 신뢰성 요구 목표를 바탕으로 하는 내장형 소프트웨어에 대한 설계, 이에 대한 신 뢰성 분석 및 평가에 관한 연구가 필요하다. 나. 연구개발의 목적내장형 소프트웨어는 IPTV, e-Transport, u-City, u-Health, u-Safety 등 새로운 융합화 사업이 빠르게 성장하는 추세에서 전통 산업의 고부가가치화, 정보통신 산업의 일류화를 위해 필요한 핵심 기술로 각광받고 있다. 그러나 내장형 소프트웨어 시장규모 및 중요성의 확대에 비해 국내 내장형 소프트웨어 산업은 낮은 생 산성과 낮은 국제적 신뢰수준으로 인해 해외 시장 진출에 많은 어려움을 겪고 있으며 소프트웨어 신뢰성 개선 을 위한 품질 관리의 미흡 및 제도적 장치가 거의 존재하지 않거나 이제 초기 단계의 수준이다. 이를 개선하 - 6 -

Page6

1. 연구개발과제의 개요 가. 연구의 필요성자동차, 국방/항공, 의료, 건설과 같은 8대 전략 산업 분야별 내장형 소프트웨어 신뢰성 측정 및 확보를 위 한 객관적인 신뢰성 목표가 제시되지 못하기 때문에 내장형 소프트웨어 개발자는 일관적이지 못한 신뢰성 관 점을 갖게 되고, 나아가 산업 분야별 내장형 소프트웨어의 설계 및 구현에 필요한 의사결정이 올바르게 이루 어지지 못함으로 인해 소프트웨어 운영 시, 내장형 소프트웨어가 본래 기능을 올바르게 수행하지 못하는 결과 를 초래할 수 있다. 이러한 초기 신뢰성 목표가 명확하게 제시되지 못해 발생되는 고장 및 결함에 대한 복구 (재작업) 비용은 시간이 경과할수록 비용 규모가 증가하게 되는 문제가 발생한다. 또한 신뢰성 목표가 명확하 게 기술되지 못해 발생하는 구체적인 신뢰성 확보 방안을 마련하기 어려운 상황을 야기하기도 한다. 이러한 문제를 해결하기 위해 최근 국제 학술대회에서 외국 전문가들의 경험에 근거한 산업 분야별 신뢰성 목표(자동 차: 10-7, 국방/항공: <10-9, 의료: <10-7)가 제시되기도 하였다. 그러나 이러한 외국 전문가들의 경험에 근 거한 신뢰성 목표는 국내 산업의 특성과 국내 내장형 소프트웨어 개발 조직의 특성을 제대로 반영하지 못해, 국내 실정에 맞는 내장형 소프트웨어 신뢰성 측정 방법 개발 및 적절한 평가 방안을 마련하는데 걸림돌로 작 용하고 있다. 또한 내장형 소프트웨어에서 발생하는 고장 및 결함에 대한 복구(재작업) 비용의 절감을 위해 개발 초기 단계, 즉 요구사항 분석 및 기본 설계 단계부터 신뢰성을 고려한 요구사항 분석, 그리고 분석 결과 를 이용한 설계가 이루어져야 함에도 불구하고, 이에 관한 연구는 거의 존재하지 않은 실정이다. 즉, 산업 분 야별 특성을 고려한 고객의 신뢰성 요구 목표를 바탕으로 하는 내장형 소프트웨어에 대한 설계, 이에 대한 신 뢰성 분석 및 평가에 관한 연구가 필요하다. 나. 연구개발의 목적내장형 소프트웨어는 IPTV, e-Transport, u-City, u-Health, u-Safety 등 새로운 융합화 사업이 빠르게 성장하는 추세에서 전통 산업의 고부가가치화, 정보통신 산업의 일류화를 위해 필요한 핵심 기술로 각광받고 있다. 그러나 내장형 소프트웨어 시장규모 및 중요성의 확대에 비해 국내 내장형 소프트웨어 산업은 낮은 생 산성과 낮은 국제적 신뢰수준으로 인해 해외 시장 진출에 많은 어려움을 겪고 있으며 소프트웨어 신뢰성 개선 을 위한 품질 관리의 미흡 및 제도적 장치가 거의 존재하지 않거나 이제 초기 단계의 수준이다. 이를 개선하 - 6 -

Page7
기 위해 고객 신뢰성 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선 방안에 관한 연구는 첫째, IT 융합 을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 품질 관리 미흡 및 신뢰성 향상을 위한 체계적 소프 트웨어 공학 기법의 미적용 문제들을 해결하기 위해 다음과 같은 연구 목적을 갖는다. 산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용 산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발 내장형 소프트웨어 개발 조직의 성숙도 개선 방안 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구 개발 다. 연구범위 및 연구수행 방법위에서 언급한 연구 목표를 수행하기 위한 연차별 세부 연구 내용은 다음과 같다. 1차년도 연구의 주요 내 용은 산업별(자동차, 국방/항공, 의료 등) 도메인의 특성 및 산업별 내장형 소프트웨어의 주요한 특성들을 기 반으로 고객이 가질 수 있는 다양한 신뢰성 요구 목표 설정 기법에 관한 연구이다. 2차년도 연구의 주요 내용 은 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스의 개발과 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 가이드라인 개발이다. 3차년도 연구의 주요 내용은 고객 신뢰성 요구 목표 기반 화이트박스 신뢰성 모델의 개발과 개발 조직 성숙도 개선 가이드라인 개발, 그리고 내장형 소프트웨어 신뢰성 보증을 위 한 프로세스 지원 도구의 개발이다. [그림 1] 연차별 세부 연구 내용 - 7 -

Page7

기 위해 고객 신뢰성 목표 기반 내장형 소프트웨어의 신뢰성 측정 및 개선 방안에 관한 연구는 첫째, IT 융합 을 위한 산업별 내장형 소프트웨어 신뢰성 요구 목표를 설정하고, 둘째, 국내 내장형 소프트웨어를 개발하는 중소기업들이 공통적으로 직면한 문제점, 즉 소프트웨어 품질 관리 미흡 및 신뢰성 향상을 위한 체계적 소프 트웨어 공학 기법의 미적용 문제들을 해결하기 위해 다음과 같은 연구 목적을 갖는다. 산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용 산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발 내장형 소프트웨어 개발 조직의 성숙도 개선 방안 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구 개발 다. 연구범위 및 연구수행 방법위에서 언급한 연구 목표를 수행하기 위한 연차별 세부 연구 내용은 다음과 같다. 1차년도 연구의 주요 내 용은 산업별(자동차, 국방/항공, 의료 등) 도메인의 특성 및 산업별 내장형 소프트웨어의 주요한 특성들을 기 반으로 고객이 가질 수 있는 다양한 신뢰성 요구 목표 설정 기법에 관한 연구이다. 2차년도 연구의 주요 내용 은 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스의 개발과 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 가이드라인 개발이다. 3차년도 연구의 주요 내용은 고객 신뢰성 요구 목표 기반 화이트박스 신뢰성 모델의 개발과 개발 조직 성숙도 개선 가이드라인 개발, 그리고 내장형 소프트웨어 신뢰성 보증을 위 한 프로세스 지원 도구의 개발이다. [그림 1] 연차별 세부 연구 내용 - 7 -

Page8
정부에서는 1980년대 이후 국가 성장을 위한 전략적 수단으로 「e-KOREA VISION 2006」(2002), 「Broadband IT KOREA VISION 2007」(2003),「IT-839전략」(2004),「u- KOREA 기본계획」(2006) 등 급속하게 발전하고 변화하는 정보화 환경을 신속히 반영한 국가사회 정보화를 추진해 왔다. 그리고 그동안 국내 산업은 자동차, 조선, 건설, 등 세계 최고 수준의 제조업과 휴대폰, 반도체, 가전 등 정보통신 산업을 중 심으로 성장해 왔으나 하드웨어에 내장되어 동작하는 내장형 소프트웨어 부문에 대한 고려는 매우 취약한 실 정이다. 특히, 최근의 시스템들은 소프트웨어가 차지하는 비중이 증가하고 있으며 소프트웨어 중심의 설계가 이루어지고 있다. 그리고 다양한 산업 분야에서 당면한 문제 해결과 고객에게 편의성을 제공하고 요구사항을 만족시키기 위해 끊임없이 진화하고 있으며 높은 소프트웨어 신뢰성에 대한 요구 또한 점점 증가하고 있다. 2009년 국내 첫 우주발사체인 나로호(KSLV-1)가 고압탱크 관련 소프트웨어 결함으로 인해 발사가 연기되어 수억원에 이르는 막대한 경제적 손실을 야기하였으며, 대외적으로는 일본의 대표적인 자동차 업체인 도요타도 자동차 엔진 제어 유닛의 소프트웨어 결함으로 인해 역사상 최대 수치인 약 540만대의 자동차를 리콜 조치하 는 등 내장형 소프트웨어의 결함으로 인한 손실은 어마어마한 수준이다. 이로 인해 최근 국내·외적으로 내장 형 소프트웨어의 신뢰성에 대한 중요성이 다시금 부각되고 있다. 그러나 내장형 소프트웨어 시장규모 및 중요 성의 확대에 비해 국내 내장형 소프트웨어 산업은 낮은 생산성과 낮은 국제적 신뢰수준으로 인해 해외 시장 진출에 많은 어려움을 겪고 있다. IEEE 표준에 따르면 소프트웨어 신뢰성이란 “소프트웨어가 주어진 조건과 시간동안 시스템 고장 발생을 일으키지 않을 확률” 이라고 정의하고 있다. 이는 하드웨어 신뢰성과 유사하지 만, 특히 주어진 시간과 환경에서 불규칙한 변수가 발생할 수 있으며, 운영환경과 데이터 이동에 대한 영향 등을 고려하여 소프트웨어 잠재적인 설계상의 문제점을 예측할 수 있어야 한다. 그러나 국내 내장형 소프트웨 어 시장에서는 소프트웨어 신뢰성 측정 및 개선 방법에 대한 기준 또는 연구가 진행된 바가 없다. 뿐만 아니 라 국내 IT 융합 산업에서 소프트웨어의 품질 테스트를 위한 품질 평가 방법론의 부재로, 국내 내장형 소프트 웨어 개발 프로세스 수준은 3점 만점에 1.63점 수준이며, 특히 중소기업의 88%는 체계적인 소프트웨어 공학 기법 적용이 전무한 상태이다 [1]. 그러므로 2008년 7월 지식경제부 기술표준연구원에서는 “IT 융합 산업에 서의 소프트웨어 테스팅 및 평가” 세미나를 통해 “IT 융합산업에서 소프트웨어 신뢰성의 확보가 필수적이지만 국내는 아직까지 신뢰성 확보를 위한 테스팅 및 평가 기술이 초보단계로, 소프트웨어 품질평가 기반 확산이 필요하다”고 강조하였다 [2]. 최근에는 소프트웨어 품질 관리에 대한 공학 수준이 평균 5.3점 정도가 향상되고 기업 규모별 SW 공학 수 준의 격차가 많이 향상되었다. 즉, 도메인 별 소프트웨어 품질에 대한 인식이 많이 개선되어 고객의 구체적인 신뢰성 요구 목표 설정에 대한 연구가 더 절실해 지고 있는 실정이다. 또한 소프트웨어 개발 프로젝트의 3개 월간 운영결함밀도를 살펴 보면 0.17개/FP로 분석되었으며, 이는 ISBSG의 평균인 0.094개/FP에 상당 수준 접근했다고 볼 수 있다. 그럼에도 불구하고 객관적 격차는 여전히 높은 수준임을 알 수 있기 때문에 신뢰성 목표 설정에 대한 정량화, 신뢰성 평가 프로세스의 개발 및 표준화에 대한 연구가 매우 시급함을 알 수 있다. - 8 -

Page8

정부에서는 1980년대 이후 국가 성장을 위한 전략적 수단으로 「e-KOREA VISION 2006」(2002), 「Broadband IT KOREA VISION 2007」(2003),「IT-839전략」(2004),「u- KOREA 기본계획」(2006) 등 급속하게 발전하고 변화하는 정보화 환경을 신속히 반영한 국가사회 정보화를 추진해 왔다. 그리고 그동안 국내 산업은 자동차, 조선, 건설, 등 세계 최고 수준의 제조업과 휴대폰, 반도체, 가전 등 정보통신 산업을 중 심으로 성장해 왔으나 하드웨어에 내장되어 동작하는 내장형 소프트웨어 부문에 대한 고려는 매우 취약한 실 정이다. 특히, 최근의 시스템들은 소프트웨어가 차지하는 비중이 증가하고 있으며 소프트웨어 중심의 설계가 이루어지고 있다. 그리고 다양한 산업 분야에서 당면한 문제 해결과 고객에게 편의성을 제공하고 요구사항을 만족시키기 위해 끊임없이 진화하고 있으며 높은 소프트웨어 신뢰성에 대한 요구 또한 점점 증가하고 있다. 2009년 국내 첫 우주발사체인 나로호(KSLV-1)가 고압탱크 관련 소프트웨어 결함으로 인해 발사가 연기되어 수억원에 이르는 막대한 경제적 손실을 야기하였으며, 대외적으로는 일본의 대표적인 자동차 업체인 도요타도 자동차 엔진 제어 유닛의 소프트웨어 결함으로 인해 역사상 최대 수치인 약 540만대의 자동차를 리콜 조치하 는 등 내장형 소프트웨어의 결함으로 인한 손실은 어마어마한 수준이다. 이로 인해 최근 국내·외적으로 내장 형 소프트웨어의 신뢰성에 대한 중요성이 다시금 부각되고 있다. 그러나 내장형 소프트웨어 시장규모 및 중요 성의 확대에 비해 국내 내장형 소프트웨어 산업은 낮은 생산성과 낮은 국제적 신뢰수준으로 인해 해외 시장 진출에 많은 어려움을 겪고 있다. IEEE 표준에 따르면 소프트웨어 신뢰성이란 “소프트웨어가 주어진 조건과 시간동안 시스템 고장 발생을 일으키지 않을 확률” 이라고 정의하고 있다. 이는 하드웨어 신뢰성과 유사하지 만, 특히 주어진 시간과 환경에서 불규칙한 변수가 발생할 수 있으며, 운영환경과 데이터 이동에 대한 영향 등을 고려하여 소프트웨어 잠재적인 설계상의 문제점을 예측할 수 있어야 한다. 그러나 국내 내장형 소프트웨 어 시장에서는 소프트웨어 신뢰성 측정 및 개선 방법에 대한 기준 또는 연구가 진행된 바가 없다. 뿐만 아니 라 국내 IT 융합 산업에서 소프트웨어의 품질 테스트를 위한 품질 평가 방법론의 부재로, 국내 내장형 소프트 웨어 개발 프로세스 수준은 3점 만점에 1.63점 수준이며, 특히 중소기업의 88%는 체계적인 소프트웨어 공학 기법 적용이 전무한 상태이다 [1]. 그러므로 2008년 7월 지식경제부 기술표준연구원에서는 “IT 융합 산업에 서의 소프트웨어 테스팅 및 평가” 세미나를 통해 “IT 융합산업에서 소프트웨어 신뢰성의 확보가 필수적이지만 국내는 아직까지 신뢰성 확보를 위한 테스팅 및 평가 기술이 초보단계로, 소프트웨어 품질평가 기반 확산이 필요하다”고 강조하였다 [2]. 최근에는 소프트웨어 품질 관리에 대한 공학 수준이 평균 5.3점 정도가 향상되고 기업 규모별 SW 공학 수 준의 격차가 많이 향상되었다. 즉, 도메인 별 소프트웨어 품질에 대한 인식이 많이 개선되어 고객의 구체적인 신뢰성 요구 목표 설정에 대한 연구가 더 절실해 지고 있는 실정이다. 또한 소프트웨어 개발 프로젝트의 3개 월간 운영결함밀도를 살펴 보면 0.17개/FP로 분석되었으며, 이는 ISBSG의 평균인 0.094개/FP에 상당 수준 접근했다고 볼 수 있다. 그럼에도 불구하고 객관적 격차는 여전히 높은 수준임을 알 수 있기 때문에 신뢰성 목표 설정에 대한 정량화, 신뢰성 평가 프로세스의 개발 및 표준화에 대한 연구가 매우 시급함을 알 수 있다. - 8 -

Page9
내장형 소프트웨어의 고객 신뢰성 목표 기반 신뢰성 측정 및 개선 방안으로 본 연구는 총 3년의 연구기간을 두고 1장에서 언급한 6가지 연구 목표들에 초점을 맞추어 진행되었다. 2010년 05월 1일부터 2013년 02월 15일까지의 연구기간 동안 국방 및 민간 분야 주요 시제업체와 협의를 거쳐 내장형 소프트웨어 분야의 도메인 분석과 관련 기술을 조사 분석 하였으며 내장형 소프트웨어 신뢰성 보장 프로세스를 정의하는 등 연구 목표별로 다음과 같은 연구를 진행하였다. [그림 2] 연구 목표 대비 연구 수행 내용 및 결과 가. 산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정 다양한 산업별 특징 분석(자동차, 국방/항공, 의료, 조선, 건설), 즉 도메인을 분석을 통한 고객 신 뢰성 요구 목표를 만족시키는 내장형 소프트웨어 신뢰성 보증 활동 요소를 정의하고, 분야별 고객이 요구하는 신뢰성 목표를 설정하기 위한 기법에 대한 연구를 수행하였다. 1) 초기 소프트웨어 개발 수명 주기에서 정량적 소프트웨어 신뢰성 목표 설정 지원 연구 수행 내용 본 연구에서는 소프트웨어 신뢰성 분석/평가를 위해 소프트웨어 개발 초기 단계에서 얻어지는 초기 입 력 값들을 이용하여 소프트웨어 개발 비용과 초기 소프트웨어 결함 밀도를 예측하고, 예측 값들을 이 - 9 -

Page9

내장형 소프트웨어의 고객 신뢰성 목표 기반 신뢰성 측정 및 개선 방안으로 본 연구는 총 3년의 연구기간을 두고 1장에서 언급한 6가지 연구 목표들에 초점을 맞추어 진행되었다. 2010년 05월 1일부터 2013년 02월 15일까지의 연구기간 동안 국방 및 민간 분야 주요 시제업체와 협의를 거쳐 내장형 소프트웨어 분야의 도메인 분석과 관련 기술을 조사 분석 하였으며 내장형 소프트웨어 신뢰성 보장 프로세스를 정의하는 등 연구 목표별로 다음과 같은 연구를 진행하였다. [그림 2] 연구 목표 대비 연구 수행 내용 및 결과 가. 산업별 내장형 소프트웨어 고객 신뢰성 요구 목표 설정 다양한 산업별 특징 분석(자동차, 국방/항공, 의료, 조선, 건설), 즉 도메인을 분석을 통한 고객 신 뢰성 요구 목표를 만족시키는 내장형 소프트웨어 신뢰성 보증 활동 요소를 정의하고, 분야별 고객이 요구하는 신뢰성 목표를 설정하기 위한 기법에 대한 연구를 수행하였다. 1) 초기 소프트웨어 개발 수명 주기에서 정량적 소프트웨어 신뢰성 목표 설정 지원 연구 수행 내용 본 연구에서는 소프트웨어 신뢰성 분석/평가를 위해 소프트웨어 개발 초기 단계에서 얻어지는 초기 입 력 값들을 이용하여 소프트웨어 개발 비용과 초기 소프트웨어 결함 밀도를 예측하고, 예측 값들을 이 - 9 -

Page10
용하여 대상 소프트웨어가 가질 수 있는 정량적 소프트웨어 신뢰성 목표를 설정하는 방법을 제안하였 다. 해당 연구는 다음의 절차로 진행되었다. (1) 소프트웨어 개발에 사용되는 자원과 비용, 그리고 소프트웨어 제품이 갖는 품질에 대한 trade-off를 파악할 수 있도록 비용 척도 및 제품 척도를 정의 (2) 비용 요소 및 제품 요소의 trade-off 결과를 조율하여 적정 수준의 자원 및 비용을 활용하면서 도 소프트웨어 신뢰성을 최대화 할 수 있도록 의사 결정을 지원하기 위한 방법을 정의 (3) 실제 산업에서 수집된 데이터를 활용한 사례 분석 이때 소프트웨어 개발 비용 예측을 위해 대표적인 COCOMO II모델을 기반으로 하였으며, 초기 소프 트웨어 결함 밀도 예측을 위해서는 COQUALMO모델을 활용하였다. 이들 모델은 소프트웨어 개발 조직 의 특성 및 대상 소프트웨어의 목적 및 역할을 잘 반영한 드라이버들을 제공하고 있기 때문에, 현실적 인 소프트웨어 신뢰성 목표를 설정하기에 매우 적합한 모델이다. 사례 연구를 통해 제안하는 방법은 프로젝트의 규모 요소와 결함 밀도 요소를 이용하여 투입되는 공수와 신뢰성을 동시에 고려한 신뢰성 목표를 설정할 수 있는 유용한 도구로써 사용될 수 있다는 것을 알 수 있었다. 이는 본 연구에서 제안 하는 정량적 소프트웨어 신뢰성 목표 설정 방법이 적절한 신뢰성 목표를 설정하는데 있어 유용한 방법 이 될 수 있음을 나타낸다. 정량적 소프트웨어 신뢰성 목표 설정 프로세스 정량적 소프트웨어 신뢰성 목표 설정은 다음과 같은 절차로 수행된다. (1) 비용 척도, 즉 COCOMO II 모델을 기반으로 유도되는 소프트웨어 개발 추정 비용에 대한 상한 (MAX(DC))과 하한값 (MIN(DC))을 결정한다. (2) 제품 척도, 즉 COQUALMO 모델을 기반으로 유도되는 잔여 결함 수와 소프트웨어 규모를 이용 하여 결함 밀도에 대한 상한 (MAX(FD))와 하한값 (MIN(FD))를 결정한다. (3) 비용 척도의 변화를 나타내는 함수 g(t)를 유도하기 위해, 소프트웨어 개발 조직 및 대상 소프 트웨어에 대한 규모 요소와 노력 가중치를 적용하여 소프트웨어 개발 비용에 대한 단계별 관측값을 도출한다. (COCOMO II 모델 이용) (4) 제품 척도에 대한 변화를 나타내는 함수 f(t)를 유도하기 위해, g(t)와 동일한 방법으로 소프트 웨어 개발 과정에서 잠재된 소프트웨어 잔여 결함을 계산하고, 이를 소프트웨어 규모로 나눈 결함 밀 도를 계산한다. (COQUALMO 모델 이용) (5) 단계 3에서 도출된 값들을 이용하여 회귀 방정식 g(t)를 유도한다. (6) 단계 4에서 계산된 값들을 이용하여 회귀 방정식 f(t)를 유도한다. (7) g(t)와 f(t)에 대한 교점에 해당하는 결함 밀도를 계산한다. 예를 들어, 단계 1에서 소프트웨어 개발 추정 비용에 대한 상한은 개발 추정 비용 계산에 영향을 주 는 모든 요소에 대해 VH (Very High) 값을 갖도록 하여 구할 수 있으며, 하한은 모든 요소에 대해 - 10 -

Page10

용하여 대상 소프트웨어가 가질 수 있는 정량적 소프트웨어 신뢰성 목표를 설정하는 방법을 제안하였 다. 해당 연구는 다음의 절차로 진행되었다. (1) 소프트웨어 개발에 사용되는 자원과 비용, 그리고 소프트웨어 제품이 갖는 품질에 대한 trade-off를 파악할 수 있도록 비용 척도 및 제품 척도를 정의 (2) 비용 요소 및 제품 요소의 trade-off 결과를 조율하여 적정 수준의 자원 및 비용을 활용하면서 도 소프트웨어 신뢰성을 최대화 할 수 있도록 의사 결정을 지원하기 위한 방법을 정의 (3) 실제 산업에서 수집된 데이터를 활용한 사례 분석 이때 소프트웨어 개발 비용 예측을 위해 대표적인 COCOMO II모델을 기반으로 하였으며, 초기 소프 트웨어 결함 밀도 예측을 위해서는 COQUALMO모델을 활용하였다. 이들 모델은 소프트웨어 개발 조직 의 특성 및 대상 소프트웨어의 목적 및 역할을 잘 반영한 드라이버들을 제공하고 있기 때문에, 현실적 인 소프트웨어 신뢰성 목표를 설정하기에 매우 적합한 모델이다. 사례 연구를 통해 제안하는 방법은 프로젝트의 규모 요소와 결함 밀도 요소를 이용하여 투입되는 공수와 신뢰성을 동시에 고려한 신뢰성 목표를 설정할 수 있는 유용한 도구로써 사용될 수 있다는 것을 알 수 있었다. 이는 본 연구에서 제안 하는 정량적 소프트웨어 신뢰성 목표 설정 방법이 적절한 신뢰성 목표를 설정하는데 있어 유용한 방법 이 될 수 있음을 나타낸다. 정량적 소프트웨어 신뢰성 목표 설정 프로세스 정량적 소프트웨어 신뢰성 목표 설정은 다음과 같은 절차로 수행된다. (1) 비용 척도, 즉 COCOMO II 모델을 기반으로 유도되는 소프트웨어 개발 추정 비용에 대한 상한 (MAX(DC))과 하한값 (MIN(DC))을 결정한다. (2) 제품 척도, 즉 COQUALMO 모델을 기반으로 유도되는 잔여 결함 수와 소프트웨어 규모를 이용 하여 결함 밀도에 대한 상한 (MAX(FD))와 하한값 (MIN(FD))를 결정한다. (3) 비용 척도의 변화를 나타내는 함수 g(t)를 유도하기 위해, 소프트웨어 개발 조직 및 대상 소프 트웨어에 대한 규모 요소와 노력 가중치를 적용하여 소프트웨어 개발 비용에 대한 단계별 관측값을 도출한다. (COCOMO II 모델 이용) (4) 제품 척도에 대한 변화를 나타내는 함수 f(t)를 유도하기 위해, g(t)와 동일한 방법으로 소프트 웨어 개발 과정에서 잠재된 소프트웨어 잔여 결함을 계산하고, 이를 소프트웨어 규모로 나눈 결함 밀 도를 계산한다. (COQUALMO 모델 이용) (5) 단계 3에서 도출된 값들을 이용하여 회귀 방정식 g(t)를 유도한다. (6) 단계 4에서 계산된 값들을 이용하여 회귀 방정식 f(t)를 유도한다. (7) g(t)와 f(t)에 대한 교점에 해당하는 결함 밀도를 계산한다. 예를 들어, 단계 1에서 소프트웨어 개발 추정 비용에 대한 상한은 개발 추정 비용 계산에 영향을 주 는 모든 요소에 대해 VH (Very High) 값을 갖도록 하여 구할 수 있으며, 하한은 모든 요소에 대해 - 10 -

Page11
VL (Very Low) 값을 갖도록 하여 구할 수 있다. 그리고 제품 척도에 대한 단계 2에서도 동일한 방 법으로 제품 척도에 대한 상한과 하한을 구할 수 있게 된다. 단계 3에서 비용 척도의 변화를 나타내 는 함수 g(t)는 대상 소프트웨어의 규모 요소에 영향을 받기 때문에 시간이 경과함에 따라 개발 추정 비용이 좀 더 구체적으로 상세화 될 수 있다. 그러므로 시간 또는 단계별 개발 추정 비용을 계산할 수 있다. 단계 4에서도 단계 3과 같은 방법으로 대상 소프트웨어의 잔여 결함에 영향을 주는 요소를 적용하여 소프트웨어의 결함 밀도를 시간 또는 단계별로 계산할 수 있다. 그리고 단계 5와 6은 앞 단 계에서 계산된 개발 추정 비용과 결함 밀도에 대한 회귀 방정식 g(t)와 f(t)를 구하는 과정으로 최소 자승법을 이용하여 회귀 방정식을 유도한다. 본 연구에서는 g(t)와 f(t)는 모두 지수형 회귀 모델을 가짐을 가정한다. 마지막으로 단계 7에서는 g(t)와 f(t)에 대한 교점(Optimal Point, OP)을 계산하고, OP에서의 결함 밀도를 소프트웨어의 신뢰성 목표로 결정하도록 한다. 그리고 아래 그림에서 보는 바 와 같이 가용신뢰성 (Available Reliability, AR)는 AR < g(t) 그리고 AR < f(t))를 만족하므로 대 상 소프트웨어가 가질 수 있는 가용 신뢰성 목표 영역으로 볼 수 있다. [그림 3] 소프트웨어 비용 추정 식 g(t)와 소프트웨어 잔여 결함 밀도 f(t) 회귀 방정식 국방 도메인에서의 산업 데이터 수집 및 사례연구 본 연구에서 제시된 정량적 소프트웨어 신뢰성 목표 설정 방법을 실제 산업계 데이터를 수집, 활용하 여 실제로 적용 하고 그 유효성을 평가하였다. 본 사례 연구에서 활용된 데이터는 2007년 9월부터 2009년 2월까지 CMMI 레벨 5 수준의 국방 분야 국내 내장형 소프트웨어 개발 조직에서 수집된 데 이터이며, COQUALMO에서 고려되는 요소, 즉 DI 단계에서 21개 요소와 DR 단계에서 3개요소, 그리 - 11 -

Page11

VL (Very Low) 값을 갖도록 하여 구할 수 있다. 그리고 제품 척도에 대한 단계 2에서도 동일한 방 법으로 제품 척도에 대한 상한과 하한을 구할 수 있게 된다. 단계 3에서 비용 척도의 변화를 나타내 는 함수 g(t)는 대상 소프트웨어의 규모 요소에 영향을 받기 때문에 시간이 경과함에 따라 개발 추정 비용이 좀 더 구체적으로 상세화 될 수 있다. 그러므로 시간 또는 단계별 개발 추정 비용을 계산할 수 있다. 단계 4에서도 단계 3과 같은 방법으로 대상 소프트웨어의 잔여 결함에 영향을 주는 요소를 적용하여 소프트웨어의 결함 밀도를 시간 또는 단계별로 계산할 수 있다. 그리고 단계 5와 6은 앞 단 계에서 계산된 개발 추정 비용과 결함 밀도에 대한 회귀 방정식 g(t)와 f(t)를 구하는 과정으로 최소 자승법을 이용하여 회귀 방정식을 유도한다. 본 연구에서는 g(t)와 f(t)는 모두 지수형 회귀 모델을 가짐을 가정한다. 마지막으로 단계 7에서는 g(t)와 f(t)에 대한 교점(Optimal Point, OP)을 계산하고, OP에서의 결함 밀도를 소프트웨어의 신뢰성 목표로 결정하도록 한다. 그리고 아래 그림에서 보는 바 와 같이 가용신뢰성 (Available Reliability, AR)는 AR < g(t) 그리고 AR < f(t))를 만족하므로 대 상 소프트웨어가 가질 수 있는 가용 신뢰성 목표 영역으로 볼 수 있다. [그림 3] 소프트웨어 비용 추정 식 g(t)와 소프트웨어 잔여 결함 밀도 f(t) 회귀 방정식 국방 도메인에서의 산업 데이터 수집 및 사례연구 본 연구에서 제시된 정량적 소프트웨어 신뢰성 목표 설정 방법을 실제 산업계 데이터를 수집, 활용하 여 실제로 적용 하고 그 유효성을 평가하였다. 본 사례 연구에서 활용된 데이터는 2007년 9월부터 2009년 2월까지 CMMI 레벨 5 수준의 국방 분야 국내 내장형 소프트웨어 개발 조직에서 수집된 데 이터이며, COQUALMO에서 고려되는 요소, 즉 DI 단계에서 21개 요소와 DR 단계에서 3개요소, 그리 - 11 -

Page12
고 COCOMO II에서 비용에 관한 요소, 즉, 5개의 제품 요소, 3개의 플랫폼 요소, 6개의 인적 요소, 그리고 3개의 프로젝트 요소로 구성된 노력 가중치와 5개의 규모 요소에 대한 데이터 수집이 사전에 이루어졌으며, 2005년 COCOMO 포럼에서 제공된 도구를 활용하였다. 그리고 COCOMO II에 관한 데 이터 수집에서 비용 산정에 대한 보정은 따로 하지 않았다. 본 사례 연구에서는 여러 신뢰성 척도 중 비용 척도 (DE), 규모 척도 (SS)와 품질 척도 (FF)를 선택 하였다. 이는 소프트웨어 개발 프로젝트에서 초기에 얻을 수 있는 신뢰성 관련 척도가 바로 소프트웨 어 개발 공수, 규모, 그리고 그에 따른 적절한 수준의 고장 및 결함이기 때문이다. 즉, 주어진 시간과 비용을 활용하여 어느 정도의 품질을 가질 수 있을 것인지가 신뢰성 목표 설정에 있어 가장 중요한 사항이기 때문이다. 사례연구 결과로 정량적 신뢰성 목표설정 절차에 따라 두 회귀 방정식 g(t)와 f(t)을 계산한 뒤 이 두 회귀 방정식에 대한 교점을 구하기 위해 g(t) = f(t)를 만족하는 매개변수 t를 구하면 약 2.78이 되 고, f(2.78) = 8.210147의 결과를 얻었다. 즉, [그림 3]에서 두방정식이 교차하는 지점이 대상 프로 젝트의 최적화 된 신뢰성 목표를 나타내며, 그에 대한 비용 및 신뢰성 목표를 결함 밀도 관점에서 계 산할 수 있다. 대상 프로젝트의 경우 2166.48 PM의 공수를 투입하여 결함 밀도 8.210147의 신뢰성 목표를 세울 수 있다는 것을 알 수 있다. 본 사례 연구를 통해 본 연구에서 제안하는 방법은 프로젝 트의 규모 요소와 결함 밀도 요소를 이용하여 투입되는 공수와 신뢰성을 동시에 고려한 신뢰성 목표 를 설정할 수 있는 유용한 도구로써 사용될 수 있다는 것을 알 수 있다. 마지막으로 [그림 4]은 계산된 결함밀도와 개발비용에 따른 신뢰성 목표에 대한 최적 지점과 가용소 프트웨어 신뢰성 목표들을 나타내고 있으며, 본 사례 연구에 따르면 구현 이후, 초기 단위 테스팅 단 계에서 발견된 결함은 모두 76개로, 이때의 결함 밀도가 0.097 (faluts/KLOC) 로 측정되었으므로 대 상 소프트웨어에 대한 목표 신뢰성을 잘 만족하고 있음을 알 수 있었다. [그림 4] 소프트웨어 신뢰성 목표의 Optimal Point 와 가용 소프트웨어 신뢰성 - 12 -

Page12

고 COCOMO II에서 비용에 관한 요소, 즉, 5개의 제품 요소, 3개의 플랫폼 요소, 6개의 인적 요소, 그리고 3개의 프로젝트 요소로 구성된 노력 가중치와 5개의 규모 요소에 대한 데이터 수집이 사전에 이루어졌으며, 2005년 COCOMO 포럼에서 제공된 도구를 활용하였다. 그리고 COCOMO II에 관한 데 이터 수집에서 비용 산정에 대한 보정은 따로 하지 않았다. 본 사례 연구에서는 여러 신뢰성 척도 중 비용 척도 (DE), 규모 척도 (SS)와 품질 척도 (FF)를 선택 하였다. 이는 소프트웨어 개발 프로젝트에서 초기에 얻을 수 있는 신뢰성 관련 척도가 바로 소프트웨 어 개발 공수, 규모, 그리고 그에 따른 적절한 수준의 고장 및 결함이기 때문이다. 즉, 주어진 시간과 비용을 활용하여 어느 정도의 품질을 가질 수 있을 것인지가 신뢰성 목표 설정에 있어 가장 중요한 사항이기 때문이다. 사례연구 결과로 정량적 신뢰성 목표설정 절차에 따라 두 회귀 방정식 g(t)와 f(t)을 계산한 뒤 이 두 회귀 방정식에 대한 교점을 구하기 위해 g(t) = f(t)를 만족하는 매개변수 t를 구하면 약 2.78이 되 고, f(2.78) = 8.210147의 결과를 얻었다. 즉, [그림 3]에서 두방정식이 교차하는 지점이 대상 프로 젝트의 최적화 된 신뢰성 목표를 나타내며, 그에 대한 비용 및 신뢰성 목표를 결함 밀도 관점에서 계 산할 수 있다. 대상 프로젝트의 경우 2166.48 PM의 공수를 투입하여 결함 밀도 8.210147의 신뢰성 목표를 세울 수 있다는 것을 알 수 있다. 본 사례 연구를 통해 본 연구에서 제안하는 방법은 프로젝 트의 규모 요소와 결함 밀도 요소를 이용하여 투입되는 공수와 신뢰성을 동시에 고려한 신뢰성 목표 를 설정할 수 있는 유용한 도구로써 사용될 수 있다는 것을 알 수 있다. 마지막으로 [그림 4]은 계산된 결함밀도와 개발비용에 따른 신뢰성 목표에 대한 최적 지점과 가용소 프트웨어 신뢰성 목표들을 나타내고 있으며, 본 사례 연구에 따르면 구현 이후, 초기 단위 테스팅 단 계에서 발견된 결함은 모두 76개로, 이때의 결함 밀도가 0.097 (faluts/KLOC) 로 측정되었으므로 대 상 소프트웨어에 대한 목표 신뢰성을 잘 만족하고 있음을 알 수 있었다. [그림 4] 소프트웨어 신뢰성 목표의 Optimal Point 와 가용 소프트웨어 신뢰성 - 12 -

Page13
연구 수행 결과 본 연구에서는 소프트웨어 신뢰성 분석/평가를 위해 소프트웨어 개발 초기 단계에서 얻어지는 초기 입력값들을 이용하여 소프트웨어 개발 비용과 초기 소프트웨어 결함 밀도를 예측하고, 예측값들을 이 용하여 대상 소프트웨어가 가질 수 있는 정량적 소프트웨어 신뢰성 목표를 설정하는 방법을 제안하였 다. 이때 소프트웨어 개발 비용 예측을 위해 대표적인 COCOMO II 모델을 기반으로 하였으며, 초기 소프트웨어 결함 밀도 예측을 위해서는 COQUALMO 모델을 활용하였다. 이들 모델은 소프트웨어 개 발 조직의 특성 및 대상 소프트웨어의 목적 및 역할을 잘 반영한 드라이버들을 제공하고 있기 때문 에, 현실적인 소프트웨어 신뢰성 목표를 설정하기에 매우 적합한 모델이다. 또한 본 연구에서 제안된 정량적 소프트웨어 신뢰성 목표 설정 방법을 이용하여 실제 국내 소프트웨어 개발 조직 및 프로젝트 에 적용하여, 제안된 방법이 적절한 신뢰성 목표를 설정하는데 있어 유용한 방법이 될 수 있음을 보 였다. 향후 연구 과제로는 COCOMO II와 COQUALMO 모델 이외에 소프트웨어 신뢰성 예측을 지원하는 다 른 여러 모델들을 특성을 모두 고려한 신뢰성 목표 설정 기법에 관한 연구가 필요하다. 또한 소프트 웨어 개발 과정에서 추가적으로 변경되는 요인, 예를 들어 요구사항 변경에 따른 기능 추가/삭제/수정, 개발 비용의 변화 등을 반영한 신뢰성 목표 설정 기법에 관한 연구를 추가적으로 진행할 예정이다. 2)　다목적 유전자 알고리즘 기반 소프트웨어 모듈에 대한 신뢰성 할당 최적화 연구 수행 내용 전체 소프트웨어 신뢰성은 소프트웨어를 구성하는 하위 모듈들의 상호 작용에 영향을 받기 때문에, 전체 소프트웨어 신뢰성 목표가 설정된 후, 이를 충족시키기 위한 각 하위 모듈들의 신뢰성을 할당하 는 것을 소프트웨어 신뢰성 할당이라고 한다. 본 연구는 소프트웨어 신뢰성을 최대화 시키고 보증 비 용을 최소화 시키는 두 개의 제약 사항에 최적화된 소프트웨어 신뢰성 할당을 식별하는 효과적인 기 법을 제안하였다. 성공적인 프로젝트를 위한 소프트웨어 신뢰성 할당은 (1) 전체 소프트웨어 신뢰성 목표, (2) 신뢰성 보증 비용, (3) 일정을 고려해야 한다. 하지만 이 세 가지 요소들은 서로 연관성을 갖기 때문에 하나의 요소를 만족시키기 위해서는 다른 두 요소들을 희생해야 한다. 본 연구는 이 세 가지 요소들을 모두 고려하며 이들 요소들 간의 최적화를 위해 다목적 유전 알고리즘인 NSGA-II를 활용한다. 기존 연구 중 대표적 연구인 Zahedi의 연구와 비교/분석을 해본 결과, 본 연구에서 제시된 기법이 최적으로 여러 개의 소프트웨어 신뢰성 할당 집합을 식별하고 있다는 것을 보여주었다. 본 연 구의 가장 큰 공헌 사항은 다수의 목적을 동시에 충족하는 최적의 소프트웨어 신뢰성 할당을 식별하 는 전략을 제안한 것이며 다수의 목적을 달성하기 위한 소프트웨어 신뢰성 할당 분야의 첫 시도이다. 그리고 프로젝트 관리자가 소프트웨어 신뢰성 할당 과정에서 소프트웨어 신뢰성과 보증 비용을 조정 하는데 도움을 줄 수 있다. - 13 -

Page13

연구 수행 결과 본 연구에서는 소프트웨어 신뢰성 분석/평가를 위해 소프트웨어 개발 초기 단계에서 얻어지는 초기 입력값들을 이용하여 소프트웨어 개발 비용과 초기 소프트웨어 결함 밀도를 예측하고, 예측값들을 이 용하여 대상 소프트웨어가 가질 수 있는 정량적 소프트웨어 신뢰성 목표를 설정하는 방법을 제안하였 다. 이때 소프트웨어 개발 비용 예측을 위해 대표적인 COCOMO II 모델을 기반으로 하였으며, 초기 소프트웨어 결함 밀도 예측을 위해서는 COQUALMO 모델을 활용하였다. 이들 모델은 소프트웨어 개 발 조직의 특성 및 대상 소프트웨어의 목적 및 역할을 잘 반영한 드라이버들을 제공하고 있기 때문 에, 현실적인 소프트웨어 신뢰성 목표를 설정하기에 매우 적합한 모델이다. 또한 본 연구에서 제안된 정량적 소프트웨어 신뢰성 목표 설정 방법을 이용하여 실제 국내 소프트웨어 개발 조직 및 프로젝트 에 적용하여, 제안된 방법이 적절한 신뢰성 목표를 설정하는데 있어 유용한 방법이 될 수 있음을 보 였다. 향후 연구 과제로는 COCOMO II와 COQUALMO 모델 이외에 소프트웨어 신뢰성 예측을 지원하는 다 른 여러 모델들을 특성을 모두 고려한 신뢰성 목표 설정 기법에 관한 연구가 필요하다. 또한 소프트 웨어 개발 과정에서 추가적으로 변경되는 요인, 예를 들어 요구사항 변경에 따른 기능 추가/삭제/수정, 개발 비용의 변화 등을 반영한 신뢰성 목표 설정 기법에 관한 연구를 추가적으로 진행할 예정이다. 2)　다목적 유전자 알고리즘 기반 소프트웨어 모듈에 대한 신뢰성 할당 최적화 연구 수행 내용 전체 소프트웨어 신뢰성은 소프트웨어를 구성하는 하위 모듈들의 상호 작용에 영향을 받기 때문에, 전체 소프트웨어 신뢰성 목표가 설정된 후, 이를 충족시키기 위한 각 하위 모듈들의 신뢰성을 할당하 는 것을 소프트웨어 신뢰성 할당이라고 한다. 본 연구는 소프트웨어 신뢰성을 최대화 시키고 보증 비 용을 최소화 시키는 두 개의 제약 사항에 최적화된 소프트웨어 신뢰성 할당을 식별하는 효과적인 기 법을 제안하였다. 성공적인 프로젝트를 위한 소프트웨어 신뢰성 할당은 (1) 전체 소프트웨어 신뢰성 목표, (2) 신뢰성 보증 비용, (3) 일정을 고려해야 한다. 하지만 이 세 가지 요소들은 서로 연관성을 갖기 때문에 하나의 요소를 만족시키기 위해서는 다른 두 요소들을 희생해야 한다. 본 연구는 이 세 가지 요소들을 모두 고려하며 이들 요소들 간의 최적화를 위해 다목적 유전 알고리즘인 NSGA-II를 활용한다. 기존 연구 중 대표적 연구인 Zahedi의 연구와 비교/분석을 해본 결과, 본 연구에서 제시된 기법이 최적으로 여러 개의 소프트웨어 신뢰성 할당 집합을 식별하고 있다는 것을 보여주었다. 본 연 구의 가장 큰 공헌 사항은 다수의 목적을 동시에 충족하는 최적의 소프트웨어 신뢰성 할당을 식별하 는 전략을 제안한 것이며 다수의 목적을 달성하기 위한 소프트웨어 신뢰성 할당 분야의 첫 시도이다. 그리고 프로젝트 관리자가 소프트웨어 신뢰성 할당 과정에서 소프트웨어 신뢰성과 보증 비용을 조정 하는데 도움을 줄 수 있다. - 13 -

Page14
다목적 유전자 알고리즘 기반 소프트웨어 신뢰성 할당 최적화 본 연구에서는 기존 연구의 한계점, 즉 소프트웨어 신뢰성과 비용 측면이 동시에 최적화 되지 않았다 는 점을 개선하기 위한 소프트웨어 신뢰성 할당 최적화 기법을 제안한다. 비록 소프트웨어 신뢰성 할 당 과정에서 효과적인 자원 활용을 위해 일정의 측면도 고려되어야 하지만, 본 연구에서는 기존 연구 를 개선하는데 초점을 맞추고 차후 연구에서 일정을 고려한 소프트웨어 신뢰성 할당 기법을 제시하도 록 한다. 본 기법은 앞장에서 언급한 바와 같이 다목적 유전 알고리즘인 NSGA-II를 이용하여 최적의 해를 식 별하게 된다. NSGA-II를 소프트웨어 신뢰성 할당 최적화 문제에 적용하기 위해서는 몇 가지 사전 준 비가 요구된다. 우선 염색체가 어떻게 대상 문제의 해를 표현할지를 결정해야 한다. 문제의 해를 표현 하기 위한 염색체 인코딩 방법에는 이진 인코딩, 순열 인코딩, 실수 인코딩, 트리 인코딩 등이 있다. 각각의 인코딩 기법의 특성을 고려하여 소프트웨어 신뢰성 할당 최적화에 적합한 인코딩 기법을 선택 /적용해야 한다. 또한, 유전 알고리즘이 수행되는 과정에서 발생하는 소프트웨어 신뢰성 할당에 대하 여, 소프트웨어 신뢰성과 그 비용이 얼마나 되는지를 평가할 수 있는 적합도 함수의 정의가 필요하다. 소프트웨어 신뢰성 할당을 위한 인코딩 기법 및 적합도 함수 정의 일반적 유전자 알고리즘에 따르면 한 개의 염색체가 대상 문제에 대한 가능한 해를 표현하게 된다. 따라서 전체 소프트웨어를 구성하는 하위 소프트웨어 모듈로 신뢰성 할당을 위한 유전자 알고리즘 적 용을 위해서는 하위 소프트웨어 모듈을 유전자 알고리즘 염색체에 적합하게 인코딩 하는 과정이 필요 하다. 유전자 알고리즘에서 염색체를 인코딩하는 방법에는 이진 인코딩, 순열 인코딩, 실수 인코딩, 트리 인 코딩 등이 있다. 이들 인코딩의 특징은 다음과 같다: ∙이진 인코딩: 매우 간단하며 작은 수의 대립 형질을 표현할 수 있다. ∙순열 인코딩: TSP(Traveling Salesman Person)과 같은 순서가 중요한 문제의 표현에 적합하다. ∙실수 인코딩: 복잡한 대상을 표현하기에 적합하며, 실수로 각 염색체의 유전자를 표현한다. ∙트리 인코딩: 수식이나 프로그램의 구조를 나타내는데 적합한 형태의 인코딩이다. 본 연구에서 각 유전자 알고리즘의 해는 소프트웨어 신뢰성 할당을 표현해야 한다. 즉, 각각의 염색체 는 고정 개수의 유전자를 가지고 있고, 각 유전자는 각 모듈에 할당된 소프트웨어 신뢰성 값을 보유 하고 있어야 한다. 이러한 측면에서, 본 연구에 가장 적합한 인코딩 기법은 실수 인코딩이라는 것을 알 수 있으며, 다음은 이러한 염색체 템플릿을 만들기 위해서는 다음과 같은 절차를 갖는다. (1) 소프트웨어 아키텍처에서 소프트웨어를 구성하는 모듈을 식별한다. (2) 만약 소프트웨어 모듈의 개수가 k개인 경우, k개의 유전자로 구성된 염색체를 만든다. (3) 각 유전자는 [0.1]의 실수 값을 가지며, 이것은 각 하위 소프트웨어 모듈의 소프트웨어 신뢰성 목표 값을 표현한다. - 14 -

Page14

다목적 유전자 알고리즘 기반 소프트웨어 신뢰성 할당 최적화 본 연구에서는 기존 연구의 한계점, 즉 소프트웨어 신뢰성과 비용 측면이 동시에 최적화 되지 않았다 는 점을 개선하기 위한 소프트웨어 신뢰성 할당 최적화 기법을 제안한다. 비록 소프트웨어 신뢰성 할 당 과정에서 효과적인 자원 활용을 위해 일정의 측면도 고려되어야 하지만, 본 연구에서는 기존 연구 를 개선하는데 초점을 맞추고 차후 연구에서 일정을 고려한 소프트웨어 신뢰성 할당 기법을 제시하도 록 한다. 본 기법은 앞장에서 언급한 바와 같이 다목적 유전 알고리즘인 NSGA-II를 이용하여 최적의 해를 식 별하게 된다. NSGA-II를 소프트웨어 신뢰성 할당 최적화 문제에 적용하기 위해서는 몇 가지 사전 준 비가 요구된다. 우선 염색체가 어떻게 대상 문제의 해를 표현할지를 결정해야 한다. 문제의 해를 표현 하기 위한 염색체 인코딩 방법에는 이진 인코딩, 순열 인코딩, 실수 인코딩, 트리 인코딩 등이 있다. 각각의 인코딩 기법의 특성을 고려하여 소프트웨어 신뢰성 할당 최적화에 적합한 인코딩 기법을 선택 /적용해야 한다. 또한, 유전 알고리즘이 수행되는 과정에서 발생하는 소프트웨어 신뢰성 할당에 대하 여, 소프트웨어 신뢰성과 그 비용이 얼마나 되는지를 평가할 수 있는 적합도 함수의 정의가 필요하다. 소프트웨어 신뢰성 할당을 위한 인코딩 기법 및 적합도 함수 정의 일반적 유전자 알고리즘에 따르면 한 개의 염색체가 대상 문제에 대한 가능한 해를 표현하게 된다. 따라서 전체 소프트웨어를 구성하는 하위 소프트웨어 모듈로 신뢰성 할당을 위한 유전자 알고리즘 적 용을 위해서는 하위 소프트웨어 모듈을 유전자 알고리즘 염색체에 적합하게 인코딩 하는 과정이 필요 하다. 유전자 알고리즘에서 염색체를 인코딩하는 방법에는 이진 인코딩, 순열 인코딩, 실수 인코딩, 트리 인 코딩 등이 있다. 이들 인코딩의 특징은 다음과 같다: ∙이진 인코딩: 매우 간단하며 작은 수의 대립 형질을 표현할 수 있다. ∙순열 인코딩: TSP(Traveling Salesman Person)과 같은 순서가 중요한 문제의 표현에 적합하다. ∙실수 인코딩: 복잡한 대상을 표현하기에 적합하며, 실수로 각 염색체의 유전자를 표현한다. ∙트리 인코딩: 수식이나 프로그램의 구조를 나타내는데 적합한 형태의 인코딩이다. 본 연구에서 각 유전자 알고리즘의 해는 소프트웨어 신뢰성 할당을 표현해야 한다. 즉, 각각의 염색체 는 고정 개수의 유전자를 가지고 있고, 각 유전자는 각 모듈에 할당된 소프트웨어 신뢰성 값을 보유 하고 있어야 한다. 이러한 측면에서, 본 연구에 가장 적합한 인코딩 기법은 실수 인코딩이라는 것을 알 수 있으며, 다음은 이러한 염색체 템플릿을 만들기 위해서는 다음과 같은 절차를 갖는다. (1) 소프트웨어 아키텍처에서 소프트웨어를 구성하는 모듈을 식별한다. (2) 만약 소프트웨어 모듈의 개수가 k개인 경우, k개의 유전자로 구성된 염색체를 만든다. (3) 각 유전자는 [0.1]의 실수 값을 가지며, 이것은 각 하위 소프트웨어 모듈의 소프트웨어 신뢰성 목표 값을 표현한다. - 14 -

Page15
본 방법론에서 소프트웨어 아키텍처는 소프트웨어를 구성하고 있는 모듈의 개수를 추출하는데 사용된 다. 아키텍처의 구체적인 속성을 이용하여 소프트웨어 신뢰성을 설계 단계에 추정하는 모델들이 존재 하지만, 본 연구에서는 테스팅 단계의 소프트웨어 신뢰성 보증 활동만을 고려하고 있다. 따라서 테스 팅 단계에 신뢰성 평가에 사용되는 모델은 개발 조직의 과거 결함 데이터를 기반으로 통계적으로 신 뢰성을 추정하기 때문에, 구체적인 소프트웨어 아키텍처 속성이 요구되지 않는다. 또한 적함도 함수란 각 염색체가 문제의 목적에 얼마나 부합하는지를 나타내주는 함수이다. 유전 알 고리즘이 동작되는 과정에서 염색체를 선택해야 되는 순간에 어떤 염색체가 더욱 우수한 성질을 가지 고 있는지 평가할 필요가 있다. 본 연구에서는 하나의 염색체가 소프트웨어 신뢰성 할당을 대표하고 있으며, 적합도 함수는 대상 소프트웨어 신뢰성 할당이 달성하는 전체 소프트웨어 시스템 신뢰성과 그 보증 비용을 평가하는데 사용된다. 유전자 알고리즘의 장점은 각 프로젝트에 적합한 적합도 함수 를 유동적으로 정의할 수 있다는 것이다. 기존의 방법론에서는 특정한 소프트웨어 신뢰성 및 그 보증 활동 비용을 평가하는 모델을 결정하면, 그 모델에 특화된 방법으로 최적의 해를 구한다. 반면 본 방 법론에서는 유전자 알고리즘을 활용함으로써 어떠한 형태의 소프트웨어 신뢰성 모델과 신뢰성 보증 활동 비용 모델을 사용하더라도 문제를 바로 적용시킬 수 있다는 장점을 가지고 있다. 예를 들어서 소프트웨어 신뢰성 할당이 모두 끝났다고 가정했을 때, 각 소프트웨어 모듈에 대한 소프트웨어 신뢰 성 목표가 설정된다. 이 때 Goel-Okumoto모델을 이용하여 각 모듈별로 신뢰성 목표를 달성하는데 걸리는 시간을 구할 수 있다. 그리고 각각의 모듈에 투입되는 시간을 가산 신뢰성 모델의 입력으로 넣으면 전체 소프트웨어 시스템의 신뢰성을 구할 수 있게 된다. 반면 Goel-Okumoto 모델을 기반으로 소프트웨어 신뢰성을 평가하는 경우, 소프트웨어 신뢰성 보증 비용은 테스팅 단계에서 발견되는 결함 수에 비례한다고 할 수 있다. 이 모델에서는 각 결함이 발견 되는 즉시 제거된다는 가정을 두고 있기 때문에, 테스팅 과정에서 발견되는 결함 수를 Goel-Okumoto 모델을 이용하여 구하고, 그 개수에 개발 조직의 과거 데이터를 이용하여 구해진 결 함당 단가를 곱해줌으로써 전체 비용을 구할 수 있게 된다. 사례 연구를 통한 검증 본 사례 연구에서는 기존 연구 중 대표적 연구인 Zahedi의 연구와 비교한다. Zahedi 연구에서 사용된 대상 시스템을 그대로 활용하였다. 그러므로 Zahedi의 연구에서 사용된 대상 시스템을 간략히 소개하 고 본 연구 내용을 적용한다. 그리고 분석을 통해 본 연구에서 제안된 기법이 소프트웨어 신뢰성과 비용, 그리고 시간을 적절히 조정할 수 있는 최적의 소프트웨어 신뢰성 할당 집합을 식별하는 과정을 보여준다. Zahedi의 연구에서 사용된 대상 시스템에서, 각 모듈의 소프트웨어 신뢰성 범위는 0.5에서 1.0이라고 가정한다. 그리고 각 소프트웨어 모듈에 대한 예산이 할당되어 있고, 현재 상황에서 가용한 금액이 식별되어 있다. 본 연구내용을 대상 시스템에 적용하기 위해 우선, 소프트웨어 시스템이 6개의 모듈로 구성되어 있기 - 15 -

Page15

본 방법론에서 소프트웨어 아키텍처는 소프트웨어를 구성하고 있는 모듈의 개수를 추출하는데 사용된 다. 아키텍처의 구체적인 속성을 이용하여 소프트웨어 신뢰성을 설계 단계에 추정하는 모델들이 존재 하지만, 본 연구에서는 테스팅 단계의 소프트웨어 신뢰성 보증 활동만을 고려하고 있다. 따라서 테스 팅 단계에 신뢰성 평가에 사용되는 모델은 개발 조직의 과거 결함 데이터를 기반으로 통계적으로 신 뢰성을 추정하기 때문에, 구체적인 소프트웨어 아키텍처 속성이 요구되지 않는다. 또한 적함도 함수란 각 염색체가 문제의 목적에 얼마나 부합하는지를 나타내주는 함수이다. 유전 알 고리즘이 동작되는 과정에서 염색체를 선택해야 되는 순간에 어떤 염색체가 더욱 우수한 성질을 가지 고 있는지 평가할 필요가 있다. 본 연구에서는 하나의 염색체가 소프트웨어 신뢰성 할당을 대표하고 있으며, 적합도 함수는 대상 소프트웨어 신뢰성 할당이 달성하는 전체 소프트웨어 시스템 신뢰성과 그 보증 비용을 평가하는데 사용된다. 유전자 알고리즘의 장점은 각 프로젝트에 적합한 적합도 함수 를 유동적으로 정의할 수 있다는 것이다. 기존의 방법론에서는 특정한 소프트웨어 신뢰성 및 그 보증 활동 비용을 평가하는 모델을 결정하면, 그 모델에 특화된 방법으로 최적의 해를 구한다. 반면 본 방 법론에서는 유전자 알고리즘을 활용함으로써 어떠한 형태의 소프트웨어 신뢰성 모델과 신뢰성 보증 활동 비용 모델을 사용하더라도 문제를 바로 적용시킬 수 있다는 장점을 가지고 있다. 예를 들어서 소프트웨어 신뢰성 할당이 모두 끝났다고 가정했을 때, 각 소프트웨어 모듈에 대한 소프트웨어 신뢰 성 목표가 설정된다. 이 때 Goel-Okumoto모델을 이용하여 각 모듈별로 신뢰성 목표를 달성하는데 걸리는 시간을 구할 수 있다. 그리고 각각의 모듈에 투입되는 시간을 가산 신뢰성 모델의 입력으로 넣으면 전체 소프트웨어 시스템의 신뢰성을 구할 수 있게 된다. 반면 Goel-Okumoto 모델을 기반으로 소프트웨어 신뢰성을 평가하는 경우, 소프트웨어 신뢰성 보증 비용은 테스팅 단계에서 발견되는 결함 수에 비례한다고 할 수 있다. 이 모델에서는 각 결함이 발견 되는 즉시 제거된다는 가정을 두고 있기 때문에, 테스팅 과정에서 발견되는 결함 수를 Goel-Okumoto 모델을 이용하여 구하고, 그 개수에 개발 조직의 과거 데이터를 이용하여 구해진 결 함당 단가를 곱해줌으로써 전체 비용을 구할 수 있게 된다. 사례 연구를 통한 검증 본 사례 연구에서는 기존 연구 중 대표적 연구인 Zahedi의 연구와 비교한다. Zahedi 연구에서 사용된 대상 시스템을 그대로 활용하였다. 그러므로 Zahedi의 연구에서 사용된 대상 시스템을 간략히 소개하 고 본 연구 내용을 적용한다. 그리고 분석을 통해 본 연구에서 제안된 기법이 소프트웨어 신뢰성과 비용, 그리고 시간을 적절히 조정할 수 있는 최적의 소프트웨어 신뢰성 할당 집합을 식별하는 과정을 보여준다. Zahedi의 연구에서 사용된 대상 시스템에서, 각 모듈의 소프트웨어 신뢰성 범위는 0.5에서 1.0이라고 가정한다. 그리고 각 소프트웨어 모듈에 대한 예산이 할당되어 있고, 현재 상황에서 가용한 금액이 식별되어 있다. 본 연구내용을 대상 시스템에 적용하기 위해 우선, 소프트웨어 시스템이 6개의 모듈로 구성되어 있기 - 15 -

Page16
때문에 염색체를 구성하는 유전자의 개수는 총 6개가 된다. 이렇게 식별된 모듈의 개수를 유전자 알 고리즘의 내부 구현에 반영하도록 한다. 소프트웨어 신뢰성 모델과 이 모델로부터 구해지는 발생 결 함 개수에 결함당 제거 단가를 곱하는 방법으로 각 염색체가 성취할 수 있는 소프트웨어 신뢰성 목표 와 그 보증 비용을 평가하기 위한 적합도 함수를 정의한다. 처음 알고리즘을 수행하면 모집단의 크기만큼 염색체가 생성된다. 이 때 각 염색체의 유전자는 0과 1 사이의 임의의 실수 값을 가지며, 이것은 각각의 모듈들의 소프트웨어 신뢰성 목표가 된다. 이렇게 생 성된 모집단이 선택/교차/돌연변이 연산을 반복하면서 소프트웨어 신뢰성을 최대화 하면서 비용을 최 소화 시키는 목표에 가까운 염색체들로 구성된 집단으로 진화해 나가게 된다. 그리고 그 결과로써 요 구사항을 만족하면서 위 두 목적에 적합한 소프트웨어 신뢰성 할당을 구할 수 있게 된다. 본 연구를 적용하여 얻은 결과는 표 2에 정리되어 있다. 이 표에서 R1부터 R6는 각각의 모듈에 할당 된 소프트웨어 신뢰성 목표를 의미한다. 예를 들어, 표 2의첫 번째 할당의 경우 각각의 모듈에 대한 소프트웨어 신뢰성 목표는 모두 99%로 설정되어 있으며, 이것은 테스팅 과정에서 결함을 발견하고 제거하는 활동을 통해 개선하기 위한 기준으로 사용된다. 또한, 신뢰성 유용성은 각 모듈에 할당된 소 프트웨어 신뢰성을 모두 만족했을 때 대상 소프트웨어 시스템의 신뢰성이 얼마나 큰지를 나타내주는 지표이며, 비용은 소프트웨어 신뢰성 보증에 소용되는 총 비용을 의미한다. 총 100개의 소프트웨어 신뢰성 할당이 식별되었으며, 여기에서 100개는 본 기법이 적용될 때 사용된 모집단의 크기이다. [그림 5] 결과 산점도 - 16 -

Page16

때문에 염색체를 구성하는 유전자의 개수는 총 6개가 된다. 이렇게 식별된 모듈의 개수를 유전자 알 고리즘의 내부 구현에 반영하도록 한다. 소프트웨어 신뢰성 모델과 이 모델로부터 구해지는 발생 결 함 개수에 결함당 제거 단가를 곱하는 방법으로 각 염색체가 성취할 수 있는 소프트웨어 신뢰성 목표 와 그 보증 비용을 평가하기 위한 적합도 함수를 정의한다. 처음 알고리즘을 수행하면 모집단의 크기만큼 염색체가 생성된다. 이 때 각 염색체의 유전자는 0과 1 사이의 임의의 실수 값을 가지며, 이것은 각각의 모듈들의 소프트웨어 신뢰성 목표가 된다. 이렇게 생 성된 모집단이 선택/교차/돌연변이 연산을 반복하면서 소프트웨어 신뢰성을 최대화 하면서 비용을 최 소화 시키는 목표에 가까운 염색체들로 구성된 집단으로 진화해 나가게 된다. 그리고 그 결과로써 요 구사항을 만족하면서 위 두 목적에 적합한 소프트웨어 신뢰성 할당을 구할 수 있게 된다. 본 연구를 적용하여 얻은 결과는 표 2에 정리되어 있다. 이 표에서 R1부터 R6는 각각의 모듈에 할당 된 소프트웨어 신뢰성 목표를 의미한다. 예를 들어, 표 2의첫 번째 할당의 경우 각각의 모듈에 대한 소프트웨어 신뢰성 목표는 모두 99%로 설정되어 있으며, 이것은 테스팅 과정에서 결함을 발견하고 제거하는 활동을 통해 개선하기 위한 기준으로 사용된다. 또한, 신뢰성 유용성은 각 모듈에 할당된 소 프트웨어 신뢰성을 모두 만족했을 때 대상 소프트웨어 시스템의 신뢰성이 얼마나 큰지를 나타내주는 지표이며, 비용은 소프트웨어 신뢰성 보증에 소용되는 총 비용을 의미한다. 총 100개의 소프트웨어 신뢰성 할당이 식별되었으며, 여기에서 100개는 본 기법이 적용될 때 사용된 모집단의 크기이다. [그림 5] 결과 산점도 - 16 -

Page17
본 기법의 적용 결과를 보여주는 산점도는 그림 5에 나타나 있다. 이 산점도는 그림 6에 나타나 있는 각각의 신뢰성 할당을 신뢰성 보증 비용을 나타내는 X축과 신뢰성을 나타내는 Y축을 가지는 좌표에 나타낸 것이다. 즉, X축에서 우측으로 갈수록 대상 신뢰성 보증 비용은 커지는 것이며, Y축에서 위로 갈수록 신뢰성 값은 더욱 커지게 된다. 본 그림에서 높은 신뢰성을 위해서 높은 보증 비용이 필요함 을 알 수 있으며, 우리의 기법의 해가 높은 신뢰성 값을 가지는 해를 찾으면서 동시에 비용을 낮추는 방향으로 나아간다는 것을 알 수 있다. 이때 본 연구에서 구하게 된 여러 해 중, 가장 최적의 해는 98.2%의 소프트웨어 신뢰성 목표를 달성하면서 $232,317의 보증 비용을 소요하게 된다. 이것은 Zahedi의 연구에서 얻은 결과인 97.6%의 소프트웨어 신뢰성 목표 달성과 그 보증비용 $233,505보다 높은 소프트웨어 신뢰성을 가지면서 낮은 보증 비용을 갖고 있다. 이 때문에 본 연구에서 제안하는 기법이 기존의 연구보다 두 목적에 더욱 최적화된 소프트웨어 신뢰성 할당을 식별한다고 볼 수 있다. [그림 6] 식별된 소프트웨어 신뢰성 할당 결과 본 사례 연구는 어떤 종류의 소프트웨어 신뢰성 모델과 보증 비용 모델을 사용할 수 있기 때문에 제 안된 기법이 여러 프로젝트에 쉽게 적용될 수 있다는 것을 보여준다. 이 결과의 가장 중요한 시사점 은 본 연구가 100개의 소프트웨어 신뢰성 할당을 식별했다는 것이다. 비록 [0.99, 0.55, 0.99, 0.99, 0.53, 0.99]와 같이 신뢰도가 낮고 보증 비용이 높은 유용하지 않은 신뢰성 할당이 존재하긴 하지만, 대부분의 소프트웨어 신뢰성 할당은 동시에 다수의 제약 사항에 최적화 되어 있다. 소프트웨어 신뢰 성과 보증 비용은 서로 상충하는 관계에 있기 때문에, 소프트웨어 신뢰성이 가장 높고 보증 비용이 가장 낮은 해가 존재할 수 없다. 하지만, 본 연구에서 제시된 기법은 최적으로 여러 개의 소프트웨어 - 17 -

Page17

본 기법의 적용 결과를 보여주는 산점도는 그림 5에 나타나 있다. 이 산점도는 그림 6에 나타나 있는 각각의 신뢰성 할당을 신뢰성 보증 비용을 나타내는 X축과 신뢰성을 나타내는 Y축을 가지는 좌표에 나타낸 것이다. 즉, X축에서 우측으로 갈수록 대상 신뢰성 보증 비용은 커지는 것이며, Y축에서 위로 갈수록 신뢰성 값은 더욱 커지게 된다. 본 그림에서 높은 신뢰성을 위해서 높은 보증 비용이 필요함 을 알 수 있으며, 우리의 기법의 해가 높은 신뢰성 값을 가지는 해를 찾으면서 동시에 비용을 낮추는 방향으로 나아간다는 것을 알 수 있다. 이때 본 연구에서 구하게 된 여러 해 중, 가장 최적의 해는 98.2%의 소프트웨어 신뢰성 목표를 달성하면서 $232,317의 보증 비용을 소요하게 된다. 이것은 Zahedi의 연구에서 얻은 결과인 97.6%의 소프트웨어 신뢰성 목표 달성과 그 보증비용 $233,505보다 높은 소프트웨어 신뢰성을 가지면서 낮은 보증 비용을 갖고 있다. 이 때문에 본 연구에서 제안하는 기법이 기존의 연구보다 두 목적에 더욱 최적화된 소프트웨어 신뢰성 할당을 식별한다고 볼 수 있다. [그림 6] 식별된 소프트웨어 신뢰성 할당 결과 본 사례 연구는 어떤 종류의 소프트웨어 신뢰성 모델과 보증 비용 모델을 사용할 수 있기 때문에 제 안된 기법이 여러 프로젝트에 쉽게 적용될 수 있다는 것을 보여준다. 이 결과의 가장 중요한 시사점 은 본 연구가 100개의 소프트웨어 신뢰성 할당을 식별했다는 것이다. 비록 [0.99, 0.55, 0.99, 0.99, 0.53, 0.99]와 같이 신뢰도가 낮고 보증 비용이 높은 유용하지 않은 신뢰성 할당이 존재하긴 하지만, 대부분의 소프트웨어 신뢰성 할당은 동시에 다수의 제약 사항에 최적화 되어 있다. 소프트웨어 신뢰 성과 보증 비용은 서로 상충하는 관계에 있기 때문에, 소프트웨어 신뢰성이 가장 높고 보증 비용이 가장 낮은 해가 존재할 수 없다. 하지만, 본 연구에서 제시된 기법은 최적으로 여러 개의 소프트웨어 - 17 -

Page18
신뢰성 할당 집합을 식별하고 있다. 이것은 프로젝트 관리자가 절충된 소프트웨어 신뢰성 할당을 선 택할 수 있도록 도울 수 있다. 연구 수행 결과 본 연구는 소프트웨어 신뢰성을 최대화 시키고 보증 비용을 최소화 시키는 두 개의 제약 사항에 최적 화된 소프트웨어 신뢰성 할당을 식별하는 효과적인 기법을 제안한다. 기존의 연구는 소프트웨어 신뢰 성을 최대화 시키거나 그 보증 비용을 최소화 시키는 하나의 목표에 최적화 시키는 소프트웨어 신뢰 성 할당을 제안해 왔다. 만약 프로젝트의 목표가 명확한 경우 기존 연구가 유용하게 사용될 수 있다. 하지만 소프트웨어 신뢰성 목표와 보증 비용이 완벽하지 않을 때 기존의 연구는 실용성에 한계가 있 을 수 있다. 본 연구의 가장 큰 공헌 사항은 다수의 목적을 동시에 충족하는 최적의 소프트웨어 신뢰성 할당을 식 별하는 전략을 제안한 것이다. 이것은 프로젝트 관리자가 소프트웨어 신뢰성 할당 과정에서 소프트웨 어 신뢰성과 보증 비용을 조정하는데 도움을 줄 수 있다. 프로젝트 관리자는 또한 최적의 소프트웨어 구조와 효과적인 시험 전략을 식별하는데 도움을 줄 수 있다. 또한 본 연구는 다수의 목적을 달성하 기 위한 소프트웨어 신뢰성 할당 분야의 첫 시도이다. 즉, 본 연구는 다수의 목적을 달성하기 위한 소 프트웨어 신뢰성 할당의 기반을 제공한다. 차후 연구에서 본 방법론에서 일정을 어떻게 다뤄야 하는지에 대한 연구를 수행할 것이다. 앞으로 본 방법론이 실제 프로젝트에 적용하여 그 결과를 제시하고, 프로젝트 일정을 적용시키는 연구로 확장하 도록 한다. 또한 유전 알고리즘에서 최적해(Global Optima)에 접근하기 전 근접해(Local Optima)에서 그 실행이 종료되는 경우 적절한 최적화를 달성하기 어렵다고 볼 수 있다. 따라서 이러한 근접해를 최적해로 제시하는 부분에 대해 조금 더 심도 있는 고찰과 그 해결책을 제시하는 연구가 필요하다. 3) 국방 도메인에서 소프트웨어 비용 추정 모델링 프로세스의 경험적 연구 신뢰성 목표 설정에는 개발 비용 요소도 고려가 되어야 한다. 소프트웨어 개발 비용의 정확한 추정 은 국방 도메인에서 매우 중요하지만 현존하는 소프트웨어 비용 추정 모델과 도구들은 정확성 측면에 서 문제점을 가지고 있다. 이 논문에서는 이러한 문제점을 해결하기 위해 다음과 같은 research question을 갖는다. - 포괄적인 도메인으로부터 특정 도메인 필드(국방 도메인)를 구분 짓기 위한 소프트웨어 개발 환경 의 특유의 요소는 무엇인가? - 만일 이러한 요소들이 구분지어 진다면, 기존의 모델링 프로세스를 적용하여 이러한 요소들을 반영 한 모델의 개발이 가능한가? - 만일 모델의 개발이 불가능하다면, 국방 도메인의 특징을 반영한 프로세스를 개발할 수 있는가? - 만일 제안된 프로세스가 비용 예측 모델의 개발에 적용된다면 모델의 정확성은 얼마나 되는가? 즉, - 18 -

Page18

신뢰성 할당 집합을 식별하고 있다. 이것은 프로젝트 관리자가 절충된 소프트웨어 신뢰성 할당을 선 택할 수 있도록 도울 수 있다. 연구 수행 결과 본 연구는 소프트웨어 신뢰성을 최대화 시키고 보증 비용을 최소화 시키는 두 개의 제약 사항에 최적 화된 소프트웨어 신뢰성 할당을 식별하는 효과적인 기법을 제안한다. 기존의 연구는 소프트웨어 신뢰 성을 최대화 시키거나 그 보증 비용을 최소화 시키는 하나의 목표에 최적화 시키는 소프트웨어 신뢰 성 할당을 제안해 왔다. 만약 프로젝트의 목표가 명확한 경우 기존 연구가 유용하게 사용될 수 있다. 하지만 소프트웨어 신뢰성 목표와 보증 비용이 완벽하지 않을 때 기존의 연구는 실용성에 한계가 있 을 수 있다. 본 연구의 가장 큰 공헌 사항은 다수의 목적을 동시에 충족하는 최적의 소프트웨어 신뢰성 할당을 식 별하는 전략을 제안한 것이다. 이것은 프로젝트 관리자가 소프트웨어 신뢰성 할당 과정에서 소프트웨 어 신뢰성과 보증 비용을 조정하는데 도움을 줄 수 있다. 프로젝트 관리자는 또한 최적의 소프트웨어 구조와 효과적인 시험 전략을 식별하는데 도움을 줄 수 있다. 또한 본 연구는 다수의 목적을 달성하 기 위한 소프트웨어 신뢰성 할당 분야의 첫 시도이다. 즉, 본 연구는 다수의 목적을 달성하기 위한 소 프트웨어 신뢰성 할당의 기반을 제공한다. 차후 연구에서 본 방법론에서 일정을 어떻게 다뤄야 하는지에 대한 연구를 수행할 것이다. 앞으로 본 방법론이 실제 프로젝트에 적용하여 그 결과를 제시하고, 프로젝트 일정을 적용시키는 연구로 확장하 도록 한다. 또한 유전 알고리즘에서 최적해(Global Optima)에 접근하기 전 근접해(Local Optima)에서 그 실행이 종료되는 경우 적절한 최적화를 달성하기 어렵다고 볼 수 있다. 따라서 이러한 근접해를 최적해로 제시하는 부분에 대해 조금 더 심도 있는 고찰과 그 해결책을 제시하는 연구가 필요하다. 3) 국방 도메인에서 소프트웨어 비용 추정 모델링 프로세스의 경험적 연구 신뢰성 목표 설정에는 개발 비용 요소도 고려가 되어야 한다. 소프트웨어 개발 비용의 정확한 추정 은 국방 도메인에서 매우 중요하지만 현존하는 소프트웨어 비용 추정 모델과 도구들은 정확성 측면에 서 문제점을 가지고 있다. 이 논문에서는 이러한 문제점을 해결하기 위해 다음과 같은 research question을 갖는다. - 포괄적인 도메인으로부터 특정 도메인 필드(국방 도메인)를 구분 짓기 위한 소프트웨어 개발 환경 의 특유의 요소는 무엇인가? - 만일 이러한 요소들이 구분지어 진다면, 기존의 모델링 프로세스를 적용하여 이러한 요소들을 반영 한 모델의 개발이 가능한가? - 만일 모델의 개발이 불가능하다면, 국방 도메인의 특징을 반영한 프로세스를 개발할 수 있는가? - 만일 제안된 프로세스가 비용 예측 모델의 개발에 적용된다면 모델의 정확성은 얼마나 되는가? 즉, - 18 -

Page19
제안된 프로세스가 얼마나 적합한가? 본 연구에서는 이러한 research question을 기반으로 포괄적인 도메인으로부터 국방 도메인을 구체화 할 수 있는 특유의 요소들을 구별하였다. 이를 통해 MND-SCEMP라는 한국 국방 도메인에 적합한 프 로세스를 제시하였으며 또한 비용 예측에 영향을 미치는 여러 factor들을 반영하여 기존에 존재하던 소 프트웨어 비용 예측 모델링 프로세스들의 단점인 ‘국방 도메인에서의 부정확한 예측’을 개선하였다. 100여개의 국내 무기 관련 프로젝트를 통한 Empirical study를 수행함으로써 제안하는 MND-SCEMP 이 한국 국방 도메인에 적합함을 객관적으로 증명하였다. 프로젝트 매니저들은 MND-SCEMP를 이용 하여 더욱 정확한 리소스 예측이 가능하며 이를 통해 성공적인 프로젝트 수행이 가능할 것으로 기대된 다 [9]. MND-SCEMP 이 논문에서 제시하는 MND-SCEMP는 기존의 소프트웨어 비용 예측 모델인 COCOMO II의 7 단계 모델링 방법과 Bailey 와 Basili가 제시한 meta-model을 결합하여 확장한 모델이다. COCOMO II의 7 단계 모델링 방법은 일반적이고 추상적인 도메인을 대상으로 구성된 방법이다. MND-SCEMP는 COCOMO II 의 7단계 모델링 방법 중 국방 도메인의 특성을 고려하여 이에 필요치 않은 단계를 제외 한 4가지 메인 프로세스 (Domain Analysis, Model Deduction, Use Model, Refine Model)로 구성된 다. MND-SCEMP의 각 단계는 연속적 혹은 동시다발적으로 수행되며 필요에 따라 이전 단계의 활동 이 다시 요구될 경우 이는 반복적으로 수행될 수 있다. 아래는 이러한 MND-SCEMP의 기본 전략을 나타내는 그림이다. [그림 7] 국방 도메인에서의 MND-SCEMP의 기본 전략 - 19 -

Page19

제안된 프로세스가 얼마나 적합한가? 본 연구에서는 이러한 research question을 기반으로 포괄적인 도메인으로부터 국방 도메인을 구체화 할 수 있는 특유의 요소들을 구별하였다. 이를 통해 MND-SCEMP라는 한국 국방 도메인에 적합한 프 로세스를 제시하였으며 또한 비용 예측에 영향을 미치는 여러 factor들을 반영하여 기존에 존재하던 소 프트웨어 비용 예측 모델링 프로세스들의 단점인 ‘국방 도메인에서의 부정확한 예측’을 개선하였다. 100여개의 국내 무기 관련 프로젝트를 통한 Empirical study를 수행함으로써 제안하는 MND-SCEMP 이 한국 국방 도메인에 적합함을 객관적으로 증명하였다. 프로젝트 매니저들은 MND-SCEMP를 이용 하여 더욱 정확한 리소스 예측이 가능하며 이를 통해 성공적인 프로젝트 수행이 가능할 것으로 기대된 다 [9]. MND-SCEMP 이 논문에서 제시하는 MND-SCEMP는 기존의 소프트웨어 비용 예측 모델인 COCOMO II의 7 단계 모델링 방법과 Bailey 와 Basili가 제시한 meta-model을 결합하여 확장한 모델이다. COCOMO II의 7 단계 모델링 방법은 일반적이고 추상적인 도메인을 대상으로 구성된 방법이다. MND-SCEMP는 COCOMO II 의 7단계 모델링 방법 중 국방 도메인의 특성을 고려하여 이에 필요치 않은 단계를 제외 한 4가지 메인 프로세스 (Domain Analysis, Model Deduction, Use Model, Refine Model)로 구성된 다. MND-SCEMP의 각 단계는 연속적 혹은 동시다발적으로 수행되며 필요에 따라 이전 단계의 활동 이 다시 요구될 경우 이는 반복적으로 수행될 수 있다. 아래는 이러한 MND-SCEMP의 기본 전략을 나타내는 그림이다. [그림 7] 국방 도메인에서의 MND-SCEMP의 기본 전략 - 19 -

Page21
Model validation 9.1 Select the data for validation9.2 Establish the criteria for cost estimation model validation9.3 Validate the cost estimation model using selected data Use the model and collect 10.1 Select a project to be applied the modeladditional data 10.2 Execute the cost estimation10.3 Data collection on the project10.4 Comparison between estimated values and real values periodically10.5 Make sure that the assumptions of developed model comply with real situation continuously10.6 Comparison between final cost and estimated values10.7 Identify the reason of errors Model revision 11.1 Identify the requirements for the revision of the cost estimation model11.2 Select a method for cost estimation model revision (optional)11.3 Revise the model using the selected methodology (optional) 나. 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발 1) 신뢰성 프로세스 개발을 위한 관련 표준 연구 내장형 소프트웨어 신뢰성 프로세스 개발을 위한 관련 표준으로는 크게 제품의 신뢰성 개선을 위한 표준과 프로세스 품질 개선을 위한 표준으로 구분하여 연구를 수행한다. 그러므로 제품의 신뢰성 개선 을 위한 표준으로는 IEEE 982 (Standard Dictionary of Measures to Produce Reliable Software), ISO 9126 (Software Quality Model), ISO 14598 (Software Product Evaluation), ISO 12119 (Software Packages - Quality Requirement & Testing) 등이 있으며, 최근에는 ISO 25000 시리즈에 이러한 표준이 통합되고 있는 추세이다. 두 번째로 프로세스 품질 개선을 위한 표준으로는 소프트웨어 개발 프로세스에 중점을 두고 있는 ISO 12207과 프로세스 성숙도 평가를 위해 유럽에서 주로 사용되 고 있는 ISO 15504 (SPICE, Software Process Improvement Capability dEtermination), 미국 중심으 로 주로 사용하는 CMM (Capability Mutirity Model), CMMI (Capability Muturity Model Integration), 그리고 테스트 프로세스 성숙도를 위한 TMM (Testing Maturity Model) 및 TMMI (Testing Maturity Model Integration)이 있다. 또한 소프트웨어의 비기능 요소인 신뢰성을 보증하기 위한 권장 활동의 표준으로 IEEE 1633 (Recommended Practice on Software Reliability)와 내장형 소프트웨어의 안전성에 관한 표준인 IEC 61508-3 (Functional Safety of Software)가 있다. 미국 국방 소프트웨어 프로세스 표준의 변화 미국 국방 소프트웨어 표준은 시대의 흐름과 개발 방법의 변화에 따라 진화의 과정을 거쳤으며 이러 한 과정을 통해 현재의 IEEE/EIA 12207이 개발되었다. DoD 소프트웨어 개발에 영향을 미친 표준의 진화 과정을 살펴보면 아래와 같이 연도별로 정리될 수 있다. 우선 MIL-STD-498에 대해 파악한 뒤, IEEE/EIA 12207까지 어떻게 진화하여 왔는지를 살펴본다. MIL-STD-498는 미 군사규격으로 - 21 -

Page21

Model validation 9.1 Select the data for validation9.2 Establish the criteria for cost estimation model validation9.3 Validate the cost estimation model using selected data Use the model and collect 10.1 Select a project to be applied the modeladditional data 10.2 Execute the cost estimation10.3 Data collection on the project10.4 Comparison between estimated values and real values periodically10.5 Make sure that the assumptions of developed model comply with real situation continuously10.6 Comparison between final cost and estimated values10.7 Identify the reason of errors Model revision 11.1 Identify the requirements for the revision of the cost estimation model11.2 Select a method for cost estimation model revision (optional)11.3 Revise the model using the selected methodology (optional) 나. 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스 개발 1) 신뢰성 프로세스 개발을 위한 관련 표준 연구 내장형 소프트웨어 신뢰성 프로세스 개발을 위한 관련 표준으로는 크게 제품의 신뢰성 개선을 위한 표준과 프로세스 품질 개선을 위한 표준으로 구분하여 연구를 수행한다. 그러므로 제품의 신뢰성 개선 을 위한 표준으로는 IEEE 982 (Standard Dictionary of Measures to Produce Reliable Software), ISO 9126 (Software Quality Model), ISO 14598 (Software Product Evaluation), ISO 12119 (Software Packages - Quality Requirement & Testing) 등이 있으며, 최근에는 ISO 25000 시리즈에 이러한 표준이 통합되고 있는 추세이다. 두 번째로 프로세스 품질 개선을 위한 표준으로는 소프트웨어 개발 프로세스에 중점을 두고 있는 ISO 12207과 프로세스 성숙도 평가를 위해 유럽에서 주로 사용되 고 있는 ISO 15504 (SPICE, Software Process Improvement Capability dEtermination), 미국 중심으 로 주로 사용하는 CMM (Capability Mutirity Model), CMMI (Capability Muturity Model Integration), 그리고 테스트 프로세스 성숙도를 위한 TMM (Testing Maturity Model) 및 TMMI (Testing Maturity Model Integration)이 있다. 또한 소프트웨어의 비기능 요소인 신뢰성을 보증하기 위한 권장 활동의 표준으로 IEEE 1633 (Recommended Practice on Software Reliability)와 내장형 소프트웨어의 안전성에 관한 표준인 IEC 61508-3 (Functional Safety of Software)가 있다. 미국 국방 소프트웨어 프로세스 표준의 변화 미국 국방 소프트웨어 표준은 시대의 흐름과 개발 방법의 변화에 따라 진화의 과정을 거쳤으며 이러 한 과정을 통해 현재의 IEEE/EIA 12207이 개발되었다. DoD 소프트웨어 개발에 영향을 미친 표준의 진화 과정을 살펴보면 아래와 같이 연도별로 정리될 수 있다. 우선 MIL-STD-498에 대해 파악한 뒤, IEEE/EIA 12207까지 어떻게 진화하여 왔는지를 살펴본다. MIL-STD-498는 미 군사규격으로 - 21 -

Page22
소프트웨어 개발 및 문서화에 대한 단일화 된 요구조건을 정립하는 목적으로 제정되었다. 1994년 11 월에 공표되었으며, DOD-STD-2167A, DOD-STD-7935A 등을 대체(replace)하였다. 이 규격은 당 초부터 상용규격이 제정되기까지 약 2년 동안만 적용할 예정이었으며, 1998년 5월 J-STD-016과 IEEE 12207로 대체되면서 취소되었다. 하지만 이 규격은 표준화된 문서가 무료로 공개되어 있어 미 군 이외의 분야에서 수행하는 사업에는 그 후에도 지속적으로 사용되었다. MIL-STD-498에서는 22 개의 산출물을 요구하고 있으며, 각 산출물들의 표준양식 및 포함되어야 할 내용들을 Data Item Description이라는 문서에 정의하였으며, 이것이 이 규격의 핵심이라고 할 수 있다. IEEE/EIA 12207(Standard for InformationTechnology-Software Life Cycle Processes)은 소프트웨어 생명주 기 프로세스의 일반적인 프레임워크(framework)를 규정하는 규격으로서 1998년 8월에 공표되었다. <미국 국방 소프트웨어 표준의 연도별 진화 과정> 표준 설 명 년도MIL-STD-1679 Software Development 1983ADOD-STD-2167 Defense System Software Development 1988ADOD-STD-7935 AIS Documentation Standards 1988A Software Development and MIL-STD-498 1994Documentation 1991ISO 9000 series - on Quality Management, etc. -J-STD-016-19 Software Development 199595 -Acquirer-Supplier AgreementInformation Technology - Software LifeISO/IEC 12207 1996Cycle ProcessesIEEE/EIA 12207 Software Life Cycle Processes 1998 12207 외에도 다양한 인증 규격들이 존재하며 현재 12207과 타 규격들간의 관계는 각 인증규격별로 공통된 부분도 있으나, 차이점도 많이 있다. 따라서, 특정 인증규격으로 인증된 소프트웨어를 다른 인 증규격으로 인증 받고자 하는 경우는 이러한 차이점에 대한 차이분석(Gap Analysis)을 수행하고, 차 이에 대한 인증절차를 수행하여야 한다. 아래는 현재의 IEEE/EIA 12207이 개발되기 까지 기존의 표 준들은 어떠한 특징을 가지고 진화하여 왔는지를 파악한다. (1) DoD-STD-2167(미 국방체계 소프트웨어 개발 표준) - 목적 :　국방체계 SW개발(Defense System SW Development)을 위하여 무기체계 분야에 주로 적 - 22 -

Page22

소프트웨어 개발 및 문서화에 대한 단일화 된 요구조건을 정립하는 목적으로 제정되었다. 1994년 11 월에 공표되었으며, DOD-STD-2167A, DOD-STD-7935A 등을 대체(replace)하였다. 이 규격은 당 초부터 상용규격이 제정되기까지 약 2년 동안만 적용할 예정이었으며, 1998년 5월 J-STD-016과 IEEE 12207로 대체되면서 취소되었다. 하지만 이 규격은 표준화된 문서가 무료로 공개되어 있어 미 군 이외의 분야에서 수행하는 사업에는 그 후에도 지속적으로 사용되었다. MIL-STD-498에서는 22 개의 산출물을 요구하고 있으며, 각 산출물들의 표준양식 및 포함되어야 할 내용들을 Data Item Description이라는 문서에 정의하였으며, 이것이 이 규격의 핵심이라고 할 수 있다. IEEE/EIA 12207(Standard for InformationTechnology-Software Life Cycle Processes)은 소프트웨어 생명주 기 프로세스의 일반적인 프레임워크(framework)를 규정하는 규격으로서 1998년 8월에 공표되었다. <미국 국방 소프트웨어 표준의 연도별 진화 과정> 표준 설 명 년도MIL-STD-1679 Software Development 1983ADOD-STD-2167 Defense System Software Development 1988ADOD-STD-7935 AIS Documentation Standards 1988A Software Development and MIL-STD-498 1994Documentation 1991ISO 9000 series - on Quality Management, etc. -J-STD-016-19 Software Development 199595 -Acquirer-Supplier AgreementInformation Technology - Software LifeISO/IEC 12207 1996Cycle ProcessesIEEE/EIA 12207 Software Life Cycle Processes 1998 12207 외에도 다양한 인증 규격들이 존재하며 현재 12207과 타 규격들간의 관계는 각 인증규격별로 공통된 부분도 있으나, 차이점도 많이 있다. 따라서, 특정 인증규격으로 인증된 소프트웨어를 다른 인 증규격으로 인증 받고자 하는 경우는 이러한 차이점에 대한 차이분석(Gap Analysis)을 수행하고, 차 이에 대한 인증절차를 수행하여야 한다. 아래는 현재의 IEEE/EIA 12207이 개발되기 까지 기존의 표 준들은 어떠한 특징을 가지고 진화하여 왔는지를 파악한다. (1) DoD-STD-2167(미 국방체계 소프트웨어 개발 표준) - 목적 :　국방체계 SW개발(Defense System SW Development)을 위하여 무기체계 분야에 주로 적 - 22 -

Page23
용할 목적으로 SW 개발 프로세스와 16개의 데이터 항목 기술서를 정의한 표준 - 내용 : 정식 명칭은 “Defense Systems Software Development"이고 미 국방부가 1988년 2월 29 일 제정한 것이다. 이 표준은 폭포수 모델을 기반으로 한다. 문서상에서는 계약자가 소프트웨어 개발 프로세스를 선택할 수 있다는 조항이 포함되어 있지만 규격화된 수락검토 사항에는 정형화된 폭포수 모델의 내용이 제시되고 있다. (2) MIL-STD-7935A(미 국방 자동화정보체계 문서화 표준) - 목적 : MIL-STD-7935A는 국방자동화 정보체계(DoD AIS: DoD Automated Information Systems)의 문서화 표준으로 자동화 정보체계 개발에 적용할 목적으로 11개의 문서형식과 내용, 문 서들의 적용지침을 제공한 표준 - 내용 : 정식명칭은 “DoD Automated Information Systems(AIS) Documentation Standards"이고 미 국방부가 1988년 10월에 제정하였다. (3) MIL-STD-498(Military-Standard-498) - 목적 : 미국의 군사 표준으로, "소프트웨어 개발과 문서화 요건을 수립"하기 위한 목적 - 내용 : MIL-STD-498은 1994년 12월에 발표된 소프트웨어 개발 및 문서화에 대한 표준으로서, 1988년에 발표된 MIL-STD-2167A를 대체했다. MIL-STD-498은 소프트웨어 분야(국방체계와 자 동화정보체계)별로 구분되어 있었던 소프트웨어 개발 표준을 하나로 통합시키고 과거의 표준을 사용 하는 과정에서 인식되었던 많은 문제점을 해결하고 변화된 소프트웨어 개발 기술 및 개발 환경과의 호환성을 확립하고 마지막으로 ISO/IEC 12207 표준에 대한 미국 버전을 구현하기 위한 토대를 제공 하기 위한 것이었다. 그래서 DoD-STD-2167과 MIL-STD-7935A를 하나로 통합했다. 이 표준은 1994년 11월 8일 공표되었으며, 기존의 표준인 DOD-STD-2167A과 DOD-STD-7935A을 대체하 도록 적용되었다. 그러나 J-STD-016 상용 표준이 만들어지는 2년의 짧은 기간 동안 표준으로 적용 되었다. MIL-STD-498은 1990년대 정보체계 개발에 큰 영향을 미쳤으며, IEEE/EIA 12207에 의해 대체되기 전까지 미국의 국방 소프트웨어 개발의 표준으로 사용되었다. MIL-STD-498에 정의된 22 종의 DID(Data Item Description)들은 아직도 많은 개발 사업에서 프로세스를 문서화하기 위해 공통 적으로 사용되고 있으며 MIL-STD-498은 많은 계약들에 표준 개발 프로세스로 남아있다. 이 표준은 1998년 5월 27일 J-STD-016과 IEEE 12207로 대체되어 효력을 상실했다. 한국을 포함하여 미국 이외의 나라에서는 여전히 이 표준을 따르는 경우가 많은데, 그 이유는 새로운 표준에 비해 MIL-STD-498이 자유롭게 공개 되어 있기 때문이다. MIL-STD-498의 본문 내용은 여러 장에 걸 쳐 작성되는데 4장의 일반적 요구사항은 계약요구사항에 일치하는 소프트웨어 개발 프로세스를 수립 하는데 있다. 소프트웨어 개발을 위한 일반적인 요구사항은 다음과 같다. 가) 체계적이고 문서화된 방법을 사용한다. - 23 -

Page23

용할 목적으로 SW 개발 프로세스와 16개의 데이터 항목 기술서를 정의한 표준 - 내용 : 정식 명칭은 “Defense Systems Software Development"이고 미 국방부가 1988년 2월 29 일 제정한 것이다. 이 표준은 폭포수 모델을 기반으로 한다. 문서상에서는 계약자가 소프트웨어 개발 프로세스를 선택할 수 있다는 조항이 포함되어 있지만 규격화된 수락검토 사항에는 정형화된 폭포수 모델의 내용이 제시되고 있다. (2) MIL-STD-7935A(미 국방 자동화정보체계 문서화 표준) - 목적 : MIL-STD-7935A는 국방자동화 정보체계(DoD AIS: DoD Automated Information Systems)의 문서화 표준으로 자동화 정보체계 개발에 적용할 목적으로 11개의 문서형식과 내용, 문 서들의 적용지침을 제공한 표준 - 내용 : 정식명칭은 “DoD Automated Information Systems(AIS) Documentation Standards"이고 미 국방부가 1988년 10월에 제정하였다. (3) MIL-STD-498(Military-Standard-498) - 목적 : 미국의 군사 표준으로, "소프트웨어 개발과 문서화 요건을 수립"하기 위한 목적 - 내용 : MIL-STD-498은 1994년 12월에 발표된 소프트웨어 개발 및 문서화에 대한 표준으로서, 1988년에 발표된 MIL-STD-2167A를 대체했다. MIL-STD-498은 소프트웨어 분야(국방체계와 자 동화정보체계)별로 구분되어 있었던 소프트웨어 개발 표준을 하나로 통합시키고 과거의 표준을 사용 하는 과정에서 인식되었던 많은 문제점을 해결하고 변화된 소프트웨어 개발 기술 및 개발 환경과의 호환성을 확립하고 마지막으로 ISO/IEC 12207 표준에 대한 미국 버전을 구현하기 위한 토대를 제공 하기 위한 것이었다. 그래서 DoD-STD-2167과 MIL-STD-7935A를 하나로 통합했다. 이 표준은 1994년 11월 8일 공표되었으며, 기존의 표준인 DOD-STD-2167A과 DOD-STD-7935A을 대체하 도록 적용되었다. 그러나 J-STD-016 상용 표준이 만들어지는 2년의 짧은 기간 동안 표준으로 적용 되었다. MIL-STD-498은 1990년대 정보체계 개발에 큰 영향을 미쳤으며, IEEE/EIA 12207에 의해 대체되기 전까지 미국의 국방 소프트웨어 개발의 표준으로 사용되었다. MIL-STD-498에 정의된 22 종의 DID(Data Item Description)들은 아직도 많은 개발 사업에서 프로세스를 문서화하기 위해 공통 적으로 사용되고 있으며 MIL-STD-498은 많은 계약들에 표준 개발 프로세스로 남아있다. 이 표준은 1998년 5월 27일 J-STD-016과 IEEE 12207로 대체되어 효력을 상실했다. 한국을 포함하여 미국 이외의 나라에서는 여전히 이 표준을 따르는 경우가 많은데, 그 이유는 새로운 표준에 비해 MIL-STD-498이 자유롭게 공개 되어 있기 때문이다. MIL-STD-498의 본문 내용은 여러 장에 걸 쳐 작성되는데 4장의 일반적 요구사항은 계약요구사항에 일치하는 소프트웨어 개발 프로세스를 수립 하는데 있다. 소프트웨어 개발을 위한 일반적인 요구사항은 다음과 같다. 가) 체계적이고 문서화된 방법을 사용한다. - 23 -

Page24
나) 요구사항, 설계, 코드 및 테스트 정보를 표현하기 위한 표준을 개발하고 적용한다. 다) 소프트웨어 산출물을 적절하게 재사용한다. (가) 계약요구사항의 이행에 사용하기 위해 재사용 가능한 소프트웨어 산출물을 평가한다. (나) 소프트웨어 개발계획에 포함된 기준을 충족시키는 산출물을 재사용 대상으로 고려한다. (다) 재사용 할 수 있는 소프트웨어 산출물을 개발하기 위한 기회를 식별한다. (라) 재사용 가능한 산출물은 비용 측면에서 효과적이며, 목적과도 일치함을 획득기관에 통보한다. 라) 안전(Safety), 보호(Security), 혹은 프라이버시(Privacy)등과 같은 주요 요구사항을 처리하기 위 한 전략을 수립하고 적용한다. 마) 하드웨어 자원에 대한 활용도 요구사항을 분석하고 이행한다. 바) 시스템 운영 부서의 사용을 위하여 주요 결정사항에 대한 이론적 근거를 기록한다. 사) 개발자 및 부계약자의 시설에 대한 획득자의 검토기회를 제공한다. MIL-STD-498의 상세요구사항은 프로젝트 계획 및 관리에서 기타활동까지 소프트웨어 개발에 있어 서의 모든 절차를 구체적으로 명시하고 있다. 해당 절차들은 제안요청서와 계약서에 근간으로 활용할 수 있도록 하고 있다. 따라서 체계개발계획서 내에 상세요구사항에 대한 내용을 그대로 수용하여 작 성하도록 하여 소프트웨어 개발에 요구되는 모든 절차에 대해 적용할 수 있도록 작성되어 있다. 다음 은 상세요구사항의 항목들이다. ○ 프로젝트 계획 관리. ○ 소프트웨어 개발 환경 설정. ○ 시스템 요구사항 분석. ○ 시스템 설계. ○ 소프트웨어 요구사항 분석. ○ 소프트웨어 설계. ○ 소프트웨어 구현 및 단위 테스팅. ○ 단위 통합 및 테스팅. ○ CSCI 직능 테스팅. ○ CSCI/HWCI 통합 및 테스팅. ○ 시스템 직능 테스팅. ○ 소프트웨어 인계준비. ○ 소프트웨어 형상관리. ○ 소프트웨어 산출물 평가. ○ 소프트웨어 품질 보증. ○ 교정 활동. ○ 합동 기술 검토 및 관리 검토. - 24 -

Page24

나) 요구사항, 설계, 코드 및 테스트 정보를 표현하기 위한 표준을 개발하고 적용한다. 다) 소프트웨어 산출물을 적절하게 재사용한다. (가) 계약요구사항의 이행에 사용하기 위해 재사용 가능한 소프트웨어 산출물을 평가한다. (나) 소프트웨어 개발계획에 포함된 기준을 충족시키는 산출물을 재사용 대상으로 고려한다. (다) 재사용 할 수 있는 소프트웨어 산출물을 개발하기 위한 기회를 식별한다. (라) 재사용 가능한 산출물은 비용 측면에서 효과적이며, 목적과도 일치함을 획득기관에 통보한다. 라) 안전(Safety), 보호(Security), 혹은 프라이버시(Privacy)등과 같은 주요 요구사항을 처리하기 위 한 전략을 수립하고 적용한다. 마) 하드웨어 자원에 대한 활용도 요구사항을 분석하고 이행한다. 바) 시스템 운영 부서의 사용을 위하여 주요 결정사항에 대한 이론적 근거를 기록한다. 사) 개발자 및 부계약자의 시설에 대한 획득자의 검토기회를 제공한다. MIL-STD-498의 상세요구사항은 프로젝트 계획 및 관리에서 기타활동까지 소프트웨어 개발에 있어 서의 모든 절차를 구체적으로 명시하고 있다. 해당 절차들은 제안요청서와 계약서에 근간으로 활용할 수 있도록 하고 있다. 따라서 체계개발계획서 내에 상세요구사항에 대한 내용을 그대로 수용하여 작 성하도록 하여 소프트웨어 개발에 요구되는 모든 절차에 대해 적용할 수 있도록 작성되어 있다. 다음 은 상세요구사항의 항목들이다. ○ 프로젝트 계획 관리. ○ 소프트웨어 개발 환경 설정. ○ 시스템 요구사항 분석. ○ 시스템 설계. ○ 소프트웨어 요구사항 분석. ○ 소프트웨어 설계. ○ 소프트웨어 구현 및 단위 테스팅. ○ 단위 통합 및 테스팅. ○ CSCI 직능 테스팅. ○ CSCI/HWCI 통합 및 테스팅. ○ 시스템 직능 테스팅. ○ 소프트웨어 인계준비. ○ 소프트웨어 형상관리. ○ 소프트웨어 산출물 평가. ○ 소프트웨어 품질 보증. ○ 교정 활동. ○ 합동 기술 검토 및 관리 검토. - 24 -

Page25
○ 기타 활동. ○ 소프트웨어 사용 준비. - 산출물 : MIL-STD-498은 국방시스템과 정보체계 개발을 통합한 새로운 SW 개발 표준으로 SW 개발 문서화 표준과 22개의 데이터항목기술서로 구성되어 있다. 모든 데이터항목기술서는 공통적인 항목으로 제목으로부터 승인 일자 및 승인기간, 주요책임부서, 적용 및 다른 데이터항목기술서와의 연 관관계 등을 나타내주고 있으며, 해당 데이터 항목기술서의 구체적인 내용은 각 항목의 제목과 해당 항목을 작성하는 방법을 상세히 설명해 주고 있다. 해당 데이터항목기술서의 세부적인 설명에 있어서 도 요구하는 사항에 대한 내용뿐만 아니라 관련된 데이터 항목 기술서 및 상세요구사항에서 제시하고 있는 내용 및 절차에 대한 사항도 같이 언급해 줌으로써 데이터항목기술서와 상세요구사항을 접목할 수 있도록 구성되어 있다. 데이터항목기술서는 데이터항목의 내용을 기술한 것으로, 소프트웨어 또는 소프트웨어 수명주기의 특정 단계를 기술한 ‘문서’가 된다. 이 문서들은 소프트웨어 코드에서부터 다 양한 전자 또는 종이 보고서 등 여러 형태가 될 수 있다. 그리고 계약당사자들은 정의된 인정 범위 내에서 결과물의 형태를 지정해야 한다. 그리고 이들 데이터 항목이 모여져서 계약에 의한 납품 목록 을 구성하게 된다. 프로젝트의 성격에 따라, 일부 데이터항목만 요구되는 경우도 있다. (4) ISO/IEC 12207 - 목적 : 소프트웨어 수명주기 프로세스를 위한 공통적인 프레임워크를 설정하며, 소프트웨어 수명주 기 프로세스를 정의하고 통제하고 개선하기 위한 프로세스를 제공한다. - 구성 : 소프트웨어 수명주기 동안에 수행할 수 있는 활동을 수명주기 프로세스와 테일러링 프로세 스로 구분하고, 수명주기 프로세스를 5가지 기본 프로세스, 8가지 지원 프로세스, 4가지의 조직 프로 세스로 그룹화 한다. 각각은 일련의 활동으로 구성되고 각 활동은 다시 일련의 작업으로 구성된다. 가) 주요 프로세스 : 공급, 획득, 개발, 운용, 유지보수 등 나) 조직 프로세스 : 관리, 개선, 기반구조, 교육훈련 등 다) 지원 프로세스 : 문서화, 형상관리, 품질보증, 문제관리 등 ISO/IEC 12207은 소프트웨어의 수명주기에 걸쳐 적용될 수 있는 프로세스를 포함한다. 그러나 이러 한 프로세스는 상이한 조직에 의하여 상이한 관점과 목적으로 사용될 수 있다. - 내용 : 소프트웨어는 정보 기술 및 전형적 시스템(수송, 군사, 의료, 재무 등)의 필수적 구성요소이 다. 그러나 소프트웨어를 개발하고 관리하기 위한 표준, 절차, 방법, 도구 및 환경들은 무분별하게 탄 생되어 왔다. 이러한 현상이 소프트웨어 관리 및 공학, 특히 제품이나 서비스를 통합하는데 있어서 많 은 어려움을 발생시키게 되었다. 따라서 소프트웨어 실무자가 소프트웨어를 개발하고 관리하는데 있 어서 “동일한 언어로 말하기 위하여” 사용될 수 있는 공통적인 기본 틀(framework)에 대한 요구가 증 가하게 되었다. 이러한 요구에 부합하기 위하여 세계표준화기구인 ISO/IEC JTC1 산하의 소위원회 - 25 -

Page25

○ 기타 활동. ○ 소프트웨어 사용 준비. - 산출물 : MIL-STD-498은 국방시스템과 정보체계 개발을 통합한 새로운 SW 개발 표준으로 SW 개발 문서화 표준과 22개의 데이터항목기술서로 구성되어 있다. 모든 데이터항목기술서는 공통적인 항목으로 제목으로부터 승인 일자 및 승인기간, 주요책임부서, 적용 및 다른 데이터항목기술서와의 연 관관계 등을 나타내주고 있으며, 해당 데이터 항목기술서의 구체적인 내용은 각 항목의 제목과 해당 항목을 작성하는 방법을 상세히 설명해 주고 있다. 해당 데이터항목기술서의 세부적인 설명에 있어서 도 요구하는 사항에 대한 내용뿐만 아니라 관련된 데이터 항목 기술서 및 상세요구사항에서 제시하고 있는 내용 및 절차에 대한 사항도 같이 언급해 줌으로써 데이터항목기술서와 상세요구사항을 접목할 수 있도록 구성되어 있다. 데이터항목기술서는 데이터항목의 내용을 기술한 것으로, 소프트웨어 또는 소프트웨어 수명주기의 특정 단계를 기술한 ‘문서’가 된다. 이 문서들은 소프트웨어 코드에서부터 다 양한 전자 또는 종이 보고서 등 여러 형태가 될 수 있다. 그리고 계약당사자들은 정의된 인정 범위 내에서 결과물의 형태를 지정해야 한다. 그리고 이들 데이터 항목이 모여져서 계약에 의한 납품 목록 을 구성하게 된다. 프로젝트의 성격에 따라, 일부 데이터항목만 요구되는 경우도 있다. (4) ISO/IEC 12207 - 목적 : 소프트웨어 수명주기 프로세스를 위한 공통적인 프레임워크를 설정하며, 소프트웨어 수명주 기 프로세스를 정의하고 통제하고 개선하기 위한 프로세스를 제공한다. - 구성 : 소프트웨어 수명주기 동안에 수행할 수 있는 활동을 수명주기 프로세스와 테일러링 프로세 스로 구분하고, 수명주기 프로세스를 5가지 기본 프로세스, 8가지 지원 프로세스, 4가지의 조직 프로 세스로 그룹화 한다. 각각은 일련의 활동으로 구성되고 각 활동은 다시 일련의 작업으로 구성된다. 가) 주요 프로세스 : 공급, 획득, 개발, 운용, 유지보수 등 나) 조직 프로세스 : 관리, 개선, 기반구조, 교육훈련 등 다) 지원 프로세스 : 문서화, 형상관리, 품질보증, 문제관리 등 ISO/IEC 12207은 소프트웨어의 수명주기에 걸쳐 적용될 수 있는 프로세스를 포함한다. 그러나 이러 한 프로세스는 상이한 조직에 의하여 상이한 관점과 목적으로 사용될 수 있다. - 내용 : 소프트웨어는 정보 기술 및 전형적 시스템(수송, 군사, 의료, 재무 등)의 필수적 구성요소이 다. 그러나 소프트웨어를 개발하고 관리하기 위한 표준, 절차, 방법, 도구 및 환경들은 무분별하게 탄 생되어 왔다. 이러한 현상이 소프트웨어 관리 및 공학, 특히 제품이나 서비스를 통합하는데 있어서 많 은 어려움을 발생시키게 되었다. 따라서 소프트웨어 실무자가 소프트웨어를 개발하고 관리하는데 있 어서 “동일한 언어로 말하기 위하여” 사용될 수 있는 공통적인 기본 틀(framework)에 대한 요구가 증 가하게 되었다. 이러한 요구에 부합하기 위하여 세계표준화기구인 ISO/IEC JTC1 산하의 소위원회 - 25 -

Page26
SC7(Sub-Committee 7)이 1995년 2월에 소프트웨어 수명주기에 대한 세계표준(International Standard) ISO/IEC 12207(Software Life Cycle Process)을 제정 발표하였다. ISO/IEC에서는 어떠한 활동들이 소프트웨어 프로젝트에서 수행되는지에 관한 조사를 전 세계적으로 실시하였으며 소프트웨 어 관련 모든 프로세스, 활동, 임무를 위한 국제 표준으로 ISO/IEC 12207을 제정하였다. ISO/IEC 12207의 기본적인 형태는 아이디어의 개념화부터 폐기에 이르기까지 소프트웨어 수명주기 프로세스를 포함하고 있다. 소프트웨어 제품이나 서비스를 획득하고 공급하는 공정들로 구성되어 있 으며 공정들을 관리하고 개선하기 위한 사항도 제공하고 있다. ISO/IEC 12207은 소프트웨어 프로젝 트 또는 개별 조직을 고려하여 조정될 수 있도록 설계된 일련의 공정, 활동 및 세부적인 업무들을 나 타낸 것이다. 또한 이 표준은 소프트웨어 수명주기 프로세스의 아키텍쳐를 나타내는 것이지 프로세스 에 포함된 활동 및 세부적인 업무들의 구현 또는 수행의 상세한 방법을 규정하는 것은 아니다. 이 표 준은 소프트웨어의 수명주기 동안 수행될 수 있는 활동들을 5가지의 주요 수명주기 프로세스, 8가지 지원 수명주기 프로세스, 그리고 4가지 조직 수명주기 프로세스로 구분한다. 각 소프트웨어 수명주기 프로세스는 일련의 과업들로 분류되고, 각 과업들은 세부업무로 세분된다. (5) IEEE/EIA 12207(Standard for InformationTechnology-Software Life Cycle Processes) - 목적 : 소프트웨어 생명주기 프로세스의 일반적인 프레임워크(framework)를 규정하는 규격 - 내용 : IEEE/EIA 12207은 1998년에 발간된 소프트웨어 수명 주기 표준으로서, 1998년 5월에 미 국방부에 의해 MIL-STD-498을 대체하는 표준으로 채택되었다. 이 표준은 산업계에 국제적으로 사 용될 수 있는 소프트웨어 관행을 제공하며, 소프트웨어 코드 시험 (Software Code and Test), 소프 트웨어 충족 시험 (Software Qualification Testing), 그리고 체계 충족 시험 (System Qualification Testing)등의 시험 활동이 정의되어 있다. 현재 대부분의 선진국은 국방 분야 정보체계 개발에 이 표 준을 적용하고 있다. IEEE(Institute of Electrical and Electronic Engineers, Inc.)/EIA (Electronic Industries Association) 12207은 ISO/IEC 12207의 미국 버전으로써, ISO/IEC 12207의 내용에 MIL-STD-498의 기술적인 내용을 포함시켰다. 즉, IEEE/EIA 12207은 ISO/IEC 12207의 본문과 부 록을 그대로 적용하고, MIL-STD-498과 MIL-STD-498의 데이터 항목 기술서와 IEEE 의 소프트 웨어 공학 표준의 세부 지침을 포함한다. 따라서 IEEE/EIA 12207은 소프트웨어 수명주기 전체를 포 함하고 있다. 기본적으로 ISO/IEC 12207의 기본프로세스를 따르고 있으며 기술적인 부분에서 MIL-STD-498을 참고하였다. 표준의 구성은 총 3부분으로 12207.0 소프트웨어 수명주기 프로세스 ('Software lifecycle Processes'), 12207.1 수명주기 데이터('Lifecycle data'), 12207.2 수행 간 고려 사항('Implementaion considerations') 이다. IEEE/EIA 12207.0은 문서부분과 부록으로 구성되며 12207.1과 12207.2는 지침 문서의 역할을 한다. 아래의 그림은 IEEE/EIA 12207의 전체적인 문서 구성을 나타낸 것이다. - 26 -

Page26

SC7(Sub-Committee 7)이 1995년 2월에 소프트웨어 수명주기에 대한 세계표준(International Standard) ISO/IEC 12207(Software Life Cycle Process)을 제정 발표하였다. ISO/IEC에서는 어떠한 활동들이 소프트웨어 프로젝트에서 수행되는지에 관한 조사를 전 세계적으로 실시하였으며 소프트웨 어 관련 모든 프로세스, 활동, 임무를 위한 국제 표준으로 ISO/IEC 12207을 제정하였다. ISO/IEC 12207의 기본적인 형태는 아이디어의 개념화부터 폐기에 이르기까지 소프트웨어 수명주기 프로세스를 포함하고 있다. 소프트웨어 제품이나 서비스를 획득하고 공급하는 공정들로 구성되어 있 으며 공정들을 관리하고 개선하기 위한 사항도 제공하고 있다. ISO/IEC 12207은 소프트웨어 프로젝 트 또는 개별 조직을 고려하여 조정될 수 있도록 설계된 일련의 공정, 활동 및 세부적인 업무들을 나 타낸 것이다. 또한 이 표준은 소프트웨어 수명주기 프로세스의 아키텍쳐를 나타내는 것이지 프로세스 에 포함된 활동 및 세부적인 업무들의 구현 또는 수행의 상세한 방법을 규정하는 것은 아니다. 이 표 준은 소프트웨어의 수명주기 동안 수행될 수 있는 활동들을 5가지의 주요 수명주기 프로세스, 8가지 지원 수명주기 프로세스, 그리고 4가지 조직 수명주기 프로세스로 구분한다. 각 소프트웨어 수명주기 프로세스는 일련의 과업들로 분류되고, 각 과업들은 세부업무로 세분된다. (5) IEEE/EIA 12207(Standard for InformationTechnology-Software Life Cycle Processes) - 목적 : 소프트웨어 생명주기 프로세스의 일반적인 프레임워크(framework)를 규정하는 규격 - 내용 : IEEE/EIA 12207은 1998년에 발간된 소프트웨어 수명 주기 표준으로서, 1998년 5월에 미 국방부에 의해 MIL-STD-498을 대체하는 표준으로 채택되었다. 이 표준은 산업계에 국제적으로 사 용될 수 있는 소프트웨어 관행을 제공하며, 소프트웨어 코드 시험 (Software Code and Test), 소프 트웨어 충족 시험 (Software Qualification Testing), 그리고 체계 충족 시험 (System Qualification Testing)등의 시험 활동이 정의되어 있다. 현재 대부분의 선진국은 국방 분야 정보체계 개발에 이 표 준을 적용하고 있다. IEEE(Institute of Electrical and Electronic Engineers, Inc.)/EIA (Electronic Industries Association) 12207은 ISO/IEC 12207의 미국 버전으로써, ISO/IEC 12207의 내용에 MIL-STD-498의 기술적인 내용을 포함시켰다. 즉, IEEE/EIA 12207은 ISO/IEC 12207의 본문과 부 록을 그대로 적용하고, MIL-STD-498과 MIL-STD-498의 데이터 항목 기술서와 IEEE 의 소프트 웨어 공학 표준의 세부 지침을 포함한다. 따라서 IEEE/EIA 12207은 소프트웨어 수명주기 전체를 포 함하고 있다. 기본적으로 ISO/IEC 12207의 기본프로세스를 따르고 있으며 기술적인 부분에서 MIL-STD-498을 참고하였다. 표준의 구성은 총 3부분으로 12207.0 소프트웨어 수명주기 프로세스 ('Software lifecycle Processes'), 12207.1 수명주기 데이터('Lifecycle data'), 12207.2 수행 간 고려 사항('Implementaion considerations') 이다. IEEE/EIA 12207.0은 문서부분과 부록으로 구성되며 12207.1과 12207.2는 지침 문서의 역할을 한다. 아래의 그림은 IEEE/EIA 12207의 전체적인 문서 구성을 나타낸 것이다. - 26 -

Page27
[그림 8] IEEE/EIA 12207의 구성 국방 소프트웨어 개발 프로세스 표준 연구 1990년대 초 우리 군은 국방 정보체계의 효율적인 획득을 위해 미군의 일괄개발 전략 중심의 소프트 웨어 개발 표준인 DoD-STD-2167A를 기반으로 ‘국방 전산망 사업관리 지침’을 제정하여 1990년대 중반까지 사용하였으며, 1990년대 중반 이후에는 DoD-STD- 2167A의 발전된 형태인 MIL-STD-498을 적용하여 위의 지침을 개정하였다. 2003년에는 국방 컴포넌트 기반 개발 방법론인 ADDMe가 국방과학연구소에 의해 개발되었으며, 2006년에는 방위사업청이 다양한 국제표준과 국내 표준 등을 참고하여 소프트웨어 개발 프로세스를 제정하였다. 2005년에 발표된 ADDMe는 국방과학연 구소(ADD)가 국제표준인 ISO/IEC 12207, MIL-STD-498 등을 분석 참조하여 개발한 국방 컴포넌 트 기반 개발 방법론이다. ADDMe는 표준화 개발을 통한 핵심 프로그램 재사용과 공유, 그리고 상호 운용성 향상을 목표로 가지고 있다. 방위사업청 소프트웨어 개발 프로세스는 무기체계로 분류되는 소 프트웨어와, 각종 무기체계에 포함되는 내장형 소프트웨어의 개발과 관련하여 공정에 관한 표준 절차 로서, 소프트웨어 수명주기 프로세스를 정의한 국제표준(ISO/IEC-12207) 및 정보통신부에서 작성한 발주․관리 표준 프로세스별 지침을 참고하여 국방 정보체계 획득 및 개발에 필요한 프로세스를 재구성 하여 획득자와 공급자의 역할을 정의한다. 국방 체계 안전성 표준 연구 오류가 있을시 치명적 재해를 발생시킬 수 있는 항공기 체계(시스템) 개발에 있어서 안전성 보장은 필수 요건사항이다. 시스템 안전을 보증하기 위해서는 기본적으로 안전에 관한 규격 및 표준을 준수 하고 따를 것이 요구되고 있다. 시스템 안전에 관한 국제 표준으로는 전기/전자/프로그램 가능한 전자장치 안전관련 시스템의 기능안 - 27 -

Page27

[그림 8] IEEE/EIA 12207의 구성 국방 소프트웨어 개발 프로세스 표준 연구 1990년대 초 우리 군은 국방 정보체계의 효율적인 획득을 위해 미군의 일괄개발 전략 중심의 소프트 웨어 개발 표준인 DoD-STD-2167A를 기반으로 ‘국방 전산망 사업관리 지침’을 제정하여 1990년대 중반까지 사용하였으며, 1990년대 중반 이후에는 DoD-STD- 2167A의 발전된 형태인 MIL-STD-498을 적용하여 위의 지침을 개정하였다. 2003년에는 국방 컴포넌트 기반 개발 방법론인 ADDMe가 국방과학연구소에 의해 개발되었으며, 2006년에는 방위사업청이 다양한 국제표준과 국내 표준 등을 참고하여 소프트웨어 개발 프로세스를 제정하였다. 2005년에 발표된 ADDMe는 국방과학연 구소(ADD)가 국제표준인 ISO/IEC 12207, MIL-STD-498 등을 분석 참조하여 개발한 국방 컴포넌 트 기반 개발 방법론이다. ADDMe는 표준화 개발을 통한 핵심 프로그램 재사용과 공유, 그리고 상호 운용성 향상을 목표로 가지고 있다. 방위사업청 소프트웨어 개발 프로세스는 무기체계로 분류되는 소 프트웨어와, 각종 무기체계에 포함되는 내장형 소프트웨어의 개발과 관련하여 공정에 관한 표준 절차 로서, 소프트웨어 수명주기 프로세스를 정의한 국제표준(ISO/IEC-12207) 및 정보통신부에서 작성한 발주․관리 표준 프로세스별 지침을 참고하여 국방 정보체계 획득 및 개발에 필요한 프로세스를 재구성 하여 획득자와 공급자의 역할을 정의한다. 국방 체계 안전성 표준 연구 오류가 있을시 치명적 재해를 발생시킬 수 있는 항공기 체계(시스템) 개발에 있어서 안전성 보장은 필수 요건사항이다. 시스템 안전을 보증하기 위해서는 기본적으로 안전에 관한 규격 및 표준을 준수 하고 따를 것이 요구되고 있다. 시스템 안전에 관한 국제 표준으로는 전기/전자/프로그램 가능한 전자장치 안전관련 시스템의 기능안 - 27 -

Page29
1995.2 : MIL-HDBK-217FN2(Rome Laboratory) 1995년 이후 추가적인 노력이 이루어지지 않은 관계로 이후의 버전은 존재하지 않지만 현재까지 세 계적으로 전기전자 부품이나 제품 신뢰성 예측의 중심적인 역할을 해오고 있다. 비록 정확성의 문제 가 대두되나 방법론으로서 뿐 아니라 정확성 측면에서 대안이 뚜렷하지 못하기 때문이다. MIL-HDBK-217에서의 시스템 고장률은 다음과 같은 부품 고장률을 근간으로 한다.    ×          이 식에서  는 대상 부품의 기본 고장률로 부품범주, 종류, 그리고 전기적 특성에 따라 다른 값으로  제공된다.  는 동작상의 온도, 동작 시 부품에 인가되는 전기적 부하, 제조상의 품질수준, 사용 환경  등의 요소를 의미한다. 고장률 공식과 적용되는 요소들은 부품별로 다르며 동일 부품에 대해서도 범 주 및 타입별로 요소의 적용 값들이 다르다. 부품의 수명은 지수분포를 가정하며, 고장률은 106 동작 시간을 단위로 정의된다. 최종적으로 전체 시스템의 고장률은 부품별 고장률을 계산한 뒤 개별 부품 들이 서로 독립임을 가정하여 이들의 합으로 정의한다. (2) PRISM PEM(plastic encapsulated micro-circuits)에 대한 새로운 모형이 1996년 Denson에 의해 제안되었 다. 이는 새로운 신뢰성 모형으로서 상업용 부품의 고장률 예측에서 MIL-HDBK-217의 약점을 극 복하는 것이었다. 이를 바탕으로 신뢰도 평가를 위한 방법론 개발에 착수 하였으며 1998년 시스템 수 준의 평가 방법론을 채택한 접근법을 개발하였다. 이 방법론의 주 특징은 특정 요인의 규명에 근거한 시스템 수준의 신뢰성 예측으로 PGF(Process grading factor)와 소프트웨어 고장률 등을 포함한다는 점이다. 그 다음해에 새로운 시스템 신뢰성 평가에 대한 연구를 바탕으로 소프트웨어화 하였으며 2000년 1월 새로운 방법론 도구인 PRISM이 출시되었다. 그 이후 PRISM은 새로운 버전을 출시하며 발전하였으며 버전 1.5까지 출시되었다. (3) 217-Plus - 개요 : 2006년 RIAC는 DoD의 자금 지원 하에 PRISM의 차세대 버전이며 MIL-HDBK-217을 대 체할 예측 방법론으로 217Plus를 출시하였으며 PRISM보다 더 포괄적인 12가지 부품 모형들을 포함 한다. 구체적으로 설명하면 기존에 존재하는 6 종류에 새로운 6종류를 추가하고 IC는 plastic encapsulate와 hermite등으로 확대하였다. 또 한 가지 주요한 특징은 PRISM이 특정 사용자 community에 의해 출발하였기 때문에 근간 데이터나 모형식들의 상세 내용들이 일반인에게 공개되지 않았던 반면 217-Plus는 공식적으로 공개됨으로써 사용자나 분석자들이 세부 모형 식들을 자유롭게 - 29 -

Page29

1995.2 : MIL-HDBK-217FN2(Rome Laboratory) 1995년 이후 추가적인 노력이 이루어지지 않은 관계로 이후의 버전은 존재하지 않지만 현재까지 세 계적으로 전기전자 부품이나 제품 신뢰성 예측의 중심적인 역할을 해오고 있다. 비록 정확성의 문제 가 대두되나 방법론으로서 뿐 아니라 정확성 측면에서 대안이 뚜렷하지 못하기 때문이다. MIL-HDBK-217에서의 시스템 고장률은 다음과 같은 부품 고장률을 근간으로 한다.    ×          이 식에서  는 대상 부품의 기본 고장률로 부품범주, 종류, 그리고 전기적 특성에 따라 다른 값으로  제공된다.  는 동작상의 온도, 동작 시 부품에 인가되는 전기적 부하, 제조상의 품질수준, 사용 환경  등의 요소를 의미한다. 고장률 공식과 적용되는 요소들은 부품별로 다르며 동일 부품에 대해서도 범 주 및 타입별로 요소의 적용 값들이 다르다. 부품의 수명은 지수분포를 가정하며, 고장률은 106 동작 시간을 단위로 정의된다. 최종적으로 전체 시스템의 고장률은 부품별 고장률을 계산한 뒤 개별 부품 들이 서로 독립임을 가정하여 이들의 합으로 정의한다. (2) PRISM PEM(plastic encapsulated micro-circuits)에 대한 새로운 모형이 1996년 Denson에 의해 제안되었 다. 이는 새로운 신뢰성 모형으로서 상업용 부품의 고장률 예측에서 MIL-HDBK-217의 약점을 극 복하는 것이었다. 이를 바탕으로 신뢰도 평가를 위한 방법론 개발에 착수 하였으며 1998년 시스템 수 준의 평가 방법론을 채택한 접근법을 개발하였다. 이 방법론의 주 특징은 특정 요인의 규명에 근거한 시스템 수준의 신뢰성 예측으로 PGF(Process grading factor)와 소프트웨어 고장률 등을 포함한다는 점이다. 그 다음해에 새로운 시스템 신뢰성 평가에 대한 연구를 바탕으로 소프트웨어화 하였으며 2000년 1월 새로운 방법론 도구인 PRISM이 출시되었다. 그 이후 PRISM은 새로운 버전을 출시하며 발전하였으며 버전 1.5까지 출시되었다. (3) 217-Plus - 개요 : 2006년 RIAC는 DoD의 자금 지원 하에 PRISM의 차세대 버전이며 MIL-HDBK-217을 대 체할 예측 방법론으로 217Plus를 출시하였으며 PRISM보다 더 포괄적인 12가지 부품 모형들을 포함 한다. 구체적으로 설명하면 기존에 존재하는 6 종류에 새로운 6종류를 추가하고 IC는 plastic encapsulate와 hermite등으로 확대하였다. 또 한 가지 주요한 특징은 PRISM이 특정 사용자 community에 의해 출발하였기 때문에 근간 데이터나 모형식들의 상세 내용들이 일반인에게 공개되지 않았던 반면 217-Plus는 공식적으로 공개됨으로써 사용자나 분석자들이 세부 모형 식들을 자유롭게 - 29 -

Page30
파악할 수 있다는 점이다. - 217-Plus만의 특징 : MIL-HDBK-217 등 전통적 모형들은 부품에 대한 고장률 모형을 중심으로 시스템 고장률을 독립 지수분포들에 근거하여 (묵시적으로)단순 합에 의해 산정한다. 217-Plus에서 는 부품 수준의 12개 모형에 추가로 독립적인 시스템 모형이 존재한다. 시스템 모형은 부품들의 고장 률을 근거로 하되 여러 고장요인들 (설계, 제조, 부품, 시스템 관리, 마모, 유도(induced), 전기적 과부 하 등)에 대한 프로세스 등급화(processgrading)과정을 거쳐 개선한다. 최종적으로 과거의 경험이나 필드 데이터를 이용하여 앞서 개선한 고장률에 통합해가는 Bayesian 기법을 포함하는 종합적인 방법 론으로 내용 및 적용과정이 전통적 방법론에 비해 훨씬 복잡하다. 그리고 DoD는 미래 217Plus 출시 나 보완과 관련하여 계획되는 데이터 수집 및 분석, 그리고 모형화 노력 등을 계속 지원함을 약속했 다. 2) 신뢰성 모델 기반 신뢰성 프로세스 개발 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스는 고객 신뢰성 요구 목표 설정 연구에서 도 출된 결과를 이용하여, 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스를 개발하였고 이를 실제 소프트웨어 개발 프로세스에 적용하였다. 특히, 신뢰성 확보가 매우 중요한 국방 무기체계에서의 소프트 웨어의 신뢰성 평가 프로세스를 정의하고 이에 따른 가이드를 제시하였다. 이를 위하여 일반적인 소프트 웨어 개발 프로세스 상에서의 신뢰성 보증 관련 활동들을 조사하여 소프트웨어 개발 프로세스 관점에서 소프트웨어 신뢰성을 보장하기 위해 표준으로 제시된 IEEE 1633을 기반으로 하는 신뢰성 보장 활동을 제시하였다. IEEE 1633은 소프트웨어 신뢰성을 수행하기 위한 Practice들을 정리한 표준으로 아래와 같 은 13가지 절차를 이용하여 소프트웨어 개발 전반에 신뢰성 보증 활동을 수행하도록 권장하고 있다. (1) 대상 애플리케이션 식별 (Identify application) (2) 소프트웨어 요구사항 명세(Specify the requirement) (3) 요구사항 할당 (Allocate the requirement) (4) 신뢰도 위험 평가 수행 (Make a reliability risk assessment) (5) 소프트웨어 에러, 결함, 실패 정의 (Define errors, faults, and failures) (6) 운영 환경 정의 (Characterize the operational environment) (7) 테스트 수행 방법 선택 (Select tests) (8) 소프트웨어 신뢰성 모델 선택 (Select models) (9) 실패 데이터 수집 (Collect data) (10) 통계 기법을 이용한 신뢰성 모델의 파라미터 추정(Estimate parameters) (11) 선정된 모델에 대한 성능 검증 (Validata the model) (12) 신뢰성 평가 및 예측 분석 활동 (Perform assessment and prediction analysis) (13) 출시 전까지 남아있는 테스트 시간 예측 (Forecast additional test duration) - 30 -

Page30

파악할 수 있다는 점이다. - 217-Plus만의 특징 : MIL-HDBK-217 등 전통적 모형들은 부품에 대한 고장률 모형을 중심으로 시스템 고장률을 독립 지수분포들에 근거하여 (묵시적으로)단순 합에 의해 산정한다. 217-Plus에서 는 부품 수준의 12개 모형에 추가로 독립적인 시스템 모형이 존재한다. 시스템 모형은 부품들의 고장 률을 근거로 하되 여러 고장요인들 (설계, 제조, 부품, 시스템 관리, 마모, 유도(induced), 전기적 과부 하 등)에 대한 프로세스 등급화(processgrading)과정을 거쳐 개선한다. 최종적으로 과거의 경험이나 필드 데이터를 이용하여 앞서 개선한 고장률에 통합해가는 Bayesian 기법을 포함하는 종합적인 방법 론으로 내용 및 적용과정이 전통적 방법론에 비해 훨씬 복잡하다. 그리고 DoD는 미래 217Plus 출시 나 보완과 관련하여 계획되는 데이터 수집 및 분석, 그리고 모형화 노력 등을 계속 지원함을 약속했 다. 2) 신뢰성 모델 기반 신뢰성 프로세스 개발 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스는 고객 신뢰성 요구 목표 설정 연구에서 도 출된 결과를 이용하여, 내장형 소프트웨어 신뢰성 보증을 위한 신뢰성 프로세스를 개발하였고 이를 실제 소프트웨어 개발 프로세스에 적용하였다. 특히, 신뢰성 확보가 매우 중요한 국방 무기체계에서의 소프트 웨어의 신뢰성 평가 프로세스를 정의하고 이에 따른 가이드를 제시하였다. 이를 위하여 일반적인 소프트 웨어 개발 프로세스 상에서의 신뢰성 보증 관련 활동들을 조사하여 소프트웨어 개발 프로세스 관점에서 소프트웨어 신뢰성을 보장하기 위해 표준으로 제시된 IEEE 1633을 기반으로 하는 신뢰성 보장 활동을 제시하였다. IEEE 1633은 소프트웨어 신뢰성을 수행하기 위한 Practice들을 정리한 표준으로 아래와 같 은 13가지 절차를 이용하여 소프트웨어 개발 전반에 신뢰성 보증 활동을 수행하도록 권장하고 있다. (1) 대상 애플리케이션 식별 (Identify application) (2) 소프트웨어 요구사항 명세(Specify the requirement) (3) 요구사항 할당 (Allocate the requirement) (4) 신뢰도 위험 평가 수행 (Make a reliability risk assessment) (5) 소프트웨어 에러, 결함, 실패 정의 (Define errors, faults, and failures) (6) 운영 환경 정의 (Characterize the operational environment) (7) 테스트 수행 방법 선택 (Select tests) (8) 소프트웨어 신뢰성 모델 선택 (Select models) (9) 실패 데이터 수집 (Collect data) (10) 통계 기법을 이용한 신뢰성 모델의 파라미터 추정(Estimate parameters) (11) 선정된 모델에 대한 성능 검증 (Validata the model) (12) 신뢰성 평가 및 예측 분석 활동 (Perform assessment and prediction analysis) (13) 출시 전까지 남아있는 테스트 시간 예측 (Forecast additional test duration) - 30 -

Page31
또한 국방 도메인의 무기체계 특성상 소홀히 할 수 없는 시스템 안전성(Safety)을 고려할 수 있도록 IEC 61508 기반의 소프트웨어 신뢰성 평가 프로세스를 제안하였다. 다음 그림은 이번 연구를 통해 tailoring 된 신뢰성 평가 프로세스(Software Reliability Assessment Process, SRAP)의 세부 평가 흐름을 보이고 있으며, 이러한 소프트웨어 신뢰성 평가 활동은 모두 기존의 소프트웨어 개발 프로세스와 상호 연결되어 유기적인 관계에 있어야 함을 보이고 있다. [그림 9] SRAP 내부 흐름 및 SW 개발 프로세스와의 연관 다. 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용 내장형 소프트웨어는 순수 소프트웨어와 달리 하드웨어를 기반으로 동작하거나 혹은 하드웨어 장치 들을 제어/관리하는 기능을 담당하기 때문에 시스템 관점에서의 신뢰성 분석/평가가 이루어져야 한다. 이를 고려한 내장형 소프트웨어 신뢰성 분석 및 평가 모델을 개발한다. 1) 하드웨어/소프트웨어 신뢰성 모델의 통합 하드웨어와 소프트웨어 신뢰성 모델링을 통합하는데는 여러 근본적인 문제점들이 존재한다. 그것들 중의 하나가 하드웨어와 소프트웨어의 실패 과정이 완전히 다르다는 사실이다. 우선 하드웨어의 전형 적인 모델링 방법과 실패 과정을 설명하고 소프트웨어에 대해 알아보도록 한다. - 31 -

Page31

또한 국방 도메인의 무기체계 특성상 소홀히 할 수 없는 시스템 안전성(Safety)을 고려할 수 있도록 IEC 61508 기반의 소프트웨어 신뢰성 평가 프로세스를 제안하였다. 다음 그림은 이번 연구를 통해 tailoring 된 신뢰성 평가 프로세스(Software Reliability Assessment Process, SRAP)의 세부 평가 흐름을 보이고 있으며, 이러한 소프트웨어 신뢰성 평가 활동은 모두 기존의 소프트웨어 개발 프로세스와 상호 연결되어 유기적인 관계에 있어야 함을 보이고 있다. [그림 9] SRAP 내부 흐름 및 SW 개발 프로세스와의 연관 다. 내장형 소프트웨어 신뢰성 분석/평가를 위한 모델 개발 및 적용 내장형 소프트웨어는 순수 소프트웨어와 달리 하드웨어를 기반으로 동작하거나 혹은 하드웨어 장치 들을 제어/관리하는 기능을 담당하기 때문에 시스템 관점에서의 신뢰성 분석/평가가 이루어져야 한다. 이를 고려한 내장형 소프트웨어 신뢰성 분석 및 평가 모델을 개발한다. 1) 하드웨어/소프트웨어 신뢰성 모델의 통합 하드웨어와 소프트웨어 신뢰성 모델링을 통합하는데는 여러 근본적인 문제점들이 존재한다. 그것들 중의 하나가 하드웨어와 소프트웨어의 실패 과정이 완전히 다르다는 사실이다. 우선 하드웨어의 전형 적인 모델링 방법과 실패 과정을 설명하고 소프트웨어에 대해 알아보도록 한다. - 31 -

Page33
SW 실패 과정 소프트웨어의 실패 과정은 하드웨어와 근본적인 차이점을 가진다. 가장 명백한 차이점은 소프트웨어 에는 어떠한 물리적 기능저하 과정이 없으며 단지 잘못 된 기능 동작을 유발하는 디자인 결함을 포함 한다는 것이다. 전통적인 하드웨어 신뢰성 모델링은 디자인 결함이 없다는 것을 가정하며 단지 외부 적 기능저하에 기인한 실패에 관심을 가지는 반면 소프트웨어는 물리적 기능 저하가 전혀 없기 때문 에 디자인 결함에 기인한 실패에만 집중한다. 소프트웨어 신뢰성은 보통 하드웨어 신뢰성과 비슷한 방식으로 정의된다. 그러나 시간과 실패가 나타나는 현상 사이의 관계는 하드웨어와 소프트웨어가 서 로 다르다. HW 컴포넌트는 외부 자극에 의해서 실패가 유발된다고 가정하며 실패를 유발하는 외부 자극의 출현 시간을 확률적으로 모델링한다. 하지만 소프트웨어는 내재된 결함의 출현 시간을 확률적 으로 모델링하며 이는 실제적으로 어려운 작업이다. 이러한 내재된 결함의 출현시간은 2가지 소프트 웨어 특성에 의존적이다. - 소프트웨어에 내재된 결함의 수와 위치 - 프로그램에서 다양한 실행 경로의 수행 빈도 이러한 2가지 특성을 높은 정확도와 함께 모델링할 수 있는 종합적인 기법은 존재하지 않으며 대신에 간접적인 방법을 통해 모델링 하려는 시도가 있어왔다. 예를 들어, 소프트웨어의 실패 강도(failure intensity : unit execution time마다 프로그램에서 발견되는 평균 실패 수)의 추정을 통해 내재된 결 함의 수와 위치를 특징지을 수 있으며 실행 경로의 수행 빈도는 Musa가 정의한 운용 프로파일로 특 징지을 수 있다. 아래는 소프트웨어를 모델링하는 3가지 일반적인 방법을 나타내며 모두 소프트웨어 테스팅을 기반으로 한다. 1. Fault seeding : 프로그램에 새로운 결함을 인위적으로 삽입하는 기법. 인위적으로 삽입된 결함들 이 테스팅에 의해 발견되는 비율이 프로그램에 내재된 결함의 비율로 추정된다. 2. Sampling : 예상되는 운용 프로파일에 따라 입력 도메인의 값을 랜덤 샘플링을 통해 추출하고 이 를 통해 프로그램을 테스팅 하는 기법. 실패의 수가 관측되고 프로그램의 신뢰성은 다음과 같이 추정 될 수 있다.  -      관측된실패의수   테스트동안의전체실행수  3. 신뢰도 성장 모형 (Reliability Growth Model) : 소프트웨어가 테스팅과 디버깅을 거침에 따라 소 프트웨어 실패강도에 변화를 지으려는 시도. 다음은 위에서 설명한 하드웨어와 소프트웨어의 신뢰성 영역에 대한 전반적인 비교를 보여주는 표이 다. - 33 -

Page33

SW 실패 과정 소프트웨어의 실패 과정은 하드웨어와 근본적인 차이점을 가진다. 가장 명백한 차이점은 소프트웨어 에는 어떠한 물리적 기능저하 과정이 없으며 단지 잘못 된 기능 동작을 유발하는 디자인 결함을 포함 한다는 것이다. 전통적인 하드웨어 신뢰성 모델링은 디자인 결함이 없다는 것을 가정하며 단지 외부 적 기능저하에 기인한 실패에 관심을 가지는 반면 소프트웨어는 물리적 기능 저하가 전혀 없기 때문 에 디자인 결함에 기인한 실패에만 집중한다. 소프트웨어 신뢰성은 보통 하드웨어 신뢰성과 비슷한 방식으로 정의된다. 그러나 시간과 실패가 나타나는 현상 사이의 관계는 하드웨어와 소프트웨어가 서 로 다르다. HW 컴포넌트는 외부 자극에 의해서 실패가 유발된다고 가정하며 실패를 유발하는 외부 자극의 출현 시간을 확률적으로 모델링한다. 하지만 소프트웨어는 내재된 결함의 출현 시간을 확률적 으로 모델링하며 이는 실제적으로 어려운 작업이다. 이러한 내재된 결함의 출현시간은 2가지 소프트 웨어 특성에 의존적이다. - 소프트웨어에 내재된 결함의 수와 위치 - 프로그램에서 다양한 실행 경로의 수행 빈도 이러한 2가지 특성을 높은 정확도와 함께 모델링할 수 있는 종합적인 기법은 존재하지 않으며 대신에 간접적인 방법을 통해 모델링 하려는 시도가 있어왔다. 예를 들어, 소프트웨어의 실패 강도(failure intensity : unit execution time마다 프로그램에서 발견되는 평균 실패 수)의 추정을 통해 내재된 결 함의 수와 위치를 특징지을 수 있으며 실행 경로의 수행 빈도는 Musa가 정의한 운용 프로파일로 특 징지을 수 있다. 아래는 소프트웨어를 모델링하는 3가지 일반적인 방법을 나타내며 모두 소프트웨어 테스팅을 기반으로 한다. 1. Fault seeding : 프로그램에 새로운 결함을 인위적으로 삽입하는 기법. 인위적으로 삽입된 결함들 이 테스팅에 의해 발견되는 비율이 프로그램에 내재된 결함의 비율로 추정된다. 2. Sampling : 예상되는 운용 프로파일에 따라 입력 도메인의 값을 랜덤 샘플링을 통해 추출하고 이 를 통해 프로그램을 테스팅 하는 기법. 실패의 수가 관측되고 프로그램의 신뢰성은 다음과 같이 추정 될 수 있다.  -      관측된실패의수   테스트동안의전체실행수  3. 신뢰도 성장 모형 (Reliability Growth Model) : 소프트웨어가 테스팅과 디버깅을 거침에 따라 소 프트웨어 실패강도에 변화를 지으려는 시도. 다음은 위에서 설명한 하드웨어와 소프트웨어의 신뢰성 영역에 대한 전반적인 비교를 보여주는 표이 다. - 33 -

Page34
<하드웨어/소프트웨어 신뢰성 영역의 비교> 신뢰성 분야항목 하드웨어 소프트웨어고장 원인 설계, 제품 및 유지 보수 설계 결함시스템 또는 해당 제품이 소모 되 소모(wear out)현상과는 관계 없고장 발생 거나 에너지 관련 현상에 의해 발 이 발생생 반드시 시간에 의존하는 것은 아니다. 시간 함수에 밀접하게 관련 수행 논리 경로에 따라 고장 발생시간 관련 운영시간이 늘어날수록 고장률이 이 에러들을 수반해서 발생떨어지는 것을 목표 신뢰성 성장은 에러들을 검출하거나 정정 활동을 통해 구현외부 환경적 영향에는 상관없이 동작환경 영향 외부 환경적 조건에 많은 영향 내부 환경적 영향에 민감하게 반응물리적인 기반으로부터 이론상 예 환경 스트레스 요소, 설계 지식으예견 견 가능 로 예견 불가 하드웨어/소프트웨어 신뢰성 모델 통합의 요구사항 하드웨어와 소프트웨어 실패를 통합 하는 신뢰성 모델을 개발하기 위해 요구되는 것은 아래와 같다. 첫 번째로, 하드웨어 신뢰성 모델링 방법과 소프트웨어 모델링 방법이 공통된 개념을 가질 수 있도록 연결하는 것이다. 그 예로 소프트웨어를 하드웨어 컴포넌트 중의 하나로 처리하면서 통합 모델을 개 발 할 수 있다. 주의해야 할 점은 소프트웨어 실패 강도에 사용되는 시간 단위와 하드웨어 실패율에 서 사용되는 시간 단위에 대해 일관성을 유지해야 한다는 점이다. 두 번째로, 신뢰성 성장 모델로부터 추정될 수 있는 소프트웨어 실패 강도의 타당성은 소프트웨어의 실패 행위가 모델이 전제하는 가정 사항들에 얼마나 잘 부합하느냐에 달려 있다. 이러한 관점에서 소프트웨어를 위한 적절한 신뢰성 성 장 모델의 선택이 통합된 하드웨어/소프트웨어 신뢰성 모델 개발에서 중요하다. 세 번째로, 신뢰성 성 장 모델에서의 실패 강도 추정은 소프트웨어 테스팅과 디버깅 과정에서 수집된 데이터에 의해 결정되 며 테스팅의 결과는 운용 프로파일을 따르기 때문에 정확한 운용파일을 결정하는 효과적인 방법이 요 구된다. 하드웨어 모델링 방법의 대부분은 컴포넌트들의 실패가 서로 독립적이라는 것을 가정한다. 하지만 하드웨어와 소프트웨어 컴포넌트가 존재하는 통합된 모델에서 이는 독립적으로 실패되는 것이 아니 다. 예를 들어 소프트웨어 컴포넌트가 실행되고 있는 프로세서의 실패는 소프트웨어 컴포넌트의 기능 적 실패를 유발할 수 있으며 반대로 하드웨어 구조 변경이나 결함 복구를 통제하는 소프트웨어의 실 패는 시스템 하드웨어 행동에 영향을 미칠 수 있다. 이러한 점은 하드웨어와 소프트웨어 컴포넌트들 - 34 -

Page34

<하드웨어/소프트웨어 신뢰성 영역의 비교> 신뢰성 분야항목 하드웨어 소프트웨어고장 원인 설계, 제품 및 유지 보수 설계 결함시스템 또는 해당 제품이 소모 되 소모(wear out)현상과는 관계 없고장 발생 거나 에너지 관련 현상에 의해 발 이 발생생 반드시 시간에 의존하는 것은 아니다. 시간 함수에 밀접하게 관련 수행 논리 경로에 따라 고장 발생시간 관련 운영시간이 늘어날수록 고장률이 이 에러들을 수반해서 발생떨어지는 것을 목표 신뢰성 성장은 에러들을 검출하거나 정정 활동을 통해 구현외부 환경적 영향에는 상관없이 동작환경 영향 외부 환경적 조건에 많은 영향 내부 환경적 영향에 민감하게 반응물리적인 기반으로부터 이론상 예 환경 스트레스 요소, 설계 지식으예견 견 가능 로 예견 불가 하드웨어/소프트웨어 신뢰성 모델 통합의 요구사항 하드웨어와 소프트웨어 실패를 통합 하는 신뢰성 모델을 개발하기 위해 요구되는 것은 아래와 같다. 첫 번째로, 하드웨어 신뢰성 모델링 방법과 소프트웨어 모델링 방법이 공통된 개념을 가질 수 있도록 연결하는 것이다. 그 예로 소프트웨어를 하드웨어 컴포넌트 중의 하나로 처리하면서 통합 모델을 개 발 할 수 있다. 주의해야 할 점은 소프트웨어 실패 강도에 사용되는 시간 단위와 하드웨어 실패율에 서 사용되는 시간 단위에 대해 일관성을 유지해야 한다는 점이다. 두 번째로, 신뢰성 성장 모델로부터 추정될 수 있는 소프트웨어 실패 강도의 타당성은 소프트웨어의 실패 행위가 모델이 전제하는 가정 사항들에 얼마나 잘 부합하느냐에 달려 있다. 이러한 관점에서 소프트웨어를 위한 적절한 신뢰성 성 장 모델의 선택이 통합된 하드웨어/소프트웨어 신뢰성 모델 개발에서 중요하다. 세 번째로, 신뢰성 성 장 모델에서의 실패 강도 추정은 소프트웨어 테스팅과 디버깅 과정에서 수집된 데이터에 의해 결정되 며 테스팅의 결과는 운용 프로파일을 따르기 때문에 정확한 운용파일을 결정하는 효과적인 방법이 요 구된다. 하드웨어 모델링 방법의 대부분은 컴포넌트들의 실패가 서로 독립적이라는 것을 가정한다. 하지만 하드웨어와 소프트웨어 컴포넌트가 존재하는 통합된 모델에서 이는 독립적으로 실패되는 것이 아니 다. 예를 들어 소프트웨어 컴포넌트가 실행되고 있는 프로세서의 실패는 소프트웨어 컴포넌트의 기능 적 실패를 유발할 수 있으며 반대로 하드웨어 구조 변경이나 결함 복구를 통제하는 소프트웨어의 실 패는 시스템 하드웨어 행동에 영향을 미칠 수 있다. 이러한 점은 하드웨어와 소프트웨어 컴포넌트들 - 34 -

Page35
이 상호 작용하는 상황이나 서로의 실패에 영향을 미치는 상황을 표현할 수 있는 모델링 방법이 필요 하다는 것을 의미한다. 2) 하드웨어 소프트웨어 상호작용을 고려한 시스템 신뢰성에 대한 고찰 연구 수행 내용 내장형 시스템에서의 실패는 순수 하드웨어, 소프트웨어에 의한 실패뿐만 아니라 하드웨어와 소프트 웨어의 상호작용에 의한 실패 또한 빈번히 발생한다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 고려하여 이러한 실패가 전체 시스템 신뢰 성에 미치는 영향을 분석하여 평가하였다. 본 연구는 기존 연구의 하드웨어와 소프트웨어를 독립적으 로 두고 신뢰성을 측정함으로 발생하는 문제점을 제시하고 그 해결책으로 하드웨어-소프트웨어 상호 작용에서 소프트웨어에 의한 하드웨어 실패까지 고려한 통합 신뢰성 모델을 제안 한다. 통합 시스템 신뢰성 모델은 기존에 고려되지 못했던 소프트웨어 연관 하드웨어 실패 현상을 마코프 기반 신뢰성 모델을 통해 나타낸다. 마코프 프로세스는 시간에 따른 시스템의 상태를 설명하기 위해 사용되며 소 프트웨어 연관 하드웨어 실패 현상은 아래의 그림과 같이 6개의 상태를 가지는 CTMC(Continuous-Time Markov Chain)로 모델링 될 수 있다. [그림 11] SW 연관 HW 실패 상태전이 다이어그램 사례 연구를 통해 기존의 시스템 신뢰성 모델에서 간과되었던 부분이 있음을 알 수 있으며 이러한 소프트웨어 연관 하드웨어 실패를 고려함으로써 전체 시스템 신뢰성을 보다 정확히 추정할 수 있었다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 본 연구에서 고려하여 모델링 방법을 제시하였으며 이러한 실패가 전체 시스템 - 35 -

Page35

이 상호 작용하는 상황이나 서로의 실패에 영향을 미치는 상황을 표현할 수 있는 모델링 방법이 필요 하다는 것을 의미한다. 2) 하드웨어 소프트웨어 상호작용을 고려한 시스템 신뢰성에 대한 고찰 연구 수행 내용 내장형 시스템에서의 실패는 순수 하드웨어, 소프트웨어에 의한 실패뿐만 아니라 하드웨어와 소프트 웨어의 상호작용에 의한 실패 또한 빈번히 발생한다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 고려하여 이러한 실패가 전체 시스템 신뢰 성에 미치는 영향을 분석하여 평가하였다. 본 연구는 기존 연구의 하드웨어와 소프트웨어를 독립적으 로 두고 신뢰성을 측정함으로 발생하는 문제점을 제시하고 그 해결책으로 하드웨어-소프트웨어 상호 작용에서 소프트웨어에 의한 하드웨어 실패까지 고려한 통합 신뢰성 모델을 제안 한다. 통합 시스템 신뢰성 모델은 기존에 고려되지 못했던 소프트웨어 연관 하드웨어 실패 현상을 마코프 기반 신뢰성 모델을 통해 나타낸다. 마코프 프로세스는 시간에 따른 시스템의 상태를 설명하기 위해 사용되며 소 프트웨어 연관 하드웨어 실패 현상은 아래의 그림과 같이 6개의 상태를 가지는 CTMC(Continuous-Time Markov Chain)로 모델링 될 수 있다. [그림 11] SW 연관 HW 실패 상태전이 다이어그램 사례 연구를 통해 기존의 시스템 신뢰성 모델에서 간과되었던 부분이 있음을 알 수 있으며 이러한 소프트웨어 연관 하드웨어 실패를 고려함으로써 전체 시스템 신뢰성을 보다 정확히 추정할 수 있었다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 본 연구에서 고려하여 모델링 방법을 제시하였으며 이러한 실패가 전체 시스템 - 35 -

Page36
신뢰성에 미치는 영향을 분석하여 평가하였다. 이를 통해 시스템 신뢰성을 보다 정확히 추정 될 수 있으며 전체 시스템의 효과적인 품질 관리가 가능함을 보였다 [13]. 하드웨어와 소프트웨어 상호작용 모델링 시스템에서 내부 컴포넌트들의 실패가 반드시 시스템 실패로 이어지는 것은 아니기 때문에 시스템 관점에서 신뢰성 모델링 기법들이 요구된다. 이번 절에서는 여러 하드웨어, 소프트웨어 컴포넌트들로 구성된 시스템의 통합 신뢰성 모델에 대해 알아보고자 한다. 1) 시스템 실패 분류 전체 시스템은 아래와 같은 상태를 가지며 전체 시스템 실패는 4가지 형태로 분류된다. (1) 정상동작 상태 : 시스템이 정상 동작하는 상태 (2) 기능저하 상태 : 시스템의 특정 컴포넌트가 실패했지만 전체 시스템은 정상 동작하는 상태(Partial failure 상태) (3) 시스템 실패 상태 : 시스템이 요구되는 기능을 수행하지 못하는 상태 가) 소프트웨어 실패 : 하드웨어와 상관없이 발생한 소프트웨어 실패가 시스템 실패로 이어짐 나) 하드웨어 실패 : 소프트웨어와 상관없이 발생한 하드웨어 실패가 시스템 실패로 이어짐 다) 하드웨어 연관 소프트웨어 실패 : 기능저하 된 특정 하드웨어 컴포넌트가 소프트웨어 실행에 영향을 미쳐 시스템 실패로 이어짐 (예 : 디스크 상의 bad sector난 부분에 접근을 해서 소프트웨어가 잘못된 동작을 하는 경우 등) 라) 소프트웨어 연관 하드웨어 실패 : 기능저하 된 특정 소프트웨어 컴포넌트가 하드웨어 실행에 영향을 미쳐 시스템 실패로 이어짐 (예 : SW의 잘못된 값 전달이 CPU의 과부하로 이어져 시스템을 멈추는 경우 등) 통합 시스템 신뢰성 모델은 Teng&Pham의 모델을 참고하여 개발되었으며 기존에 고려되지 못했던 소프트웨어 연관 하드웨어 실패 현상을 마코프 기반 신뢰성 모델을 통해 나타낸다. 마코프 프로세스는 시스템이 일정한 시간으로 진화하는 과정을 설명하기 위해 주로 사용되며 본 연구에서도 시간에 따른 시스템의 상태를 설명하기 위해 마코프 프로세스를 사용한다. 여기서 하드웨어 실패들은 고장시간이나 대기시간을 모형화하는데 주로 사용되는 와이블(Weibull)모 델을 사용하며 소프트웨어 실패들은 NHPP(Non-Homogeneous Poisson Process)로 모델링 될 수 있 다고 가정한다. 그리고 하드웨어 연관 소프트웨어 실패들은 Teng&Pham의 신뢰성 모델을 이용하여 모델링 될 수 있다고 본다. 위에서의 4가지 시스템 실패 상태들은 독립적으로 발생한다고 가정한다. - 36 -

Page36

신뢰성에 미치는 영향을 분석하여 평가하였다. 이를 통해 시스템 신뢰성을 보다 정확히 추정 될 수 있으며 전체 시스템의 효과적인 품질 관리가 가능함을 보였다 [13]. 하드웨어와 소프트웨어 상호작용 모델링 시스템에서 내부 컴포넌트들의 실패가 반드시 시스템 실패로 이어지는 것은 아니기 때문에 시스템 관점에서 신뢰성 모델링 기법들이 요구된다. 이번 절에서는 여러 하드웨어, 소프트웨어 컴포넌트들로 구성된 시스템의 통합 신뢰성 모델에 대해 알아보고자 한다. 1) 시스템 실패 분류 전체 시스템은 아래와 같은 상태를 가지며 전체 시스템 실패는 4가지 형태로 분류된다. (1) 정상동작 상태 : 시스템이 정상 동작하는 상태 (2) 기능저하 상태 : 시스템의 특정 컴포넌트가 실패했지만 전체 시스템은 정상 동작하는 상태(Partial failure 상태) (3) 시스템 실패 상태 : 시스템이 요구되는 기능을 수행하지 못하는 상태 가) 소프트웨어 실패 : 하드웨어와 상관없이 발생한 소프트웨어 실패가 시스템 실패로 이어짐 나) 하드웨어 실패 : 소프트웨어와 상관없이 발생한 하드웨어 실패가 시스템 실패로 이어짐 다) 하드웨어 연관 소프트웨어 실패 : 기능저하 된 특정 하드웨어 컴포넌트가 소프트웨어 실행에 영향을 미쳐 시스템 실패로 이어짐 (예 : 디스크 상의 bad sector난 부분에 접근을 해서 소프트웨어가 잘못된 동작을 하는 경우 등) 라) 소프트웨어 연관 하드웨어 실패 : 기능저하 된 특정 소프트웨어 컴포넌트가 하드웨어 실행에 영향을 미쳐 시스템 실패로 이어짐 (예 : SW의 잘못된 값 전달이 CPU의 과부하로 이어져 시스템을 멈추는 경우 등) 통합 시스템 신뢰성 모델은 Teng&Pham의 모델을 참고하여 개발되었으며 기존에 고려되지 못했던 소프트웨어 연관 하드웨어 실패 현상을 마코프 기반 신뢰성 모델을 통해 나타낸다. 마코프 프로세스는 시스템이 일정한 시간으로 진화하는 과정을 설명하기 위해 주로 사용되며 본 연구에서도 시간에 따른 시스템의 상태를 설명하기 위해 마코프 프로세스를 사용한다. 여기서 하드웨어 실패들은 고장시간이나 대기시간을 모형화하는데 주로 사용되는 와이블(Weibull)모 델을 사용하며 소프트웨어 실패들은 NHPP(Non-Homogeneous Poisson Process)로 모델링 될 수 있 다고 가정한다. 그리고 하드웨어 연관 소프트웨어 실패들은 Teng&Pham의 신뢰성 모델을 이용하여 모델링 될 수 있다고 본다. 위에서의 4가지 시스템 실패 상태들은 독립적으로 발생한다고 가정한다. - 36 -

Page37
[그림 12] 개략적인 통합 시스템 신뢰성 모델링 방법 상호작용 모델링의 적용 사례 연구를 수행하기 위해서는 위에서 정의한 실패 데이터가 수집되어야 한다. 하지만 현재 데이터 수집의 어려움으로 Teng&Pham의 연구에서 사용된 데이터를 사용하였으며 하드웨어 연관 소프트웨어 실패의 30%가 소프트웨어 연관 하드웨어 실패라는 가정을 두고 실험을 하였다. 대상 시스템은 네트워크를 구축하기 위해 사용되는 기지국 제어기(Base Station Controller)라는 통신 시스템이며 배치된 각 필드에서 trouble ticket을 받아서 각 실패의 유형을 분석 하였다. 이러한 실패 데이터로부터 각각의 파라미터 값이 추정되며 기존의 연구와 본 연구에서 제시한 모델링 방법을 비교한 신뢰성 결과는 아래의 그림과 같이 나타낼 수있다. 첫 번째 그림은 실패 유형별 신뢰성 함수 값의 추이를 나타낸다. 여러 유형의 실패 중 하드웨어 실패가 전체 시스템 신뢰성에 많은 영향을 미친다는 것을 알 수 있으며 시스템이 300일의 임무 시간 동안 실패 없이 동작할 확률은 66%임을 알 수 있다. 두 번째 그림은 기존의 하드웨어, 소프트웨어 실패만 고려한 독립 모델과 하드웨어 연관 소프트웨어 실패까지 고려한 Teng&Pham 모델, 그리고 본 연구의 모델을 비교한 그래프이다. 시간에 따른 그래프의 차이를 통해 기존의 시스템 신뢰성 모델에서 간과된 부분이 있음을 알 수 있으며 이러한 소프트웨어 연관 하드웨어 실패를 본 연구에서 고려함으로써 전체 시스템 신뢰성을 보다 정확히 추정할 수 있다. 내장형 시스템에서의 실패는 순수 하드웨어, 소프트웨어에 의한 실패뿐만 아니라 하드웨어와 소프트웨어의 상호작용에 의한 실패 또한 빈번히 발생한다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 본 연구에서 고려하여 모델링 방법을 제시하였으며 이러한 실패가 전체 시스템 - 37 -

Page37

[그림 12] 개략적인 통합 시스템 신뢰성 모델링 방법 상호작용 모델링의 적용 사례 연구를 수행하기 위해서는 위에서 정의한 실패 데이터가 수집되어야 한다. 하지만 현재 데이터 수집의 어려움으로 Teng&Pham의 연구에서 사용된 데이터를 사용하였으며 하드웨어 연관 소프트웨어 실패의 30%가 소프트웨어 연관 하드웨어 실패라는 가정을 두고 실험을 하였다. 대상 시스템은 네트워크를 구축하기 위해 사용되는 기지국 제어기(Base Station Controller)라는 통신 시스템이며 배치된 각 필드에서 trouble ticket을 받아서 각 실패의 유형을 분석 하였다. 이러한 실패 데이터로부터 각각의 파라미터 값이 추정되며 기존의 연구와 본 연구에서 제시한 모델링 방법을 비교한 신뢰성 결과는 아래의 그림과 같이 나타낼 수있다. 첫 번째 그림은 실패 유형별 신뢰성 함수 값의 추이를 나타낸다. 여러 유형의 실패 중 하드웨어 실패가 전체 시스템 신뢰성에 많은 영향을 미친다는 것을 알 수 있으며 시스템이 300일의 임무 시간 동안 실패 없이 동작할 확률은 66%임을 알 수 있다. 두 번째 그림은 기존의 하드웨어, 소프트웨어 실패만 고려한 독립 모델과 하드웨어 연관 소프트웨어 실패까지 고려한 Teng&Pham 모델, 그리고 본 연구의 모델을 비교한 그래프이다. 시간에 따른 그래프의 차이를 통해 기존의 시스템 신뢰성 모델에서 간과된 부분이 있음을 알 수 있으며 이러한 소프트웨어 연관 하드웨어 실패를 본 연구에서 고려함으로써 전체 시스템 신뢰성을 보다 정확히 추정할 수 있다. 내장형 시스템에서의 실패는 순수 하드웨어, 소프트웨어에 의한 실패뿐만 아니라 하드웨어와 소프트웨어의 상호작용에 의한 실패 또한 빈번히 발생한다. 이와 같이 분명히 발생함에도 불구하고 기존의 연구에서 간과되었던 소프트웨어 연관 하드웨어 실패들을 본 연구에서 고려하여 모델링 방법을 제시하였으며 이러한 실패가 전체 시스템 - 37 -

Page38
신뢰성에 미치는 영향을 분석하여 평가하였다. 향 후에는 실제 산업 현장에서 발생하는 하드웨어와 소프트웨어 상호작용에 의한 실패 데이터를 수집하여 모델에 적용해 볼 것이며 신뢰성에 미치는 영향을 다각도로 분석할 것이다. 이를 고려함으로써 시스템 신뢰성을 보다 정확히 추정 할 수 있으며 전체 시스템의 효과적인 품질 관리가 가능할 것이다. [그림 13] 실패 유형별 신뢰성 함수 [그림 14] 시스템 신뢰성 비교 3) 하드웨어 기반 소프트웨어 실패를 고려한 내장형 소프트웨어 신뢰성 연구 연구 수행 내용 내장형 시스템에서 소프트웨어는 하드웨어와 다양한 상호작용이 발생하고 하드웨어에 영향을 받아 실 패가 발생함에도 기존의 연구에서는 이러한 하드웨어 기능저하로 발생하는 추가적인 소프트웨어 실패 들을 간과하였다. 이러한 하드웨어로 인한 소프트웨어 실패는 실패 현상이 근본적으로 다르기 때문에 - 38 -

Page38

신뢰성에 미치는 영향을 분석하여 평가하였다. 향 후에는 실제 산업 현장에서 발생하는 하드웨어와 소프트웨어 상호작용에 의한 실패 데이터를 수집하여 모델에 적용해 볼 것이며 신뢰성에 미치는 영향을 다각도로 분석할 것이다. 이를 고려함으로써 시스템 신뢰성을 보다 정확히 추정 할 수 있으며 전체 시스템의 효과적인 품질 관리가 가능할 것이다. [그림 13] 실패 유형별 신뢰성 함수 [그림 14] 시스템 신뢰성 비교 3) 하드웨어 기반 소프트웨어 실패를 고려한 내장형 소프트웨어 신뢰성 연구 연구 수행 내용 내장형 시스템에서 소프트웨어는 하드웨어와 다양한 상호작용이 발생하고 하드웨어에 영향을 받아 실 패가 발생함에도 기존의 연구에서는 이러한 하드웨어 기능저하로 발생하는 추가적인 소프트웨어 실패 들을 간과하였다. 이러한 하드웨어로 인한 소프트웨어 실패는 실패 현상이 근본적으로 다르기 때문에 - 38 -

Page39
기존의 SW 모델링 기법에는 사용될 수 없지만 그냥 소프트웨어 실패로 간주되어 사용되고 있는 실정 이다. 만약 이러한 HW related SW 실패 데이터를 제외시킨다면 이는 소프트웨어 신뢰성이 과대평가 되는 결과를 초래한다. 그리고 전체 시스템 신뢰성 모델의 예측 정확도도 저하될 수 있다. 기존의 Markov 모델링 방법론은 제품이 완성된 다음의 필드에서의 실패 데이터를 활용하여 현 시스템의 신 뢰성을 파악한다. 이는 누적 실패수나 실패 강도등 유용한 데이터를 얻는 것이 제한적이다. [그림 15] 하드웨어 연관 소프트웨어 신뢰성 모델링 개요 새롭게 제안하는 모델은 하드웨어 연관 소프트웨어 실패가 랜덤하게 발생한다고 가정하는 Random based model과 Weibull 형태에 기반한다고 가정하는 Weibull based model로 나눌 수 있다. 이러한 가정은 외부적인 조건을 고려한 것으로 하드웨어의 환경적 요인에 의한 기능 저하는 랜덤하게 발생한 다는 사실 (즉, 실패가 발생하는 현상이 균일 분포를 따른다)에 기반을 둔다. 그리고 하드웨어 기능 저하 현상을 설명하기 위해 Weibull Process가 모델링에 종종 사용된다는 사실에 기반을 한다. 각 모 델의 Mean value function (MVF) 은 아래와 같이 정의 된다 [13]. - 39 -

Page39

기존의 SW 모델링 기법에는 사용될 수 없지만 그냥 소프트웨어 실패로 간주되어 사용되고 있는 실정 이다. 만약 이러한 HW related SW 실패 데이터를 제외시킨다면 이는 소프트웨어 신뢰성이 과대평가 되는 결과를 초래한다. 그리고 전체 시스템 신뢰성 모델의 예측 정확도도 저하될 수 있다. 기존의 Markov 모델링 방법론은 제품이 완성된 다음의 필드에서의 실패 데이터를 활용하여 현 시스템의 신 뢰성을 파악한다. 이는 누적 실패수나 실패 강도등 유용한 데이터를 얻는 것이 제한적이다. [그림 15] 하드웨어 연관 소프트웨어 신뢰성 모델링 개요 새롭게 제안하는 모델은 하드웨어 연관 소프트웨어 실패가 랜덤하게 발생한다고 가정하는 Random based model과 Weibull 형태에 기반한다고 가정하는 Weibull based model로 나눌 수 있다. 이러한 가정은 외부적인 조건을 고려한 것으로 하드웨어의 환경적 요인에 의한 기능 저하는 랜덤하게 발생한 다는 사실 (즉, 실패가 발생하는 현상이 균일 분포를 따른다)에 기반을 둔다. 그리고 하드웨어 기능 저하 현상을 설명하기 위해 Weibull Process가 모델링에 종종 사용된다는 사실에 기반을 한다. 각 모 델의 Mean value function (MVF) 은 아래와 같이 정의 된다 [13]. - 39 -

Page41
사용 가능하다. <기존 모델과 제안한 모델의 비교> 4) UML 모델 기반의 소프트웨어 신뢰성 예측 기법 제안 기존의 소프트웨어 구조 기반 화이트박스 신뢰성 모델 컴포넌트 기반 신뢰성 모델(Component-based Reliability Model)은 소프트웨어의 구조를 고려하 는 모델인 화이트 박스 모델로써 소프트웨어의 서로 다른 모듈을 위해 획득된 추정치들의 결합으로 소프트웨어의 신뢰성 추정이 이루어진다. 다른 이름으로는 Architecture-based model이라고도 불 린다. 소프트웨어의 재사용이 점점 더 중요하게 다루어지고 있는 시점에서 조직들은 큰 응용 프로 그램에서 컴포넌트의 부분들을 재사용하기 때문에 기존의 블랙박스 모델들은 이러한 컴포넌트 기반 의 소프트웨어 시스템에는 적합하지 않다. 그렇기 때문에 소프트웨어 컴포넌트들을 분석하기 위해 새로운 모델링 기법이 필요하였으며 화이트 박스 기반 신뢰성 모델이 블랙 박스 모델을 대신하게 되었다. 컴포넌트 기반의 소프트웨어 시스템을 정량적으로 평가하기 위한 Architecture-based model이 등장하게 된 동기는 다음과 같다 [17]. 재사용 가능하거나 COTS(Commercial off-the-shelf, 상용기성품) 소프트웨어 컴포넌트들로 구성된 어플리케이션의 신뢰성과 성능을 평가하기 위한 기법 개발의 필요성. 시스템 신뢰성 및 성능이 어떻게 시스템 컴포넌트의 신뢰성, 성능 그리고 상호작용에 의존하게 되는지의 이해. - 41 -

Page41

사용 가능하다. <기존 모델과 제안한 모델의 비교> 4) UML 모델 기반의 소프트웨어 신뢰성 예측 기법 제안 기존의 소프트웨어 구조 기반 화이트박스 신뢰성 모델 컴포넌트 기반 신뢰성 모델(Component-based Reliability Model)은 소프트웨어의 구조를 고려하 는 모델인 화이트 박스 모델로써 소프트웨어의 서로 다른 모듈을 위해 획득된 추정치들의 결합으로 소프트웨어의 신뢰성 추정이 이루어진다. 다른 이름으로는 Architecture-based model이라고도 불 린다. 소프트웨어의 재사용이 점점 더 중요하게 다루어지고 있는 시점에서 조직들은 큰 응용 프로 그램에서 컴포넌트의 부분들을 재사용하기 때문에 기존의 블랙박스 모델들은 이러한 컴포넌트 기반 의 소프트웨어 시스템에는 적합하지 않다. 그렇기 때문에 소프트웨어 컴포넌트들을 분석하기 위해 새로운 모델링 기법이 필요하였으며 화이트 박스 기반 신뢰성 모델이 블랙 박스 모델을 대신하게 되었다. 컴포넌트 기반의 소프트웨어 시스템을 정량적으로 평가하기 위한 Architecture-based model이 등장하게 된 동기는 다음과 같다 [17]. 재사용 가능하거나 COTS(Commercial off-the-shelf, 상용기성품) 소프트웨어 컴포넌트들로 구성된 어플리케이션의 신뢰성과 성능을 평가하기 위한 기법 개발의 필요성. 시스템 신뢰성 및 성능이 어떻게 시스템 컴포넌트의 신뢰성, 성능 그리고 상호작용에 의존하게 되는지의 이해. - 41 -

Page42
컴포넌트들과 인터페이스들의 신뢰성이 어플리케이션 신뢰성에 얼마나 민감하게 반응하는지에 대 한 연구. 크리티컬한 컴포넌트들과 인터페이스들을 식별하는 프로세스 지원. 소프트웨어 개발 생명 주기에서 정량적으로 분석하기 위한 기법 개발 필요성. 컴포넌트 기반 신뢰성 모델은 컴포넌트들의 정보로부터 시스템 신뢰성을 계산할 수 있으며 시스템 신뢰성을 규정하고 컴포넌트들에 할당된 신뢰성을 계산하기 위해 사용될 수 있다. 컴포넌트 기반 신뢰성 모델은 아래 그림과 같이 크게 State-based models, Path-based models, and Additive models 3가지로 나누어진다. [그림 16] Component based models (1) State-based models State 기반 모델은 시스템의 구조를 표현하기 위해 제어흐름 그래프(Control Flow Graph)를 사용 한다. 컴포넌트 기반 소프트웨어 신뢰성 모델들은 컴포넌트들의 실패는 독립적이며 컴포넌트의 실 패는 시스템의 실패로 연결된다고 가정하고 있다. 하드웨어의 시스템 신뢰성 측면에서 보면 모든 컴포넌트들은 계속적으로 작동되고 있음을 고려하여 이러한 시스템의 신뢰성은 다음과 같은 식으로 표현이 된다.   , R i : 각 컴포넌트의 신뢰성    소프트웨어 시스템 신뢰성에서의 핵심은 컴포넌트들의 이용성과 이들을 실행하는 동안 각 컴포넌트 의 부하를 어떻게 설명하는가이다 . - 42 -

Page42

컴포넌트들과 인터페이스들의 신뢰성이 어플리케이션 신뢰성에 얼마나 민감하게 반응하는지에 대 한 연구. 크리티컬한 컴포넌트들과 인터페이스들을 식별하는 프로세스 지원. 소프트웨어 개발 생명 주기에서 정량적으로 분석하기 위한 기법 개발 필요성. 컴포넌트 기반 신뢰성 모델은 컴포넌트들의 정보로부터 시스템 신뢰성을 계산할 수 있으며 시스템 신뢰성을 규정하고 컴포넌트들에 할당된 신뢰성을 계산하기 위해 사용될 수 있다. 컴포넌트 기반 신뢰성 모델은 아래 그림과 같이 크게 State-based models, Path-based models, and Additive models 3가지로 나누어진다. [그림 16] Component based models (1) State-based models State 기반 모델은 시스템의 구조를 표현하기 위해 제어흐름 그래프(Control Flow Graph)를 사용 한다. 컴포넌트 기반 소프트웨어 신뢰성 모델들은 컴포넌트들의 실패는 독립적이며 컴포넌트의 실 패는 시스템의 실패로 연결된다고 가정하고 있다. 하드웨어의 시스템 신뢰성 측면에서 보면 모든 컴포넌트들은 계속적으로 작동되고 있음을 고려하여 이러한 시스템의 신뢰성은 다음과 같은 식으로 표현이 된다.   , R i : 각 컴포넌트의 신뢰성    소프트웨어 시스템 신뢰성에서의 핵심은 컴포넌트들의 이용성과 이들을 실행하는 동안 각 컴포넌트 의 부하를 어떻게 설명하는가이다 . - 42 -

Page43
(2) Path-based models 상태 기반 모델과 유사한 모델로 소프트웨어의 구조를 명시적으로 고려하며 컴포넌트들의 실패는 독립적임을 가정한다. 그러나 컴포넌트들과 인터페이스들의 실패 행동과 함께 소프트웨어 구조를 결합하는 방법은 분석적이지 않다. 우선 각 경로에 대해서 실행된 컴포넌트들의 순서는 테스팅이나 알고리즘 적으로 알 수 있게 되며 경로에 대한 신뢰성은 경로에서의 컴포넌트들의 신뢰성의 곱에 의해 달성된다. 그리고 나면 시스템 신뢰성은 모든 경로에 대해서 신뢰성의 평균에 의해 추정이 된 다. 이렇게 경로 기반 모델들은 각 경로에 따라 각 컴포넌트의 이용에 대해 설명한다. 상태 기반 접근방법과 경로 기반 접근방법 사이에서의 다른 점은 루프를 어플리케이션에서의 제어 흐름 그래 프가 루프를 포함할 때 나타난다. 상태 기반 모델들은 루프 때문에 경로의 수가 무한인 것을 설명 하지만 경로 기반 모델에서는 경로의 수가 테스팅 동안에 발견된 경로들에 의해 제한되거나 또는 어플리케이션의 평균 실행 시간의 사용으로 각 경로의 깊이로의 이동을 끝내는 것으로 제한하게 된 다. (3) Additive models Additive models은 소프트웨어 테스팅 단계를 고려하는 모델이며 각 컴포넌트의 신뢰성은 NHPP(Non-Homogeneous Poisson Process)에 의해 모델화 될 수 있다. 만약 컴포넌트의 실패가 NHPP에 의해 모델화 되면 시스템 실패는 누적 실패 수와 실패 강도와 함께 NHPP 모델이 된다는 것은 잘 알려져 있다. 여기에는 두 가지 종류의 모델이 존재하게 된다. 첫 번째로 소프트웨어 컴포 넌트들의 서로 다른 이용과 같은 소프트웨어 구조를 고려하지 않는 모델이다. 즉 시스템 안에서 서 로 다른 컴포넌트들이 서로 협력하여 작동될 때 작동되는 시간을 고려하기 위해 이에 상응하는 기 능들의 시간을 적당하게 조절하는 것이 첫 번째 모델이 된다. 두 번째로 컴포넌트의 신뢰성 성장을 관측하기 위해 사용하는 모델이다. 이 모델에는 모델의 파라미터로 각 컴포넌트에서 부과되는 상대 적인 사용 부하에 대한 정보가 포함되게 된다. 또한 테스팅 동안에 각 컴포넌트에서 소요된 누적 실행 시간은 개별적인 컴포넌트의 실패 강도와 누적 실패 수를 계산하기위해 사용된다. 그러므로 이 모델은 함축적으로 소프트웨어 구조와 같은 소프트웨어 컴포넌트의 활용을 고려하게 된다. 다른 말로, 이러한 접근은 명시적으로 소프트웨어의 구조를 설명하고 표현하는 컴포넌트들의 신뢰성을 추정하기 위한 접근과 밀접하게 관련된다고 할 수 있다. 연구 수행 내용 본 연구에서는 UML모델과 같은 구현 이전 단계에서 생산되는 산출물들을 통해 시스템 신뢰성을 예 측하고자 하였다. 제안한 테크닉은 신뢰성 분석 프로세스를 크게 여섯 단계로 나누고 UML 모델의 유 즈케이스 다이어그램, 활동 다이어그램, 그리고 시퀀스 다이어그램을 사용하여 전체 시스템의 신뢰성 을 추정한다. 특히method level 의 failure intensity 를 busy period와 complexity weight value를 통 - 43 -

Page43

(2) Path-based models 상태 기반 모델과 유사한 모델로 소프트웨어의 구조를 명시적으로 고려하며 컴포넌트들의 실패는 독립적임을 가정한다. 그러나 컴포넌트들과 인터페이스들의 실패 행동과 함께 소프트웨어 구조를 결합하는 방법은 분석적이지 않다. 우선 각 경로에 대해서 실행된 컴포넌트들의 순서는 테스팅이나 알고리즘 적으로 알 수 있게 되며 경로에 대한 신뢰성은 경로에서의 컴포넌트들의 신뢰성의 곱에 의해 달성된다. 그리고 나면 시스템 신뢰성은 모든 경로에 대해서 신뢰성의 평균에 의해 추정이 된 다. 이렇게 경로 기반 모델들은 각 경로에 따라 각 컴포넌트의 이용에 대해 설명한다. 상태 기반 접근방법과 경로 기반 접근방법 사이에서의 다른 점은 루프를 어플리케이션에서의 제어 흐름 그래 프가 루프를 포함할 때 나타난다. 상태 기반 모델들은 루프 때문에 경로의 수가 무한인 것을 설명 하지만 경로 기반 모델에서는 경로의 수가 테스팅 동안에 발견된 경로들에 의해 제한되거나 또는 어플리케이션의 평균 실행 시간의 사용으로 각 경로의 깊이로의 이동을 끝내는 것으로 제한하게 된 다. (3) Additive models Additive models은 소프트웨어 테스팅 단계를 고려하는 모델이며 각 컴포넌트의 신뢰성은 NHPP(Non-Homogeneous Poisson Process)에 의해 모델화 될 수 있다. 만약 컴포넌트의 실패가 NHPP에 의해 모델화 되면 시스템 실패는 누적 실패 수와 실패 강도와 함께 NHPP 모델이 된다는 것은 잘 알려져 있다. 여기에는 두 가지 종류의 모델이 존재하게 된다. 첫 번째로 소프트웨어 컴포 넌트들의 서로 다른 이용과 같은 소프트웨어 구조를 고려하지 않는 모델이다. 즉 시스템 안에서 서 로 다른 컴포넌트들이 서로 협력하여 작동될 때 작동되는 시간을 고려하기 위해 이에 상응하는 기 능들의 시간을 적당하게 조절하는 것이 첫 번째 모델이 된다. 두 번째로 컴포넌트의 신뢰성 성장을 관측하기 위해 사용하는 모델이다. 이 모델에는 모델의 파라미터로 각 컴포넌트에서 부과되는 상대 적인 사용 부하에 대한 정보가 포함되게 된다. 또한 테스팅 동안에 각 컴포넌트에서 소요된 누적 실행 시간은 개별적인 컴포넌트의 실패 강도와 누적 실패 수를 계산하기위해 사용된다. 그러므로 이 모델은 함축적으로 소프트웨어 구조와 같은 소프트웨어 컴포넌트의 활용을 고려하게 된다. 다른 말로, 이러한 접근은 명시적으로 소프트웨어의 구조를 설명하고 표현하는 컴포넌트들의 신뢰성을 추정하기 위한 접근과 밀접하게 관련된다고 할 수 있다. 연구 수행 내용 본 연구에서는 UML모델과 같은 구현 이전 단계에서 생산되는 산출물들을 통해 시스템 신뢰성을 예 측하고자 하였다. 제안한 테크닉은 신뢰성 분석 프로세스를 크게 여섯 단계로 나누고 UML 모델의 유 즈케이스 다이어그램, 활동 다이어그램, 그리고 시퀀스 다이어그램을 사용하여 전체 시스템의 신뢰성 을 추정한다. 특히method level 의 failure intensity 를 busy period와 complexity weight value를 통 - 43 -

Page44
해 할당하고 activity의 complete 전이확률을 DTMC를 이용하여 계산함으로써 전체 시스템 신뢰성을 예측한다. 제안된 기법의 적용 가능성과 예측력, 그리고 분석력을 평가하기 위해 safety critical system 인 인슐린 펌프 소프트웨어에 적용하여 시스템 신뢰성을 예측하였고 이를 실제 fault history 를 통해 추출한 블랙박스 모델의 신뢰성과 additive 모델의 신뢰성 결과와 비교하여 predictive power 를 검증하였다. 또한 신뢰성 저항에 가장 많은 영향을 주는 시스템 활용과(usage) 그 활동(activity) 를 정량적으로 식별할 수 있으며 운영프로파일 변화에 따른 신뢰성 변화도 효과적으로 분석할 수 있 음을 실험을 통해 제시하였다 [14]. [그림 17] UML 기반 신뢰성 예측 모델 개요 및 프로세스 제안된 방법론은 블랙박스 모델에 비해 신뢰성 예측의 정확도를 근소하게 증가시켰으며 그리고 운영 프로파일의 변화에 따른 신뢰성 시뮬레이션이 가능함을 실제 적용 결과를 통해 제시 하였다. 초기 시 스템 설계 시에는 정확한 운영 프로파일을 예측하기 어렵기 때문에 테스트 및 운영 단계에서의 프로 파일이 변경 될 수 있는데, 제안한 모델은 이러한 프로파일 변화에 따른 전체 시스템 신뢰성의 변화 를 추정 할 수 있도록 시뮬레이션이 가능하다. UML 모델 기반 소프트웨어 신뢰성 예측 기법 제안 기존 아키텍처 기반 소프트웨어 신뢰성 분석에서 컴포넌트의 관계를 단순히 호출 그래프로 표현하던 것과는 달리 최근 소프트웨어 설계시 많이 사용되는 UML 모델을 이용하여 설계 단계에서 소프트웨 - 44 -

Page44

해 할당하고 activity의 complete 전이확률을 DTMC를 이용하여 계산함으로써 전체 시스템 신뢰성을 예측한다. 제안된 기법의 적용 가능성과 예측력, 그리고 분석력을 평가하기 위해 safety critical system 인 인슐린 펌프 소프트웨어에 적용하여 시스템 신뢰성을 예측하였고 이를 실제 fault history 를 통해 추출한 블랙박스 모델의 신뢰성과 additive 모델의 신뢰성 결과와 비교하여 predictive power 를 검증하였다. 또한 신뢰성 저항에 가장 많은 영향을 주는 시스템 활용과(usage) 그 활동(activity) 를 정량적으로 식별할 수 있으며 운영프로파일 변화에 따른 신뢰성 변화도 효과적으로 분석할 수 있 음을 실험을 통해 제시하였다 [14]. [그림 17] UML 기반 신뢰성 예측 모델 개요 및 프로세스 제안된 방법론은 블랙박스 모델에 비해 신뢰성 예측의 정확도를 근소하게 증가시켰으며 그리고 운영 프로파일의 변화에 따른 신뢰성 시뮬레이션이 가능함을 실제 적용 결과를 통해 제시 하였다. 초기 시 스템 설계 시에는 정확한 운영 프로파일을 예측하기 어렵기 때문에 테스트 및 운영 단계에서의 프로 파일이 변경 될 수 있는데, 제안한 모델은 이러한 프로파일 변화에 따른 전체 시스템 신뢰성의 변화 를 추정 할 수 있도록 시뮬레이션이 가능하다. UML 모델 기반 소프트웨어 신뢰성 예측 기법 제안 기존 아키텍처 기반 소프트웨어 신뢰성 분석에서 컴포넌트의 관계를 단순히 호출 그래프로 표현하던 것과는 달리 최근 소프트웨어 설계시 많이 사용되는 UML 모델을 이용하여 설계 단계에서 소프트웨 - 44 -

Page45
어 신뢰성을 예측 할 수 있는 테크닉과 이를 적용할 수 있는 프로세스를 제안하였다. 제안된 테크닉 에서는 UML 모델의 유즈케이스 다이어그램과 액티비티 다이어그램 그리고 시퀀스 다이어그램을 활 용하여 시스템을 표현하고 이들의 분석을 통해 신뢰성을 예측한다. 유즈케이스 다이어그램은 사용자 의 시스템 활용, 즉 운영 프로파일을 명시적으로 기술하고, 액티비티 다이어그램은 해당 유즈케이스 시나리오의 처리 절차를 표현하며 액티비티 다이어그램에서 각각의 액티비티는 그 액티비티를 구현하 기 위한 컴포넌트 들과 그들의 인터렉션을 표현하기 위해 시퀀스 다이어그램으로 확장된다. 유즈케이 스 다이어그램의 각 유즈케이스별로 하나의 액티비티 다이어그램을 포함하고 있으며 모든 액티비티 다이어그램 내의 각각의 액티비티는 하나의 시퀀스 다이어그램을 갖고 있는, 계층적 구조로 연결 되 어 있다. UML 모델 기반 소프트웨어 신뢰성 예측 절차 제안된 테크닉의 적용을 위해서는 총 6가지 단계의 절차에 따라 UML 모델로 표현된 초기 디자인을 분석하게 되는데 처음 1~3 단계는 시스템을 분해하여 각 서브 시스템별 실행 확률을 추출하는데 중 점을 두고 있으며 후기 4~6 단계는 분해된 각각의 유닛들을 다시 재결합 하면서 이 유닛들의 신뢰성 과 실행 확률을 통해 전체 시스템 신뢰성을 예측하는데 중점을 두고 있다. 다시 말해 본 연구에서 제 안된 모델의 신뢰성 분석은 [그림 17]의 하단에서 표현하는 것과 같이 거시적인 시스템 활용 레벨에 서부터 미시적인 컴포넌트 메소드 활용레벨 까지 분해해 가면서 각각의 실행/운영 확률을 구하고 이 를 다시 메소드 레벨의 신뢰성에서부터 시스템 레벨의 시나리오별 신뢰성까지 추출하여 최종적으로는 각 레벨별 신뢰성을 예측한다. (1) 시스템 활용 확률 식별 (2) 활동 전이 확률 식별 (3) 컴포넌트 인터렉션 식별 (4) 컴포넌트 인터렉션 신뢰성 계산 (5) 활동 전이 신뢰성 계산 (6) 시스템 신뢰성 계산 의료 산업 도메인에서의 안전 최우선 임베디드 시스템에 적용 본 연구에서 제안한 방법론이 실제 환경에서 얼마나 정확한 예측력을 갖는지를 평가해 보기 위해 의 료 산업 도메인에서 안전 최우선 시스템인 인슐린 자동제어 펌프 시스템을 대상으로 케이스 스터디를 실시하였다. 인슐린 펌프는 그 설계와 제조가 미국 식품의약품안전청(FDA)의 규제를 받고 있는 휴대 용 의료기기로서 설계와 구성품까지 상세하게 문서화된 과정을 따라야 하며 성능의 경우 엄격한 문서 화, 개발 테스트, 생산 테스트 및 현장 유지보수 요구사항을 만족해야 한다. 이 기기는 당뇨병 환자의 혈당 수치에 따라 적절한 인슐린 양을 적절한 타이밍에 투약하는 기능을 담당한다. 만약 소프트웨어 - 45 -

Page45

어 신뢰성을 예측 할 수 있는 테크닉과 이를 적용할 수 있는 프로세스를 제안하였다. 제안된 테크닉 에서는 UML 모델의 유즈케이스 다이어그램과 액티비티 다이어그램 그리고 시퀀스 다이어그램을 활 용하여 시스템을 표현하고 이들의 분석을 통해 신뢰성을 예측한다. 유즈케이스 다이어그램은 사용자 의 시스템 활용, 즉 운영 프로파일을 명시적으로 기술하고, 액티비티 다이어그램은 해당 유즈케이스 시나리오의 처리 절차를 표현하며 액티비티 다이어그램에서 각각의 액티비티는 그 액티비티를 구현하 기 위한 컴포넌트 들과 그들의 인터렉션을 표현하기 위해 시퀀스 다이어그램으로 확장된다. 유즈케이 스 다이어그램의 각 유즈케이스별로 하나의 액티비티 다이어그램을 포함하고 있으며 모든 액티비티 다이어그램 내의 각각의 액티비티는 하나의 시퀀스 다이어그램을 갖고 있는, 계층적 구조로 연결 되 어 있다. UML 모델 기반 소프트웨어 신뢰성 예측 절차 제안된 테크닉의 적용을 위해서는 총 6가지 단계의 절차에 따라 UML 모델로 표현된 초기 디자인을 분석하게 되는데 처음 1~3 단계는 시스템을 분해하여 각 서브 시스템별 실행 확률을 추출하는데 중 점을 두고 있으며 후기 4~6 단계는 분해된 각각의 유닛들을 다시 재결합 하면서 이 유닛들의 신뢰성 과 실행 확률을 통해 전체 시스템 신뢰성을 예측하는데 중점을 두고 있다. 다시 말해 본 연구에서 제 안된 모델의 신뢰성 분석은 [그림 17]의 하단에서 표현하는 것과 같이 거시적인 시스템 활용 레벨에 서부터 미시적인 컴포넌트 메소드 활용레벨 까지 분해해 가면서 각각의 실행/운영 확률을 구하고 이 를 다시 메소드 레벨의 신뢰성에서부터 시스템 레벨의 시나리오별 신뢰성까지 추출하여 최종적으로는 각 레벨별 신뢰성을 예측한다. (1) 시스템 활용 확률 식별 (2) 활동 전이 확률 식별 (3) 컴포넌트 인터렉션 식별 (4) 컴포넌트 인터렉션 신뢰성 계산 (5) 활동 전이 신뢰성 계산 (6) 시스템 신뢰성 계산 의료 산업 도메인에서의 안전 최우선 임베디드 시스템에 적용 본 연구에서 제안한 방법론이 실제 환경에서 얼마나 정확한 예측력을 갖는지를 평가해 보기 위해 의 료 산업 도메인에서 안전 최우선 시스템인 인슐린 자동제어 펌프 시스템을 대상으로 케이스 스터디를 실시하였다. 인슐린 펌프는 그 설계와 제조가 미국 식품의약품안전청(FDA)의 규제를 받고 있는 휴대 용 의료기기로서 설계와 구성품까지 상세하게 문서화된 과정을 따라야 하며 성능의 경우 엄격한 문서 화, 개발 테스트, 생산 테스트 및 현장 유지보수 요구사항을 만족해야 한다. 이 기기는 당뇨병 환자의 혈당 수치에 따라 적절한 인슐린 양을 적절한 타이밍에 투약하는 기능을 담당한다. 만약 소프트웨어 - 45 -

Page47
별로 각각의 수행 확률과 신뢰성을 추정하여 전체 시스템 신뢰성을 계산한다. 따라서 특정 레벨에서 의 수행 확률이나 신뢰성의 변화에 따라서 전체 시스템 신뢰성이 어떤 영향을 받는지 정량적인 측정 이 가능한다. 초기 시스템 설계시에는 정확한 운영 프로파일을 여측하기 어렵기 때문에 테스트 및 운 영 단계에서의 프로파일이 변경 될 수 있는데, 제안한 모델은 이러한 프로파일 변화에 따른 전체 시 스템 신뢰성의 변화를 추정 할 수 있도록 시뮬레이션이 가능하다. 아래의 그림은 실험 대상의 운영 프로파일에서 센서와 인젝터의 사용 비율이 줄어들고 오퍼레이터의 사용비율이 증가는 운영 프로파일의 변화가 생겼을 때 전체 시스템 신뢰성이 어떻게 변화하는지를 보 여준다. 결과를 살펴보면 Operator 의 사용 비율이 10에서 50%까지 증가함에 따라 전체 시스템 신뢰 성은 93.42에서 95.04 로 증가하는 것을 볼 수 있다. 이는 Operator의 주된 기능인 log backup 과 log restore 기능 구현이 신뢰성이 높은 COTS (CSV Library)를 사용했기 때문이었음을 알 수 있었 다. [그림 19] 운영프로파일 변화에 따른 시스템 신뢰성 변화 5) 개발 초기 단계에서 통계적 모델 체킹을 통한 소프트웨어 신뢰성 검증 본 연구에서는 SMC(Statistical Model Checking)를 통한 개발 초기단계의 소프트웨어 신뢰성을 입 증 방법을 제안한다. 개발 단계 종료 이후에나 신뢰성에 대한 입증이 가능하였던 기존의 신뢰성 평가 프로세스의 고 비용 문제를 해결하였고 신뢰성 할당 오류와 디자인상의 오류들이 다음 단계로 전파되 지 않도록 방지하는 방법을 제시하였다. 또한 추가적으로 automobile 도메인의 Fault-Tolerant Fuel control system(FFCS)에 대한 사례 연구를 수행함으로써 SMC에 대한 결과의 우수성을 입증하였다 [10]. 아래의 그림은 본 연구에서 제안하는 소프트웨어 신뢰성 프레임워크를 나타낸다. 소프트웨어 신 - 47 -

Page47

별로 각각의 수행 확률과 신뢰성을 추정하여 전체 시스템 신뢰성을 계산한다. 따라서 특정 레벨에서 의 수행 확률이나 신뢰성의 변화에 따라서 전체 시스템 신뢰성이 어떤 영향을 받는지 정량적인 측정 이 가능한다. 초기 시스템 설계시에는 정확한 운영 프로파일을 여측하기 어렵기 때문에 테스트 및 운 영 단계에서의 프로파일이 변경 될 수 있는데, 제안한 모델은 이러한 프로파일 변화에 따른 전체 시 스템 신뢰성의 변화를 추정 할 수 있도록 시뮬레이션이 가능하다. 아래의 그림은 실험 대상의 운영 프로파일에서 센서와 인젝터의 사용 비율이 줄어들고 오퍼레이터의 사용비율이 증가는 운영 프로파일의 변화가 생겼을 때 전체 시스템 신뢰성이 어떻게 변화하는지를 보 여준다. 결과를 살펴보면 Operator 의 사용 비율이 10에서 50%까지 증가함에 따라 전체 시스템 신뢰 성은 93.42에서 95.04 로 증가하는 것을 볼 수 있다. 이는 Operator의 주된 기능인 log backup 과 log restore 기능 구현이 신뢰성이 높은 COTS (CSV Library)를 사용했기 때문이었음을 알 수 있었 다. [그림 19] 운영프로파일 변화에 따른 시스템 신뢰성 변화 5) 개발 초기 단계에서 통계적 모델 체킹을 통한 소프트웨어 신뢰성 검증 본 연구에서는 SMC(Statistical Model Checking)를 통한 개발 초기단계의 소프트웨어 신뢰성을 입 증 방법을 제안한다. 개발 단계 종료 이후에나 신뢰성에 대한 입증이 가능하였던 기존의 신뢰성 평가 프로세스의 고 비용 문제를 해결하였고 신뢰성 할당 오류와 디자인상의 오류들이 다음 단계로 전파되 지 않도록 방지하는 방법을 제시하였다. 또한 추가적으로 automobile 도메인의 Fault-Tolerant Fuel control system(FFCS)에 대한 사례 연구를 수행함으로써 SMC에 대한 결과의 우수성을 입증하였다 [10]. 아래의 그림은 본 연구에서 제안하는 소프트웨어 신뢰성 프레임워크를 나타낸다. 소프트웨어 신 - 47 -

Page48
뢰성 평가는 IEEE 1633을 참고하여 수행되고 여기서 신뢰서 요구사항 할당과 평가 스텝에서 제안하는 SMC를 이용하여 신뢰성 요구사항이 검증된다. [그림 20] 제안된 소프트웨어 신뢰성 프레임워크 라. 산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발 내장형 소프트웨어 신뢰성 보증 활동 가이드라인은 각 활동에 대한 선행 조건과 실제 수행 활동, 그 리고 수행 활동이 완료되었음을 입증할 수 있는 완료 조건을 기술하는 형식으로 개발되었다. 그래서 내장형 소프트웨어를 개발 조직에서 실제적인 적용이 가능할 수 있도록 적용하며, 또한 소프트웨어 개 발 프로세스 별로 신뢰성 프로세스 활동을 매핑하여 어떤 단계에 어떤 활동들이 수행되어야 함을 함께 기술하였다. 아울러 실제 수행활동에서 사용되는 여러 가지 소프트웨어 공학기술들에 대한 설명을 첨 부함으로써, 신뢰성 프로세스가 보다 효율적으로 활용 될 수 있도록 작성하였다. - 48 -

Page48

뢰성 평가는 IEEE 1633을 참고하여 수행되고 여기서 신뢰서 요구사항 할당과 평가 스텝에서 제안하는 SMC를 이용하여 신뢰성 요구사항이 검증된다. [그림 20] 제안된 소프트웨어 신뢰성 프레임워크 라. 산업별 내장형 소프트웨어 신뢰성 보증 활동 가이드라인 개발 내장형 소프트웨어 신뢰성 보증 활동 가이드라인은 각 활동에 대한 선행 조건과 실제 수행 활동, 그 리고 수행 활동이 완료되었음을 입증할 수 있는 완료 조건을 기술하는 형식으로 개발되었다. 그래서 내장형 소프트웨어를 개발 조직에서 실제적인 적용이 가능할 수 있도록 적용하며, 또한 소프트웨어 개 발 프로세스 별로 신뢰성 프로세스 활동을 매핑하여 어떤 단계에 어떤 활동들이 수행되어야 함을 함께 기술하였다. 아울러 실제 수행활동에서 사용되는 여러 가지 소프트웨어 공학기술들에 대한 설명을 첨 부함으로써, 신뢰성 프로세스가 보다 효율적으로 활용 될 수 있도록 작성하였다. - 48 -

Page49
마. 내장형 소프트웨어 개발 조직의 성숙도 개선 방안 제안된 방법들을 실제 내장형 소프트웨어 개발 조직에 적용하여, 개발 조직이 갖고 있는 문제점을 도출하고, 이를 개선할 수 있는 방안을 도출하는 것을 목표로 한다. 1) 초기 테스트 단계에서의 산업 현장 (국방 도메인)에 신뢰성 모델 적용 연구 내용 본 연구에서는 실제 산업에서 사용할 수 있는 산업 데이터 수집 템플릿을 정의하고 이 템플릿에 따라 수집된 데이터를 이용하여 신뢰성을 측정 할 수 있는 방안을 마련하였다. 데이터 수집을 위해서 다음 표와 같이 표준화된 수집 템플릿을 작성하여 이용하였으며 개발자가 직접 데이터를 입력하여 수집하 도록 하였다. 수집 데이터는 CMMI 레벨 5를 보유한 개발 조직으로부터 전체 28개의 파일로 수집되 었으며 그중 실험 가능한 데이터를 분류하는 작업을 통해서 10개의 유닛에 대한 데이터가 실험에서 사용되었다. [그림 21] 고장 발견 템플릿 예시 실험을 통해 초기 테스트 단계에서는 개발자가 테스트와 디버그를 모두 수행 하지만 Goel-Okumoto 모델의 경우에는 이를 제대로 반영하지 못해 실제 값과 오차가 발생함을 알 수 있었다. 이번 연구에 서는 테스트 시간뿐만 아니라 디버그 시간까지 함께 고려하는 새로운 모델을 제안했으며 이를 통해서 초기 테스트 단계에서부터 개별 유닛의 신뢰성을 관리할 수 있기 때문에 나중 단계에서의 고장 제거 비용을 감소시킬 수 있다. 관리 측면에서는 예측 모델, 초기 추정 모델, 나중 추정 모델의 3단계 프 로세스를 제공하여 스케줄 관리 및 비용 감소 효과를 기대할 수 있으며 전체 프로젝트 측면에서는 신 뢰할 수 있는 소프트웨어를 개발할 확률을 높일 수 있을 것으로 기대한다. 국방 도메인에서 제안된 신뢰성 모델 적용 실험 및 검증 본 연구에서는 가상의 데이터가 아닌 실제 산업데이터를 이용하여 실험을 수행하였다. 데이터는 현재 개발 중인 프로젝트로부터 수집 되었으며 개발 조직은 현재 CMMI 레벨 5를 보유한 조직이다. 전체 이용 가능한 10개의 유닛 중 하나의 유닛의 고장 데이터를 이용하였으며 아래 그림의 회색 라인은 고 장의 제거 시간을 고려하지 않은 Goel-Okumoto 모델의 MVF결과 그래프이다. 이 그래프는 34시간 유닛에서 10개의 고장을 추정하며 38시간 유닛에서는 10.41 의 고장수를 추정하고 있다. 아래 Goel 모델과 제안하는 모델의 비교 그래프의 빨간 선은 고장의 제거시간을 반영하여 새로 제안한 모델의 - 49 -

Page49

마. 내장형 소프트웨어 개발 조직의 성숙도 개선 방안 제안된 방법들을 실제 내장형 소프트웨어 개발 조직에 적용하여, 개발 조직이 갖고 있는 문제점을 도출하고, 이를 개선할 수 있는 방안을 도출하는 것을 목표로 한다. 1) 초기 테스트 단계에서의 산업 현장 (국방 도메인)에 신뢰성 모델 적용 연구 내용 본 연구에서는 실제 산업에서 사용할 수 있는 산업 데이터 수집 템플릿을 정의하고 이 템플릿에 따라 수집된 데이터를 이용하여 신뢰성을 측정 할 수 있는 방안을 마련하였다. 데이터 수집을 위해서 다음 표와 같이 표준화된 수집 템플릿을 작성하여 이용하였으며 개발자가 직접 데이터를 입력하여 수집하 도록 하였다. 수집 데이터는 CMMI 레벨 5를 보유한 개발 조직으로부터 전체 28개의 파일로 수집되 었으며 그중 실험 가능한 데이터를 분류하는 작업을 통해서 10개의 유닛에 대한 데이터가 실험에서 사용되었다. [그림 21] 고장 발견 템플릿 예시 실험을 통해 초기 테스트 단계에서는 개발자가 테스트와 디버그를 모두 수행 하지만 Goel-Okumoto 모델의 경우에는 이를 제대로 반영하지 못해 실제 값과 오차가 발생함을 알 수 있었다. 이번 연구에 서는 테스트 시간뿐만 아니라 디버그 시간까지 함께 고려하는 새로운 모델을 제안했으며 이를 통해서 초기 테스트 단계에서부터 개별 유닛의 신뢰성을 관리할 수 있기 때문에 나중 단계에서의 고장 제거 비용을 감소시킬 수 있다. 관리 측면에서는 예측 모델, 초기 추정 모델, 나중 추정 모델의 3단계 프 로세스를 제공하여 스케줄 관리 및 비용 감소 효과를 기대할 수 있으며 전체 프로젝트 측면에서는 신 뢰할 수 있는 소프트웨어를 개발할 확률을 높일 수 있을 것으로 기대한다. 국방 도메인에서 제안된 신뢰성 모델 적용 실험 및 검증 본 연구에서는 가상의 데이터가 아닌 실제 산업데이터를 이용하여 실험을 수행하였다. 데이터는 현재 개발 중인 프로젝트로부터 수집 되었으며 개발 조직은 현재 CMMI 레벨 5를 보유한 조직이다. 전체 이용 가능한 10개의 유닛 중 하나의 유닛의 고장 데이터를 이용하였으며 아래 그림의 회색 라인은 고 장의 제거 시간을 고려하지 않은 Goel-Okumoto 모델의 MVF결과 그래프이다. 이 그래프는 34시간 유닛에서 10개의 고장을 추정하며 38시간 유닛에서는 10.41 의 고장수를 추정하고 있다. 아래 Goel 모델과 제안하는 모델의 비교 그래프의 빨간 선은 고장의 제거시간을 반영하여 새로 제안한 모델의 - 49 -

Page51
이렇게 보정된 결과는 실제 데이터와의 비교 그래프에서 보는 바와 같이 실제 데이터에 보다 정확한 결과를 추정하였음을 알 수 있다. 아래 표는 Goel-Okumoto 모델을 이용하여 추정한 결과와 제안된 모델의 추정 결과를 실제 수집된 데이터와 비교하여 그 결과를 정리하였다. 즉, 초기 테스트 단계에서 는 개발자가 테스트와 디버그를 모두 수행 하지만 Goel-Okumoto 모델의 경우에는 이를 제대로 반영 하지 못해 위 그림과 같이 실제 값과 오차를 발생하게 된다. 특히 전체 고장수를 의미하는 α와 β가 어떻게 변경되었는지를 보이고 있으며, 본 연구에서 제안하는 모델에서는 실제 소요된 시간을 모두 반영하고 있기 때문에 상대적으로 작은 MRE와 MSE 값을 갖고 있다. Goel-Okumoto Model Proposed Model Time 1140 1140 Detection time rate - 0.8947 α 12.3437 12.3437 β 0.0489 0.0437 MRE 0.1276 0.0909 MSE 0.5964 0.2990 Total intervals 38 38 Failures 10.4161 10 이와 같은 연구를 통해 테스트 시간뿐만 아니라 디버그 시간까지 함께 고려하는 새로운 모델을 제안 했으며 이를 통해서 초기 테스트 단계에서부터 개별 유닛의 신뢰성을 관리할 수 있기 때문에 나중 단계에서의 고장 제거 비용을 감소시킬 수 있다. 실제 산업데이터를 이용하여 기존 모델과 비교를 통해 그 특징을 살펴보았으며 Paired T Test를 통해서 기존 모델과의 차이와 실제 데 이터 값과의 차이를 통계적인 방법으로 확인하였다. 이 모델을 통해서 테스트 측면에서는 보다 정확한 추정 결과를 제공할 수 있으며 개발 측면에서는 유닛별 신뢰성 관리를 통해 나중 단계에서의 결함 제거 노력이 감소될 수 있다. 관리 측면에서는 예측 모델, 초기 추정 모델, 나중 추정 모델의 3 단계 프로세스를 제공하여 스케줄 관리 및 비용 감소 효과를 기대할 수 있으며 전체 프로젝트 측면 에서는 신뢰할 수 있는 소프트웨어를 개발할 확률을 높일 수 있을 것으로 기대한다. 2) 소프트웨어 산업에서 COPQ를 사용한 품질 개선 전략의 식별 COPQ(Cost of Poor Quality)는 six sigma의 중요한 성능 척도중 하나이지만 실제 많은 소프트웨어 개발 조직들이 COPQ를 평가하는데 어려움을 겪고 있는 것이 현실이다. 본 연구에서는 이러한 COPQ의 - 51 -

Page51

이렇게 보정된 결과는 실제 데이터와의 비교 그래프에서 보는 바와 같이 실제 데이터에 보다 정확한 결과를 추정하였음을 알 수 있다. 아래 표는 Goel-Okumoto 모델을 이용하여 추정한 결과와 제안된 모델의 추정 결과를 실제 수집된 데이터와 비교하여 그 결과를 정리하였다. 즉, 초기 테스트 단계에서 는 개발자가 테스트와 디버그를 모두 수행 하지만 Goel-Okumoto 모델의 경우에는 이를 제대로 반영 하지 못해 위 그림과 같이 실제 값과 오차를 발생하게 된다. 특히 전체 고장수를 의미하는 α와 β가 어떻게 변경되었는지를 보이고 있으며, 본 연구에서 제안하는 모델에서는 실제 소요된 시간을 모두 반영하고 있기 때문에 상대적으로 작은 MRE와 MSE 값을 갖고 있다. Goel-Okumoto Model Proposed Model Time 1140 1140 Detection time rate - 0.8947 α 12.3437 12.3437 β 0.0489 0.0437 MRE 0.1276 0.0909 MSE 0.5964 0.2990 Total intervals 38 38 Failures 10.4161 10 이와 같은 연구를 통해 테스트 시간뿐만 아니라 디버그 시간까지 함께 고려하는 새로운 모델을 제안 했으며 이를 통해서 초기 테스트 단계에서부터 개별 유닛의 신뢰성을 관리할 수 있기 때문에 나중 단계에서의 고장 제거 비용을 감소시킬 수 있다. 실제 산업데이터를 이용하여 기존 모델과 비교를 통해 그 특징을 살펴보았으며 Paired T Test를 통해서 기존 모델과의 차이와 실제 데 이터 값과의 차이를 통계적인 방법으로 확인하였다. 이 모델을 통해서 테스트 측면에서는 보다 정확한 추정 결과를 제공할 수 있으며 개발 측면에서는 유닛별 신뢰성 관리를 통해 나중 단계에서의 결함 제거 노력이 감소될 수 있다. 관리 측면에서는 예측 모델, 초기 추정 모델, 나중 추정 모델의 3 단계 프로세스를 제공하여 스케줄 관리 및 비용 감소 효과를 기대할 수 있으며 전체 프로젝트 측면 에서는 신뢰할 수 있는 소프트웨어를 개발할 확률을 높일 수 있을 것으로 기대한다. 2) 소프트웨어 산업에서 COPQ를 사용한 품질 개선 전략의 식별 COPQ(Cost of Poor Quality)는 six sigma의 중요한 성능 척도중 하나이지만 실제 많은 소프트웨어 개발 조직들이 COPQ를 평가하는데 어려움을 겪고 있는 것이 현실이다. 본 연구에서는 이러한 COPQ의 - 51 -

Page52
평가를 위해 일반적으로 많이 사용되는 품질 평가 모델인 Constructive Quality Model(COQUALMO) 와 Defect Amplification Model(DAM)을 이용하여 소프트웨어 COPQ를 유추하는 방법을 제시하였으며 이를 통해 소프트웨어 개발 조직들이 소프트웨어 품질 향상 전략을 설립하는데 기반을 다질 수 있게 하였다. 또한 추가적으로 LG전자에서 수집 된 실제 소프트웨어 결함 데이터를 이용하여 SDLC에 대한 결함 분포가 COPQ에 미치는 영향을 분석함으로써 품질 개선 전략을 식별하였다는 점에서 결과에 대한 우수성을 갖는다 [11]. 이 논문에서는 COPQ를 산출하기 위해 기존의 품질 평가 모델인 COQUALMO와 DAM을 이용한다. COQUALMO COQUALMO는 유명한 소프트웨어 품질 모델 중 하나이며 University of Souther California (USC) 소 프트웨어 공학 센터의 Sunita Chulani에 의해 개발되었다. COQUALMO는 소프트웨어 규모 단위 당 잔여 결함 수 혹은 결함 밀도에 대한 예측 값을 산출해 내는 모델로써 소프트웨어 품질평가를 위한 FLEX driver를 제외하고는 COCOMO II와 같은 driver를 갖는다. 아래는 COCOMO II와 COQUALMO 의 개념을 도식화한 그림이다. [그림 24] COCOMO II와 COQUALMO의 개념도 DAM - 52 -

Page52

평가를 위해 일반적으로 많이 사용되는 품질 평가 모델인 Constructive Quality Model(COQUALMO) 와 Defect Amplification Model(DAM)을 이용하여 소프트웨어 COPQ를 유추하는 방법을 제시하였으며 이를 통해 소프트웨어 개발 조직들이 소프트웨어 품질 향상 전략을 설립하는데 기반을 다질 수 있게 하였다. 또한 추가적으로 LG전자에서 수집 된 실제 소프트웨어 결함 데이터를 이용하여 SDLC에 대한 결함 분포가 COPQ에 미치는 영향을 분석함으로써 품질 개선 전략을 식별하였다는 점에서 결과에 대한 우수성을 갖는다 [11]. 이 논문에서는 COPQ를 산출하기 위해 기존의 품질 평가 모델인 COQUALMO와 DAM을 이용한다. COQUALMO COQUALMO는 유명한 소프트웨어 품질 모델 중 하나이며 University of Souther California (USC) 소 프트웨어 공학 센터의 Sunita Chulani에 의해 개발되었다. COQUALMO는 소프트웨어 규모 단위 당 잔여 결함 수 혹은 결함 밀도에 대한 예측 값을 산출해 내는 모델로써 소프트웨어 품질평가를 위한 FLEX driver를 제외하고는 COCOMO II와 같은 driver를 갖는다. 아래는 COCOMO II와 COQUALMO 의 개념을 도식화한 그림이다. [그림 24] COCOMO II와 COQUALMO의 개념도 DAM - 52 -

Page53
DAM은 소프트웨어 개발 주기 (SDLC)에서 결함이 각 단계에서 어떻게 전달되고 증폭되는지에 대해 보여주는 유용한 모델로써 1981년 IBM에 의해 개발되었다. 이 모델은 ‘소프트웨어 결함은 SDLC의 모든 단계에서 발생하거나 제거될 수 있으며 이전 단계에서 남은 잔존 결함은 다음 단계로 전달될 뿐 만 아니라 증폭 또한 가능하다.’ 라는 근본적인 아이디어를 가지며 이에 따라 DAM은 SDLC의 매 단 계에서 결함의 제거율과 증폭율이 요구된다. 아래는 DAM의 개념도를 나타낸 그림이다. DAM은 각 소프트웨어 개발 단계별로 1) Defects passed through, 2) Amplified defects, 3) Newly generated defects 세 가지 결함 유형을 구분 짓는다. 이 논문에서는 Newly generated defects를 산 출하기 위해 COQUALMO를 적용한다. 결과적으로 세 가지 결함 유형에 대한 총 결함 수를 도출해 낼 수 있으며 이를 통해 다음 단계로 전달되는 결함 수를 예측할 수 있다. [그림 25] 결함 증폭 모델 결함 제거 분포가 COPQ에 미치는 영향 분석 이 논문은 결함 제거 분포가 COPQ에 미치는 영향을 분석하기 위해 다음과 같은 실험을 수행하였다. 아래는 각 소프트웨어 개발 단계에서의 결함 제거 비용을 분석한 표이다. <결함 제거 비용 (단위: $1)> Unit System Qualification SDLC Requirement Design Implementation Testing Testing Testing Defect Removal 150 150 150 5,100 9,000 24,000 Cost 다음은 실제 소프트웨어 개발 과정에서 두 생산 모델에 대한 SDLC 별 결함 제거 수를 조사한 표이 다. Model A는 시스템 테스트 단계 이후부터 결함 제거 활동을 수행한 생산 모델이며 Model B는 초 기 요구사항 단계부터 결함 제거 활동을 수행한 모델이다. - 53 -

Page53

DAM은 소프트웨어 개발 주기 (SDLC)에서 결함이 각 단계에서 어떻게 전달되고 증폭되는지에 대해 보여주는 유용한 모델로써 1981년 IBM에 의해 개발되었다. 이 모델은 ‘소프트웨어 결함은 SDLC의 모든 단계에서 발생하거나 제거될 수 있으며 이전 단계에서 남은 잔존 결함은 다음 단계로 전달될 뿐 만 아니라 증폭 또한 가능하다.’ 라는 근본적인 아이디어를 가지며 이에 따라 DAM은 SDLC의 매 단 계에서 결함의 제거율과 증폭율이 요구된다. 아래는 DAM의 개념도를 나타낸 그림이다. DAM은 각 소프트웨어 개발 단계별로 1) Defects passed through, 2) Amplified defects, 3) Newly generated defects 세 가지 결함 유형을 구분 짓는다. 이 논문에서는 Newly generated defects를 산 출하기 위해 COQUALMO를 적용한다. 결과적으로 세 가지 결함 유형에 대한 총 결함 수를 도출해 낼 수 있으며 이를 통해 다음 단계로 전달되는 결함 수를 예측할 수 있다. [그림 25] 결함 증폭 모델 결함 제거 분포가 COPQ에 미치는 영향 분석 이 논문은 결함 제거 분포가 COPQ에 미치는 영향을 분석하기 위해 다음과 같은 실험을 수행하였다. 아래는 각 소프트웨어 개발 단계에서의 결함 제거 비용을 분석한 표이다. <결함 제거 비용 (단위: $1)> Unit System Qualification SDLC Requirement Design Implementation Testing Testing Testing Defect Removal 150 150 150 5,100 9,000 24,000 Cost 다음은 실제 소프트웨어 개발 과정에서 두 생산 모델에 대한 SDLC 별 결함 제거 수를 조사한 표이 다. Model A는 시스템 테스트 단계 이후부터 결함 제거 활동을 수행한 생산 모델이며 Model B는 초 기 요구사항 단계부터 결함 제거 활동을 수행한 모델이다. - 53 -

Page54
<두 생산 모델에 대한 SDLC 별 결함 제거 수> Unit System Qualification Model Requirement Design Implementation TotalTesting Testing Testing A 0 0 0 0 117 43 160 B 22 12 3 11 39 9 96 위의 두 표를 기반으로 결함 제거 분포가 COPQ에 미치는 영향을 분석하기 위해 두 생산 모델에 대한 COPQ를 계산한 결과는 다음 표와 같다. <두 모델의 COPQ (단위: $1,000)> Unit System Qualification Model Requirement Design Implementation TotalTesting Testing Testing A 0.0 0.0 0.0 0.0 6.58 6.45 13.03 B 0.03 0.02 0.005 0.58 3.66 2.25 6.55 표의 결과를 통해 초기 단계부터 결함 제거 활동을 수행하는 모델 B를 이용한 프로세스가 테스트 단 계 이후부터 결함 제거 활동을 수행하는 모델 A의 프로세스보다 50% 가량의 COPQ를 줄일 수 있음 을 확인하였으며 이를 통해 초기 단계부터 결함 제거 활동이 요구됨을 확인할 수 있다. COPQ를 통해 본 소프트웨어 프로세스 향상의 영향 이 논문은 소프트웨어 프로세스 향상이 COPQ에 얼마나 큰 영향을 미치는지에 대해 분석하기 위해 다 음과 같은 실험을 수행하였다. 이 실험은 ‘소프트웨어 프로세스 향상은 소프트웨어 초기 개발 단계에 서의 더 많은 결함 제거 활동을 의미한다.’ 라는 가정을 갖고 이전 실험에서 이용한 모델 A의 데이터 를 기반으로 실험을 수행하였다. 이 실험을 위해 요구사항 단계부터 단위 테스트 단계까지의 결함 제 거율을 각각 5%(10%) 증가시키고 시스템 테스트 단계 이후부터의 결함 제거율을 5%(10%)감소시킨 가상의 프로세스가 향상된 모델을 설정하였다. 아래는 이에 대한 결함 제거 활동 분포 표이다. <결함 제거 활동 분포 (%)> Unit System Qualification Name Requirement Design Implementation TotalTesting Testing Testing Base 0.0 0.0 0.0 0.0 73.1 26.9 100(A) 5% 5.0 5.0 5.0 5.0 63.1 16.9 100-shift - 54 -

Page54

<두 생산 모델에 대한 SDLC 별 결함 제거 수> Unit System Qualification Model Requirement Design Implementation TotalTesting Testing Testing A 0 0 0 0 117 43 160 B 22 12 3 11 39 9 96 위의 두 표를 기반으로 결함 제거 분포가 COPQ에 미치는 영향을 분석하기 위해 두 생산 모델에 대한 COPQ를 계산한 결과는 다음 표와 같다. <두 모델의 COPQ (단위: $1,000)> Unit System Qualification Model Requirement Design Implementation TotalTesting Testing Testing A 0.0 0.0 0.0 0.0 6.58 6.45 13.03 B 0.03 0.02 0.005 0.58 3.66 2.25 6.55 표의 결과를 통해 초기 단계부터 결함 제거 활동을 수행하는 모델 B를 이용한 프로세스가 테스트 단 계 이후부터 결함 제거 활동을 수행하는 모델 A의 프로세스보다 50% 가량의 COPQ를 줄일 수 있음 을 확인하였으며 이를 통해 초기 단계부터 결함 제거 활동이 요구됨을 확인할 수 있다. COPQ를 통해 본 소프트웨어 프로세스 향상의 영향 이 논문은 소프트웨어 프로세스 향상이 COPQ에 얼마나 큰 영향을 미치는지에 대해 분석하기 위해 다 음과 같은 실험을 수행하였다. 이 실험은 ‘소프트웨어 프로세스 향상은 소프트웨어 초기 개발 단계에 서의 더 많은 결함 제거 활동을 의미한다.’ 라는 가정을 갖고 이전 실험에서 이용한 모델 A의 데이터 를 기반으로 실험을 수행하였다. 이 실험을 위해 요구사항 단계부터 단위 테스트 단계까지의 결함 제 거율을 각각 5%(10%) 증가시키고 시스템 테스트 단계 이후부터의 결함 제거율을 5%(10%)감소시킨 가상의 프로세스가 향상된 모델을 설정하였다. 아래는 이에 대한 결함 제거 활동 분포 표이다. <결함 제거 활동 분포 (%)> Unit System Qualification Name Requirement Design Implementation TotalTesting Testing Testing Base 0.0 0.0 0.0 0.0 73.1 26.9 100(A) 5% 5.0 5.0 5.0 5.0 63.1 16.9 100-shift - 54 -

Page55
10% 10.0 10.0 10.0 10.0 53.1 6.9 100-shift 위의 데이터를 기반으로 산출한 COPQ는 아래의 그림과 같다. 이를 통해 초기 시스템 테스트 단계와 품질 테스트 단계에서의 결함 제거 활동이 COPQ에 큰 영향을 미친다는 것을 확인할 수 있으며 이를 통해 소프트웨어 개발 비용 축소를 위해 초기 단계의 결함 제거 활동이 요구됨을 확인할 수 있다. [그림 26] 소프트웨어 프로세스 향상에 따른 COPQ 예측 3) 소프트웨어 인스펙션 척도 분석을 통한 개발 개선 방안 연구 연구 수행 내용 소프트웨어 개발에 있어 각 단계별 프로세스 활동들에 대한 분석 및 평가는 소프트웨어의 품질을 좌 우하는 큰 요인이다. 따라서 많은 소프트웨어 척도들이 소프트웨어 품질을 분석하는데 이용되고 있으 며 유사 프로젝트를 통해 설정되는 기준치와 척도 값의 비교가 수행된다. 하지만 기존의 유사프로젝 트를 찾기란 쉽지 않은 일이며 유사프로젝트를 찾더라도 해당 프로젝트의 개발환경은 현재 개발중인 프로젝트의 환경과 다른 경우가 많다. 따라서 본 연구에서는 외적인 기준치에 의존하지 않고 현재 개 발 단계의 인스펙션 결과를 분석하는 방법을 제시하도록 한다. 산포도를 이용한 상대적 데이터 분석 이 이용되며 국방도메인에서 개발중인 프로젝트 내부 31개의 기능으로부터 수집된 데이터를 통한 사 례분석을 수행 하도록 한다. 이를 통해 기능들 간 현재 개발과정의 일관성 유지여부를 평가하고 다음 - 55 -

Page55

10% 10.0 10.0 10.0 10.0 53.1 6.9 100-shift 위의 데이터를 기반으로 산출한 COPQ는 아래의 그림과 같다. 이를 통해 초기 시스템 테스트 단계와 품질 테스트 단계에서의 결함 제거 활동이 COPQ에 큰 영향을 미친다는 것을 확인할 수 있으며 이를 통해 소프트웨어 개발 비용 축소를 위해 초기 단계의 결함 제거 활동이 요구됨을 확인할 수 있다. [그림 26] 소프트웨어 프로세스 향상에 따른 COPQ 예측 3) 소프트웨어 인스펙션 척도 분석을 통한 개발 개선 방안 연구 연구 수행 내용 소프트웨어 개발에 있어 각 단계별 프로세스 활동들에 대한 분석 및 평가는 소프트웨어의 품질을 좌 우하는 큰 요인이다. 따라서 많은 소프트웨어 척도들이 소프트웨어 품질을 분석하는데 이용되고 있으 며 유사 프로젝트를 통해 설정되는 기준치와 척도 값의 비교가 수행된다. 하지만 기존의 유사프로젝 트를 찾기란 쉽지 않은 일이며 유사프로젝트를 찾더라도 해당 프로젝트의 개발환경은 현재 개발중인 프로젝트의 환경과 다른 경우가 많다. 따라서 본 연구에서는 외적인 기준치에 의존하지 않고 현재 개 발 단계의 인스펙션 결과를 분석하는 방법을 제시하도록 한다. 산포도를 이용한 상대적 데이터 분석 이 이용되며 국방도메인에서 개발중인 프로젝트 내부 31개의 기능으로부터 수집된 데이터를 통한 사 례분석을 수행 하도록 한다. 이를 통해 기능들 간 현재 개발과정의 일관성 유지여부를 평가하고 다음 - 55 -

Page56
개발단계의 프로세스 활동 강화 여부에 대한 권고사항을 제시할 수 있다. 연구 수행 동기 소프트웨어는 개발 단계에서의 시스템 분석 및 설계 공정이 소프트웨어의 품질을 좌우한다. 이에 따 라 소프트웨어 개발 과정 및 인스펙션에 대한 분석이 중요시 되고 있으며 많은 척도들이 이에 대한 분석을 위해 이용되고 있다. 소프트웨어 척도는 소프트웨어 측정 기술을 기반으로 소프트웨어 생명 주기 동안에 소프트웨어 특징 또는 특성을 객관적이고 과학적인 수치로 정량화 할 수 있도록 하는 기 술이다. 일반적인 소프트웨어 척도의 유형은 규모, 복잡도, 품질 척도 등으로 나뉘며 계발 단계별로 다양하게 존재한다. 이 중 기능의 규모 대비 발견된 결함 수를 나타내는 결함 밀도(Defect Density) 은 각 단계의 인스펙션 과정에 대한 분석에 있어 인스펙션을 통해 얼마만큼의 결함을 검출해 내는 가 를 확인하는 중요한 척도라 할 수 있다. 하지만 단순히 결함 밀도만을 갖고 인스펙션 단계를 분석하기에는 부족한 점이 존재한다. 결함 밀도 가 높다는 것은 인스펙션 단계가 잘 이루어 졌다는 것을 의미할 수 있지만 다른 측면에서는 기능의 품질이 떨어지기 때문에 그만큼 많은 결함이 발견되는 것으로 해석이 가능하다. 또한 결함 밀도가 낮 은 경우, 이는 기능의 품질이 높다는 것을 의미하거나 인스펙션이 잘 이루어지지 않았다는 것을 의미 할 수 있다. 이렇듯 하나의 척도 만으로는 그 값이 정확한 분석을 나타내기 어렵다. 따라서 더 정확한 분석을 위해 이를 보완하기 위한 다른 척도와의 결합이 필요하다. Linda M. Laird는 저서를 통해서 프로세스의 효율성을 측정할 수 있는 척도로 기능에 대한 규모 대비 인스펙션 시간을 나타내는 Inspection Intensity를 정의하고 결함 밀도와의 결합을 제시하고 있다. Inspection Intensity는 각 인스펙션 단계에서 얼마만큼의 시간을 할애했는가에 대한 척도로 인스펙션 에 대한 효율성을 나타낸다. Linda M. Laird는 결함 밀도와 Inspection Intensity 두 척도를 이용하여 각 척도의 기준치 충족 여부에 따른 현재 개발 단계에 대한 인스펙션 결과를 4가지 시나리오로 구분 지어 분석하고 각 시나리오 별 다음 개발 단계에 대한 권고사항을 제시하고 있다. 이 과정에서 이용 하는 척도에 대한 기준치는 신뢰할 수 있는 기존의 유사 프로젝트를 기반으로 성공적으로 수행되었던 인스펙션 프로세스의 분석 값을 이용하게 된다. 하지만 대부분의 소프트웨어 개발은 기존의 유사 프 로젝트에서 성공한 프로세스의 분석 값을 찾기 어려울 뿐만 아니라 성공 여부에 대한 기준이 모호한 경우가 많기 때문에 척도에 대한 기준을 정의하기가 어렵다. 따라서 이 연구에서는 기존의 성공 프로세스를 기반으로 하는 척도 기준치에 의존하지 않고 두 척도 간의 결합을 통한 현재 개발 단계의 인스펙션 결과 분석 및 다음 개발 단계에 대한 권고 사항을 제시 하는 방법을 보이도록 한다. 기존 유사프로젝트의 성공 프로세스를 기반으로 하는 척도 기준치가 존 재하지 않는다는 가정하에 산포도를 이용하여 두 척도간의 상대적인 평가를 내리도록 한다. 산포도는 두 변수간의 관계를 알아보기 위해 두 변수 값을 나타내는 점을 도표화 한 것이다. 이를 통해 두 변 수에 대한 각 기능간의 상대적인 관계를 나타낼 수 있다. 제안된 방법에서는 산포도를 이용하여 개발 - 56 -

Page56

개발단계의 프로세스 활동 강화 여부에 대한 권고사항을 제시할 수 있다. 연구 수행 동기 소프트웨어는 개발 단계에서의 시스템 분석 및 설계 공정이 소프트웨어의 품질을 좌우한다. 이에 따 라 소프트웨어 개발 과정 및 인스펙션에 대한 분석이 중요시 되고 있으며 많은 척도들이 이에 대한 분석을 위해 이용되고 있다. 소프트웨어 척도는 소프트웨어 측정 기술을 기반으로 소프트웨어 생명 주기 동안에 소프트웨어 특징 또는 특성을 객관적이고 과학적인 수치로 정량화 할 수 있도록 하는 기 술이다. 일반적인 소프트웨어 척도의 유형은 규모, 복잡도, 품질 척도 등으로 나뉘며 계발 단계별로 다양하게 존재한다. 이 중 기능의 규모 대비 발견된 결함 수를 나타내는 결함 밀도(Defect Density) 은 각 단계의 인스펙션 과정에 대한 분석에 있어 인스펙션을 통해 얼마만큼의 결함을 검출해 내는 가 를 확인하는 중요한 척도라 할 수 있다. 하지만 단순히 결함 밀도만을 갖고 인스펙션 단계를 분석하기에는 부족한 점이 존재한다. 결함 밀도 가 높다는 것은 인스펙션 단계가 잘 이루어 졌다는 것을 의미할 수 있지만 다른 측면에서는 기능의 품질이 떨어지기 때문에 그만큼 많은 결함이 발견되는 것으로 해석이 가능하다. 또한 결함 밀도가 낮 은 경우, 이는 기능의 품질이 높다는 것을 의미하거나 인스펙션이 잘 이루어지지 않았다는 것을 의미 할 수 있다. 이렇듯 하나의 척도 만으로는 그 값이 정확한 분석을 나타내기 어렵다. 따라서 더 정확한 분석을 위해 이를 보완하기 위한 다른 척도와의 결합이 필요하다. Linda M. Laird는 저서를 통해서 프로세스의 효율성을 측정할 수 있는 척도로 기능에 대한 규모 대비 인스펙션 시간을 나타내는 Inspection Intensity를 정의하고 결함 밀도와의 결합을 제시하고 있다. Inspection Intensity는 각 인스펙션 단계에서 얼마만큼의 시간을 할애했는가에 대한 척도로 인스펙션 에 대한 효율성을 나타낸다. Linda M. Laird는 결함 밀도와 Inspection Intensity 두 척도를 이용하여 각 척도의 기준치 충족 여부에 따른 현재 개발 단계에 대한 인스펙션 결과를 4가지 시나리오로 구분 지어 분석하고 각 시나리오 별 다음 개발 단계에 대한 권고사항을 제시하고 있다. 이 과정에서 이용 하는 척도에 대한 기준치는 신뢰할 수 있는 기존의 유사 프로젝트를 기반으로 성공적으로 수행되었던 인스펙션 프로세스의 분석 값을 이용하게 된다. 하지만 대부분의 소프트웨어 개발은 기존의 유사 프 로젝트에서 성공한 프로세스의 분석 값을 찾기 어려울 뿐만 아니라 성공 여부에 대한 기준이 모호한 경우가 많기 때문에 척도에 대한 기준을 정의하기가 어렵다. 따라서 이 연구에서는 기존의 성공 프로세스를 기반으로 하는 척도 기준치에 의존하지 않고 두 척도 간의 결합을 통한 현재 개발 단계의 인스펙션 결과 분석 및 다음 개발 단계에 대한 권고 사항을 제시 하는 방법을 보이도록 한다. 기존 유사프로젝트의 성공 프로세스를 기반으로 하는 척도 기준치가 존 재하지 않는다는 가정하에 산포도를 이용하여 두 척도간의 상대적인 평가를 내리도록 한다. 산포도는 두 변수간의 관계를 알아보기 위해 두 변수 값을 나타내는 점을 도표화 한 것이다. 이를 통해 두 변 수에 대한 각 기능간의 상대적인 관계를 나타낼 수 있다. 제안된 방법에서는 산포도를 이용하여 개발 - 56 -

Page57
하고자 하는 소프트웨어의 각 기능들에 대한 두 척도간의 상대적인 평가를 내리고 이를 통해 현 개발 단계에 대한 인스펙션 결과 분석 및 다음 단계에서의 권고사항을 판단하도록 한다. 산포도를 이용한 분석 방법 이 절에서는 산포도를 이용하여 두 척도간의 결합을 통한 현재 개발 단계의 인스펙션 결과 분석 및 다음 개발 단계에 대한 권고 사항을 제시하는 방법을 보이도록 한다. 분석을 위해서는 다음과 같은 절차를 거친다. 먼저 데이터를 수집하고 이에 대한 결함 밀도와 Inspection Intensity에 해당하는 척도 값을 도출한다. 그 다음에 도출된 각 척도 값에 대해 평균값을 구하여 상대적인 기준치를 정하고 산포도를 통해 각각의 기능이 어떠한 시나리오에 해당하는지를 확 인한다. 산포도를 이용한 분석 결과는 각 기능들에 대해 상대적인 분석이기 때문에 각 시나리오에 해당하는 권고사항이 절대적인 분석을 나타내지는 않는다. 즉 각각의 기능에 대한 분석 결과를 통해 나타난 시 나리오는 다른 기능들에 비해 해당 시나리오의 상황에 가까움을 뜻한다. 따라서 이에 대한 다음과 같 은 재해석이 필요하다. Scenario 1. 다른 기능들에 비해 Software Quality가 높음을 의미한다. Scenario 2. 다른 기능들에 비해 결함 발견이 잘 이루어 지지 않았음을 의미한다. Scenario 3. 다른 기능들에 비해 Code Quality 가 만족함을 의미한다. Scenario 4. 다른 기능들에 비해 개발이 잘 이루어 지지 않고 있음을 의미한다. 재해석된 4가지 시나리오를 통해 상대적인 기준치에 대하여 각각의 기능이 어떠한 시나리오에 해당하 는지를 분석할 수 있다. 시나리오 1에 해당하는 기능들에 대해서는 다른 기능들에 비해 상대적으로 Software Quality에 대해 보장이 되며 시나리오3에 해당하는 기능들에 대해서는 시나리오 1보다는 못 하지만 다른 기능들에 비해 어느 정도의 Code Quality는 보장됨을 의미한다. 나머지 시나리오 2와 4 에 해당하는 기능들은 다른 기능들에 비해 개발 및 인스펙션이 잘 이루어 지지 않았음을 의미하며 이 에 대한 보완이 필요할 것으로 예상된다. 이를 통해 다른 기능에 비해 상대적으로 부족한 부분을 분석하고 다음 개발 단계를 거침으로써 각 기 능들은 이전 단계보다 더 나은 개발 및 인스펙션을 수행하도록 권고된다. 이는 개발 과정이 진행됨에 따라 각 단계별 분석이 반복적으로 시행되고 이를 통해 각 기능에 대한 Software Quality는 점진적으 로 증가하며 전체 기능에 대한 품질 또한 일관성을 띄게 된다. 사례 분석 사례 분석에 이용한 데이터는 실제 국방 프로젝트에서 수행하고 있는 소프트웨어에 대한 요구사항 단 계의 인스펙션 수집 데이터를 이용하였다. 데이터는 31개의 기능에 대한 2가지 버전의 데이터를 이용 하도록 한다. 국방 데이터의 특성상 척도에 따른 자세한 데이터 분석 결과는 감추도록 한다. - 57 -

Page57

하고자 하는 소프트웨어의 각 기능들에 대한 두 척도간의 상대적인 평가를 내리고 이를 통해 현 개발 단계에 대한 인스펙션 결과 분석 및 다음 단계에서의 권고사항을 판단하도록 한다. 산포도를 이용한 분석 방법 이 절에서는 산포도를 이용하여 두 척도간의 결합을 통한 현재 개발 단계의 인스펙션 결과 분석 및 다음 개발 단계에 대한 권고 사항을 제시하는 방법을 보이도록 한다. 분석을 위해서는 다음과 같은 절차를 거친다. 먼저 데이터를 수집하고 이에 대한 결함 밀도와 Inspection Intensity에 해당하는 척도 값을 도출한다. 그 다음에 도출된 각 척도 값에 대해 평균값을 구하여 상대적인 기준치를 정하고 산포도를 통해 각각의 기능이 어떠한 시나리오에 해당하는지를 확 인한다. 산포도를 이용한 분석 결과는 각 기능들에 대해 상대적인 분석이기 때문에 각 시나리오에 해당하는 권고사항이 절대적인 분석을 나타내지는 않는다. 즉 각각의 기능에 대한 분석 결과를 통해 나타난 시 나리오는 다른 기능들에 비해 해당 시나리오의 상황에 가까움을 뜻한다. 따라서 이에 대한 다음과 같 은 재해석이 필요하다. Scenario 1. 다른 기능들에 비해 Software Quality가 높음을 의미한다. Scenario 2. 다른 기능들에 비해 결함 발견이 잘 이루어 지지 않았음을 의미한다. Scenario 3. 다른 기능들에 비해 Code Quality 가 만족함을 의미한다. Scenario 4. 다른 기능들에 비해 개발이 잘 이루어 지지 않고 있음을 의미한다. 재해석된 4가지 시나리오를 통해 상대적인 기준치에 대하여 각각의 기능이 어떠한 시나리오에 해당하 는지를 분석할 수 있다. 시나리오 1에 해당하는 기능들에 대해서는 다른 기능들에 비해 상대적으로 Software Quality에 대해 보장이 되며 시나리오3에 해당하는 기능들에 대해서는 시나리오 1보다는 못 하지만 다른 기능들에 비해 어느 정도의 Code Quality는 보장됨을 의미한다. 나머지 시나리오 2와 4 에 해당하는 기능들은 다른 기능들에 비해 개발 및 인스펙션이 잘 이루어 지지 않았음을 의미하며 이 에 대한 보완이 필요할 것으로 예상된다. 이를 통해 다른 기능에 비해 상대적으로 부족한 부분을 분석하고 다음 개발 단계를 거침으로써 각 기 능들은 이전 단계보다 더 나은 개발 및 인스펙션을 수행하도록 권고된다. 이는 개발 과정이 진행됨에 따라 각 단계별 분석이 반복적으로 시행되고 이를 통해 각 기능에 대한 Software Quality는 점진적으 로 증가하며 전체 기능에 대한 품질 또한 일관성을 띄게 된다. 사례 분석 사례 분석에 이용한 데이터는 실제 국방 프로젝트에서 수행하고 있는 소프트웨어에 대한 요구사항 단 계의 인스펙션 수집 데이터를 이용하였다. 데이터는 31개의 기능에 대한 2가지 버전의 데이터를 이용 하도록 한다. 국방 데이터의 특성상 척도에 따른 자세한 데이터 분석 결과는 감추도록 한다. - 57 -

Page59

석 방법을 제시하였다. 이 방법을 통해 상대적으로 Software Quality가 부족한 기능들은 점진적인 보 완을 수행 함으로써 모든 기능들에 대한 Software Quality가 일관성을 가질 수 있게 된다. 향후 연구 에서는 아직 수집되지 않은 요구사항 이후 단계의 실제 국방 데이터를 이용하여 제안된 방법을 적용 해 볼 계획이다. 산포도에 나타난 결과들은 이전 단계의 결과 및 분석에 영향을 받을 수 있기 때문에 향후 많은 단계의 개발이 진행되면 이에 대한 연구도 필요할 것으로 확인된다. 또한, 개발 과정에 대 한 공정관리 방법으로 통계적 공정 관리(Statistical Process control)가 일반적으로 많이 사용된다. 이 는 프로젝트의 특성이 설계사양 혹은 품질 규격과 일치하는지를 통계적으로 측정하고 평가함으로써 공정을 효율적으로 관리해 나가는 방법을 말한다. Nancy Eickelman의 연구에서는 공정관리에 있어 SPC의 중요성과 이를 위해 필요한 요소들을 정의하고 있다. 현재 사례분석에서 이용한 프로젝트의 데 이터는 두 버전의 개발 단계만이 존재하기 때문에 SPC를 이용하기에는 데이터가 다소 부족하다. 추가 적인 개발단계가 진행되면 SPC에 대한 분석도 가능하기 때문에 논문에서 제시하는 방법과의 비교 또 한 가능하다. [그림 28] 두 번째 데이터에 대한 산포도 바. 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구 개발 내장형 소프트웨어 신뢰성 보증을 위한 프로세스 지원 도구는 원시 데이터 수집, 수집된 데이터의 가공, 그리고 가공된 데이터를 분석하여 내장형 소프트웨어의 신뢰성 평가 과정을 지원하는 도구이다. 본 연구에서는 이를 위해 2개의 신뢰성 분석 지원 도구를 개발하였다. (1) M&A 지원도구는 품질 데 이터 수집 및 관리를 체계화하여 내장형 소프트웨어 신뢰성 측정 및 분석을 효율적으로 수행할 수 있 도록 하며 (2) 내장형 소프트웨어 신뢰성 분석 지원 도구(신뢰성 분석 및 예측 도구)는 초기 단계부터 Release 단계까지 대상 시스템의 신뢰성 계산을 수행하는 도구이다. - 59 -

Page60

1) 소프트웨어 신뢰성 평가 도구 분석 연구 수행 내용 소프트웨어가 점점 복잡해지면서 신뢰할 수 있는 소프트웨어의 개발에 대한 필요성이 제기되고 있다. 이에 따라 소프트웨어 개발 업체는 소프트웨어 신뢰성 보장을 위한 많은 활동들을 수행하고 있다. 이 과정에서 소프트웨어 신뢰성 평가는 핵심이 되는 작업 중 하나이며, 다양한 소프트웨어 신뢰성 평가 도구가 개발되어 정확하고 효율적인 신뢰성 평가를 돕고 있다. 소프트웨어 신뢰성 평가 도구는 적용 할 수 있는 소프트웨어 개발 단계와 적용 방법에 차이가 있기 때문에 도구들은 적시적소에 적용되어 야 한다. 본 연구에서는 CASRE, SMERFS, SREPT, GERT, SRTPRO와 같은 소프트웨어 신뢰성 평가 도구의 분석을 통해 각 도구들의 특징, 목적, 적용단계 등을 고려하여 사용자가 다양한 도구 중 어떤 도구를 선택해야 하는지 판단하는데 도움을 주고자 한다. 본 연구에서는 입출력, 지원하는 신뢰성 평 가 모델, 적용 가능한 개발 주기, 사용성 등을 고려한 몇 가지 대표적인 소프트웨어 신뢰성 평가 도구 들의 특징을 분석 하였다. 본 연구에서 제시한 분석 자료와 정확한 소프트웨어 신뢰성 모델에 대한 이해를 바탕으로 실무에서 적절한 소프트웨어 신뢰성 평가 도구를 선정하고 소프트웨어 신뢰성을 평 가할 수 있을 것이다. 도구 분석 내용 소프트웨어 신뢰성 도구 분석에 앞서, 각 도구의 평가를 위한 다음과 같은 기준이 필요하다. - 입력과 출력: 사용자의 입장에서 입력과 출력은 매우 중요한 역할을 한다. 현재 이용 가능한 산출 물(Artifact)에서 입력이 가능한지 그리고 원하는 결과를 얻을 수 있는지 확인할 필요가 있다. 예를 들어 현재 소프트웨어 아키텍처가 있을 때, 앞으로 설명할 SREPT의 경우 아키텍처를 입력 받기 때문 에 이 단계에서는 SRPET가 가장 적합한 도구로서 선정될 수 있다. - 지원하는 소프트웨어 신뢰성 평가 방식: 도구에서 지원하는 평가 모델을 안다면 현재 프로젝트와 해당 모델의 적합성을 검토할 수 있다. 예를 들어 NHPP 모델을 지원하려면 구현 이후 단계부터 신뢰 성을 평가해야 하는 프로젝트에 적용해야 할 것이다. - 도구를 적용할 수 있는 소프트웨어 개발 단계: 사용자는 도구를 적용할 수 있는 소프트웨어 개발 단계를 파악하여 적용하고자 하는 시점에 적용 가능한지 확인해야 한다. - 사용성: 사용성이 뛰어난 도구는 신뢰성 평가 작업을 효율적으로 진행시키는데 도움을 주기 때문에 중요하다. 소프트웨어 신뢰성 예측을 위해 다양한 소프트웨어 신뢰성 평가 도구가 개발되었다. 본 연구에서는 그 중 가장 대표적으로 사용되었던 4개의 도구와, 이 중 일부의 단점을 보완한 1개의 도구를 분석한 다. 그리고 각각의 도구는 소프트웨어 신뢰성 평가 방법을 정확하게 구현하여 각 도구에서 제시하는 신뢰성 수치는 같은 모델 간에 차이가 없다고 가정한다. 또한 각 도구는 최신 버전으로 분석했음을 밝힌다. - 60 -

Page61

CASRE (Computer Aided Software Reliability Estimation) [6]은 소프트웨어 신뢰성 성장 모델을 이용하여 신뢰성을 평가하는 도구이다. 초창기에 개발된 도구로서 다음과 같은 특징을 갖는다 (1) 고 장간 시간 (Time Between Failure, TBF) 또는 고장 수 (Failure Counts, FC)데이터 파일을 입력으 로 받는다. 하지만 직접 수치를 입력할 수 없기 때문에 사용성이 떨어진다는 단점을 가지고 있다. 입 력에 따라서 결과를 그래프로 얻을 수 있고 프린터 출력도 가능하다. (2) TBF를 입력 받는 경우, Geometric, Jelinski-Mornada, Littlewood-Verrall, Musa-Basic, Musa-Okumoto, NHPP [4] 와 같 은 신뢰성 성장 모델을 적용할 수 있다. FC를 입력 받는 경우 Generalized Poisson, NHPP, Schneidewind, Shick-Wolverton, Yamada S-Shaped [4] 신뢰성 성장 모델을 적용할 수 있다. (3) CASRE는 TBF와 FC의 값이 입력으로 필요하기 때문에 시스템 테스트, 수용 테스트, 운용 단계에 적 용할 수 있다. (4) 데이터 입력은 파일로만 가능하며 직접 입력하지 못하기 때문에 사용성이 떨어진 다. 그리고 데이터 윈도우와 결과 그래프 윈도우가 분리되어 있어 다소 산만한 느낌을 준다. 또한 메 뉴 구성과 인터페이스는 직관적이지 못하고, 신뢰성에 대한 전문 지식이 없으면 사용하기가 어렵다. SMERFS(Statistical Modeling and Estimation of Reliability Functions for Software)는 CASRE와 마찬가지로 초창기에 개발된 소프트웨어 신뢰성 평가 도구로서 많은 공통점을 가진다. SMERFS 역시 소프트웨어 신뢰성 성장 모델을 이용하여 신뢰성을 평가한다. (1) SMERFS 는 TBF나 FC 데이터를 입력 받는다. CASRE와의 차이점은 파일 입력 이외에도 사용자가 직접 수치를 입력할 수 있다는 점이 다. 이렇게 입력된 수치와 각 모델을 적용한 결과를 그래프로 출력하고 인쇄가 가능하다. (2) SMERFS는 TBF 입력의 경우 Geometric, Jelinski-Mornada, Littlewood-Verrall, Musa’s Basic, Musa’s Logarithmic, NHPP [4] 모델을 지원한다. 또한 FC의 경우 Brook’s and Motely’s 모델, Generalized Poisson, NHPP, Schneidewind, Yamada S-shaped [4] 모델을 지원한다. (3) SMERFS 는 CASRE와 마찬가지로 소프트웨어의 테스트 단계 혹은 운용 단계에서 적용할 수 있다. (4) SMERFS의 사용성은 CASRE에 비해 초보자도 쉽게 이용할 수 있고 직관적이다. 하지만 입력된 데이 터를 프로그램 상에서 조작하지 못한다는 단점을 가지고 있다. SRTPRO는 CASRE와 SMERFS의 단점을 보완한 신뢰성 평가 도구이다. SRTPRO는 신뢰성 추정뿐만 아니라 신뢰성 예측을 위한 평가 모델을 제공한다. 또한 CASRE와 SMERFS가 도구 내에서 데이터를 변경하지 못했던 단점을 보완하였다. (1) SRTPRO는 CASRE나 SMERFS와 마찬가지로 TBF나 FC와 같은 데이터를 입력 받을 수 있다. 뿐만 아니라 예측 모델을 위한 몇 가지 척도를 입력하기도 한다. 이러한 입력을 통해 신뢰성 추정 및 예측에 관한 데이터 수치를 얻을 수 있다. 또한 고장 강도 (Failure Intensity), 누적 고장수 (Cumulative Failure)와 같은 다양한 결과를 그래프로 출력하고, 이 결과를 HTML 문서로 리포트 하거나 인쇄하는 것이 가능하다. (2) SRTPRO는 TBF 입력의 경우 Musa Okumoto Model, Musa Basic Model, Jelinski Moranda Model, Littlewood and Verrall Linear Model, Littlewood and Verrall Quadratic Model, Non-homogeneous Poisson Model [4]을 지원한 다. FC 입력의 경우 NHPP, Schneidewind Model, Yamada S-Shaped Model [4]을 지원한다. 그리고 - 61 -

Page62

예측을 위해 RL-TR-92-52 Model, Musa Basic Method, COQUALMO [4]와 같은 모델을 지원한 다. (3) SRTPRO는 신뢰성 예측 모델을 지원하기 때문에 CASRE와 SMURFS와 다르게 소프트웨어 개발 주기 초반부터 후반에 이르는 광범위한 주기에 적용할 수 있다는 장점을 가진다. (4) SRTPRO 는 기존의 도구가 가지고 있는 사용상의 불편함을 경감시켰다. 도구 내에서의 데이터 조정, 한 화면에 다양한 추정 결과를 그래프로 볼 수 있는 기능들이 그것이다. 또한 초보자도 쉽게 이용할 수 있는 직 관적인 인터페이스를 갖추고 있다. SREPT (Software Reliability Estimation and Prediction Tool) [7]은 소프트웨어 성장 모델, 척도뿐 만 아니라 소프트웨어 아키텍처 기반 신뢰성 평가 모델까지 지원해주는 도구이다. 따라서 이 도구는 특정 개발 프로세스에 한정되지 않고 전 영역에 걸쳐 적용할 수 있다. SREPT는 다음과 같은 특징을 가진다. (1) 이 도구는 현재의 결함을 추정하기 위해 소프트웨어 척도를 입력 받는다. 그리고 고장 강 도 (Failure Intensity), 잔여 결함 수, 출시 후 신뢰성 등을 알기 위해 테스트 커버리지, TBF 등이 입 력으로 사용된다. 또한 프로젝트 초반에 신뢰성 예측을 위해 소프트웨어 아키텍처를 입력으로 받는다. (2) SREPT에서 결함 수를 추정하기 위하여 고장 밀도 (Fault Density)와 회귀 트리(Regression Tree) 모델이 사용된다. 또한 고장 강도, 잔여 결함 수, 출시 후 신뢰성 등을 예측하기 위해 ENHPP 모델이 사용된다. 마지막으로 아키텍처를 이용하는 아키텍처 기반 신뢰성 모델이 사용된다 [13]. (3) SREPT는 다양한 모델을 지원함으로써 소프트웨어 개발 주기 전반에 걸쳐 적용할 수 있다. (4) SREPT는 각각의 모델을 적용하는데 있어서 쉽고 직관적인 인터페이스를 제공한다. 하지만 지원하는 모델의 종류가 많아 각각을 적용하기 위해서는 소프트웨어 신뢰성에 대한 전반적인 지식이 필요하다. 따라서 초보자가 이용하기에는 어려움을 겪을 수 있다. GERT(“Good Enough” Reliability Tool) [8]은 TDD (Test-Driven Development) 환경에 특화된 소 프트웨어 신뢰성 평가 도구다. 지금까지 설명한 다른 도구들과는 달리, Eclipse의 플러그인 형태로 존 재한다. (1) GERT의 입력은 JUnit 테스팅 프레임워크를 위한 테스트케이스와 소스코드이다. 이러한 입력에 대해 신뢰성 모델에 따른 결과가 화면에 수치로서 표현된다. (2) GERT는 STREW[5]에서 제 시한 척도를 통해 소프트웨어의 신뢰성을 예측한다. (3) GERT는 테스트 케이스와 소스 코드가 구현 되어 있어야 한다. 따라서 구현 이후에 적용이 가능하다. (4) Eclipse IDE 플러그인 형태로 제작되어 있기 때문에 프로그램 개발자는 구현을 하면서 신뢰도의 변화를 바로 확인할 수 있다. 또한 인터페이 스 역시 매우 쉽고 직관적으로 구성되어 있다. (5) GERT는 사용하기 쉽고 직관적인 인터페이스를 갖 추고 있지만 구현 이후에 적용이 가능하다는 점과 지원하는 신뢰성 평가 모델이 부족하다는 단점을 가지고 있다. 지금까지 분석한 소프트웨어 신뢰성 평가 도구들을 정리하면 아래의 표와 같다. CASRE와 SMERFS는 입력으로 고장 데이터를 받고, 검증과 유지 보수 단계에 적용이 가능하다. SRTRO는 고장 데이터와 척도를 입력으로 하고, 소프트웨어 개발 전 단계에 걸쳐 적용이 가능하다. SREPT는 고장 데이터, 척도, 아키텍처를 입력으로 하여 전 단계에 걸쳐 적용이 가능하다. GERT는 척도를 입력받아 - 62 -

Page63

구현, 검증 그리고 유지보수 단계에 적용이 가능하다. <소프트웨어 신뢰성 평가 도구 비교> CASRE& SRTPRO SREPT GERTSMERFSFailure Data √ √ √Metrics √ √ √Architecture √Requirement √ √Design √ √Implementation √ √ √Verification √ √ √ √Maintenance √ √ √ √Usability Low High Middle High 2) M&A(Measurement & Analysis) 지원 도구 소프트웨어의 품질관리와 관련하여 관리자가 정확한 의사결정을 하기 위해서는 올바른 품질데이터가 적시에, 적합한 형태로 가공되어 제시되어야 한다. 소프트웨어 개발이 복잡해지고 생산되는 산출물과 관리해야 하는 품질관련 데이터들이 늘어남에 따라 이들을 효율적이고 체계적으로 수집/관리하는 일이 매우 중요해 지고 있다. 품질 데이터의 수집/관리는 조직 내에 정의된 품질 관리 프로세스에 따라 사전 에 수집할 데이터를 선별하고 이들의 용도를 분명히 하여 적절한 계측을 통해 표준화된 기록을 하여야 한다. 하지만 품질 관리 수준이 높지 않은 조직에서는 개발자가 개인별로 데이터를 수집/보관하게 되어 데이터의 일관성과 객관성이 보장되지 않거나 체계적이고 통합적인 관리가 이루어지지 못하는 경우가 많다. QDMS (Quality Data Management System) 은 소프트웨어 개발 주기 중 리뷰와 테스팅 과정에서 산 출되는 결함 및 신뢰성 척도 데이터 등 품질 데이터를 체계적으로 관리하는 시스템이다. 웹기반 데이 터를 수집할 수 있도록 유도하며, 측정치의 의미와 활용에 대한 가이드를 도구 내에서 제공받음으로써 측정자에 대한 교육 강화 및 정확한 측정과 기록이 보장되도록 돕는다. 수집된 데이터는 측정자뿐만 아니라 관리자가 한눈에 파악할 수 있도록 그래프와 모델을 이용한 가시화된 대시보드를 제공하며, 여 러 품질 데이터들을 연계하여 척도의 분석 및 통계적 기능을 제공한다. 간단히 요약하면, QDMS는 테 스트 프로세스에서 측정 가능한 측도와 척도를 수집하여 관리자가 편리하게 활용할 수 있는 정보로 가 공 및 표현하는 기능을 목표로 한다. 소프트웨어 개발 주기 중 리뷰와 테스트 과정에서 산출되는 결함 및 신뢰성 척도 데이터와 같은 품질 데이터를 체계적으로 관리하는 시스템이며 주요 특징은 다음과 같다. - 63 -

Page64

- 프로젝트 관리 - 결함 관리 - 신뢰성 척도 설정 관리 - 신뢰성 척도 데이터 관리 / 분석 - 사용자 관리 - 품질 데이터 분석 리포트 관리 [그림 29] M&A 지원 도구 화면-품질 데이터 현황 주요기능은 프로젝트 관리, 결함 관리, 척도 설정 관리, 척도 데이터 관리, 척도 데이터 분석, 사용자 관리, 리포트 관리, 외부데이터 통합 (WIST/ADDRE/RELEX)이며 컨텍스트 다이어그램을 이용하여 시 스템이 외부 개체와 상호작용하는 방식을 보여주기도 한다. 먼저 시스템 관리자는 QDMS에 사용자 관 리를 하는 역할이고, 프로젝트 관리자는 프로젝트 관리, 척도 설정관리, 리포팅을 확인하는 역할을 가 지고 있다. 프로젝트 멤버는 척도데이터 관리와 결함관리를 주로 수행한다. QDMS는 기본적으로 제공 하는 기능 외에 다른 신뢰성 지원 도구들과의 연동을 지원한다. WIST (Web-based Inspection & Formal Review Support Tool)은 웹기반으로 소프트웨어 리뷰 프로세스에서 데이터를 수집하는 도구이 다. WIST가 인스펙션과 리뷰 결과 데이터를 QDMS 저장소에 저장한 후, WIST는 QDMS의 척도 분석 결과를 확인할 수 있게 된다. - 64 -

Page65

3) 내장형 소프트웨어 신뢰성 분석 지원 도구 내장형 소프트웨어 신뢰성 분석 지원 도구는 소프트웨어 신뢰성 예측 모델과 추정 모델을 이용한 신 뢰성 계산과 하드웨어의 정보를 통합한 시스템 신뢰성을 계산하기 위해 개발된 도구이다. 이 도구는 개발 전 단계에 걸쳐 소프트웨어 신뢰성을 분석, 평가할 수 있는 도구로써 주요 특징은 다음과 같다. - 소프트웨어 규모, 개발 조직 특성 등 프로젝트 데이터를 이용하여 소프트웨어 신뢰성 예측 - 구현 이후 테스팅 및 유지보수 단계에서 발생하는 실패 데이터를 입력받아 소프트웨어 신뢰성 추정 - 하드웨어와 연관되어 발생하는 소프트웨어 실패를 고려한 내장형 소프트웨어 신뢰성 예측 아래의 그림은 내장형 소프트웨어 신뢰성 분석 지원 도구에 포함된 전체적인 모델을 나타내는 개념도 이다. 예측하고자 하는 모델을 도구에서 선택하면 좌측의 그림과 같은 화면이 나타나며 사용자 가이드 에 따라 데이터를 입력하면서 신뢰성 분석 작업이 이루어진다. [그림 30] 신뢰성 분석 지원 도구 개념도 위의 그림에서 보는 것처럼 도구에 포함된 다양한 모델들은 시스템 개발 동안 발생하는 여러 데이터를 입력으로 받으며 신뢰성과 관련한 유용한 척도들을 출력으로 제공한다. 도구의 입력 데이터로는 Prediction을 위한 데이터(환경, 경험 요소, 프로세스 활동과 연계한 측도로부터 수집된 데이터 값, CMM 레벨), Testing 동안에 수집되는 Pure 소프트웨어 실패 데이터, HW와의 Interaction에 의해 발 생하는 소프트웨어 실패 데이터, 하드웨어 초기 실패율 등이 있다. 이들 데이터는 소프트웨어 개발자, 프로젝트 매니저나 테스터들을 통해 수집되며 도구의 다양한 모델을 통해 보통 초기 결함 수(Initial Fault Content), 고장 간 시간(Time To Next Failure), 남아 있는 결함 수(Number Of Remaining Faults), 소프트웨어 신뢰성 함수(Software Reliability Function), 결함 밀도 함수(Fault Density Function), 시스템 결함율(System Failure rate)와 같은 신뢰성 척도들을 출력한다. - 65 -

Page66

도구에서 사용되는 모델 소프트웨어 신뢰성 분석 지원 도구는 소프트웨어에서 요구하는 모델의 고려사항을 참조하여 소프트웨 어 개발 단계별도 신뢰성 모델을 적용한다. 그러나 소프트웨어 개발 과정에서 적용하는 모델은 달라 질 수 있다. - 시스템 분석/소프트웨어 요구사항 단계 소프트웨어 개발 초기단계에는 개발되는 소프트웨어의 유형이나 개발환경 등 데이터를 이용하여 초기 결합밀도를 계산하는 RL-TR-92-52 모델을 적용한다. - 구현 및 단위테스트 단계 소프트웨어 구조를 알 수 있는 단계이므로 소프트웨어 실행 경로에 의한 신뢰성을 정량화할 수 있는 Shooman 모델을 적용한다. - 통합 테스트 단계 테스트 단계에서는 가장 많은 신뢰성 데이터가 발생하므로 본 연구에서는 복수개의 신뢰성 모델을 적 용하고자 한다. 우선 국방에서 가장 많이 사용하고 검증된 모델인 Schneidewind 모델을 적용한다. 또 한 다양한 형태의 데이터를 분석하기 위해 소프트웨어 개발 후반기에 사용할 수 있는 신뢰성 모델을 추가적으로 적용하여 이를 통해 구해진 신뢰성 추정치를 비교분석한다. - 체계 테스트 단계 이와 같은 소프트웨어 신뢰성 모델을 통해 신뢰성을 평가하며 다음의 목적으로 활용 될 수 있다. 소 프트웨어 개발 단계별 해당 시점에서 신뢰성을 정량적으로 기술함으로써 신뢰성 목표 수준 대비 평가 가 가능하며 이를 통해 효과적인 테스트신 전략 수립 및 품질 관리 방안 수립을 할 수 있다. 예를 들 어, 테스트에 투입되어야 하는 기간과 노력을 산정하는 기준으로 활용하거나 개발된 소프트웨어의 배 포 시점, 다음 결함 발생 시점 등을 결정/예측하는 기준으로 활용될 수 있다. 그리고 신뢰성과 시스템 의 성능, 비용, 개발기간과 같은 시스템 요소들 간의 상호연관 관계를 결정하는 소프트웨어 설계과정 을 마련해 준다. 신뢰성 예측 모델 대표적인 소프트웨어 신뢰성 예측은 RL_TR_92_52 모델이다. 다음 그림은 도구에서 RL-TR-92-52 모델의 각 단계별 측정치를 측정하기 위한 화면이다. RL-TR-92-52 모델은 크게 3단계로 나누어 초기 결함 밀도를 예측하게 된다. 즉, 프로젝트 수행 경험에 기반을 둔 체크리스트에 대한 응답을 입 력으로 각 단계별 초기 결함 밀도를 예측한다. 본 모델은 시스템 분석, 소프트웨어 요구사항 분석 및 설계, 구현 및 단위 시험 단계에서 소프트웨어 신뢰성 예측이 가능하다. - 66 -

Page70

가. 연차별 연구 성과 목표 및 평가 착안점 본 연구를 통해 목표하는 연구 성과로, 총 15편의 논문(국외논문(SCI급 포함): 8편, 국내논문(SCI급 포함): 7편)과 특허 출원 4건, 특허 등록 2건을 목표로 한다. 연구 점검 시 주요 연구 성과 척도로써 국내외 논문과 관련 특허를 주요 실적 지표로 삼을 수 있을 것이다. (단위 : 편,건,명) 국외논문게재 국내논문게재 특허출원 특허등록 인력양성연도 SCI 비SCI 계 SCI 비SCI 계 국내 국외 계 국내 국외 계 석사 박사 계 1차년도 0 2 2 0 2 2 1 0 1 0 0 0 2 0 2 2차년도 1 2 3 0 2 2 1 0 1 1 0 1 2 0 2 3차년도 1 2 3 1 2 3 1 1 2 1 0 1 2 1 3 나. 연구 개발목표의 달성도주요 연구 성과로써 전체 과제기간 동안 총 15편의 논문(국외논문(SCI급 포함): 9편, 국내논문(SCI급 포 함): 6편)이 게재 및 발표 되었으며 목표로 했던 논문 수를 모두 달성하였다. 부족한 국내 논문 수는 초과 달 성 된 해외 논문 실적으로 보완되었다. 그리고 최근의 연구 진행 상황으로 미루어 보아, 더 많은 수의 논문 제출 및 특허 출원이 가능할 것으로 예상한다. 특히 본 연구에서 제안하는 고객 요구 신뢰성 목표의 설정에 관한 연구는 현재까지 국내/외에서 연구가 진행된 사례가 많지 않을 뿐만 아니라, 최근 자동차, 국방/항공, 의 료 산업 등에서 내장형 소프트웨어의 의존도가 높아짐에 따라, 각 산업별 고객의 신뢰성 요구 목표에 대한 인 지도가 높아지고, 그에 따른 산업적 요구가 커짐에 따라 더욱 활발한 연구가 진행될 것으로 예상 된다. - 70 -

Page71

목 표 달성도(%) 내 용● MND_SCEMP: an Empirical Study of a Software Cost Estimation Modeling Process in the Defense Domain, Empirical 해외 SCI 2편 100 % Software Engineering, 2012● Validating Software Reliability Early through Statistical Model Checking, IEEE Software, 2013 (게재 확정)● Identification of Quality Improvement Strategies using COPQ in Software Industry, International Journal of Performability Engineering, 2012● Improvement of Software Reliability Estimation Accuracy with Consideration of Failure Removal Effort, IJNDC 2013● An Embedded Software Reliability Model with Consideration of Hardware related Software Failures, SERE 2012해외 비 SCI 6편 ●116% A UML Model based White Box Reliability Prediction to (해외 컨퍼런스 포함) Identify Unreliable Components, SSIRI 2011● Designing an architecture of SNS platform by applying a product line engineering approach, ICIS 2012● An Integrated Software Management Tool for Adopting Software Product Lines, ICIS 2012● A Hypothetical Scenario-based Analysis on Software Reliability Evaluation Approaches in the Web environment, SNPD 2013, (Accepted)● 소프트웨어 개발초기단계에서 정량적 소프트웨어 신뢰성 목표 설정 방법, 정보과학회 논문지: 소프트웨어 및 응용 제 38권 제 5 호, 2011.● 다목적 유전자 알고리즘기반 소프트웨어 모듈에 대한 신뢰성 할당 최적화, 정보과학회 논문지: 소프트웨어 및 응용 제 39권 제 3호, 2012.국내 논문 7편 86% ● 서비스 지형 아키텍처에서의 신뢰성 평가 연구 비교, 한국 소 프트웨어공학 학술대회, 2013년 1월● 산포도를 이용한 소프트웨어 인스펙션 척도의 기준치 비 의존 상대적 데이터 분석, 한국정보처리학회 추계학술대회, 2012년 12월● 하드웨어와 소프트웨어 상호작용을 고려한 시스템 신뢰성 모 델링 접근방법, 한국정보처리학회 추계학술대회, 2011년 12월● 소프트웨어 신뢰성 평가 도구 분석, 2010년 11월 - 71 -

Page72

다. 관련 분야의 기술 발전에의 기여도 IT 융합 관점에서 보면 국내 시장에서 국산 내장형 소프트웨어의 보급률이 낮은 대표적인 요인으로 국산 내장형 소프트웨어의 신뢰성이 충분히 확보되지 못하고 있다는 점을 들 수 있다. 본 연구는 산업 구조 측면에 서 내장형 소프트웨어 신뢰성 보증 방안 및 체계를 확립함으로써 국내 시장에서의 국산 내장형 소프트웨어 보 급률 향상 및 해외시장 진출을 모색하는 기반 기술로서 활용 될 수 있다. 기업 측면에서는 내장형 소프트웨어 를 개발하는 중소기업의 품질 관리 체계 확립을 위한 기반기술을 확보하고 아울러 내장형 소프트웨어 신뢰성 확보 및 내장형 소프트웨어 기반 공정 관리 시스템의 생산성 향상에 기여하였다. 기술 측면에서는 내장형 소 프트웨어의 핵심 기술로서 신뢰성 개선 및 측정방안을 확립하고, 내장형 소프트웨어 신뢰성 평가 방안 지침서 작성을 통해 신뢰성 개선 및 측정에 관련한 세부 방법론을 확립할 수 있도록 하였으며, 또한 작성된 지침서를 활용한 내장형 소프트웨어 신뢰성 개선 및 측정 시범 적용을 통해 다양한 산업 도메인에 독립적이고 표준화된 산업 인프라로서 내장형 소프트웨어 신뢰성 개선 방안 확립에 기여하였다.

Page72

고객 신뢰성 목표 기반 내장형 소프트웨어 신뢰성 측정 및 개선 방안에 대한 연구는 기존 수행연구들이 공 통적으로 갖는 문제점인 신뢰성 목표 수준 설정이 올바르게 이루어지지 못해서 발생하는 모델 개발 및 적용의 어려움과 국방 소프트웨어의 특성인 내장형 소프트웨어와 순수 소프트웨어 간의 차이로 인한 문제를 해결하기 위해 수행되었다. 이를 위해 여러 논문 연구들을 수행하였으며 LG전자, 삼성 탈레스 등의 국내 소프트웨어 개 발 조직에 연구들을 적용하여 그 유용성을 증명하였다. 그리고 M&A(Measurement & Analysis) 도구와 내장 형 소프트웨어 신뢰성 분석 지원 도구를 개발하여 소프트웨어 신뢰성 보증을 위한 프로세스 지원하도록 하였 다. 우선, 개발 초기 단계에서 정량적 소프트웨어 신뢰성 목표 설정 방법을 제시하였으며 사례 연구를 통해 제안하는 방법이 적절한 신뢰성 목표를 설정하는데 있어 유용한 방법이 될 수 있음을 보였다. 그리고 각 모듈 별 신뢰성 목표 값 할당을 위해서는 유전자 알고리즘을 활용하여 비용과 개발 기간을 모두 고려하는 신뢰성 목표값 할당 방법을 제시하였다. 신뢰성 목표값 설정과 관련이 깊은 소프트웨어 개발 비용의 추정을 위해서는 MND-SCEMP라는 한국 국방 도메인에 적합한 프로세스를 제시하였고 100여개의 국내 무기 관련 프로젝트에 대한 Empirical study를 수행 하여 적합성을 검증하였다. 그리고 품질 평가 모델인 Constructive Quality Model(COQUALMO)와 Defect Amplification Model(DAM)을 통합하여 COPQ 평가를 수행하였으며 이를 통 해 개발 조직들이 소프트웨어 품질 향상 전략을 설립하는데 기반을 다질 수 있게 하였다. 내장형 소프트웨어 의 중요한 이슈사항인 하드웨어와 소프트웨어의 상호작용 실패를 고려하는 신뢰성 분석을 위해서는 마르코프 체인을 이용하여 모델링하는 방법과 NHPP기반의 모델을 제시하여 내장형 소프트웨어에는 이러한 상호작용 실패를 고려한 신뢰성 모델이 적합함을 보였다. 구현 이전 단계에서 신뢰성 예측을 위해서는 UML 모델을 활 용한 기법을 제시하고 운용프로파일의 변화에 따른 신뢰성 값의 변화를 시뮬레이션을 통해 나타내었으며 소프 트웨어 신뢰성 검증을 위해 SMC(Statistical Model Checking)을 이용하는 방안을 제시하였다. 이는 automobile 도메인의 Fault-Tolerant Fuel control system(FFCS)에 대한 사례 연구를 수행함으로써 SMC에 - 72 -

Page73

대한 결과의 우수성을 입증하였다. 본 연구 개발의 결과는 국내 내장형 소프트웨어의 신뢰성 측정/분석/평가/보증 방안 및 신뢰성 관점의 조직 체계를 확립하고 이를 보급함으로써 내장형 소프트웨어를 개발하는 기업의 시장 경쟁력을 강화하고 나아가 중 소기업간 클러스터 구성이 가능하도록 지원할 예정이다. 이를 통해 국내 시장에서의 국산 내장형 소프트웨어 보급률 향상 및 해외시장 진출 모색하는 기반 기술로서의 역할을 기대할 수 있다. 그러나 해당 연구를 수행함에 있어 발견된 또 다른 연구과제로 첫째, 자동화 된 측정 및 분석 (Measurement & Analysis) 방법의 고안이다. 개발 프로세스 상에서 발생하는 데이터를 수집하기 위해 전통 적으로 사용되는 방법은 개발 중간 중간에 작업을 기록하는 수동(Manual) 수집 방법이다. 이번 연구를 통해 서 개발 된 웹 기반의 QDMS(Quality Data Management System)이라는 척도 데이터 수집 및 측정 도구도 대부분이 개발자들에 의한 수동 입력으로 구성되어 부가적인 업무 부담을 줄 뿐만 아니라 데이터의 오류 가능 성 또한 많아진다. 결국, 완전(fully) 자동화 된 데이터 수집 방안이 고안되지 않으면 부 정확한 신뢰성 추정 을 유발하고 개발자의 효율성에 부정적인 영향을 미치게 된다. 이를 해결하기 위해 시스템의 백 그라운드에서 돌아가는 데이터 자동 수집/분석 시스템의 고안이 필요하며 이는 척도 데이터 수집을 위해 필요한 개발자들의 수고를 덜 뿐만 아니라 보다 정확한 정량화된 신뢰성 값의 도출을 이끌 수 있으며, 절약된 시간에 소프트웨어 개발에 보다 집중함으로써 개발 생산성 향상에도 기여할 수 있을 것으로 판단된다. 둘째, 신뢰성 평가를 위한 방법과 도구들이 각각 분리되어 개발되고 정보나 모델들을 공유하지 않는다는 것이다. 그 결과, 아키텍처 설계를 위한 도구와 컴포넌트들의 신뢰성 추정을 위한 도구, 각 컴포넌트의 신뢰성 을 통합하는 아키텍처 레벨의 신뢰성 분석 도구가 각각 따로 존재하여 정보나 모델들을 새롭게 입력해야 하는 문제점이 발생하고 각 도구간의 일관성에도 불일치의 문제가 발생한다. 이를 해결하기 위해, 초기 단계의 신 뢰성 목표 설정부터 디자인, 구현, 테스트, 배치 단계에서 신뢰성 분석을 일관성 있고 차질 없게 수행할 수 있 도록 기존의 기법들을 통합하는 툴 체인의 개발이 필요하다. 이를 통해 reliability-driven software development가 가능할 것으로 판단된다. 그리고 국내에서는 아키텍처 단계에서 수행될 수 있는 신뢰성 연구 가 부족한 실정이다. ATAM 등의 아키텍처 품질 평가 방법이 있지만 신뢰성 품질에 대한 적절한 평가 없이 구현 및 테스트가 진행되고 있다. 특히, 대형 소프트웨어 시스템의 경우, 더 이상 단일팀에 의해 단일 시스템 으로 개발될 수 없으며 여러 팀에 의해 제작되고 합쳐지기 때문에 전체 시스템의 아키텍처를 어떻게 구성하느 냐는 중요한 이슈이다. 기능 구현에만 초점을 둔 아키텍처 설계는 품질 요구사항을 충족시키지 못하는 문제를 발생시키기 때문에 디자인 단계에서 아키텍처에 대한 신뢰성은 반드시 고려되어야 한다. 그러므로 앞서 제기 된 데이터 수집 및 분석의 자동화를 위한 연구와 아키텍처 신뢰성 자동 평가 방안에 대한 연구를 수행하여, 기존 연구가 갖는 문제점을 해결하고 이를 더욱 확장/심화된 연구로 발전시키기 위한 추가 연구가 필요하다.

Page73
고객 신뢰성 목표 기반 내장형 소프트웨어 신뢰성 측정 및 개선 방안에 대한 연구를 수행하면서 전 세계적 으로 최근에 이슈가 되고 있는 서비스 지향 아키텍처(SOA)나 클라우드 컴퓨팅(SaaS)에서의 신뢰성 분석 기 - 73 -

Page74

법의 필요성을 알 수 있었다. 이에 이쪽 도메인에서는 어떠한 연구가 수행되고 있는지 관련된 해외과학기술정 보를 수집하여 아래와 같이 정리하였다. SOA 시스템에서의 신뢰성 평가는 아래의 그림과 같이 단위 서비스 (Atomic service) 신뢰성과 조합 서비스(Composite service) 신뢰성 2가지로 나뉜다. 단위 서비스는 특정 임 무를 수행하기 위해 어떤 다른 서비스나 리소스를 요구하지 않는 서비스이며 이러한 단위 서비스들이 결합하 여 새로운 서비스를 구성하게 되는 데 이를 조합 서비스라고 한다. SOA 시스템의 신뢰성 평가에서는 아래의 그림과 같이 개별적인 단위 서비스 신뢰성을 어떻게 측정할 지와 이들을 조합하는 조합 서비스 신뢰성을 어떻 게 작성할건지가 관건이다. [그림 35] SOA에서의 신뢰성 평가 SOA에서의 조합 서비스 신뢰성은 각 서비스의 조합이라는 측면에서 컴포넌트 기반 신뢰성 모델과 비슷하다. 그러므로 기존에 컴포넌트 기반 신뢰성 모델에서 고려되었던 모든 신뢰성 기법들을 그대로 적용할 수 있을 것 이라고 판단할 수도 있다. 하지만 SOA 시스템은 웹이라는 특성 때문에 기존과는 다른 다양한 실패들이 발생 할 수 있으며 이를 고려하는 것이 중요하다. 원격 웹 서비스들은 보통 다른 기관에 의해 소유되며 웹 서비스 의 호출은 비용이 드는 경우가 많기 때문에 테스트를 통한 웹 서비스 후보들의 평가는 많은 비용을 초래한다. 그러므로 테스트를 통한 실패 데이터를 얻기가 단일 애플리케이션 보다 어렵다. 그리고 서비스 사용자들은 서 로 다른 지리적, 네트워크 환경에 놓여있기 때문에 각 사용자마다 다른 신뢰성을 가지게 된다. SOA 시스템의 신뢰성 추정을 위해서는 이러한 동적인 환경에서 발생하는 실패들이 고려되어야 한다. 이와 같이 SOA 시스템 의 신뢰성 추정은 기존 컴포넌트 기반 소프트웨어보다 훨씬 어렵지만 이를 통해 새로 만드는 웹 서비스의 신 뢰성을 판단하거나 여러 후보 웹 서비스 중 적합한 웹 서비스를 선택하는데 도움을 줄 수 있기 때문에 적절한 추정 기법이 고안되어야 한다. 가. 단위 서비스 신뢰성 추정 기법 기존의 전통적인 소프트웨어와는 다르게 SOA 시스템에서는 테스트 동안의 결함 제거로 인한 신뢰성 성장 현상을 보는 것이 아니라 서비스 실행 중에 동적인 인터넷 환경으로 인해 발생하는 다양한 실패들을 고려하기 때문에 Nelson model과 같은 Input domain based models이 주로 사용된다. 그렇기 때문에 시스템이 호출될 때 그것의 임무를 성공적으로 수행할 확률을 의미하는 Reliability on demand 와 같은 정의가 주로 사용된다. 기존의 소프트웨어 신뢰성 정의는 주어진 임무시간 동안 실패 없이 동작해야 하는 소프트웨어 시스템에 적합 - 74 -

Page75

한 반면 Reliability on demand의 정의는 한번 호출되면 성공적으로 완료되어야 하는 서비스를 제공하는 시스 템(Service delivery systems)들과 관련이 있다 [15]. Nelson model [16]에서 신뢰성 값은 1에서 실패율(r) 을 뺀 값으로 간단히 계산될 수 있으며 여기서 웹 서비스 실패율은 총 서비스 호출 수(n)를 누적 실패 수(f) 로 나누어서 계산한다. 결국 단위 서비스 신뢰성 추정을 위해서는 전통적인 소프트웨어 신뢰성 추정을 위해 사용하였던 통계적 기법 을 사용하기 보다는 서비스를 호출 했을 때 실패의 확률을 구하는 것이 관건이다. 이 정보를 어떻게 얻느냐가 중요한 부분이며 여러 논문들이 이를 해결하기 위해 여러 가지 방법들을 도입하고 있다. 각 연구들에서 단위 서비스 신뢰성 추정을 위해 사용한 기법들은 실패 데이터를 획득하는 방법에 따라 아래의 3가지 접근방법으 로 분류할 수 있다. 로그 정보 기반 방법 첫 번째 신뢰성 추정 기법은 Web service들의 실행 중에 발생하는 로그 정보를 이용하는 것이다. 확 장된 UDDI 모델 [18]은 UDDI에서 서비스의 호출, 실행, 실패 정보를 모니터하고 파일화 한다. 로그 정보를 저장하는 것은 UDDI 또는 중간 서버가 될 수 있으며 이들 정보를 이용하여 각 웹 서비스의 신뢰성이 Nelson model을 이용하여 계산된다. 테스트 기반 방법 WebStrar라는 기반 시설을 제시하고 여기서 등록된 모든 서비스들에 대한 그룹 테스트를 수행한다 [19]. 과반수 투표(majority voting)를 통해 실패 하는 서비스들을 판별하여 테스트 대비 에러 수를 로그에 기록한다. 기록되는 정보를 이용하여 각 서비스의 신뢰성은 Nelson model을 이용하여 계산된 다. 하지만 서비스 요청이나 입력 값이 들어올 때 마다 같은 그룹내의 서비스들이 모두 테스트 되어 야 하는 비 효율성이 존재한다. Andrew G. Liu et al [20]은 사용하고자 하는 Web 서비스들을 출시 전 여러 번 호출 해보고 매 시간당 발생하는 실패 패턴을 분석하여 재 측정(Recalibrate)한다. 이 역 시 서버의 리소스를 많이 요구하는 단점이 존재한다. 협동 기반 방법 협동 기반 방법 [21]은 비슷한 실패 유형을 가지는 다른 사용자를 식별하고 해당 사용자의 각 서비스 에 대한 실패 확률 정보를 참고하여 웹 서비스 신뢰성을 계산한다. 이 방법에서 모든 사용자들의 각 서비스에 대한 실패확률 정보는 미들웨어를 통해 중앙 서버에 자동적으로 저장된다. 중앙 서버에서 비슷한 실패 패턴을 가지는 사용자들을 식별하고 그 사용자들의 정보를 이용하여 해당 서비스의 실패 확률을 예측한다. 하지만 이 방법은 모든 사용자들로부터 각 서비스들에 대한 실패 확률 정보를 요구 하며 많은 정보의 교류로 인한 리소스 문제 역시 발생할 수 있다. 그리고 새롭게 개발된 웹 서비스나 새로운 사용자의 경우는 참조할 데이터가 없기 때문에 협동 기반 방법을 사용하지 못하는 한계가 있 다. - 75 -

Page77

소속기관 논문게재지/특허등록국 논문게재일 특기사항번호 논문명/특허명/기타 역할명 가 /특허등록일 (SCI여부) MND_SCEMP: an Empirical Study of 1 a Software Cost Estimation Modeling KAIST 교신저자 Empirical Software 2012.08.17 SCIEngineeringProcess in the Defense Domain 2 Validating Software Reliability Early KAIST 참여저자 IEEE Software 2013.05.01 SCIthrough Statistical Model Checking I n t e r n a t i o n a l Identification of Quality Improvement 3 l of Strategies using COPQ in Software KAIST 참여저자 Journa 2012.11.01P er f o r m a b i l i t y Industry Engineering (8/6) 4 다목적 유전자 알고리즘기반 소프트웨 KAIST 교신저자 한국정보과학회 논 2012.03.01어 모듈에 대한 신뢰성 할당 최적화 문지(제39권 제3호) 5 소프트웨어 개발초기단계에서 정량적 KAIST 교신저자 한국정보과학회 논 2011.05.01소프트웨어 신뢰성 목표 설정 방법 문지(제38권 제5호) - 77 -

Page78

[1] "소프트웨어 기업 프로세스 능력 수준조사", 한국소프트웨어진흥원, Nov. 2007. [2] 강동식, "IT 융복합시대 소프트웨어 테스팅 뜬다", 디지털타임스, July 2008. [3] Myungmuk Kang, "A User Friendly Software Reliability Analysis Tool based on Development Process to Iteratively Manage Software Reliability", International Symposium on Software Reliability Engineering, 2009. [4] W.H.Farr. “A survey of software reliability modeling and estimation”, NJaval Surface Weapons Center, Sept. 1983. [5] N. Nagappan, Wiolliams, L., Vouk, M.A., “Toward a Metric Suite for Early Software Reliability Assessment”, ISSRE 2003. [6] Lyu, M.R., Nikora, A. "CASRE: a computer-aided software reliability estimation tool", Computer-Aided Software Engineering, 1992 [7] Trivedi, K.S., "SREPT: a tool for Software Reliability Estimation and Prediction," Dependable Systems and Networks, 2002. [8] Davidsson, M. et al, "GERT: an empirical reliability estimation and testing feedback tool," Software Reliability Engineering, ISSRE 2004. [9] Taeho. L, Taewan. G, Jongmoon B, “MND_SCEMP: an Empirical Study of a Software Cost Estimation Modeling Process in the Defense Domain”, Empirical Software Engineering, 2012. [10] Youngjoo. K, Okjoo. C. Moonzoo. K, Jongmoon. B, Taihyo. K, “Validating Software Reliability Early through Statistical Model Checking”, IEEE Software, 2013 (게재 확정) [11] Yeongseok. S. et al, “Identification of Quality Improvement Strategies using COPQ in Software Industry”, International Journal of Performability Engineering, 2012 [12] Myungmuk. K, et al, “Improvement of Software Reliability Estimation Accuracy with Consideration of Failure Removal Effort”, IJNDC 2013. [13] Jinhee. P. et al, “An Embedded Software Reliability Model with Consideration of Hardware related Software Failures”, SERE 2012. [14] Daeeui. H. et al, “A UML Model based White Box Reliability Prediction to Identify Unreliable Components”, SSIRI 2011. [15] V. Grassi, “Architecture-Based Reliability Prediction for Service-Oriented Computing”, ARCHITECTING DEPENDABLE SYSTEM III, LNCS 3549, pp. 279-299, 2005. [16] E. Nelson, Estimating software reliability from test data, Microelectronics and Reliability, 17(1):67-73, 1978. [17] Reussner, R. Schmidt, H., Poernomo, I., "Realibility Prediction, for Component-based Software - 78 -

Page80

사업명 핵심개인연구 연구책임자 백종문 주관기관 한국과학기술원 과제번호 2010-0014375 과제명 고객 신뢰성 목표 기반 내장형 소프트웨어 신뢰성 측정 및 개선 방안 과학기술/학술적 연구성과(단위 : 건) 학술대회전문학술지 논문게재 지식재산권 출판실적초청 논문발표 수상 국내논문 국외논문 강연 출원 등록 실적국내 국제 저역서 보고서SCI 비SCI SCI 비SCI 실적 국내 국외 국내 국외 0 2 1 2 0 4 4 0 0 0 0 0 0 0 인력양성 및 연구시설(단위 : 명,건) 학위배출 국내외 연수지원 장기 단기 산학강좌 연구기자재박사 석사 국내 국외 국내 국외 0 3 0 0 0 0 0 2 국제협력(단위 :명,건) 과학자교류 국제협력기반 학술회의개최 국내과학자 외국과학자 MOU체결 국제공동연구 국제사업참여 국내 국제해외파견 국내유치 0 0 0 0 0 0 0 산업지원 및 연구성과 활용(단위 : 건) 기술확산 연구성과활용(사업화 및 후속연구과제 등) 기술실시계약 기술이전 기술지도 기술평가 후속연구추진 사업화추진중 사업화완료 기타목적활용 0 0 0 0 1 0 0 0 Accepted Papers Validating Software Reliability Early through Statistical Model Checking (게재 확정) - 저널명 : IEEE Software 2013 - 저자명 : 김영주, 최옥주, 김문주, 백종문, 김태호 A Hypothetical Scenario-based Analysis on Software Reliability Evaluation Approaches in the Web environment(Accepted) - 학회명 : SNPD 2013 - 저자명 : 박진희, 김현정, 백종문 - 80 -

Page82

[별첨1] 〈 대 표 연 구 성 과 〉 대표연구업적 요약문 연구업적 제목 MND_SCEMP: an Empirical Study of a Software Cost Estimation Modeling Process in the Defense Domain 학술지게재논문(O) 저서( ) 역서( ) 특허( ) 국제학회 초청강연( ) 연구업적 유형 학술지 편집위원 참여( ) 기술이전( ) 기타( )주관연구책임자 또는 공동연구원 성명 백 종 문 참여자수 3 ▣ 요약문 신뢰성 목표 설정에는 개발 비용 요소도 고려가 되어야 한다. 소프트웨어 개발 비용의 정확한 추정은 국방 도메인에서 매우 중요하지만 현존하는 소프트웨어 비용 추정 모델과 도구들은 정확성 측면에서 문제점을 가 지고 있다. 본 연구에서는 MND-SCEMP라는 한국 국방 도메인에 적합한 프로세스를 제시하였으며 비용 예 측에 영향을 미치는 여러 factor들을 반영하여 기존에 존재하던 소프트웨어 비용 예측 모델링 프로세스들의 단점인 ‘국방 도메인에서의 부정확한 예측을 개선하였다. 100여개의 국내 무기 관련 프로젝트를 통한 Empirical study를 수행함으로써 제안하는 MND-SCEMP이 한국 국방 도메인에 적합함을 객관적으로 증명하 였다. 프로젝트 매니저들은 MND-SCEMP를 이용하여 더욱 정확한 리소스 예측이 가능하며 이를 통해 성공 적인 프로젝트 수행이 가능할 것으로 기대한다. ▣ 본 과제 수행결과로 인한 대표 연구성과 작성 시 기술내용 - 논문의 경우 참여자의 역할(제1저자, 교신저자, 참여저자)을 기술 : 본 논문은 Empirical Software Engineering 저널(SCI급)에 2012년 개재된 논문으로 2010년 연구에 착수 하여 2012년 게재될 때까지 교신저자로서의 역할을 수행하였다. - 82 -