소프트웨어 검증 및 검증

Software verification and validation
IEEE 소프트웨어의 라이프 사이클

소프트웨어 프로젝트 관리, 소프트웨어 테스트 및 소프트웨어 엔지니어링에서 검증과 검증(V&V)은 소프트웨어 시스템이 사양과 요건을 충족하고 있는지 확인하는 프로세스입니다.소프트웨어 품질 관리라고도 합니다.일반적으로 소프트웨어 개발 라이프사이클의 일부로서 소프트웨어 테스터의 책임입니다.간단히 말하면 소프트웨어 검증은 "X를 구축해야 한다고 가정할 때 당사의 소프트웨어는 버그나 갭 없이 목표를 달성합니까?"입니다.한편 소프트웨어 검증은 다음과 같습니다.X는 우리가 구축해야 할 것이었습니까?X가 높은 수준의 요건을 충족합니까?

정의들

검증과 검증은 동일하지 않지만 혼동되는 경우가 많습니다.Boehm은 그 차이를[1] 간결하게 표현했다.

  • 검증:우리가 제품을 제대로 만들고 있나요?
  • 검증:올바른 제품을 만들고 있습니까?

「제품의 올바른 구축」은 사양이 시스템에 의해서 올바르게 실장되고 있는 것을 체크하고, 「적절한 제품의 구축」은 유저의 요구를 참조합니다.일부 상황에서는 준수 여부를 결정하기 위한 공식 절차 또는 프로토콜뿐만 아니라 두 가지 모두에 대한 서면 요구사항이 요구됩니다.정식 방법은 소프트웨어가 사양을 충족한다는 수학적 보증을 제공하는 것이 이상적입니다.

제품의 올바른 구축은 개발 프로세스의 다음 단계인 설계 프로세스의 입력으로 요건 사양을 사용하는 것을 의미하며, 그 결과물이 설계 사양입니다.또한 설계 사양을 사용하여 건설 프로세스를 공급해야 한다는 의미도 있습니다.프로세스의 출력이 입력 사양을 올바르게 구현할 때마다 소프트웨어 제품은 최종 검증에 한 걸음 더 다가갑니다.프로세스의 출력이 올바르지 않으면 개발자는 이해관계자가 원하는 제품을 올바르게 구축하지 못하고 있습니다.이러한 종류의 검증을 "아티팩트 또는 사양 검증"이라고 합니다.

적절한 제품을 구축하려면 소프트웨어 제품의 이해관계자의 요구와 목표를 포함하는 요건 사양을 작성해야 합니다.이러한 아티팩트가 불완전하거나 잘못되면 개발자는 이해관계자가 원하는 제품을 만들 수 없습니다.이는 "아티팩트 또는 사양 검증" 형식입니다.

주의: 검증 전에 검증을 시작하여 소프트웨어 제품이 [clarification needed]출시될 때까지 병렬로 실행됩니다.(반대되는 이유는 다음과 같습니다).

검증이라는 용어는 종종 검증이라는 용어와 관련지어지며 V&V의 단일 개념으로 이해된다.검증은 문제가 올바르게 동작하고 있는지 확인하기 위해 사용되는 반면 검증은 문제를 올바르게 해결했는지 확인하기 위해 사용됩니다(Martin 1997).실제와 어원적인 의미로부터, 검증이라는 용어는 진실을 의미하는 라틴어 verus와 만들고 실행한다는 의미인 facere에서 유래했다.따라서 검증이란 어떤 것이 진실인지 또는 옳다는 것을 증명하는 것을 의미합니다(특성, 특성 등).validation이라는 용어는 강해진다는 뜻의 라틴어 valere에서 유래했으며, 어원적으로 값이라는 단어와 같은 어원을 가지고 있다.따라서 검증이란 기대 효과를 내기 위한 적절한 기능을 갖추고 있음을 증명하는 것을 의미한다.(「평범한 영어로 검증과 검증」(Lake INCOSE 1999)에서 인용).[1][ISO/IEC/IEEE 15288]

소프트웨어 검증

