Attachment_A__Safety_LOR-Table.xlsx

XLSX spreadsheet 64 KB Posted Aug 9, 2017

Attached to: Flight Management Function (FMF) Software Application
Solicitation number: N00421-17-R-0021
Issued by: Department of the Navy Naval Air Systems Command Naval Air Warfare Center

About this file

From the source

SOW Attachment A

View the file

Other files

File	Type	Posted
Attachment_6__Cost-Price_worksheets_REV_1.xlsx	XLSX spreadsheet	Sep 6, 2017
Industry_questions_FINAL_31_AUG.docx	DOCX document	Sep 1, 2017
Amendment_0002.docx	DOCX document	Sep 1, 2017
Amendment_0001.docx	DOCX document	Aug 9, 2017
Attachment_3_N00421-17-R-0021_Past_Performance_Information_Form_Mar_2017.pdf	PDF	Jul 28, 2017
Attachment_11_OT-17-20085_-_Software_Accomplishment_Summary_(SAS).pdf	PDF	Jul 28, 2017
Attachment_5__Offeror_Summary_Table.xlsx	XLSX spreadsheet	Jul 28, 2017
Attachment__12_-_OT-17-20086_-_Flight_Management_Function_Face_Data_Model_(FMF_FACE_DM).pdf	PDF	Jul 28, 2017
Attachment_13_OT-17-20087_-_System_Integration_Lab_Desctription.pdf	PDF	Jul 28, 2017
N00421-17-R-0021.docx	DOCX document	Jul 28, 2017
Attachment_9_OT-17-20083_-_Plan_for_Software_Aspects_of_Certification_(PSAC).pdf	PDF	Jul 28, 2017
Attachment_2_Govt_Spec_for_FMF_SW_App_Rev_A_29_June_2017_w_signatures.pdf	PDF	Jul 28, 2017
Attachment_6__Cost-Price_worksheets_07-10-17_WBS_SRM.xlsx	XLSX spreadsheet	Jul 28, 2017
Attachment_10_OT-17-20084_-_FACE_Conformance_Verification_Artifacts_(CVA).pdf	PDF	Jul 28, 2017
ATTACHMENT_1_-_N00421-17-R-0021-_FMF_APP_SOW.PDF	PDF	Jul 28, 2017
Attachment_14_OT-17-20089_-_Software_Metrics_Report_(SWMR).pdf	PDF	Jul 28, 2017
Attachment_8_FMF_App_Security_Control_Selection_Worksheet.xlsx	XLSX spreadsheet	Jul 28, 2017
Attachment_4_Contractor_Performance_Assessment_Questionnaire_May_2016.msg.pdf	PDF	Jul 28, 2017
Attachment_7_Part_B__Annex-9-Government-Furnished-Property-Compliance-Checklist-NMCARS-13-12.....xlsx	XLSX spreadsheet	Jul 28, 2017
Attachment_15_FMF_App_CDRLs_signed.pdf	PDF	Jul 28, 2017
Attachment_7_Part_A_NMCARS_Change_13-12_-_Annex_9_Instructions_with_NAVAIR_Notes.docx	DOCX document	Jul 28, 2017
SOW_for_RNP_RNAV_FMF_v2.7_(20161222).docx	DOCX document	Dec 22, 2016

Show all 22

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Read Me

The following general principles shall be applicable in consideration of the tasks delineated on the LOR task tabs

Some tasks are identified at multiple levels of LOR and should be interpreted as to its application based on the below guidance.

An Example is the SSHA for software, at LOR 3 it should be construed to go to the software requirements (SRS) level, for LOR 2 to the software design level (SDD or model), LOR 1 to the code level.

The LOR list should only be used when considered as a supplement to Mil-Std-882E as this list assumes compliance with Mil-Std-882E tasks as a baseline and those requirements are not repeated here.

LOR 1

Program shall perform analysis of requirements, architecture, design, and code; and conduct corresponding in-depth safety-specific testing.

Program shall perform LOR 1 level software assurance tasks

LOR 2

Program shall perform analysis of requirements, architecture, and design; and conduct corresponding in-depth safety-specific testing.

Program shall perform LOR 2 level software assurance tasks

LOR 3

Program shall perform analysis of requirements and architecture; and conduct corresponding safety-specific testing.

Program shall perform LOR 3 level software assurance tasks

LOR 4

Program shall conduct safety-specific testing.

Program shall perform LOR 4 level software assurance tasks

The program shall interpret "analysis" as a safety program task requiring implementation and documentation of an appropriate analytical technique to identify causal factors or controls at the appropriate level. Artifacts to support analysis may be those generated by other activates and leveraged by software safety to provide as evidence.

The program shall ensure "Safety-specific testing" is inclusive at all levels of test cases derived from the hazard analysis to mitigate causal factors or verify controls. Safety review of test plans performed without documented traceability to hazard analysis to incorporate appropriate safety specific tests into the test plans/procedures cannot be considered complete.

Safety specific tasks shall be hazard chain focused. E.g. LOR 1 logical code analysis techniques described in 4.3.7.3.2 of the JSSSEH should be applied only to code related to the safety significant functionality

Software assurance tasks shall be applied to the CSCI or partition thereof if appropriate time and space partitioning exists. E.g. application of MISRA C and structural coverage analysis cannot be applied strictly to the safety significant function

DoD standards have not ben updated to incorporate the latest software development practices, however, these processes pose unique challenges which must be accounted for within the safety and development processes to ensure a safe system. Following are requirements to address Model Based development and Agile development

Model based development

DO-331 is a supplement to DO-178 to address model based development in software assurance for safety significant systems. If models are used in software development, the program shall develop a supplement to the LOR tasking identified above, utilizing DO-331, to ensure the intent of the LOR tasks are fulfilled.

Agile software development

If Agile methods are used in software development, the program shall develop a supplement to the LOR tasking detailing safety involvement in the Agile process to show that the intent of LOR tasks are fulfilled.

Task 102 - SSPP

