소프트웨어 신뢰성 관련 용어 정리

여기서 소개하는 소프트웨어 신뢰성 관련 용어는 TTA (Telecommunications Technology Association)의 "정보통신용어사전"과 소프트웨어 품질 및 신뢰성 관련 표준을 기반으로 정의하였으며, 그외 IEEE 표준을 참조 하였음을 밝힌다.

---

• 고장 (Failure)
  필요한 기능을 수행하는 어떤 요소의 기능 종료 혹은 미리 지정된 제한 시간 내에서의 수행 불능 상태
• 결점 (Defect)
  고장을 야기하는 버그 또는 문제점을 의미하며, 예를 들어 리뷰를 통해 발견하지 못한 사항으로 인해 소프트웨어의 고장을 야기하게 되면 이들을 결점이라고 한다.
• 오류 (Error)
  결과적으로 결함이 포함된 소프트웨어를 만든 사람의 행위, 예를 들면 소프트웨어 명세시 사용자 요구사항을 누락하거나 잘못 해석한 것을 오류라고 한다.
• 결함 (Fault)
  컴퓨터 소프트웨어 내부의 부정확한 절차, 처리 또는 데이터를 의미한다. (IEEE Std. 610.12-1990)
• 버그 (Bug)
  프로그램이나 하드웨어의 잘못된 동작을 의미하며, 컴퓨터 기술 분야에서는 컴퓨터 프로그램의 코딩 오류를 의미한다.
• 디버깅 (Debugging)
  프로그램에서 발견되는 버그를 찾아서 수정하는 것을 의미하며, 프로그램 개발 시작 단계부터 완료시까지 계속해서 디버깅 과정이 수행된다.
• 시험 (Test)
  시스템이나 시스템 구성 요소 (Component) 또는 소프트웨어 프로그램을 실행하고 평가하는 과정을 말한다. IEEE 정의에 따르면 수작업 또는 자동화된 방법으로 규정된 요구사항을 만족시키고 있는지 검증하고, 기대되는 결과와 실제 결과의 차이를 식별하는 작업을 말한다. 또한 G. J. Myers의 정의에 따르면 "시험은 '테스팅 (Testing)'이라고도 하며, 일반적으로 결함이 없음을 증명하는 것이 아니라, 결함이 있음을 발견하기 위해 체계적으로 수행하는 일련의 작업"을 의미한다.
• 단위 시험 (Unit Test)
  하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지 여부를 시험하는 최소 수준의 시험을 말한다. 원시 코드를 대상으로 하며, 단위 시험을 수행하는데 사용하는 주된 시험 방법은 화이트 박스 시험 (White Box Test)이다. 단위 프로그램별로 설계서 상에 정의된 기능을 제대로 수행하는지 검증하는 것을 목적으로 한다. 단위 시험은 해당 개발자가 수행할 수 있으나 다른 개발자나 또는 제 3자에 의한 시험도 가능하다.
• 통합 시험 (Integration Test)
  시스템이나 시스템 구성 요소 (Component) 또는 소프트웨어 프로그램의 데이터 및 기능 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행하는 시험을 의미한다.
• 시스템 시험 (System Test)
  시스템 구성 요소 (Component)나 소프트웨어 프로그램의 모듈의 하나의 시스템으로 동작하게 되면서, 시스템 성능과 관련된 고객의 요구 사항이 완벽하게 수행되는지를 평가하는 시험을 말한다. 현장에서 적용 가능한 시스템 시험으로 스트레스 시험과 볼륨 시험을 들 수 있다. 시스템 시험을 성공적으로 수행하기 위해서는 성능 요구 사항을 명확히 하여야 하며, 단위 시험과 통합 시험이 완료되어 기능상 문제가 없는 상태여야 한다. 실제 운영 환경과 동일한 모의 시스템을 구성하여야 하는 것은 물론, 개발자와 시험 전문가가 원활히 정보를 공유하고 협력하여야 한다.
• 인수 시험 (Acceptance Test, 현장 검수)
  계약상의 요구 사항이 만족되었는지 확인하기 위해, 설치 후 고객의 현장에서 납품자도 참가하여 고객에 의해 실시되는 시스템 또는 기능 단위의 시험을 의미한다.
• 요구사항 (Requirement)
  • 어떤 문제를 해결하거나 특정의 목적을 위하여, 사용자가 필요로 하는 조건이나 능력을 말한다.
  • 계약, 표준, 명세 또는 다른 형식으로 제시된 문서에 적합하여 시스템이나 시스템 구성 요소가 갖추어져야 할 조건이나 능력을 말한다. 요구 사항들은 시스템이나 시스템 구성 요소의 후속 개발 단계의 자료가 된다.
