Strategy for Software Reliability Improvement

소프트웨어 신뢰성은 "시스템이 고장 또는 결함으로부터 자유롭다는 것을 표현하기 위한 측정"이라 할 수 있다. 시스템 고장은 소프트웨어 안에 내재한 여러 가지 문제점으로부터 발생되어지므로 신뢰성 있는 소프트웨어를 위한 접근은 시스템 고장의 원인이 되는 요소를 계층화하고 이를 소프트웨어 개발 프로세스 상의 초기단계부터 고려하여 고장의 원인이 되는 결함들을 제거함으로써 성취할 수 있다.

---

소프트웨어 개발 프로세스 상에서의 결함에 대한 관리 프로세스는 크게 4가지 활동으로 나눠볼 수가 있다. 결함을 예방하는 활동, 결함을 검출하는 활동, 결함 발견 시 이를 즉시 제거하는 활동, 시스템 설계 시 결함으로부터 내성을 가지도록 설계하는 활동이 그것이다. 이를 정리하면 다음과 같다.

• 결함예방(Fault Prevention): 시스템 설계와 구현 프로세스는 프로그래밍 오류를 피하는 것을 도와 프로그램 결함 수를 최소화 할 수 있는 소프트웨어 기법을 이용.
• 결함내성 설계(Design Fault Tolerance): 시스템의 실행 동안 결함이나 예상하지 않은 시스템의 동작을 탐지하는 방식으로 시스템이 설계되고, 시스템 고장이 발생하지 않는 방식으로 관리되도록 설계되어야 함.
• 결함탐지(Fault Detection): 검증(Verification)과 확증(Validation) 프로세스를 이용하여 프로그램이 운영되기 이전에 결함을 발견하는 활동.
• 결함제거(Fault Removal): 결함탐지를 통해 발견된 결함을 제거하는 활동.

다음 그림은 위에서 설명한 내용을 좀 더 구체화하여 도식화한 것으로, 신뢰성 있는 소프트웨어를 위해 수행되어야할 활동, 방법, 툴, 그리고 데이터의 수집에 대한 내용을 포함하고 있으며 제품의 품질과 관련된 데이터를 수집하고 이를 통해 프로세스를 모니터링 함으로써 본 절의 목표를 성취하기 위한 전략을 표현하고 있다.

[신뢰성 있는 소프트웨어를 개발하기 위한 전략]

위 그림에서와 같이, 신뢰성 있는 소프트웨어를 개발하기 위한 전략은 크게 3가지로 나누어진다. 첫째는 제품을 잘 만들기 위한 전략, 둘째는 결함의 검출과 즉각적인 수정에 대한 전략, 셋째는 데이터의 수집과 평가에 대한 전략이 그것이다.

1. 제품을 잘 만들기 위한 전략(Do It Right)
결함을 예방하고 결함에 대한 내성을 같기 위해서는 먼저 기술력과 능력 있는 인적자원이 바탕이 되어야 하며, 이들을 통해서 Concept 단계에서 사용자의 요구사항과 목표들을 식별하고 관련 도메인에 대한 경험을 바탕으로 요구사항과 목표들이 사용자 응용시스템에 적당한 것인지 적당하지 않은 것인지에 대한 판단이 필요하다.
또한 운영 시 발생할 수 있는 문제에 대한 사전 고찰이 필요하다. 이를 통해 개발 초기단계에서 명확하고 안정된 목표들을 설정함으로써 전체 개발 프로세스의 방향을 설정할 수 있고, 운영 환경과 유지보수단계에서 다루어질 수 있는 중요한 요구사항을 미반영하는 실수를 피할 수 있으며, 아키텍처 단계에서 시스템의 품질 속성을 고려한 설계가 가능하다.
또한 생산성과 품질을 보장하기 위한 명세와 설계, 구현 그리고 형상관리를 위해 최신의 방법론과 자동화된 툴, 도메인에 적당한 개발 언어의 선택 역시 고려되어야 한다. 이들을 통해 요구사항의 추적성과 완벽하고 일관성 있는 분석과 구현, 주요 기능에 대한 시뮬레이션, 복잡도의 측정과 형상의 식별 및 관리가 가능하고 이는 인적자원으로 통해 발생할 수 있는 결함 위험을 최소화 해줄 수 있다.
그리고 운영환경에서의 사용자 시나리오를 고려한 운영 프로파일(Operation Profile)의 개발이 필요한데, 이것은 고객의 유형, 사용자의 유형, 시스템의 운영형태, 그리고 시스템의 주요기능을 기반으로 하여 각 유형에 따른 시스템의 기능의 동작을 실제 운영 시나리오 기반으로 작성된 테스트케이스라 할 수 있다.