NAVAIR Software System Safety Level of Rigor Tasks - SSPP
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
102.01	The Purpose section of the SSSPP shall define the purpose and scope of the plan, including those safety goals that are expected to be achieved by adherence to the plan.	X	X	X		1. IEEE 1228 Section 4.1 Purpose

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.02 The Organization and Responsibilities section of the SSSPP shall depict the software safety activities within the overall organization and shall describe organizational and functional relationships pertaining to software safety issues, lines of communication, and authority. X X X 1. IEEE 1228 Section 3.1 Organization and Responsibilities

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.03 The Resources section of the SSSPP shall specify resource requirements, physical and personnel and the allocation of those resources to safety tasks. X X X 1. IEEE 1228 Section 4.3.2 Resources

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

	102.04	The Staff Qualifications and Training section of the SSSPP shall specify the qualifications required for safety personnel commensurate with the software deveopment methods, techniques, tools.
For instance a program utilyzing model driven development such as UML, the safety engineer should have experience or training in UML	X	X	X	1. IEEE 1228 Section 4.3.3 Staff Qualifications and Training

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.05 The Software Life Cycle section of the SSSPP shall ensure the software life cycle that will be used and the relationship among specific software safety tasks and the activities embodied in the organization's chosen software life cycle are specified X X X 1. IEEE 1228 Section 4.3.4 Software Life Cycle

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.06 The Documentation Requirements section of the SSSPP shall specify the format and content for all software safety deliverable documents X X X 1. IEEE 1228 Section 4.3.5 Documentation Requirements

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.07 The Software Configuration Management Activities section of the SSSPP shall describe how the safety-significant software will be managed in accordance with an approved software configuration management plan. X X X 1. IEEE 1228 Section 4.3.7 Software Configuration Management Activities

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.08 The Software Quality Assurance Activities section of the SSSPP shall describe the role of software quality assurance in ensuring proper performance of key software safety program activities. X X X 1. IEEE 1228 Section 4.3.8 Software Quality Assurance Activities

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.09 The Tool Support and Approval section of the SSSPP shall specify the process to be used and the criteria to be applied in selecting, approving, and controlling tools, such as Computer-Aided Software Engineering (CASE) products, compilers, editors, fault tree generators, and test environments for hardware and software. X X X 1. IEEE 1228 Section 4.3.10 Tool Support and Approval

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

	102.1	The Previously Developed or Purchased Software section of the SSSPP shall state the provisions for ensuring that previously developed or purchased software meets the requirements of the safety-significant application, shall define the role of software safety program personnel in the approval process, and shall define the approval authority required before previously developed or purchased software can be used.
This section shall specifically address COTS/GOTS/MOTS/NDI/IRAD/Adapted/re-used utilyzing Appendix D of the JSSSEH	X	X	X	1. IEEE 1228 Section 4.3.11 Previously Developed or Purchased Software

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.11 The Subcontract Management section of the SSSPP shall specify the provisions for ensuring that subcontractor software complies with software safety program requirements and provides supporting evidence. X X X 1. IEEE 1228 Section 4.3.12 Subcontract Management

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.12 The Software Safety Analyses section of the SSSPP shall identify and describe hazard analysis to be completed, roles and resonsiblities of stakeholders in the analysis process, and how analysis influences the development process. See the annex for a discussion of software safety analyses. X X X 1. IEEE 1228 Section 4.4 Software Safety Analyses

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.13 The Plan Approval section of the SSSPP shall specify how the SSSPP is maintained and updated. X X X 1. IEEE 1228 Section 4.4.1 Plan Approval

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.14 The Software Safety Requirements Analysis section of the SSSPP shall define the methods, techniques, and resources to accomplish requirements analysis. X X X 1. IEEE 1228 Section 4.4.2 Software Safety Requirements Analysis

2. IEEE 1228 Annex A.1 Software Safety Requirements Analysis

3. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.15 The Software Safety Design Analysis section of the SSSPP shall define the methods, techniques, and resources to accomplish design hazard analysis. X X X 1. IEEE 1228 Section 4.4.3 Software Safety Design Analysis

2. IEEE 1228 Annex A.2 Software Safety Design Analysis

3. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.16 The Software Safety Code Analysis section of the SSSPP shall define the methods, techniques, and resources to accomplish hazard analysis on the code. X X 1. IEEE 1228 Section 4.4.4 Software Safety Code Analysis

2. IEEE 1228 Annex A.3 Software Safety Design Analysis

3. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.17 The Software Safety Test Analysis section of the SSSPP shall define the roles and responsibilities of stakeholders associated with T&E of safety significant software. X X X 1. IEEE 1228 Section 4.4.5 Software Safety Test Analysis

2. IEEE 1228 Annex A.4 Software Safety Test Analysis

3. JSSSEH (2010) Figure C-1 Contents of a SwSPP

	102.18	The Software Safety Change Analysis section of the SSSPP shall define the safety involvement in defect and change management.
The section shall include the criteria, based on table B1 of Mil-std-882E, for determining risk associated with software defects	X	X	X	1. IEEE 1228 Section 4.4.6 Software Safety Change Analysis

2. IEEE 1228 Annex A.5 Software Safety Change Analysis

3. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.19 The Post Development section of the SSSPP shall define the requirements for training, deployment, monitoring, maintenance, and retirement of safety-significant software that are necessary to ensure the continued safety of the system after its deployment and until its orderly retirement. X X X 1. IEEE 1228 Section 4.5 Post Development

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

	102.2	The Training section of the SSSPP shall define software safety involvement in development training material and tools needed to ensure safe operation and use of the software within the overall system.
This section shall address workarounds and workload associated with the accumulation of defects.	X	X	X	1. IEEE 1228 Section 4.5.1 Training

2. JSSSEH (2010) Figure C-1 Contents of a SwSPP

102.21 The contractor shall provide a software safety schedule with links to the Program Integrated Master Schedule X X X

Task 104 - Reviews & Audits

NAVAIR Software System Safety Level of Rigor Tasks - Support of Government Reviews/Audits
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
104.01	The contractor shall support Government audits prior to significant SETR events, flight readiness reviews, or safety review boards (LSRB, SSSTRP, WSESRB etc). Audits shall include status and health of the software safety program, LOR compliance, Generic software safety requirements compliance, hazard analysis maturity, evidence of development assurance influence on product domain or "ility" processes (SQA, Architecture, CM,etc), as appropriate to program maturity.	X	X	X

Task 106 - HTS

