중소기업융합학회논문지제 6 권제 1 호 pp. 7-15, 2016 ISSN 2234-4438 DOI : http://dx.doi.org/10.22156/cs4smb.2016.6.1.007 김순겸, 홍장의 * 충북대학교전자정보대학컴퓨터과학과 Application of Safety Analysis and Management in Software Development Process Soon-Kyeom Kim, Jang-Eui Hong * Department of Computer Science, Chungbuk National University 요약현대사회에서자동차, 철도, 항공우주, 원자력, 국방등의다양한분야에서대부분의장치들이소프트웨어를내장하고, 제어용소프트웨어시스템이탑재됨에따라소프트웨어의안전성에대한중요도가높아지고있다. 다양한산업분야에서소프트웨어가사용되면서소프트웨어에의한사고의위협도높아지기때문에소프트웨어오동작에의한안전성위협이큰이슈로떠오르게되었다. 소프트웨어의사고는사용자의오조작에의해서발생할수도있지만가장근본적으로는설계과정에서의안전성에대한검증이제대로이루어지지않아서발생하게된다. 따라서본논문에서는소프트웨어개발프로세스에서소프트웨어안전성분석및관리활동이어떻게이루어져야하는가를제시한다. 특별히프로토타입이나점진적개발프로세스에서의안전성분석및관리활동의적용방안에대하여제시한다. 키워드 : 소프트웨어안전성, 소프트웨어개발프로세스, 안전성분석, 안전성관리 Abstract As most devices in a wide range of automotive, aerospace, and missile have built-in software that controls the system behaviors, the safety of the software is growing in its importance. That is, the software safety has emerged as one of big issues because the threat of accidents caused by software malfunction is rising. Accident by software can be occurred from user mal-operation, but the fundamental reason of the accident comes from insufficient verification of the safety in software development process. Therefore, this paper presents how the software safety analysis and management activities should be done in the development process. In particular, we propose how to apply the safety analysis and management activities in the prototype or incremental development process. Key Words : Software Safety, Development Process, Safety Analysis, Safety Management 1. 서론 현대사회에서는자동차, 철도, 항공, 원자력, 국방 등의다양한분야에서소프트웨어가접목되어사용되고있다. 이러한소프트웨어들은우리생활에편의를위한기능을제공하지만, 생활에밀접하게관련이있 Received 2016-02-12 Revised 2016-03-03 Accepted 2016-03-04 Published 2016-03-31 본연구는기초연구지원사업 (NRF-2014R1A1A4A01005566) 과차세대정보통신개발사업 (NRF-2015M3C4A7030505) 의지원에의해수행되었음. * Corresponding author : Jang-Eui Hong (jehong@chungbuk.ac.kr) 7
중소기업융합학회논문지제 6 권제 1 호 는만큼소프트웨어의오류는크고작은사고를야기하는원인이될수있다. 자동차분야에서는 2014년도요타프리우스자동차리콜사례가있었다 [1]. 철도분야에서는 KTX의사고사례를들수있고, 항공우주분야에서는 Arian 5 Rocket 폭발과 2012년러시아화성탐사선의추락사고가있었다 [2-4]. 원자력분야에서가장대표적으로알려진 Therac -25 사고가있었다. 이러한사고들은모두소프트웨어의결함으로비롯되었다 [5]. 소프트웨어중심사회가되어가면서대부분의국가기반시설및대단위산업분야에서소프트웨어를이용한제어가이루어지고, 금융, 자동차, 항공, 전력, 국방, 의료, 교육등대부분분야에서소프트웨어의존도가높아짐에따라이의오류로인한사고의피해범위와규모가확대되고있다. 소프트웨어에의한사고를예방하기위한소프트웨어안전성에대한연구는소프트웨어개발단계에서매우중요한부분이다. 안전성이란사고나손실로부터자유로운상태라고정의할수있는데, 소프트웨어시스템의경우외부의잘못된입력으로부터시스템을안전하게지켜주고, 재난발생을막기위한통제를수행할수있는가에대한관심을말한다. 이와관련하여신뢰성과안전성은소프트웨어에있어서는매우유사한개념으로사용되었으나최근에는그개념이분리되는추세에있다. 신뢰성은특정한환경조건에서준비된기능이특정시간내에바르게수행될수있는지에대한가능성을말하는것이라면, 안전성은외부에서의잘못된입력으로부터재난이일어나지않도록할수있는조건과, 계획된기능이수행될것인지아닌지에대한가능성을의미한다 [6,7]. 소프트웨어에의한사고는조작미숙혹은외적인요인에의해서발생할수도있지만, 가장근본적인원인은소프트웨어개발단계에서의안전성에대한검증이제대로이루어지지않기때문에발생하게된다. 소프트웨어분석및설계단계에서안전성에대한연구는대부분안전성분석및평가, 또는소프트웨어아키텍처설계기법을통한안전성의확보를목표로수행하는것이일반적인추세이다. 가장많이알려진소프트웨어안전성분석기법인고장유형및영향분석 (Failure-Mode & Effect Analysis, FMEA) 와결함위험분석 (Fault Hazard Analysis, FHA), 결함트리분석 (Fault Tree Analysis, FTA)[8,9,10], 위험및운용분석 (Hazard and Operability analysis, HAZOP) 등이있다 [8-14]. 이러한다양한연구들이있지만, 소프트웨어개발프로세스에서이러한다양한기법들을어떻게활용할것인지에대한가이드라인은충분하지않다. ISO 26262 등과같은안전성관련표준들이소프트웨어개발에대한가이드라인을제공하고있지만, 구체적이지못하며대체적으로폭포수모델 (Waterfall Model) 과같은프로세스에서의적용을기준으로제시하고있다 [11,12]. 따라서본연구에서는먼저소프트웨어개발프로세스에서안전성을어떻게관리해야하는가를살펴보고, 이를기반으로점진적개발에서의안전성분석및관리방안을제시한다. 본논문의구성은다음과같다. 2장에서는배경및관련연구로써, 소프트웨어안전성과관련된사고사례, 소프트웨어안전성표준, 그리고안전성관련기존의연구들을살펴본다. 3장에서는소프트웨어시스템의안전성분석을위한다양한기법을정리하고, 4장에서는소프트웨어시스템개발단계별안전성관리활동에대하여정리하였다. 5장에서는점진적소프트웨어개발절차상에서의안전성분석및관리활동의적용방안을제시하고, 마지막으로 6장에서결론및향후연구내용을제시한다. 2. 배경및관련연구 2.1 안전성관련사고사례소프트웨어가다양한분야에서활용되고있는만큼여러분야에서의소프트웨어안전성관련사고사례가있다. 항공우주분야의대표적인사례는 Arian 5 Rocket 의폭발사고와최근에있었던러시아화성위성탐사선 포보스 -그룬트 호의추락사고가있다 [3,4]. Arian 5 로켓사고는 Arian 5호가 Ada로작성된 Arian 2의일부모듈을그대로재사용하며발생하게되었다. 문제가된모듈은 16비트정수값을처리할때는문제가없으나, 64비트부동소수값을처리할때오버플로우 (Overflow) 가발생하였고, 이를제대로처리하지못해사고가발생한것이다. 포보스-그룬트호의추락은프로그램상의문제로인하여탐사선컴퓨터 2 개채널이동시에재부팅되면서발생하게되었다. 8
자동차분야의사례로는최근도요타프리우스의리콜사고를들수있는데, 리콜원인은전력제어장치소프트웨어의결함으로주행중차량이갑자기멈출가능성이발견되었기때문이다 [1]. 원자력분야에서는대표적으로 Therac-25의사고사례를들수있는데, Therac-25는암환자용방사선치료기로서, 높은에너지방사광선을빠르게집중적으로조사해악성종양을파괴하는장비이다 [5]. 간호사와방사선사가환자에게맞는치료방식을설정하기위해기계를조작하는과정에서조작자가입력실수를유발했고, 이것이인터페이스에저장되었는데재입력이 8초이내에이루어지는바람에기계가오작동되었다. 6명의사망자가발생하였으며, 이사고는인터페이스설계부실과, 기계조작에대한방사선사의교육이제대로이루어지지않은데원인이있었다. 국방분야에서는패트리어트미사일사고가있는데이사고는소프트웨어버그에의해사우디아라비아의더란에서 28명의미국병사들이사망했던사건이다 [13]. 마지막으로철도분야의사고로는 KTX의정지사고등이있는데 KTX의사고는소프트웨어에의한사고비율이 60% 에이를정도로소프트웨어사고가큰비중을차지하고있다. 2.2 관련표준다양한산업분야에서소프트웨어안전성과관련된 표준들이제정되어있다. 각산업분야별표준은 Table 1과같고, Fig. 1은안전성표준들이다루고있는주요내용을자동차분야의기능안전성표준인 ISO 26262 를기준으로나타낸것이다 [11]. 안전성관련표준들을산업분야별로살펴보면항공분야의안전성평가에대한가이드라인이가장먼저제정되었고, 국방분야, 철도분야, 원자력분야가안전성에대한관심이먼저이루어진것을알수있다. 최근에는일반사용자를중심으로하는자동차및의료분야의안전성이중요시되고있는실정이다. 이중에서전기및전자장치의가장기본적인표준이며, 공통표준인 IEC 61508은산업에적용되는안전성규칙의국제표준이다 [14]. 이것의이름은전기 / 전자 / 프로그램가능한전자안전관리시스템의기능안전으로명명되었다. IEC 61508에서는안전관련시스템의정확한기능수행, 다른안전시스템과외부위험감소장치에의존하는제어장비, 그리고제어장비를제어하는시스템의부분적또는전반적인안전으로기능안전을정의하고있다. ISO 26262 또는자동차기능안전성국제표준은자동차에탑재되는 E/E (Electric & Electronic) 시스템의오류로인한사고방지를위해 ISO에서제정한자동차기능안전국제규격이다 [11]. ISO 26262는프로세스모델과함께요구되는활동, 유무형의증거물, 그 Table 1. International Standards for Safety by Industrial Areas Domains Standards Titles of Standards (Publication Year) Common IEC 61508 Standard for Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES) (2010) Automotive ISO 26262 Road vehicles Functional safety (2011) Railway IEC 62278 Railway applications - Specification and demonstration of reliability, maintainability and safety (RAMS) (2002) IEC 62279 Railway applications - Communications, signalling and processing systems - Software for railway control and protection systems (2002) Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne ARP 4761 Airborne Systems and Equipment (1996) DO-178C Software Considerations in Airborne Systems and Equipment Certification (2012) IEC 60880 Nuclear power plants - Instrumentation and control systems important to safety - Software aspects for computer-based systems performing category A functions (2006) Nuclear power plants - Instrumentation and control important for safety - Software aspects IEC 62138 Nuclear for computer-based systems performing category B or C functions (2004) Power IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating IEEE7-4.3.2 Stations (2010) IEC 61513 Nuclear power plants - Instrumentation and control important to safety - General requirements for systems (2011) Defense MIL-STD-498 Software Development And Documentation (1994) MIL-STD-882E Department of Defense Standard Practice for System Safety (2012) IEC 60601 Medical electrical equipment (2014) Medical IEC 62304 Medical device software - Software life cyce processes (2006) ISO 13606 Health informatics - Electronic health record communication (2008) 9
중소기업융합학회논문지제 6 권제 1 호 리고개발과생산에사용되는안전성지원방법을정의한다. 기능안전은각제품개발단계에통합되어고려되는데, 그범위는명세부터시작하여설계, 구현, 통합, 검증, 인증, 그리고생산및인도단계에이른다. ISO 26262 표준은기능안전표준 IEC 61508을자동차전기 / 전자시스템에적용시킨것이다. ISO 26262는모든자동차용전기 / 전자안전관련시스템의제품수명전주기에걸쳐적용가능한자동차용장비의기능안전을정의한다. 필수소프트웨어의안전성을향상시킬수있는기법이다. Kwon 의연구에서는리소스맵 (Resource map) 과 Fault Prevention Tree를사용하여사고예방동작간의충돌가능성을분석하고, 이를해결하기위한방안을제안하였다 [18]. 이는 Safety Critical 시스템에서피해를예방하기위한서브시스템들을더욱견고하게설계할수있고, 시스템의안전성이향상될수있는방법이다. 3. Software Safety 분석기법 Fig. 1. Main contexts of ISO 26262 2.3 관련연구소프트웨어의안전성에관한연구는다양하게이루어지고있다. Kim이수행한안전성평가에관한연구에서는안전필수시스템에서소프트웨어안전성을보다엄격하게평가할수있는방안을제시하였다 [15]. 상호보완적인관계에있는결함분석기법을이용하여안전성을분석하는방법으로 FTA와 FMEA 분석기법을결합한하이브리드방법을제안하였다. Hwang 의연구에서는기존의자동화된소프트웨어테스트도구를확장하는방식을통한안전성점검방안을제시하였으며, 소프트웨어개발주기에서파생된안전성활동의결과들을입력으로표준에서요구하는평가항목들을동적으로테스트하는평가도구를제안하였다 [16]. 소프트웨어설계단계에서수행한안전성활동결과를테스트도구의입력으로사용하여지속적으로안전성을검증하도록기능을확장하였다. Park의연구에서는안전필수소프트웨어개발시구현단계또는유지보수단계에서적용할수있는 Introduce De-Bouncing 기법을제안했다 [17]. 해당기법은스위치바운싱현상을소프트웨어를통해해결할수있고더불어저렴한비용으로기존에완성된안전 3.1 모델검증기법 (Model Checking) 모델검증기법은정형기법의한종류로, 정형언어로작성된모델이검증하고자하는특성을만족하는지여부를입증하는방법이다 [19]. 모델검증기법은모델명세와입증할검증특성을입력받아모델명세가기능적특성및안전성요구사항을만족하는지논리적으로증명한다. 만약입력받은모델이검증특성을만족하지못한다면어떠한상황에서모델이해당검증특성을만족하지못하는지반례를출력한다. 시스템개발자는이를토대로모델을분석하고보완할수있다. 3.2 결함트리분석 (FTA) 안전필수시스템을위한 FTA는위험요소를확인하는것이아니라위험요소들의원인을분석하기위한수단이다 [18]. FTA는위험이많은사건을구성할수있는개별적인오류들의결합을설명하기위하여부울논리를사용한다. 트리의각단계는그단계의위쪽에나타난문제의원인이될수있는필요충분한사건들을식별하여트리를구성하는과정으로결함을목록화한다. 3.3 결함위험분석 (FHA) 결함위험분석은위험에대한정성적분석으로만사용하거나, 필요시정량적인분석방법으로확장시킬수있는연역적방법이다 [20]. FHA는서브시스템이갖는세부위험경향, 위험의원인, 그리고서브시스템의운영에대한위험의영향을결정하기위해사용한다. FHA는반드시치명적인모드의 (Catastrophic Mode) 위험과허용범위밖의 (Out-of-Tolerance Mode) 위험 10
에대한양쪽모두의고려가필요하다. 3.4 고장유형및영향분석 (FMEA) 고장유형및영향분석기법은신뢰성 / 안전성공학자들이장비의신뢰성을예측하기위해서개발되어졌으며, 부품그자체에고장발생원인이삽입되는것을피하기위한목적으로사용하는기법이다 [21]. FMEA는설계, 공정, 품질보증등각부분에산재한안전성문제점을정량적으로관리하기위한기법이며, 점차복잡해지는안전성관련문제를제품개발초기단계에서사전제거하기위한목적으로활용된다. FMEA의단계는 (1) 모든컴포넌트를리스트형태로정의를하고, (2) 각각의고장모드가영향을미칠모든컴포넌트, 시스템을정의하고, (3) 각각의고장모드의가능성과함께심각성을계산하는것이다 [22]. FMEA의결과물은하나의시스템기능별로각요소가발생시킬수있는잠재적실패들과그실패로인해생기는영향들을도표로기록하고있으며, 영향도, 확률, 발생빈도, 위험도우선순위등으로평가를한결과물들이첨가되어있다. 벗어나사고가발생하는것을가정하고, 설계부터예상운용에서일어날수있는모든가능한일탈상황과그와관련된위험요소를찾으려고하는것이다 [22,23]. 분석과정에서시스템에대한효율적인검토를수행하기위하여시스템설계의일정구간을분할하여단계적으로장비의오작동이나운전조작실수등과같은위험및운영성을평가한다. 3.6 요약소프트웨어개발에사용될수있는안전성분석기법은지속적으로개발되고, 개선되고있기때문에그종류와수가다양하다. 위에서설명한다섯가지기법은소프트웨어개발에서의안전성검증에공통적으로많이사용되는기법들을대표적으로나타낸것이다. Table 2에서는이외에도그동안연구되어왔던다양한안전성분석기법들이위험분석을어느정도지원하는가, 소프트웨어개발의어느단계에적용할수있는가, 위험분석의접근방법은연역적인지, 귀납적인지등에따라정리한것이다. 정리된것과같이다양한안전성분석기법이존재하며, 각개발단계에맞는합당한분석기법을선택하여적용하는것이중요하다. 3.5 위험및운용분석 (HAZOP) HAZOP 은설계또는운용상에서의도한기능에서 Table 2. Applying strategies of safety analysis techniques Technique Name Hazard Analysis Applying Phase 1) Results 2) Methods Cause consequence analysis Full supported PD~DD Q1/Q2 Deductive Common cause failure analysis Partially supported PD~DD Q1 Deductive Event tree analysis Partially supported PD~DD Q1/Q2 Deductive Failure mode and effects analysis Partially supported PD~DD Q1 Inductive Fault hazard analysis Full supported PD~DD Q1 Inductive Fault tree analysis Partially supported PD~DD Q1/Q2 Deductive Functional failure mode & effect analysis Partially supported CD Q1 Deductive Hazard and operability analysis Full supported PD~DD Q1 Inductive Markov analysis Partially supported PD~DD Q1/Q2 Deductive Petri net analysis Partially supported PD~DD Q1/Q2 Deductive Preliminary hazard analysis Full supported CD~PD Q1 Induc./Deduc. Preliminary hazard list analysis Full supported CD~PD Q1 Inductive Safety requirement/criteria analysis Partially supported PD~DD Q1/Q2 N/A Sneak circuit analysis Partially supported DD Q1 Deductive Software safety assessment Full supported CD~PD Q1 N/A Subsystem hazard analysis Full supported DD Q1 Induc./Deduc. System hazard analysis Full supported PD~DD~T Q1 Induc./Deduc. Systems theoretic process analysis Not Supported CD~PD Q1 Deductive Remark 1) CD: Conceptual Design, PD: Preliminary Design, DD: Detailed Design, T : Testing Remark 2) Q1: Qualitative, Q2: Quantitative, N/A: Not Applicable 11
중소기업융합학회논문지제 6 권제 1 호 4. 소프트웨어시스템개발단계별안전성관리활동 ISO 26262를기준으로살펴볼때, 안전성을고려하는소프트웨어시스템의개발단계는 Fig. 2에서나타난것과같이개념정립단계 (Concept Phase), 제품개발단계 (Product Development Phase), 그리고운영유지단계 (Operation and Maintenance Phase) 로구분한다. 개념정립단계에서는안전성에대한요구사항및이의분석활동이, 그리고개발단계에서는안전성을고려하는하드웨어및소프트웨어에대한개발활동이, 마지막으로운영단계에서는안전한소프트웨어시스템의운영을모니터링하고그결과에따른피드백이이루어진다. 각단계별로이루어지는안전성분석및관리프로세스는다음과같다. Fig. 2. Analysis and management Process for software safety 4.1 개념화단계개념정립단계에서는안전성을요구하는시스템에대한정의및기능요구사항에대한형상정의를시작으로, 요구사항을기반으로하는위협분석및안전성목표 (Safety Goals) 를식별하는활동등으로이루어진다. 위협분석은운영환경조건, 시스템과사용자의상호작용등을고려하는모든가능한시나리오에대하여분석되어야하며, 위험한상황이발생했을때, 이러한상황이사용자또는정의된시스템에서제어가능한상태인지, 얼마나심각한위험인지, 얼마나빈번하게 발생하는지등을고려하여분석한다. 위협분석의결과를기반으로시스템이제공해야하는기본적인안전성요구사항을확정하게된다. 안전성요구사항은발생가능한모든위험으로부터사람의생명을보호하고인재물적피해를최소화하는방향으로설정된다. 설정된요구사항은기능안전요구사항으로확정하여제품개발단계로전달된다. 4.2 제품개발단계제품개발단계에서의활동은크게 5가지의기본활동으로구성된다 ; (1) 시스템수준에서의제품설계및아키텍처설계, (2) 하드웨어수준의제품개발, (3) 소프트웨어수준의제품개발, (4) 개발된하드웨어와소프트웨어의통합및테스트, 그리고 (5) 기능안전성에대한검증및평가활동이다. 시스템수준에서의설계활동은상위수준에서시스템의형상을기반으로시스템아키텍처를개발하는활동이다. 이때시스템아키텍처는선행적으로명세된기술적안전성요구사항을고려하여개발되어야한다. 시스템수준에서정의된기술적안전요구사항은하드웨어및소프트웨어개발활동으로전달된다. 하드웨어수준의제품개발활동은전달된안전요구사항을하드웨어측면에서명세하고, 이를기준으로제품개발활동을진행한다. 이러한활동은일반적인하드웨어개발절차를준수하되, 안전성목표를준수하고있는지를점검하고확인하는활동을반복적으로수행한다. 소프트웨어수준의제품개발활동은먼저시스템수준에서의안전성요구사항을기반으로소프트웨어안전요구사항을명세한다. 즉시스템수준의요구사항을소프트웨어안전요구사항으로구체화하면서소프트웨어개발과정에서고려되어야하는요구사항으로분리해내는활동을수행한다. 이러한요구사항이정의되면, 전체적인소프트웨어시스템에대한아키텍처설계가진행된다. 이러한아키텍처는안전성을고려하는소프트웨어컴포넌트가반드시포함되도록개발되어야한다. 아키텍처를이루는각각의소프트웨어모듈은상세설계과정을거쳐구현되며, 단위테스트과정을거쳐통합된다. 그리고마지막으로통합된소프트웨어시스템에대하여안전요구사항이만족되는지를점검한다. Fig. 3은시스템수준의요구사항에서소프트웨어요 12
구사항의검증에대한개념적흐름을나타낸다. (Incremental Approach) 이안전소프트웨어개발에적용될수있다. 반복적개발과점진적개발의개념적차이는 Fig. 4에서나타난것과같이시스템의개발하는대상모듈을분리하여개발하는가아니면추상화수준에따라개발을진행할것인가에따라다르게나타난다. Fig. 3. Application of SW safety requirements 4.3 제품운영단계제품이생산되어사용자에게이관되면, 소프트웨어가탑재된시스템이실제환경에서운영되게된다. 그러나이러한안전성분석및관리활동들이개념화단계및개발단계에서심도있게적용되었다고하더라도, 앞서 2장에서살펴본것과같이실제운영환경에서많은사고가발생할수있다. 따라서운영단계에서도시스템의동작과정에서기능안전요구사항이충분히만족되는지를모니터링해야한다. 모니터링결과들은시스템내부에존재하는로그형태로기록되어야하며, 예상하지못했던운영조건에서사고가발생하면, 로그를기반으로어떠한기능적오동작이있는지를분석하는과정을수행한다. 이러한분석과정을거쳐 Fig. 2에나타난안전성관리수명주기의해당단계로이동하여새로운안전성요구사항을포함하는개선활동이이루어진다. Fig. 4. Incremental and Iterative development approach Fig. 4에서와같이점진적개발방식에의한안전소프트웨어개발에서는도출된소프트웨어안전성요구사항이각분할된노듈에할당되어개발된다. 다만각모듈이개발될때반드시고려되어야하는사항은각모듈이갖는기능적요구사항이이외에두개의모듈간에존재할수있는상호작용에대한모듈이임의로고려되어야한다는것이다. 즉 Fig. 5에서와같이두개의모듈사이에존재하는안전성관련요구사항이정의되고검증되어야한다. Fig. 5. Safety consideration in incremental approach 5. 점진적소프트웨어프로세스에서의안전성관리활동소프트웨어개발은다양한프로세스에의해개발될수있다. 기본적인폭포수모델을근간으로하여반복적개발방식 (Iterative Approach) 과점진적개발방식 반복적개발접근방법에서는시스템에부여되는안전성요구사항들이계층적구조를가지고설계되어야한다. 일반적인결함트리분석에서처럼상위수준에서의결함이하위수준에서의결함으로구성될수있다는기본개념을적용하는것이다. 하위수준에서의결함이상위수준의결함을유발하기위해 AND 조건 13
중소기업융합학회논문지제 6 권제 1 호 으로연결될것인가 OR 조건으로연결될것인가를고려하여안전성요구사항을할당하고검증한다. 이와같은접근방법에의해안전소프트에어의개발프로세스가점진적방식을적용하는가, 아니면점진적개발방식을적용하는가를적용하는가에따라안전요구사항의할당및적용에다소차이가있을수있다. 기본적으로소프트웨어개발과정에서사용될수있는나선형모델이나, 애자일 (Agile) 방법에서도제시한접근방법을통해안전요구사항을충족시키는소프트웨어개발이가능할수있다. 이에대한적용방안을고찰하는것이다. ACKNOWLEDGEMENTS This research was supported by Next-Generation Information Computing Development Program(NRF- 2014M3C4A7030505), and also partially supported by Basic Research Support Program(NRF-2014R1A1A4A 01005566) through the NRF of Korea. 6. 결론및향후연구내용소프트웨어안전성에대한분석은안전필수시스템의개발에서반드시수행되어야하는활동중하나이다. 산업분야별별도의안전성관련표준이정의되어있고, 이에따른필수안전소프트웨어개발이가이드되고있지만, 대부분의시스템은소프트웨어의동작에따라작동되기때문에시스템에내장되는소프트웨어의동작및제어를어떻게안전하게수행해야할것인가가안전필수시스템개발에서의가장핵심적인요소라고볼수있다. 따라서소프트웨어의개념화단계부터개발단계및운영단계에서안전성은명확하고일관성있게분석및관리되어야한다. 본논문에서는소프트웨어개발프로세스단계에서어떠한안전성관련활동등이있는가를정리하였고, 이를통해안전소프트웨어개발활동이어떻게이루어지는가를프로세스관점에서조명하였다. 이를위해서는먼저정확한기능요구사항으로부터안전성목표를정의하고, 이에따른안전성요구사항을도출하는것이중요하다. 이러한안전요구사항들이시스템의설계활동에서반영될수있도록고려되어야함은물론, 시스템의개발과정에서반드시기능안전성에대한검증이수행되어야한다. 또한본논문에서는점진적인개발프로세스를기반으로안전필수소프트웨어가개발되는경우, 어떠한프로세스관점에서의고려가있는지도제시하였다. 이들은안전소프트웨어를개발하는조직에서개발프로세스를정립하기위한기반으로활용될수있을것이다. 향후의연구로써는 3 장에서제시한다양한안전성분석기법이소프트웨어의특성에따라어떻게적용될수있는가를분류하고, REFERENCES [1] Korea YeonHap News, Toyota Prius Recall Software Faluts, 2014. [2] MK News, KTX Stop Again, http://news.mk.co.kr/, 2011. 2. [3] J. L. LIONS, Ariane 5 Flight 501 Failure, Report by the Inquiry Board, http://www.esa.int/for_media/press_releases /Ariane_501_-_Presentation_of_Inquiry_Board_ report, 1996. 7. [4] A. G. Stephenson, L. S. Lapiana, D. R. Mulville, P. J. Rutledge, F. H. Bauer, D. Folta, G. A. Dukeman, R. Sackheim, P. Norvig, Mars Climate Orbiter Mishap Investigation Board Phase I Report, 1999. [5] Nancy Leveson, Software: System Safety and Computers, Addison-Wesley, 1995. [6] K. S. Kim and H. C. Kim, Comparative Study for Software Reliability Model Based on Finite and Infinite Failure Property using Rayleigh Distribution, Journal of Digital Convergence, Vol. 12, No. 12, pp. 277-284, Dec. 2014. [7] M. H. Kim and Man-Gon Park, A Study on the Software Fault Modes and Effect Analysis for Software Safety Evaluation," Journal of Korea Multimedia Society, Vol. 15, NO.1, pp. 115-130, Jan. 2012. [8] C. H. Han, Y. S. Lee, J. Ahn and W. S. Jo, "A study on the Correlation Hazard Analysis for Signaling System Safety," Journal of the Korean Society for Railway, pp. 634-641, 2007. [9] E. S. Kim, S. H. Yoon and J. Yoo, "A Survey on Safety Analysis Techniques for Safety- 14
Critical Systems," Journal of IT Conver gence Society for SMB, Vol. 2, No. 1, pp. 11-18, Jun. 2012. [10] C. A. Ericson, Fault tree Analysis-A History, Proceedings of the 17th International System Safety conference, pp. 1-9, 1999. [11] ISO Standards, ISO 26262 Road vehicles- Functional safety, ISO, 2011. [12] I. Sommerville, Software Engineering 8th Edition, Addison-Wesley, 2007. [13] United States General Accounting Office, GAO Report IMTEC-92-26, 1992. 2. [14] IEC Standards, IEC 61508 - Standard for Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems, International Electrotechnical Commission, 2010. [15] M. H. Kim and M. G. Park, "A Study on the Software Fault Modes and Effect Analysis for Software Safety Evaluation," Journal of Korea Multimedia Society, Vol. 15, No. 1, pp. 115-130, Jan. 2012. [16] J. G. Hwang, H. J. Jo and H. S. Kim, "Design of Train Control Software Safety Evaluation Tool," Journal of the Korean Society for Railway, Vol. 11, No. 2, pp.139-144, Apr. 2008. [17] J. J. Park and J. E. Hong, "An Approach to improve software safety by Code refactoring," Proceedings on Korea Computer Congress, pp.532-534, 2013. [18] J. J. Kwon, D. W. Kim, J. J. Park and J. E. Hong, "Collision Analysis of Safety Devices to Prevent Hazards in Safety Critical Systems", IEEE Software Security and Reliability, pp.245-254, 2014. [19] E. M. Clarke, O. Grumberg and D. Peled, Model checking, MIT press, 1999. [20] P. J. Wilkinson, Functional Hazard Analysis for Highly Integrated Aerospace System, Certification of Ground/Air System Seminar, 1998. [21] H. H. Kim and N. H. Lee, "The Case Study on Software FMEA for the Efficient Improvement of Functional Safety," Transactions of The KSAE, Vol. 2012, No. 11, pp.1303-1308, Nov. 2012. [22] I. B. Pirie, "Software? How do we know it is safe?", IEEE Conference on ASME, pp.122-129, 1999. [23] K. B. Sung and M. G. Park, "Safety Activities on The Software Life-Cycle," Journal of Korea Multimedia Society, pp.432-437, 1998. 저자소개김순겸 (Soon-Kyeom Kim) [ 학생회원 ] 2015년 8월 : 충북대학교컴퓨터공학과 ( 전산학학사 ) 2015년 9월 현재 : 충북대학교컴퓨터과학과석사과정 < 관심분야 > : 모델기반소프트웨어공학, 소프트웨어안전성, 소프트웨어품질홍장의 (Jang-Eui Hong) [ 정회원 ] 2001년 2월 : KAIST 전산학과 ( 전산학박사 ) 2002년 10월 : 국방과학연구소선임연구원 2004년 8월 : 솔루션링크기술연구소장 2004년 9월 현재 : 충북대학교소프트웨어학과교수 < 관심분야 > : 소프트웨어공학, IT 융합, 소프트웨어품질, 소프트웨어안전성, 저전력소프트웨어개발 15