DO-178 인증 실무가이드 번역본 목차 정리
번역본의 목차와 원서의 목차를 1:1로 정리했습니다. 참고로 번역본의 목차에는 3단계(예 - 2.1.1) 이하의 하부 제목은 목차 페이지에는 인쇄되어 있지 않습니다만 본문에는 아래와 같이 원서와 동일하게 모두 포함되어 있습니다.
워낙 항목이 많아서 전체를 정리하니 표가 상당히 길어졌습니다. 참고하세요.
|
구분 |
인덱스(번역본) |
인덱스(원서) |
|
Part 01 |
소개 |
Introduction |
|
Chapter 1 |
소개 및 개요 |
Introduction and Overview |
|
1.1 |
안전 필수 소프트웨어에 대한 정의 |
Defining Safety-Critical Software |
|
1.2 |
안전에 초점을 맞추는 것에 대한 중요성 |
Importance of Safety Focus |
|
1.3 |
책의 목적과 중요한 단서 조항 |
Book Purpose and Important Caveats |
|
1.4 |
책의 개요 |
Book Overview |
|
참고문헌 |
참고문헌 |
References |
|
Part 02 |
안전 필수 소프트웨어 개발의 맥락 |
Context of Safety-Critical Software Development |
|
Chapter 2 |
시스템 맥락에서의 소프트웨어 |
Software in the Context of the System |
|
2.1 |
시스템 개발의 개요 |
Overview of System Development |
|
2.2 |
시스템 요구사항 |
System Requirements |
|
2.2.1 |
시스템 요구사항의 중요성 |
Importance of System Requirements |
|
2.2.2 |
시스템 요구사항의 유형 |
Types of System Requirements |
|
2.2.3 |
좋은 요구사항의 특징 |
Characteristics of Good Requirements |
|
2.2.4 |
시스템 요구사항 고려사항 |
System Requirements Considerations |
|
2.2.4.1 |
무결성과 유효성에 대한 고려사항 |
Integrity and Availability Considerations |
|
2.2.4.2 |
시스템 요구사항의 다른 고려사항 |
Other System Requirements Considerations |
|
2.2.5 |
요구사항에 대한 가정 |
Requirements Assumptions |
|
2.2.6 |
아이템으로의 할당 |
Allocation to Items |
|
2.3 |
시스템 요구사항 확인 및 검증 |
System Requirements Validation and Verification |
|
2.3.1 |
요구사항 확인 |
Requirements Validation |
|
2.3.2 |
구현 검증 |
Implementation Verification |
|
2.3.3 |
확인 및 검증 권고사항 |
Validation and Verification Recommendations |
|
2.4 |
시스템 엔지니어를 위한 모범 사례 |
Best Practices for Systems Engineers |
|
2.5 |
시스템에 대한 소프트웨어의 관계 |
Software’s Relationship to the System |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 3 |
시스템 안전성 평가 맥락에서의 소프트웨어 |
Software in the Context of the System Safety Assessment |
|
3.1 |
항공기와 시스템 안전성 평가 프로세스의 개요 |
Overview of the Aircraft and System Safety Assessment Process |
|
3.1.1 |
안전성 프로그램 계획 |
Safety Program Plan |
|
3.1.2 |
Functional Hazard Assessment |
Functional Hazard Assessment |
|
3.1.3 |
System Functional Hazard Assessment |
System Functional Hazard Assessment |
|
3.1.4 |
Preliminary Aircraft Safety Assessment |
Preliminary Aircraft Safety Assessment |
|
3.1.5 |
Preliminary System Safety Assessment |
Preliminary System Safety Assessment |
|
3.1.6 |
Common Cause Analysis |
Common Cause Analysis |
|
3.1.7 |
Aircraft Safety Assessments와 System Safety Assessments |
Aircraft and System Safety Assessments |
|
3.2 |
개발 보증 |
Development Assurance |
|
3.2.1 |
개발 보증 레벨 |
Development Assurance Levels |
|
3.3 |
소프트웨어는 어떻게 안전성 프로세스에 맞춰지는가? |
How Does Software Fit into the Safety Process? |
|
3.3.1 |
소프트웨어의 독특함 |
Software’s Uniqueness |
|
3.3.2 |
소프트웨어 개발 보증 |
Software Development Assurance |
|
3.3.3 |
다른 관점 |
Other Views |
|
3.3.4 |
시스템 안전성 프로세스에서 소프트웨어를 다루기 위한 몇 가지 제안 |
Some Suggestions for Addressing Software in the System Safety Process |
|
참고문헌 |
참고문헌 |
References |
|
Part 03 |
DO-178C를 사용한 안전 필수 소프트웨어 개발 |
Developing Safety-Critical Software Using DO-178C |
|
Chapter 4 |
DO-178C의 개요와 지원 문서들 |
Overview of DO-178C and Supporting Documents |
|
4.1 |
DO-178의 역사 |
History of DO-178 |
|
4.2 |
DO-178C와 DO-278A 핵심 문서들 |
DO-178C and DO-278A Core Documents |
|
4.2.1 |
DO-278A와 DO-178C의 차이점 |
DO-278A and DO-178C Differences |
|
4.2.2 |
DO-178C Annex A 목표 테이블의 개요 |
Overview of the DO-178C Annex A Objectives Tables |
|
4.3 |
DO-330 : 소프트웨어 도구 인증 고려사항 |
DO-330: Software Tool Qualification Considerations |
|
4.4 |
DO-178C 기술 부속서 |
DO-178C Technology Supplements |
|
4.4.1 |
DO-331 : 모델 기반 개발 부속서 |
DO-331: Model-Based Development Supplement |
|
4.4.2 |
DO-332 : 객체 지향 기술 부속서 |
DO-332: Object-Oriented Technology Supplement |
|
4.4.3 |
DO-333 : 정형 기법 부속서 |
DO-333: Formal Methods Supplement |
|
4.5 |
DO-248C : 지원 항목 |
DO-248C: Supporting Material |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 5 |
소프트웨어 계획 |
Software Planning |
|
5.1 |
소개 |
Introduction |
|
5.2 |
일반적인 계획 권고사항들 |
General Planning Recommendations |
|
5.3 |
다섯 가지 소프트웨어 계획 |
Five Software Plans |
|
5.3.1 |
소프트웨어 인증 계획(PSAC) |
Plan for Software Aspects of Certification |
|
5.3.2 |
소프트웨어 개발 계획(SDP) |
Software Development Plan |
|
5.3.3 |
소프트웨어 검증 계획(SVP) |
Software Verification Plan |
|
5.3.4 |
소프트웨어 형상 관리 계획(SCMP) |
Software Configuration Management Plan |
|
5.3.5 |
소프트웨어 품질 보증 계획(SQAP) |
Software Quality Assurance Plan |
|
5.4 |
세 가지 개발 표준 |
Three Development Standards |
|
5.4.1 |
소프트웨어 요구사항 표준(SRS) |
Software Requirements Standards |
|
5.4.2 |
소프트웨어 설계 표준(SDS) |
Software Design Standards |
|
5.4.3 |
소프트웨어 코딩 표준(SCS) |
Software Coding Standards |
|
5.5 |
도구 인증 계획 |
Tool Qualification Planning |
|
5.6 |
기타 계획들 |
Other Plans |
|
5.6.1 |
프로젝트 관리 계획 |
Project Management Plan |
|
5.6.2 |
요구사항 관리 계획 |
Requirements Management Plan |
|
5.6.3 |
시험 계획 |
Test Plan |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 6 |
소프트웨어 요구사항 |
Software Requirements |
|
6.1 |
소개 |
Introduction |
|
6.2 |
요구사항 정의하기 |
Defining Requirement |
|
6.3 |
좋은 소프트웨어 요구사항의 중요성 |
Importance of Good Software Requirements |
|
6.3.1 |
이유 1 : 요구사항은 소프트웨어 개발에 대한 근간이다 |
Reason 1: Requirements Are the Foundation for the Software Development |
|
6.3.2 |
이유 2 : 좋은 요구사항은 시간과 돈을 절약한다 |
Reason 2: Good Requirements Save Time and Money |
|
6.3.3 |
이유 3 : 좋은 요구사항은 안전에 필수이다 |
Reason 3: Good Requirements Are Essential to Safety |
|
6.3.4 |
이유 4 : 좋은 요구사항은 고객의 요구를 충족하기 위해 필요하다 |
Reason 4: Good Requirements Are Necessary to Meet the Customer Needs |
|
6.3.5 |
이유 5 : 좋은 요구사항은 시험을 위해 중요하다 |
Reason 5: Good Requirements Are Important for Testing |
|
6.4 |
소프트웨어 요구사항 엔지니어 |
The Software Requirements Engineer |
|
6.5 |
소프트웨어 요구사항 개발의 개요 |
Overview of Software Requirements Development |
|
6.6 |
소프트웨어 요구사항에 대한 입력 수집 및 분석 |
Gathering and Analyzing Input to the Software Requirements |
|
6.6.1 |
요구사항 수집 활동 |
Requirements Gathering Activities |
|
6.6.2 |
요구사항 분석 활동 |
Requirements Analyzing Activities |
|
6.7 |
소프트웨어 요구사항 작성하기 |
Writing the Software Requirements |
|
6.7.1 |
작업 1 : 방법론을 결정하라 |
Task 1: Determine the Methodology |
|
6.7.2 |
작업 2 : 소프트웨어 요구사항 문서 레이아웃을 결정하라 |
Task 2: Determine the Software Requirements Document Layout |
|
6.7.3 |
작업 3 : 소프트웨어 기능을 하위 시스템 그리고/혹은 특징으로 나누어라 |
Task 3: Divide Software Functionality into Subsystems and/or Features |
|
6.7.4 |
작업 4 : 요구사항의 우선순위를 결정하라 |
Task 4: Determine Requirements Priorities |
|
6.7.5 |
잠시 우회하기(작업이 아님) : 피해야 할 위험한 상황 |
A Brief Detour (Not a Task): Slippery Slopes to Avoid |
|
6.7.5.1 |
위험한 상황 #1 : 너무 빨리 설계하기 |
Slippery Slope #1: Going to Design Too Quickly |
|
6.7.5.2 |
위험한 상황 #2 : 한 가지 레벨의 요구사항 |
Slippery Slope #2: One Level of Requirements |
|
6.7.5.3 |
위험한 상황 #3 : 코드로 바로 가기 |
Slippery Slope #3: Going Straight to Code |
|
6.7.6 |
작업 5 : 요구사항 작성하기 |
Task 5: Document the Requirements |
|
6.7.6.1 |
기능 요구사항 작성하기 |
Document Functional Requirements |
|
6.7.6.2 |
비기능 요구사항 작성하기 |
Document Nonfunctional Requirements |
|
6.7.6.3 |
인터페이스 작성하기 |
Document Interfaces |
|
6.7.6.4 |
각각의 요구사항을 유일하게 식별하기 |
Uniquely Identify Each Requirement |
|
6.7.6.5 |
근거를 작성하기 |
Document Rationale |
|
6.7.6.6 |
요구사항에 대한 소스를 추적하기 |
Trace Requirements to Their Source |
|
6.7.6.7 |
불확실성과 가정을 식별하기 |
Identify Uncertainties and Assumptions |
|
6.7.6.8 |
데이터 사전을 시작하기 |
Start a Data Dictionary |
|
6.7.6.9 |
좋은 요구사항의 특징을 구현하기 |
Implement Characteristics of Good Requirements |
|
6.7.7 |
작업 6 : 시스템 요구사항에 피드백을 전달하기 |
Task 6: Provide Feedback on the System Requirements |
|
6.8 |
요구사항 검증하기(리뷰하기) |
Verifying (Reviewing) Requirements |
|
6.8.1 |
추천되는 동료 검토 사례들 |
Peer Review Recommended Practices |
|
6.9 |
요구사항 관리하기 |
Managing Requirements |
|
6.9.1 |
요구사항 관리의 기본 |
Basics of Requirements Management |
|
6.9.2 |
요구사항 관리 도구들 |
Requirements Management Tools |
|
6.10 |
요구사항 프로토타이핑하기 |
Requirements Prototyping |
|
6.11 |
추적성 |
Traceability |
|
6.11.1 |
추적성의 중요성과 장점 |
Importance and Benefits of Traceability |
|
6.11.2 |
양방향 추적성 |
Bidirectional Traceability |
|
6.11.3 |
DO-178C와 추적성 |
DO-178C and Traceability |
|
6.11.4 |
추적성에 대한 어려움 |
Traceability Challenges |
|
참고문헌 |
참고문헌 |
References |
|
추천 자료 |
추천 자료 |
Recommended Readings |
|
Chapter 7 |
소프트웨어 설계 |
Software Design |
|
7.1 |
소프트웨어 설계의 개요 |
Overview of Software Design |
|
7.1.1 |
소프트웨어 아키텍처 |
Software Architecture |
|
7.1.2 |
소프트웨어 하위 레벨 요구사항 |
Software Low-Level Requirements |
|
7.1.3 |
설계 패키징 |
Design Packaging |
|
7.2 |
설계 접근법 |
Approaches to Design |
|
7.2.1 |
구조 기반 설계(전통적인) |
Structure-Based Design (Traditional) |
|
7.2.2 |
객체 지향 설계 |
Object-Oriented Design |
|
7.3 |
좋은 설계의 특성 |
Characteristics of Good Design |
|
7.4 |
설계 검증 |
Design Verification |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 8 |
소프트웨어 구현 : 코딩 및 통합 |
Software Implementation: Coding and Integration |
|
8.1 |
소개 |
Introduction |
|
8.2 |
코딩 |
Coding |
|
8.2.1 |
DO-178C 코딩 지침의 개요 |
Overview of DO-178C Coding Guidance |
|
8.2.2 |
안전 필수 소프트웨어에 사용되는 언어 |
Languages Used in Safety-Critical Software |
|
8.2.2.1 |
어셈블리 언어 |
Assembly Language |
|
8.2.2.2 |
Ada |
Ada |
|
8.2.2.3 |
C |
C |
|
8.2.3 |
언어와 컴파일러 선택하기 |
Choosing a Language and Compiler |
|
8.2.4 |
프로그래밍에 대한 일반적인 권고사항 |
General Recommendations for Programming |
|
8.2.5 |
코드와 관련된 특별한 주제들 |
Special Code-Related Topics |
|
8.2.5.1 |
코딩 표준 |
Coding Standards |
|
8.2.5.2 |
컴파일러 제공 라이브러리 |
Compiler-Supplied Libraries |
|
8.2.5.3 |
자동 코드 생성기(Autocode Generators) |
Autocode Generators |
|
8.3 |
소스 코드를 검증하기 |
Verifying the Source Code |
|
8.4 |
개발 통합 |
Development Integration |
|
8.4.1 |
빌드 프로세스 |
Build Process |
|
8.4.2 |
로드 프로세스 |
Load Process |
|
8.5 |
개발 통합을 검증하기 |
Verifying the Development Integration |
|
참고문헌 |
참고문헌 |
References |
|
추천 자료 |
추천 자료 |
Recommended Readings |
|
Chapter 9 |
소프트웨어 검증 |
Software Verification |
|
9.1 |
소개 |
Introduction |
|
9.2 |
검증의 중요성 |
Importance of Verification |
|
9.3 |
독립성과 검증 |
Independence and Verification |
|
9.4 |
리뷰 |
Reviews |
|
9.4.1 |
소프트웨어 계획 리뷰 |
Software Planning Review |
|
9.4.2 |
소프트웨어 요구사항, 설계 그리고 코드 리뷰 |
Software Requirements, Design, and Code Reviews |
|
9.4.3 |
시험 데이터 리뷰 |
Test Data Reviews |
|
9.4.4 |
다른 데이터 항목들의 리뷰 |
Review of Other Data Items |
|
9.5 |
분석 |
Analyses |
|
9.5.1 |
워스트 케이스 실행시간(Worst-Case Execution Time : WCET) 분석 |
Worst-Case Execution Time Analysis |
|
9.5.2 |
메모리 마진 분석 |
Memory Margin Analysis |
|
9.5.3 |
링크 및 메모리맵 분석 |
Link and Memory Map Analysis |
|
9.5.4 |
로드 분석 |
Load Analysis |
|
9.5.5 |
인터럽트 분석 |
Interrupt Analysis |
|
9.5.6 |
수학 분석 |
Math Analysis |
|
9.5.7 |
에러와 경고 분석 |
Errors and Warnings Analysis |
|
9.5.8 |
파티션 분석 |
Partitioning Analysis |
|
9.6 |
소프트웨어 시험 |
Software Testing |
|
9.6.1 |
소프트웨어 시험의 목적 |
Purpose of Software Testing |
|
9.6.2 |
DO-178C 소프트웨어 시험 지침의 개요 |
Overview of DO-178C’s Software Testing Guidance |
|
9.6.2.1 |
요구사항 기반 시험 방법 |
Requirements-Based Test Methods |
|
9.6.2.2 |
정상적인 시험과 강건성 시험 |
Normal and Robustness Tests |
|
9.6.3 |
시험 전략에 대한 조사 |
Survey of Testing Strategies |
|
9.6.3.1 |
동등 클래스 분할 |
Equivalence Class Partitioning |
|
9.6.3.2 |
경계값 시험 |
Boundary Value Testing |
|
9.6.3.3 |
상태 전이 시험 |
State Transition Testing |
|
9.6.3.4 |
결정 테이블 시험 |
Decision Table Testing |
|
9.6.3.5 |
통합 시험 |
Integration Testing |
|
9.6.3.6 |
성능 시험 |
Performance Testing |
|
9.6.3.7 |
기타 전략들 |
Other Strategies |
|
9.6.3.8 |
복잡도 측정 |
Complexity Measurements |
|
9.6.3.9 |
좋은 시험의 요약과 특징 |
Summary and Characteristics of a Good Test |
|
9.6.4 |
시험 계획 |
Test Planning |
|
9.6.5 |
시험 개발 |
Test Development |
|
9.6.5.1 |
시험 케이스 |
Test Cases |
|
9.6.5.2 |
시험 절차 |
Test Procedures |
|
9.6.5.3 |
DO-178C 요구사항 |
DO-178C Requirements |
|
9.6.5.4 |
하위 레벨 요구사항 시험 vs. 단위 시험 |
Low-Level Requirements Testing versus Unit Testing |
|
9.6.5.5 |
시험될 수 없는 요구사항의 처리 |
Handling Requirements That Cannot Be Tested |
|
9.6.5.6 |
여러 레벨의 시험에 대한 신뢰를 획득하기 |
Obtaining Credit for Multiple Levels of Testing |
|
9.6.5.7 |
요구사항의 추가적인 레벨을 시험하기 |
Testing Additional Levels of Requirements |
|
9.6.6 |
시험 수행 |
Test Execution |
|
9.6.6.1 |
예행 연습 수행하기 |
Performing Dry Runs |
|
9.6.6.2 |
시험 케이스와 절차를 리뷰하기 |
Reviewing Test Cases and Procedures |
|
9.6.6.3 |
타깃 컴퓨터 vs. 에뮬레이터 혹은 시뮬레이터 사용하기 |
Using Target Computer versus Emulator or Simulator |
|
9.6.6.4 |
검증 환경을 문서화하기 |
Documenting the Verification Environment |
|
9.6.6.5 |
시험 준비 리뷰(TRR) |
Test Readiness Review |
|
9.6.6.6 |
인증 신뢰를 위한 시험 수행하기 |
Running Tests for Certification Credit |
|
9.6.7 |
시험 리포팅 |
Test Reporting |
|
9.6.8 |
시험 추적성 |
Test Traceability |
|
9.6.9 |
회귀 시험 |
Regression Testing |
|
9.6.10 |
시험가능성 |
Testability |
|
9.6.11 |
검증 프로세스에서의 자동화 |
Automation in the Verification Processes |
|
9.7 |
검증의 검증 |
Verification of Verification |
|
9.7.1 |
시험 절차의 리뷰 |
Review of Test Procedures |
|
9.7.2 |
시험 결과의 리뷰 |
Review of Test Results |
|
9.7.3 |
요구사항 커버리지 분석 |
Requirements Coverage Analysis |
|
9.7.4 |
구조적 커버리지 분석 |
Structural Coverage Analysis |
|
9.7.4.1 |
Statement 커버리지(DO-178C Table A-7 목표 7) |
Statement Coverage (DO-178C Table A-7 Objective 7) |
|
9.7.4.2 |
Decision 커버리지(DO-178C Table A-7 목표 6) |
Decision Coverage (DO-178C Table A-7 Objective 6) |
|
9.7.4.3 |
Modified Condition/Decision Coverage(DO-178C Table A-7 목표 5) |
Modified Condition/Decision Coverage (DO-178C Table A-7 Objective 5) |
|
9.7.4.4 |
추가적인 코드 검증(DO-178C Table A-7 목표 9) |
Additional Code Verification (DO-178C Table A-7 Objective 9) |
|
9.7.4.5 |
데이터 결합도와 컨트롤 결합도 분석(DO-178C Table A-7 목표 8) |
Data Coupling and Control Coupling Analyses (DO-178C Table A-7 Objective 8) |
|
9.7.4.6 |
구조적 커버리지 갭을 해결하기 |
Addressing Structural Coverage Gaps |
|
9.7.4.7 |
구조적 커버리지 분석에 대한 최종 고찰 |
Final Thoughts on Structural Coverage Analysis |
|
9.8 |
문제점 리포팅 |
Problem Reporting |
|
9.9 |
검증 프로세스를 위한 권고사항 |
Recommendations for the Verification Processes |
|
참고문헌 |
참고문헌 |
References |
|
추천 자료 |
추천 자료 |
Recommended Readings |
|
Chapter 10 |
소프트웨어 형상 관리 |
Software Configuration Management |
|
10.1 |
소개 |
Introduction |
|
10.1.1 |
소프트웨어 형상 관리가 무엇인가? |
What Is Software Configuration Management? |
|
10.1.2 |
소프트웨어 형상 관리가 왜 필요한가? |
Why Is Software Configuration Management Needed? |
|
10.1.3 |
소프트웨어 형상 관리를 구현하는 것은 누구의 책임인가? |
Who Is Responsible for Implementing Software Configuration Management? |
|
10.1.4 |
소프트웨어 형상 관리가 관여하는 것은 무엇인가? |
What Does Software Configuration Management Involve? |
|
10.2 |
SCM 활동들 |
SCM Activities |
|
10.2.1 |
형상 식별 |
Configuration Identification |
|
10.2.2 |
베이스라인 |
Baselines |
|
10.2.3 |
추적성 |
Traceability |
|
10.2.4 |
문제점 리포팅 |
Problem Reporting |
|
10.2.4.1 |
여러 이해관계자들과 함께 문제점 리포트 관리 |
Problem Report Management with Multiple Stakeholders |
|
10.2.4.2 |
오픈/연기된 문제점 리포트 관리하기 |
Managing Open/Deferred Problem Reports |
|
10.2.5 |
변경 컨트롤과 리뷰 |
Change Control and Review |
|
10.2.6 |
형상 상태 감사 |
Configuration Status Accounting |
|
10.2.7 |
릴리즈 |
Release |
|
10.2.8 |
보관과 복구 |
Archival and Retrieval |
|
10.2.9 |
데이터 컨트롤 분류 |
Data Control Categories |
|
10.2.10 |
로드 컨트롤 |
Load Control |
|
10.2.11 |
소프트웨어 라이프 사이클 환경 컨트롤 |
Software Life Cycle Environment Control |
|
10.3 |
특별한 SCM 기술들 |
Special SCM Skills |
|
10.4 |
SCM 데이터 |
SCM Data |
|
10.4.1 |
SCM 계획 |
SCM Plan |
|
10.4.2 |
문제점 리포트 |
Problem Reports |
|
10.4.3 |
소프트웨어 라이프 사이클 환경 형상 인덱스 |
Software Life Cycle Environment Configuration Index |
|
10.4.4 |
소프트웨어 형상 인덱스 |
Software Configuration Index |
|
10.4.5 |
SCM 레코드 |
SCM Records |
|
10.5 |
SCM 함정들 |
SCM Pitfalls |
|
10.6 |
변경 영향 분석 |
Change Impact Analysis |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 11 |
소프트웨어 품질 보증 |
Software Quality Assurance |
|
11.1 |
소개 : 소프트웨어 품질 및 소프트웨어 품질 보증(SQA) |
Introduction: Software Quality and Software Quality Assurance (SQA) |
|
11.1.1 |
소프트웨어 품질 정의하기 |
Defining Software Quality |
|
11.1.2 |
고품질 소프트웨어의 특징 |
Characteristics of High-Quality Software |
|
11.1.3 |
소프트웨어 품질 보증 |
Software Quality Assurance |
|
11.1.4 |
공통 품질 프로세스 및 제품 이슈의 예시 |
Examples of Common Quality Process and Product Issues |
|
11.2 |
효과적인 SQA와 효과적이지 않은 SQA의 특징 |
Characteristics of Effective and Ineffective SQA |
|
11.2.1 |
효과적인 SQA |
Effective SQA |
|
11.2.2 |
효과적이지 않은 SQA |
Ineffective SQA |
|
11.3 |
SQA 활동들 |
SQA Activities |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 12 |
인증 교섭 |
Certification Liaison |
|
12.1 |
인증 교섭이 무엇인가? |
What Is Certification Liaison? |
|
12.2 |
인증 당국과 커뮤니케이션하기 |
Communicating with the Certification Authorities |
|
12.2.1 |
인증 당국과의 조율에 대한 모범 사례 |
Best Practices for Coordinating with Certification Authorities |
|
12.3 |
소프트웨어 완수 요약 |
Software Accomplishment Summary |
|
12.4 |
SOI(Stage of Involvement) 감사 |
Stage of Involvement (SOI) Audits |
|
12.4.1 |
SOI 감사의 개요 |
Overview of SOI Audits |
|
12.4.2 |
소프트웨어 Job Aid의 개요 |
Overview of the Software Job Aid |
|
12.4.3 |
소프트웨어 Job Aid 사용하기 |
Using the Software Job Aid |
|
12.4.4 |
감사자에 대한 일반적인 권고사항 |
General Recommendations for the Auditor |
|
12.4.5 |
피감사자(지원자/개발자)를 위한 일반적인 권고사항 |
General Recommendations for the Auditee (the Applicant/Developer) |
|
12.4.6 |
SOI 리뷰 상세 |
SOI Review Specifics |
|
12.4.6.1 |
SOI 1 진입 기준, 예상 그리고 준비 권고사항 |
SOI 1 Entry Criteria, Expectations, and Preparation Recommendations |
|
12.4.6.2 |
SOI 2 진입 기준, 예상 그리고 준비 권고사항 |
SOI 2 Entry Criteria, Expectations, and Preparation Recommendations |
|
12.4.6.3 |
SOI 3 진입 기준, 예상 그리고 준비 권고사항 |
SOI 3 Entry Criteria, Expectations, and Preparation Recommendations |
|
12.4.6.4 |
SOI 4 진입 기준, 예상 그리고 준비 권고사항 |
SOI 4 Entry Criteria, Expectations, and Preparation Recommendations |
|
12.5 |
인증 비행 시험 전 소프트웨어 성숙도 |
Software Maturity Prior to Certification Flight Tests |
|
참고문헌 |
참고문헌 |
References |
|
Part 04 |
도구 인증과 DO-178C 부속서 |
Tool Qualification and DO-178C Supplements |
|
Chapter 13 |
DO-330과 소프트웨어 도구 인증 |
DO-330 and Software Tool Qualification |
|
13.1 |
소개 |
Introduction |
|
13.2 |
도구 인증 필요성과 레벨을 결정하기(DO-178C Section 12.2) |
Determining Tool Qualification Need and Level (DO-178C Section 12.2) |
|
13.3 |
도구 인증하기(DO-330 개요) |
Qualifying a Tool (DO-330 Overview) |
|
13.3.1 |
DO-330에 대한 필요성 |
Need for DO-330 |
|
13.3.2 |
DO-330 도구 인증 프로세스 |
DO-330 Tool Qualification Process |
|
13.4 |
특별한 도구 인증 주제들 |
Special Tool Qualification Topics |
|
13.4.1 |
FAA Order 8110.49 |
FAA Order 8110.49 |
|
13.4.2 |
도구 결정론 |
Tool Determinism |
|
13.4.3 |
추가적인 도구 인증 고려사항 |
Additional Tool Qualification Considerations |
|
13.4.4 |
도구 인증의 함정들 |
Tool Qualification Pitfalls |
|
13.4.5 |
DO-330과 DO-178C 부속서 |
DO-330 and DO-178C Supplements |
|
13.4.6 |
다른 분야를 위해 DO-330 사용하기 |
Using DO-330 for Other Domains |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 14 |
DO-331과 모델 기반 개발 및 검증 |
DO-331 and Model-Based Development and Verification |
|
14.1 |
소개 |
Introduction |
|
14.2 |
모델 기반 개발 및 검증의 잠재적인 이점 |
Potential Benefits of Model-Based Development and Verification |
|
14.3 |
모델 기반 개발 및 검증의 잠재적인 위험 |
Potential Risks of Model-Based Development and Verification |
|
14.4 |
DO-331 개요 |
Overview of DO-331 |
|
14.5 |
DO-331에 대한 인증 당국의 인식 |
Certification Authorities Recognition of DO-331 |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 15 |
DO-332와 객체 지향 기술 및 관련 기법 |
DO-332 and Object-Oriented Technology and Related Techniques |
|
15.1 |
객체 지향 기술의 소개 |
Introduction to Object-Oriented Technology |
|
15.2 |
항공 분야에서 OOT의 사용 |
Use of OOT in Aviation |
|
15.3 |
항공 분야 핸드북에서의 OOT |
OOT in Aviation Handbook |
|
15.4 |
FAA가 후원하는 OOT와 구조적 커버리지에 대한 연구 |
FAA-Sponsored Research on OOT and Structural Coverage |
|
15.5 |
DO-332 개요 |
DO-332 Overview |
|
15.5.1 |
계획 |
Planning |
|
15.5.2 |
개발 |
Development |
|
15.5.3 |
검증 |
Verification |
|
15.5.4 |
취약성 |
Vulnerabilities |
|
15.5.5 |
타입 안전성 |
Type Safety |
|
15.5.6 |
관련된 기법들 |
Related Techniques |
|
15.5.7 |
자주 묻는 질문 |
Frequently Asked Questions |
|
15.6 |
OOT 권고사항 |
OOT Recommendations |
|
15.7 |
결론 |
Conclusion |
|
참고문헌 |
참고문헌 |
References |
|
추천 자료 |
추천 자료 |
Recommended Readings |
|
Chapter 16 |
DO-333과 정형 기법 |
DO-333 and Formal Methods |
|
16.1 |
정형 기법에 대한 소개 |
Introduction to Formal Methods |
|
16.2 |
정형 기법이 무엇인가? |
What Are Formal Methods? |
|
16.3 |
정형 기법의 잠재적인 이점 |
Potential Benefits of Formal Methods |
|
16.4 |
정형 기법에 대한 어려움들 |
Challenges of Formal Methods |
|
16.5 |
DO-333 개요 |
DO-333 Overview |
|
16.5.1 |
DO-333의 목적 |
Purpose of DO-333 |
|
16.5.2 |
DO-333과 DO-178C의 비교 |
DO-333 and DO-178C Compared |
|
16.5.2.1 |
계획 및 개발 |
Planning and Development |
|
16.5.2.2 |
형상 관리, 품질 보증 그리고 인증 교섭 |
Configuration Management, Quality Assurance, and Certification Liaison |
|
16.5.2.3 |
검증 |
Verification |
|
16.6 |
다른 자료들 |
Other Resources |
|
참고문헌 |
참고문헌 |
References |
|
Part 05 |
특별한 주제들 |
Special Topics |
|
Chapter 17 |
커버되지 않은 코드 (데드 코드, 관련 없는 코드, 비활성화된 코드) |
Noncovered Code (Dead, Extraneous, and Deactivated Code) |
|
17.1 |
소개 |
Introduction |
|
17.2 |
관련 없는 코드와 데드 코드 |
Extraneous and Dead Code |
|
17.2.1 |
관련 없는 코드와 데드 코드의 늦은 발견을 피하기 |
Avoiding Late Discoveries of Extraneous and Dead Code |
|
17.2.2 |
관련 없는 코드 혹은 데드 코드를 평가하기 |
Evaluating Extraneous or Dead Code |
|
17.3 |
비활성화된 코드 |
Deactivated Code |
|
17.3.1 |
계획 |
Planning |
|
17.3.2 |
개발 |
Development |
|
17.3.3 |
검증 |
Verification |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 18 |
현장 적재가능 소프트웨어 |
Field-Loadable Software |
|
18.1 |
소개 |
Introduction |
|
18.2 |
현장 적재가능 소프트웨어가 무엇인가? |
What Is Field-Loadable Software? |
|
18.3 |
현장 적재가능 소프트웨어의 장점 |
Benefits of Field-Loadable Software |
|
18.4 |
현장 적재가능 소프트웨어의 어려움 |
Challenges of Field-Loadable Software |
|
18.5 |
현장 적재가능 소프트웨어 개발 및 검증하기 |
Developing and Loading Field-Loadable Software |
|
18.5.1 |
현장 적재가능하도록 시스템 개발하기 |
Developing the System to Be Field-Loadable |
|
18.5.2 |
현장 적재가능 소프트웨어 개발하기 |
Developing the Field-Loadable Software |
|
18.5.3 |
현장 적재가능 소프트웨어 로딩하기 |
Loading the Field-Loadable Software |
|
18.5.4 |
현장 적재가능 소프트웨어 수정하기 |
Modifying the Field-Loadable Software |
|
18.6 |
요약 |
Summary |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 19 |
사용자 수정가능 소프트웨어 |
User-Modifiable Software |
|
19.1 |
소개 |
Introduction |
|
19.2 |
사용자 수정가능 소프트웨어는 무엇인가? |
What Is User-Modifiable Software? |
|
19.3 |
UMS의 예시 |
Examples of UMS |
|
19.4 |
UMS를 위한 시스템 설계하기 |
Designing the System for UMS |
|
19.5 |
UMS를 수정하고 유지보수하기 |
Modifying and Maintaining UMS |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 20 |
실시간 운영체제 |
Real-Time Operating Systems |
|
20.1 |
소개 |
Introduction |
|
20.2 |
RTOS란 무엇인가? |
What Is an RTOS? |
|
20.3 |
왜 RTOS를 사용하는가? |
Why Use an RTOS? |
|
20.4 |
RTOS 커널과 그것을 지원하는 소프트웨어 |
RTOS Kernel and Its Supporting Software |
|
20.4.1 |
RTOS 커널 |
RTOS Kernel |
|
20.4.2 |
애플리케이션 프로그램 인터페이스 |
Application Program Interface |
|
20.4.3 |
보드 지원 패키지 |
Board Support Package |
|
20.4.4 |
디바이스 드라이버 |
Device Driver |
|
20.4.5 |
지원 라이브러리 |
Support Libraries |
|
20.5 |
안전 필수 시스템에 사용되는 RTOS의 특징 |
Characteristics of an RTOS Used in Safety-Critical Systems |
|
20.5.1 |
결정론적 |
Deterministic |
|
20.5.2 |
신뢰할 수 있는 성능 |
Reliable Performance |
|
20.5.3 |
호환가능한 하드웨어 |
Compatible with the Hardware |
|
20.5.4 |
호환가능한 환경 |
Compatible with the Environment |
|
20.5.5 |
결함 허용 |
Fault Tolerant |
|
20.5.6 |
헬스 모니터링 |
Health Monitoring |
|
20.5.7 |
인증가능성 |
Certifiable |
|
20.5.8 |
유지보수가능성 |
Maintainable |
|
20.5.9 |
재사용가능성 |
Reusable |
|
20.6 |
안전 필수 시스템에 사용되는 RTOS의 특성 |
Features of an RTOS Used in Safety-Critical Systems |
|
20.6.1 |
멀티태스킹 |
Multitasking |
|
20.6.2 |
보장되고 결정론적인 스케줄가능성 |
Guaranteed and Deterministic Schedulability |
|
20.6.2.1 |
파티션 간의 스케줄링 |
Scheduling between Partitions |
|
20.6.2.2 |
파티션 내의 스케줄링 |
Scheduling within Partitions |
|
20.6.3 |
결정론적 태스크 간 통신 |
Deterministic Intertask Communication |
|
20.6.4 |
신뢰할 수 있는 메모리 관리 |
Reliable Memory Management |
|
20.6.5 |
인터럽트 프로세싱 |
Interrupt Processing |
|
20.6.6 |
후크(Hook) 기능 |
Hook Functions |
|
20.6.7 |
강건성 체크하기 |
Robustness Checking |
|
20.6.8 |
파일 시스템 |
File System |
|
20.6.9 |
강건한 파티셔닝 |
Robust Partitioning |
|
20.7 |
고려해야 할 RTOS 이슈들 |
RTOS Issues to Consider |
|
20.7.1 |
고려해야 할 기술적인 이슈들 |
Technical Issues to Consider |
|
20.7.1.1 |
리소스 경합 |
Resource Contention |
|
20.7.1.2 |
우선순위 역전 |
Priority Inversion |
|
20.7.1.3 |
메모리 누수 |
Memory Leaks |
|
20.7.1.4 |
메모리 단편화 |
Memory Fragmentation |
|
20.7.1.5 |
태스크 간 간섭 |
Intertask Interference |
|
20.7.1.6 |
지터(Jitter) |
Jitter |
|
20.7.1.7 |
취약성들 |
Vulnerabilities |
|
20.7.2 |
고려해야 할 인증 이슈들 |
Certification Issues to Consider |
|
20.7.2.1 |
안전 서브셋을 생성하기 |
Creating a Safe Subset |
|
20.7.2.2 |
사용자 매뉴얼 |
User’s Manual |
|
20.7.2.3 |
리버스 엔지니어링 |
Reverse Engineering |
|
20.7.2.4 |
비활성화된 특성들 |
Deactivated Features |
|
20.7.2.5 |
복잡도 |
Complexity |
|
20.7.2.6 |
시스템과의 비연결성 |
Disconnect with the System |
|
20.7.2.7 |
코드 준수 이슈 |
Code Compliance Issues |
|
20.7.2.8 |
에러 처리 이슈 |
Error Handling Issues |
|
20.7.2.9 |
문제점 리포팅 |
Problem Reporting |
|
20.7.2.10 |
파티셔닝 분석 |
Partitioning Analysis |
|
20.7.2.11 |
다른 지원 소프트웨어 |
Other Supporting Software |
|
20.7.2.12 |
타깃 시험 |
Target Testing |
|
20.7.2.13 |
수정 |
Modifications |
|
20.8 |
RTOS 관련 다른 주제들 |
Other RTOS-Related Topics |
|
20.8.1 |
ARINC 653 개요 |
ARINC 653 Overview |
|
20.8.2 |
도구 지원 |
Tool Support |
|
20.8.3 |
오픈 소스 RTOS |
Open Source RTOSs |
|
20.8.4 |
멀티코어 프로세서, 가상화 그리고 하이퍼바이저 |
Multicore Processors, Virtualization, and Hypervisors |
|
20.8.5 |
보안 |
Security |
|
20.8.6 |
RTOS 선택을 위한 질문 |
RTOS Selection Questions |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 21 |
소프트웨어 파티셔닝 |
Software Partitioning |
|
21.1 |
파티셔닝에 대한 소개 |
Introduction to Partitioning |
|
21.1.1 |
파티셔닝: 보호의 서브셋 |
Partitioning: A Subset of Protection |
|
21.1.2 |
DO-178C와 파티셔닝 |
DO-178C and Partitioning |
|
21.1.3 |
강건한 파티셔닝 |
Robust Partitioning |
|
21.2 |
공유 메모리(공간 파티셔닝) |
Shared Memory (Spatial Partitioning) |
|
21.3 |
공유 중앙 처리 장치(시간 파티셔닝) |
Shared Central Processing Unit (Temporal Partitioning) |
|
21.4 |
공유 입력/출력 |
Shared Input/Output |
|
21.5 |
파티셔닝과 관련된 몇 가지 어려움 |
Some Partitioning-Related Challenges |
|
2.15.1 |
직접 메모리 액세스 |
Direct Memory Access |
|
2.15.2 |
캐시 메모리 |
Cache Memory |
|
2.15.3 |
인터럽트 |
Interrupts |
|
2.15.4 |
파티션 간 통신 |
Interpartition Communication |
|
21.6 |
파티셔닝에 대한 권고사항 |
Recommendations for Partitioning |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 22 |
구성 데이터 |
Configuration Data |
|
22.1 |
소개 |
Introduction |
|
22.2 |
용어 및 예시 |
Terminology and Examples |
|
22.3 |
파라미터 데이터에 대한 DO-178C 지침의 요약 |
Summary of DO-178C Guidance on Parameter Data |
|
22.4 |
권고사항 |
Recommendations |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 23 |
항공용 데이터 |
Aeronautical Data |
|
23.1 |
소개 |
Introduction |
|
23.2 |
DO-200A : Standards for Processing Aeronautical Data |
DO-200A: Standards for Processing Aeronautical Data |
|
23.3 |
FAA Advisory Circular 20-153A |
FAA Advisory Circular 20-153A |
|
23.4 |
항공용 데이터 프로세싱을 위해 사용되는 도구들 |
Tools Used for Processing Aeronautical Data |
|
23.5 |
항공용 데이터와 관련된 기타 업계 문서들 |
Other Industry Documents Related to Aeronautical Data |
|
23.5.1 |
DO-201A : Standards for Aeronautical Information |
DO-201A: Standards for Aeronautical Information |
|
23.5.2 |
DO-236B: Minimum Aviation System Performance Standards: Required Navigation Performance for Area Navigation |
DO-236B: Minimum Aviation System Performance Standards: Required Navigation Performance for Area Navigation |
|
23.5.3 |
DO-272C: User Requirements for Aerodrome Mapping Information |
DO-272C: User Requirements for Aerodrome Mapping Information |
|
23.5.4 |
DO-276A: User Requirements for Terrain and Obstacle Data |
DO-276A: User Requirements for Terrain and Obstacle Data |
|
23.5.5 |
DO-291B: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data |
DO-291B: Interchange Standards for Terrain, Obstacle, and Aerodrome Mapping Data |
|
23.5.6 |
ARINC 424: Standard, Navigation System Database |
ARINC 424: Standard, Navigation System Database |
|
23.5.7 |
ARINC 816-1: Embedded Interchange Format for Airport Mapping Database |
ARINC 816-1: Embedded Interchange Format for Airport Mapping Database |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 24 |
소프트웨어 재사용 |
Software Reuse |
|
24.1 |
소개 |
Introduction |
|
24.2 |
재사용가능한 컴포넌트 설계하기 |
Designing Reusable Components |
|
24.3 |
이전에 개발된 소프트웨어 재사용하기 |
Reusing Previously Developed Software |
|
24.3.1 |
민간 항공 제품에 사용하기 위해 PDS를 평가하기 |
Evaluating PDS for Use in Civil Aviation Products |
|
24.3.2 |
DO-178[ ]을 사용해서 개발되지 않은 PDS 재사용하기 |
Reusing PDS That Was Not Developed Using DO-178[ ] |
|
24.3.3 |
COTS 소프트웨어에 대한 추가적인 생각 |
Additional Thoughts on COTS Software |
|
24.4 |
제품 서비스 히스토리 |
Product Service History |
|
24.4.1 |
제품 서비스 히스토리의 정의 |
Definition of Product Service History |
|
24.4.2 |
제품 서비스 히스토리를 사용해서 신뢰를 추구하는 것의 어려움 |
Difficulties in Seeking Credit Using Product Service History |
|
24.4.3 |
제품 서비스 히스토리를 사용해서 신뢰를 주장할 때 고려해야 할 요인들 |
Factors to Consider When Claiming Credit Using Product Service History |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 25 |
리버스 엔지니어링 |
Reverse Engineering |
|
25.1 |
리버스 엔지니어링이란 무엇인가? |
What Is Reverse Engineering? |
|
25.2 |
리버스 엔지니어링의 예시 |
Examples of Reverse Engineering |
|
25.3 |
리버스 엔지니어링할 때 해결되어야 할 이슈들 |
Issues to Be Addressed When Reverse Engineering |
|
25.4 |
리버스 엔지니어링에 대한 권고사항 |
Recommendations for Reverse Engineering |
|
참고문헌 |
참고문헌 |
References |
|
Chapter 26 |
아웃소싱 및 해외 외주(Offshoring) 소프트웨어 라이프 사이클 활동 |
Outsourcing and Offshoring Software Life Cycle Activities |
|
26.1 |
소개 |
Introduction |
|
26.2 |
아웃소싱을 하는 이유 |
Reasons for Outsourcing |
|
26.3 |
아웃소싱의 어려움과 위험 |
Challenges and Risks in Outsourcing |
|
26.4 |
어려움과 위험을 극복하기 위한 권고사항 |
Recommendations to Overcome the Challenges and Risks |
|
26.5 |
요약 |
Summary |
|
참고문헌 |
참고문헌 |
References |
|
Appendix |
부록 |
Appendix |
|
Appendix A |
전이 기준 예시 |
Example Transition Criteria |
|
Appendix B |
실시간 운영체제 우려 영역 |
Real-Time Operating System Areas of Concern |
|
Appendix C |
안전 필수 시스템을 위한 실시간 운영체제를 선택할 때 고려해야 할 질문 |
Questions to Consider When Selecting a Real-Time Operating System for a Safety-Critical System |
|
Appendix D |
소프트웨어 서비스 히스토리 질문 |
Software Service History Questions |
|
찾아보기 |
찾아보기 |
- |