Space Environment Technologies (SET) QUALITY ASSURANCE PROGRAM. Command Media. Approved by: Approved by: Approved by:

(1)

Space Environment Technologies (SET)

QUALITY ASSURANCE PROGRAM

Command Media

Approved by:

___________________

____________________

(2)

1-1

SECTION 1 - QUALITY POLICY & ADMINISTRATION

Scope

This document is the Quality Assurance Program Command Media. It is a dynamic

document (i.e., a living document) that describes the company-wide quality assurance

(QA) policies, processes, and management systems that are applied throughout the life

cycle of all SET products and services. The requirements stated herein are grouped

according to the unit-value criticality of the SET product or service that they are applied

to. These requirements and their enabling activities are purposely described in general

terms, highlighting the key QA activities and associated artifacts. A detailed description

of how the QA requirements and objectives of a particular SET project are met is found

in the QA Program Plan of that project. Suggestions for improving this document should

be brought to the attention of the SET President.

Purpose

The purpose of the SET QA Program is to identify the activities required to assure all

product qualification requirements are met during design, manufacturing, and assembly.

This document identifies the QA activities that should be done and describes how they

should be done. The QA Program Plan (QAPP) is intended to be a living document that

is updated as needed. Each project’s Lead QA Engineer is responsible for developing a

QAPP that will achieve the project’s QA requirements and objectives in a cost-effective

manner. Cumulatively, the tasks described in the QAPP form a structured quality system.

However, the QAPP is not intended to stifle opportunities to adopt improvements in the

quality system that is already in place. Long-term efforts to continuously improve

product or process quality are documented in the SET Quality Improvement Plan.

Document Organization

This command media is organized in eight sections:

1.

Quality Assurance Policy and Administration

2. Overview of SET Operations

3 Product Design Management

4 Supplier Quality Assurance

5 Production Quality Control

6 Customer Contact and Field Performance

7 Closed Loop Corrective Action

8 Employee Management, Training, etc

These eight sections represent the collective goals and objectives for quality assurance by

our management team. They represent the essence of our past successful performance

and our future expectations. While some changes are inevitable, we expect to continue to

implement quality assurance in a cost-effective manner that is commensurate with the

unit-value criticality of the product that it is applied to.

(3)

1-2

SET Quality Assurance Policy

Our entire management team is committed to SET’s long-standing policy to deliver

products and services that conform to their documented specifications at minimum cost.

This policy fosters a company-wide philosophy of “high-quality at low-cost” among our

managers, staff, and subcontractors. Each person and organization is responsible for

establishing and maintaining high standard in their work, with emphasis on doing it right

the first time.

When required by a project, SET will allocate resources to establish a process to

continuously improve our capability to prevent defects from occurring. This process will

be implemented in accordance with a Quality Improvement Plan, which will be a living

document that is updated on a regular basis. The primary focus of this plan is to improve

root cause identification and corrective action implementation. The ancillary focus of

this plan is to reduce costs. This dual-focus approach to QA planning facilitates SET

maintaining its competitive edge in the space weather marketplace’s by providing

cost-effective benefits to our customers over the long term.

Responsibilities /Accountabilities for Quality Assurance

The achievement of our corporate objectives depends on clearly defined responsibilities

and accountabilities. In all aspects of SET’s business, the management team is

responsible for defining and documenting specific responsibilities. The corporate

hierarchy of responsibility is provided in Table 1.

Paul Plumb 12/30/10 9:38 AM

(4)

1-3

Table 1. Quality Assurance Responsibilities/Accountabilities

Position

Responsibility

Company

President

Establish and meet corporate quality policies. Provide the resources and

commitment to implement quality improvement opportunities identified

by managers, staff, subcontractors, and customers.

Lead Quality

Engineer

Define quality requirements and objectives. Maintain quality manuals

and develop quality improvement plans for implementation by systems

engineering functions. Develop quality measuring and reporting

systems. See that goals are met and develop corrective action plans.

Develop QA checklists and distribute them to quality assurance

stake-holders. Provide QA training to QA stake-stake-holders.

Project

Managers

Meet QA requirements and objectives by actively managing the QA

Program Plan tasks that fall within their area of responsibility. Establish

quality goals for their area. Initiate action to correct unfavorable quality

variances, assuring that the root cause of the variance is identified and

eliminated. If required, provide resources to the personnel in their area

to focus on quality improvement and cost reduction efforts that will

provide customers with long term benefits.

Establish personal expectations for high-quality work standards.

Perform job responsibilities with a conscience effort to do the job right

the first time.

Initiate action to correct unfavorable quality variance. Accept full

accountability for the quality of his or her work.

All

Employees

If required, provide inputs to the management team for developing the

Quality Improvement Plan. Be creative in identifying process

improvement opportunities that will reduce costs and increase the level

of quality.

Systems Engineering Artifacts

Systems engineering artifacts will be collected or developed, and maintained to document

the quality assurance efforts of SET and its subcontractors. The artifacts listed below are

of various types, and include the documents that SET is required to develop in

accordance with the Statement of Work:

1.

Contractor’s Internal QA Program Command Media.

2.

Contractor’s proposal.

3.

Customer’s Statement of Work.

4.

Contractor’s subcontractor RFP/SOW

5.

Military and Commercial Standards and Guides

a.

MIL-STD-45662A

b.

MIL-STD-882C

c.

MIL-STD-1629A

d.

SMC Standard SMC-S-003T

(5)

1-4

f.

TBS Decision Analysis Guide (Similar to Quality Function Deployment

Method) (Ref: SOW Section 3.12 DECISION ANALYSIS)

6.

Work Breakdown Structure (WBS)

7.

Systems Engineering Management Plan (SEMP)

8.

Integrate Master Plan (IMP)

9.

Integrated Master Schedule (IMS)

10.

QA Program Budget Plan

11.

QA Program Budget Report

12.

Individual Systems Engineering Discipline Plans/Charters

a.

Risk Management Plan (Ref: SOW Section 3.10 RISK/OPPORTUNITY

MANAGEMENT)

b.

System Safety Program Plan (SSPP)

i.

Capability-based System Safety Process Description

(a)

Hazard Analysis

(b)

Product Safety Testing

(c)

Subcontractor/Supplier System Safety Program

Management (Ref: SOW Section 3.8 SUPPLIER

MANAGEMEN)

ii.

System Safety Program Technical Performance Metrics (Ref:

SOW Section 3.10.1 Technical Performance Measurement)

(a)

System Safety Program Inspection/Audit Criteria

c.

Reliability, Maintainability, Availability and Dependability (RMAD)

Program Plan

i.

Capability-based RMAD Process Description

(a)

Product FMECA