NAVAIR Software System Safety Level of Rigor Tasks - Hazard Tracking System
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
106.01	The contractor shall establish and maintain a closed-loop Hazard Tracking System (HTS)	X	X	X	X	MIL-STD-882E Task 106 Hazard Tracking System
106.02	The HTS shall include additional data for software associated hazards. System, subsystem (if applicable), applicability (version specific hardware designs or software releases), requirements references, safety significant function, SwCI of the function, and defect configuration management data (STR, PAR, CR etc #).	X	X	X	X	MIL-STD-882E Task 106.2.a,b,c,d,e Hazard Tracking System
106.03	The HTS records shall include justifcation/rational for Severity and SCC (combined to justify SwCI) as well as detailed hazard scenerio to justify the risk assessment				X	MIL-STD-882E Section 4.3.1d. Documenting Hazards with a Closed-loop Hazard Tracking System (HTS)
106.04	HTS records for software defects shall utilize Table B-1 of Mil-Std-882E to assess the software contribution to system hazard risk					MIL-STD-882E Section 4.3.2 Identify and Document Hazards

Task 201 - PHL

NAVAIR Software System Safety Level of Rigor Tasks - Preliminary Hazard List
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
201.01	The safety program shall examine the system shortly after the materiel solution analysis begins and compile a Preliminary Hazard List (PHL) identifying potential hazards associated with software "failures" inherent in the concept.	X	X	X	X	1. JSSSEH Section 4.3.4.1 PHL Development

2. JSSSEH Section C.3.3 Preliminary Hazard List

3. MIL-STD-882E Task 201 Preliminary Hazard List (PHL)

201.02 Contractors shall develop a PHL shortly after contract award,if a system PHL was developed it shall be used as input. X X X X 1. JSSSEH Section 4.3.4.1 PHL Development

2. JSSSEH Section C.3.3 Preliminary Hazard List

3. MIL-STD-882E Task 201 Preliminary Hazard List (PHL)

Task 202 - PHA

NAVAIR Software System Safety Level of Rigor Tasks - Preliminary Hazard Analysis
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
202.01	The safety program and any vendors safety program shall perform and document a PHA to identify hazards including software causal factors, assess the initial risks, and identify potential mitigation measures.	X	X	X	X	1. JSSSEH Section 4.3.4.2 PHA Development

2. JSSSEH Section C.3.5 Preliminary Hazard Analysis

3. JSSSEH Section 4.3.4.2 PHA Development

202.02 For each identified hazard including software causal factors, the PHA shall include an initial risk assessment based on an assessment of Software Control Category (SCC) for each Safety-significant Software Function (SSSF). Assign a Software Criticality Index (SwCI) for each SSSF mapped to the software design architecture. X X X X 1. JSSSEH Section 4.3.4.2 PHA Development

2. JSSSEH Section C.3.5 Preliminary Hazard Analysis

202.03 For each identified hazard, the PHA shall identify potential risk mitigation measures using the system safety design order of precedence specified in MIL-STD-882E section 4.3.4. X X X X 1. JSSSEH Section 4.3.4.2 PHA Development

2. JSSSEH Section C.3.5 Preliminary Hazard Analysis

Task 203 - SRHA

NAVAIR Software System Safety Level of Rigor Tasks - System Requirements Hazard Analysis
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
203.01	The safety program and all vendor safety programs shall perform and document a System Requirements Hazard Analysis (SRHA) by establishing bi-directional tracability of safety criteria and requirements through specifications, design,code, V&V, and hazards .	X	X	X	X	MIL-STD-882E Task 203 System Requirements Hazard Analysis (SRHA)
203.02	The SRHA shall document and determine appropriate software architecture requirements and system design requirements to eliminate hazards or reduce the associated risks	X	X	X	X	1. MIL-STD-882E Task 203 Section 203.2.1b

2. MIL-STD-882E Section B.2.1 Software System Safety Hazard Analysis

3. MIL-STD-882E Section 4.3.2 Identify and document hazards.

4. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

203.03 The following categories of safety requirements shall be analyzed in the SHRA and identified with an attribute in the in the appropriate requirements and architecture tools and documentation (e.g DOORS, UML models). They are contributing software safety requirements (CSSRs), Generic Software Safety Requirements (GSSRs), and mitigating software safety requirements (MSSRs). X X X X 1. JSSSEH Section 4.3.5.1 Categories of Software Safety Requirements

2. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

3. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

4. IEEE 1228 Appendix A.1 Software Safety Requirements Analyses (SSRA)

5. JSSSEH Section 4.3.5.3 Documenting SSRs

6. IEEE 1228 Appendix A.1(b) Specification Analysis

7. AOP52 Section 3.3.6.4 Documenting Software Safety Requirements

203.04 Contractor shall implement the JSSSEH, or AOP-52 as appropriate to show compliance to Generic Software Safety Requirements (GSSRs). Developer shall indicate applicable, not applicable, compliant, partially compliant, and not compliant with appropriate justification. Compliance claims shall have evidence to support, and non-compliance shall have an assessment of risk. X X X X 1. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

2. AOP-52 Section 3.3.3 Tailoring Generic Safety-Related Requirements

3. STANAG 4404

4. MIL-STD-882E Task 203 System Requirements Hazard Analysis (SRHA)

5. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

203.05 Contractor shall analyze safety-significant requirements to ensure they are accurate, consistent, complete, verifiable, and traceable to safety-significant system-level requirements and compliant to requirements standards. Accuracy and consistency is demonstrated by showing that each safety-significant high-level software requirement is accurate, unambiguous, and sufficiently detailed and that the requirements do not conflict with each other. X X X 1. IEEE 1228 Appendix A.1(b) Specification Analysis

2. JSSSEH Section 4.2.1.6.2 Technical Interfaces

3. AOP52 Section 3.2.1.3.2 Technical Interfaces

4. RTCA DO-178B Section 6.3.1 Reviews and Analyses of the High-Level Requirements

203.06 Contractor shall assign a SwCI to each safety-significant requirement. X X X 1. MIL-STD-882E Section 4.4 Software Contribution To System Risk

2. MIL-STD-882E APPENDIX B SOFTWARE SYSTEM SAFETY ENGINEERING AND ANALYSIS

3. JSSSEH Section 4.2.1.3.1 Software Safety Assurance and Integrity Process

4. JSSSEH Section 4.2.1.5 Defining the Requirements for Level of Rigor

5. JSSSEH Section 4.2.1.8.2 Mishap Probability

6. JSSSEH Section 4.3.5.1 Categories of Software Safety Requirements

7. AOP 52 Section 3.2.1.5 Developing a Software Safety Criticality Index Matrix

8. AOP 52 Section 3.4 Software Safety Risk Assessment	in FHA?
	203.07	Contractor shall provide evidence that the safety-significant high-level requirements are compatible with target computer.	X	X		RTCA DO-178B Section 6.3.1c Reviews and Analyses of the High-Level Requirements	discuss with James and SE
	203.08	Contractor shall perform safety-significant timing and sizing analysis - evaluate safety implications of safety-significant requirements that relate to execution time, clock time, and memory allocation, and multi-threading,	X	X	X	IEEE 1228 Appendix A.1(c) Timing and Sizing Analysis	Move to ssha?

Task 204 - SSHA

	NAVAIR Software System Safety Level of Rigor Tasks - Subsystem Hazard Analysis
	Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
			LOR-1	LOR-2	LOR-3	LOR-4
	204.01	Contractor shall document a Subsystem Hazard Analysis (SSHA) to verify subsystem compliance with requirements to eliminate hazards or reduce the associated risks; to identify previously unidentified hazards associated with the design of subsystems; and, to recommend actions necessary to eliminate identified hazards or mitigate their associated risks. The SSHA shall be performed at the level where software design is implemented.	X	X	X	X	MIL-STD-882E Task 204 Subsystem Hazard Analysis (SSHA)
	204.02	The Developer shall perform a Preliminary Software Design SSHA using applicable techniques identified in the JSSSEH section 4.3.6	X	X	X		JSSSEH Section 4.3.6 Preliminary Software Design, SSHA
	204.03	The Developer shall perform a Detailed Software Design SSHA using applicable techniques identified in the JSSSEH section 4.3.7
Detailed Design shall include all models used to directly (auto generate) or indirectly (manual) develop code.	X	X			JSSSEH Section 4.3.7 Detailed Software Design, SSHA
	204.04	The SSHA shall identify hazards and mitigation measures in software component design	X	X	X		1. MIL-STD-882E Task 204 Section 204.2

2. JSSSEH Section 4.3.1 Analyze and Comprehend the Conceptual Design Baseline of the System

3. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

4. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

5. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)

6. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

7. IEEE 1228 Appendix A.1 Software safety requirements analyses

204.05 The SSHA shall include and document Commercial-Off-the-Shelf (COTS), Government-Off-the-Shelf (GOTS), Government-Furnished Equipment (GFE), Non-Developmental Items (NDI), reused, and developed software. AppendixD shall be applied. X X X 1. MIL-STD-882E Task 204 Section 204.2

2. JSSSEH APPENDIX D COTS and Non-Developmental Item Software

3. AOP 52 Section 5.3 Points to Consider for COTS Software(SRA)

204.06 The SSHA shall consider areas that include performance, performance degradation, functional failures, timing errors, design errors, or defects, and inadvertent functioning. X X X 1. MIL-STD-882E Task 204 Section 204.2

2. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

3. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

4. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)

5. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

204.07 The SSHA shall consider the human a component within a subsystem, receiving both inputs and initiating outputs. X X X 1. MIL-STD-882E Task 204 Section 204.2

2. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

3. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

4. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)

5. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

204.08	The SSHA shall validate applicable flow-down of design requirements from top-level specifications to detailed design specifications for the subsystem.	X	X	X	MIL-STD-882E Task 204 Section 204.2.1a(1)
204.09	The SSHA shall ensure safety design criteria in the subsystem specifications have been satisfied and that verification and validation of subsystem mitigation measures have been included in test plans and procedures.	X	X	X	1. MIL-STD-882E Task 204 Section 204.2.1a(2)

2. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

3. JSSSEH Section 4.3.6.3.3Traceability Analysis

4. JSSSEH Section 4.3.5.3 Documenting SSRs

5. AOP52 Section 3.3.6.4 Documenting Software Safety Requirements

6. IEEE 1228 Appendix A.1(b) Specification Analysis

204.1 The SSHA shall determine and document modes of failure, including component failure modes and human errors, single point and common mode failures, the effects when failures occur in subsystem components, and from functional relationships between components and equipment comprising each subsystem. X X X 1. MIL-STD-882E Task 204 Section 204.2.1b(2)

2. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

3. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

4. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)

5. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

204.11 The SSHA shall ensure system-level hazards attributed to the subsystem are analyzed and adequate mitigations of the potential hazards are implemented in the design. X X X 1. MIL-STD-882E Task 204 Subsystem Hazard Analysis (SSHA)

2. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

3. JSSSEH Section 4.3.5 Safety Requirements Analysis (SRA)

4. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)

5. AOP-52 Section 3.4.2.2.3 Requirements Hazards Analysis

6. IEEE 1228 Appendix A.2 Software Safety Design Analysis

204.12 When software used in conjunction with the subsystem is developed under a separate software development effort, the contractor performing the SSHA shall monitor, obtain, and use the output of each phase of the formal software development process in evaluating the software contribution to the SSHA. X X X 1. MIL-STD-882E Task 204 Section 204.2.3

2. JSSSEH Section 4.2 Software Safety Planning and Management

3. AOP 52 Section 4 Generic Software Safety Design Requirements (SRA)	UCLAS eliminated last sentence
	204.13	The SSHA shall include a description of hazard analysis methods and techniques used in conduct of the analysis as well as other sources of analytical data (e.g.FTA, FMECA etc). Include a description of assumptions made for each analysis and the qualitative or quantitative data used. The SSHA is intended to be a logical analysis of the design utilizing an appropriate analytical technique for the design or concern.	X	X	X	1. MIL-STD-882E Task 204 Section 204.2.5b

2. JSSSEH Section 4.5 Safety Assessment Report

204.14 The SSHA shall include the hazard analysis results. Contents and formats may vary according to the individual requirements of the program and methods and techniques used. Analysis results should be captured in the Hazard Tracking System (HTS). X X X 1. MIL-STD-882E Task 204 Section 204.2.5c