2. 결함의 검출과 즉각적인 수정에 대한 전략(Detect It)
결함의 발견과 수정은 프로젝트 계획 시부터 계획된 필수 활동들이어야 한다. 검증(Verification)은 소프트웨어 수명 주기의 각 단계의 산출물들이 상위단계에서의 요구사항들을 전부 만족하는지를 검증하는 프로세스이며 “우리가 제품을 정확하게 제작했는가?”를 확인하는 활동이다. 확증(Validation)은 각 시스템 기능이 소프트웨어 요구사항에 맞게 구현되었음을 보증하는 활동으로 “우리가 정확한 제품을 제작했는가?”를 확인하는 활동이다.
개발 초기단계에서 결함의 검출은 검토(Review), 검사(Inspections), Prototyping, 그리고 정형 명세 및 증명을 통해 가능하며 검출된 결함은 다음 단계로 넘어가기 전에 수정되어야 하며, 수정 시에는 결함에 대한 영향도와 발생의 빈도를 고려하여야 한다. 또한 시험 단계에서는 소프트웨어 시험에 대한 계획, 환경 구축, 절차에 따라 이에 필요한 자원과 일정에 대한 고려를 통해 시험이 수행되어야 하며, 이를 통해 제품이 릴리즈되기 전까지의 소프트웨어에 잠재되어 잇는 결함을 제거할 수 있다.
일반적으로 시험은 기능단위에 대한 단위 시험, 설계확인을 위한 통합 시험, 요구사항 확인을 위한 시스템 및 인수 시험으로 진행된다. 긴 시간동안 많은 시험을 수행한다고 해서 신뢰성를 보장할 수 있는 것은 아니다. 신뢰성 보장을 위해서는 Criticality와 운영 프로파일이 고려된 테스트 케이스를 이용한 시험을 수행하는 것이 필요하다. 소프트웨어의 결함은 소프트웨어의 불확실성 때문에 잠재되어 있는 결함들이 릴리즈 이전까지 모두 제거되지 않는다. 따라서 비용과 일정, 그리고 신뢰성 목표 수준에 따른 릴리즈 계획도 고려되어야 한다.


3. 데이터의 수집, 계산, 평가에 대한 전략(Monitor It)
소프트웨어 수명 주기에서 각 프로세스의 활동들로부터 원시 데이터의 수집과 평가가 필요하다. 이는 현재의 프로세스가 얼마나 옳게 진행되고 있는지, 얼마나 명확하게 진행되는지를 정량적으로 표현해 주며 이들의 평가를 통해 현재의 상태를 모니터링 할 수 있다. 또한 수집된 데이터들의 평가를 통해 현재의 소프트웨어 품질에 대한 평가가 가능하며, 결함 검출에 대한 효과성의 측정이 가능하다. 하지만 좋은 데이터의 수집은 잘 정의되고 마련된 검증(Verification)과 확증(Validation) 프로세스가 없이는 불가능하다. 이러한 데이터의 수집은 제품의 특성과 품질속성을 고려하여 알맞은 측도와 척도의 식별로 가능하며 계산된 결과의 정확성에 대한 확인과 측정결과에 대한 평가가 함께 이루어 져야 한다.


본 게시물의 모든 저작권은 본인에게 있으며, 본 게시물의 일부 또는 전체를 인용할 시에는 반드시 출처를 밝혀야 합니다.