ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 5.5 구현 검증
    잡談/ARP4754A 기본 2023. 8. 14. 13:28

    검증(Verification)의 목적은 구현의 각 레벨이 지정된 요구사항을 충족하는지 확인하는 것이다.

     

    검증 프로세스는 시스템 구현이 확인된 요구사항을 충족하는지 확인한다. 검증은 검증 계획에 따라 적용되는 조사, 리뷰, 분석, 테스트 그리고 서비스 경험으로 구성된다. 이러한 활동들은 이어지는 단락에서 설명된다.

     

    5.5.1. 검증 프로세스 목표

     

    검증 프로세스는:

     

    a. 의도된 기능이 올바르게 구현되었는지 확인한다.

    b. 요구사항이 충족되었는지 확인한다. (항공기를 올바로 제작했는가?)

    c. 안전성 분석이 구현된 시스템에 대해서 유효하게 유지되도록 보장한다.

     

    5.5.2. 검증 프로세스 모델

     

    그림 13은 시스템 구현의 각 레벨에서 검증을 위한 일반적인 프로세스 모델의 개요를 보여준다.

     

    그림 13 검증 프로세스 모델

     

    검증 프로세스는 다음과 같이 세 가지 요소로 구성된다.

     

    a. 계획: 필요한 리소스에 대한 계획, 활동 순서, 생성할 데이터, 필요한 정보의 수집, 특정 활동 및 평가 기준의 선택, 검증용 하드웨어 혹은 소프트웨어의 생성이 포함된다. (5.5.3 참조)

    b. 방법: 검증 방법이 적용되는 활동을 포함한다. (5.5.5 참조)

    c. 데이터: 프로세스에서 개발되는 결과의 증거를 포함한다. (5.5.6 참조)

     

    검증 수준은 FDAL과 IDAL에 의해서 결정된다. (5.5.3 참조)

     

    검증 프로세스에 대한 입력에는 구현된 항공기, 시스템 혹은 아이템에 대한 일련의 문서화된 요구사항과 검증될 시스템 혹은 아이템에 대한 완전한 설명이 포함된다.

     

    요구사항 준수를 입증하기 위해 두 가지 이상의 검증 방법이 필요할 수 있다. 예를 들어, 워스트 케이스가 다루어졌는지 확인하기 위해 물리적인 테스트와 함께 분석이 필요할 수 있다.

     

    의도된 기능을 검증하는 과정에서 인식된 모든 이상(의도되지 않은 기능 혹은 부정확한 성능과 같은)은 리뷰되고 처리될 수 있도록 보고되어야 한다. 검증 프로세스, 설계 구현 프로세스 혹은 요구사항 정의 프로세스를 체크하여 이상을 식별할 수 있다.

     

    검증은 개발 프로세스의 반복적인 특성으로 인해 설계 프로세스 중에 반복적으로 나타날 수 있는 프로세스임을 언급해야 한다. (섹션 4.2의 그림 6 “항공기 기능 구현 프로세스” 참조)

     

    5.5.3. 검증 엄격성

     

    검증 엄격성의 수준은 항공기 혹은 시스템에 대한 기능 개발 보증 레벨(들)(FDAL)과 아이템에 대한 아이템 개발 보증 레벨(들)(IDAL)에 의해서 결정된다. 개발 보증 레벨에 상응하는 추가 검증 엄격성 즉. 독립성은 섹션 4.6의 항공기 혹은 시스템 설계 구현과 섹션 5.5의 검증 활동 사이에 적용될 필요가 있다. 검증에서 독립성을 달성하는 가장 일반적인 방법은 섹션 5.5.5에 설명된 검증 방법을 독립적으로 개발하는 것이다. (예를 들어 항공기 혹은 시스템 설계에 관여하지 않은 개인 혹은 그룹이 검증 방법을 생성한다) 검증 계획(5.5.4 참조)에는 독립성이 적용되는 검증 활동에 대한 설명이 포함되어야 한다. 부록 A는 개발 보증 레벨에 적합한 특정 검증 목표를 강조한다.

     

    5.5.4. 검증 계획

     

    이 단계의 목적은 구현이 요구사항을 충족하는 방법을 보여줄 때 적용할 프로세스와 기준을 정의하는 것이다. 다음의 활동들이 계획 단계에서 수행되어야 한다.

     

    a. 검증 활동 수행과 관련된 역할 및 책임의 식별 그리고 설계 및 검증 활동 간의 독립성에 대한 설명

    b. 특수 테스트 장비, 시설 그리고 검사할 특수 하드웨어 혹은 소프트웨어 특징의 정의를 포함하여 시스템 혹은 아이템 구성의 식별

    c. 개발 보증 레벨을 기반으로 각 요구사항의 준수를 보여주기 위해 사용할 특정 검증 방법의 정의

    d. 적용된 각 검증 방법에서 비롯된 증거를 평가하는 데 사용되는 기준의 정의 (즉 성공 기준)

    e. 하드웨어 혹은 소프트웨어 검증 활동에서 얻게 되는 시스템 검증 신뢰의 식별

    f. 주요 검증 활동 및 종속 활동의 순서 식별

    g. 검증 데이터의 식별

     

    5.5.5. 검증 방법

     

    이러한 활동의 목적은 구현이 의도된 운영 환경을 포함해서 요구사항을 충족하는지 확인하는 것이다. 다음의 네 가지 방법이 항공기 및 모든 시스템 혹은 아이템의 검증에 사용될 수 있다.

     

    a. 조사 혹은 리뷰

    b. 분석

    c. 테스트 혹은 시연

    d. 서비스 경험

     

    이러한 각각의 방법은 이어지는 단락에서 설명된다.

     

    5.5.5.1 조사 혹은 리뷰

     

    조사 혹은 리뷰는 요구사항이 충족되었는지 검증하기 위한 프로세스 문서, 도면, 하드웨어 혹은 소프트웨어의 육안 검사로 구성된다. 일반적으로 체크리스트 혹은 이와 유사한 보조 도구가 사용된다. 시스템 혹은 아이템이 확립된 물리적 구현 및 숙련도를 충족하는지에 대한 조사는 전형적인 조사/리뷰의 유형이다.

     

    5.5.5.2 분석

     

    분석은 시스템 혹은 아이템에 대한 자세한 검사(예: 기능, 성능, 안전성)를 수행하여 준수의 증거를 제공한다. 시스템 혹은 아이템이 정상 및 비정상 조건에서 어떻게 수행될 것으로 예상되는지에 대한 평가가 포함되어야 한다. 분석 방법은 이어지는 단락에서 설명되는 방법이 포함될 수 있으며 이에 국한되지는 않는다.

     

    5.5.5.3 모델링

     

    복잡한 시스템의 모델링은 일반적으로 계산과 테스트의 조합으로 구성된다. 하지만 결정론적 시스템 동작을 모델링하는 것은 전적으로 계산적일 수도 있다. 모델링은 초기 시스템 정보 제공 혹은 다른 목적으로 시스템 파라미터 평가에 사용될 수 있다.

     

    5.5.5.3.1 커버리지 분석

     

    커버리지 분석은 개발 및 검증 활동 전반에 걸쳐 요구사항이 해결되는 정도를 결정하기 위해 수행된다. 이것은 일반적으로 추적성의 형태를 사용해서 구현된다.

     

    5.5.5.4 테스트 혹은 시연

     

    테스트는 요구사항이 충족되는지 검증하기 위해 시스템 혹은 아이템을 실행하여 정확성에 대한 반복 가능한 증거를 제공한다. 테스트 준비 리뷰는 시스템 혹은 아이템 요구사항에 대한 테스트 케이스의 적용가능성을 확립한다. 테스트는 다음의 두 가지 목표를 가진다.

     

    a. 시스템 혹은 아이템 구현이 의도된 기능을 수행함을 입증하는 것. 의도된 기능에 대한 테스트는 요구사항에 의해서 설정된 목표의 PASS/FAIL 기준에 대한 평가가 포함된다.

    b. 구현된 시스템이 안전성에 영향을 미치는 의도되지 않은 기능(즉, 의도적인 설계의 일부가 아님)을 수행하지 않는다는 확신을 제공하는 것. 의도되지 않은 시스템 혹은 아이템 작동이나 사이드이펙트를 식별하는 데에 임시 테스트 그리고 일반 테스트 중 특별한 경계가 사용될 수 있다.

     

    테스트는 제2자(second party)가 테스트 결과를 재현할 수 있도록 충분히 상세하게 문서화된 절차를 사용하여 물리적 시스템 혹은 아이템이나 적절히 확인된 모델의 전체 혹은 일부에서 수행된다. 테스트 중에 발견되는 문제점은 보고하고, 수정 조치를 추적하며 변경된 시스템(들) 그리고/혹은 아이템(들)을 다시 테스트해야 한다.

     

    각각의 테스트 혹은 테스트 그룹에 대해 다음이 지정되어야 한다.

     

    a. 테스트 기준 설정에 고려되어야 하는 필요한 입력 변동성

    b. 시간에 종속적인 경우 필요한 작업 및 작업 순서

    c. 테스트(들)의 목적 혹은 근거

    d. 테스트(들)에 의해 커버되는 요구사항

    e. 예상 결과 및 해당 결과와 관련된 허용 오차

     

    테스트 결과 데이터는 다음을 포함해야 한다.

     

    a. 사용된 테스트 규격의 버전

    b. 테스트되는 시스템 혹은 아이템의 버전

    c. 해당되는 캘리브레이션 데이터와 함께, 사용되는 도구 및 장비에 대한 버전 혹은 참조 표준

    d. PASS 혹은 FAIL 선언을 포함한 각각의 테스트 결과

    e. 예상 결과와 실제 결과 사이의 차이점

    f. 검증 프로그램과의 관계를 포함해서 테스트 성공 혹은 실패에 대한 선언

     

    5.5.5.4.1 테스트 시설

     

    부정확하거나 의도되지 않은 기능을 탐지할 확률을 향상시키는 다음과 같은 기능성이 시스템 테스트 시설에 제공될 수 있다.

     

    a. 테스트용 하드웨어 및 소프트웨어가 해당 시설 및 대응하는 소프트웨어와 하드웨어에 존재한다.

    b. 환경 모델은 사용자 컨트롤 입력 표현을 사용하여 실제 서비스를 대표하는 방식으로 테스트 중인 시스템에 입력을 설정하는 데 사용할 수 있다.

    c. 환경 모델은 테스트 중인 시스템의 출력을 수신하고 높은 수준의 요구사항 측면에서 시스템 동작을 계산 및 표시할 수 있다.

    d. 테스트 중인 시스템의 동작이 높은 수준의 매개변수 측면에서 명확하게 표시된다.

    e. 높은 수준의 수동 입력이 회귀 테스트를 용이하게 하기 위해 반복 가능하게 만들어진다.

    f. 실패 혹은 경고 메시지와 같은 중요한 이벤트와 높은 수준의 요구사항을 충족하지 못하는 실패가 고지되고 기록된다.

     

    위와 같은 기능성 제공은 매우 높은 생산성으로 테스트 결과를 생성하고 결과를 해석하는 모델을 사용하여 위험 감소를 위한 개발 테스트를 가능하게 하며 예기치 않은 결과를 만들어 낼 수 있는 관리 가능한 수단을 사용할 수 있게 한다.

     

    5.5.5.5 유사성/서비스 경험

     

    검증 신뢰는 설계 및 설치 평가 그리고 관련 속성이 유사한 동일하거나 다른 시스템을 사용하는 다른 항공기에서의 만족스러운 서비스 경험의 증거에서 파생될 수 있다. 이 방법은 이러한 설치에서 해결되지 않은 심각한 고장이 없음을 입증하기 위해 엔지니어링 및 운영 판단과 함께 문서화된 경험을 사용해야 한다. 더 자세한 내용은 섹션 6.5를 참조한다.

     

    5.5.5.6 추천되는 검증 방법

     

    표 7은 개발 보증 레벨의 기능에 따른 다양한 권장되는 그리고 허용되는 검증 방법과 데이터를 나열하고 있다. 이러한 방법 및 데이터와 관련되는 필요한 범위 및 커버리지 또한 개발 보증 레벨에 따라 달라지며, 알려진 경우에는 특정 관련 결함 조건에 의해 조금 더 영향을 받을 수 있다.

     

    예를 들어, 레벨 A 혹은 레벨 B로 검증되는 구현은 조사 혹은 리뷰 그리고 분석을 포함할 수 있으며 어떤 형태의 테스트를 포함해야 한다. 각각의 방법이 적용되는 정도 혹은 개발되는 데이터의 범위는 인증될 특정 시스템을 기반으로 한 인증 당국과의 합의 결과가 될 것이다.

     

    표 7 검증 방법 및 데이터

    참고: R - 인증을 위해 추천됨, A- 인증을 위해 협의된 대로, N-인증에 필요하지 않음

    참고 1: 이러한 방법들은 유사한 수준의 검증을 제공한다. 가장 유용한 방법의 선택은 특정 시스템 아키텍처 혹은 구현된 특정 기능(들)에 따라 달라질 수 있다. DO-178B/ED-12B 그리고 DO-254/ED-80은 IDAL에 따라 소프트웨어 그리고 하드웨어에 대한 적용가능한 테스트를 정의한다.

     

    참고 2: 설치 및 환경 호환성을 보여주기 위해 필요한 경우.

     

    참고 3: ASA/SSA 리포트(섹션 5.1)는 검증 프로세스의 세 번째 목표(섹션 5.5.1)와 직접 관련이 있으므로 이 표에 포함된다.

     

     

    5.5.6. 검증 데이터

     

    검증 데이터의 목적은 검증 프로세스가 수행되었다는 증거를 제공하는 것이다. 이 증거는 표 7에 따른 준수 입증 및 인증 데이터 요구사항을 뒷받침하기 위해 필요할 수 있다. 합리적인 접근법은 개발 중에 검증 매트릭스를 유지하고 검증 요약 리포트를 작성하는 것이다.

     

    소프트웨어 검증에 대한 요구사항은 DO-178B/ED-12B에 포함되어 있고 전자 하드웨어 검증에 대한 요구사항은 DO-254/ED-80에 포함되어 있다. 소프트웨어 그리고 하드웨어 검증의 요약은 그것이 내장된 시스템의 검증 데이터에 포함되어야 한다.

     

    5.5.6.1 검증 계획

     

    검증 계획은 항공기 및 시스템 구현이 요구사항을 어떻게 충족하는지를 보여주는 전략을 수립한다. 일반적인 검증 계획에는 다음이 포함될 수 있다.

     

    a. 검증 활동 수행과 관련된 역할 및 책임

    b. 설계 및 검증 활동의 독립성 정도에 대한 설명

    c. 검증 방법(들)의 적용

    d. 생성될 검증 데이터

    e. 종속된 활동의 순서

    f. 핵심 검증 활동의 일정

    g. 아이템(하드웨어 혹은 소프트웨어) 검증 활동에서 얻게 되는 시스템 검증 신뢰의 식별

     

    또한 검증 프로세스의 일부 측면은 특정 요구사항의 확인을 지원할 수 있으며 확인 계획과 조정되어야 한다.

     

    5.5.6.2 검증 절차 및 결과

     

    달성된 결과와 함께 검증 절차를 설명하는 데이터는 검증 노력의 적절성을 확립하는 데 필요한 증거를 제공한다.

     

    5.5.6.3 검증 매트릭스

     

    검증 프로세스의 상태를 추적하기 위해 검증 매트릭스 혹은 이에 상응하는 추적 문서를 생성해야 한다. 이 매트릭스의 상세화 수준은 검증되는 시스템 혹은 아이템의 개발 보증 레벨에 따라 달라야 한다. 구체적인 형식은 지원자에 의해서 결정될 수 있지만 최소한 다음을 포함해야 한다.

     

    a. 요구사항

    b. 관련된 기능

    c. 적용되는 검증 방법

    d. 검증 절차 및 결과 참조(들)

    e. 검증 결론 (즉, PASS 혹은 FAIL, 검증 커버리지 요약)

     

    5.5.6.4 검증 요약

     

    검증 요약은 항공기, 시스템 혹은 아이템 구현이 요구사항을 충족한다는 것을 보여주는 데 사용되는 증거에 대한 가시성을 제공한다. 요약은 다음을 포함해야 한다.

     

    a. 검증 계획에 대한 참조 및 계획과의 중요한 차이점에 대한 설명

    b. 할당된 개발 보증 레벨

    c. 섹션 5.5.6.3에 설명된 검증 매트릭스

    d. 오픈된 문제점 리포트에 대한 설명 및 안전성에 미치는 관련된 영향의 평가

    e. 지원 데이터 혹은 데이터 소스의 식별

    f. 검증 커버리지 요약

     

     

     

     

     

     

    '잡談 > ARP4754A 기본' 카테고리의 다른 글

    5.7 프로세스 보증  (0) 2023.08.14
    5.6. 형상 관리  (0) 2023.08.14
    5.4 요구사항 확인  (0) 2023.08.14
    5.3 요구사항 캡처  (0) 2023.08.14
    6. 항공기 혹은 시스템에 대한 변경  (0) 2023.08.14

    댓글

Designed by Tistory.