{"text_format":"2","workbook":"xlsx","n_sheets":2,"sheets":["Cover","SOI 1"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":2,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Cover","index":0,"n_rows":26,"n_cols":7,"rows_kept":26,"cut":false,"hidden":false,"merged":[[22,4,22,5],[22,6,22,8],[23,4,23,5],[24,4,24,5],[25,4,25,5],[25,6,25,8],[24,6,24,8],[19,4,19,5],[19,6,19,8],[20,4,20,5],[20,6,20,8],[21,4,21,5],[21,6,21,8],[18,4,18,5],[18,6,18,8],[2,1,11,12],[15,6,15,7],[16,6,16,7],[17,4,17,5],[17,6,17,8]]}
[]
[]
[null,"A DO-278A Process Compliance Document\nSOFTWARE QUALITY ASSURANCE RECORD\nFOR UTM SERVICE (Software Planning SW Quality Audit)\nDOCUMENT NUMBER: 10\nREVISION:-"]
{"$rows_empty":14}
[{"$nulls":4},"Department :",null,"QA"]
[{"$nulls":4},"Project :",null,"UTM SERVICE"]
[{"$nulls":4},"Owner :",null,"CHOI, HYUNSIK"]
[{"$nulls":4},"Date Last Updated :",null,"2025.06.10"]
[{"$nulls":4},"Last Updated By :",null,"CHOI, HYUNSIK"]
[{"$nulls":4},"Author  :",null,"CHOI, HYUNSIK"]
[{"$nulls":4},"Reviewer 1 :",null,"HAN, KOOKYI "]
[{"$nulls":4},"Reviewer 2 :",null,"JI, DEAHAN"]
[{"$nulls":4},"Approvaed By  :",null,"CHOI, HYUNSIK"]

{"sheet":"SOI 1","index":1,"n_rows":114,"n_cols":7,"rows_kept":114,"cut":false,"hidden":false,"merged":[]}
[null,"SOFTWARE QUALITY ASSURANCE PROCESS CHECKLISTS"]
[null,"• Activities for Stage of Involvement #1 – PLANNING  REVIEW"]
[]
[null,"Item #","SOI #1 Evaluation Activity/Question",null,"DO-278A/DO-332 objective(s)","Complies","Reference"]
[null,1.1000000000000001,"Review all plans (PSAC, SCMP, SQAP, SDP, SVP, software tool qualification plans, etc.) and standards.  Based on your review of all the plans, consider the following questions:","모든 계획(PSAC, SCMP, SQAP, SDP, SVP, 소프트웨어 도구 인증 계획 등) 및 표준을 검토하십시오.  모든 계획을 검토한 후 다음 질문을 고려하십시오."]
[null,"1.1.1","Has the planning data been signed and put under CM (CC1 or CC2 as appropriate for the software level)? Verify there is objective evidence of coordination (e.g., authorized signatures) from all organizations controlled and affected by the software plans and standards.","계획 데이터에 서명하여 CM(소프트웨어 레벨에 적합한 CC1 또는 CC2) 아래에 넣었는가? 소프트웨어 계획 및 표준에 의해 제어되고 영향을 받는 모든 조직의 조정(예: 승인된 서명)에 대한 객관적인 증거가 있는지 확인하십시오.","A-1, #1-7","Y","Ref. 12.2 Software Lifecycle Data Category"]
[null,"1.1.2","Have the plans and standards been reviewed and approved by a software designee (as authorized)?","소프트웨어 설계자가 계획 및 표준을 검토하고 승인하였는가?","A-1, #1-7","Y","PSAA\n9. Organization\n\nRef. PSAA, SDP, SVP, SCMP, SQAP, SRStd, SDStd\nAuthorized Signature of Software leader"]
[null,"1.1.3","Are plans and standards cited complete, clear, and consistent?","계획 및 기준이 완전하고 명확하며 일관성이 있는가?","A-1, #1, 7","N","Some of SVR issues are remained\nAfter DER Review 18th to 20th on JUNE with DER\n\nPALNETWORKS will do Corrective action about PR based on SVR and DER Comments"]
[null,"1.1.4","Were reviews of the plans and standards conducted and review results retained? And, were review deficiencies corrected? (See section 4.6 of DO-278A.)","시행된 계획 및 표준에 대한 검토와 검토 결과를 유지하였는가? 그리고, 검토결함은 수정되었는가? (DO-278A의 섹션 4.6 참조)","A-1, #6, 7","Y","SVP 9.4 Verification Method and Tools\n\nSDP 5 Software Development Life Cycle\n\nPASS 7 Software Life Cycle Data"]
[null,"1.1.5","Do the plans and standards comply with the content as specified in DO-278A section 11 (i.e., sections 11.1 through 11.8)? Note: The plans and standards are not required to be packaged as identified in 11.1 through 11.8; however, the items specified in 11.1 through 11.8 should be documented somewhere in the plans and standards.","계획 및 표준이 DO-278A 섹션 11(예: 섹션 11.1 ~ 11.8)에 명시된 내용을 준수하고 있는가? 참고: 계획과 표준은 11.1에서 11.8까지에 명시된 대로 포장할 필요는 없지만, 11.1에서 11.8까지에 명시된 항목은 계획과 표준의 어딘가에 문서화되어야 한다.","A-1, #1-7","N","Ref. PSAA, SDP, SVP, SCMP, SQAP, SRStd, SDStd\nSee abovie 1.1.3"]
[null,"1.1.6","Do the plans and standards address the software change process and procedures for the airborne software and tools (if tools are used)?","계획과 표준은 공중 소프트웨어와 도구의 소프트웨어 변경 프로세스와 절차를 다루고 있는가?","A-1, #1, 2","Y","PSAA \n8.11 Deviations and Modifications to Plans\n\nSCMP \n8 Change Control and Change Review\n12 Configuration Management Data"]
[null,"1.1.7","Are all software tools identified in the plans and is rationale included for why each does or does not need to be qualified?","모든 소프트웨어 툴이 계획서에 식별되었고, 각 툴이 자격 요건을 갖추거나 갖추지 않아도 되는 이유에 대한 근거가 포함되었는가?","A-1 #4","N/A","PSAA\n10.2 Tool Qualification\n\nPALNETWORKS don't apply for DO-330, TQ"]
[null,"1.1.8","Are the inputs, activities, transition criteria, and outputs specified for each process?","각 프로세스에 대해 입력, 활동, 전환 기준 및 출력이 지정되어 있는가?","A-1, #1","Y","SDP\n5.1 Software Requirements Process\n5.2 Software Design Process\n5.3 Software Coding Process\n5.4 Software Integration Process\n\nSQAP\n5 Transition Criteria"]
[null,"1.1.9","Are the development and verification life cycle activities defined in sufficient detail (reference DO-278A sections 11.1-11.3) to satisfy section 4.2 of DO-278A?","개발 및 검증 수명주기 활동은 DO-278A의 섹션 4.2를 만족하기에 충분한 세부사항(DO-278A 섹션 11.1-11.3 참조)으로 정의되어 있는가?","A-1, #1-7","Y","PSAA\n2 System Overview\n3 Software Overview\n6 Software Life Cycle Processes\n7 Software Life Cycle Data\n8 Schedule\n10 Additional Considerations\n\nSDP\n4 Software Standards\n5 Software Development Life Cycle\n9 Software Development Environment\n\nSVP\n2 Software Verification Process"]
[null,"2010-01-01","Do the plans and standards meet the DO-278A planning objectives in Table A-1? (i.e., Is each plan and standard internally consistent? Are the plans and standards consistent with each other? Is the software life cycle defined? Are the transition criteria defined?)","계획과 표준은 표 A-1의 DO-278A 계획 목표를 충족하는가? (즉, 각 계획과 표준은 내부적으로 일관성이 있는가? 계획과 기준이 서로 일치하는가? 소프트웨어 수명주기가 정의되어 있는가? 전환기준이 규정되어 있는가?)","A-1, #7","N","PSAA\n6 Software Life Cycle Processes\nSDP\n4 Software Standards\n5 Software Development Life Cycle\nSVP \n2.1 Software Reviews\nSee above 1.1.3"]
[null,"2011-01-01","If the plans and standards are followed, would this ensure that all applicable DO-278A objectives in Tables A-2 through A-10 are met? (I.e., do the plans and standards address how each of the applicable DO-278A objectives will be satisfied?)","계획과 표준을 준수하는 경우, 표 A-2에서 A-10까지의 모든 적용 가능한 DO-278A 목표가 충족되는지 확인할 수 있는가? (즉, 계획과 표준은 적용 가능한 각 DO-278A 목표를 어떻게 달성할 것인지를 다루고 있는가?)","A-2 to A-10\n(All Objectives)","Y","PSAA\n12 DO-278A Planned Compliance Matrix"]
[null,"2012-01-01","Are the plans sufficiently clear and detailed to allow the development and verification engineers to follow them?","개발 및 검증 엔지니어가 계획을 따를 수 있도록 충분히 명확하고 상세하고 있는가?","A-1, #1-7","Y","SDP\n4 Software Standards\n5 Software Development Life Cycle\nSVP\n2 Software Verification Process"]
[null,"2013-01-01","Are the interfaces and communication channels with the system development processes addressed in the plans and well defined? Evaluate processes for flow down of system requirements (functional, performance, operational, safety-related, system architecture safety features, databus usage, I/O device usage) and for clarifying ambiguous system requirements. Determine if the software verification process will be claiming “formal test credit” for testing conducted by the system verification and validation processes, what kind of credit, and how much credit. Determine how and the environment that the developer will be performing worst-case timing analyses, memory usage analysis, etc.","시스템 개발 프로세스와의 인터페이스 및 통신 채널이 계획에서 다루어지고 잘 정의되고 있는가? 시스템 요구사항(기능, 성능, 운영, 안전 관련, 시스템 아키텍처 안전 기능,  databus 사용, I/O 장치 사용)의 흐름 하향 및 모호한 시스템 요구사항을 명확히 하기 위한 프로세스를 평가한다. 소프트웨어 검증 프로세스가 시스템 검증 및 검증 프로세스에 의해 수행되는 시험에 대해 \"공식 테스트 크레딧\"을 청구할 것인지, 어떤 크레딧의 종류, 얼마의 크레딧을 청구할 것인지를 결정한다. 개발자가 최악의 타이밍 분석, 메모리 사용량 분석 등을 수행하는 방법과 환경을 결정한다.","A-1, #1, 7","N","PSAA\n2 System Overview\non architecture, there is no data bus, I/O, interface. And also, there is no system diagram.\nPALNETWORKS just described at configuration diagram"]
[null,"2014-01-01","Are the interfaces and communication channels with the system safety assessment process addressed in the plans and well defined? Evaluate the flow down of safety-related requirements (software partitioning, safety monitoring software, built-in test, etc.) and safety objectives from the system safety assessment (SSA) process to the software processes, and the feedback from the software requirements and design processes of derived requirements to the SSA process for evaluation.","시스템 안전성평가 프로세스와의 인터페이스와 통신채널을 계획에서 다루고 있으며 잘 정의하고 있는가? 시스템 안전성 평가(SSA) 프로세스에서 소프트웨어 프로세스에 이르기까지 안전 관련 요구사항(소프트웨어 분할, 안전 모니터링 소프트웨어, 내장 테스트 등) 및 안전 목표의 흐름과 파생 요구사항의 소프트웨어 요구사항 및 설계 프로세스에서 평가용 SSA 프로세스에 대한 피드백을 평가한다.","A-1, #1, 7","N","PSAA\n2.5 Safety and Assurance Perspective\n\nsee above 1.1.13"]
[null,"2015-01-01","Are the interfaces and communication channels with the complex electronic hardware development and procurement processes addressed in the plans and well defined? Evaluate the processes for documenting and communicating software dependencies and interactions with the hardware  and its development/ procurement processes, and for hardware dependencies on the software and its development and verification processes. Determine the process used to convey hardware safety features (e.g., watchdog timers, built-in test, memory management unit, I/O device, processor features (cache, registers, priorities, schedulers, supervisor/user modes, etc.)) and hardware changes to the software processes, and how the software processes will address them.","복잡한 전자 하드웨어 개발 및 조달 프로세스와의 인터페이스와 통신 채널이 계획에서 다루어지고 잘 정의되고 있는가? 소프트웨어 종속성과 하드웨어 및 하드웨어의 개발/구매 프로세스와의 상호작용을 문서화하고 전달하는 프로세스, 소프트웨어 및 소프트웨어 개발 및 검증 프로세스에 대한 하드웨어 종속성을 평가한다. 하드웨어 안전 기능(예: 감시 타이머, 내장 테스트, 메모리 관리 장치, I/O 장치, 프로세서 기능(캐시, 레지스터, 우선순위, 스케줄러, 감독자/사용자 모드 등) 및 소프트웨어 프로세스에 대한 하드웨어 변경 사항 및 소프트웨어 프로세스에서 이를 처리하는 방법을 결정한다.","A-1, #1, 7","N","N/A\n\nsee above 1.1.13"]
[null,1.2,"Determine if additional considerations defined in Section 12 of DO-278A have been documented and addressed in the plans.  Consider the following questions:","DO-278A의 섹션 12에서 정의한 추가 고려사항이 계획에서 문서화되고 다루어졌는지를 결정한다.  다음 질문을 고려하십시오."]
[null,"1.2.1","Are such items as previously developed software, COTS software, user-modifiable software, field- loadable software, option-selectable software, multiple-version dissimilar software, product service history, alternative methods of compliance, etc. identified and addressed in the plans?","이전에 개발된 소프트웨어, COTS 소프트웨어, 사용자 수정 가능한 소프트웨어, 현장 로딩 가능한 소프트웨어, 옵션 선택 가능한 소프트웨어, 다중 버전 차이 소프트웨어, 제품 서비스 이력, 대체 컴플라이언스 방법 등과 같은 항목이 계획에서 식별되고 해결되었는가?","A-1, #4","Y","PSAA\n3.7 Commercial Off-The-Shelf Software\n9 Additional Considerations"]
[null,"1.2.2","If the developer plans on using previously developed software (PDS) for the current development, consider the following questions:\n•      Have any issues regarding modification to legacy systems or reuse of previously developed software been addressed in the plans? (Reference chapter 10 of Order 8110.49 for use of DO-278A for legacy systems.)\n•      If PDS from legacy systems is intended to be used, does the service history of the system support reuse of its software?\n•      Are there any airworthiness directives, service bulletins, in-work National Transportation Safety Board safety recommendations, or unresolved problem reports with safety, functional, performance, operational or maintenance issues for the legacy system or any proposed PDS?\n•      Does the PDS have a satisfactory service history?\n•      Does the developer intend to make any modifications to PDS? Are plans and processes defined for managing, controlling, and verifying those changes (in compliance with DO-278A section 12.1, 12.1.1-12.1.6)?\n•      Is the PDS or legacy system software used in an identical manner and executed on the same hardware and in the same environment as its previous uses?","개발자가 현재 개발에 앞서 개발한 소프트웨어(PDS)를 사용할 계획인 경우 다음 질문을 고려하십시오.\n• 기존 시스템에 대한 수정 또는 이전에 개발된 소프트웨어의 재사용과 관련된 문제가 계획에서 해결되었는가? (기존 시스템에 대한 DO-278A 사용에 대한 주문서 8110.49의 10장 참조)\n• 레거시 시스템의 PDS를 사용하고자 하는 경우, 시스템의 서비스 이력이 해당 소프트웨어의 재사용을 지원하는가?\n• 기존 시스템 또는 제안된 PDS에 대한 안전성, 기능, 성능, 운영 또는 유지 보수 문제와 관련된 내공성 지침, 서비스 게시판, 작업 중 국가 교통 안전 위원회 안전 권고 또는 미해결 문제 보고서가 있는가?\n• PDS에 만족스러운 서비스 기록이 있는가?\n• 개발자가 PDS를 수정할 의향이 있는가? 이러한 변경사항의 관리, 통제 및 확인을 위한 계획과 프로세스가 규정되어 있는가(DO-278A 섹션 12.1, 12.1.1-12.1.6에 따름)\n• PDS 또는 레거시 시스템 소프트웨어가 이전 사용과 동일한 방식으로 사용되었고 동일한 하드웨어 및 환경에서 실행되었는가?","A-1, #4","N/A","PSAA\n9.1 Previously Developed Software"]
[null,"1.2.3","Verify that software tools are identified and explained in the plans. Consider the following questions:\n•      Do the plans provide rationale for why tools do or do not need to be qualified? (I.e., Does the use of tools result in the elimination, reduction, or automation of processes or activities found in DO-278A? Is the output of the tool verified by manual (review) or other means (another tool or activity)?)\n•      Is service history claimed for the use of any tool? If so, has the tool changed or is it being used in the same way as previously used? Does the documented tool service history support the intended use for the current development?","소프트웨어 도구가 계획에 식별되고 설명되어 있는지 확인하십시오. 다음 질문을 고려하십시오.\n• 이 계획에서 도구의 자격을 획득할 필요가 없는 이유에 대한 근거를 제공하고 있는가? (즉, 도구의 사용이 DO-278A에서 발견된 프로세스 또는 활동의 제거, 감소 또는 자동화를 초래하는가? 수동(검토) 또는 기타 수단(다른 도구 또는 활동)으로 공구의 출력이 확인되었는가?)\n• 툴 사용에 대한 서비스 기록이 요청되었는가? 만약 그렇다면, 툴이 변경되었는가, 아니면 이전에 사용했던 것과 동일한 방식으로 사용되고 있는가? 문서화된 툴 서비스 이력이 현재 개발 목적의 사용을 지원하고 있는가?","A-1, #3, 4","Y","PSAA\n9.2 Tool Qualification"]
[null,"1.2.4","Are tools to be qualified supported with a tool qualification plan (either in the PSAC or in a separate document)? Verify that tools are properly categorized into development, configuration management, or verification tools. Verify that the plan for qualification of tools is documented and adequate for the specified tool use.\nNote: Section 12.2 of DO-278A and Chapter 9 of Order 8110.49 provide specific guidelines regarding software tool qualification.","자격을 갖춘 도구가 (PSAC 또는 별도 문서에서) 도구 자격 인정 계획으로 지원되고 있는가? 도구가 개발, 구성 관리 또는 검증 도구로 적절하게 분류되어 있는지 확인하십시오. 도구 자격에 대한 계획이 문서화되어 있고 지정된 도구 사용에 적합한지 확인한다.\n참고: DO-278A의 섹션 12.2와 주문서 8110.49의 9장은 소프트웨어 도구 자격에 관한 구체적인 지침을 제공한다.","A-1, #3, 4","N/A","PSAA\n1.2.1\tExclusive section\nPALNETWORKS don’t apply for these below:\n"]
[null,"1.2.5","Are there unique additional considerations associated with the project (unique alternative means or methods of compliance, unique approaches to development, verification, SCM, SQA), proposals that don’t comply with FAA national or Directorate policy or issue papers, etc.? If so:\n•      Have national or directorate software and systems personnel reviewed and approved any unique additional considerations?\n•      Is rationale for acceptance or rejection of developer/applicant’s proposals well documented?\n•      Did the proposal and agreement/rejection result in new policy, an issue paper, or other means of documenting the decision?\n•      Did the decision result in any precedence for future system or software approvals?","프로젝트와 관련된 고유한 추가 고려사항(독특한 대체 수단 또는 준수 방법, 개발에 대한 고유한 접근법, 검증, SCM, SQA), FAA 국가 또는 이사 정책 또는 발행 서류에 부합하지 않는 제안 등)이 있는가? 만약 그렇다면:\n• 국가 또는 이사 소프트웨어 및 시스템 담당자가 고유한 추가 고려 사항을 검토하고 승인하였는가?\n• 개발자/신청자의 제안을 수락 또는 거절한 근거가 충분히 문서화되어 있는가?\n• 제안서 및 합의/거부 결과 새로운 정책, 발행서 또는 기타 결정문 문서화 수단이 되었는가?\n• 향후 시스템 또는 소프트웨어 승인에 대한 우선 순위가 결정되었는가?","A-1, #4","N/A","PSAA\n9 Additional Considerations"]
[null,"1.2.6","Are issue papers or national/directorate policy required for any of the additional considerations? If so, do the plans and standards address how compliance with the issue papers and/or national/directorate policy will be achieved?","추가 고려사항에 대하여 발행서류 또는 국가/지휘정책이 필요한가? 만약 그렇다면, 계획과 표준은 발행서 및/또는 국가/감독 정책의 준수를 어떻게 달성할 것인가?","A-1, #4","N/A","No issues are identified."]
[null,"1.2.7","Have all foreign certification issues (e.g., certification review items, certification action items, review findings/issues/actions, etc.) been addressed (if a joint certification or validation project)? Additionally, do the plans and standards address how the foreign certification authority issues and concerns will be addressed?","모든 외국 인증 문제(예: 인증 검토 항목, 인증 조치 항목, 검토 결과/이슈/조치 등)를 해결하였는가(공동 인증 또는 유효성 확인 프로젝트인 경우) 또한, 계획과 표준은 외국 인증기관의 문제 및 우려사항을 다루는 방법을 다루고 있는가?","A-1, #4","N/A","No issues are identified."]
[null,"1.2.8","Is reverse engineering being planned for any PDS? If so:\n•      Has the rationale for reverse engineering been documented and adequately justified (typically in the “additional considerations” section of the PSAC)?\n•      Has the reverse engineering effort been planned (in the PSAC and other plans)?\n•      Are processes and procedures well defined?\n•      Is the reverse engineering life cycle documented?\n•      Does the reverse engineering approach meet DO- 278A objectives?\n•      How will the high-level requirements be created? Is the plan adequate?\n•      Do transition criteria and traceability exist? Are they adequate?\nNote: See CAST-18 [6] for specific certification concerns regarding reverse engineering. In some cases, an issue paper may be required, if the plans do not address the DO-278A objectives compliance.","PDS를 위해 역공학을 계획하고 있는가? 만약 그렇다면:\n• 역공학의 근거를 문서화하고 적절히 정당화하였는가(일반적으로 PSAC의 \"추가 고려사항\" 섹션에서)?\n• 역 공학 노력이 계획 되었습니까 (PSAC 및 기타 계획에서)?\n• 프로세스 및 절차가 잘 정의되어 있는가?\n• 역설계 수명주기를 문서화하였는가?\n• 역설계 접근법이 DO- 278A 목표를 충족하는가?\n• 높은 수준의 요구사항은 어떻게 만들어질 것인가? 그 계획은 충분한가?\n• 전환 기준 및 추적가능성이 존재하는가? 그들은 충분한가?\n참고: 역 엔지니어링과 관련된 특정 인증 문제는 CAST-18 [6]을 참조하십시오. 어떤 면에서는\n계획에서 DO-278A 목표 준수를 다루지 않는 경우, 발행서가 필요할 수 있다.","A-1, #4","N/A","PDS has not used."]
[null,1.3,"Review PSAC and consider the following questions:","PSAC를 검토하고 다음 질문을 고려하십시오."]
[null,"1.3.1","Does the PSAC adequately address the proposed contents described in DO-278A, Section 11.1? If not, where are the contents documented? [Note: If it is documented in another data item, that data item will need to be evaluated before the PSAC can be approved. Also, that data item should be configuration controlled to the same CC level as the PSAC.","PSAC는 DO-278A, 섹션 11.1에 기술된 제안된 내용을 적절히 다루고 있는가? 그렇지 않은 경우, 내용은 어디에서 문서화되었는가? [참고: 다른 데이터 항목에 문서화되면 PSAC가 승인되기 전에 해당 데이터 항목을 평가해야 한다. 또한, 그 데이터 항목은 PSAC와 동일한 CC 레벨로 구성되어야 한다.","A-1, #1-7\nA-10, #2","N","PSAA\n2. System Overview\n3 SOFTWARE OVERVIEW\n5 SOFTWARE LIFE CYCLE\n6 SOFTWARE LIFE CYCLE DATA\n7 SCHEDULE\n9 ADDITIONAL CONSIDERATIONS\n\nsee above 1.1.13"]
[null,"1.3.2","Does the PSAC address the following questions regarding changes to plans and standards:\n•      Is a process in place to address changes to plans and standards that may occur throughout the development process?\n•      Are there plans and processes to address any deviations to plans and standards?\n•      Do the deviations require justification and rationale for why they are acceptable for this project?\n•      Will applicable aspects of the software plans, standards and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards and procedures?\n•      Are the plans and standards under change control?","PSAC는 계획 및 표준 변경에 관한 다음 질문을 다루고 있는가?\n• 개발 프로세스 전반에 걸쳐 발생할 수 있는 계획 및 표준의 변경사항을 해결하기 위한 프로세스가 시행되고 있는가?\n• 계획 및 표준의 편차를 해결하기 위한 계획 및 프로세스가 있는가?\n• 편차가 이 프로젝트에 허용 가능한 이유에 대한 정당성과 근거를 요구하는가?\n• 소프트웨어 계획, 표준 및 절차의 해당 측면이 승인된 계획, 표준 및 절차의 준수를 보장하기 위해 시스템 및 하청업체의 하위 계층 공급업체에 전달될 것인가?\n• 계획 및 표준이 변경 통제 하에 있는가?","A-1, #1, 2","Y","PSAA\n6.2 Right Side – Verification \n6.3 Software Planning Process\n6.4.2 Software Design Process\n6.4.3 Software Coding Process\n6.4.4 Integration Process"]
[null,"1.3.3","Does the system safety assessment adequately support the software level proposed in the PSAC? If the software level is lower than what the system safety assessment suggests, is there adequate justification (e.g., through system architecture, safety feature, redundancy, fail safe design techniques, partitioning)?\n[Note: This determination will likely require input from the systems engineer.]","시스템 안전성 평가는 PSAC에서 제안된 소프트웨어 수준을 적절히 지원하고 있는가? 소프트웨어 레벨이 시스템 안전성 평가에서 제시하는 것보다 낮은 경우, 적절한 정당성이 있는가(예: 시스템 아키텍처, 안전 기능, 중복성, 고장 안전 설계 기법, 분할을 통한)?\n[참고: 이 결정은 시스템 엔지니어의 입력이 필요할 것 같다.]","A-1, #1-4","Y","PSAA\n2.5 Safety and Assurance Perspective"]
[null,1.4,"Review SDP and consider the following questions:","SDP를 검토하고 다음 질문을 고려하십시오."]
[null,"1.4.1","If the SDP is followed, will the DO-278A objectives defined in Table A-2 be met?\n(Note: Some objectives in Tables A-3, A-4, and A-5 may also be addressed in the SDP.)","SDP를 준수할 경우 표 A-2에 정의된 DO-278A 목표가 달성될 것인가?\n(참고: 표 A-3, A-4 및 A-5의 일부 목표는 SDP에서도 다룰 수 있다.)","A-2, #1-7","Y","SDP\n4 Software Standards\n5 Software Development Life Cycle\n9 Software Development Environment"]
[null,"1.4.2","Does the SDP adequately address the proposed contents described in DO-278A, Section 11.2?\nIf not, are the contents included in another plan?","SDP는 DO-278A, 11.2절에 기술된 제안된 내용을 적절히 다루고 있는가?\n만약 그렇지 않다면, 그 내용은 다른 계획에 포함되어 있는가?","A-1, #1-4","Y","SDP\n5 Software Development Life Cycle\n9 Software Development Environment"]
[null,"1.4.3","Are the software development processes defined in sufficient detail to ensure proper implementation of the software life cycle processes and model proposed for the project? Are transition criteria clear and enforceable?","소프트웨어 개발 프로세스는 프로젝트에 제안된 소프트웨어 수명주기 프로세스와 모델을 적절히 구현할 수 있도록 충분히 상세하게 정의되어 있는가? 전환 기준이 명확하고 시행 가능한가?","A-1, #1-4","Y","SDP \n5.1 Software Requirements Process\n5.2 Software Design Process\n5.3 Software Coding Process\n5.4 Software Integration Process"]
[null,"1.4.4","Will applicable aspects of the SDP, development environment, and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?","SDP, 개발 환경 및 절차의 해당 측면이 승인된 계획, 표준 및 절차에 대한 준수를 보장하기 위해 시스템 및 하청업체의 하위 계층 공급업체에 전달될 것인가?","A-1, #1-4","N/A","SCMP \n14 Supplier Control\nN/A"]
[null,"1.4.5","Are software development standards referenced in the SDP?","SDP에서 소프트웨어 개발 표준을 참조하고 있는가?","A-1, #1, 3, 5","Y","SDP\n4 Software Standards"]
[null,"1.4.6","Has the software development environment been adequately defined (e.g., documentation tools, requirements definition and capture tools, traceability tools, design tools (including architecture, derived requirements and low-level requirements definition and capture tools), coding tools (including code templates, code editors, compiler options and optimizations to be used), integration tools (including linkage editors and loaders, linking and loading procedures and tools), development host computer environment, tools to ensure protection of baselined software life cycle data such as configuration management and control tools, access privileges, etc.)? Additionally:\n•      Are tool users’ guides, restrictions, and limitations available and known by the software developers using them?\n•      Do any of the tools support enforcement of the software standards, transition criteria, data baselining and approval process, etc.? For example: (1) does the code editor tool or compiler enforce any coding rules, restrictions, or limitations? (2) does the document control (CM system) enforce access privileges to data and ensure no unauthorized changes to baselined data?","소프트웨어 개발 환경이 적절하게 정의되었는가(예: 문서화 도구, 요건 정의 및 캡처 도구, 추적가능성 도구, 설계 도구(건축, 파생 요구사항 및 낮은 수준의 요구사항 정의 및 캡처 도구 포함), 코딩 도구(코드 템플릿, 코드 편집기, 컴파일러 옵션 및 운영 포함)사용할 시간화, 통합 도구(링크 편집기 및 로더, 링크 및 로딩 절차 및 도구 포함), 개발 호스트 컴퓨터 환경, 구성 관리 및 제어 도구, 액세스 권한 등 기본 소프트웨어 수명주기 데이터의 보호를 보장하는 도구 등? 추가:\n• 소프트웨어 개발자가 도구 사용 설명서, 제한사항 및 제한사항을 이용할 수 있으며 이를 알고 있는가?\n• 소프트웨어 표준의 시행, 전환 기준, 데이터 베이스링 및 승인 프로세스 등을 지원하는 툴이 있는가? 예: (1) 코드 편집기 도구 또는 컴파일러는 코딩 규칙, 제한 또는 제한을 시행하는가? (2) 문서 제어(CM 시스템)는 데이터에 대한 접근 권한을 적용하고 기본 데이터에 대한 무단 변경을 보장하지 않는가?","A-1, #3","Y","SDP\n9 Software Development Environment"]
[null,"1.4.7","What kind of compiler is being proposed? Does the applicant have experience with the compiler?\nHave the compiler options and optimization been identified?\n(Note: Changes to compiler options and optimization may invalidate previous tests and coverage analysis.)","어떤 종류의 컴파일러가 제안되고 있는가? 신청자는 컴파일러 경험이 있는가?\n컴파일러 옵션 및 최적화가 확인되었는가?\n(참고: 컴파일러 옵션 및 최적화를 변경하면 이전 테스트 및 적용 범위 분석이 무효화될 수 있음)","A-1, #3","Y","SDP \n4.1 Language Selection\n9.3 Coding Method and Tools"]
[null,"1.4.8","Is the programming language and operating system specified and will they meet the objectives of DO- 278A?\n(Note: Some language and operating system choices may produce non-deterministic results and therefore may not meet the objectives of DO-278A.)","프로그래밍 언어와 운영체제가 명시되어 있으며, DO- 278A의 목적을 달성할 것인가?\n(참고: 일부 언어 및 운영 체제 선택은 비결정적인 결과를 초래할 수 있으므로 DO-278A의 목적을 충족하지 못할 수 있다.)","A-1, #3","Y","SDP \n4.1 Language Selection\n5.3 Software Coding Process\n9 Software Development Environment"]
[null,"1.4.9","Is the “host” software development environment similar to or identical to the target environment? Consider the following questions:\n•      Will a different compiler, linker, or loader be used when integrating the software into the target environment than will be used in the “host” environment?\n•      Have all differences been identified, analyzed and justified? (For example, will the results of verification (analyses and testing) conducted on software in the host environment still be valid for the software in the target environment?)\n•      Will timing, memory and resource management analyses and testing have to be repeated for the target environment?","\"호스트\" 소프트웨어 개발 환경이 대상 환경과 유사하거나 동일한가? 다음 질문을 고려하십시오.\n• 소프트웨어를 대상 환경에 통합할 때 \"호스트\" 환경에서 사용되는 것과 다른 컴파일러, 링크 또는 로더를 사용할 것인가?\n• 모든 차이가 확인, 분석 및 정당화되었는가? (예를 들어, 호스트 환경의 소프트웨어에 대해 수행된 검증(분석 및 테스트) 결과가 여전히 대상 환경의 소프트웨어에 유효할 것인가?)\n• 목표 환경에 대해 타이밍, 메모리 및 리소스 관리 분석 및 테스트를 반복해야 하는가?","A-1, #3","Y","SDP \n9 Software Development Environment"]
[null,1.5,"Review the SCM plan and consider the following questions:","SCM 계획을 검토하고 다음 질문을 고려하십시오."]
[null,"1.5.1","If the SCM plan is followed, will the DO-278A objectives defined in Table A-8 be met?","SCM 계획을 준수할 경우 표 A-8에 정의된 DO-278A 목표가 충족되는가?","A-8, #1-6","N","SCMP\nneed to define Configuration Item indetail"]
[null,"1.5.2","Are the CM processes described in Section 7.0 of DO-278A in sufficient detail (Ref. 178B Sections 11.4) to satisfy Section 4.2?","DO-278A의 섹션 7.0에 설명된 CM 프로세스가 섹션 4.2를 만족하기에 충분한 세부사항(참고문헌 178B 섹션 11.4)에 설명되어 있는가?","A-8, #1-6","Y","SCMP\n1.1 Purpose\n3 Configuration Identification\n7 Problem Reporting\n8 Change Control and Change Review\n9 Configuration Status Accounting"]
[null,"1.5.3","Does the SCM plan adequately address the proposed contents described in DO-278A, Section 11.4? If not, are the contents included in another plan?","SCM 계획은 DO-278A, 섹션 11.4에 기술된 제안된 내용을 적절히 다루고 있는가? 만약 그렇지 않다면, 그 내용은 다른 계획에 포함되어 있는가?","A-8, #1-6","Y","SCMP\n1.1 Purpose\n3 Configuration Identification\n7 Problem Reporting\n8 Change Control and Change Review\n9 Configuration Status Accounting"]
[null,"1.5.4","Does the SCM plan provide for the following items?\n•      Configuration identification of software life cycle data.\n•      Baselining of all configuration control 1 (CC1) data.\n•      Problem reporting, change control, and configuration status accounting.\n•      Archival, retrieval, and release.","SCM 계획은 다음 항목을 제공하고 있는가?\n• 소프트웨어 수명 주기 데이터의 구성 식별.\n• 모든 구성 제어 1(CC1) 데이터의 기초.\n• 문제 보고, 변경 제어 및 구성 상태 계정\n• 보관, 검색 및 릴리스","A-8, #1-6","Y","SCMP\n3 Configuration Identification\n7 Problem Reporting\n8 Change Control and Change Review"]
[null,null,"•       Data retention provisions supporting airworthiness requirements.\n•      Software load control and part numbering to include any additional considerations required for electronic part numbering.\n•      Configuration management of the software life cycle development environment includes tools.\n•       All DO-278A life cycle data to be maintained consistently with the configuration control category associated with the software level.","• 내공성 요구사항을 지원하는 데이터 보존 규정\n• 전자 부품 번호 부여에 필요한 추가 고려사항을 포함하는 소프트웨어 부하 제어 및 부품 번호 부여\n• 소프트웨어 수명주기 개발 환경의 구성 관리에는 도구가 포함된다.\n• 모든 DO-278A 수명주기 데이터는 소프트웨어 레벨과 관련된 구성 제어 범주와 일관되게 유지되어야 한다.",null,"Y"]
[null,"1.5.5","Will applicable aspects of the SCM plan, environment, tools, training and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards and procedures?","SCM 계획, 환경, 도구, 교육 및 절차의 해당 측면이 승인된 계획, 표준 및 절차의 준수를 보장하기 위해 시스템 및 하청업체의 하위 계위 공급업체에 전달될 것인가?","A-8, #1-6","MA","SCMP\n14 Supplier Control"]
[null,1.6,"Review the SQA plan and consider the following questions:","SQA 계획을 검토하고 다음 질문을 고려하십시오."]
[null,"1.6.1","If the SQA plan is followed, will the DO-278A objectives defined in Table A-9 be met?","SQA 계획을 준수할 경우, 표 A-9에 정의된 DO-278A 목표가 충족될 것인가?","A-9, #1-5","Y","SQAP\n2 Environment\n3 Authority\n4 Activities\n5 Transition Criteria\n6 Timing\n7 QA Records"]
[null,"1.6.2","k","DO-278A의 섹션 8.0에 정의된 SQA 프로세스가 섹션 4.2를 충족하기에 충분한 세부사항(DO-278A 섹션 11.5 참조)에 설명되어 있는가?","A1, #1","Y","SQAP\n2 Quality Assurance Environment\n3 QA Authority\n4 Activities\n5 Transition Criteria\n6 Timing\n7 SQA Records"]
[null,"1.6.3","Does the SQA plan adequately address the proposed contents described in DO-278A, Section 11.5? If not, are the contents included in another plan?","SQA 계획은 DO-278A, 섹션 11.5에 기술된 제안된 내용을 적절히 다루고 있는가? 만약 그렇지 않다면, 그 내용은 다른 계획에 포함되어 있는가?","A-1, #1","Y","SQAP\n2 Quality Assurance Environment\n3 QA Authority\n4 Activities\n5 Transition Criteria\n6 Timing\n7 QA Records"]
[null,"1.6.4","Is SQA independent from the development organization to a sufficient degree to ensure that SQA has the autonomy and authority to ensure SQA audit findings, actions, and deficiencies will be corrected?","SQA는 SQA 감사 결과, 조치 및 결함을 시정할 수 있는 자율성과 권한을 SQA가 갖도록 개발 조직으로부터 충분히 독립되어 있는가?","A-1, #2;\nA-9, #2","Y","SQAP\n2 Quality Assurance Environment\n2.3 QA Responsibilities\n"]
[null,"1.6.5","Are there any deviations proposed for this project from the SQA plans and procedures? If so, are those deviations identified and justified?","이 프로젝트에 대해 SQA 계획 및 절차에서 편차가 제안되었는가? 만약 그렇다면, 그러한 편차가 확인되고 정당화되었는가?","A-1, #2;\nA-9, #2","Y","SQAP\n5 Transition Criteria"]
[null,"1.6.6","Are the transition criteria, interrelationships, and sequences among process properly and adequately defined, and are they capable of being audited to ensure process compliance?","프로세스 간의 전환 기준, 상호관계 및 시퀀스가 적절하고 적절하게 정의되어 있으며, 프로세스 준수를 보장하기 위해 감사를 수행할 수 있는가?","A-1, #2;\nA-9, #2","Y","SQAP\n4.5.1 QA Objectives\n5 Transition Criteria"]
[null,"1.6.7","Are there defined procedures for how SQA audit findings, actions, and observed deficiencies will be corrected for the project?","SQA 감사 결과, 조치 및 관찰된 결함을 프로젝트에 대해 어떻게 수정하는지에 대해 정의된 절차가 있는가?","A-1, #2;\nA-9, #2","Y","SQAP\n7 QA Records"]
[null,"1.6.8","Is the SQA findings process a separate process or does it use different tools for issues resolution than the development organization (i.e., how are the SQA and development team problems reported)?","SQA 조사결과는 별도의 프로세스인가, 아니면 개발조직과 다른 문제해결을 위한 도구를 사용하고 있는가(즉, SQA 및 개발팀 문제는 어떻게 보고되고 있는가)?","A-1, #2;\nA-9, #2","Y","QA is performed as a separate organization, and unlike development, verification, and configuration management, it audits all activities from a process perspective and creates QAR."]
[null,"1.6.9","Is the criteria for SQA involvement (sampling, attending reviews, evaluation, conducting process compliance audits, witnessing tests, “conforming” environments, etc.) defined for the project? (Note: Criteria for involvement may be dependent on the software level or novelty of the product being developed.)","SQA 참여 기준(샘플링, 검토 참석, 평가, 프로세스 준수 감사 실시, 증인 시험, \"적합성\" 환경 등)이 프로젝트에 대해 정의되어 있는가?\n(참고: 참여 기준은 개발 중인 제품의 소프트웨어 수준 또는 새로움에 따라 달라질 수 있다.)","A-1, #2;\nA-9, #1-2","Y","SQAP\nTiming"]
[null,"2010-01-06","Has an accountable person or organization been identified for each documented SQA process and activity?","문서화된 각 SQA 프로세스 및 활동에 대해 책임 있는 사람 또는 조직이 확인되었는가?","A-1, #1;\nA-9, #1-5","Y","SQAP\n2.2 QA Interfaces\n2.3 QA Responsibilities"]
[null,"2011-01-06","Will applicable aspects of the SQA plan, environment, tools, training, and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?","SQA 계획, 환경, 도구, 교육 및 절차의 해당 측면이 승인된 계획, 표준 및 절차를 준수하기 위해 시스템 및 하청업체의 하위 계층 공급업체에 전달될 것인가?","A-1, #1-3, 7;\nA-9, #1-2","N/A","N/A"]
[null,1.7,"Review the SVP and consider the following questions:","SVP를 검토하고 다음 질문을 고려하십시오."]
[null,"1.7.1","If SVP is followed, will objectives of A-3, A-4, A-5, A-6, and A-7 be met?","SVP를 준수할 경우 A-3, A-4, A-5, A-6 및 A-7의 목표가 달성될 것인가?","A-3 to A-7\n(all objectives)","N","SVP \n2.1.8 Software Verification Results Reviews\n2.3.3 Non-testable Requirements Analysis\n\nneed to define Test Environment in detail"]
[null,"1.7.2","Does the SVP adequately address the proposed contents described in DO-278A, Section 11.3? If not, are the contents included in another plan?","SVP는 DO-278A, 섹션 11.3에 기술된 제안된 내용을 적절히 다루고 있는가?\n만약 그렇지 않다면, 그 내용은 다른 계획에 포함되어 있는가?","A-1, #1-3","N","SVP \n2.1.8 Software Verification Results Reviews\n2.3.3 Non-testable Requirements Analysis\n\nSee Above 1.7.1"]
[null,"1.7.3","Will applicable aspects of the SVP plan, environment, tools, training and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?","SVP 계획, 환경, 도구, 교육 및 절차의 해당 측면이 승인된 계획, 표준 및 절차를 준수하기 위해 시스템 및 하청업체의 하위 계층 공급업체에 전달될 것인가?","A-1, #1-3, 7\nA-3 to A-7\n(all objectives)","N/A"," PSAA, SCMP, SDP, SQAP, SVP"]
[null,"1.7.4","Does the SVP describe how independence will be achieved, when required?","SVP는 필요한 경우 독립성을 달성하는 방법을 기술하고 있는가?","A-3 to A-7\n(all objectives)","N/A","AL-4"]
[null,"1.7.5","Does the SVP describe the verification method used for each software verification activity? Specifically:\n•      Are methods, checklists, tools and procedures described for conducting reviews of software requirements, design, coding, and integration?\n•      Are methods, checklists, tools and procedures described for conducting analyses of traceability, change impact, timing, memory usage, stack usage, common shared resource (memory, I/O ports, buffers and devices, floating point processor, cache, etc.) usage, requirements- based test coverage, structural coverage, normal range coverage, robustness test coverage, data coupling, control coupling, etc.?\n•      Are methods, checklists, tools and procedures described for conducting reviews of test plans, test procedures, test cases, and test results?\n•      Are methods, checklists, tools and procedures described for conducting testing of software high-level requirements, software derived requirements, software low-level requirements, software components, software integration, hardware-software integration, normal range, and robustness?\n•      Will most of the formal software verification testing be conducted on a “host” computer environment or on the target environment?\nNote: If conducted on a host, justification should be provided for why the testing is valid for the target environment.\n•      Will most of the formal software verification testing be conducted on the executable object code embedded in the target environment, or on another form of the software (e.g., assembly\nlanguage) on a “host” computer environment? Note: If conducted on software other than the final airborne software load, justification should be provided for why the testing is valid for the airborne software in the target environment.\n•      If software verification test credit will be claimed for testing conducted on system benches, laboratory, integrated system facilities, do the plans and procedures describe how those activities will be conducted and software test results and coverage analyses documented?\n•      Is there a well-defined process and procedure for ensuring that deficiencies detected during the testing process will be conveyed to and corrected by the software development process and team?","SVP는 각 소프트웨어 검증 활동에 사용되는 검증 방법을 기술하고 있는가? 구체적으로:\n• 소프트웨어 요구사항, 설계, 코딩 및 통합의 검토를 수행하기 위한 방법, 체크리스트, 도구 및 절차를 기술하고 있는가?\n• 추적성, 변경 영향, 타이밍, 메모리 사용량, 스택 사용량, 공통 공유 리소스(메모리, I/O 포트, 버퍼 및 장치, 플로팅 포인트 프로세서, 캐시 등) 사용량, 요구 사항 기반 테스트 적용 범위, 구조적 적용 범위, 정상 범위, Rustn의 분석을 수행하기 위한 방법, 체크리스트, 도구 및 절차가 설명되어 있는가? ess 시험 범위, 데이터 커플링, 제어 커플링 등.\n• 시험 계획, 시험 절차, 시험 사례 및 시험 결과의 검토를 수행하기 위한 방법, 점검표, 도구 및 절차를 기술하고 있는가?\n• 소프트웨어 상위 레벨 요구사항, 소프트웨어 파생 요구사항, 소프트웨어 하위 레벨 요구사항, 소프트웨어 구성요소, 소프트웨어 통합, 하드웨어-소프트웨어 통합, 정상 범위 및 견고성의 테스트를 수행하기 위한 방법, 체크리스트, 도구 및 절차가 설명되어 있는가?\n• 대부분의 공식적인 소프트웨어 검증 테스트는 \"호스트\" 컴퓨터 환경에서 수행될 것인가 아니면 대상 환경에서 수행될 것인가?\n참고: 호스트에서 수행할 경우 테스트가 대상 환경에 유효한 이유에 대한 정당성이 제공되어야 한다.\n• 대부분의 공식 소프트웨어 검증 테스트는 대상 환경에 내장된 실행 가능한 객체 코드 또는 소프트웨어의 다른 형태(예: 조립)에서 수행될 것인가\n언어)는 \"호스트\" 컴퓨터 환경에서? 참고: 최종 공중 소프트웨어 부하가 아닌 다른 소프트웨어에 대해 수행되는 경우, 대상 환경에서 공중 소프트웨어에 대해 시험이 유효한 이유를 설명해야 한다.\n• 시스템 벤치, 실험실, 통합 시스템 시설에서 수행되는 시험에 대해 소프트웨어 검증 시험 크레딧이 청구되는 경우, 계획과 절차는 그러한 활동이 어떻게 수행될 것인지 그리고 소프트웨어 테스트 결과 및 적용범위 분석을 문서화하는지 기술하고 있는가?\n• 시험 과정에서 발견된 결함을 소프트웨어 개발 프로세스 및 팀에 전달하고 수정할 수 있도록 하기 위한 잘 정의된 프로세스와 절차가 있는가?","A-1, #1-3","Y","SVP \n2.1 Software Reviews\n2.2 Software Testing\n2.3 Software Analysis Methods\n3 Regression Testing and Re-Review Methods"]
[null,"1.7.6","Does the SVP describe the verification environment, including the test equipment? Consider the following questions:\n•      Are there any automated tools? If so, do any of the tools need to be qualified?\n•      Is there any overlap between various kinds of testing (e.g., overlap of system and requirements-based testing)?\n•      Is the division of the testing task between suppliers and sub-contract suppliers adequately addressed and controlled?","SVP는 시험 장비를 포함하여 검증 환경을 기술하고 있는가? 다음 질문을 고려하십시오.\n• 자동화된 툴이 있는가? 만약 그렇다면, 어떤 도구라도 자격을 갖추어야 하는가?\n• 다양한 종류의 시험(예: 시스템 및 요건 기반 시험) 사이에 중복이 있는가?\n• 공급업체와 하청업체 간의 시험업무 분담을 적절히 처리하고 통제하고 있는가?","A-1, #1-3","N","SVP \n2.2.4 Test Environment\n\n\nneed to define Test Environment in detail\nSee above 1.7.1"]
[null,"1.7.7","Are verification plans, including test plans, and procedures conveyed to suppliers and sub-contractors to ensure their activities and results will comply with the approved plans and procedures?","시험계획서를 포함한 검증계획서 및 그 활동 및 결과가 승인된 계획서 및 절차에 부합하는지 확인하기 위해 공급업체 및 하도급업체에게 전달되고 있는가?","A-1, #1-3",null,"N/A\nThere are no sub-contract suppliers"]
[null,"1.7.8","Do the plans and procedures describe how configuration control of the software test environment will be maintained?\nIf a system test environment will be used for formal software testing “credit,” do the plans and procedures describe how the system test bench will be configuration controlled and conformed?","계획과 절차는 소프트웨어 테스트 환경의 형상 관리를 유지하는 방법을 기술하고 있는가?\n시스템 테스트 환경이 공식적인 소프트웨어 테스트 \"크레딧\"에 사용될 경우, 계획과 절차는 시스템 테스트 벤치를 어떻게 제어하고 준수하는지 기술하고 있는가?","A-1, #1-3","Y","SVP\n2.2.4\tTest Environment\nThe exact Test Environment setup will be documented in STP and configuration documented in SECI"]
[null,"1.7.9","Does the SVP describe methods for test case selection? Does the SVP specify how each requirement will be tested (e.g., module test, software integration, hardware-software integration, system, etc.)?","SVP는 테스트 케이스 선택 방법을 설명합니까? SVP는 각 요구 사항을 테스트하는 방법(예: 모듈 테스트, 소프트웨어 통합, 하드웨어-소프트웨어 통합, 시스템 등)을 지정합니까?","A-1, #1-3","Y","SVP\n2.2 Software Testing"]
[null,"2010-01-07","Does the SVP or procedures specify who is allowed to\nperform verification tasks?","SVP 또는 절차는 다음을 수행할 수 있는 사람을 지정합니까?\n확인 작업을 수행합니까?","A-1, #1-3","Y","SVP\n2.2 Software Testing"]
[null,"2011-01-07","For Levels A, B, and C software, do the plans address all aspects of structural coverage analysis? For example, are the following addressed:\n•      tools and tool qualification, if tools are used for structural coverage analysis and results recording\n•      the relationship between requirements-based testing and measuring structural coverage\n•      a process for determining when additional requirements-based tests should be added if coverage is not achieved as expected\n•      a procedure for regression analysis and testing, if necessary\n•      the transition criteria to start and end structural coverage analysis\n•      regression analysis and testing with respect to the unique requirements for structural coverage\n•      processes and procedures for conducting analyses of data coupling (data interfaces and dependencies between system components) and control coupling (execution interfaces and dependencies between system components)\nNOTE: See A Practical Tutorial on Modified Condition/Decision Coverage [3] for additional information on MC/DC.","레벨 A, B 및 C 소프트웨어의 경우, 계획은 구조적 적용범위 분석의 모든 측면을 다루고 있는가? 예를 들어, 다음과 같은 내용을 다룬다.\n• 구조 범위 분석 및 결과 기록에 도구를 사용하는 경우 도구 및 도구 자격 부여\n• 요구사항 기반 테스트와 측정 구조 범위 간의 관계\n• 커버리지가 예상대로 달성되지 않을 경우 추가 요구 사항 기반 테스트를 언제 추가해야 하는지 결정하는 프로세스\n• 필요한 경우 회귀 분석 및 테스트 절차\n• 구조 범위 분석을 시작하고 종료하기 위한 전환 기준\n• 구조적 범위에 대한 고유한 요구 사항에 대한 회귀 분석 및 테스트\n• 데이터 커플링(시스템 구성요소 간 데이터 인터페이스 및 의존성) 및 제어 커플링(시스템 구성요소 간 실행 인터페이스 및 종속성)의 분석을 수행하기 위한 프로세스 및 절차\n참고: MC/DC에 대한 자세한 내용은 수정된 조건/의사 결정 범위[3]에 대한 실제 자습서를 참조하십시오.","A-1, #1-3\na-7, #5-8","Y","SVP\n2.3.2 Data Control and Control Coupling Analysis"]
[null,"2012-01-07","If it is level A software and structural coverage analysis is performed at the source code level, does the SVP address how source to object code traceability will be performed and documented?\nNOTE: See CAST-12 [4] for additional information on source to object code traceability.","레벨 A 소프트웨어로서 소스코드 레벨에서 구조적 커버리지 분석이 수행되는 경우, SVP는 소스와 오브젝트 코드 추적성을 수행하고 문서화하는 방법을 다루고 있는가?\n참고: 소스와 객체 코드 추적 가능성에 대한 자세한 내용은 CAST-12 [4]를 참조하십시오.","A-1, #1-3\na-7, #5","N/A","AL-4"]
[null,"2013-01-07","If verification tools are used, consider the following questions to determine whether the tool(s) needs to be qualified:\n•      Does the tool eliminate, reduce or automate a process or activity related to compliance with DO-278A?\n•      Can the verification tool allow an existing error to remain undetected? If so, what classes of errors can the tool fail to detect? Is there another verification activity performed to detect these classes and instances of errors?\n•      Is the output of the verification tool(s) verified manually or by another tool?\nNOTE: See section 12.2 of DO-278A and chapter 9 of Order 8110.49 [2] for more information on tools.","검증 공구를 사용하는 경우 다음 질문을 검토하여 공구를 검증해야 하는지 확인하십시오.\n• 도구는 DO-278A 준수에 관련된 프로세스 또는 활동을 제거, 감소 또는 자동화하는가?\n• 확인 도구가 기존 오류를 감지되지 않은 상태로 유지할 수 있는가? 그렇다면 툴이 감지하지 못할 수 있는 오류 등급은 무엇인가? 이러한 클래스와 오류 인스턴스를 탐지하기 위해 또 다른 확인 활동을 수행하였는가?\n• 확인 도구의 출력은 수동으로 확인되는가, 아니면 다른 도구에 의해 검증되는가?\n참고: 공구에 대한 자세한 내용은 DO-278A의 섹션 12.2와 주문서 8110.49의 9장을 참조하십시오.","A-1, #1-4","Y","LDRA"]
[null,"2014-01-07","If verification tools are reused, does the SVP (or other document) address possible reuse of verification tools? For example, is credit being claimed from previous tool qualifications or will the tool qualification data be used in a future program?","검증 도구를 재사용하는 경우, SVP(또는 기타 문서)가 검증 도구의 재사용을 다루고 있는가? 예를 들어, 이전의 도구 자격에서 신용이 청구되는가, 아니면 도구 자격 데이터가 향후 프로그램에 사용될 것인가?","A-1, #1-4","N/A","N/A\nDo not reuse verification tools."]
[null,1.8,"Develop an understanding of the system from applicant’s plans, safety assessment, standards, and briefings.  ","신청자의 계획, 안전성 평가, 표준 및 브리핑으로부터 시스템에 대한 이해를 개발한다."]
[null,"1.8.1","Does the safety assessment support the software level for every software component, as proposed in the plans?","안전평가는 계획서에 제시된 모든 소프트웨어 구성요소에 대한 소프트웨어 수준을 지원하는가?","A-1, #1","N/A","PAL don't apply for ARP 4754B/4761A"]
[null,"1.8.2","Are SAE ARP-4754 and/or ARP-4761 the proposed means of compliance for conducting system development process and system safety assessment process, respectively, or does the applicant/developer have other proposed means of compliance?","SAE ARP-4754 및/또는 ARP-4761은 각각 시스템 개발 프로세스와 시스템 안전성 평가 프로세스를 수행하기 위해 제안된 준수 수단인가, 아니면 신청자/개발자가 다른 제안된 준수 수단을 가지고 있는가?","A-1, #1","N/A","PAL don't apply for ARP 4754B/4761A"]
[null,"1.8.3","Are safety features to be implemented in software identified to the software processes as safety-related requirements","소프트웨어 프로세스에서 안전 관련 요구 사항으로 식별된 소프트웨어에서 구현해야 하는 안전 기능","A-1, #1, 2","N/A","PAL don't apply for ARP 4754B/4761A"]
[null,"1.8.4","Are safety features to be provided by the system or hardware robust enough to support the assigned software levels?","시스템 또는 하드웨어가 할당된 소프트웨어 레벨을 지원할 수 있을 정도로 안전 기능을 제공하고 있는가?","A-1, #1","N/A","PAL don't apply for ARP 4754B/4761A"]
[null,"1.8.5","Are derived software requirements provided back to the system safety assessment process for analysis of their impact on the safety assessment?","파생된 소프트웨어 요건이 안전성 평가에 미치는 영향을 분석하기 위해 시스템 안전성 평가 프로세스에 다시 제공되고 있는가?","A-1, #1, 2","N/A","PAL don't apply for ARP 4754B/4761A"]
[null,1.9,"Review the software development standards and consider the following questions:","소프트웨어 개발 표준을 검토하고 다음 질문을 고려하십시오."]
[null,"1.9.1","Are the software development standards (requirements, design, and coding) identified and well defined?","소프트웨어 개발 표준(요건, 설계 및 코딩)을 식별하고 잘 정의하고 있는가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.2","Are the software development standards consistent with the plans and do they support implementation of the plans?","소프트웨어 개발 표준이 계획과 일치하고 계획의 구현을 지원하는가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.3","Will the software development standards support the proposed software level(s) and software’s compliance with DO-278A objectives and other applicable policy and guidance?","소프트웨어 개발 표준은 제안된 소프트웨어 레벨과 소프트웨어의 DO-278A 목표 및 기타 적용 가능한 정책과 지침 준수를 지원할 것인가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.4","Have standards been verified for each defined software life cycle process? Are the standards adequate to support the software level?","정의된 각 소프트웨어 수명주기 프로세스에 대한 표준을 확인하였는가? 표준이 소프트웨어 레벨을 지원하기에 적절한가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.5","Have standards been verified to ensure compliance to Section 11 of DO-278A (i.e., sections 11.6, 11.7, and 11.8)?","DO-278A의 섹션 11(예: 섹션 11.6, 11.7 및 11.8)에 대한 준수를 보장하기 위한 표준을 검증하였는가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.6","Have standards been verified to ensure that any constructs are not permitted which would invalidate the assumptions about the safety levels (e.g., unconstrained recursion, non-determinism)?","안전 수준에 대한 가정(예: 제약되지 않은 재귀, 비결정론)을 무효화할 수 있는 구조가 허용되지 않는지 확인하기 위한 표준을 검증하였는가?","A-1, #5","Y","SRS\nSDS"]
[null,"1.9.7","Have the software development standards been verified to ensure that there are limitations, prohibitions, and constraints to not permit the use of design and code features that are not deterministic and not verifiable?","소프트웨어 개발 표준을 검증하여 확정적이지 않고 검증할 수 없는 설계 및 코드 기능의 사용을 허용하지 않는 제한, 금지 및 제약이 있는지 확인하였는가?",null,"Y","SRS\nSDS"]
[null,"1.9.8","Do design standards address exception handling, interrupts, re-entry, recursion, and scheduling constraints and methods? (See DO-278A, Section 11.7)","설계기준은 예외처리, 인터럽트, 재진입, 재침입, 스케줄링 제약사항 및 방법을 다루고 있는가? (DO-278A, 섹션 11.7 참조)",null,"Y","SRS\nSDS"]
[null,1.1000000000000001,"Review the plans to determine if real-time aspects of the software implementation have been addressed.  Consider if the following questions have been addressed in the plans:","계획을 검토하여 소프트웨어 구현의 실시간 측면이 해결되었는지 확인하십시오.  계획에서 다음과 같은 질문이 제기되었는지를 고려한다."]
[null,"1.10.1","Is the processor type identified in the plans? Does the applicant have experience with the processor? Is the processor usage justified? Additionally, consider the following questions:\n•      What features of the processor are unique and/or may impose specific scheduling, priorities, memory management, protection, and so forth requirements on the software?\n•      What safety features and capabilities does the processor have that will be used by the system to support system requirements? Will these features have an impact on the design of the software?\n•      Does the developer have plans and procedures for how they will use the features of the processor to develop the software functions’ architecture, scheduling, priorities, partitioning, built-in test, memory management, etc.? If so, how will those features and capabilities will be verified?","계획에서 프로세서 유형이 확인되었는가? 지원자는 프로세서에 대한 경험이 있는가? 프로세서 사용이 정당한가? 또한 다음 질문을 고려하십시오.\n• 프로세서의 고유한 기능은 무엇이며/또는 소프트웨어에 특정 예약, 우선 순위, 메모리 관리, 보호 등의 요구사항을 부과할 수 있는가?\n• 시스템에서 시스템 요구 사항을 지원하는 데 사용할 안전 기능 및 기능은 무엇인가? 이러한 기능이 소프트웨어 설계에 영향을 미칠 것인가?\n• 개발자는 프로세서의 기능을 사용하여 소프트웨어 기능의 아키텍처, 스케줄링, 우선순위, 파티셔닝, 내장 테스트, 메모리 관리 등을 개발하는 방법에 대한 계획과 절차를 가지고 있는가? 그렇다면 그러한 특징과 기능은 어떻게 검증될 것인가?","A-1, #3","N","need to define and describe in detail to PSAA"]
[null,"1.10.2","Will the processor cache and/or pipelining be used?\nIf so, how will partitioning, isolation, separation, and other protection methods and worst-case execution timing for the system be addressed?","프로세서 캐시 및/또는 파이프라이닝을 사용할 것인가?\n만일 그렇다면, 시스템의 파티션 분할, 격리, 분리 및 기타 보호 방법 및 최악의 실행 타이밍을 어떻게 해결할 것인가?","A-1, #1, 3","N","need to define and describe in detail to PSAA"]
[null,"1.10.3","Does the system use a board support package or device drivers?\nAre any of them new, modified, or unique for this system?\nHow will the applicant or developer show that they satisfy the DO-278A objectives or guidance of DO- 254? Is any service history credit claimed for their use?","시스템에서 보드 지원 패키지 또는 장치 드라이버를 사용하고 있는가?\n이들 중 이 시스템에 대해 새로운 것, 변형된 것 또는 고유한 것이 있는가?\n신청자나 개발자는 DO-254의 DO-278A 목표나 지침을 충족한다는 것을 어떻게 보여줄 것인가? 서비스 이력 크레딧이 청구되었는가?","A-1, #3","N","need to define and describe in detail to PSAA"]
[null,"1.10.4","Is a memory management unit (MMU) used?\nIf so, do the plans address how its accuracy and correct function will be verified?","메모리 관리 장치(MMU)를 사용하고 있는가?\n만약 그렇다면, 계획은 정확성과 정확한 기능을 검증하는 방법을 다루고 있는가?","A-1, #1, 3","N","need to define and describe in detail to PSAA"]
[null,"1.10.5","Does the system include any libraries, functions, macros, etc. provided by the compiler, real-time system, operating system, microprocessor, or development environment vendors? \nAre plans and procedures established for how these components will be shown to satisfy the DO-278A objectives and other applicable software policy?\nDoes the applicant have a user’s guides for these components that describe their intended functions and any constraints or limitations for their use?","시스템에 컴파일러, 실시간 시스템, 운영 체제, 마이크로프로세서 또는 개발 환경 벤더가 제공하는 라이브러리, 기능, 매크로 등이 포함되어 있는가? \n이러한 구성요소가 DO-278A 목표 및 기타 적용 가능한 소프트웨어 정책을 충족하는 것으로 입증되는 방법에 대한 계획과 절차를 수립하고 있는가?\n신청자는 의도한 기능 및 사용에 대한 제약사항이나 제한을 기술하는 이러한 구성요소에 대한 사용자 지침을 가지고 있는가?","A-1, #1, 3","N","need to define and describe in detail to PSAA"]
[null,"1.10.6","Are any application programming interfaces (APIs) used? If so, are the following addressed in the plans:\n•      Are their functions described?\n•      Can they be fully verified?\n•      Can they have any effects on the other applications and functions of the system?\n•      Are there requirements that specify the interfaces in detail (e.g., user’s guide or interface specification)?\n•      Does the system or system’s software applications have the ability to detect any errors of the API to be used?","응용 프로그램 프로그래밍 인터페이스(API)를 사용하고 있는가? 만약 그렇다면, 계획에서 다음 사항을 다루고 있는가?\n• 그 기능이 설명되어 있는가?\n• 그들이 완전히 검증될 수 있는가?\n• 시스템의 다른 애플리케이션 및 기능에 영향을 미칠 수 있는가?\n• 인터페이스를 자세히 지정하는 요구사항이 있는가(예: 사용자 가이드 또는 인터페이스 사양)\n• 시스템 또는 시스템의 소프트웨어 애플리케이션이 사용할 API의 오류를 탐지할 수 있는가?","A-1, #3","Y","PSAA\n3.7 Commercial Off-The-Shelf Software"]
[null,"1.10.7","Is an integrated development environment (IDE) used? Will any of the tools be qualified?\nAre dependencies and interactions between the tools of the environment document and well understood?\nAre the tools in the IDE compatible with one another and with other tools used in the development and verification processes? Is this well documented?","통합개발환경(IDE)을 사용하고 있는가? 그 도구들 중 어떤 것이라도 자격을 갖추게 될까?\n환경 도구의 의존성과 상호작용을 문서화하고 잘 이해하고 있는가?\nIDE의 툴이 개발 및 검증 프로세스에 사용되는 다른 툴과 호환되는가? 이것은 잘 문서화되어 있는가?","A-1, #3","Y","PSAA\n9.2 Tool Qualification"]
[null,"1.10.8","Do the plans describe how the development environment will be preserved for any future changes to software? Does the applicant or developer have plans and procedures for managing changes to the tools and analyzing their impact on already approved as well as future systems and projects?","이 계획에는 향후 소프트웨어 변경 시 개발 환경을 보존하는 방법이 설명되어 있는가? 신청자나 개발자는 도구 변경사항을 관리하고, 이미 승인된 미래 시스템 및 프로젝트에 미치는 영향을 분석하기 위한 계획과 절차를 가지고 있는가?","A-1, #3, 6","Y","Ref SCMP"]
[null,"1.10.9","Are cyclic redundancy checks (CRC) used? If so, how is their accuracy and adequacy ensured? Are CRC’s or checksums used for loading software, for verifying databus message content correctness, for verifying files stored in system memory, for conducting built-in testing, etc.?  \nAre other checksums and parity checks used? Are plans and procedures established for ensuring that CRC’s, checksums, parity checks, and the like provide the appropriate level of integrity and assurance for each use?","주기적 이중화 점검(CRC)을 사용하고 있는가? 만약 그렇다면, 그들의 정확성과 적절성은 어떻게 보장되는가? CRC 또는 체크섬은 소프트웨어 로딩, 메시지 내용의 정확성 확인, 시스템 메모리에 저장된 파일 확인, 내장 테스트 등에 사용되었는가?  \n다른 체크섬과 패리티 체크가 사용되었는가? CRC, 체크섬, 패리티 검사 등을 통해 각 용도에 적절한 수준의 무결성과 보장을 제공할 수 있도록 계획 및 절차를 수립하고 있는가?","A-1, #1","Y","PSAA\n2.3 System Safety Features"]
[null,"2010-01-10","What language is being used?\n•      Does the applicant have experience with the language?\n•      Does the language have any dynamic features or capabilities that may be difficult to verify? Has the applicant or developer imposed any prohibitions or restrictions on the use of these features in the coding standards and/or review checklists? Does the applicant/developer have plans and procedures established for how these dynamic features will be verified?\n•      What features of the language support or hinder real-time implementation and verification?\n•      Are any language problems documented and addressed?\n•      Has a safe sub-set of the language been selected? How will it be verified that that safe sub-set was adhered to (e.g., code reviews, checklists, testing, etc.)?\n•      What are common errors of the language? Do coding standards protect against these errors?","어떤 언어가 사용되고 있는가?\n• 지원자는 해당 언어에 대한 경험이 있는가?\n• 언어에 검증하기 어려울 수 있는 동적 특징 또는 기능이 있는가? 신청자나 개발자가 코딩 표준 및/또는 검토 체크리스트에서 이러한 기능의 사용에 대해 금지 또는 제한을 가하였는가? 신청자/개발자가 이러한 동적 특성을 검증하는 방법에 대한 계획과 절차를 수립하였는가?\n• 실시간 구현 및 검증을 지원하거나 방해하는 언어의 기능은?\n• 언어 문제가 문서화되고 해결되었는가?\n• 언어의 안전한 하위 집합이 선택되었는가? 안전한 서브셋(코드 리뷰, 체크리스트, 테스트 등)을 준수했는지 확인하는 방법?\n• 언어의 일반적인 오류는 무엇인가? 코딩 표준이 이러한 오류로부터 보호되고 있는가?","A-1, #3, 5","Y","JAVA language"]
[null,"2011-01-10","If the system or its software will use multitasking, what kind of scheduling strategy is used? How will priorities, protection, and interrupts be addressed?","시스템 또는 소프트웨어에서 멀티태스킹을 사용할 경우 어떤 종류의 스케줄링 전략을 사용하십니까? 우선순위, 보호 및 인터럽트는 어떻게 처리될 것인가?","A-1, #1, 6"]
[null,"2012-01-10","If partitioning or other protection capabilities are used, how will they be implemented and verified?","파티셔닝이나 다른 보호 기능을 사용할 경우, 어떻게 구현하고 검증할 것인가?","A-1, #1, 6","N/A","there is no SW Partitioning\nN/A"]
[null,"2013-01-10","If a Real-Time Operating System (RTOS) is used:\n•      How will the applicant demonstrate that it satisfies the DO-278A objectives and other applicable software policy? Will service history credit be claimed for its use in this system? If so, is the service history relevant for the system being developed?\n•      How will RTOS requirements trace to the software applications and/or system requirements?\n•      Will there be any unused features of the RTOS? If so, how will it be addressed (either not loaded in the airborne application or shown to be deactivated)?\n•      Will the RTOS be used to implement multiple software levels of software applications? If so, has the applicant or developer addressed partitioning and protection capabilities in their plans and procedures for time partitioning (shared use of the CPU, registers, cache, coprocessors, I/O devices, and other “shared” system resources) and space (memory, such as, shared use of RAM, stack space, I/O buffers, global data and other shared memory devices) been addressed? How will these features and capabilities be verified?","실시간 운영 체제(RTOS)를 사용하는 경우:\n• 신청자가 DO-278A 목표와 기타 적용 가능한 소프트웨어 정책을 충족한다는 것을 어떻게 입증할 것인가? 서비스 이력 크레딧이 이 시스템에 사용되어 청구될 것인가? 만일 그렇다면, 서비스 이력이 개발 중인 시스템과 관련되는가?\n• RTOS 요건은 소프트웨어 애플리케이션 및/또는 시스템 요구 사항을 어떻게 추적할 것인가?\n• RTOS의 사용되지 않는 기능이 있는가? 만약 그렇다면, 그것은 어떻게 다루어질 것인가(공중 애플리케이션에서 로드되지 않았거나 비활성화된 것으로 보여지는가)?\n• RTOS를 여러 소프트웨어 레벨의 소프트웨어 애플리케이션을 구현하는 데 사용할 것인가? 만일 그렇다면, 신청자나 개발자는 시간 분할(CPU, 레지스터, 캐시, 복사기, I/O 장치 공유)과 공간(예: RAM, 스택 공간, I/O 버퍼, 글로벌 데이터 및 기타 공유)을 위한 계획과 절차에서 분할 및 보호 기능을 다루었는가? 메모리 장치)가 설명되었는가? 이러한 특징과 기능은 어떻게 검증될 것인가?","A-1, #1,3,6","N/A","do not use RTOS\nN/A"]
[null,"2014-01-10","Are there any libraries used in the software? If so, how will the applicant show that they satisfy the DO- 278A objectives and other applicable software policy and agreements?","소프트웨어에 사용된 라이브러리가 있는가? 그렇다면 신청자는 DO- 278A 목표와 기타 적용 가능한 소프트웨어 정책 및 합의를 어떻게 충족하는지 보여줄 것인가?","A-1, #1,3,6","Y","PSAA\n3.5 Commercial Off-The-Shelf Software"]
[null,1.1100000000000001,"If object-oriented technology is used. Consider if the following questions have been addressed:"]
[null,"1.11.1","Is RTCA/DO-332 invoked for the OOT software?","OOT 소프트웨어에 RTCA/DO-332가 적용됩니까?","N/A","N/A","N/A\nPAL don't apply for DO-332"]
[null,"1.11.2","Do the plans reflect the required modification per DO-332?","계획에 DO-332에 따라 필요한 수정 사항이 반영되어 있습니까?","N/A","N/A","N/A\nPAL don't apply for DO-332"]
[null,"1.11.3","Is local type consistency specified for class hierarchies with an appropriate mechanism to verify said consistency?","클래스 계층 구조에 대한 로컬 유형 일관성이 명시되어 있으며, 해당 일관성을 검증하는 적절한 메커니즘이 있습니까?","OO.A-7, #10","N/A","N/A\nPAL don't apply for DO-332"]
[null,"1.11.4","Is there a mechanism specified to verify robust dynamic memory management?","강력한 동적 메모리 관리를 검증하는 메커니즘이 명시되어 있습니까?","OO.A-7,  #11","N/A","N/A\nPAL don't apply for DO-332"]
[null,"1.11.5","Does the additional considerations section (or some other section) of the PSAC address that the project is using object-oriented (OO) technology and identify OO-related issues for the specific project?  Consider the following questions:\n•  Are there specific standards and guidance applicable for the project using OO?  \n•  Does the applicant or developer have experience using OO for airborne system developments? \n•  Do the DERs for the project have experience assessing OO projects and data to compliance with DO-278A?","PSAC의 추가 고려 사항 섹션(또는 다른 섹션)에서 프로젝트가 객체 지향(OO) 기술을 사용하고 있음을 언급하고 특정 프로젝트의 OO 관련 문제를 식별합니까? 다음 질문을 고려하십시오.\n• OO를 사용하는 프로젝트에 적용할 수 있는 특정 표준 및 지침이 있습니까?\n• 신청자 또는 개발자가 항공 시스템 개발에 OO를 사용한 경험이 있습니까?\n• 프로젝트의 DER(기술자)이 OO 프로젝트 및 데이터를 DO-278A 준수 여부에 따라 평가한 경험이 있습니까?","OO.A-1, #1-7","N/A","N/A\nPAL don't apply for DO-332"]
[null,"1.11.6","Do the plans address how the following common OO issues will be addressed?\n• Encapsulation\n• Overloading\n• Inheritance\n• Dynamic binding/dispatch\n• Polymorphism\n• Templates\n• Inlining\n• Dead pr deactivated code\n• Traceability\n• Structural coverage\nWill verification of the OO development have specific procedures, testing, and analyses to address the above issues?  Does the applicant or developer have experience in addressing these issues for past projects/systems?\nNOTE 1:  CAST-8 [5] addresses common C++ issues, which may also apply to other OO languages.\nNOTE 2:  The FAA is developing a handbook on OO issues – it is slated for release in June 2004.  Volume 4 of the handbook will contain questions that should be considered in addition to this Job Aid.","계획서에 다음과 같은 일반적인 객체 지향(OO) 문제 해결 방법이 포함되어 있습니까?\n• 캡슐화\n• 오버로딩\n• 상속\n• 동적 바인딩/디스패치\n• 다형성\n• 템플릿\n• 인라이닝\n• 데드 또는 비활성화된 코드\n• 추적성\n• 구조적 커버리지\nOO 개발 검증에 위 문제들을 해결하기 위한 구체적인 절차, 테스트 및 분석이 포함되어 있습니까? 지원자 또는 개발자는 과거 프로젝트/시스템에서 이러한 문제들을 해결한 경험이 있습니까?\n참고 1: CAST-8 [5]은 일반적인 C++ 문제를 다루며, 이는 다른 객체 지향 언어에도 적용될 수 있습니다.\n참고 2: FAA는 객체 지향 문제에 대한 핸드북을 개발 중이며, 2004년 6월에 출간될 예정입니다. 핸드북 4권에는 이 Job Aid 외에도 고려해야 할 문제들이 포함될 것입니다.","OO.A-1, #1-7","N/A","N/A\nPAL don't apply for DO-332"]