제 2 절 소프트웨어 품질보증의 의미

 

소프트웨어의 품질보증업무는 일반 하드웨어의 품질보증업무와 마찬가지로 단지 최종결과물의 검사와 시험에 의해서만 수행되는 것이 아니고 소프트웨어의 전 개발단계에 적용함으로서만이 가능하다. 물론 소프트웨어의 결함을 제거하고 해석하는 일이 소프트웨어의 품질보증을 위해서 중요한 기능이기는 하지만 보다 중요한 것은 사전에 이들 결함이 발생되지 않도록 예방하는 일이라 할 수 있다.

 

과거의 소프트웨어 품질보증 프로그램은 시험계획, 시험절차, 시험범주, 시험형식, 시험방법에 대한 규격서와 같은 시험프로그램이 전부였다. 이와 같이 시험에 국한된 소프트웨어 품질보증 프로그램의 취약점은 시험을 통해서는 단지 소프트웨어 제품의 품질을 제한적으로 확인할 수는 있어도 결코 과정 중에 품질을 만들어 넣지는 못한다는 것이다.

 

기본적으로 소프트웨어 품질보증 프로세스와 그 관리정도는 소프트웨어 제품의 품질에 대한 판단기준에 따라 결정된다. 구체적인 목표가 없는 프로세스는 결코 목적한 곳에 도달할 수 없다. 물론 특정된 소프트웨어 품질보증 기법은 프로세스상의 방법과 기준에 따라 적용할 수 있다.

 

예를 들면 전체 시스템에 대한 소프트웨어 결함의 영향 도를 평가하는데 위험도 분석(Risk Analysis)을 이용할 수 있으며 위험도와 그 영향도가 클수록 소프트웨어 품질보증 효과가 나타나게 된다.

 

소프트웨어 품질보증프로그램은 조직의 목표, 특성 및 업무에 따라 수립되어야 한다.

 

소프트웨어를 개발하는 조직은 소프트웨어 제품을 이용하는 조직보다는 설계와 시험과정에 대해 더 관심을 기울여야 한다. 또한 후자 조직은 형태관리(Configuration Man-agement) 및 코드관리, 합부시험 및 구매 행위에 중점을 두어야 한다.

 

소프트웨어 품질보증이란 요구되어 지는 소프트웨어 품질을 성취하기 위해서 계획되어 지고 체계화된 모든 활동을 의미하는 것이며 따라서 품질보증 활동은 materials, 데이타, supplies 또는 서비스 등이 기 확립된 기술적인 요구사항과 일치하는 지를 확인케 하여 주며 또한 소프트웨어가 만족스럽게 수행되는 지를 확인케 한다.

 

따라서 소프트웨어 품질보증의 본질(Essence)은 프로그램의 결점(Defects)을 사전에 방지하고 그들이 발견되면 제거함으로써 소프트웨어의 사용도(Usability)와 보전도 (Maintainability)를 높이는데 있다.

 

소프트웨어 품질보증 계획은 최종결과물 검사(Inspection)와 검증(Testing)은 물론 전 소프트웨어 개발과정에 대하여 적용되어지는 것이다. 소프트웨어 품질보증의 목적이 결점의 제거와 그 분석이지만 더 중요한 것은 결점의 방지에 있는 것이다. 과거에는 소프트웨어 품질보증계획이라 하면 검증계획, 검증절차서, 검증의 범위, 검증 종류 및 검증 방법 등에 대한 규격서(Specification)와 같은 검증계획(Test Program)을 일컬었다. 이와 같이 검증에 중점을 둔 소프트웨어 품질보증계획의 주요 단점은 품질은 소프트웨어 결과물로서 검증되어 지는 것이 아니라는 점이다. 즉, 품질은 소프트웨어 결과물로 만들어지면서 결정되는 것이다.

 

소프트웨어의 품질을 판단하기 위해서는 사용하는 품질기준에 따라 소프트웨어 품질 보증계획의 방향이 결정된다. 따라서 각 조직은 그들의 업무(Activities)에 적용시킬 소프트웨어 품질보중 계획을 작성하여야 한다. 소프트웨어를 개발하는 조직은 소프트웨어를 사용해야 하는 조직보다 설계와 검증과정(Testing Process)에 관심을 가져야 하며, 소프트웨어 사용 조직은 Configuration Management, Acceptance Testing 및 구매업무에 중점을 두어야 한다.

 

