항공용 SW의 안전성을 위한 DO-178C / DO-278A 프로세스

개요

"DO-178C/DO-278A는 미국 연방항공국(FAA)에서 소프트웨어가 탑재된 항공기와 항공/지상장비 부품의 감항인증에 적용하고 있는 항공기 소프트웨어 안전성을 위한 감항인증 규격입니다. DO-178C/DO-278A는 민수 항공기 뿐만 아니라, 무인기를 포함한 군용항공기 개발을 위한 기준인 '군용항공기 표준감항인증 기준(Part1~Part3)' 에서도 요구되고 있습니다.

본 교육을 통해 DO-178C/DO-278A의 항공 시스템에 요구되는 안전성수준(Level A,B,C,D)에 따른 Objectives, Activities, Outputs를 이해하고, 시스템 요구사항으로부터 할당된 SW 요구사항에 대한 구현 완전성, 정확성, 추적성을 보증하기 위한 문서화 방법을 습득할 수 있습니다. 또한 Tool Qualification 규격인 DO-330과 DO-178C/DO-278A의 부속규격인 DO-331(모델기반 개발 규격)을 이해할 수 있습니다."

중점

RTCA DO-178C/DO-278A 개요SW Level(SIL: SAFETY INTEGRITY LEVEL)별 Objectives, Activities, Outputs 이해시스템 요구사항으로부터 할당된 SW 요구사항 구현의 완전성, 정확성, 추적성 보증을 위한 문서화 방안 이해DO-330(Tool Qualification 규격) 및 DO-331(모델기반 개발 규격) 소개

참석대상

프로젝트 매니저시스템 엔지니어 소프트웨어 엔지니어품질보증 관리자

교육 프로그램

일정

세부내용

강사

1 일차

10:00-17:00

1. Course Introduction

2. RTCA DO-178C/DO-278A Overview

3. System Aspects Relating to Software Development

4. Software Life Cycle

5. Software Planning Process

6. Software Development Process

장정훈 부장

강유선 책임

(모아소프트)

2 일차

10:00-17:00

7. Software Verification Process

- Software Reviews and Analyses

- Software Testing

8. Software Configuration Mangement Process

9. Software Quality Assurance

10. Certification Liaison Process and Process Overview

장정훈 부장

강유선 책임

(모아소프트)

3 일차

10:00-17:00

11. Software Life Cycle Data

12. Additional Considerations

13. DO-330 Software Tool Qualification Considerations

14. Supplements to DO-178C/DO-278A

- DO-331 Model-Based Development and Verification

장정훈 부장

강유선 책임

(모아소프트)

* 상기 강의 일정은 진행에 따라 다소 변경될 수 있습니다.

교육 일정 안내

교육장소

서울 송파구 가락동 175-14 연암빌딩 4층 모아소프트 교육장

교육기간

2019년 연내 4회

교육비

33만원 (유저/비유저 모두 유료)

교재

자체제작

교육장

교육신청 및 안내

http://www.moasoftware.co.kr/edu/edu.asp

02.6945.2182 (hmnam@moasoftware.co.kr)

 

 

DO-178C SOFTWARE PLANNING PROCESS

Objective - 3의 이해


  

1. Objective - 3의 개요

SW 라이프 사이클 프로세스의 활동을 위해 사용되는 방법. 도구 등을 포함하는 SW 라이프 사이클 환경이 선정되고 정의되어야 한다. (DO-178C 4.4참조)

 


2. Activity 

  • SW 개발환경

