{{위키데이터 속성 추적}}
'''DO-178B (항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항)'''는 [[RTCA]] 사에 의해 발표된 소프트웨어 개발 표준이다. 이 표준은 [[RTCA]] SC-167과 [[EUROCAE]] WG-12에 의해 개발되었고, 이를 [[미국 연방 항공국]](FAA)이 항공기 소프트웨어 인증을 위한 용도로 사용할 것을 인정하여 현재 업계에서 상용 항공기이 탑재되는 safety-critical 소프트웨어를 위한 사실 상의(de facto) 표준으로 자리잡았다.<ref>FAA 권고(Advisory Circular) 20-115B</ref>.

== 소프트웨어 레벨 ==
[[안전 평가 프로세스]](safety assessment process), [[위험도 분석]](hazard analysis)으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준으로 삼는 것으로 다음과 같은 단계가 있다.
* Catastrophic - 추락의 위험을 갖는 고장 위험 수준
* Hazardous - 성능 또는 안전에 큰 부정적인 요소를 갖거나 물리적인 변형 또는 과도한 업무 부하로 인해 조종사가 비행을 유지할 수 없는 위험 수준
* Major - 심각한 수준이지만 위험한 상태는 아님( 예를 들어 승객이 다치는 것보다 불편한 상태)
* Minor - 고장 상태가 보이지만 Major 상태보다는 덜한 상태 수준(예를 들어 승객에게 불편을 초래하거나 비행 경로를 변경하는 상태)
* No Effect - 안전, 비행 조정 또는 조종사 과부하에 영향을 미치지 않은 고장 수준

위와 같은 소프트웨어 레벨에 따라 만족시켜야할 요건의 수와 독립성 수준이 정해진다. 표준에 따르면, "독립성"이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어 있어야 한다는 의미이다.<ref>RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification", p.82</ref>.

{| class="wikitable" style="margin: auto;"
! '''레벨'''
! '''고장영향성'''
! '''만족요건의 수'''
! '''독립성 만족요건의 수'''
|-
! A
| Catastrophic
| 66
| 25
|-
! B
| Hazardous
| 65
| 14
|-
! C
| Major
| 58
| 2
|-
! D
| Minor
| 28
| 2
|-
! E
| No effect
| 0
| 0
|}

== 프로세스와 문서들 ==

소프트웨어 레벨(A에서 D까지, E의 경우에는 DO-178B 상 요건이 없음)에 따른 목표를 만족시키기 위해서는 프로세스가 필요하다. DO-178B에서 프로세스 자체가 구체적으로 명확히 기술되어 있지 않으며 추상적인 수준으로 기술되어 있고, 이를 구체적인 실제 프로젝트에서 실행하는 방법에 대해서는 각 프로젝트 계획 단계에서 이를 계획하도록 되어 있다. 그러므로 실제 프로젝트에서는 구체적인 프로세스를 만족시킨다기보다는 DO-178B의 각각의 요건(objectives)을 만족시키기 위한 활동들이 진행된다. 그리고 사실 그러한 활동이 계획 단계에서 계획된다.

=== 기획 프로세스 ===

이 프로세스의 결과물들은 다음과 같다.

* 소프트웨어 인증 계획서(Plan for software aspects of certification: PSAC)
* 소프트웨어 개발 계획서(Software development plan: SDP)
* 소프트웨어 검증 계획서(Software verification plan: SVP)
* 소프트웨어 형상관리 계획서(Software configuration management plan: SCMP)
* 소프트웨어 품질보증 계획서(Software quality assurance plan: SQAP)
* 시스템 요구사항(System requirements)
* 소프트웨어 요구사항 표준서(Software requirements standard: SRS)
* 소프트웨어 설계 표준서(Software design standard: SDS)
* 소프트웨어 코딩 표준서(Software code standard: SCS)

위에서 시스템 요구사항은 전체 프로젝트의 시작을 위한 일반적인 입력 요구조건이다. 그리고 마지막 세개의 표준서 결과물은 레벨 D에 해당하는 소프트웨어에는 요구되지 않는다.

=== 개발 프로세스 ===
이 프로세스는 여러 개의 하위 프로세스로 나눌 수 있다.
* 요구사항 분석
* 설계
* 코딩(구현)
* 통합

개발 프로세스의 산출물은 다음과 같다.
* 소프트웨어 요구사항 데이터 (Software requirements data, SRD)
* 소프트웨어 설계 기술서 (Software design description, SDD)
* 소스코드
* 실행가능한 오브젝트 코드

개발시 일반적으로 시스템 요구사항에서 모든 소스 코드 또는 실행가능한 오브젝트 코드로의 추적성이 요구된다.
(요구 수준은 소프트웨어 레벨에 따라 다소 차이가 있다)

일반적으로 적용되는 [[소프트웨어 개발 프로세스]]는 다음과 같다.
* [[폭포수 모델]] (waterfall model)
* [[나선형 모델]] (spiral model)
* [[V 모델]] (V model)

=== 통합 프로세스 ===
검증, 형상관리, 품질보증, 인증지원으로 이루어져 있다.

=== 검증 프로세스 ===

이 프로세스에서 산출되는 문서는 다음과 같다.
* 소프트웨어 시험 절차서 (Software verification cases and procedures, SVCP)
* 소프트웨어 시험 결과서 (Software verification results, SVR)
** 모든 요구사항, 설계, 코드에 대한 검토 결과
** 모든 실행 오브젝트에 대한 시험 결과
** [[코드 커버리지]] 분석 결과