2. MIL-STD-882E Task 106 Hazard Tracking System

3. JSSSEH Section 4.1.3 Software Safety Engineering Products

4. JSSSEH Section 4.5 Safety Assessment Report

204.15 SSHA shall evaluate function implementation, evaluate monitoring strategies (i.e. feedback loops,fault detection) and safety strategies (i.e. unit/component partitioning, authority limits, safe state operations). X X X JSSSEH Section 4.3.6.2 Other Design Considerations for Safety JSSSEH Section E.7 Safety-Critical Computing System Functions Protection Requirements and Guidelines JSSSEH E.8 Interface Design Requirements

204.16 Contractor shall analyze safety-significant algorithms for correctness, accuracy, and validity of assumptions. X X X 1. JSSSEH Section 4.3.7.2 Detailed Design Software Safety Analysis

2. JSSSEH Section C.3.6 Subsystem Hazard Analysis

3. JSSSEH Section 4.3.5.2.2Matured SSRs

4. AOP-52 Section 3.3.6.3 Subsystem Hazard Analysis

5. AOP-52 Section 3.3.6.2 Matured Software Safety Requirements

6. IEEE 1228 Appendix A.2 Software Safety Design Analysis

7. RTCA DO-178B Section 6.3.1g Algorithm Aspects

8. RTCA DO-178B Section 6.3.2g Algorithm Aspects

204.17 Contractor shall perform safety-significant data analysis using applicable techniques described in the JSSSEH section 4.3.7 or comparable methods as accepted by the government. X X X 1. JSSSEH Section 2.5.5.5 Data Interfaces

2. JSSSEH Section4.3.7.3.2.1 Data Structure Analysis

3. JSSSEH Section 4.3.7.3.2.2 Data Flow Analysis

4. IEEE 1228 Appendix A.2(b) Data Analysis

204.18 Contractor shall analyze safety significant software architecture to ensure compatibility with safety-significant high-level requirements, precepts, CONOPS, DODAF assumptions X X X X 1. JSSSEH Section 4.3.6.3.3 Traceability Analysis

2. JSSSEH Section 4.3.7.2 Detailed Design Software Safety Analysis

3. RTCA DO-178B Section 6.3.3a Reviews and Analyses of the Software Architecture

204.19 Contractor shall analyze safety significant software architecture to ensure compatibility with target computer, operating system, and middleware. X X 1. JSSSEH Section 4.3.6.3.3 Traceability Analysis

2. JSSSEH Section 4.3.7.2 Detailed Design Software Safety Analysis

3. RTCA DO-178B Section 6.3.3c Reviews and Analyses of the Software Architecture

204.2 Contractor shall analyze software partitioning to ensure integrity is confirmed. X X X X 1. JSSSEH Section 4.3.6.2 Other Design Considerations for Safety

2. RTCA DO-178B Section 6.3.3f Reviews and Analyses of the Software Architecture

204.21 Contractor shall analyze safety significant source code to ensure compliance with design and design level models if utilized . X X 1. JSSSEH Section 4.3.6.3.3 Traceability Analysis

2. RTCA DO-178B Section 6.3.4a Reviews and Analyses of the Source Code

204.22 Contractor shall analyze safety significant source code to ensure compliance with software architecture. X X 1. JSSSEH Section 4.3.3 Functional Hazard Analysis

2. JSSSEH Section 4.3.6.3.3 Traceability Analysis

3. RTCA DO-178B Section 6.3.4b Reviews and Analyses of the Source Code

204.23 Contractor shall analyze safety significant source code to ensure it is verifiable. X X 1. JSSSEH Section 4.4.2.13 Test Phases

2. RTCA DO-178B Section 6.3.4c Reviews and Analyses of the Source Code

204.24 Contractor shall analyze safety significant source code to ensure it conforms to standards. X X 1. JSSSEH Section 4.4.3 Software Standards and Criteria Assessment

2. JSSSEH Section 4.3.7.3.2 Code-Level Analysis

3. RTCA DO-178B Section 6.3.4d Reviews and Analyses of the Source Code

204.25 Contractor shall analyze safety significant source code to ensure it is accurate and consistent. X X 1. JSSSEH Section 4.3.7.3.2 Code-Level Analysis

2. IEEE 1228 Appendix A.3(a) Software Logic analysis

3. RTCA DO-178B Section 6.3.4f Reviews and Analyses of the Source Code

204.26 Contractor shall ensure safety significant executable object code complies with high-level requirements. X X 1. JSSSEH Section 4.3.6.3.3 Traceability Analysis

2. RTCA DO-178B Section 6.4.2.1 Normal Range Test Cases

3. RTCA DO-178B Section 6.4.3 Requirements-Based Testing Methods

	204.27	Contractor shall ensure safety significant executable object
code complies with the software design (SDD,Model etc).	X	X	1. JSSSEH Section 4.3.6.3.3 Traceability Analysis

2. RTCA DO-178B Section 6.4.2.1 Normal Range Test Cases

3. RTCA DO-178B Section 6.4.3 Requirements-Based Testing Methods

204.28	Contractor shall ensure safety significant executable object code is compatible with target computer.	X	X	X	X	JSSSEH Appendix E 11.14
204.29	Contractor shall perform static code analysis on partitions containing safety significant source code.	X	X	X		1. JSSSEH Section 4.3.7.3.2.7 Code Analysis Software Tools

2. JSSSEH Section 4.3.7.2 Detailed Design Software Safety Analysis

3. JSSSEH Section 4.3.7.3.2 Code-Level Analysis

4. RTCA DO-178B Section 6.3 Software Reviews and Analyses

204.3 Contractor shall perform review of safety significant static code analysis results and provide safety impact. X X X 1. JSSSEH Section 4.3.7.3.2.7 Code Analysis Software Tools

2. JSSSEH Section 4.3.7.2 Detailed Design Software Safety Analysis

3. RTCA DO-178B Section 6.3 Software Reviews and Analyses

204.31 Contractor shall perform and document logical code analysis using methods/techniques defined in the JSSSEH section 4.3.7 or comparible methods/techiniques approved by the government X 1. JSSSEH Section 4.3.7.3.2 Code-Level Analysis

2. IEEE 1228 Appendix A.3(a) Software Logic analysis