(b)

System Reliability Modeling

(c)

Component Reliability Predictions

a.

Software Component Reliability Predictions

(d)

Maintainability Predictions

(e)

Finite Element Analysis

a.

Circuit Structural Stress Analysis

b.

Circuit Thermal Stress Analysis

(f)

Worst Case Analysis

(g)

Reliability Development/Growth Testing

(h)

Reliability Life Testing

(i)

Subcontract/Supplier RMAD Program Management (Ref:

SOW Section 3.8 SUPPLIER MANAGEMEN)

ii.

RMAD Program Technical Performance Metrics (Ref: SOW

Section 3.10.1 Technical Performance Measurement)

(a)

RMAD Program Inspection/Audit Criteria

d.

Quality Assurance Program Plan (QAPP) (Ref: SOW Section 3.9

QUALITY)

i.

Capability-based Quality Assurance Process Description

(a)

Quality Assurance

(6)

1-5

(c)

Configuration/Data Management (Ref: SOW Section

3.10.2 CONFIGURATION/DATA MANAGEMENT

(CM/DM))

a.

Configuration Control Board (CCB)

b.

Configuration Control Database

(d)

Failure Reporting, Analysis, and Corrective Action System

(FRACAS)

(e)

Failure Review Board (FRB)

(f)

Statistical Process Control (SPC)

(g)

Critical Item Risk Management(CIRM)

(h)

Component Engineering

a.

Preferred Parts List (PPL)

b.

Parts Stress Derating Analysis

(i)

Environmental Stress Screening (ESS)

(j)

Subcontract/Supplier QA Program Management (Ref:

SOW Section 3.8 SUPPLIER MANAGEMEN)

ii.

QA Program Technical Performance Metrics (Ref: SOW Section

3.10.1 Technical Performance Measurement)

(a)

QA Program Inspection/Audit Criteria

e.

Quality Improvement Plan

f.

System Safety Working Group (SSWG) Charter

g.

Reliability and Maintainability Working Group (RMWG) Charter

h.

QA Working (QAWG) Group Charter

i.

Failure Review Board Charter

j.

Configuration Control Board (CCB) Charter

k.

Lessons Learned Approval Process Plan

l.

Lessons Learned Review Committee (LLRC) Charter

m.

Requirements Verification Plan (RVP) (Ref: SOW Section 3.19

VERIFICATION)

i.

Software Requirements Verification Plan (RVP) (Ref: SOW

Section 3.18 CODE & UNIT TEST)

13.

Systems Engineering Discipline Management Reports

a.

Lessons Learned Review Committee (LLRC) Meeting Minutes

b.

Lessons Learned Database Report

c.

Risk Submittal

d.

Risk Management Database Report

e.

System Safety Working Group (SSWG) Meeting Minutes Report

f.

System Safety Program Inspection/Audit Report

g.

Reliability and Maintainability Working Group (RMWG) Meeting

Minutes Report

h.

RMAD Program Inspection/Audit Report

i.

QA Working Group (QAWG) Meeting Minutes Report

j.

QA Program Inspection/Audit Report

k.

Production/Build Records

l.

Failure/Discrepancy Report (FR/DR)

(7)

1-6

n.

Engineering Change Proposal (ECP)

o.

Configuration Control Board (CCB) Meeting Minutes Report

p.

Configuration Control Database Report

q.

Comment Resolution Matrix (CRM)

r.

Waiver Request

s.

Approved Waiver Report

t.

Shipment Records

u.

Training Materials

i.

System Safety Training Materials

ii.

RMAD Training Materials

iii.

QA Training Materials

14.

Systems Engineering Discipline Engineering and Evaluation Reports

a.

Mission Critical Events Analysis Report (Ref: SOW Section 3.13

MISSION ANALYSIS)

b.

Hazard Analysis Reports

i.

System Requirements Hazard Analysis Report (Ref: SOW Section

3.14 SYSTEM REQUIREMENTS ANALYSIS)

(a)

Software Requirements Hazard Analysis Report (Ref:

SOW Section 3.16 SOFTWARE REQUIREMENTS

ANALYSIS)

ii.

Preliminary Hazard Analysis

iii.

Subsystem Hazard Analysis

iv.

System Hazard Analysis

v.

Operating and Support Hazard Analysis

vi.

Health Hazard Assessment

c.

System Architecture Design Trade Study Report (Ref: SOW Section 3.15

ARCHITECTURE DESIGN)

i.

Software Architecture Design Trade Study Report (Ref: SOW

Section 3.17 SOFTWARE DESIGN)

d.

Failure Mode, Effects and Criticality Analysis (FMECA) Report

e.

Reliability Prediction Report

f.

Hazard Reports

g.

Worst Case Analysis Report

h.

Defect Avoidance Checklists

i.

Design Safety Checklist

ii.

Design Reliability Checklist

iii.

QA Checklist

i.

Fishbone Analysis Report

j.

Failure Analysis Report

k.

Part Stress Derating Analysis Report

l.

Process FMECA Report

m.

Approved Parts List (APL) Report

n.

Preferred Parts List (PPL) Report

o.

Critical Items List (CIL) Report

p.

Statistical Process Control (SPC) Report

q.

Waiver Report

(8)

1-7

15.

Systems Engineering Discipline Test Reports

a.

Environmental Stress Screening (ESS) Report

b.

Reliability Development/Growth Testing Report

c.

Reliability Life Testing Report

16.

Product Specifications. Documents that contain detailed descriptions and

drawings that specify the key requirements of each major item produced.

17.

Calibration Standards. Documents that define the test equipment calibration

requirements and the criteria for interpreting product outputs observed during

testing.

18.

Production/Build Procedures. Documents that identify the individual process

steps for producing/building each product and or class of products.

a.

Physical Layout Drawings

b.

Bill of Materials (BOM)

c.

Manufacturing Work Instructions

d.

Computer Program Logic Flow Diagrams

e.

Computer Program Source Code

19.

Inspection Procedure. A document that covers procedures for inspecting

individual products and or class of products.

20.

End of Life Plan (EOLP)

Structure of SET Quality Assurance Program

Many aspects of quality assurance are hard to define because the word

quality

has several

meanings depending on usage. At SET,

quality

is defined as follows:

1.

Quality means meeting the expectations of our customers. This means following

through to determine what our customers require and then meeting those

requirements in every aspect of our business.

2.

Quality means conformance to specifications. This means developing meaningful

specifications for products and services. Then putting forth maximum effort by

each employee to meet those specifications.

3.

Quality also includes reduced loss of data with an increased effort by every

member of the team to do it right the first time.

4.

Quality of grade defines the degree of excellence. At SET, this means a

