감항인증을 위한 DO-178C

항공용 SW개발 프로세스 컨설팅


감항인증을 위한 항공용 SW 안전성 국제 규격인 DO-178C Level A 기준에 따른

SW 개발 프로세스 구축 및 인증획득 지원 컨설팅을 수행합니다.




1. GAP 분석 및 개선사항 도출                                     


▶ GAP 분석 및 개선 전략 수립

- DO-178C 표준 프로세스 대비 고객의 현행 프로세스와의 GAP 분석

- 효과적인 GAP 감소를 위한 개선 전략 및 일정 수립에 대한 보고서 제공




2. 개선전략 수립 및 활동                                              


▶ 개발 프로세스 구축 및 활동 수행방안 제시

- GAP 분석 결과를 토대로 DO-178C에 따른 프로세스 구축

- 71개의 Objectives 달성을 위한 단계별 검증 활동 수행방안 제시

- 자동화 도구를 이용한 단계별 요구사항 추적성 확보방안


▶개발 단계별 시험환경 구축 및 시험방안 제시

- 구현 및 통합 시험단계를 위한 arget 시험환경 구축

- 시험 자동화 도구(LDRA)를 이용한 정적분석 및 동적시험 방안 제시


▶산출물 제공

- Level A의 71개 Objectives를 달성하기 위한 검토 체크리스트 제공

- 20여종의 전체 개발 단계 산출물 템플릿 제공




3. 프로세스 및 엔지니어링 교육                                    


▶ 감항인증을 위한 DO-178C 프로세스 교육

▶ 임베디드 프로그래밍 최적화 및 SW 테스트를 위한 엔지니어링 교육

▶ 고객 방문교육 및 사내 정기교육




4. 인증획득 지원                                                          


▶ DO-178C 기준의 인증심사 활동 지원

- FAA 인증심사원(DER) 보유

- FAA SOI)Stage Of Involvement)

  #1 ~ #4 체크리스트 기준으로 모의수행 지원

  (Planning, Development, Verification, Certification 단계 리뷰)


▶ 장비품의 기술표준폼 표준서(TSO) 지원

- TSO-C9 :  자동 조종 장치

- TSO-C129a : GPS를 이용한 탑재식 추가 항행 장치

- TSO-C112, TSO-C10b, TSC-C30c 등의 기술표준서 지원


▶DO-178C Tool Qualification Suppot Pack 지원

- SW 측면의 인증 계획서 (PSAC)

- Tool Qualification 계획서 (TQP)

- Tool 수행 완료 요약서 (TAS)



===========================================================================


컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141




DO-331 규격 소개

 

1. DO-331 개요

항공분야 소프트웨어와 관련된 개발 표준으로는 RTCA에서 제정한 DO-178C DO-278A가 있다. 항공기에 탑재되는 소프트웨어에 대한 개발 표준은 DO-178C인 반면, 지상용 항공장비에 탑재되는 소프트웨어를 위한 개발 표준은 DO-278A이다.

포스팅에서 소개하고자 하는 DO-331DO-178CDO-278A 규격의 모델 기반 개발 및 검증을 위한 보충 문서이며, DO-178C 규격을 기준으로 설명한다.

DO-331에는 DO-178C를 위한 모델기반 개발 및 검증을 위해 해결해야 하는 목표(objectives), 활동(activities), 설명 텍스트(explanatory text), 소프트웨어 라이프 사이클 데이터가 포함되어 있다.

DO-178C DO-331 모델 기반 설계 사용자에게 있어 DO-178B의 오래된 문제는, DO-178B 목표를 모델 기반 설계 아티팩트(artifact)에 매핑(mapping)할 때의 불확실성이다. 이러한 매핑 문제를 해결하는 것이 모델 기반 설계에 중점을 둔 DO-178C 서브그룹(SG-4)의 주요 목표였다. 단일 매핑으로는 충분하지 않았기에 DO-331에서는 몇 가지 매핑을 추가적으로 제공했다. 일부는 설계와 코드 생성에 사용된 것과는 별개인 사양의 모델 개념을 포함하기도 한다. 이 외 또 다른 개념은, 코드 생성에 사용되는 상세한 요구사항 역할을 하는 설계 모델이다. 이렇듯 설계(시스템 및/또는 소프트웨어)에 모델을 사용할 수 있고 모델 외부의 요구사항을 사용하여 개발해야 한다.