이는 소프트웨어를 실행함으로써 사양이 충족되는지 여부를 검증하는 것을 의미하지만, 이는 불가능합니다(예를 들어 아키텍처/설계 등이 소프트웨어를 실행함으로써 올바르게 구현되었는지 어떻게 알 수 있습니까?).관련된 아티팩트를 검토해야만 규격이 충족되는지 여부를 판단할 수 있습니다.

아티팩트 또는 사양 검증

각 소프트웨어 개발 프로세스 단계의 출력은 입력 사양과 대조하여 확인 대상이 될 수도 있습니다(아래 CMMI 정의 참조).

아티팩트 검증의 예:

  • 요건 사양에 대한 설계 사양:아키텍처 설계, 상세 설계 및 데이터베이스 논리 모델 사양이 기능 및 비기능 요건 사양을 올바르게 구현하고 있습니까?
  • 설계 사양에 따른 시공 아티팩트:소스 코드, 사용자 인터페이스 및 데이터베이스 물리 모델이 설계 사양을 올바르게 구현하고 있습니까?

소프트웨어 검증

소프트웨어 검증은 소프트웨어 제품이 의도한 용도를 충족하는지 여부를 확인합니다(개요 수준의 체크). 즉, 소프트웨어가 사용자 요건을 충족하는지 확인합니다.사양상의 아티팩트나 소프트웨어를 조작하는 사람만의 요구가 아니라 모든 이해관계자(사용자, 오퍼레이터, 관리자, 관리자, 투자자 등)의 요구에 따라 이루어집니다.s 등).소프트웨어 검증에는 내부와 외부 두 가지 방법이 있습니다.내부 소프트웨어 검증에서는 이해관계자의 목표가 올바르게 이해되고 요건 아티팩트에 정확하고 포괄적으로 표현되었다고 가정한다.소프트웨어가 요건 사양을 충족하고 있는 경우는, 사내에서 검증되고 있습니다.외부 검증은 소프트웨어가 이해관계자에게 요구 사항을 충족하는지 물어봄으로써 수행됩니다.다른 소프트웨어 개발 방법론에서는 다양한 수준의 사용자 및 이해관계자의 관여와 피드백을 요구합니다.따라서 외부 검증은 개별 이벤트 또는 연속 이벤트일 수 있습니다.최종적인 외부 검증은 모든 이해관계자가 소프트웨어 제품을 승인하고 소프트웨어 제품이 자신의 요구를 충족한다고 표명할 때 이루어집니다.이러한 최종 외부 검증을 위해서는 동적 테스트인 인수 테스트를 사용해야 합니다.

다만, 내부 스태틱테스트를 실시해, 소프트웨어가 요건 사양을 만족하고 있는지 아닌지를 판별할 수도 있습니다만, 소프트웨어가 동작하고 있지 않기 때문에 스태틱 검증의 대상이 됩니다.

아티팩트 또는 규격 검증

소프트웨어 제품 전체가 준비되기 전에 요건을 검증해야 합니다(폭포 개발 프로세스에서는 설계를 시작하기 전에 요건을 완벽하게 정의해야 하지만 반복 개발 프로세스에서는 이를 요구하지 않고 지속적으로 개선할 수 있습니다).

아티팩트 검증의 예:

  • 사용자 요건 사양 검증:「사용자 요건 사양」이라고 불리는 문서에 기재되어 있는 유저 요건은, 실제로 이해관계자의 의지와 목적을 나타내고 있는지를 체크하는 것으로 검증됩니다.이 작업은 이해관계자를 인터뷰하여 직접 질문하거나(정적 테스트), 프로토타입을 공개하고 사용자와 이해관계자가 평가하도록 하는(동적 테스트) 방법으로 수행할 수 있습니다.
  • 사용자 입력 유효성 검사:사용자 입력(키보드, 바이오 메트릭 센서 등 주변기기에 의해 수집됨)은 소프트웨어 오퍼레이터 또는 사용자가 제공한 입력이 도메인 규칙 및 제약사항(데이터 유형, 범위, 형식 등)을 충족하는지 확인함으로써 검증됩니다.