SW개발 환경은 높은 품질의 SW를 개발하는데 있어 중요한 요소이다. SW개발 시 몇 가지 환경들은 악영향을 끼칠 수 있다. 예를 들어 컴파일러(compiler)는 오류 있는 데이터를 만들어 에러를 일으킬 수 있고, 링커(linker)는 메모리할당 에러가 있는 것을 나타내지 못할 수도 있다. SW 개발 환경 방법 및 도구의 선택을 위한 활동은 아래와 같다.


  1. SW 계획 단계에서, SW 개발 환경은 소프트웨어 개발 시 잠재적인 위험을 줄일 수 있도록 선택해야 한다.

  2. 도구의 사용 또는 도구와 일부 SW 개발환경과의 결합은 어떤 한 부분에서 유입된 에러를 다른 부분에서 발견할 수 있을 정도의 확신 수준이 달성될 수 있도록 선택되어야 한다. 두 부분이 지속적으로 함께 사용되는 경우에 수용가능한 환경이 만들어 진다. 이러한 선택은 tool qualification필요성 여부에 대한 평가도 포함한다.

  3. SW 검증 절차 활동 또는 SW 개발 표준은 SW 등급을 고려하여 잠재적인 SW 개발 환경과 관련된 에러를 줄이기 위해 정의해야 한다.

  4. 도구의 사용을 위해 도구에 대한 certification이 필요하다면 도구의 사용절차가 계획에 적절하게 명시되어야 한다.

  5. 특정 프로젝트에서 SW 도구의 부가적인 옵션이 선택된다면, 옵션의 영향성은 계획단계에서 검토 및 명시되어야 한다. 이것은 특히 컴파일러와 자동코드 생성기에 중요한 사항이다.

  6. 도구의 알려진 문제점 및 한계점은 반드시 평가해야 하며 항공 SW에 부정적인 영향을 끼칠 수 있는 이런 이슈들은 반드시 다뤄져야 한다.

 

  • 언어 및 컴파일러 고려사항

    SW 제품의 검증이 성공적으로 완료된다면 컴파일러는 해당 제품에 적합하다고 여겨진다. 이 활동이 유효 하려면, SW 검증 절차는 프로그래밍 언어 및 컴파일러의 특별한 특성을 고려할 필요가 있다 SW 계획 과정은 검증을 위한 프로그래밍 언어 및 계획을 선택할 때 위와 같은 특성을 고려해야 한다. 활동은 아래와 같다.

    1. 어떤 컴파일러는 오브젝트코드의 성능을 최적화하려는 특성이 있다. 만약 SW 레벨에 적절하게 테스트케이스가 작성되었다면 최적화의 정확성은 검증될 필요가 없다. 그렇지 않다면, 구조적 커버리지(structural coverage) 분석에 대한 이러한 특징의 영향이 결정되어야 한다. 추가적인 정보는 DO-178C 6.4.4.2에 기술되어 있다.

    2. 특정기능을 구현하기위해, 몇 개의 컴파일러는 소스코드로 직접 추적할 수 없는 오브젝트코드를 생성 한다. 예를 들어 초기화, 내장(built-in)된 에러 검출, 예외처리가 있으며 추가적인 정보는 DO-178C 6.4.4.2.b에 서술되어 있다. SW계획 절차에서 오브젝트코드의 검출 및 범위(coverage)를 검증하기 위한 수단을 제공해야 하며, 적합한 계획(appropriate plan)에서 수단을 정의해야 한다.

    3. 만약 새로운 컴파일러, linkage editor 또는 로더(loader) 버전이 도입되거나, SW 라이프 싸이클 동안 컴파일러 옵션이 변경될 경우, 기존에 테스트 및 커버리지 분석은 더 이상 유효하지 않을 수 있다. 검증 계획은 DO-178C 6장 및 12.1.3장과 일관되는 재검증 수단을 제공해야 한다.

 

  • SW 테스트환경

    SW 테스트 환경 계획은 통합 프로세스의 결과를 시험하기 위해 사용될 방법, 도구, 절차, HW를 정의한다. 테스팅은 target computer, target computer emulator, 또는 host computer simulator을 이용하여 수행된다.

    테스팅의 활동들은 다음과 같다.

  •  

  1. Emulator 또는 simulatorDO-178C 12.2장에 기술된 것처럼 툴 자격을 갖춰야 한다.

  2. Target computeremulator(또는 simulator)의 차이점 및 에러를 검출하고 기능을 검증하는 능력에 대한 target computeremulator(or simulator)차이점의 결과를 고려해야 한다. SW 검증 프로세스에 의해 에러가 검출되어야 하며 SW 검증 계획(SVP)에서 에러 검출방법이 명시되어야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A~C 에서는 모두 달성해야 하며 레벨 D SW는 해당되지 않는다.

 

 