이 프로세스를 완료하기 위해서는 모든 코드에 대한 검토 분석 결과와, 시험 및 시험 결과로부터 요구사항으로의 추적성 요건 만족이 일반적으로 요구된다. (소프트웨어 레벨에 따라 요건의 수준은 다소 상이할 수 있음.)

이 프로세스에서는 일반적으로 다음과 같은 도구들을 적용하게 된다.
* 요구사항 기반의 소프트웨어 시험 도구
* 코드 커버리지 분석 도구

또한 이 프로세스 내에서 다음과 같은 시험이 수행될 수 있다.
* 단위 시험
* 통합 시험
* 블랙 박스(black box) 및 수락 시험

=== 형상 관리 프로세스 ===

[[형상 관리]] (Configuration Management) 프로세스를 통해 관리, 유지되는 문서들은 다음과 같다.
* 소프트웨어 형상 색인 (Software configuration index, SCI)
* 소프트웨어 생명주기 환경 형상 색인 (Software life cycle environment configuration index, SECI)

이 프로세스를 통해 결함 보고 및 변경과 관련된 활동을 정의하고 통제한다. 형상 관리 프로세스는 일반적으로 다음과 같은 데이터를 보관하고 갱신하는 기능을 수행한다.
* 소스 코드 개발 환경
* 기타 개발 환경 (예를 들어 시험 및 분석 도구)
* 소프트웨어 통합 도구
* 모든 산출 문서, 소프트웨어 및 하드웨어

=== 품질 보증 프로세스 ===

품질 보증 (quality assurance) 프로세스에 의한 산출 문서는 다음과 같다.
* 소프트웨어 품질 보증 기록 (Software quality assurance records, SQAR)
* 소프트웨어 적합성 검토 (Software conformity review, SCR)
* 소프트웨어 개발실적 요약서 (Software accomplishment summary, SAS)

이 프로세스를 통해 프로젝트 전반에 걸쳐 DO-178B 적합성에 대한 검토(review)와 감사(audit)를 수행한다. 또한 DO-178B 인증 기관인 FAA 또는 이를 위임한 DER에 인증에 필요한 데이터를 제공하는 등의 연결 역할을 수행한다.

=== 인증 절차 프로세스 ===

일반적으로 미 항공국에서 그 권한을 위임받은 DER (Designated Engineering Representative)이 항공기 제조사 내에 고용되어 인증 절차를 진행한다.

== 유럽에서의 항공용 소프트웨어 인증 ==

* Replace [[Federal Aviation Administration|FAA]] with [[European Aviation Safety Agency|EASA]], [[Joint Aviation Authorities|JAA]] or [[Civil Aviation Authority|CAA]]
* Replace [[Federal Aviation Regulations|FAR]] with JAR or CS
* Replace AC with AMJ

== 도구 인증(Tool Qualification) ==

소프트웨어 도구를 사용하면 DO-178B가 요구하는 프로세스를 자동화하고 관리하며 쉽게 적용할 수 있다. DO-178B 기반의 개발 프로젝트에 사용되는 모든 소프트웨어 도구는 인증 프로세스의 부분이다. 따라서 코드를 자동으로 생성하는 개발 도구는 소스 코드와 동일하게 그 개발 도구로서의 인증(qualification)을 보장해야한다. 이는 그러한 개발 도구가 생성한 코드가 최종 항공 시스템에 결함을 발생시킬 수 있기 때문이다. 단 해당 생성 코드에 대해 수동으로 독립적인 검토를 수행할 경우에는 인증 데이터(qualification data)를 제출할 의무는 사라진다. 또한 검증 프로세스에서 소스 코드를 시험/검증하기 위한 도구(시뮬레이터, 시험 실행 환경, 커버리지 분석 도구, 보고서 생성 도구 등)은 대개 소스 코드 자체에 결함을 발생시킬 위험은 낮다. 따라서 검증 도구로서의 적격 검토는 개발 도구의 요건보다는 가벼울 수 있으며, 도구에 대한 동작 요구사항(Tool Operational Requirements) 정의와 그에 대한 시험을 통한 검증을 통해 데이터를 제출한다.

== 같이 보기 ==
* [[DO-254]](DO-178B와 유사한 항공기 하드웨어 인증에 대한 표준)
* [[DO-248B]](DO-178B의 모호함을 보완하여 명확화하기 위한 최종 보고서, 오타 및 오기, 주요 이슈에 대한 추가 설명 등이 포함됨)
* [[ARINC-653]](항공용 소프트웨어의 응용시 인터페이스 표준화 및 파티셔닝 정의)
* [[항공용 소프트웨어]]
* [[ARP4761]] (안전 평가 프로세스 정의)
* [[ARP4754]] (시스템 개발 프로세스 정의)
* [[요구사항 관리]]
* [[IEC61508]]

== 각주 ==
<references/>

== 외부 링크 ==
* [https://web.archive.org/web/20080827171956/http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/50bfe03b65af9ea3862569d100733174/$FILE/AC25.1309-1A.pdf AC 25.1309-1A]
* [https://web.archive.org/web/20080827165642/http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/0/dcdb1d2031b19791862569ae007833e7/$FILE/AC20-115B.pdf AC 20-115B]
* [https://web.archive.org/web/20080827173536/http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgOrders.nsf/0/640711b7b75dd3d486256d3c006f034f/$FILE/Order8110.49.pdf FAA Order 8110.49]

[[분류:RTCA 규격]]
[[분류:컴퓨터 표준]]
[[분류:소프트웨어 요구사항]]