검증과 검증

능력 성숙도 모델(CMMI-SW v1.1)[2]에 따르면

  • 소프트웨어 검증:개발 프로세스 중 또는 개발 프로세스의 마지막에 소프트웨어를 평가하여 특정 요건을 충족하는지 여부를 판단하는 프로세스.[IEEE-STD-610]
  • 소프트웨어 검증:특정 개발 단계의 제품이 해당 단계의 시작 시 부과된 조건을 충족하는지 여부를 판단하기 위해 소프트웨어를 평가하는 과정입니다.[IEEE-STD-610]

소프트웨어 개발 프로세스에서의 검증은 사용자 요건 사양 검증의 한 형태로 간주할 수 있습니다.또한 개발 프로세스의 마지막에 내부 소프트웨어 검증 및/또는 외부 소프트웨어 검증과 동등합니다.CMMI의 관점에서 검증은 분명히 아티팩트의 종류입니다.

반면 소프트웨어 검증을 수행하면 소프트웨어 제품(그러므로, r. 모든 이해 관계자들의 요구를 충족을 보장한다 즉, 소프트웨어 검증에서 소프트웨어 개발 과정의 각 단계의 출력 효과적으로 해당 입력 유물(요건 ->, 설계 ->, 소프트웨어 제품)이 지정하는 수행,을 보장한다equire멘트 규격은 애초에 정확하고 정확하게 표현되었다.)소프트웨어 검증을 통해 "올바른 구축"을 보장하고 제공된 제품이 개발자의 계획을 충족하는지 확인할 수 있습니다.소프트웨어 검증을 통해 "올바른 것을 구축했다"는 것을 보증하고 제공된 제품이 이해관계자의 의도된 사용 및 목표를 충족하는지 확인합니다.

이 문서에서는 검증의 엄격한 정의 또는 좁은 정의를 사용하고 있습니다.

테스트의 관점:

  • 결함 – 코드의 기능이 잘못되었거나 누락되었습니다.
  • Failure(실패) – 실행 중 장애의 징후입니다.소프트웨어는 효과적이지 않았다.'무엇'을 해야 하는지 알 수 없다.
  • 오작동 – 사양에 따라 시스템이 지정된 기능을 충족하지 않습니다.소프트웨어는 효율적이지 않았습니다(CPU 사이클, 메모리 사용량, I/O 작업 실행이 너무 많음 등). 사용할 수 없거나 신뢰성이 떨어졌습니다.그것은 그것을 어떻게 할 것인가 하는 것을 하지 않는다.


관련 개념

검증과 검증은 모두 품질 및 소프트웨어 품질 보증의 개념과 관련되어 있습니다.검증과 검증만으로는 소프트웨어의 품질을 보증할 수 없습니다.계획, 트레이서빌리티, 구성관리 및 기타 소프트웨어 엔지니어링 측면이 필요합니다.

모델링 및 시뮬레이션(M&S) 커뮤니티 내에서 검증, 검증 및 인증의 정의는 유사합니다.

  • M&S 검증은 모델 및 시뮬레이션 구현의 컴퓨터 모델, 시뮬레이션 또는 연합과 관련 데이터가 개발자의 개념 설명 및 [3]사양을 정확하게 나타내는 프로세스입니다.
  • M&S 검증은 모델, 시뮬레이션 또는 모델 및 시뮬레이션의 연합과 관련 데이터가 의도된 용도의 관점에서 실제 세계를 정확하게 표현하는 정도를 결정하는 과정이다.[3]
  • 인증은 모델 또는 시뮬레이션이 특정 [3]목적을 위해 사용될 수 있다는 공식 인증입니다.

M&S 검증의 정의는 M&S가 실제 의도된 용도를 나타내는 정확성에 초점을 맞춘다.모든 M&S는 현실의 근사치이며, 일반적으로 근사치가 의도한 용도에 적합한지 여부를 결정하는 것이 중요하기 때문에 M&S 정확도 결정이 필요하다.이는 소프트웨어 검증과는 대조적입니다.