204.32 Contractor shall perform and document data analysis - evaluate the data structure and usage in the code to ensure each is defined and used properly by the program. Analysis of the data items used by the program is usually performed in conjunction with logic analysis. X 1. IEEE 1228 Appendix A.3(b) Software Data analysis

2. JSSSEH Section 4.3.7.3.2.1 Data Structure Analysis

3. JSSSEH Section 4.3.7.3.2.2 Data Flow Analysis

204.33 Contractor shall perform safety-significant interface analysis - ensure compatibility of program modules with each other and with external hardware and software. X 1. JSSSEH Section 4.3.7.3.2.4 Interface Analysis

2. IEEE 1228 Appendix A.3(c) Software Interface analysis

3. JSSSEH Section 4.3.7.3.2.3 Control Flow Analysis

204.34 Contractor shall perform safety-significant constraint analysis - ensure that the program operates within the constraints imposed upon it by requirements, the design, and the target computer. Constraint analysis is designed to identify these limitations, to ensure that the program operates within them, and to ensure that all interfaces have been considered for out-of-sequence and erroneous inputs. X 1. JSSSEH Section 4.3.7.3.2.5 Interrupt Analysis

2. IEEE 1228 Appendix A.3(d) Software Constriant analysis

204.35 Contractor shall perform isolation analysis to prove that interfaces between safety-critical code and non-safety-critical code do not create hazards. If isolation is not provable, the Plan should discuss how to handle the risk. X 1. JSSSEH Section 4.3.7.3.2.6 Analysis by Inspection

2. IEEE 1228 Appendix A.3(f) Software Non-critical code analysis

204.36 Contractor shall perform safety-significant timing and sizing analysis to ensure that no hazards due to timing or sizing factors have been added during the development process X X 1. IEEE 1228 Appendix A.3(g) Software Timing analysis

2. JSSSEH 4.4.2.14 Regression Testing

204.37 Contractor shall conduct independent safety review of test plans, cases, procedures and results (unit, integration, functional, system, FMET, regression, etc.). This review shall ensure that safety test cases have been identified and provide adequate safety testing scope (stress, boundary condition, robustness testing, go-no-go, path etc.) of all safety significant design constraints and requirements. Safety test cases shall be done at the lowest appropriate level (e.g. unit level, black box level, system integration level and end level testing) X X X X 1. JSSSEH Section E.13.1 General Testing Guidelines

2. JSSSEH Section 4.4.2.14 Regression Testing

3. JSSSEH Section 4.4.1.1 Guidance for Safety-Critical Software Testing

4. JSSSEH Section 4.4.1.6 Formal Safety Qualification Testing

5. JSSSEH Section 4.4.2 Software Systems Safety Tests

6. JSSSEH Section 4.4.2.2 Functionality Tests

7. JSSSEH Section 4.4.2.7 User Interface Tests

8. JSSSEH Section 4.4.2.8 Fault Insertion and Failure Mode Tests

Task 205 - SHA

	NAVAIR Software System Safety Level of Rigor Tasks - System Hazard Analysis
	Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
			LOR-1	LOR-2	LOR-3	LOR-4
	205.01	The contractor shall perform and document a System Hazard Analysis (SHA) to verify system compliance with requirements to eliminate hazards or reduce the associated risks; to identify previously unidentified hazards associated with the subsystem interfaces and faults; identify hazards associated with the integrated system design, including software and subsystem interfaces; and to recommend actions necessary to eliminate identified hazards or mitigate their associated risks.
Note: the SHA is considered an interface and integration analysis from a software perspective, as such in complex systems the SHA shall require iteration at appropriate levels of abstraction (depth). In complex systems, a 'subsystem" may in itself be a system with internal interfaces and interaction that require analysis.	X	X	X	X	1. MIL-STD-882E Task 205 System Hazard Analysis (SHA)

2. JSSSEH Section 4.3.8 System Hazard Analysis

205.02 The SHA shall include interfaces associated with Commercial-Off-the-Shelf (COTS), Government-Off-the-Shelf (GOTS), Government-Furnished Equipment (GFE), Non-Developmental Items (NDI), and software. Appendix D of the JSSSEH shall be applicable to COTS/GOTS/GFE/NDI X X X 1. JSSSEH Section 4.3.8 System Hazard Analysis

2. JSSSEH Section C.3.7 System Hazard Analysis

3. JSSSEH APPENDIX D COTS AND NON-DEVELOPMENTAL ITEM SOFTWARE

205.03	The SHA shall consider performance, performance degradation, functional failures, timing errors, design errors or defects, and inadvertent functioning.	X	X	X	JSSSEH Section 4.3.8 System Hazard Analysis
205.04	The SHA shall consider possible independent, dependent, and simultaneous events, including system failures, failures of safety devices, common cause failures, and system interactions that could create a hazard or result in an increase in risk.	X	X	X	1. JSSSEH Section 4.3.8 System Hazard Analysis

2. JSSSEH Section C.3.7 System Hazard Analysis

205.05 The SHA shall consider degradation of a subsystem or the total system. X X X 1. JSSSEH Section 4.3.8 System Hazard Analysis

2. JSSSEH Section C.3.7 System Hazard Analysis

205.06 When software to be used within the system is being developed under a separate software development effort, the contractor performing the SHA shall monitor, obtain, and use the output of each phase of the formal software development process in evaluating the software contribution to the SHA. X X X 1. JSSSEH Section 4.3.8 System Hazard Analysis

2. JSSSEH Section C.3.7 System Hazard Analysis

3. IEEE 1228 Section 4.3.12 Subcontract management

205.07 The SHA shall document hazard analysis methods and techniques. Provide a description of each method and technique used in conduct of the analysis. Include a description of assumptions made for each analysis and the qualitative or quantitative data used. X X X 1. JSSSEH Section 4.3.8 System Hazard Analysis

2. JSSSEH Section C.3.7 System Hazard Analysis

Task 206 - O&SHA

NAVAIR Software System Safety Level of Rigor Tasks - Operating and Support Hazard Analysis
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
206.01	The contractor shall perform and document an Operating and Support Hazard Analysis (O&SHA) to identify and assess hazards introduced by operational and support activities and procedures; and to evaluate the adequacy of operational and support procedures, facilities, processes, and equipment used to mitigate risks associated with identified hazards.	X	X	X	X	1. MIL-STD-882E Task 206 Operating and Support Hazard Analysis (O&SHA)