소스 코드는 설계 모델에서 직접 생성할 수 있다(자동 또는 수동). 이 표준에서 언급한 접근 방식 중 하나는 시스템 설계에 처음 사용한 모델을 가공하여 소프트웨어 설계 및 코드 생성에 재사용하는 것이다. 이 방법은 모델 기반 설계를 사용하는 UAV 시스템 및 소프트웨어 개발자를 위해 ARP 4754DO-178C를 매우 자연스럽게 연결한다.

 

2. 모델 기반 개발 및 검증의 특성(Characteristics of Model-Based Development and Verification)

소프트웨어 개발 및 검증 프로세스의 일부로서, 모델은 부분적으로 또는 완전히 소프트웨어 요구사항 또는 아키텍처를 나타낼 수 있다.

모델링 기법에 의해 모델들은 특징지어지고 소프트웨어 생명주기를 나타내는데 사용된다. 모델링 기법은 모델링 언어와, 모델링 언어를 사용하는 특정 방법의 결합이다. 정확하고 완전한 소프트웨어 수명주기 데이터의 특정 유형을 표현하는 모델능력은 사용모델링 기법에 의존한다. 사용 모델링 기술은 유형과 모델에 의해 표현되는 정보의 추상화 수준에 적합해야 한다. 소프트웨어 모델 표준모델링 기법은, 설명하고 이 기술을 목적에 맞는 방법의 시범을 지원하는 수단이다.

 

3. 소프트웨어 시험(Software Testing)

DO-178C6.4절은 변경되지 않았으며 시뮬레이션 실행 가능한 오브젝트 코드 검증의 일부로서 사용되는 경우, 이 섹션 MB.6.8.2 DO-178C 6.4절 에 추가 적용된다.

 

4. 소프트웨어 검증 계획(Software Verification Plan)

소프트웨어 검증 계획(SVP)은 검증 절차의 설명과 소프트웨어의 검증 절차 목적을 만족하기 위해 사용되어야 한다.

 

5. 소프트웨어 코드 표준(Software Code Standards)

소프트웨어 코드 표준은 DO-178C11.8절은 변경하지 않으며 이를 적용한다.

 

6. 소프트웨어 검증 케이스와 과정 (Software Verification Cases and Procedures)

소프트웨어 검증 케이스와 과정이 어떻게 구현되는지 소프트웨어 인증 케이스 및 절차의 세부 사항으로, 세부내용은 아래와 같다:

- 검토와 분석과정 : 검토 또는 분석 방법의 범위와 깊이는 분석 방법 중 소프트웨어 인증 계획에 대한 설명에 추가하여 사용된다.

- 테스트 케이스 : 각 테스트 케이스의 목적, 입력, 조건, 예상된 결과는 테스트 커버리지와 통/실패의 기준이 된다.

- 테스트 절차 : 단계별 명령을 각 테스트 케이스가 어떻게 실행하는지, 어떻게 평가하는지, 테스트환경이 어떻게 사용되는지 확인한다.

- 시뮬레이션 케이스 : 시뮬레이션 케이스의 목적은 입력, 조건, 결과 값 기대, 그리고 통과/실패의 기준이 된다.

- 시뮬레이션 과정 : 단계별 명령을 시뮬레이션 케이스가 어떻게 실행되는지, 어떻게 시뮬레이션 결과가 평가되는지, 어떤 환경에서 사용되는지 확인한다.

 

7. 소프트웨어 검증 결과(Software Verification Results)

소프트웨어 검증결과는 소프트웨어 검증절차 진행을 통해 만들어진다. 소프트웨어 검증 결과는 다음 내용을 만족시켜야 한다.

- 각각의 검토, 분석, 시뮬레이션 그리고 테스트는 수행과정 동안의 성공 또는 실패 과정과  최종 성공/실패 결과를 나타낸다.

- 분석 시뮬레이션 또는 시험평가 구성항목, 모델, 소프트웨어 버전을 확인한다. 높은 수준의 요구사항, 낮은 수준의 요구사항 또는 소프트웨어 구조를 나타내는 모델을 이용한다면, 모델의 구성이 확인되어야 한다.

- 테스트의 결과, 시뮬레이션, 검토, 분석, 커버리지 분석, 추적분석 결과는 시뮬레이션을 지원하여 포함한다.

- 발견되는 불일치 문제를 기록하고 문제 보고를 통해 추적한다. 또한 증명은 소프트웨어 검증결과를 고려하는 소프트웨어 프로세스에 의해 공급된 시스템 프로세스를 평가하고 제공한다.

 