4. Outputs(산출물)


  • PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 구성 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조


 

5. Control Category by Software Level

SW 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며, SW 레벨 C, D의 산출물 PSAC CC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

6. 달성방안

  • SDP SW 개발 절차 및 활동에서 활용하는 방법, 도구(Tool), HW장비를 선정한다.

  • Development Tools, Coding Rule, Programming Language, Editor, Compiler

  • Verification Tools: LDRA Testbed/TBrun, Debugging Tool

  • Management Tools: MS-Project, PMS, ClearCase, CVS, Doors

  • Tool 중에서는 Tool Qualification을 받아야 하는 것을 명시한다. (Ref. DO-178C 12.2)

  • Tool을 선정할 때에는 SW의 잠재적인 위험 및 결함을 최소화할 수 있는지를 고려한다.

  • SW가 탑재될 HW장비 또는 그 장비를 대신할 Emulator 또는 Simulator를 선정한다.

 

다음에는 Objective - 4에 대해 알아보도록 하자.


감항인증을 위한 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




모아소프트 6월 교육과정 안내

(주)모아소프트 6월 정규 교육과정 일정 안내드립니다.

2016년, 더 다양하고 더 심도깊은 교육을 선보이고 있는 모아소프트의 교육과정 놓치지 마세요!

2016년 업계 관계자분들의 요청으로 인해 신설된,

"감항인증을 위한 항공용 SW개발 프로세스(RTCA DO-178C) " 와 "MISRA를 기반으로 한 코딩룰 교육"

 

일년에 두차례 진행되는  "가속수명시험 및 환경시험 실무교육"

다양한 수치해석 기법의 장단점을 이해하고, 실제 환경에서 이용할 수 있는

EMC, RCS, Radome 해석을 도출하는 방법을  알아보는 "안테나 및 전자파 해석(심화)" 교육이 6월 내에 진행됩니다!

많은 관심 부탁드립니다.



* 모아소프트 6월 정규 교육과정 신청 안내

http://www.moasoftware.co.kr/edu/edu.asp?curDate=2016-06-01

 

 

 

 

 

 

 

* 모아소프트 연간 정규 교육과정 안내

http://www.moasoftware.co.kr/cscenter/notice_view.asp?idx=22&cPage=1



* 교육비 및 기타 교육 문의

전화  02 - 6945 - 2182 (남혜미 과장)

E-mail  hmnam@moasoftware.co.kr

 

 

DO-178C(항공용 소프트웨어 감항인증)에 적합한

정적분석을 활용한 소프트웨어 동적 시험 프로세스

 

 

DO-178C는 항공기 소프트웨어 오작동으로 인한 항공기 사고 위험을 최소화하기 위한, 항공기 소프트웨어 안전성(Safety)에 대한 국제적인 감항 인증 표준 규격으로 소프트웨어 계획, 요구사항, 설계 구현 및 통합, 검증, 형상관리, 품질관리, 인증 프로세스 등의 소프트웨어 개발 프로세스를 가지며, 그 중 검증 및 테스트와 관련된 부분이 가장 중요한 이슈로 부각되고 있다. 

 

항공용 소프트웨어 안전성 확보를 위해서는 DO-178C(항공용 소프트웨어 안전성 및 감항인증 국제 규격)에 적합한 테스트를 수행하여야 하며 DO-178C Annex A. Table 7에서 테스트 수행에 대한 목표(Objectives)를 명확하게 정의하고 있다.

 

