소프트웨어공학 포털 블로그

2017년 4월 13일 목요일

SW 영향평가 제도

SW분야에서 공공과 민간의 역할 정립을 위해 공공정보화 사업의 기획단계부터 민간시장에 미치는 부정적 영향을 평가.

정부가 민간시장을 위축시키면 안 되며 민간시장에 미치는 영향을 사전 평가하는 등 공공정보화 사업 추진절체 개선(SW중심사회 실현전략 보고회, ’14.7월)

안전성 관리를 위한 국제 규격 IEC61508 은 수명주기 단계별 요구사항을 제시하고 있다. 수명주기 별 요구사항은 규격을 적용하는 시스템의 환경 및 범위 별 차별화되지 않고 모두 적용할 수 있도록 보편화되어 있으므로 요구사항의 만족을 입증하기 위한 문서화 및 입증자료 작성에 대한 구체적인 요구사항을 요구하지 않는다. 국제 표준을 적용한 국내외 인증기관들이 제공하는 입증자료인 위험분석 기법이나 위험원 목록의 양식이 다양한 이유도 이러한 요구사항의 보편성 때문이다.

안전성 관리는 안전관련 시스템 또는 소프트웨어 안전수명주기의 하나 이상의 단계에 대해 책임이 있는 사람들이 수행해야 할 기능안전성 관리 책임을 규정하는 것으로, 안전관련 활동 또는 안전수명주기에 대한 책임자가 해야 할 일은 다음과 같다.

시스템 및 수명주기 단계별 안전관련 활동 수행자의 역할 할당/조정
이들 단계와 타 조직/시스템 간 인터페이스
기능안전성 달성 정책, 전략, 평가 수단, 소통 수단
감지되는 모든 위험한 사건 분석, 권고사항의 반복 발생 가능성 최소화
기능안전성 평가 실행/조정(의사소통, 계획 및 문서화, 판단, 권고 등)
기능안전성이 이 표준의 목적 및 요구사항에 따라 달성 및 입증되고 있는지를 확인

또한 다음으로부터 발생하는 것들을 포함하여 안전관련 시스템에 관하여 즉시 대응 및 권고사항의 만족스러운 해결을 확보할 수 있는 절차를 개발해야 한다.

위험원 및 위험성 분석, 기능안전성 평가
각 수명주기의 단계별 산출물 검증 활동
전체 안전 검증 계획 및 검증 활동
위험관련 사건의 보고 및 분석
기능안전성 심사 빈도, 심사자들의 독립성 수준, 필요한 문서화와 후속 활동
위험원과 위험 사건, 안전 기능 및 안전관련 시스템에 대해 정확한 정보를 유지하기 위한 절차를 개발

안전성 관리를 위해 사고의 원인이 되는 위험원(Hazard)의 크기를 상대적으로 정량화한 위험성(Risk)가 허용할 수 있는 수준으로 제어된 상태를 의미하므로 안전성 관리를 위해서는 반드시 사고에 대한 정의가 먼저 수행되어야 한다. 이를 위해 대상 시스템의 정의와 안전성 관리 범위를 선정한다.

이어 위험원 식별, 위험성 계산, 위험성 결정을 수행하고 해당 허용 또는 수용 가능 여부에 따라 적정한 안전 수준을 확보하기 위한 안전기능을 추가하는 과정을 되풀이하여 가능한 안전 기능을 할당하고 이를 요구사항에 반영하여 개발 수명주기에 따라 관리한다.

2017년 4월 12일 수요일

정보공개제도란?

정의

"정보공개제도"란 국가기관 지방자치단체등 공공기관이 업무 수행 중 생산하여 보유ㆍ
관리하는 정보를 국민에게 공개함으로써, 국민의 알 권리를 보장하고 더 많은 정보를
바탕으로 국정운영에 대한 참여를 유도하기 위한 제도입니다.

정보공개법의 제정ㆍ시행

정보공개법의 개정(1998.1.1 시행)
국민의 알 권리를 확대하고 국정운영의 투명성을 높이기 위해
지난 '96년 <공공기관의 정보공개에 관한 법률> 을 제정ㆍ공포하고, ’98년1월1일부터 시행

공개형태

청구공개
공공기관이 직무상 작성 또는 취득하여 관리하고 있는 정보를 청구인의 청구에 의하여 공개하는 제도
(예)공문서의 열람, 복사청구 등
정보공개
정보를 보유한 공공기관이 자발적으로 또는 법령상 의무적으로 정보를 제공하는 제도
(예)인터넷을 통한 정보제공, 간행물의 배포 등

IEC62304 : 의료분야 국제 표준

