DEMATEL 기법과 내용분석을 이용한 임베디드 소프트웨어 결함요소 간의 영향 관계 분석

Ⅰ. 서 론

임베디드 소프트웨어는 자동차, 철도, 항공, 조선, 우주 등의 분야와 건설, 의료, 국방무기체계에 이르기까지 적용범위가 확대되고 있다. 임베디드 소프트웨어는 순수 소프트웨어와 마찬가지로 결함이 내재되어 있고, 결함으로 인하여 치명적인 사고가 발생하기도 한다. 의료계통에서는 방사선 치료기의 safety-critical 시스템의 결함으로 약 2년 동안 6건 이상의 과도한 방사선 방출로 인한 인명사고가 발생하였다. 나사 화성 탐색로봇인 패스파인더호가 화성에 착륙한 지 며칠 만에 시스템이 재기동이 되는 현상이 발생하였으며, 결국에는 250일 만에 통신이 두절되었고, 원인은 공유메모리 사용에 결함이 있는 것으로 밝혀졌다. 항공분야에서는 보잉 737기가 그리스 칼라모스 부근에서 이상이 발생해, 115명의 여행객과 승무원이 전부 사망하는 사건이 발생했었다. 이와 같이 역사 속의 중대한 시스템 사고의 이면에는 임베디드 소프트웨어의 결함에 의한 사고가 그것의 중심에 있다고 해도 과언이 아니다.

또한, 다양한 산업 분야에서 임베디드 소프트웨어가 사용되면서 소프트웨어의 위협도 높아져서 소프트웨어 오동작에 대한 안전성 위협이 큰 이슈로 부각되고 있다. 그로 인하여 결함을 체계적으로 제거하기 위하여 HAZOP(Hazard and Operability)기법이나 FMEA(Failure Modes and Effects Analysis) 기법 등을 이용하여 결함 원인과 영향, 상대적인 중요성 등을 평가하여 체계적으로 결함을 제거하려고 노력하고 있으며, 다양한 테스트 기법을 적용하여 임베디드 소프트웨어 내재된 결함을 제거하고 있다.

임베디드 소프트웨어는 일반 소프트웨어와 유사한 제어 논리가 있고, 일반 소프트웨어에서는 찾아보기 힘든 하드웨어를 밀접하게 제어하는 소프트웨어가 있다. 순수 소프트웨어 분야에서는 다양한 결함을 수집하여 핵심 결함을 도출한 연구가 있다. 이 연구에서는 소프트웨어에 내재된 결함은 전부 제거할 수 없으므로 핵심 결함을 집중적으로 제거하여 결함을 최소화하는 것이 효율적이고 효과적으로 소프트웨어를 개발하는 방법이라고 제시한다[1]. 하지만 임베디드 소프트웨어 결함에 대하여 조사한 결과, 체계적이고 통합적인 관점으로 분석한 연구는 없고, 연구자가 관심이 있는 분야에 대해서만 편향적으로 임베디드 결함을 분석한 연구가 주를 이루었다.

선행 연구에서는 임베디드 소프트웨어 결함에는 어떤 결함이 존재하고, 결함 간에는 어떻게 영향을 미치고 있으며, 어느 결함이 핵심 결함인 지에 대한 연구는 미흡한 것으로 파악되었다. 이에 본 연구에서는 기존에 연구자들이 연구한 임베디드 소프트웨어 결함을 수집하여 분류하고, 요소 간의 인과관계를 도출할 수 있는 데마텔(DEMATEL) 기법을 적용하여, 임베디드 소프트웨어 결함 간의 인과관계를 도출하고 핵심 결함을 도출하도록 한다.

임베디드 소프트웨어 결함 별로 인과관계를 산정할 수 있다면, 임베디드 프로젝트를 시작하기 전에 프로젝트 특성에 맞게 핵심 결함을 도출할 수 있을 것이다. 핵심 결함을 산정할 수 있다면, 좀 더 효율적이고 효과적으로 결함을 관리할 수 있을 것이며, 임베디드 소프트웨어 품질을 좀 더 용이하게 향상시킬 수 있을 것이다.

제 2장은 관련연구와 이론적 배경을 살펴보고, 제 3장은 연구 설계와 결과를 도출하고, 제 4장에서는 도출된 결과를 이용하여 임베디드 소프트웨어 결함 간의 인과관계와 핵심 결함을 분석하고 제 5장에서는 결론을 제시하였다.