대부분의 원자력이용자(Nuclear Utilities)는 소프트웨어의 사용조직으로 고려되어지며, 소프트웨어 결과물이 소프트웨어 품질보증 요건에 일치하는 지를 보증하기 위해 소프트웨어 공급자에 대한 검토와 품질감사를 수행할 수 있는 능력을 갖추어야 한다.

 

2.1 소프트웨어 품질과 하드웨어 품질

 

 

원자력 산업에서 사용되는 하드웨어 품질보증 개념의 대부분이 소프트웨어 품질보증에 적용될지라도 양자간에는 많은 차이가 있는데, 이러한 차이점들은 소프트웨어 품질보증계획을 확립하는 데 분명히 고려되어야 한다.

 

● 하드웨어의 보수(Repairs)는 원상태대로의 복귀를 의미하지만 소프트웨어 보수란 또 하나의 새로운 소프트웨어의 개발을 의미한다.

 

● 소프트웨어의 고장은 하드웨어와는 달리 경고(Warning)없이 일어난다.

 

● 하드웨어 기기들은 표준화될 수 있지만, 소프트웨어는 거의 표준화될 수 없다.

 

● 하드웨어는 소모적인 시험이 가능하나, 소프트웨어는 근본적으로 무한한 시험을 할 수 있다.

 

● 하드웨어 품질은 초음파시험, 재료시험과 같이 제품의 측정에 의해 확립이 가능한 반면 소프트웨어는 그렇지 않다.

 

● 하드웨어의 고장은 설계, 생산, 운영 등에 기인하나 주로 설계상의 잘못에 기인한다

 

● 하드웨어의 신뢰도는 다중설계(Redundancy)에 의해 향상되지만 소프트웨어는 복합설계에 의해 신뢰도가 향상되지 않는다.

 

위의 내용을 고찰할 때 소프트웨어의 품질은 개발과정을 통하여 소프트웨어에 반영되어야 한다는 것을 알 수 있다.

 

 

2.1.1 품질보증을 적용해야 할 소프트웨어 종류

 

소프트웨어 품질보증 계획을 적용해야할 필요가 있는 소프트웨어의 종류는 근본적으로 10 CFR 50 Appendix B에 의해 정하여진다. 이는 안전과 관련된 구조물, 계통, 기기에 대한 설계, 분석, 운 전시에 사용되는 소프트웨어들로서 아래와 같다.

 

● 응용소프트웨어 (Application Software)

 

응용소프트웨어의 예로는 원자로설계(Reactor Design), 노심 연구(Core Physics Studies), 웅력계산(Stress Calculations), 수력학적 계산(Thermal Hydraulic Calculations), 플랜트 제한조건을 결정하는 각종 원자로안전사고분석(Power Distribution, Heat Generation Rates) , Surveillance Testing, Safety System Actuation 그리고 발전소 운영(Plant Control) 등을 위한 컴퓨터 코드 등이 있다. 응용소프트웨어가 쓰이는 또 다른 분야는 가동중 검사, 유지 보수일정을 위한 자재 호환성(Materials Compatibility)의 결정, 설비접근성(Plant  Accessibility) 등을 포함한다.

 

● 지원소프트웨어 (Support Software)

 

지원소프트웨어는 응용 소프트웨어를 개발하거나 사용할 때 시스템 측면에서 지원하는 소프트웨어를 말한다. 예를 들어 컴파일러, 어셈블러, 에디터, 시험프로그램(Testing Program), 수학적인 서브루틴 라이브러리, 시스템라이브러리, 유틸리티(Utility Routines) 등이 이에 속한다.

 

● 시험 및 운영 소프트웨어 (Test and Maintenance Software)

 

시험 및 운영소프트웨어는 시험(Testing), 운전(Operation)과 운영기능(Main-tenance Functions)을 수행하는데 사용되는 소프트웨어이다.

 

● 교육용 소프트웨어 (Training Software)