• 소프트웨어 수명 주기 (Software Life Cycle)
  소프트웨어 제품의 개념 형성에서 시작하여 운용/유지 보수에 이르기까지 변화의 전 과정을 말한다. 대상이 되는 소프트웨어의 규모나 종류, 개발 방법론에 따라 단계의 구분 방법이나 명칭이 다른다. 소프트웨어 수명 주기에는 요구 분석, 설계, 구현, 품질 보증, 도입/검수, 운영/유지보수의 여러 단계와 경우에 따라서는 사용 정지 단계가 포함된다. 이들 단계는 중복되기도 하고 반복되기도 한다.
• 내부 품질 (Internal Quality, IQ)
  제품이 지정된 조건에서 사용될 경우, 명시된 요구와 내재된 요구를 충족할 수 있는 능력을 결정하는 제품 속성 전체를 말한다.
• 외부 품질 (External Quality, EQ)
  제품이 지정된 조건하에서 사용될 경우에, 명시된 요구와 내재된 요구를 충족하는 정도를 말한다.
• 모수 (Parameter)
  모집단 (Population)의 특성을 나타내는 양적인 척도의 값을 모수라고 한다. 모수는 주어진 모집단의 고유한 상수로써 분포 (Distribution)에 따라 결정 될 수 있으며, 소프트웨어 신뢰성 성장 모델 (Software Reliability Growth Model, SRGM)에 따라 모수가 결정된다. 일반적으로 추정된 모수값을 이용하여 소프트웨어 신뢰성을 평가하기 위한 평가 척도를 정량적으로 측정할 수 있다.
• 모수 추정법 (Parameter Estimation Method)
  모집단의 특성치인 모수를 알아내기 위한 방법을 말한다. 모수 추정법으로는 소프트웨어 신뢰도 성장 모델에 따라 각 특성별로 추정된다.
• 소프트웨어 성능 (Software Performance)
  소프트웨어의 실행 시간이나 메모리 점유율과 같은 컴퓨터 자원의 관점에서 뿐만 아니라, 기능성, 신뢰성, 유지보수성, 이식성, 사용성, 효율성 등 소프트웨어 수명 전체에 걸쳐 나타나는 종합적인 성능을 의미한다.
• 소프트웨어 신뢰성 (Software Reliability, SR)
  소프트웨어가 특정한 시간 동안 주어진 환경 하에서 고장 없이 작동할 확률을 의미한다. 소프트웨어 신뢰성은 확률값이기 때문에 0과 1사이의 값을 갖는다.
• 소프트웨어 신뢰성 성장 모델 (Software Reliability Growth Mode, SRGM)
  소프트웨어 신뢰성을 평가하기 위한 확률적인 모델로서 소프트웨어의 시험 기간 중 발생되는 고장 데이터에 대해 고장 시간이나 고장 수를 중심으로 소프트웨어의 신뢰성을 평가한다. 소프트웨어 신뢰성 성장 모델은 각각의 고장 데이터를 적용하기 위한 조건을 제시하고, 제시된 조건을 만족하는 경우에 대하여 신뢰성을 평가하고 이러한 평가 결과는 소프트웨어 품질 특성과 관련된 평가 항목에 적용 가능하다. 고장 데이터의 특징에 따라 분석하며, 그 특성을 반영한 소프트웨어 신뢰성 성장 모델에 적용할 수 있다.
• 측도, 측정, 또는 수단 (Measurement, Measure)
  • 신뢰성 평가를 위해 실제 측정 가능한 정량적인 값 (예, 결함 수, 테스트케이스 수, 시험 시간, 투입인원 등)
    - 실제 신뢰성 평가에 주로 사용되는 의미이다.  (by Taewan Gu)
  • 척도를 이용하여 개체의 속성에 정해진 범위로부터 값을 할당하는 행위
• 측정치 (Measure)
  측도에 의해 개체의 속성에 할당된 값으로, 수치 또는 범주 또는 측정 결과 할당되는 값의 변수를 의미한다.
• 척도 (Metrics)
  • 정의된 측정 방법 및 측정 등급
  • 실제 신뢰성 평가에 활용되는 정량적 등급 또는 방법 (예, 결함 밀도)
    - 실제 신뢰성 평가에 주로 사용되는 의미히다. (by Taewan Gu)
• 평균 고장 시간 (Mean Time Between Failure, MTBF)
  신뢰성 측정에 있어서 평균적으로 고장과 고장 사이의 시간을 의미하는 것으로 MTBF는 고장에 대한 평균 시간 (Mean Time To Failure, MTTF)과 고장을 해결하는데 걸리는 평균 시간 (Mean Time To Repair, MTTR)의 합으로 계산된다.