Ⅱ. 관련연구와 이론적 배경

2.1 선행연구의 고찰

임베디드 소프트웨어 결함은 순수 소프트웨어 결함과 하드웨어와 제어하는 소프트웨어 결함이 존재한다. 우선, 순수 소프트웨어 결함에 대해서 살펴보면, 소프트웨어 결함 가중치 연구에서는 표 1과 같이 기관, 기업 및 연구자들이 소프트웨어 결함을 연구하였고, 연구된 결함을 수집하여 표 2와 같이 결함을 분류하였다. 그리고 인사, 급여, 회계 등 일반 어플리케이션에 대한 결함 간의 영향관계를 분석하여 ANP(Analytic Network Process)기법을 적용하여 핵심 결함을 산정하였다.

Table 1.

Sources of pure software defects

Table 2.

Pure software defects defined in prior study

이 연구에서는 프로젝트 수행 시 막연한 결함관리 보다는 핵심결함을 집중적으로 제거하면, 좀 더 효율적이고 효과적으로 소프트웨어 품질을 향상시킬 수 있다고 한다[1]. 이 연구는 순수 소프트웨어 결함에 대하여 인과관계를 분석하여 핵심결함을 도출한 연구로서 본 연구와 유사한 면이 있다. 하지만, 이 연구는 임베디드 소프트웨어 결함에 대한 연구는 아니다. 이 연구에서 정의한 순수 소프트웨어 결함은 체계적이고 통합적으로 분류했기 때문에 본 연구의 순수 소프트웨어 결함으로 활용하기로 한다.

다음으로 하드웨어를 제어하는 임베디드 소프트웨어 결함에 대한 연구를 살펴보면, 임베디드 시스템의 결함에 대하여 소프트웨어 테스트 방법을 제시한 도서가 있다. 이 도서에서 언급되고 있는 결함은 데이터 계산 결함, 구조적 논리 흐름, 하드웨어와 소프트웨어 간의 인터페이스, 시간 결함, 소프트웨어 오류 복구, 성능 테스트, 휴먼 인터페이스, 모바일/임베디드 보안 등 다양한 결함에 대하여 테스트하는 방법을 제시하였다[6]. 이 도서의 내용은 임베디드 시스템을 테스트할 때 유용하게 활용할 수 있을 것으로 보인다. 그렇지만, 임베디드 결함 간의 인과관계와 핵심결함을 도출하려는 연구는 아니다.

임베디드 소프트웨어의 중요한 열 가지 결함은 경쟁조건, 재진입할 수 없는 함수, 스택 오버플로우, 메모리 힙, 메모리 누수, 데드락(Deadlock), 우선순위 역전 같은 결함이라고 제시한 연구가 있다[7][8]. 하지만 이 연구도 임베디드 결함 간의 인과관계를 이용하여 핵심결함을 도출한 연구는 아니다.

임베디드 소프트웨어를 함체에 탑재하기 전에 대상 플랫폼 및 기능이 정확하게 동작하는 지 테스트하는 평가모델을 수행한 연구가 있다. 이 연구에서는 태스크 관리, 태스크 간 통신, 시간관리, 인터럽트, 예외처리, 메모리관리, 입출력관리, 네트워킹, 파일 시스템 등에 대하여 평가항목을 이용하여 테스트를 수행하였고, 수행 전에 문제가 없었다고 판단된 시스템에 대하여 결함을 발견하기도 하였다[9]. 이 연구는 아홉 가지 임베디드 결함에 대하여 평가항목을 마련하여 결함을 도출하는 연구로서 결함을 충실하게 평가할 수 있는 연구로 보인다. 하지만 이 연구에서 평가한 아홉 가지 임베디드 결함에 대한 출처가 명확하지 않고, 결함의 중요도를 고려하지 않았으며, 단순히 결함을 발견하는 측면으로만 진행한 연구로서, 결함 간의 인과관계를 도출하여 핵심 결함을 도출하려는 연구는 아니다.

이외에도 여러 임베디드 소프트웨어 결함 관련 자료를 조사하였고 여러 연구자들의 임베디드 소프트웨어 결함을 접할 수 있었지만, 체계적이고 통합적인 관점으로 분석한 연구는 찾아보기 어려웠다. 주로 연구자가 관심이 있는 분야에 대해서만 결함을 분석한 연구들이 존재하였다.