소프트웨어 시스템은 원자력 설비 관련 업무에 있어서 CAI(Computer Aided Instruction)를 수행하기 위해서도 사용된다. 이 훈련용 소프트웨어는 CAI는 물론 원자로 조종사 혹은 기타 원자력설비 운영자를 교육시키기 위해 만들어진 시뮬레이터(Simulators) 소프트웨어 등으로 구성되어 있다.

 

2.1.2 소프트웨어 품질의 계량화 방법

 

소프트웨어 품질보증 프로그램을 확립하기 위해서는 소프트웨어의 품질에 대한 정의가 있어야 한다. 소프트웨어의 품질은 측정 가능할 때만 성취할 수 있고 품질이 정의되었을 경우에 만 측정 가능하다.

 

품질의 측정은 두 가지의 측면에서 고려할 수 있는데 그 하나는 품질코스트(Quality Cost)의 측면이고 다른 하나는 요구사항(Requirements)에의 적합성(Conform-trance)의 측면이다.

 

(가) 품질비용 측면

 

품질비용(Quality Cost)은 품질관리에 드는 비용의 총칭을 의미한다.

 

즉 소프트웨어(SW) 제품이 사용자가 쓰는데 문제가 없다는(Defect-free) 것을 보증하는데 드는 비용을 의미하며 예방비용, 평가비용, 실패비용 등으로 구분한다.

 

예방비용은 소프트웨어를 개발하기 전에 에러를 방지하기 위하여 드는 비용이며, 평가비용은 개발중인 소프트웨어가 사용자의 요구사항과 일치하는 지를 확인하는데 드는 비용이며, 테스트, 검토 등이 이에 해당한다. 여기서 테스트와 검토를 정의한다면 테스트(test)는 Sample data 또는 실제 data를 가지고 소프트웨어 제품을 검사하는 것이며 검토(Review)는 테스트를 할 수 없는 경우 규격 서를 서면으로 검사하는 것을 말한다.

 

실패비용은 개발 완료된 소프트웨어를 사용하고 유지 보수하는 단계에서 재개발(Rework)을 한다거나 또는 결점을 보완하기 위하여 수정 및 보수하는데 드는 비용을 의미한다.

 