collaborative effort to achieve a product quality level that is commensurate with

the unit-value criticality of the product that it is applied to.

The SET QA Program structure is divided into the following seven program areas:

1.

Authorization

2.

Requirements Definition

3.

Planning

4.

Coordination

5.

Engineering and Evaluation

6.

Risk Assessment and Tracking

7.

Requirements Verification

(9)

1-8

Table 2 provides a comparison of the Quality Assurance Program Area Objectives versus

(10)

ii

INTRODUCTION

The SET Quality Assurance Program Command Media is based on the QA Program defined in

the AIAA Standard S-102.0.1. The SET QA program is managed independently of the

acquisition or service project’s management chain. The lead Quality Engineer is assigned the

responsibility and authority to ensure all quality assurance requirements are met across the

product life cycle. The QA Program for all high unit-value or above products are required to

effectively avoid anticipated processing faults during the design, manufacturing, testing,

transportation, integration, and operations phases. This is a mandatory requirement that is

implemented through either a contract vehicle or this command media. If QA activities are

omitted in a portion of the life cycle of a high unit-value or above product, then the lead Quality

Engineer is responsible for providing artifacts that verify only negligible or non-credible

processing faults are applicable for the portion of life cycle when QA is omitted.

The Space Environment Technologies (SET) policy is to provide products and services of

optimum value to our customers. At the foundation of our quality assurance programs is our

management team’s commitment to identify and achieve all of the customer’s requirements and

all of our self-imposed objectives. We also assist our customers in defining or redefining their

requirements when the need arises.

The Quality Assurance Program Command Media is a living document that applies to the entire

life cycle of every product and service that SET provides. Its main purpose is to provide a major

part of the capability-based mission assurance framework that SET has adopted to maintain its

competitive edge in the space weather marketplace. The other major parts of our mission

assurance framework are provided by the System Safety Program Command Media, and the

Reliability, Maintainability, Availability and Dependability (RMAD) Program Command Media.

This document describes the structure, key activities, and artifacts of SET’s quality assurance

programs. It is a living document that is intended to be followed by the entire team of every

project. It is supplemented by training courses that are made available to all employees,

subcontractors, partners, and customers. Our goal is to make the capability-based mission

assurance philosophy an integral part of our corporate culture. The principles described herein

represent the cumulative knowledge of many highly-experienced quality assurance experts

through industry. This cumulative knowledge allows us to maintain our competitive advantage

by providing a disciplined approach to optimize our quality assurance efforts.

The continued success of SET depends on our ability to consistently deliver products and

services that meet all of our customer’s requirements and all of our self-imposed objectives, the

first time and on time. As a result, we are committed to finding efficient ways to fully engaging

our employees, subcontractors, partners, and customers, in collaborative efforts to achieve the

optimum balance between cost and mission assurance, which includes our quality assurance

efforts. Each of our mangers has been assigned specific responsibilities for assuring success in

this endeavor, and their performance is evaluated accordingly.

SET has earned many industry-recognized certifications and awards over the years. These

certifications and awards have become the cornerstones of our corporate pride. Among our

Valued Acer Customer 12/6/10 9:33 PM

Comment: The term “optimal value” means that the customer’s costs are optimally balanced against the product’s safety, reliability, and quality assurance (SR&QA) attributes. It does not mean that the product’s SR&QA attributes are maximized.

(11)

iii

recent certifications is the Capability Level IV rating we earned for our enterprise level mission

assurance program. This certification is significant because it also applies to our enterprise level

system safety program, RMAD program, and quality assurance program. We earned this

certification through our affiliation with the S-102 Missions Assurance Standards Working

Group.

(12)

iv

Table of Contents

Section

Title

Page

1.

Quality Policy and Administration

1.1

2.

Overview of SET Operations

2.1

3.

Product Design Management

3.1

4.

Supplier Quality Assurance

4.1

5.

Production Quality Control

5.1

6.

Customer Contact and Field Performance

6.1

7.

Closed Loop Corrective Action

7.1

8.

Employee Management, Training, etc

8.1

(13)

Table 2: Quality Assurance Program Objectives versus Systems Engineering Artifacts Matrix.

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA

1

The contractor has an industry acknowledged basis for authorizing its Quality Assurance Program.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T OUTPUTS:

(a)Customer’s Statement of Work (SOW) (b)Contractor’s proposal and subcontractor

RFP/SOW

(c)Contractor’s Internal QA Program Command Media

(d)QA Program Plan and QA Working Group (QAWG) charter

(a)Document references specific excerpts from AIAA Standard S-102.0.1 or SMC Standard SMC-S-003T as basis for authorization of the Quality Assurance Program.

(b)Quality Assurance Program authorization includes the contractor’s recognition of specific organizations, managers, staff, working groups, procedures, and responsibilities

1

The contractor has an industry acknowledged basis for establishing the minimum qualifications of the Lead Quality Assurance Engineer.

INPUTS:

RFP/SOW

(a)Document references specific excerpts from AIAA Standard S-102.0.1 or SMC Standard SMC-S-003T as basis for establishing the Lead Quality Assurance Engineer’s minimum qualifications.

(b)Lead Quality Assurance Engineer’s qualifications include minimum college degrees and minimum years of directly related experience.

2

The contractor has an industry acknowledged basis for establishing empowering policies to facilitate effective execution of the Quality Assurance Program.

INPUTS:

RFP/SOW

(a)Document describes specific excerpts from AIAA Standard S-102.0.1 or SMC Standard SMC-S-003T as basis for establishing empowering policies to facilitate effective execution of the Quality Assurance Program.

(b)Lead Quality Assurance Engineer’s empowering responsibilities include reporting quality risks directly to the project director, and coordinating all of the quality related activities that are performed by other disciplines. Program

Authorization

3

The contractor has an industry acknowledged basis for acquiring resources to facilitate cost-effective execution of

INPUTS:

RFP/SOW

(d)QA Program Plan and QA Working Group

(a)Document describes specific excerpts from AIAA Standard S-102.0.1 or SMC Standard SMC-S-003T as basis for acquiring resources to facilitate cost-effective execution of the Quality Assurance Program.

(b)Quality Assurance Program resources include the project-wide parts engineering database, and quality engineering checklists to be used by all QA stakeholders in the project.

(14)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (QAWG) charter

4 _{The contractor has an industry acknowledged basis for} interfacing with outside industry organizations and working groups whose charter/goal is to maximize the effectiveness and minimize the risk of industry acknowledged quality assurance methods.

INPUT:

(a)AIAA Standard S-102.0.1 OUTPUT:

(a)Contractor’s Internal QA Program Command Media