이상과 같이 임베디드 소프트웨어 결함에는 어떤 결함들이 존재하고, 결함 간에는 어떤 인과관계가 있으며, 그로 인하여 핵심 결함은 어떤 것인지에 대한 연구는 미흡한 것으로 파악되었다. 이에 본 논문에서는 소프트웨어 결함과 임베디드 소프트웨어 결함을 수집하여 데마텔 기법을 이용하여 임베디드 소프트웨어 결함 간의 인과관계를 도출하고 중요 결함을 도출하고자 한다.

2.2 실험방법의 이론적 배경

2.2.1 내용분석(Content Analysis) 기법

임베디드 결함을 살펴보면, 용어는 다르지만 의미가 동일한 경우가 있고, 연구자들 간의 분류가 불일치하는 경우가 있다. 내용분석 기법은 분석할 용어의 특성, 의미의 범주를 기준으로 분류하고 통합하는 기법이다[10]. 내용분석은 허니의 내용분석(Honey's Content Analysis)기법과 부트스트래핑(Bootstrapping Content Analysis)기법이 있다. 허니의 내용분석은 요소들 간의 차이를 유사도로 분류하는 기법이다. 본 연구에서 적용한 부트스트래핑 기법은 표 3과 같이 7단계를 통하여 수행한다.

부트스트래밍 기법은 연구자와 전문가가 각자 표 3의 절차를 따라서 용어를 분류한다. 분류한 이후에 서로 만나서 분류 관점을 토의하며 신뢰도 테이블(Reliability Table)를 이용하여 서로 일치하는 분류를 찾아낸다. 일치하는 분류는 합의된 것으로 채택하고, 일치하지 않는 것은 시간을 갖고 다시 분류한 후, 대면하여 분류 관점을 토의한다, 토의한 후 일치하는 분류는 합의된 것으로 채택하고 일치하지 않는 분류는 다시 수행한다. 이런 과정을 반복하여 합의된 분류를 도출한다. 합의된 분류에 대한 신뢰도는 분류지수(Categorization Index)를 이용하며 측정한다. 신뢰도는 대각선에 위치된 합의된 수치의 비율을 의미하며, 일반적으로 80%이상이면 양호하고 90%이상이면 우수하다고 한다[10].

Table 3.

Procedure of content analysis

2.2.2 데마텔 기법

데마텔은 1972년부터 1979년까지 제네바의 Battelle 기념연구소에서 복잡하고 얽혀있는 문제를 해결하기 위하여 개발되었다. 데마텔 기법은 구성요소들 간의 인과관계를 해결하는 가장 좋은 기법 중 하나로 알려져 있으며 여섯 단계를 통하여 인과관계를 도출한다[11].

첫 번째, 직접영향관계행렬(DRM, Direct Relation Matrix)을 도출하는 단계로서, 임베디드 소프트웨어 결함(i)이 다른 결함(j)에게 미치는 영향력을 m명의 전문가에게 설문을 받은 후, 아래 수식을 이용하여 평균을 산출한다. 결함 요소들 간의 영향력을 설문으로 수집한다.

$\[ \mathit{\text{Ai}}=\frac{1}{m}\sum _{i=1}^m{X}_i \]$

(1)

행렬 A는 전문가 m명이 평가한 값을 산술평균한 직접영향관계행렬(DRM) 값이며, A_i는 i번째 전문가가 평가한 행렬 값이다.

두 번째, 행렬을 정규화하는 단계이다. 행렬 A에서 행의 합의 최대값과 열의 합의 최대값으로 나눈 값 중에 작은 값을 선택한 후 그 값으로 곱하여 정규화된 행렬 N을 구하는 단계로서 수식 (2)와 (3)과 같이 표현할 수 있다. A_ij는 행렬 A의 i번째 행의 j번째 열에 해당하며, i,j={1,2,3,...n}이다.

$\[ s=\text{min}\left[\frac{1}{\text{max}\sum _{j=1}^n{A}_{ij }}, \frac{1}{\text{max}\sum _{i=1}^n{A}_{ij }}\right] \]$

(2)

$\[ N=\mathit{\text{sA}} \]$

(3)

세 번째, 전체 영향관계행렬(TRM, Total Relation Matrix)을 도출하는 단계이다. TRM을 T라고 했을 때, 단위행렬에서 N행렬을 뺀 값에 대한 역행렬이며 수식 (4)와 같이 표현할 수 있다.

$\[ T=N+N{}^2+N^3+\dots +N^m=N{\left(I-N\right)}^{-1} \]$

(4)

네 번째, 영향을 주는 요소들과 영향을 받는 요소들을 분리하는 단계이다. T 행렬에서 행(Row)의 합(D)과 열(Column)의 합(R)을 구하고 중심도(D+R)와 원인도(D-R)을 구한다. 원인도인 D-R>0이면 속성이 원인요소가 되고 D-R<0이면 속성이 결과요소가 된다.

$\[ D={\left[D_i\right]}_{n\times 1}={\left[\sum _{j=1}^n{T}_{\text{ij}}\right]}_{n\times 1} \]$

(5)

$\[ R={\left[R_i\right]}_{1\times n}={\left[\sum _{i=1}^n{T}_{\text{ij}}\right]}_{1\times n} \]$

(6)

다섯 번째, 인과관계도를 도출하기 위한 기준점(Threshold)를 선정해야 한다. 기준점은 T행렬의 요소들의 평균에 의하여 구할 수 있고, 수식은 (7)과 같다[11].

$\[ \sigma =\frac{\sum _{i=1}^n\sum _{i=1}^n\left[T_{ij}\right]}{n} \]$

(7)

마지막으로 기준점을 이용하여 T행렬에 적용하여 인과관계도(Casual & Effect Diagram)를 도식화한다.

3.1 연구 모델 설계 및 연구 수행

본 연구는 임베디드 소프트웨어 결함을 수집, 분류하고 결함 요소 간의 인과관계를 이용하여 핵심 결함을 도출하는 연구이다. 연구 절차는 그림 1과 같이 데이터 수집, 용어 표준화, 용어 분류, 설문 수행, 결과도출단계로 구성되어 있다.

Fig. 1.

Research procedures

첫 번째, 데이터 수집단계는 선행연구에서 연구된 임베디드 소프트웨어 결함 및 중요 요소를 수집한다. 두 번째, 용어 표준화단계는 수집된 결함 요소들의 관점 또는 용어에 따라서 중복되거나 다르게 분류되는 오류를 배제하기 위하여 용어 표준화를 수행한다.

세 번째, 용어 분류단계는 표준화된 결함 용어를 기반으로 연구자와 전문가가 표 3과 같은 내용분석의 부트스트래핑 기법을 통하여 용어를 그루핑한다. 네 번째, 설문 수행단계는 그루핑된 결함에 대하여 설문을 통하여 전문가들의 견해를 수집하고, 데마텔기법에 적용하여 결함 요소간의 인과관계를 도출한다. 마지막 결과도출단계는 결함요소 간의 인과관계도를 도식화하고 원인인자, 결과인자, 중심도 등을 산정한다.

3.2 결함요소 수집 및 논의

3.2.1 임베디드 소프트웨어 결함에 대한 논의

임베디드 소프트웨어 결함은 첫 번째 순수한 소프트웨어 측면의 결함을 수집해야 하고, 두 번째, 하드웨어를 제어하는 소프트웨어 결함을 수집해야 한다. 그렇지만, 본 연구는 하드웨어 자체 결함은 포함하지 않는다.

첫 번째, 순수 소프트웨어 결함은 표 1과 같이 기관과 연구자들에 의해 연구되었고, 소프트웨어 결함 가중치 연구[1]에서 표 2와 같이 순수 소프트웨어 결함을 분류하였다. 다음으로, 하드웨어와 밀접한 임베디드 소프트웨어 결함을 위하여, 다른 연구자들이 연구한 결함과 임베디드 시스템 아키텍처에서 중요 요소를 조사하였고, 표 4와 같이 수집되었다.

Table 4.

Embedded software defects and sources

각 연구자들이 연구한 표 2와 표 4의 결함의 결함들은 기관 및 연구자들의 관점에 따라 동일한 의미를 다르게 표현하거나 중복된 용어가 존재하므로 용어 표준화가 필요하다. 표준화는 선행연구에서 분류된 결함을 기반으로 임베디드 소프트웨어 전문가와 논의하여 대표 단어로 재정의하여 분류하였고, 표 5와 같이 표준화된 결함요소들이 도출되었다.

표 5와 같이 표준화된 임베디드 소프트웨어 결함에 대하여 표 3의 내용분석 절차를 이용하여 연구자와 전문가가 각자 결함을 분류하였고, 그림 2의 신뢰도 테이블(Reliability Table)를 이용하여 서로 일치하는 분류를 도출하였다.

Table 5.

Standardized embedded software defects

Fig. 2.

The result for content analysis of table 5

이런 과정을 여러 번 수행한 결과, 표 6과 같이 최종적으로 합의된 열두 가지의 임베디드 소프트웨어 결함이 도출되었다. 합의된 결함 분류의 신뢰도를 확인하기 위하여 분류 지수(Categorization Index)를 이용하였다.

Table 6.

Derived final embedded software defects

분류지수는 그림 2의 대각선에 위치된 합의된 수치에 대한 비율을 의미하며, 결함 요소 총 66 건 중 합의된 건수가 64건으로 분류 지수는 약 96% 정도로서 우수한 수준으로 분류되었다.

3.2.2 전문가 설문 수행 및 분석

표 6과 같이 도출된 열두 가지의 결함요소 간의 인과관계를 데마텔기법으로 도출하기 위하여, 임베디드 개발 전문가의 의견을 설문으로 수집하였다. 설문 응답자는 표 7과 같이 기술사를 중심으로 감리사와 특급기술자 14인을 대상으로 구성하였다. 설문은 열두 가지의 결함이 다른 결함에게 영향을 주는 정도를 0부터 4까지의 영향력(0.영향력없음, 1.영향력낮음 2.보통영향력, 3.높은영향력, 4.매우높은영향)을 선택하는 방식으로 진행하였다.

설문 데이터의 신뢰도를 진단하기 위하여 SPSS 도구를 이용하여 크론바흐 알파계수(Cronbach's α)를 측정하였다. 크론바흐 알파계수는 설문 값의 신뢰도를 측정하는 지표로서, 값의 범위는 0에서 1사이로 도출되며, 1 값에 가까울수록 신뢰도가 높다. 크론바흐 알파계수를 진단한 결과, 0.895라는 높은 값이 도출되었고, 응답자별로는 표 8과 같은 값으로 데마텔 설문 데이터의 신뢰도를 확인할 수 있었다.

Table 7.

Summary of embedded expert respondents

Table 8.

The analysis result of cronbach alpah

임베디드 소프트웨어 전문가의 결함 간의 영향관계 의견이 수집되었으므로, 설문을 기반으로 임베디드 소프트웨어 결함의 인과관계 도출을 위하여, 데마텔기법을 여섯 단계로 적용하였다. 첫 번째, 수집된 인과관계 행렬 값에 대하여 식 (1)을 대입하여 산술평균을 내었고, 표 9와 같이 일반화된 행렬(A)을 도출하였다.

두 번째, 일반화(A)된 행렬에 대한 정규화를 위하여 식 (2)을 이용하여 행의 합의 최대값, 열의 합의 최대값 중에서 최소값을 도출하여 식 (3)를 적용하였고, 표 10과 같은 정규화된 행렬(N)을 도출하였다.

세 번째, 정규화된 행렬(N)를 단위행렬의 역행렬을 구하는 식 (4)를 이용하여 적용하였고, 표 11과 같은 종합인과관계 행렬(T)를 구하였다. 네 번째, 표 11의 종합인과관계행렬(T)에서 행의 합(D)과 열의 합(R)을 구하고 식 (5)와 식 (6)을 이용하여 중심도(D+R)요인과 원인도(D-R)요인을 구한 결과, 표 12와 같은 결과가 도출되었다. 다섯 번째, 영향력을 판단하는 기준점은 식 (7)을 이용하여 계산하였고, 0.375라는 평균값이 도출되었다. 행렬 T에서 기준점보다 작은 값은 영향을 미치지 않는 것이고, 기준점보다 큰 값은 영향을 미치는 것이다. 마지막으로. 도출된 표 12를 이용하여 인과관계도를 도식화한다. 표 12의 원인도(D-R) 요인은 y축으로, 중심도(D+R)요인은 x축으로 기준점을 설정한 후, 표 12 값 중에서 기준점 0.375보다 큰 값을 이용하여 인과관계를 도식화하였고, 그림 3과 같은 인과관계도가 도출되었다. 도식화하는 과정 중에 결함들이 중심도(D+R)요인 8.75부터 9.25까지 집중되어 있어서, 용이한 식별을 위하여 x축을 점선 박스로 확대하여 도식화하였다.

Table 9.

Generalized cause & effect matrix(A)

Table 10.

Normalized cause & effect matrix(N)

Table 11.

Total cause & effect matrix(T)

Table 12.

Cause & effect analysis result of defects

Ⅳ. 결함 인과관계 분석

4.1 임베디드 소프트웨어 결함 인과관계 분석

도식화된 그림 3을 분석하면 원인도(D-R)요인이 양수 값이거나 순수하게 원인 결함이라면, 다른 결함에게 영향을 미치는 그룹으로 분류할 수 있다. 원인도(D-R)요인 값 중에 제일 큰 값의 결함은 다른 결함에게 가장 많은 영향을 미친다[33]. 본 논문에서는 플래쉬 메모리 및 저장장치(Flash Memory & File System) 결함, 예외처리(Exception Handling, D4), 내부 소프트웨어 인터페이스(Internal Software Interface, D5), 동적메모리 결함(Dynamic Memory, D11), 데이터 처리 및 공유메모리(Data & Shared Memory, D10), 함수결함(Incorrect Function, D2), 논리결함(Incorrect Logic, D1)들이 영향을 주는 원인 그룹으로 분석되었고, 그 중에 논리 결함, 함수결함, 플래쉬 메모리 및 저장장치, 예외처리 결함, 동적메모리 결함 순으로 영향 원인이 큰 것으로 나타났다.

Fig. 3.

The casual and effect diagram of embedded software defects

원인도(R-C)요인 값이 음수 값이거나 다른 결함에게 영향을 받기만 한다면, 영향을 받는 효과(Effect)그룹이라고 한다. 본 연구에서는 외부 인터페이스(External Interface, D6), 하드웨어 인터럽트(Hardware Interrupt, D8), 디바이스 드라이버(Device Driver, D7), 타이밍 결함(Timing Error, D9), 태스크 관리(Task Management, D3)결함이 효과그룹으로 분석되었고, 그중에 외부 인터페이스, 하드웨어 인터럽트, 디바이스 드라이버, 타이밍 결함, 태스크 관리 결함 순으로 영향을 많이 받는 것으로 분석되었다.

결함 간의 인과관계가 밝혀졌기 때문에, 핵심결함을 분석하면, 핵심 결함은 다른 결함으로부터 영향을 많이 받는 효과그룹에 많이 존재한다.

첫 번째로 제일 중요한 핵심 결함은 외부 인터페이스 결함으로 도출되었다. 외부 인터페이스는 네트워크, 시리얼 포트, 휴먼 인터페이스 등이 있다. 만약 휴먼 인터페이스에 결함이 있다면 사용자가 원하는 기능을 요청해도 다른 기능이 동작하여 문제가 발생할 수 있고, 외부 시스템에서 송신하는 명령을 잘못 수신하여, 잘못 동작하면 중대한 문제를 발생시킬 수 있으므로 제일 중요한 결함이라고 이해할 수 있다.

두 번째로 중요한 결함은 하드웨어 인터럽트로, 타이머, 0 으로 나누기, 오버플로우, 언더플로우 등의 하드웨어 인터럽트가 존재하며, 개발자가 인터럽트를 처리 루틴을 직접 작성해야 한다. 만약 인터럽트 처리에 결함이 발생하면 중대한 문제가 발생될 수 있으므로 중요한 결함이라고 이해할 수 있다.

세 번째로 중요한 결함은 디바이스 드라이버 결함이 도출되었다. 디바이스 드라이버는 응용 소프트웨어에서 하드웨어를 제어할 수 있도록 인터페이스를 제공하는 역할을 수행한다. 만약 디바이스 드라이버에 결함이 발생하면 임베디드 시스템이 어떻게 동작할지 예측할 수 없기 때문에 중요한 결함으로 도출된 것으로 이해할 수 있다.

네 번째로 중요한 결함은 시간 결함(Timing error)으로 도출되었다. 임베디드 시스템은 자동차 자율주행시스템, 항공분야의 항법시스템, 원자력 발전소 제어장치, 국방 분야의 미사일 제어 장치 등 인간의 생명과 직결될 수 있다. 만약 즉각적으로 반응해야 하는 기능에 대하여 시간이 초과된다면, 예측할 수 없는 결과를 초래될 수 있을 것이다. 그런 면에서 중요한 결함으로 도출되었다고 이해할 수 있다.

다섯 번째로 중요한 결함은 태스크 관리 결함으로 도출되었다. 태스크 관리 결함은 데드락, 경쟁조건 등으로 인하여 태스크들이 정상적으로 수행되지 않을 수 있으므로 중요한 결함요소로 도출되었다. 이와 같이 다섯 가지 결함이 가장 중요한 결함으로 도출되었고, 나머지 결함은 핵심 결함만큼 중요도가 미치지 못하는 것으로 파악되었다.

핵심 결함을 종합적으로 해석하면, 임베디드 시스템은 외부 시스템 및 환경에 영향을 받지 않고 견실하게 수행되어야 하며, 인터럽트는 정확하게 처리되어야 하며, 다양한 하드웨어 종류에 적합하게 동작해야 하고, 제 시간 내에 응답하도록 구현되어야 하며, 다양한 여러 태스크들이 착종되지 않고 자기 기능을 충실하게 수행할 수 있도록 제작하는 것이 가장 중요하다고 나타났다.

연구 결과의 신뢰성을 확인하기 위하여 임베디드 전문가 6인에게 임베디드 소프트웨어 결함 중에서 중요하다고 판단되는 결함에 대한 의견을 수집하였다. 표 13과 같이 전문가 중에는 논리결함이나, 예외처리, 데이터, 동적 메모리 결함도 중요하다고 의견을 준 경우도 있었으나, 중요 결함에 대한 전문가들의 공통된 의견은 하드웨어 인터럽트, 디바이스 드라이버, 외부 인터페이스, 타이밍, 태스크 관리 결함이 중요하다고 의견을 주었다. 이와 같이 전문가들이 중요하다고 생각하는 결함과 본 연구에서 도출한 중요 결함을 비교한 결과, 미미한 차이가 있을 뿐 전부 일치하는 것으로 확인되었다.

Table 13.

Opinion of key defects of embedded experts

Ⅴ. 결론 및 향후 과제

References

• S. M. Huh, and W. J. Kim, "A Method to Establish Severity Weight of Defect Factors for Application Software using ANP", Journal of KIISE, Vol. 42(No. 11), p1449-1460, Nov.), (2015. [https://doi.org/10.5626/JOK.2015.42.11.1349]
• IEEE, "IEEE Standard Classification for Software Anomalies", IEEE Std., p1044-1993, (1994).
• IBM, "Orthogonal Defect classification v5.2 for Software Design and Code", IBM, (2013).
• Huber, JT, "A comparison of IBM’s orthogonal defect classification to Hewlett Packard’s defect origins, types and modes", In: Proceedings of International Conference on Applications of Software Measurement, San Jose, CA, p1-17, (2000).
• Wikipidia, http://en.wikipedia.org/wiki/Software_bug [Accessed: May. 02. 2018].
• J. D. Hagar, "Software Test Attacks to Break Mobile and Embedded Devices", CRC press, (2013).
• M. Barr, "Five top causes of nasty embedded software bugs", Embedded systems design, Vol. 23(No. 3), p10-15, Apr.), (2010.
• M. Barr, "Five more top causes of nasty embedded software bugs", Embedded systems design, Vol. 23(No. 9), p9-12, Apr.), (2010.
• H. M. Choi, A. y. Sung, B. J. Choi, and J. W. Kim, "A Functionality - based Evaluation Model for Embedded Software", Journal of KIISE: Software and Applications, Vol. 32(No. 12), p1192-1204, Nov.), (2005.
• D. Jankowicz, "The Easy Guide to Repertory Grids", John wiley & sons, (2005).
• D. Sumrit, and P. Anuntavoranich, "Using DEMATEL method to analyze the causal relations on technological innovation capability evaluation factors in Thai technology-based firms", International Transaction Journal of Engineering, Management, & Applied Sciences & Technologies, Vol. 4(No. 2), p81-103, Jan.), (2013.
• M. Leszak, and D. E. Perry, "A Case Study in Root Cause Defect Analysis", Software Engineering, 2000. Proceedings of the 2000 International Conference, p428-437, June), (2000. [https://doi.org/10.1145/337180.337232]
• R. R. Lutz, "Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems", In Requirements Engineering Proceedings of IEEE International Symposium on, p126-133, Jan.), (1993.
• T. L. Bennett, and P. W. Wennberg, "Eliminating embedded software defects prior to integration test", Journal of Defence Software Engineering, Dec.), (2005.
• Nigel Jones, "A Taxonomy of Bug Types in Embedded Systems", Oct.), (2009.
• P. Rodriguez-Dapena, "Software Safety Verification in Critical Software Intensive Systems", Draft Phd thesis, Eindhoven Technical University, Jan.), (2002.
• Tammy Noergaard, "Embedded System Architecture", Elsevier, (2005).
• S. Ji, and X. Bao, "Research on Software Hazard Classification", Procedia Engineering, Vol. 80, p407-414, (2014). [https://doi.org/10.1016/j.proeng.2014.09.098]
• H. W. Jung, "Failure Mode based Test Methods for Embedded Software", Ajou University Graduate School of Engineering, Jun.), (2007.
• A. Sung, W. Srisa-an, G. Rothermel, and T. Yu, "Testing Inter-Layer and Inter-Task Interactions in RTES Applications", In Software Engineering Conference (APSEC), 17th Asia Pacific, p260-269, Jun.), (2010. [https://doi.org/10.1109/APSEC.2010.38]
• J. Duraes, and H. Madeira, "Emulation of Software Faults by Educated Mutations at Machine-Code Level", Proceedings of the Thirteenth IEEE InternationalSymposium on Software Reliability Engineering, ISSRE’02, p329-340, Nov.), (2002. [https://doi.org/10.1109/ISSRE.2002.1173283]
• H. J. Lee, "Statistical JTAG fault injection methodology for reliability verification of aerospace embedded systems", Department of Electronics and Information Engineering Korea Aerospace University, Feb.), (2012.
• H. J. Lee, J. H. Yoon, K. Y. Lee, D. W. Lee, and J. W. Na, "Reclassification of fault, error, and failure types for reliability verification of defense embedded systems", Institute of Control, Robotics and Systems, p925-932, July), (2012.
• H. J. Lee, and J. W. Park, "JTAG fault injection methodology for reliability verification of defense embedded systems", Journal of the Korea Academia-Industrial cooperation Society, Vol. 14(No. 10), p5123-5129, Aug.), (2013.
• J. Y. Seo, "Embedded Software Interface Test Based on the Status of System", Department of Computer Science and Engineering The Graduate School of EWHA Womans University, Jan.), (2009.
• Y. N. Choi, "Automated Debugging Cooperative Method for Dynamic Memory Defects in Embedded Software System Test", Department of Computer Science and Engineering The Graduate School of EWHA Womans University, Jan.), (2010.
• D. H. Jung, S. J. Ahn, and J. Y. Choi, "Programming Enhancements for Embedded Software Development-focus on MISRA-C", Journal of KIISE : cmputing practives and letters, March, Vol. 19(No. 3), p149-152, Jan.), (2013.
• J. Y. Seo, and B. J. Choi, "An Interface Test Tool Based on an Emulator for Improving Embedded Software Testing", Journal of KIISE : Computing Practices and Letters, Vol. 14(No. 6), p547-558, Aug.), (2008.
• A. Y. Sung, B. J. Choi, and S. K. Shin, "An interface test model for hardware-dependent software and embedded OS API of the embedded system", Computer Standards & Interfaces, Vol. 29(No. 4), p430-443, Sep.), (2006. [https://doi.org/10.1016/j.csi.2006.07.002]
• S. Y. Lee, J. S. Jang, K. H. Choi, S. K. Park, K. H. Jung, and M. H. Lee, "A Study of Verification for Embedded Software", Industrial Engineering & Management Systems, p669-676, (2004).
• A. Y. Sung, "Interface Based Embedded Software Test for Real-Time Operating System", Department of Computer Science and Engineering EWHA Womans University, July ), (2007.
• S. H. Lee, "Automated Method for Reliability Verification in Embedded Software System Exception Handling Test", Department of Computer Science and Engineering The Graduate School of Ewha Womans University, Jan.), (2010.
• M. G. ÖLÇER, "Developing a spreadsheet based decision support system using DEMATEL and ANP approaches, (Doctoral dissertation, DEÜ Fen Bilimleri Enstitüsü), Jun.), (2013.