2. JSSSEH Section C.10 Hardware and Human Interface Requirements

206.02 The contractor shall consider software failure contributions to operating and supporting hazards. X X X JSSSEH Section C.10 Hardware and Human Interface Requirements

Task 208 - FHA

NAVAIR Software System Safety Level of Rigor Tasks - Functional Hazard Analysis
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
208.01	The contractor shall perform and document a FHA to identify and classify the system functions and the safety consequences of functional failure or malfunction, i.e. hazards.	X	X	X		1. MIL-STD-882E Section B.2.1 Software System Safety Hazard Analysis

2. MIL-STD-882E Section B.2.2.1 Perform a Functional Hazard Analysis

3. JSSSEH Section 4.2.1.3.2Software Safety Hazard Analysis Process

4. JSSSEH Section 4.3.3 Functional Hazard Analysis

5. AOP52 Section 4.4 Safety-Related Events and Safety-Related Functions

6. IEEE 1228 Appendix A.2(d) Functional Analysis

7. RTCA DO-178B Section 2.2 Failure Condition and Software Level

208.02 The FHA shall provide an assessment of whether the functions identified are to be implemented in the design hardware, software, or human control interfaces. This assessment should map the functions to their implementing hardware or software components. Functions allocated to software should be mapped to the lowest level of technical design or configuration item prior to coding (e.g., implementing modules or use cases). X X X 1. MIL-STD-882E Task 208 Section 208.2.1f

2. MIL-STD-882E Section B.2.1 Software System Safety Hazard Analysis

3. MIL-STD-882E Section B.2.2.1 Perform a Functional Hazard Analysis

4. JSSSEH Section 4.3.3 Functional Hazard Analysis

5. ARP4761 Appendix A Functional Hazard Assessment (FHA)	break into two tasks. For allocation specify level for LOR
	208.03	The FHA shall provide a continual assessment/reassessment of Software Control Category (SCC) for each Safety-significant Software Function (SSSF). A Software Criticality Index (SwCI) shall be assigned for each SSSF mapped to the software design architecture

Based on the architecture and software partitioning the determination of CSCI SwCI shall be assessed based on the highest SwCI function applicable to the CSCI. Accordingly, the appropriate software assurance Level of Rigor shall be applied based on the SwCI. X X X 1. MIL-STD-882E Task 208 Section 208.2.1g

2. MIL-STD-882E Section B.2.2 Software System Safety Integrity

3. JSSSEH Section 4.2.1.3.1 Software Safety Assurance and Integrity Process

4. JSSSEH Section 4.3.6.3.1 Module Safety-Criticality Analysis

5. ARP4754a Section 5.2 Development Assurance Level Assignment

6. MIL-STD-882E Task 208 Section 208.2.2

7. RTCA DO-178B Section 2.2 Failure Condition and Software Level

208.04 The FHA shall provide a list of recommendations (requirements and constraints to be included in the specifications) that, when successfully implemented, will eliminate the software hazard or reduce the criticality of software in the system X X X 1. MIL-STD-882E Task 208 Section 208.2.1h

2. JSSSEH Section 4.3.5.3 Documenting SSRs

3. IEEE 1228 Appendix A.1(b) Specification Analysis

4. AOP52 Section 3.3.6.4 Documenting Software Safety Requirements

5. ARP4754a 4.1.7 Allocation of System Requirements to Items

208.05	Safety significant functions shall be mapped to COTs/GOTs/GFI/NDI/IRAD and apply APPENDIX D of the JSSSEH.	X	X	X	JSSSEH APPENDIX D COTS and Non-Developmental Item Software
208.06	The FHA shall map safety-significant functions to other interfaces and systems in the SoS and determine based on collaboration if the SwCI is impacted by external use of the data and update the FHA as appropriate.	X	X	X	1. MIL-STD-882E Section B.2.2.1 Perform a Functional Hazard Analysis

2. JSSSEH Section 4.3.3 Functional Hazard Analysis

3. ARP4761 Appendix A Functional Hazard Assessment (FHA)

208.07 The FHA shall provide a mechanism to identify top-level mishaps (TLMs), system hazards, and subsystem hazards which supplement the PHL and the PHA. X X X 1. MIL-STD-882E Section B.2.2.1 Perform a Functional Hazard Analysis

2. JSSSEH Section 4.3.3 Functional Hazard Analysis

Task 301 - SAR

NAVAIR Software System Safety Level of Rigor Tasks - Safety Assessment Report
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
301.01	The shall perform and document a Safety Assessment Report (SAR) to provide a comprehensive evaluation of the status of safety hazards and their associated risks prior to test or operation of a system, before the next contract phase, or at contract completion.	X	X	X	X	1. MIL-STD-882E Task 301 Safety Assessment Report (SAR)

2. JSSSEH Section 4.5 Safety Assessment Report

3. JSSSEH Section 4.1.3 Software Safety Engineering Products

301.02 The SAR shall contain information as it relates to recommendations applicable to hazards located at the interface of the system with other systems. X X X 1. JSSSEH Section 4.5 Safety Assessment Report

2. JSSSEH Section 4.1.3 Software Safety Engineering Products

301.03 The SAR shall contain information based on the scope of the report, a summary statement addressing the system’s readiness to test, operate, or proceed to the next acquisition phase. X X X 1. JSSSEH Section 4.5 Safety Assessment Report

2. JSSSEH Section 4.1.3 Software Safety Engineering Products

301.04 The SAR shall list all pertinent references, including (but not limited to) test and analysis reports, standards and regulations, specifications and requirements documents, operating manuals, and maintenance manuals. X X X 1. JSSSEH Section 4.5 Safety Assessment Report

2. JSSSEH Section 4.1.3 Software Safety Engineering Products

301.05 The SAR shall provide evidence of compliance with Level of Rigor and an assessment of risk for any non-compliance. X X X JSSSEH Section 4.4.4 Safety Residual Risk Assessment

Safety Verification Tasks