8. 소프트웨어 모델 표준(Software Model Standards)

소프트웨어 모델표준은 각각의 모델타입에 따른 모델링 기법에 의해 정의되며 모델링 기법에 대한 포함사항은 다음과 같다

- 메소드와 도구는 모델을 개발하기 위해 사용된다.

- 언어를 모델링 하는데 사용한다. 각각의 모델링 언어들은 모델 소프트웨어 생명주기 데이터의 종류에 대하여 문맥 구분과 의미를 정의하는 데이터를 참조한다. 이 모델링 언어의 일부 기능에 대해 사용을 제한할 수 있다.

- 모델링 언어와 툴의 사용을 위해 스타일 설명지침 및 복잡도를 제한한다. 예를 들어 명명규칙, 다이어그램 레이아웃, 허용요소, 중첩 레벨의 최대 수, 각 다이어그램 모델 요소의 최대 수, 레이어 구조의 최대수 등이다.

- 모델링 툴(예를 들어, 스케줄링 기법 또는 글로벌 데이터)과 모델 요소의 라이브러리 사용을 제한한다.

- 메소드는 요구사항과 기타 생명주기 간의 추적을 설정하기 위한 의미와 모델의 요구사항 범위를 설명하기 위해 사용된다.

- 메소드는 모델 및 시스템의 안정성평가 방법을 포함하여 시스템 프로세스에서 파생된 요구사항을 제공하기 위한 방법에 포함되어 파생된 요구사항을 확인하고 분리하는데 사용될 수 있다.

- 메소드는 시스템 안정성 평가 처리를 포함하여 시스템 프로세스에서 파생된 요구사항을 제공하고, 그 모델에서 파생된 요구사항의 정의와 확인을 위해 사용된다.

- 구체적 모델 또는 디자인 모델에 의해 표현되는 정보의 유형에 대한, 기술의 적합성에 대한 이론적 근거이다.

 

9. 툴 인증 요구(Tool Qualification is Needed)

이 문서의 프로세스는 제거, 감소, 또는 섹션 MB.6에 지정된 것으로 확인되는 (출력 없는) 소프트웨어 툴을 사용함으로써, 자동화 될 때 툴의 자격이 필요하다.

툴의 인증 절차의 목적은 도구가 제공하는 프로세스의 제거, 감소, 또는 자동화된 프로세스의 공급을 적어도 동등한 신뢰성을 제공한다는 것을 보장한다.

툴 인증 절차는 단일 툴, 툴 내의 도구, 또는 하나 이상의 기능의 집합에 적용 할 수 있다. 툴의 다양한 기능을 위해 툴의 기능 보호를 입증할 수 있다면 오직 그 기능들은 제거, 감소, 자동화된 소프트웨어의 생명주기 과정과 검증 되지 않은 결과는 자격이 필요하다. 보호는 도구 기능이 또 다른 도구의 기능에 악영향을 줄 수 없도록 안전한 메카니즘을 사용한다.

툴은 도구를 사용하는 의도가 시스템을 지원하는 인증의 소프트웨어 측면에 대한 계획에 언급된 특정 시스템에서 사용하기 위해 자격이 부여된다. 이전 시스템에서 규정한 툴이 다른 시스템에서 사용하기 위해 제안 되는 경우, 다른 시스템의 맥락에서 재 규정한다.

 

10. 툴 자격수준 결정(Determining the Tool Qualification Level)

DO-178C12.2.2절을 적용한다.

 

11. 툴 검증 과정(Tool Qualification Process)

DO-178C12.2.3절을 적용한다.

 


DO-178C 컨설팅 전문기업

(주)모아소프트

컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141



DO-178C란?  

 

1.    
DO-178C 개요

 

본 문서는 RTCA 특별위원회 205 (SC-205) EUROCAE 실무단 71 (WG-71)이 제작하고, 2011 12 13일에 RTCA 프로그램관리위원회 (PMC)에서 승인하였다.

                                                                            

RTCA는 비영리 기업으로 공익을 위해 항공학 및 항공기술, 항공전자시스템을 발전시키고, 연방 자문위원회로서 활동 및 당대의 항공 이슈에 대한 합의기반 권고사항을 개발한다.

RTCA의 목적은 다음을 포함하지만, 이에 한정되지는 않는다.

 

·         정부와 산업이 상호간의 목표와 책임을 충족할 수 있도록 도와 주는 방식으로 항공 시스템 사용자 공급자 기술 요건을 취합한다.