• 품질 (Quality)
  주어진 요구 사항을 만족시키는 능력을 가진 제품이나 서비스의 전체적인 특징을 의미하며, 제품이나 서비스가 가지고 있는 명시적 또는 묵시적 요구사항을 만족시키기 위한 능력을 갖는 개체의 특성 및 특성의 집합을 의미한다.
• 품질 평가 (Quality Evaluation or  Quality Assessment)
  한 개체가 명시된 요구사항을 충족 시킬 수 있는 정도에 대한 체계적인 분석/조사 등의 행위를 의미한다.
• 품질 모델 (Quality Model, QM)
  품질 요구 사항을 명세하고, 품질을 평가하는 기준을 제공하는 특성 집합과 그들 간의 상호 관계를 의미한다.
• 소프트웨어 제품 (Software Product)
  컴퓨터 소프트웨어, 또는 소프트웨어와 관련된 문서 및 소프트웨어와 관련된 데이터의 집합을 의미한다.
• 확증 (Validation)
  • 명확한 번역이 존재하지 않으나, 국내 표준에서는 "Validation"을 "확증"으로 번역하고 있다. (by Taewan Gu)
  • 소프트웨어 개발 과정에서 생성된 최종 산출물이 사용자 요구사항을 만족하는지를 보장하기 위한 평가 과정을 의미한다.
• 검증 (Verification)
  소프트웨어 수명 주기 상의 각 단계에서 생성되는 산출물이 이전 단계에서 설정된 요구 사항을 만족하는지를 결정하는 과정을 의미한다.
• 복잡도 (Complexity)
  시스템이나 시스템 구성 요소 (Component) 또는 소프트웨어 프로그램의 복잡도를 측정하는 척도를 말한다. 시스템을 어느 정도의 수준까지 시험해야 하는지 또는 시스템을 개발하는에 어느 정도의 노력을 소요해야 하는지를 결정하는 근거를 제공한다. 복잡도 매트릭을 통해 시스템 (구성 요소)의 복잡도를 측정한 결과 복잡도가 높은 경우, 일반적으로 많은 결함이 발생할 가능성이 크므로 보다 정밀한 시험을 통해 내재된 결함 및 오류를 사전에 제거하여야 한다. 일반적으로 복잡도 척도는 시스템 구성 요소의 크기를 제어하는 논리의 복잡도 조합으로 볼 수 있다. 복잡도를 측정하는 표준적인 방법에는 LOC (Line Of Code), McCabe's Complexity, Halstead's Metrics 등이 있다.
• 운영 시험 (Operational Testing)
  운영 환경에서 컴포넌트나 시스템의 평가를 수행하는 시험을 말한다. (IEEE Std. 610)
• 개발 시험 (Development Testing)
  시스템 구성 요소 및 시스템 구현 과정에서 주로 개발환경에서 수행하는 공식/비공식 시험을 말한다. (IEEE Std. 610)
• 검토 (Review)
  계획되어 있는 결과 (Planned Results)와 불일치 하는 것을 확인하고, 개선을 조언하기 위해 제품이나 프로젝트의 상태를 평가하는 것을 말한다. 예로는 관리 검토 (Management Review), 비공식 검토 (Informal Review), 기술적 검토 (Technical Review) , 인스펙션 (Inspection), 그리고 워크 쓰루 (Walkthrough)가 있다. (IEEE Std. 1028 준수)
• 비공식 검토 (Informal Review)
  공식적인 (문서화된) 절차를 따르지 않는 검토를 의미한다.
• 공식 검토 (Formal Review)
  인스펙션과 같이 문서화된 절차 및 요구사항에 의해 구별되는 검토를 의미한다.
• 동료 검토 (Peer Review)
  결함과 개선을 식별하기 위해, 개발자의 동료가 소프트웨어 작업 산출물을 검토하는 것을 의미한다. 예를 들어, 인스펙션, 기술적 검토, 워크 쓰루 등이 이에 포함된다.
• 코드 커버리지 (Code Coverage)
  Test Suit로 소프트웨어의 어떤 부분이 실행(커버)되었고, 어떤 부분이 실행되지 않았는지 결정하는 분석 기법을 의미한다. 예를 들어, 구문 (Statement) 커버리지, 결정 (Decision) 커버리지, 조건 (Condition) 커버리지 그리고 MC/DC 커버리지 등이 있다.
• 심각도 (Severity)
  시스템 구성 요소나 시스템의 개발이나 운영에 결함이 미치는 영향도를 의미한다. (IEEE Std. 610)

 

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