의료기기 기능 안전성 확보를 위해 국제표준이 제정되어 각 나라에서 사용하고 있다. IEC60601 에서는 의료기기에 대한 안전 요구사항을 도출해 안전성을 분석하고 있으며, IEC62304 에서는 의료기기의 개발 및 유지보수의 개발 생명주기를 정의하고 각 단계별로 수행해야 하는 활동과 지표 및 산출물을 정의하고 있다.

ISO14971 은 의료기기 개발 시 필요한 위험분석 방법을 규정하고 있으며 소프트웨어 개발 단계에 이를 적용하고 있다.

어떤 종류의 소프트웨어도 안전성을 100% 보장할 방법은 없다. 의료기기 소프트웨어의 안전성을 향상시키는 주요 원칙 세 가지는 위험관리, 품질관리, 소프트웨어 엔지니어링이다.

안전한 의료기기 소프트웨어를 개발하고 유지보수하려면 적절한 소프트웨어 엔지니어링 방법 및 기술에 대한 전체적인 체제로서 품질관리시스템의 일부로 위험관리를 확립해야 한다.

이러한 세 가지 개념을 조합하면 의료기기 제조업체가 잘 구성되고 일관성 있게 반복 정밀도가 높은 의사결정 프로세스를 사용해 의료기기 소프트웨어의 안전성을 향상시킬 수 있다.

의료기기에 포함되는 소프트웨어 및 자동화 공정 소프트웨어의 안전성을 확보하기 위해선 위험관리와 소프트웨어 검증(Software Validation) 활동을 통해 확인 검증할 수 있다. 소프트웨어 기능 안전성 평가모델의 수행절차는 그림과 같다.

그림. IEC62304 기반 기능안전성 평가모델

IEC62304 는 안전기능 요구사항을 도출하는 과정이 포함되어 있지는 않으나, 소프트웨어의 위험등급을 나누고, 위험등급에 따라 개발프로세스의 세부적인 사항들을 바꾸는 방법으로 소프트웨어의 안전성을 확보하고자 하였다.

IEC62304 는 필요한 소프트웨어의 위험등급을 구분하고 이에 따른 소프트웨어 개발 프로세스를 정의했다는 측면에서 소프트웨어의 안전성을 확보하는 표준으로 참고할 만 하지만 적극적으로 안전기능 요구사항을 도출하고 이를 구현하기 위한 구체적인 방법을 제시하는 데에는 한계가 있다.

DO-178C : 항공분야 국제 표준

DO-178C(Software considerations in airbone systems and equipment certification: 항공 시스템 및 장비 인증의 소프트웨어 고려사항)는 1992 년에 제정된 표준으로 항공분야에서 소프트웨어 기능안전성 표준으로 널리 알려진 표준이다. 그러나 이 표준 역시 엄밀하게는 기능 안전성이라는 개념을 가지고 있지는 않다.

그림. DO-178C requires a documented connection

DO-178C 는 시스템을 위험등급에 따라 5 가지로 구분하여 개발하도록 정의하고 있다. 레벨 A 부터 레벨 D 까지는 소프트웨어의 오작동이 발생했을 때, 유발할 수 있는 장애의 등급을 나누어 소프트웨어 등급을 정하고 있는데, 특히, 레벨 E 는 항공기의 운항이나 파일럿의 임무에 영향을 미치지 않는 소프트웨어로 본 표준의 대상이 아님을 명시하고 있다.

DO-178C 는 장애(failure condition)에 대한 등급을 정의하고 있다. ‘Catastrophic’ 등급은 항공기 자체가 추락할 수 있는 장애, ‘Hazardous/Servere-Major’ 등급은 항공기의 기능이나 항공승무원의 임무에 심각한 피해를 주거나 탑승자 일부에게 생명을 위협하는 부상을 입힐 수 있는 장애, ‘Major’등급은 항공기의 기능이나 항공승무원의 임무에 주요한 피해를 주거나 탑승자에게 부상을 입힐 수 있는 장애, ‘Minor’등급은 항공기나 승무원에게 그 자신의 능력범위 안에서 해결할 수 있을 정도의 피해를 주는 장애를 말한다.

DO-178C 는 소프트웨어 테스팅과 관련하여 커버리지(Coverage)라는 정량화된 조건을 명시하고 있다. 이는 소프트웨어 테스팅의 완숙도를 정량적으로 측정하는 지표로써 이후 다른 표준에서도 사용하도록 영향을 주었다고 할 수 있다. DO178C 에서 제시하는 커버리지는 두 가지 종류가 있는데, 하나는 요구사항 커버리지(Requirement Coverage)이며, 나머지는 구조적 커버리지(Structural Coverage)이다.