NAVAIR Software System Safety Level of Rigor Tasks - Safety Specific Verification Requirements
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
Safety Test 01	Contractor shall ensure safety-significant test results are correct and all discrepancies are analyzed and dispositioned.	X	X	X			Need to provide the reference for this.
Safety Test 02	Contractor shall create Functional/integration and unit level safety specific test cases to include hazard/hazard causal factor controls and mitigations are present in a given test event.	X	X			1. JSSSEH Section 4.4.2 Software Systems Safety Tests

2. JSSSEH Section 4.4.2.7 User Interface Tests

3. JSSSEH Section 4.4.2.8 Fault Insertion and Failure Mode Tests Safety Test 03 Contractor shall incorporate safety test cases to verify that all functional, physical, and human interfaces are under positive control . X X X 1. JSSSEH Section 4.4.2.2 Functionality Tests

2. JSSSEH Section 4.4.2.7 User Interface Tests

	Safety Test 04	Contractor shall ensure non- safety-significant software not partitioned from safety-significant software is Regression Tested at the same level as the safety significant software.	X	X	X	JSSSEH Section 4.4.2.14 Regression Testing
	Safety Test 05	Provide complete unit test statement coverage.			X	JSSSEH 4.4.2.4 Statement Coverage Testing
	Safety Test 06	Provide complete unit test decision coverage.		X		JSSSEH 4.4.2.4 Statement Coverage Testing
	Safety Test 07	Provide complete unit test MC/DC coverage.	X			JSSSEH 4.4.2.4 Statement Coverage Testing
	Safety Test 08	Contractor shall ensure requirements based Modified Condition/Decision Coverage (MC/DC) Analysis is performed on representative hardware at the highest appropriatelevel (e.g. CSCI) to ensure test coverage of high-level, low-level requirements, and software structure. It also provides for detection of code errors, dead code, and unintended functionality.
Note: no specific percentage of coverage is required, however, all discrepancies must be justified via documented analysis.	X				1. JSSSEH Section 4.4.1.3 Robustness Testing

2. JSSSEH Section 4.4.1.5 Structural Coverage Analysis

3. JSSSEH Section 4.4.1.4 Requirements Coverage Analysis

4. JSSSEH Section 4.4.1.1 Guidance for Safety-Critical Software Testing

5. JSSSEH Section E.13.3 Formal Test Coverage

	Safety Test 09	Contractor shall conduct requirements based Decision Coverage (DC) Analysis is perfomed on representative hardware at the highest appropriatelevel (e.g. CSCI) to ensure test coverage of high-level, low-level requirements and software structure. It also provides for detection of code errors, dead code, and unintended functionality.
Note: no specific percentage of coverage is required, however, all discrepancies must be justified via documented analysis.		X	1. JSSSEH Section 4.4.1.3 Robustness Testing

2. JSSSEH Section 4.4.1.5 Structural Coverage Analysis

3. JSSSEH Section 4.4.1.4 Requirements Coverage Analysis

4. JSSSEH Section 4.4.1.1 Guidance for Safety-Critical Software Testing

5. JSSSEH Section E.13.3 Formal Test Coverage

	Safety Test 10	Contractor shall conduct requirements based Statement Coverage (SC) Analysis is perfomed on representative hardware at the highest appropriatelevel (e.g. CSCI) to ensure test coverage of high-level, low-level requirements and software structure. It also provides for detection of code errors, dead code, and unintended functionality.
Note: no specific percentage of coverage is required, however, all discrepancies must be justified via documented analysis.			X	1. JSSSEH Section 4.4.1.3 Robustness Testing

2. JSSSEH Section 4.4.1.5 Structural Coverage Analysis

3. JSSSEH Section 4.4.1.4 Requirements Coverage Analysis

4. JSSSEH Section 4.4.1.1 Guidance for Safety-Critical Software Testing

5. JSSSEH Section E.13.3 Formal Test Coverage Safety Test 11 Contractor shall conduct Safety review and analysis of requirements based coverage analysis results to assess risk with uncovered paths. X X X 1. JSSSEH Section 4.4.1.3 Robustness Testing

2. JSSSEH Section 4.4.1.5 Structural Coverage Analysis

3. JSSSEH Section 4.4.1.4 Requirements Coverage Analysis

4. JSSSEH Section 4.4.1.1 Guidance for Safety-Critical Software Testing

5. JSSSEH Section E.13.3 Formal Test Coverage Safety Test 12 Contractor shall conduct Safety review and analyses to ensure test coverage of software structure (data coupling and control coupling) is achieved. X X X 1. JSSSEH Section 4.4.1.3 Robustness Testing

2. JSSSEH Section 4.4.1.5 Structural Coverage Analysis

3. JSSSEH Section 4.4.1.4 Requirements Coverage Analysis

Safety Test 13	Contractor T&E planning shall include safety in the preparation and updating of the T&E Strategy (TES) and the T&E Master Plan (TEMP) to include hazard considerations and identification of when hazard analyses, risk assessments, and risk acceptances shall be completed in order to support T&E schedules.	X	X	X
Safety Test 14	Contractor T&E planning shall include Contractor T&E planning shall include Contractor T&E planning shall include participation in the development of test plans and procedures to include hazard considerations that support analysis of hazards associated with test equipment and procedures.	X	X	X
Safety Test 15	Contractor shall conduct post-test analysis to identify and assess new system hazards, assess effectiveness of mitigation measures, and update risk assessments.	X	X	X

Safety Change Analysis

NAVAIR Software System Safety Level of Rigor Tasks - System Safety Change Analysis Tasks
Task ID	SYSTEM SAFETY TASKS (Software/Firmware)	LEVEL OF RIGOR				REFERENCES	Notes
		LOR-1	LOR-2	LOR-3	LOR-4
Change Analysis 01	Contractor shall perform safety impact analysis for each change to ensure the change does not create a hazard, does not impact on a previously resolved hazard, does not make a currently existing hazard more severe, and does not adversely affect any safety-critical software design element.	X	X	X	X	1. JSSSEH Section C.11 Managing Change

2. JSSSEH Section C.11.1 Software Defect Resolution

3. JSSSEH Section C.11.3 Software Configuration Control Board Change Analysis 02 Contractor shall ensure software changes are traced to their origin and the software life cycle processes repeated from the point at which the change affects their outputs.

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated Nov 14, 2017.