(a)Document describes specific excerpts from AIAA Standard S-102.0.1 as basis for interfacing with outside industry organizations and working groups whose charter/goal is to maximize the effectiveness and minimize the risk of industry recognized quality engineering methods. (b)The types of information to be exchanged with

outside industry organizations include non-proprietary lessons learned, part reliability models, and open source computerized tools.

1

All of the applicable systems engineering requirements (including quality and certification requirements) and self-imposed objectives are identified by the lead of each systems engineering discipline using System Requirements Analysis and Software Requirements Analysis methods.

INPUTS:

(c)AIAA Standard S-102.0.1 (a)SMC Standard SMC-S-003T (b)Customer’s Statement of Work (SOW) (c)Contractor’s proposal and subcontractor

RFP/SOW

(d)Contractor’s Internal QA Program Command Media

OUTPUT:

(e)QA Program Plan and QA Working Group (QAWG) charter

(a)All of the quality requirements and their sources are identified in the Requirements vs. Tasks Matrix in the QAPP.

(b)Each discipline is supposed to have a similar matrix in their respective Plan to identify the tasks that will be performed to achieve their particular systems engineering requirements.

1

All implemented systems engineering processes are required to be actively controlled.

INPUTS:

RFP/SOW

(d)Systems Engineering Management Plan (e)Integrated Master Plan

OUTPUT:

(a)Work Breakdown Structure

(a)The contractor’s WBS establishes active control over all implemented systems engineering processes.

Requirements Definition

1

The applicable quality requirements (including quality certification requirements and specified configuration requirements) are incorporated in all program documents

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T (c)Customer’s Statement of Work (SOW) (d)Contractor’s proposal and subcontractor

RFP/SOW

(e)Contractor’s Internal QA Program Command Media

OUTPUTS:

(b)QAPP includes a requirement versus responsible discipline matrix that identifies all of the QA requirements that other disciplines in Systems Engineering have. Each discipline is supposed to have a similar matrix in their respective Plan. The Plan is supposed to identify the tasks that will be

(15)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (a)QA Program Plan and QA Working Group

(QAWG) charter

(b)Individual Systems Engineering Discipline Plans (c)Product specifications

performed to achieve the quality requirements.

1

All of the required deliverables are identified, along with the required reporting format for each one.

INPUTS:

RFP/SOW OUTPUTS:

(a)QA Program Plan and QA Working Group (QAWG) charter

(b)Individual Systems Engineering Discipline Plans

(a)The customer’s Statement of Work (SOW) and the contractor’s subcontractor RFP/SOW identifies the required deliverables, along with their required reporting formats.

(b)The SOW may call out deliverables identified in AIAA Standard S-102.0.1 or SMC Standard SMC-S-003T.

(c)All of the quality requirements and their sources are identified in the Requirements vs. Tasks Matrix in the QAPP.

(d)QAPP includes a requirement versus responsible discipline matrix that identifies all of the QA requirements that other disciplines in Systems Engineering have. Each discipline is supposed to have a similar matrix in their respective Plan that identifies the tasks they will perform to achieve their quality requirements.

2

All applicable quality requirements are flowed down to internal stakeholder and subcontractors.

INPUTS:

RFP/SOW

OUTPUTS:

(b)Individual Systems Engineering Discipline Plans (c) Subcontractor SOW

(d)Subcontractor QAPP

(a)All of the internal QA stakeholders and subcontractors are identified in the QAPP, along with their flowed down QA requirements. (b)The subcontractor SOW identifies the flowed

down QA requirements.

(c)Each subcontractor’s QAPP identifies the tasks to achieve their flowed down QA requirements.

3

The use of industry acknowledged analytical methods is required of all systems engineering disciplines.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T

OUTPUTS:

(a)Individual Systems Engineering Discipline Plans (b)Systems Engineering Discipline Engineering and

Evaluation Reports

(a)Contractor’s Internal QA Program Command Media requires all systems engineering disciplines to use industry acknowledged analytical methods.

(b)The QAPP and Systems Engineering Discipline Plans and Reports should identify their analytical methods and the references to industry acknowledgements.

(16)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA

3 Overlooked, unnecessary, or incorrect quality requirements _{are identified by using Decision Analysis, Mission} Analysis, and Requirements Hazard Analysis, or equivalent methods.

INPUTS:

(a)Decision Analysis Report (b)Mission Analysis Report

(c)Requirements Hazard Analysis Report OUTPUT:

(d)Risk Management Database Report

(a)Contractor’s Risk Management Database Report identifies overlooked, unnecessary, or incorrect quality requirements.

3

Approved waivers are provided for all unmet contract-specified functional performance requirements, and approved exceptions are provided for all unmet contractor-specified configuration requirements.

INPUTS: (a)SEMP (b)IMP

(c)Systems Engineering Discipline Engineering and Evaluation Reports

(d)Requirement Verification Report OUTPUTS:

(a)Risk Management Database Report (b)Approved Waiver Report

(a)The requirement for an approved waiver to be provided for all unmet contract-specified functional performance requirements should be called out in the SEMP and the IMP. (b)Collectively, the Systems Engineering Discipline

Engineering and Evaluation Reports should identify all unmet requirements. (c)Approved Waiver Reports document the

contractors rational for not meeting a significant requirement.

4

Criteria and frequency for self-inspections, and subcontractor proposal evaluations and audits are established.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T OUTPUT:

(c)AIAA Standard S-102.0.1and SMC Standard SMC-S-003T provides guidance for self-inspections.

(a)Contractor’s internal QA Program Command Media defines the criteria and frequency for self-inspections, subcontractor proposal evaluations, and subcontractor audits.

4

The identification of analytical assumptions is required of all systems engineering disciplines.

INPUTS:

(a)AIAA Standard S-102.0.1

(b)Contractor’s Internal QA Program Command Media

OUTPUTS:

(a)Contractor’s Internal QA Program Command Media requires all systems engineering disciplines to identify their analytical assumptions (b)Systems engineering disciplines should include in their respective plans the requirement to identify their analytical assumptions

4

Quality assurance defines the standardized formats for exchanging systems engineering data, including subcontract quality assurance data deliverables.

INPUT:

(a)AIAA Standard S-102.0.1 OUTPUT:

(a)AIAA Standard S-102.0.1and SMC Standard SMC-S-003T provides guidance for standardized formats used to exchange systems engineering data,.

(b)Contractor’s Internal QA Program Command Media defines the required formats for exchanging systems engineering data, including subcontract quality assurance data deliverables. Planning

(Including Test Plans) 1

All applicable quality requirements and self-imposed objectives that QA must meet are identified in the Quality Assurance Program Plan (QAPP).

INPUTS:

(a)QAPP includes a requirement versus task matrix that identifies all of the tasks that QA will perform to achieve their quality requirements. (b)Each discipline is supposed to have a matrix in

(17)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA RFP/SOW

OUTPUTS:

will perform to achieve their quality requirements.

1

All applicable quality requirements (including quality certifications) and self-imposed objectives that other Systems Engineering disciplines must meet are identified in the respective plan of each responsible discipline and in the QAPP. (These plans would include the Systems Engineering Management Plan, the Integrate Master Plan, and the Risk Management Plan.)

INPUTS:

RFP/SOW

OUTPUTS:

(b)Systems Engineering Management Plan (SEMP) (c)Integrate Master Plan (IMP)

(d)Risk Management Plan (e)Quality Improvement Plan (f) System Safety Program Plan (g)RMAD Program Plan (h)End of Life Plan (EOLP)

(a)QAPP includes a requirement versus task matrix that identifies all of the tasks that QA will perform to achieve their quality requirements. (b)QAPP also includes a requirement versus

responsible discipline matrix that identifies all of the QA requirements that other disciplines in Systems Engineering have.

(c)Each discipline is supposed to have a similar matrix in their respective Plan to identify the tasks that they will be perform to achieve their quality requirements.

2

The selection of the measureable and level-of-effort (LOE) quality assurance tasks are based on: (1) comprehensive coverage of the quality requirements and self-imposed objectives, (2) optimized balance among quality assurance costs, schedules, and risk factors, and (3) the applicable system life cycle phases.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T (c)Work Breakdown Structure (WBS) (d)Customer’s Statement of Work (SOW) (e)Contractor’s proposal and subcontractor

RFP/SOW

(f) Contractor’s Internal QA Program Command Media

OUTPUTS:

(b)Integrated Master Plane (IMP) (c)Integrated Master Schedule (IMS) (d)QA Program Budget Plan

(a) The contractor’s internal QA Program Command Media should include a product unit-value criticality versus QA Program capability level matrix.

(b)The contractor’s internal QA Program Command Media also should include a product life cycle versus QA Program capability level activities matrix.

(c) All QA activities that can be “notionally” scheduled should be included in the Integrated Master Schedule (IMS). The rest of the activities should be allocated a fixed number of hours (i.e., Level of Effort) based on “estimated/anticipated” project support needs.

2

All subcontractor key quality assurance data products/deliverables are identified in the QAPP.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T (c)Customer’s Statement of Work (SOW)

(a) The QAPP identifies the subcontractor‘s quality assurance data products/deliverables and their respective required delivery dates. (b)The SEMP and IMP also identify the

(18)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (d)Contractor’s proposal and subcontractor

RFP/SOW

OUTPUTS:

(b)SEMP (c)IMP

(d) Integrated Master Schedule (IMS)

subcontractor‘s quality assurance data products/deliverables

(c) The IMS also identifies the respective required delivery dates.

2

All planned and LOE quality assurance tasks are adequately funded.

INPUTS:

(b)QA Program Plan and QA Working Group (QAWG) charter

(c)Individual Systems Engineering Discipline Plans OUTPUTS:

(a)Integrated Master Schedule (IMS) (b)QA Program Budget Plan

(a)The QAPP identifies all scheduled and LOE quality assurance tasks.

(b)The hours for the scheduled tasks are identified in the IMS.

(c)The rationale for the fixed hours for each LOE task is documented in the QA Program Budget Plan.

(d)The QA Program Budget Plan shows adequate funding for all of the QA tasks.

3

The use of validated analytical methods is planned for all systems engineering disciplines.

INPUTS:

(a)Military and Commercial Standards and Guides (b)Contractor’s Internal QA Program Command

Media OUTPUTS:

(c)Individual Systems Engineering Discipline Plans

(c)Contractor’s Internal QA Program Command Media requires all systems engineering disciplines to use validated analytical methods (d)Systems engineering disciplines should include in

their respective plans the intent to use only validated analytical methods

(e)Systems engineering disciplines identify all key assumptions in their analytical reports.

3

Plans are developed for safe disposal of hazardous materials and of the system itself during the post operational mission.

INPUTS:

RFP/SOW

OUTPUTS:

(b)System Safety Program Plan (SSPP) and System Safety Working Group (SSWG) charter (c)End of Life Plan (EOLP)

(a)The QAPP identifies the system’s post-mission end of life (EOL) requirements that impact quality assurance

(b)The QAPP also identifies system safety as the coordinator of the development of the End of Life Plan (EOLP)

(c)The EOLP should comply with its required format and address all of the EOL requirements

4

A plan is developed and implemented to improve quality of the operational system over time.

INPUTS:

RFP/SOW

(c)Contractor’s Internal QA Program Command

(a)The QAPP identifies the system’s quality improvement requirements.

(b)The QAPP also identifies the Project Quality Improvement Plan development and implementation tasks.

(19)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA Media

OUTPUTS:

(a)Project Quality Improvement Plan (b)Integrated Master Schedule (IMS) (c)FRACAS Plan

(d)FRB Charter

(c)The Project Quality Improvement Plan should comply with its required format and address all of the quality improvement requirements. (d)The schedule for implementing the Project

Quality Improvement Plan should be identified in the IMS.

(e)The FRACAS and the FRB play crucial in roles in identifying and mitigating inherent quality defects. Those roles should be defined in the FRACAS Plan and FRB Charter.

1

Quality assurance participates in all program meetings/reviews that are run by other disciplines that make decisions which impact product quality. (NOTE: This objective includes Failure Review Board (FRB) and Configuration Control Board (CCB) meetings)

INPUTS:

RFP/SOW

OUTPUTS:

(b)QAPP includes a requirement versus responsible discipline matrix that identifies all of the QA requirements that other disciplines in Systems Engineering have. Each discipline is supposed to have a similar matrix in their respective Plan. The Plan is supposed to identify the tasks that will be performed to achieve the quality requirements, and the intent to invite QA to all meetings involving product quality.

1

Quality assurance coordinates the documentation and maintenance of the as-built configurations of all major components

INPUTS:

(c)System drawings and schematics OUTPUTS:

(a)Configuration Control Board (CCB) Database Report

(a)The QAPP describes the process for coordinating the documentation and maintenance of the as-built configurations of all major components. (b)All of the versions of the system drawings and

schematics are maintained in the Configuration Control Database.

Program Coordination

1

Quality assurance coordinates the systems engineering activities that must be performed to obtain the applicable product quality certifications.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T (c)Military and Commercial QA Standards (d)Customer’s Statement of Work (SOW) (e)Contractor’s proposal and subcontractor

RFP/SOW

(f) Contractor’s Internal QA Program Command Media