(표 12.1)은 예방비용, 평가비용 그리고 실패비용의 요소를 나타내었으며 (그림 12.1)에서 Cost 간의 관계는 예방비용을 증가시키면 평가비용과 실(그림 12패 비용이 감소하며 전체 Quality cost가 감소하는 것으로 나타나 있다. 이 예는 소프트웨어 개발의 초기부터 품질보증 적용의 필요성을 강조하는 내용이다.

 

                (그림 12.1) 품질코스트에 대한 oA의 역할

 (표 12.1) 소프트웨어 품질 코스트의 요소

Prevention

Cost

Consulting, Quality planning, 프로젝트 개발 방법 설정, 데이터베이스 계획, Standards와 요구사항의 정의, SQAP의 작성, 프로젝트 품질계획, 개발환경의 확립

Appraisal

Cost

검토계획 작성, V/V, Audit, Inspection, Review, 점검 및 기술검토 Acceptance Test.

Failure

Cost

Project rework, Malfunction, Maintenance Repair, Redundancy, Damage Claim, Retest Error Analysis

 

(나) 품질적합성(Conformance) 측면

 

품질에 대한 관점 차이로서 개발자의 관점은 프로그래밍 규약에 따라 프로그램을 올바로 제작하는 것이고 사용자의 관점은 사용하기 쉬우며 응답시간이 빠른 것으로 말할 수 있으며 운영자의 경우는 확실한 문서화(Documentation)와 이해 용이한 소스 프로그램으로 소프트웨어(SW)의 품질을 말하기도 한다.

 

여기서는 이러한 관점들을 통합하여 (그림 12.2)과 같은 소프트웨어 품질계량 모델(SQM 소프트웨어 Quality Metric Model)을, (표 12.2 및 12.3)에 나타난 바와 같이 13개의 품질요건(Factors)과 26개의 품질기준(Criteria)을 고려할 수 있다. 이 품질기준은 SW를 개발하는 과정(Process)으로부터 유도된 것이 아니라 SW의 제품의 속성을 의미한다. 각각의 기준(Criteria)의 측정은 요소(Element)에 의하여 측정 가능하며 이 요소의 측정값을 metric이라고 정의한다.

 

예를 들어서 완전성(Completeness)은 프로그램의 전 부분이 완성되었는가를 나타내는 척도로서 그 요소(Elements)는

 

● 각 의사결정 분기점(Decision Point)의 모든 조건과 처리형태가 정의되었는 가의 여부

 

● 각 내부데이터 구조가 정의되었는 가의 여부

 

● 각 입력 조건 값이 정의되었을 가의 여부

 

등으로 나타내어 평가할 수 있다는 것이다. .수백 개의 이러한 요소가 26개의 기준과 연관되어 있고 또한 한 개의 기준에 대하여 여러 개의 요소들이 SW적용분야, 개발단계, 요소(Factors) 등에 의해 변화한다. 이러한 요건과 기준의 관계가 (표 12.4)에 나타나 있으며 기준에 대한. 요소의 내용들을 점검표로 작성하여 소프트웨어의 품질을 측정할 수 있을 것이다.

 

    [그림 12.2] 소프트웨어 품질측정의 체계

 

                              (표 12.2) 소프트웨어 품질요소(ractors)

정 확 성

(Correctness)

소프트웨어의 목적을 달성하는 ?

신 뢰 성

(Reliability)

프로그램이 의도된 기능을 항상 정확히 수행하는 ?

효 율 성

(Efficiency)

시간이나 자료를 낭비하지 않는 ?

순 수 성

(Integrity)

시스템 및 데이터의 보호기능이 있는 ?

재 사 용 성

(Reusability)

일반적인 독립모듈로 구성되어 있는?

사용의 편의성

(Usability)

사용하기 쉬운 ?

유지보수성

(Maintainability)

새로운 환경에서 용이하게 수정되는 ?

테스트 용이성

(Testability)

테스트가 가능한 ?

범 용 성

(Potability)

타 기종에서도 수행되는 ?

상호작동성

(Inter-operability)

타 시스템과 연계성이 있는 ?

모듈 통신성

(Intra-operability)

구성 프로그램 모듈간에 통신이 잘되는 ?

신 축 성

(Flexibility)

수정이 가능한 ?

생 존 성

(survivability)

시스템의 어떤 부분이 동작 불가능할 때 중요기능이 수행되는 ?

                                   

(표 12.3) 소프트웨어 품질기준(criteria)

 

접근 감시성(Access Audit)

일반성(Generality)

접근관리성(Access control)

장치독립성(Hardware Independence)

정확성(Accuracy)

기계사용성(Modularity)

자율성(Autonomy)

모듈성(Modularity)

통신보편성(Communication commonality)

작동성(Operability)

통신용이성(Communicativeness)

재구성 용이성(Reconfigurability)

완벽성(Completeness)

견고성(Robustness)

간결성(Conciseness)

자기 기술성(Self-Descriptiveness)

일관성(Consistency)

단순성(Simplicity)

데이터 보편성(Data commonality)

독립성(소프트웨어 System Independence)

에러 허용성(Error tolerance)

저장 효율성(Storage Efficiency)

실행효율성(Execution efficiency)

추적 용이성(Traceability)

확장성(Expandibility)

훈련성(Training)

                (표 12.4) 품질요건(Factor)과 품질기준(Criteria)의 관계

품 질 요 건

품 질 기 준

정 확 성

추적용이성, 완전성, 일관성

신 뢰 성

일관성, 정확성, 단순성, 에러허용성

효 율 성

실행효율성, 접근관리성

순 수 성

접근감시성, 접근관리성

재 사 용 성

일반성, 모듈성, SW 시스템 독립성

사 용 의 편 의 성

훈련용이성, 통신용이성, 작동성

유 지 보 수 성

일관성, 단순성, 간결성, 모듈성, 자기기술성

테 스 트 용 이 성

모듈성, 단순성, 자기기술성, 기계사용성

범 용 성

모듈성, 자기기술성, 장치독립성

상 호 작 동 성

모듈성, 통신보편성, 데이터보편성

모 듈 통 신 성

모듈성, 통신보편성, 데이터보편성

생 존 성

에러허용성, 모듈성, 견고성, 재구성용이성, 자율성