2017년 4월 11일 화요일

소프트웨어 안전성 분석(1)

산업 내에서 직접적인 소프트웨어 활용이 많아지면서 소프트웨어의 안전성에 대한 고민이 다른 측면으로 다시 시작되었다. 소프트웨어가 오류없이 동작하는데 초점이 맞춰진 예전에는 소프트웨어 테스팅이나 보안 중심으로 안전성을 확인했지만 지금은 소프트웨어가 산업 자체에 영향을 주는 경우가 많아 이 외에도 다양한 관점으로 안전성을 살펴볼 필요가 생겼다. 2회에 걸쳐 소프트웨어 안전성 분석에 대해 알아보고자 하며 이번 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴보도록 한다.

소프트웨어 관점의 소프트웨어 안전성 분석

소프트웨어가 사용되면서 사용자들에게 가장 큰 고민은 소프트웨어 오류였다. 소프트웨어를 개발하면서 나타나는 오류는 사용자뿐만 아니라 개발을 완료한 개발자 입장에서도 많은 시간과 노력을 들여야 하는 경우가 많았다. 또한 소프트웨어를 사용하는 범위가 산업의 기반 시설들을 다루는 경우보다는 대체로 오퍼레이션과 관련된 것들이 많아 소프트웨어의 안전성이 좋지 않아도 산업 자체가 동작하는데 큰 무리는 없었다. 그래도 소프트웨어의 안전성을 높이기 위해 글로벌 기업을 중심으로 많은 예산과 인력을 투입하였고 다양한 소프트웨어 분석 도구와 기술을 개발하여 대처하였다. 개발 과정에서부터 보안 안전성을 고려하여 개발하는 시큐어 소프트웨어 개발 방법론(Secure Software Development Methodology)도 소프트웨어 안전성이나 보안 위협을 고려한 방법이라고 할 수 있다.

과거에 많이 사용된 소프트웨어 안전성 분석 방법은 크게 화이트박스 테스팅(White box Testing)과 블랙박스 테스팅(Black box Testing)으로 볼 수 있다. 화이트박스 테스팅은 분석 대상이 되는 소프트웨어의 소스코드를 대상으로 취약성이 발생할 수 있는 패턴을 분석하거나 버퍼 오버플로우와 포맷 스트링 취약점 등을 점검하여 소프트웨어가 적절하게 데이터를 처리하는지 점검하는 방식이다. 블랙박스 테스팅은 소프트웨어에 데이터를 입력하고 소프트웨어의 동작을 모니터링하면서 안전성을 점검한다. 블랙박스 테스팅은 소스코드가 반드시 필요하지는 않고 화이트박스 테스팅이 발견하지 못하는 예외적인 상황을 유발시켜 다양한 형태의 안전성 분석을 할 수 있지만 시간과 비용이 많이 드는 것이 단점이기 때문에 효율적인 테스팅을 위해서 자동화된 안전성 분석 도구가 이용되는 경우가 많다(그림1).

<그림1> 블랙박스 테스트와 화이트박스 테스트

소프트웨어의 안전성 분석을 위해서는 분석 대상 소프트웨어의 수준에 따라 분석 방법을 결정하는데 실행 프로그램만 있는 경우에는 블랙박스 테스팅, 소스코드가 제공되는 경우에는 화이트박스 테스팅을 수행하는 경우가 많다. 블랙박스 테스팅과 리버스 엔지니어링(Reverse Engineering)을 접목한 그레이박스 테스팅(Gray box Testing)도 알려져 있다(표1).

<표1> 소프트웨어 안전성 분석 방법의 장단점

출처: 한국전자통신연구원(ETRI)

블랙박스 테스팅과 화이트박스 테스팅을 활용하는 방법도 여러가지가 있다. 먼저 소프트웨어에 다양한 입력을 하여 실행시킨 후 결과를 살펴보는 동적 분석(Dynamic Analysis)과 소프트웨어를 실행시키지 않고 소스 코드의 내용으로 판단하는 정적 분석(Static Analysis)이 있다. 블랙박스 테스트와 화이트박스 테스트를 이 두가지 방법으로 구분하여 안전성을 테스트 할 수 있다(표2).

<표2> 정적 분석과 동적 분석

출처: 데이터베이스진흥원

소프트웨어 안전성 확인을 위해서 동적 분석은 소프트웨어의 특성에 따라 다양한 방법으로 확인해야 하지만 정적 분석은 요구사항을 받아 개발을 하면서 확인하기 때문에 요구사항을 받은 후 진행되는 프로세스에 따라 안전성 확인 방법이 어느 정도 정해져 있다.

피드 구독하기: 글 ( Atom )