·         높은 안전성, 시스템 가용량, 효율성을 추구하는 항공이 직면하는 시스템의 기술적인 이슈에 대해 분석하고 해결책을 권장한다.

·         항공 지원 전자 시스템 장비에 대한 최소 운영 성능 표준의 개발을 포함하여, 사용자와 공급자 요구 사항을 충족하는 관련 기술용의 합의점을 개발한다.

·         국제 민간 항공 기구 국제 전기 통신 연합, 또 다른 국제 기구에 대한 적합한 기술 자료 개발 지원이 기반이 될 수 있다.

 

 

조직의 권고사항은 많은 연방 항공 관리 기술 표준 순서에 대한 기반뿐만 아니라, 정부 및 민간 부문 의사결정에 대한 기반으로써 자주 사용된다.

 

RTCA는 미국 정부의 공식 기관은 아니기 때문에, 권고사항들과 관련된 어떠한 문제들에 대해 법적인 관할권을 가지는 미국 정부 조직 또는 기관에 의해 공표되지 않는 경우에는 그 권고사항들은 공식 정부 정책의 성명으로써 간주되지 않을 수도 있다.

 

 

2.     소개

 

1980년대 초, 항공기 소프트웨어의 사용과 항공기 엔진 및 장비의 급격한 증가가 보고됨에 따라 감항 요건의 충족에 대한 산업에서 수용되는 지침의 필요성이 생겼다. DO-178"항공 시스템 및 장비 인증에서의 소프트웨어 고려사항"에 대한 필요를 충족시키기 위해 쓰여졌다.

 

지금의 경험에 비추어 개정된 본 문서는 항공 시스템 및 장비를 소프트웨어 방식으로 감항 요건을 준수하고 있는지를 일관된 방법으로 소프트웨어 신뢰도의 허용 수준을 결정하는 지침과 항공 커뮤니티를 제공한다. 또한 소프트웨어의 사용이 증가함에 따라 기술의 발전 및 경험을 본 문서를 통해 얻을 수 있도록 본 문서를 검토하고 개정한다.

부록 A는 본 문서의 배경을 제공한다.

 

 

3.     목적

 

본 문서의 목적은 감항 요건을 준수하는 안전성에 대한 신뢰 수준에 의도된 기능을 수행하는, 항공 시스템 및 장비 소프트웨어 제품에 대한 지침을 제공하는 것이다. 또한 지침이 포함되어 있다.

Ÿ   소프트웨어 수명주기의 목적(Objectives)

Ÿ   목표를 만족 시키기 위한 수단을 제공하는 활동

Ÿ   목표가 충족 되었는지는 알려주는 소프트웨어 수명주기 데이터 형태의 증거에 대한 설명

Ÿ   소프트웨어 레벨의 목표, 독립성, 소프트웨어 수명주기 데이터 및 제어 카테고리의 변경

Ÿ   어떤 응용에 적용 가능한 추가 고려사항(예를 들어 기존에 개발한 적 있는 소프트웨어)

Ÿ   용어사전에서 제공되는 용어의 정의

 

위 지침과 더불어, 독자의 이해를 돕기 위해 정보 지원이 제공된다.

 

 

4.     범위

 

본 문서에서는 항공기, 엔진, 프로펠러 및 지역별 보조 동력 장치에 사용되는 항공기 탑재 장비 및 시스템 소프트웨어의 제품 관련 인증에 대해 설명한다. 이러한 형태의 설명은 시스템 수명주기와 소프트웨어 수명주기의 관계가 인증 프로세스의 이해를 돕기 위함이다.

반면, 시스템의 안전성 평가 및 검증 프로세스를 포함한 시스템 수명주기 프로세스 또는 인증 프로세스에 대한 자세한 설명은 포함되어 있지 않다.

 

본 문서에 포함된 지침은 인증 과정에서 인증 기관의 관여 수준을 정의하거나 의미하는 것이 아니다. 인증 기관의 관여를 이해하기 위해 신청자는 적용되는 규칙과 관련된 인증 기관에서 발급된 지침문서를 참고해야 한다. 인증 문제는 오직 소프트웨어 수명주기와 관해서만 논의되기 때문에,​​ 소프트웨어의 결과의 운영적 측면에 대해서는 논의되지 않는다. 예를 들어, 사용자의 변경 데이터의 인증 부분은 본 문서에 해당되지 않는다.

 