DO-178C의 테스트 요건은 테스트 절차, 테스트 케이스 생성 및 수행, 테스트 결과 분석, 테스트 커버리지-Statement Coverage(SC), Branch Coverage(BC), Modified Condition/Decision Coverage(MC/DC)- 달성 등이 있다.

 

다년간 수행한 소프트웨어 시험에서 나타난 주요 문제점 및 원인은 아래와 같다.  이에 모아소프트에서는 이러한 문제점을 개선하기 위해 “정적분석 기반의 동적시험 프로세스”를 구축하였다.

 

현상 및 문제점

원인

소프트웨어 설계문서와

소스코드의 불일치

SW개발팀이 작성한 설계문서는 초기 버전이며,

최종적으로 완료전에 현행화할 예정이므로 테스트

단계에서는 테스트 설계에 직접 활용하기 어려움

테스트 케이스 설계 시간소요

소스코드의 각 단위함수에 대한 테스트 커버리지를 위해 필요한

입력변수의 입력값이 테스트를 수행하면서 사후적으로 작성되고 있음

소스코드 실행율(SC,BC, MC/DC)

100% 달성 시간소요

소스코드 실행율 100% 달성을 위해 일부 소스코드를

수정하고 다시 적용하기까지 시간이 소요됨

2차 소스코드에 대한

재시험 수행의 비효율성

개발업체로부터 수정된 소스코드를 다시 전달받아서

재수행 하기까지 시간이 소요됨

  

[단계 1] 정적분석 도구 활용

 

정적분석 도구인 LDRA Tested의 주요 기능은 다음과 같다.

(테스트에 사용될 자동화 도구는 LDRA이며, LDRA 도구는 DO-178C 규격에 대한 Certification을 보유하고 있다.)

- 소스코드에 대한 코딩룰 검사 (MISRA coding standard 1,500 여개의 코딩표준 검사)

- 소스코드에 대한 품질 메트릭 산출 (Cyclomatic Complexity, Testability 40 여개의 Quality Metric 산출)

- 단위함수에 대한 input/output parameter call function 정보 제공

- Call graph, Flow diagram 등 소스코드에 대한 시각적 구조 정보 제공

 

 

[단계 2] 테스트 케이스 자동 생성 

LDRA Testbed에서 정적분석을 수행하면 생성되는 Quality Review Report*.glh(정적분석 결과 파일)로부터 단위함수에 대한 정보(Function I/O정보, Cyclomatic Complexity, Testability, Function Call정보)를 추출하여 테스트 케이스를 설계한다.

테스트 케이스 설계 도구(TCMAN)를 이용하여 단위함수의 input/output 변수 정보를 Excel 문서로 생성하고 동적시험에서 필요한 *.tcf (테스트 케이스 파일)를 생성한다.

 

[단계 3] 테스트 실행 및 결과보고서

동적시험 도구인 LDRA TBrun을 사용하여 *.tcf 파일을 적용하여 테스트를 수행하고, 국제 SW 분야 표준 서식(ISO/IEC/IEEE 29119, IEEE Std. 829)의 테스트결과보고서(*.doc)을 자동으로 생성하며 테스트커버리지(코드실행률) 및 결함을 기록한다.

정적분석 기반의 동적시험 프로세스를 적용하여 소스코드에 대한 정적분석 결과에서의 코드 품질매트릭과 함수 정보로부터 자동 생성된 테스트케이스에 의한 동적시험을 수행할 수 있었으며, 국제 표준의 시험결과보고서를 자동 생성하여 제공함으로써 항공 안전성 감항인증에 적합한 SW개발 및 테스트 프로세스의 효율성과 SW신뢰성 및 품질향상을 제공할 수 있다.



컨설팅 담당 장정훈 차장 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



+ Recent posts