(g)QA Program Plan and QA Working Group (QAWG) charter

OUTPUTS:

(a)Individual Systems Engineering Discipline Plans

(a)The QAPP identifies each quality certification requirement and all of the disciplines that participate in obtaining each one. (b)The Lead Quality Engineer ensures the quality

certification requirements are included in the Plan of each participating discipline.

(c)The Lead Quality Engineer periodically convenes QA Working Group (QAWG) meetings to ensure that a collaborative effort is implemented to obtain the required quality certifications.

(20)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (b)QA Working Group (QAWG) Meeting Minutes

2

The Lead Quality Engineer tracks the status of tasks and customer deliverables that are shared with other Systems Engineering disciplines.

INPUTS:

RFP/SOW

(f) QA Program Plan and QA Working Group (QAWG) charter

(g)Individual Systems Engineering Discipline Plans OUTPUTS:

(a) QA Working Group (QAWG) Meeting Minutes

(b)QAPP includes a requirement versus responsible discipline matrix that identifies all of the QA requirements that other disciplines in Systems Engineering have. Each discipline is supposed to have a similar matrix in their respective Plan. (c)The Lead Quality Engineer periodically convenes

QA Working Group (QAWG) meetings to ensure that a collaborative effort is implemented to complete tasks and customer deliverables that are shared with other disciplines.

2

Quality assurance inputs to key project documents are properly reviewed, coordinated, and approved.

INPUTS:

OUTPUTS:

(a) Product Specifications (b) Calibration Standards (c) Production Procedures (d) Inspection Procedures

(a)All key project documents that require QA inputs are identified in the QAPP

(b)Each project document for which quality assurance provides a significant input is supposed to have an approval page with a signature line for the Lead Quality Engineer on.

2

The Lead Quality Engineer monitors the QA activities of subcontractors during product design, manufacture, assembly, test, inspection, shipping, and operations.

INPUTS:

(a)Contractor’s proposal and subcontractor RFP/SOW

(c)QA Program Plan and QA Working Group (QAWG) charter

OUTPUTS:

(a)QA Working Group (QAWG) Meeting Minutes

(a)All of the subcontractor quality requirements and their sources are identified in the QAPP. (b)The Lead Quality Engineer periodically convenes

QA Working Group (QAWG) meetings to ensure that subcontractors are properly implementing their required QA tasks.

2

Quality assurance coordinates the documentation and maintenance of the functional test history of all major components.

INPUTS:

(c)Test Reports

(a)The QAPP describes the process for coordinating the documentation and maintenance of the functional test history of all major components.. (b)The Test Records are entered and maintained in the project-wide Systems Engineering Database.

(21)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA OUTPUTS:

(a)Project-wide Systems Engineering Database

3

Quality assurance coordinates the documentation and maintenance of the complete build history of all major components

INPUTS:

(e)QA Program Plan and QA Working Group (QAWG) charter

(f) Production/Build Records OUTPUTS:

(a) Configuration Control Board (CCB) Database Report

(b)The QAPP describes the process for coordinating the documentation and maintenance of the as-built configurations of all major components. (c)All of the Production/Build Records are entered

and maintained in the Configuration Control Database.

3

All quality assurance stake-holders are identified and provided with Defect Avoidance Checklists that enhance defect avoidance.

INPUTS:

(a) Contractor’s Internal QA Program Command Media

(b) QA Program Plan and QA Working Group (QAWG) charter

OUTPUTS:

(a) Defect Avoidance Checklists

(a) The QAPP identifies all of the Systems Engineering disciplines that have quality assurance responsibilities.

(b) The QAPP identifies the development and distribution of QA checklists as tasks. (c) The Lead QA Engineer coordinates the

documentation, approval, and distribution of defect avoidance checklists.

3

The contractor establishes and maintains a program-wide Systems Engineering Database.

INPUTS: (a) SEMP (b) IMP

(c) Contractor’s Internal QA Program Command Media

(d) QA Program Plan and QA Working Group (QAWG) charter

(e) Individual Systems Engineering Discipline Plans

OUTPUTS:

(a) Systems Engineering Database

(a) The SEMP, IMP, and QAPP define the program-wide quality assurance database structure and data fields.

(b) The Systems Engineering Discipline Plans collectively identify the required data fields in the Systems Engineering Database

3 Quality assurance collects, reviews, and utilizes QA lessons learned, as applicable, and ensures that other disciplines also collect and utilize QA lessons learned to help identify existing and potential quality defects early. NOTE: These lessons learned include design, test, and operating guidelines.

INPUTS:

(c) Individual Systems Engineering Discipline Plans

OUTPUTS:

(a) Lessons Learned Review Committee (LLRC) Meeting Minutes

(b) Lessons Learned Database Report

(a) The SEMP, IMP, and QAPP describe the program-wide Lessons Learned Database structure

(b) The Lessons Learned Database Report describes the contents of the Lessons Learned Database (c) Quality assurance is the administrator of the

program-wide Lessons Learned Database

3

Quality assurance evaluates all aspects of the Mission Assurance Program to identify and approve new candidate quality assurance lessons learned, and ensures that other

INPUTS:

(a) The SEMP, IMP, and QAPP describe the program-wide Lessons Learned Database structure

(22)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA disciplines do the same. NOTE: This objective includes

evaluating customer reported failures and in-house subcontractor Failure Reports .

(c) Individual Systems Engineering Discipline Plans

(d) Failure Reports (e) FRB Meeting Minutes

OUTPUTS:

(a) Lessons Learned Review Committee (LLRC) Meeting Minutes

(b) Lessons Learned Database Report

(b) The QAPP and individual Systems Engineering Discipline Plans call out lesson learned identification as a key task

(c) Quality assurance and the other systems engineering disciplines submit new lessons learned to the Lessons Learned Review Committee (LLRC) for approval

3

Quality assurance coordinates the documentation and maintenance of the complete rework history of all major components.

INPUTS:

(c)Production/Build Records OUTPUTS:

(a) Configuration Control Board (CCB) Database Report

(a)The QAPP describes the process for coordinating the documentation and maintenance of the rework history of all major components.

(b)All of the Rework Records are entered and maintained in the Configuration Control Database.

4

Quality assurance coordinates the documentation and maintenance of the complete storage history of all major components.

INPUTS:

OUTPUTS: (a)Shipment Records

(b)Project-wide Systems Engineering Database

(a)The QAPP describes the process for coordinating the documentation and maintenance of the storage history of all major components.

(b)The Shipment Records documents the storage history of all major components.

(c)The Shipment Records are entered and maintained in the project-wide Systems Engineering Database.

4