또한, 본 문서에서는 펌웨어(Firmware) 정의는 하지 않는다. 펌웨어는 하드웨어 또는 소프트웨어로 분류되어야 하며, 적용 가능한 프로세스에 의해 처리되어야 한다. 본 문서는 시스템 정의, 기능들이 소프트웨어 또는 하드웨어에 할당된 것을 가정한다. 이 문서 외의 다른 문서는 하드웨어 구현에

할당된 기능의 개발 안전에 대한 지침을 제공한다. 본 문서는 소프트웨어에 할당된 기능에 대한 지침만을 제공한다.

 

Note: 이것은 시스템이 명시되고 기능 할당되는 시점에서 결정되기 위해 구현의 효율적인 방법 및 개발 보장을 허용한다. 모든 당사자는 할당이 이루어진 시점에서 이 시스템 결정에 동의해야 한다.

 

추가로, 청자의 조직 구조에 관한 사항이나 신청자와 그 공급업체 및 직원의 자격 기준 사이의 상업 관계는 본 문서의 범위에 해당되지 않는다.

 

5.     다른 문서와의 관계

 

항공 요건과 더불어, 소프트웨어에 대한 다양한 국내 및 국제 표준은 이용 가능하다. 일부 커뮤니티에서는 이러한 표준에 대한 적합성이 요구될 수 있다. 하지만 특정 국가 또는 국제 표준을 적용하는 것 또는 이러한 표준들이 대안으로써 사용되고, 또는 본 문서와 더불어 사용될 수 있는 수단을 제안하는 것은 본 문서의 범위 밖이다.

 

예를 들어, 프로젝트가 계약 또는 다른 수단을 통해 엔진 또는 항공기 제조사에 의해 적용되는

추가적인 표준을 준수하는 것이 의무가 될 수 있다고 인식된다. 이러한 표준은 그 활동을 위해

제조사에 의해 생성되거나 채택된 일반 규격으로부터 파생될 수도 있다. 공급 업체의 감독을 적용 할

때 적절하게 이러한 표준은 계획 프로세스에 의해 고려되고, 간주 되어야 한다.

 

6.     문서 사용방법

 

본 문서를 사용할 경우에는 다음과 같은 점에 유의해야 한다.

 

a. 본 문서는 국제 항공 커뮤니티(international aviation community) 에서 사용되는 것으로 의도된다. 이러한 사용을 지원하기 위해, 특정 국가 규정과 절차에 대한 참조가 최소화된다. 대신, 일반적인 용어가 사용된다. 예를 들어, 용어 "certification authority"는 조직 또는 제품 (예시: 항공기, 엔진)인증을 담당하는 국가 대신에 승인을 주는 사람을 나타내는 데 사용된다. 두 번째 국가 또는 국가의 그룹이 확인(Validation) 또는 이 인증(Certification)에 참여하는 경우, 본 문서는 국가간의 양자 협정 또는 관계된 국가 간의 양해각서(MOU)에 의한 소정의 인식으로 사용될 있다.

 

b. 본 문서는 본 문서의 지침이 법으로 의무화되지는 않지만 항공 커뮤니티 합의를 나타낸다는 것을 인식한다. 또한 본 문서에 서술된 방법에 대한 대안 방법이 신청자에 적용 가능할 수도 있다는 점을 인식한다. 이러한 이유로 인해 " shall " 또는 " must "등의 단어를 사용은 피하고 있다.

 

c. 신청자는 적합성 목적으로 본 문서를 사용하는 경우에 신청자는 해당하는 모든 목표를 만족해야 한다. 본 문서는 소프트웨어 수명주기 프로세스 또는 본 문서에 서술된 프로세스들의 산출물과 연관된 신청자와 그의 공급업체들에 적용해야 한다. 신청자는 공급업체의 모든 감독을 총괄하고 있다.

 

d. 신청자 목적을 충족시키기 위해 활동 계획해야 한다. 본 문서에서는 이러한 목표를 달성하기 위한 활동 설명한다. 신청자 계획하고 인증 기관의 승인을 조건으로, 본 문서에 기재되어있는 것들을 대체하는 활동을 있다. 신청자는 또한 추가로 필요하다고 결정된 활동을 계획하고 수행할 수도 있다.

 

e. 신청자 해당 소프트웨어의 계획과 표준에서 추가 고려 사항들을 다루어야 한다.

 

f. 신청자는 목적(Objectives) 충족 되었는지를 입증하기 위해 Section 11서 보여주는 것처럼 계획된 활동을 수행해야 하고, 증거를 제공해야 한다.

 

