**DO-178B (항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항)**는 RTCA 사에 의해 발표된 소프트웨어 개발 표준이다. 이 표준은 RTCA SC-167과 EUROCAE WG-12에 의해 개발되었고, 이를 미국 연방 항공국(FAA)이 항공기 소프트웨어 인증을 위한 용도로 사용할 것을 인정하여 현재 업계에서 상용 항공기이 탑재되는 safety-critical 소프트웨어를 위한 사실 상의(de facto) 표준으로 자리잡았다..

소프트웨어 레벨
--------

안전 평가 프로세스(safety assessment process), 위험도 분석(hazard analysis)으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준으로 삼는 것으로 다음과 같은 단계가 있다.

* Catastrophic - 추락의 위험을 갖는 고장 위험 수준
* Hazardous - 성능 또는 안전에 큰 부정적인 요소를 갖거나 물리적인 변형 또는 과도한 업무 부하로 인해 조종사가 비행을 유지할 수 없는 위험 수준
* Major - 심각한 수준이지만 위험한 상태는 아님( 예를 들어 승객이 다치는 것보다 불편한 상태)
* Minor - 고장 상태가 보이지만 Major 상태보다는 덜한 상태 수준(예를 들어 승객에게 불편을 초래하거나 비행 경로를 변경하는 상태)
* No Effect - 안전, 비행 조정 또는 조종사 과부하에 영향을 미치지 않은 고장 수준

위와 같은 소프트웨어 레벨에 따라 만족시켜야할 요건의 수와 독립성 수준이 정해진다. 표준에 따르면, "독립성"이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어 있어야 한다는 의미이다..

| **레벨** | **고장영향성** | **만족요건의 수** | **독립성 만족요건의 수** |
| --- | --- | --- | --- |
| 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 FAA with EASA, JAA or CAA
* Replace FAR with JAR or CS
* Replace AC with AMJ

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

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