Quality assurance coordinates the documentation and maintenance of the traceability of lower level parts and materials in all safety-critical and mission-critical components.

INPUTS:

(c)FMECA OUTPUTS:

(a)Critical Items List (CIL)

(a)The QAPP describes the process for coordinating the documentation and maintenance of the traceability history of lower level parts and materials in all safety-critical and mission-critical components

(b)The FMECA identifies the critical items (c)The Critical Items List (CIL) documents the

traceability history of lower level parts and materials in all safety-critical and mission-critical components

(d)The CIL is entered and maintained in the project-wide Systems Engineering Database 4

Quality assurance coordinates the documentation and maintenance of the complete test and inspection history of lower level parts and materials in all safety-critical and

INPUTS:

(a)The QAPP describes the process for coordinating the documentation and maintenance of the complete test and inspection history of lower

(23)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA mission-critical components. (b)QA Program Plan and QA Working Group

(QAWG) charter (c)FMECA OUTPUTS:

level parts and materials in all safety-critical and mission-critical components

complete test and inspection history of lower level parts and materials in all safety-critical and mission-critical components.

(d)The complete test and inspection history of lower level parts and materials are entered and maintained in the project-wide Systems Engineering Database.

4

Quality assurance coordinates the documentation and maintenance of the physical and chemical analysis history of lower level materials in all safety-critical and mission-critical components.

INPUTS:

(c)FMECA OUTPUTS:

(a)The QAPP describes the process for coordinating the documentation and maintenance of the physical and chemical analysis history of lower level parts and materials in all safety-critical and mission-critical components.

physical and chemical analysis history of lower level parts and materials in all safety-critical and mission-critical components.

(d)The physical and chemical analysis history of lower level materials is entered and maintained in the project-wide Systems Engineering Database.

4

Quality assurance ensures stake-holders are trained to properly utilize the Defect Avoidance Checklists and computer-aided tools that they are provided with.

INPUTS:

(c) QA Program Plan and QA Working Group (QAWG) charter

(d) Individual Systems Engineering Discipline Plans OUTPUTS:

(a)QA Training Materials

(a)All of the quality assurance tasks are identified in the QAPP and Systems Engineering Discipline Plans.

(b)The guidance for performing all of the quality assurance tasks is provided in the QA Training Materials.

1 Detailed and comprehensive (a) Statistical Process Control _{(SPC) Reports, (b) Failure/Discrepancy Reports} (FRs/DRs), (c) Fishbone Analysis Reports, (d) Failure Analysis Reports, (e) Part Stress Derating Analysis Report, and the (f) Environmental Stress Screening (ESS) Report are reviewed by quality assurance.

INPUTS:

(a) Statistical Process Control (SPC) Reports (b) Failure/Discrepancy Reports (FRs/DRs) (c) Fishbone Analysis Reports

(d) Failure Analysis Reports

(e) Part Stress Derating Analysis Reports (f) Environmental Stress Screening (ESS) Reports OUTPUT:

(a) Engineering Report Comment Resolution Matrix (CRM)

Quality assurance completes a Comment Resolution Matrix (CRM) for each engineering report that is reviewed.

Engineering & Evaluation

1

The Preferred Parts List (PPL) is developed and

(24)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA maintained. (a) Approved Parts List (APL)

(b) Product Specifications OUTPUT:

(a) Preferred Parts List (PPL)

Specifications.

(b)The PPL is documented, approved, maintained, and updated as needed.

1

The Critical Items List (CIL) is developed and maintained.

INPUTS: (a) FMECA

(b) Hazard Analysis Reports OUTPUT:

(a) Critical Items List (CIL)

(a) The CIL is developed from the FMECA and Hazard Analysis Reports.

(b)The CIL is documented, approved, maintained, and updated as needed.

2 Safety, Reliability, and Quality Assurance (SR&QA) identify, evaluate, and resolve all differences between (1) the build-to and as-built configurations of major components, and (2) the qualification test and acceptance test of major components.

INPUTS:

(a)Engineering Change Proposal (ECP) OUTPUT:

(a)Risk Submittal

(a)Safety, Reliability, and Quality Assurance (SR&QA) review ECP for major components to identify and evaluate possible differences between (1) their build-to and as-built configurations, and (2) their qualification test and acceptance test.

(b)Significant differences that affect the product’s form, fit, or function are documented as risk submittals

2 Product Failure Mode, Effects and Criticality Analysis (FMECA) and Reliability Predictions are performed for all major components, and these analyses correctly represent the product’s design and operation.

INPUTS:

(a)Mission Critical Events Analysis Report (b)Product Specifications

OUTPUTS:

(a)Failure Mode, Effects and Criticality Analysis (FMECA) Report

(b)Reliability Prediction Report

(a)FMECA and Reliability Prediction Report are based on accurate functional diagram models and product descriptions.

(b)FMECA includes identification of both safety-critical and mission-safety-critical functions.

3

Industry acknowledged analytical methods are utilized by all systems engineering disciplines.

INPUTS:

(c)Individual Systems Engineering Discipline Plans OUTPUT:

(a)Systems Engineering Discipline Analytical Reports

(a)Contractor’s QA Program Command Media requires all systems engineering disciplines to use industry acknowledged analytical methods for high unit-value criticality products. (b)The analytical reports of the various systems

engineering disciplines should include references to verify each analytical method is acknowledged by industry.

4

The input data and assumptions that are utilized in all key engineering and analytical methods are evaluated with regard to their maturity.

INPUTS:

(a) Systems Engineering Discipline Analytical Reports

(a)Contractor’s QA Program Command Media requires all systems engineering disciplines to evaluate the maturity of the input data and assumptions that are utilized in all key engineering and analytical methods for high unit-value criticality products.

(b)The analytical reports of the various systems engineering disciplines should identify the maturity of the input data and assumptions used for each analytical method.

(25)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA engineering disciplines should also identify any uncertainties associated with the input data.

4

Quality assurance ensures that validated computer-aided mission assurance tools are acquired and integrated to the greatest extent practical to form a comprehensive mission assurance toolset.

INPUTS:

(a)Systems Engineering Discipline Analytical Reports

(a)Contractor’s QA Program Command Media requires that validated computer-aided mission assurance tools are acquired and integrated to the greatest extent practical to form a comprehensive mission assurance toolset for very-high unit-value criticality products.

(b)The analytical reports of the various systems engineering disciplines should identify the validated computer-aided mission assurance tools that were used.

1

The defect risk mitigation/control order of precedence is defined and enforced across the systems engineering process.

INPUTS:

(d)AIAA Standard S-102.0.1 (a)MIL-STD-882D (b)AFI 91-202 AFSPC SUP1 (c)AFI 91-217

OUTPUTS:

(b)Risk Management Plan (RMP) (c)Failure Review Board (FRB) Charter (d)Configuration Control Board (CCB) Charter

(a)Contractor’s internal QA Program Command Media requires using the risk and problem mitigation order of precedence that is consistent with AIAA Standard S-102.0.1, MIL-STD-882D, AFI 91-202 AFSPC SUP1, and AFI 91-217. (b)The contractor’s QAPP, Risk Management Plan

(RMP), FRB charter, and CCB charter should all define a risk and problem mitigation order of precedence that is consistent with AIAA Standard S-102.0.1 and MIL-STD-882D.

1

All concerns that are identified by FMECA, Worst Case Analysis, Parts Stress Derating Analysis, Circuit Thermal Stress Analysis, and Circuit Structural Stress Analysis are tracked and resolved appropriately.

INPUTS:

(b)Risk Management Plan (RMP) (c)Failure Review Board (FRB) Charter (d)Configuration Control Board (CCB) Charter (e)FMECA Report

(f) Worst Case Analysis Report (g)Parts Stress Derating Analysis Report (h)Circuit Thermal Stress Analysis Report (i) Circuit Structural Stress Analysis Report OUTPUTS:

(a)Risk Management Database Report (b)Hazard Database Report

(a)The contractor’s QAPP, QAWG Charter, Risk Management Plan, and other Plans, should describe the process for tracking and resolving concerns that are identified in analytical reports. (b)The contractor’s Risk Management Database

Report and the Hazard Database Report identify the concerns that are being tracked. Risk Assessment &

Tracking

1

All high and serious defect risks are identified, documented, and appropriately adjudicated.

INPUTS:

(a)The contractor’s internal QA Program Command Media includes a requirement to identify all high and serious defect risks.

(26)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (c)QA Program Plan and QA Working Group

(QAWG) charter

(d)Risk Management Plan (RMP) (e)Failure Review Board (FRB) Charter (f) Configuration Control Board (CCB) Charter OUTPUTS:

(a)Risk Management Database Report (b)Hazard Database Report

Plan (RMP) also should include a requirement to identify all high and serious defect risks. (c)The identified high and serious risks are identified

in the Risk Management Database Report and the Hazard Database Report.

1

The implementation of defect risk mitigations/controls that are chosen are all tracked to closure.

INPUTS:

(b)Risk Management Plan (RMP) (c)Failure Review Board (FRB) Charter (d)Configuration Control Board (CCB) Charter OUTPUTS:

(a)Risk Management Database Report (b)Hazard Database Report

(a)The contractor’s QAPP defines the risk and problem mitigation order of precedence that is consistent with AIAA Standard S-102.0.and MIL-STD-882D.

(b)The contractor’s Risk Management Plan (RMP), FRB charter, and CCB charter also should define the risk and problem mitigation order of precedence that is consistent with AIAA Standard S-102.0.and MIL-STD-882D.

(c)The contractor’s Risk Management Database Report and the Hazard Database Report identify the defect risk mitigations/controls that are being tracked.

2

The defect risk metrics that are selected fully comply with the system safety risk metrics and the reliability risk metrics, in that order of precedence.

INPUTS:

RFP/SOW

(e) Contractor’s Internal QA Program Command Media

OUTPUTS:

(b)System safety Program Plan (SSPP) (c)RMAD Program Plan

(d)Risk Management Plan (RMP)

(a)The SOW, contractor’s QA Program Command Media, QAPP, SSPP, RMAD Program Plan, and Risk Management Plan all should define the defect risk metrics.

(b)The system safety risk metrics should take precedence over the reliability risk metrics if they are different.

3 The Lead Quality Engineer convenes quality assurance working group (QAWG) meetings with peers on a regular basis to identify and mitigate or control quality assurance risks/problems.

INPUT:

(a) QA Program Plan and QA Working Group (QAWG) charter

OUTPUT:

(a) QA Working Group Meeting Minutes

(a)The QAWG Charter should call for the Lead Quality Engineer to convene QAWG meetings with peers on a regular basis to mitigate or control quality assurance risks and correct problems. (b)The QAWG meeting minutes should verify the

authority to convene QAWG meetings was exercised.

3

The contractor reports high and serious risks to the appropriate approval authority.

INPUTS:

(a)The SOW and contractor’s internal QA Program Command Media include requirements to report

(27)

PROGRAM AREA LEVEL OBJECTIVES CANDIDATE ARTIFACTS OUTPUT ARTIFACT EVALUATION CRITERIA (b)SMC Standard SMC-S-003T

(c)Customer’s Statement of Work (SOW) (d)Contractor’s proposal and subcontractor

RFP/SOW

OUTPUTS:

(b)Risk Management Plan (RMP) (c)Risk Management Database Report (d)Hazard Database Report

high and serious defect risks to the appropriate approval authority.

(b)The contractor’s QAPP and Risk Management Plan (RMP) also should include a requirement to report high and serious defect risks to the appropriate approval authority.

(c)The Risk Management Database Report and Hazard Database Report identify the approval authority for each risk submittal.

3

Quality assurance ensures that each requests for a requirement waiver involves a system deficiency that has an acceptable level of risk.

INPUTS:

(a)AIAA Standard S-102.0.1 (b)SMC Standard SMC-S-003T (c)Customer’s Statement of Work (SOW) (d)Contractor’s Internal QA Program Command

Media

(e)System Safety Program Plan (SSPP) (f) RMAD Program Plan

(g)QA Program Plan and QA Working Group (QAWG) charter

(h)Risk Management Plan (i) Waiver Request OUTPUTS: (a)Risk Submittal

(a)The contractor’s internal QA Program Command Media includes a requirement to ensure that each requests for a requirement waiver involves a system deficiency that has an acceptable level of risk.

(b)The acceptable risk criteria are identified in the SSPP, RMAD Program Plan, QAPP, and Risk Management Plan.

(c)Quality assurance evaluates the Waiver Request and generates a Risk Submittal.

(d)The Risk Submittal identifies the residual risk associated with the Waiver Request for a system deficiency.

4

Quality assurance periodically inspects/audits various systems engineering disciplines to identify and mitigate latent process risks early.

INPUTS:

(j) AIAA Standard S-102.0.1 (k)SMC Standard SMC-S-003T (l) Customer’s Statement of Work (SOW) (m)Contractor’s Internal QA Program Command

Media

(n)QA Program Plan and QA Working Group (QAWG) charter

OUTPUTS:

(a)QA Program Inspection/Audit Report

(e)The contractor’s internal QA Program Command Media includes a requirement to periodically audit various systems engineering disciplines. (f) The QA inspection/audit criteria are identified in

<