V&V 방식

공식적인.

미션 크리티컬한 소프트웨어 시스템에서는 시스템의 올바른 동작을 보증하기 위해 정식 방법을 사용할 수 있습니다.그러나 이러한 공식적인 방법은 총 소프트웨어 설계 비용의 80%에 달하는 비용이 들 수 있습니다.

독립적인

ISVV(Independent Software Verification and Validation)는 안전에 중요한 소프트웨어 시스템을 대상으로 하며 소프트웨어 제품의 품질을 향상시키고, 그 결과 소프트웨어의 동작 수명 동안 리스크와 비용을 절감하는 것을 목적으로 합니다.ISVV의 목표는 소프트웨어가 지정된 신뢰수준까지, 그리고 설계된 파라미터와 [4][5]정의된 요건 내에서 수행되도록 보장하는 것이다.

ISVV 액티비티는 소프트웨어 개발 프로세스에 관여하지 않는 독립된 엔지니어링 팀에 의해 프로세스와 결과물을 평가하기 위해 수행됩니다.ISVV 팀의 독립성은 재무, 관리, 기술 등 3가지 수준으로 이루어집니다.

ISVV는, 개발 팀이 적용하는 「기존의」검증 및 검증 기술을 넘어서는 것입니다.후자는 소프트웨어가 명목상의 요건에 대해 양호한 성능을 발휘하도록 하는 것을 목적으로 하고 있지만 ISVV는 견고성과 신뢰성 등의 비기능적 요건과 소프트웨어 장애를 일으킬 수 있는 조건에 초점을 맞추고 있습니다.

ISVV의 결과와 결과는 수정과 개선을 위해 개발팀에 피드백됩니다.

역사

ISVV는 IV&V(Independent Verification and Validation)를 소프트웨어에 적용함으로써 파생됩니다.초기 ISVV 적용(오늘날 알려진)은 미 육군이 탄도미사일 방어 시스템을 위한 [6]IV&V와 관련된 첫 번째 중요한 프로그램을 후원했던 1970년대 초로 거슬러 올라간다.또 다른 예는 [7]1993년에 설립된 나사의 IV&V 프로그램이다.

1970년대 말까지 IV&V는 빠르게 인기를 끌었다.소프트웨어의 복잡성, 크기 및 중요성의 지속적인 증가로 인해 소프트웨어에 적용되는 IV&V에 대한 수요가 증가했습니다.

한편 IV&V(및 소프트웨어 시스템용 ISVV)가 통합되어 현재는 DoD, FAA,[8] NASA[7], [9]ESA 등의 조직에서 널리 사용되고 있습니다.IV&V는 DO-178B, ISO/IEC 12207에 기재되어 있으며 IEEE 1012에 공식화되어 있다.

ESA에서

2004-2005년, 유럽 우주국이 주도하고 DNV, Critical Software SA, Terma 및 CODA SciSys plc에 의해 구성된 유럽 컨소시엄은 다른 [10]기관의 지원을 받아 ISVV에 전념하는 "ESA Guide for Independent Verification and Validation"이라는 가이드의 첫 버전을 만들었습니다.이 가이드에서는 ISVV와 관련된 모든 소프트웨어 엔지니어링 단계에 적용할 수 있는 방법에 대해 설명합니다.

2008년 유럽우주국은 여러 유럽 우주 ISVV [10]이해관계자들로부터 입력을 받은 두 번째 버전을 출시했다.

방법론

ISVV는 보통 5개의 주요 단계로 구성됩니다.이러한 단계는 순차적으로 또는 맞춤 프로세스의 결과로 실행될 수 있습니다.

계획.

  • ISVV 활동 계획
  • 시스템 중요도 분석:일련의 RAM 액티비티를 통한 중요 컴포넌트 특정(Value for Money)
  • 적절한 방법 및 도구 선택

요건 검증

  • 검증: 완전성, 정확성, 테스트 가능성

설계 검증

  • 소프트웨어의 요건과 인터페이스에 대한 설계의 적절성과 적합성
  • 내부 및 외부 일관성
  • 타당성 및 유지관리 검증