g. 주석(Explanatory text)의 경우 논의중인 주제를 독자가 이해하는 것을 돕기 위해 포함되어 있다. 예를 들어, Section 2는 시스템 수명주기와 소프트웨어 수명주기 사이의 상호작용을 이해하는 데 필요한 정보를 제공한다.

마찬가지로, Section 3은 소프트웨어 수명주기, Section 10은 인증 프로세스에 대한 개요를 설명한다.

 

h. Section 11은 일반적으로 인증 프로세스에서 소프트웨어를 지원하기 위해 작성된 데이터가 포함되어 있고 데이터의 이름은 각 단어의 첫 글자를 대문자로 표시하고 있다. (예를 들어, Source Code)

 

i. Section 12는 이전에 개발된 소프트웨어를 사용하기 위한 지침 tool qualification Section 2부터 Section11까지에서 설명된 것들을 대체하는 방법에 대해 설명한다. Section 12는 모든 프로젝트에 사용되지 않을 수도 있다.

 

j. Annex A는 각 소프트웨어 레벨에 대한 독립성과 제어 카테고리(control categories)의 차이뿐만 아니라, 각 소프트웨어 레벨에 대한 목적, 활동, 및 소프트웨어 수명주기 데이터의 적용을 명시한다. 완전한 지침을 이해하기 위해서는 본 문서의 전체를 파악해야 한다.

 

K 도표 또는 서술을 통해 지침이 적용될 수 있는 방법을 나타내기 위해 예제가 사용되는 경우, 그 예제는 선호되는 방법으로 해석되는 것이 아니다. 이러한 경우 예제는 정보지원이 고려된다.

 

l. 항목의 목록이 모든 목록을 포함하고 있다는 뜻은 아니다.

 

m. 본 문서에 기재되어있는 주의사항은 설명되어 있는 자료로 정보를 지원하는 점을 강조하며 문맥 내에서 완전하지 않은 항목에 주목하고 있다.

 

n. 주요 Section은 본 문서를 통해서 X. 0으로 번호가 정해져 있다.

전체 Section 에 대한 참조는 " Section X"로 나타내고 있다.

한편, Section 헤더의 X. 0 X. 1 사이의 내용에 대한 참조는 " Section X. 0"로 참조된다.

 

o. 본 문서에는 하나 이상의 부록이 존재한다. 그리고 특정 기술 문서가 있는 경우에는 지침이 추가된다. 또한 부록은 문서와 관련하여 서로 함께 사용할 수 있으며 또 다른 문서와 사용할 수 있다. 대안이 사용되지 않는 경우에는 (see 1.4.i), 부록이 있으면 부록의 추가, 삭제, 또는 다른 목적, 활동, 설명 텍스트를 수정하는 데 사용 되며 문서에서의 각 부록의 적절한 사용이 소프트웨어 수명주기 데이터의 문제를 해결한다.

인증기관에 따른 적절한 부록의 사용은 신청자의 권한이다.

부록의 사용은 소프트웨어 계획 프로세스의 일부로써, 신청자는 잠재적으로 모든 관련 부록의 사용을 고려하여 적절히 사용되는 부록들을 선택해야 한다. 부록의 정보는 문서와 동일한 방식으로 표기되어 있으며, Annex A는 본 문서의 목적이 부록에 의해 제시된 특정한 기술이 어떻게 수정되어 있는지 확인할 수 있다.

 

p. 모든 적용 가능한 목적은 모든 계획 활동과 관련 증거를 수집하면서 충족되었을 경우에 적합성이 달성된다.

 

 

7.     문서 개요

 

그림 1-1은 본 문서의 Section들과 서로의 관계에 대한 그림 설명이다.

Section 2: 소프트웨어 개발과 관련된 시스템 측면

Section 3: 소프트웨어 수명주기

소프트웨어 수명주기 프로세스에 포함된 단계

 

Section 4: 소프트웨어 계획 단계

Section 5: 소프트웨어 개발 단계

소프트웨어 요구사항 단계

소프트웨어 설계 단계

소프트웨어 구현 단계

통합 단계

 

전체 필수 프로세스

 

Section 6: 소프트웨어 검증 프로세스

Section 7: 소프트웨어 형상관리 프로세스

Section 8: 소프트웨어 품질보증 프로세스

Section 9: 인증 프로세스

Section 10: 인증 (Certification Liaison) 프로세스 개요

Section 11: 소프트웨어 수명주기 데이터

Section 12: 추가 고려사항

 

 

 

+ Recent posts