코드 검증

  • 검증: 완전성, 정확성, 일관성
  • 코드 메트릭스 분석
  • 코딩 표준 컴플라이언스 검증

확인

  • 불안정한 컴포넌트/기능 식별
  • 오류 처리에 초점을 맞춘 검증: 개발 팀이 수행한 검증에 대한 보완적(동시적이지 않음) 검증
  • 소프트웨어 및 시스템 요건 준수
  • 블랙박스 테스트 및 화이트박스 테스트 기술
  • 경험 기반 기술

규제 환경

소프트웨어는 종종 정부 기관이나[11][12] 산업 행정 당국에 의해 유도되는 법적 규제를 받는 업계의 컴플라이언스 요건을 충족해야 합니다.예를 들어 FDA는 소프트웨어 버전과 패치를 검증할 [13]것을 요구합니다.

「 」를 참조해 주세요.

추가 정보

  • 1012-2012 IEEE Standard for System and Software Verification and Validation. 2012. doi:10.1109/IEEESTD.2012.6204026. ISBN 978-0-7381-7268-2.
  • Tran, E. (1999). "Verification/Validation/Certification". In Koopman, P. (ed.). Topics in Dependable Embedded Systems. Carnegie Mellon University. Retrieved 2007-05-18.
  • Menzies, T.; Y. Hu (2003). "Data mining for very busy people". Computer. 36 (1): 22–29. doi:10.1109/MC.2003.1244531.

외부 링크

레퍼런스

  1. ^ Pham, H. (1999). Software Reliability. John Wiley & Sons, Inc. p. 567. ISBN 9813083840. Software Validation. The process of ensuring that the software is performing the right process. Software Verification. The process of ensuring that the software is performing the process right." Likewise and also there: "In short, Boehm (3) expressed the difference between the software verification and software validation as follows: Verification: ‘‘Are we building the product right?’’ Validation: ‘‘Are we building the right product?’’.
  2. ^ "CMMI for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1, Staged)". resources.sei.cmu.edu. Retrieved 2021-03-20.
  3. ^ a b c "Department of Defense Documentation of Verification, Validation & Accreditation (VV&A) for Models and Simulations". Missile Defense Agency. 2008. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  4. ^ Rogers, R. (1981-10-26). "Planning for independent software verification and validation". 3rd Computers in Aerospace Conference. San Diego,CA,U.S.A.: American Institute of Aeronautics and Astronautics. doi:10.2514/6.1981-2100.
  5. ^ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (2008-05-12). "A Independent Software Verification and Validation Process for Space Applications". SpaceOps 2008 Conference. Heidelberg, Germany: American Institute of Aeronautics and Astronautics. doi:10.2514/6.2008-3517. ISBN 978-1-62410-167-0.
  6. ^ Lewis, Robert O. (1992). Independent verification and validation : a life cycle engineering process for quality software. New York: Wiley. ISBN 0-471-57011-7. OCLC 74908695.
  7. ^ a b Asbury, Michael (2015-03-09). "About NASA's IV&V Program". NASA. Retrieved 2021-03-20.
  8. ^ Balci, O. (2010). "Golden Rules of Verification, Validation, Testing, and Certification of Modeling and Simulation Applications". S2CID 61476570. Retrieved 2021-03-20.
  9. ^ "Flight Software Systems Section (TEC-SWF)". www.esa.int. Retrieved 2021-03-20.
  10. ^ a b lavva.pt. "New ISVV Guide for Space in the Works". www.criticalsoftware.com. Retrieved 2021-03-20.
  11. ^ "General Principles of Software validation; Final Guidance for Industry and FDA Staff" (PDF). Food and Drug Administration. 11 January 2002. Retrieved 12 July 2009.
  12. ^ "Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application" (PDF). Food and Drug Administration. August 2003. Retrieved 12 July 2009.
  13. ^ "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the Shelf (OTS) Software" (PDF). Food and Drug Administration. 14 January 2005. Retrieved 12 July 2009.