NASA: software quality assurance plan

(1)

<Project Name>

Software Quality Assurance (SQA) Plan

<Document Control Number>

Date:

(2)

General Tailoring Guidelines

This document is a template for a Software Quality Assurance Plan intended for use by Code This document is a template for a Software Quality Assurance Plan intended for use by Code 303, Assurance Management Office (AMO) personnel

303, Assurance Management Office (AMO) personnel as the basis for a mission-specificas the basis for a mission-specific Software Quality Assurance Plan.

Software Quality Assurance Plan. There are three general types of tex

There are three general types of text format: t format: Text in Black, Text Text in Black, Text inin BlueBlue withwith < >< >,, Text

Text inin BlueBlue withwith [ ][ ] and Text underlined inand Text underlined in blueblue.. Text in Black

Text in Black •

• Text in this style, black, is used for Text in this style, black, is used for text that is equally applicable to text that is equally applicable to all Software Qualityall Software Quality Assurance Plans and will be included in the Software Quality Assurance Plan without Assurance Plans and will be included in the Software Quality Assurance Plan without modification. All document section headings are in

modification. All document section headings are in the same category.the same category. Text in

Text in BlueBlue withwith < >< > •

• Text in this style,Text in this style, <blue>,<blue>, is used to indicate that the text needs to be updated withis used to indicate that the text needs to be updated with project specific information such as the project

project specific information such as the project name, persons name, persons title, date,name, persons name, persons title, date, revision #, Document Control Number, exc…

revision #, Document Control Number, exc… Text

Text inin BlueBlue withwith [ ][ ] •

• Text in this style,Text in this style, [blue][blue], is used to indicate that there , is used to indicate that there is additional instruction for tailoringis additional instruction for tailoring text in any s

text in any specific section. pecific section. Delete this styDelete this style,le, [blue][blue], text before the document is, text before the document is finalized.

finalized. Text underlined in Text underlined in BlueBlue

•

• Text in this style,Text in this style, blueblue, is used to indicate active , is used to indicate active links. links. These links are usually to projectThese links are usually to project or software assurance websites.

or software assurance websites. The text color may very depending on The text color may very depending on each personseach persons personal computer settings/configuration.

personal computer settings/configuration. All components of the

All components of the table of contents table of contents will be addressed, but the level of detail is left up to thewill be addressed, but the level of detail is left up to the software quality personnel. The length and

software quality personnel. The length and level of detail of the level of detail of the Software Quality AssuranceSoftware Quality Assurance Plan should be commensurate with

Plan should be commensurate with the scope and complexity of the project.the scope and complexity of the project. Section headings

Section headings may be added where necessary, butmay be added where necessary, but existing headings should not beexisting headings should not be modified or deleted

modified or deleted. If a particular section is not . If a particular section is not applicable to the specific Software Qualityapplicable to the specific Software Quality Assurance Plan under production, that fact should be noted under the section heading, together Assurance Plan under production, that fact should be noted under the section heading, together with a brief explanation.

with a brief explanation. The following

The following disclaimer disclaimer appears on all pages: “Printed copies of this document are forappears on all pages: “Printed copies of this document are for REFERENCE PURPOSES ONLY!

REFERENCE PURPOSES ONLY! The only controlled copy of this The only controlled copy of this document is located on-linedocument is located on-line at

at <<http://xxxxxxxx>http://xxxxxxxx>. This disclaimer should be modified to contain the appropriate URL, but. This disclaimer should be modified to contain the appropriate URL, but should not be removed.

should not be removed.

Finally, in the Software Assurance Plan

Finally, in the Software Assurance Plan Template, this entire section (“Template, this entire section (“ General TailoringGeneral Tailoring Guidelines

(3)

Foreword Foreword This document is a

This document is a <Project Name><Project Name> Project controlled document and adheres to IEEE 730-Project controlled document and adheres to IEEE 730-2002, the IEEE Standard for Software Quality

2002, the IEEE Standard for Software Quality Assurance Plans. Assurance Plans. Changes to this documentChanges to this document require prior approval of the

require prior approval of the <Project Name><Project Name> Project Configuration Control Board (CCB).Project Configuration Control Board (CCB). Proposed changes shall be submitted to the

Proposed changes shall be submitted to the <Project Name><Project Name> Systems Assurance ManagerSystems Assurance Manager (SAM), along with supportive material ju

(SAM), along with supportive material justifying the proposed change.stifying the proposed change. Questions or comments concerning this document should be

Questions or comments concerning this document should be addressed to the Assuranceaddressed to the Assurance Management Office:

Management Office: <Project Name>

<Project Name>,, <SAM Name><SAM Name> /Code 303 /Code 303 Building

Building <XX><XX>RoomRoom <XXX><XXX> Mail Stop

Mail Stop <XXX><XXX>

Goddard Space Flight Center Goddard Space Flight Center Greenbelt, Maryland 20771 Greenbelt, Maryland 20771 (301)

(4)

Signature Page Signature Page Prepared by: Prepared by: _______ _______ <Preparer Name>

<Preparer Name> <Date><Date> <Preparer Title> <Preparer Title> Reviewed by: Reviewed by: _______ _______ <Reviewer Name>

_________ _________ <Reviewer Name>

<Reviewer Name> <Date><Date> <Reviewer Title> <Reviewer Title> Approved by: Approved by: _______ _______ <Approver Name>

(5)

<Project Name> Project Document TitleProject Document Title DOCUMENT CHANGE RECORD

DOCUMENT CHANGE RECORD Sheet: Sheet: 1 1 of of 11

REV/ REV/ VER VER LEVEL LEVEL DESCRIPTION OF CHANGE DESCRIPTION OF CHANGE APPROVED APPROVED BY BY DATE DATE APPRO APPRO VED VED <REV <REV - #> - #> <Initial

<Initial Publication> Publication> <Approver<Approver Name> Name> <Month <Month Day, Day, Year> Year>

(6)

Table of Contents Table of Contents 1.0 1.0 PurposePurpose ...1...1 1.1 1.1 ScopeScope ...1...1 2.0

2.0 Reference Reference Documents...Documents...2...2 3.0

3.0 Management...Management...3...3 3.1

3.1 Management Management OrganizationOrganization ...3...3 3.1.1

3.1.1 <Project Name> <Project Name> Project OfficeProject Office ...33 3.1.2

3.1.2 Assurance Assurance Management Management Office...Office...3...3 3.2

3.2 TasksTasks ...55 3.2.1

3.2.1 Product Product AssessmentsAssessments ...55 3.2.2

3.2.2 Process Process Assessments...Assessments...55 3.3

3.3 Roles Roles and and ResponsibilityResponsibility ...7...7 3.3.1

3.3.1 SAMSAM ...7...7 3.3.2

3.3.2 Software Quality Software Quality PersonnelPersonnel ...7...7 3.3.3

3.3.3 Other Other OSSMA OSSMA PersonnelPersonnel ...8...8 3.4

3.4 Software Assurance Estimated Software Assurance Estimated ResourcesResources ...9...9 4.0

4.0 DocumentationDocumentation ...10...10 4.1

4.1 PurposePurpose ...10...10 4.2

4.2 Minimum Documentation Minimum Documentation RequirementRequirement ...10...10 5.0

5.0 Standards, Practices, Standards, Practices, Conventions, and Conventions, and MetricsMetrics...1111 5.1

5.2 Software QuSoftware Quality Programality Program ...11...11 5.2.1

5.2.1 Standard Standard Metrics...Metrics...11...11 6.0

6.0 Software Software ReviewsReviews...13...13 6.1

6.2 Minimum Minimum Software Software ReviewsReviews ...13...13 7.0

(7)

8.0

8.0 Problem Reporting and Problem Reporting and Corrective ActionCorrective Action ...14...14 9.0

9.0 Tools, Tools, Techniques and Techniques and MethodologiesMethodologies...14....14 9.1

9.1 NASA NASA GSFC GSFC ToolsTools ...14...14 9.2

9.2 Software Software Quality Quality ToolsTools ...1414 9.3

9.3 Project Project Tools...Tools...15...15 10.0

10.0 Media Media ControlControl ...1515 11.0

11.0 Supplier Supplier ControlControl...15...15 12.0

12.0 Record Collection, Maintenance, and RetentionRecord Collection, Maintenance, and Retention ...1616 13

13..0 0 Training Training 1717

14.0

14.0 Risk Risk Management...Management...168168 15.0

15.0 GlossaryGlossary ...179...179 16.0

16.0 SQA SQA Plan Plan Change Change Procedure Procedure and and History History 2020

List Of Tables

Table Table Table 3-2

(8)

1.0 Purpose

The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals, The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals, processes, and responsibilities required to implement effective quality assurance

processes, and responsibilities required to implement effective quality assurance functions forfunctions for the

the <Project Name><Project Name> project.project.

The <Project Name> Software Quality Assurance P

The <Project Name> Software Quality Assurance Plan provides the framework necessary tolan provides the framework necessary to ensure a consistent approach to software quality assurance

ensure a consistent approach to software quality assurance throughout the project life cycle. Itthroughout the project life cycle. It defines the approach that will be used by the SAM and Software Quality (SQ) personnel to defines the approach that will be used by the SAM and Software Quality (SQ) personnel to monitor and assess software development processes and products to

monitor and assess software development processes and products to provide objective insightprovide objective insight into the maturity and quality of

into the maturity and quality of the software. the software. The systematic monitoring ofThe systematic monitoring of <Project Name><Project Name> products, processes, and services will be evaluated to

products, processes, and services will be evaluated to ensure they meet requirements andensure they meet requirements and comply with National Aeronautics and Space Administration (NASA), Goddard Space Flight comply with National Aeronautics and Space Administration (NASA), Goddard Space Flight Center (GSFC), and

Center (GSFC), and <Project Name><Project Name> policies, standards, and procedures, as well as appolicies, standards, and procedures, as well as applicableplicable Institute of Electrical and Electronic Engineers (IEEE)

Institute of Electrical and Electronic Engineers (IEEE) standards.standards.

1.1 Scope

This plan covers SQA activities throughout the

This plan covers SQA activities throughout the <<identify phases, e.g.,identify phases, e.g., formulation andformulation and implementation

implementation>> phases of thephases of the <Project Name><Project Name> mission. mission. [Indicate w[Indicate whether or hether or not SQAnot SQA activities will continue through operations and maintenance

activities will continue through operations and maintenance of the system.]of the system.] [Enter a brief description of

[Enter a brief description of the project, the suppliers of the the project, the suppliers of the software, the software items coveredsoftware, the software items covered by the plan, and their intended use.]

(9)

2.0 Reference Documents

The following documents were used or referenced in the development of this plan: The following documents were used or referenced in the development of this plan:

•

• NASA-STD-8719.13, NASA Software Safety StandardNASA-STD-8719.13, NASA Software Safety Standard •

• NASA-STD-8739.8, NASA Software Assurance StandardNASA-STD-8739.8, NASA Software Assurance Standard •

• NPR 7150.2, NASA Software Engineering RequirementsNPR 7150.2, NASA Software Engineering Requirements •

• GPG 5100.3, Quality Assurance Letter of GPG 5100.3, Quality Assurance Letter of DelegationDelegation •

• GPG 7120.4, Risk ManagementGPG 7120.4, Risk Management •

• GPG 8700.4, Integrated Independent ReviewsGPG 8700.4, Integrated Independent Reviews •

• GPG 8700.6, Engineering Peer ReviewsGPG 8700.6, Engineering Peer Reviews •

• 303-PG-1060.1.1, Systems Assurance Manager Reporting303-PG-1060.1.1, Systems Assurance Manager Reporting •

• 303-PG-1060.1.2, Assurance Management303-PG-1060.1.2, Assurance Management •

• 303-PG-7120.2.1, Procedure for Developing and Implementing Software Quality303-PG-7120.2.1, Procedure for Developing and Implementing Software Quality Programs

Programs •

• 300-PG-7120.2.2, Mission Assurance Guidelines (MAG) For Tailoring to the needs of300-PG-7120.2.2, Mission Assurance Guidelines (MAG) For Tailoring to the needs of GSFC Projects

GSFC Projects •

• 303-WI-7120.2.2, Software Quality Assessment Process303-WI-7120.2.2, Software Quality Assessment Process •

• 303-WI-7120.2.1, Software Quality Reporting Process303-WI-7120.2.1, Software Quality Reporting Process •

• IEEE STD 730-2002, IEEE Standard for Software Quality Assurance PlansIEEE STD 730-2002, IEEE Standard for Software Quality Assurance Plans •

• <Project Name><Project Name> Project Surveillance PlanProject Surveillance Plan •

• <Project Name><Project Name> Project PlanProject Plan •

• <Project Name><Project Name> System Implementation Plan (SIP)System Implementation Plan (SIP) •

• <Project><Project> Software Management Plan (or Product Plan)Software Management Plan (or Product Plan) •

• <Project><Project> Statement of Work (SOW)Statement of Work (SOW) •

• <Project><Project> Configuration Management Plan (CMP)Configuration Management Plan (CMP)

[Update the reference document list to include

[Update the reference document list to include a list of project documents used or a list of project documents used or referenced inreferenced in the development of this plan.

the development of this plan. This includes policies, standardsThis includes policies, standards, procedures, guidelines, and, procedures, guidelines, and other similar

other similar documents. documents. Note: Note: the last the last 6 documents 6 documents listed are listed are examples of projecexamples of project plans thatt plans that you might include.

(10)

3.0 Management

This section describes the management organizational structure, its roles an

This section describes the management organizational structure, its roles and responsibilities,d responsibilities, and the software quality tasks to be

and the software quality tasks to be performed.performed.

3.1

3.1 Management

Management Organization

Organization

<Project Name> efforts are supported by numerous entities, organizations and efforts are supported by numerous entities, organizations and personnel (seepersonnel (see <Project Name>

<Project Name> internal website for internal website for a detailed organizational ca detailed organizational chart). hart). Relevant entities/roles Relevant entities/roles thatthat are of interest and applicable to this SQA Plan and the software assurance effort are described are of interest and applicable to this SQA Plan and the software assurance effort are described at a high level below.

at a high level below. [Enter a copy of the

[Enter a copy of the project’s management organizational chart or the projeproject’s management organizational chart or the project’s website wherect’s website where this information can be found.

this information can be found. This chart should reflect This chart should reflect the project’s interface with Cthe project’s interface with Code 303.]ode 303.]

3.1.1 3.1.1 <Project Name>

<Project Name>

Project Office

The

The <Project Name><Project Name> Project Office at NASA GSFC is responsible for management of projectProject Office at NASA GSFC is responsible for management of project objectives within the guidelines and

objectives within the guidelines and controls prescribed by NASA Headquarters, GSFCcontrols prescribed by NASA Headquarters, GSFC Management, and the

Management, and the <Project Name><Project Name>Project Plan. The Project Manager (PM) from GSFCProject Plan. The Project Manager (PM) from GSFC Code

Code <enter Code><enter Code> is specifically responsible for the success of theis specifically responsible for the success of the <Project Name><Project Name> Project,Project, including but not limited to cost, schedule, an

including but not limited to cost, schedule, and quality.d quality.

3.1.2 3.1.2 Assurance

Assurance Management

Management Office

Office

The Assurance Management Office (AMO), Code 303,

The Assurance Management Office (AMO), Code 303, provides mission assurance support toprovides mission assurance support to NASA GSFC programs and

NASA GSFC programs and projects (Reference projects (Reference 303-PG-1060.1.2). 303-PG-1060.1.2). The AMO is The AMO is comprised ofcomprised of civil service Systems Assurance Managers (SAMs), Quality Assurance Specialists (QASs), and civil service Systems Assurance Managers (SAMs), Quality Assurance Specialists (QASs), and Product Assurance Engineers

Product Assurance Engineers (PAEs). (PAEs). The SAM assigned The SAM assigned to a projectto a project is an AMO civil serviceis an AMO civil service representative responsible for supporting the Project Manager in the coordination of the

representative responsible for supporting the Project Manager in the coordination of the definition and implementation of a

definition and implementation of a Project Mission Assurance Program.Project Mission Assurance Program. The SAM provides Project Management with

The SAM provides Project Management with visibility into the processes being used by thevisibility into the processes being used by the software development teams and t

software development teams and the quality of the products being built. he quality of the products being built. The SAM is matrixed toThe SAM is matrixed to the

the <Project><Project> project and maintains a level of independence from the project and the softwareproject and maintains a level of independence from the project and the software developers.

developers. Risk escalation begins at tRisk escalation begins at the project level, and extends to the AMO he project level, and extends to the AMO and the Officeand the Office of Systems Safety and Mission Assurance (OSSMA), Code

of Systems Safety and Mission Assurance (OSSMA), Code 300.300. In support of software quality assurance activities, the SAM

In support of software quality assurance activities, the SAM has assigned and secured Softwarehas assigned and secured Software Quality personnel from the Mission Assurance Services Contract (MASC)

Quality personnel from the Mission Assurance Services Contract (MASC) to coordinate andto coordinate and conduct the SQ activities f

conduct the SQ activities for the project and identify and document or the project and identify and document noncompliance issues. noncompliance issues. InIn the future and on an as needed basis, SQ personnel support from the Supplier Assurance the future and on an as needed basis, SQ personnel support from the Supplier Assurance Contract (SAC) and/or Defense Contract Management Agency (DCMA) may be

Contract (SAC) and/or Defense Contract Management Agency (DCMA) may be utilized toutilized to support the SQ activities at remote (non-GSFC)

support the SQ activities at remote (non-GSFC) locations.locations.

Additional support personnel may also include OSSMA Safety and Reliability and NASA Additional support personnel may also include OSSMA Safety and Reliability and NASA Independent Verification and Validation (IV&V) personnel from the NASA IV&V Facility in Independent Verification and Validation (IV&V) personnel from the NASA IV&V Facility in Fairmont, WV.

Fairmont, WV. For additional For additional details on Idetails on IV&V activities, V&V activities, reference the reference the IV&V Memorandum IV&V Memorandum ofof Agreement (MOA) and/or the IV&V Project Plan (IVVP).

Agreement (MOA) and/or the IV&V Project Plan (IVVP). [Identify which IV&V agreements/plans[Identify which IV&V agreements/plans are applicable to your project.]

(11)

[Enter any additional management organization and/or suppliers providing support to this [Enter any additional management organization and/or suppliers providing support to this project.

project. Some examples of Some examples of other management organizations other management organizations include the Observatory include the Observatory provider,provider, instrument provider, and/or ground data system providers.]

(12)

3.2 Tasks

This section summarizes the tasks (product and process assessments) to be performed

This section summarizes the tasks (product and process assessments) to be performed duringduring the development, operations, and maintenance of

the development, operations, and maintenance of software. These tasks are selected based onsoftware. These tasks are selected based on the developer’s

the developer’s Project Schedule, Software Management Plan (SMP) (and/or Project Schedule, Software Management Plan (SMP) (and/or SoftwareSoftware

Maintenance Plan) and planned deliverables, contractual deliverables, and identified reviews. Maintenance Plan) and planned deliverables, contractual deliverables, and identified reviews. Reference 303-PG-7120.2.1, Procedure for Developing an

Reference 303-PG-7120.2.1, Procedure for Developing and Implementing Software Qualityd Implementing Software Quality Programs, for additional information on the

Programs, for additional information on the various process and product assessments.various process and product assessments.

Reference 303-WI-7120.2.2, Software Quality Assessment Process, for specific instructions on Reference 303-WI-7120.2.2, Software Quality Assessment Process, for specific instructions on conducting process and product assessments.

conducting process and product assessments.

Reference the NASA GSFC Software Assurance web

Reference the NASA GSFC Software Assurance web site,site, http://sw-assurance.gsfc.nasa.govhttp://sw-assurance.gsfc.nasa.gov toto retrieve software quality check

retrieve software quality checklists and forms. lists and forms. This site is owned and maintained by This site is owned and maintained by the NASAthe NASA GSFC Software Assurance Lead, located in

GSFC Software Assurance Lead, located in the OSSMA.the OSSMA.

3.2.1 3.2.1 Product

Product Assessments

Assessments

The following are typical product as

The following are typical product assessments that may sessments that may be conducted by SQ personnel. be conducted by SQ personnel. SeeSee the SQ Activity Schedule for the

the SQ Activity Schedule for the planned assessments:planned assessments: •

• Peer Review packagesPeer Review packages •

• Document Reviews (see Section 4, Documentation)Document Reviews (see Section 4, Documentation) •

• Software Development FoldersSoftware Development Folders •

• Software Configuration Management (e.g., configuration baselines, configuration changeSoftware Configuration Management (e.g., configuration baselines, configuration change requests, and change control records)

requests, and change control records) •

• Test results (e.g., requirements traceability matrix, test reports)Test results (e.g., requirements traceability matrix, test reports)

3.2.2 3.2.2 Process

Process Assessments

Assessments

The following are typical process a

The following are typical process assessments that mssessments that may be conducted by SQ personnel. ay be conducted by SQ personnel. SeeSee the SQ Activity Schedule for the

the SQ Activity Schedule for the planned assessments:planned assessments: •

• Project PlanningProject Planning •

• Project Monitoring and ControlProject Monitoring and Control •

• Measurement and AnalysisMeasurement and Analysis •

• System/Subsystem ReviewsSystem/Subsystem Reviews •

• Peer ReviewsPeer Reviews •

• Requirements ManagementRequirements Management •

• Software Configuration Management and Configuration Audits (FCA/PCA)Software Configuration Management and Configuration Audits (FCA/PCA) •

• Test Management (Verification & Validation)Test Management (Verification & Validation) •

• Software Problem Reporting and Corrective ActionSoftware Problem Reporting and Corrective Action •

• Risk ManagementRisk Management •

(13)

[Add or delete assessments from Sections 3.2.1 and

[Add or delete assessments from Sections 3.2.1 and 3.2.2 to establish a comprehensive list of3.2.2 to establish a comprehensive list of processes and products you intend to

(14)

3.3

3.3 Roles

Roles and

and Responsibility

Responsibility

This section describes the roles and

This section describes the roles and responsibilities for each assurance person assigned to responsibilities for each assurance person assigned to thethe <Project Name>

<Project Name> Project.Project.

3.3.1 SAM

Responsibilities include, but are not limited to: Responsibilities include, but are not limited to:

•

• Secure and manage SQ personnel resource levelsSecure and manage SQ personnel resource levels •

• Ensure that SQ personnel have office space and the appropriate tools to conduct SQEnsure that SQ personnel have office space and the appropriate tools to conduct SQ activities

activities •

• Provide general guidance and direction to the SQ personnel responsible for conductingProvide general guidance and direction to the SQ personnel responsible for conducting software quality activities and assessments

software quality activities and assessments •

• Issue Letters of Delegation, MASC Service Orders, Issue Letters of Delegation, MASC Service Orders, and SAC task orders to and SAC task orders to initiateinitiate software support services (as required)

software support services (as required) •

• Provide AMO with weekly and quarterly Provide AMO with weekly and quarterly software status (per 303-PG-1060.1.1, Systemssoftware status (per 303-PG-1060.1.1, Systems Assurance Manager Reporting)

Assurance Manager Reporting) •

• Assist SQ personnel in the resolution of any noncompliances, issues and/or risksAssist SQ personnel in the resolution of any noncompliances, issues and/or risks identified as a result of

identified as a result of software quality activitiessoftware quality activities •

• Escalate any noncompliances to project managementEscalate any noncompliances to project management

3.3.2 3.3.2 Software

Software Quality

Quality Personnel

Personnel

•

• Develop and maintain the project Develop and maintain the project software quality assurance plansoftware quality assurance plan •

• Generate and maintain a Generate and maintain a schedule of software quality assurance activitiesschedule of software quality assurance activities •

• Conduct process and product assessments, as described within this Conduct process and product assessments, as described within this plan, usingplan, using objective criteria

objective criteria •

• Interface with Safety, Reliability, and IV&V personnel Interface with Safety, Reliability, and IV&V personnel on software assurance activitieson software assurance activities •

• Identify and document noncompliances, observations, and risks from all Identify and document noncompliances, observations, and risks from all softwaresoftware assurance related activities to the SAM

assurance related activities to the SAM •

• Communicate results from assessments with relevant stakeholdersCommunicate results from assessments with relevant stakeholders •

• Ensure resolution of noncompliances and Ensure resolution of noncompliances and escalate any issues that cannot be resolvedescalate any issues that cannot be resolved within the project

within the project •

• Identify lessons learned that could improve proceIdentify lessons learned that could improve processes for future productssses for future products •

(15)

3.3.3 3.3.3 Other

Other OSSMA

OSSMA Personnel

Personnel

The Systems Safety and Reliability Office, Code 302, provides

The Systems Safety and Reliability Office, Code 302, provides NASA GSFC projects withNASA GSFC projects with Safety and Reliability support.

Safety and Reliability support. The following are the primary responsibilThe following are the primary responsibilities for Safety andities for Safety and Reliability personnel in support of software assurance.

Reliability personnel in support of software assurance.

3.3.3.1

3.3.3.1 Safety

Safety Personnel

Personnel

•

• Provide system software safety expertise to the SQ personnel Provide system software safety expertise to the SQ personnel and/or project personnel,and/or project personnel, as required

as required •

• Assist in the assessment of the various software development Assist in the assessment of the various software development efforts in terms of meetingefforts in terms of meeting applicable software safety standards and requirements

applicable software safety standards and requirements •

• Assist in the resolution of any Assist in the resolution of any software safety related issues, concerns, and/or riskssoftware safety related issues, concerns, and/or risks identified throughout the project life cycle

identified throughout the project life cycle •

• Assist in the review of various Assist in the review of various life cycle related artifacts as they pertain to life cycle related artifacts as they pertain to systemsystem software safety

software safety

For additional support information, reference the proj

For additional support information, reference the project’s System Safety Plan.ect’s System Safety Plan. [Note:

[Note: make sure this informatmake sure this information is covered in the System Safion is covered in the System Safety Plan.]ety Plan.]

3.3.3.2

3.3.3.2 Reliability

Reliability Personnel

Personnel

•

• Provide software reliability expertise to the SQ personnel and/or project personnel, asProvide software reliability expertise to the SQ personnel and/or project personnel, as required.

required. Assist in the assesAssist in the assessment of the various softwsment of the various software development efforts in termsare development efforts in terms of meeting applicable software reliability standards and

of meeting applicable software reliability standards and requirementsrequirements •

• Assist in the resolution of any Assist in the resolution of any software reliability related issues, concerns, and/or riskssoftware reliability related issues, concerns, and/or risks identified throughout the life cycle

identified throughout the life cycle •

• Assist in the review of various Assist in the review of various life cycle related artifacts as they pertain to life cycle related artifacts as they pertain to softwaresoftware reliability

(16)

3.4

3.4 Software

Software Assurance

Assurance Estimated

Estimated Resources

Resources

Staffing to support software assurance (i.e., quality, safety, and reliability)

Staffing to support software assurance (i.e., quality, safety, and reliability) activities must beactivities must be balanced against various project characteristics and constraints, including cost, schedule, balanced against various project characteristics and constraints, including cost, schedule, maturity level of the providers, criticality of the software being

maturity level of the providers, criticality of the software being developed, return on investment,developed, return on investment, perceived risk, etc.

perceived risk, etc.

The staffing resource levels provided in the table below represent what has currently been The staffing resource levels provided in the table below represent what has currently been agreed upon between Project Management and the SAM.

agreed upon between Project Management and the SAM. For applicable IV &V resources, seeFor applicable IV &V resources, see the

the <Project Name><Project Name> IV&V MOA or IVVP. As IV&V MOA or IVVP. As the project’s efforts progress, these staffingthe project’s efforts progress, these staffing resource levels may be revisited and

resource levels may be revisited and updated as necessary to complete the updated as necessary to complete the activities/tasksactivities/tasks described within this plan

described within this plan. . [NOTE: [NOTE: Table 3-2 can Table 3-2 can be omitted fbe omitted from the SQAP rom the SQAP so long as so long as aa reference to the information is provided and the resource information is maintained.]

reference to the information is provided and the resource information is maintained.]

Table

Table 3-2

3-2 Software

Software Assurance

Assurance Resources

Resources

Support

Support Personnel Personnel FYFY<YY><YY> FYFY<YY><YY> FYFY<YY><YY> SQ Personnel

SQ Personnel <x.x><x.x> FTEFTE <x.x><x.x>FTEFTE <x.x><x.x> FTEFTE Safety Personnel

Safety Personnel <x.x><x.x> FTEFTE <x.x><x.x>FTEFTE <x.x><x.x> FTEFTE Reliability Personnel

Reliability Personnel <x.x><x.x> FTEFTE <x.x><x.x>FTEFTE <x.x><x.x> FTEFTE DCMA

DCMA <x.x><x.x> FTEFTE <x.x><x.x>FTEFTE <x.x><x.x> FTEFTE SAC

SAC <x.x><x.x> FTEFTE <x.x><x.x>FTEFTE <x.x><x.x> FTEFTE x.x = FTE number (1.0, 0.5, 2.5,

x.x = FTE number (1.0, 0.5, 2.5, etc…)etc…) YY = Year (04, 05, 06, 07, etc…)

YY = Year (04, 05, 06, 07, etc…)

[Enter the Resource Level by Full Time Equivalent (FTE) and Fiscal Year for the duration of the [Enter the Resource Level by Full Time Equivalent (FTE) and Fiscal Year for the duration of the project life

project life cycle. cycle. Example resource Example resource data is provdata is provided. ided. Update the tUpdate the table to highlight able to highlight all softwareall software assurance resources supporting the project.]

assurance resources supporting the project.]

See Section 9 for a list of additional resources for performing process and product quality See Section 9 for a list of additional resources for performing process and product quality assurance activities.

(17)

4.0 Documentation

4.1 Purpose

This section identifies the minimum documentation governing the

This section identifies the minimum documentation governing the requirements, development,requirements, development, verification, validation, and maintenance of software that falls within the

verification, validation, and maintenance of software that falls within the scope of this softwarescope of this software quality plan.

quality plan. Each document below Each document below shall be assessed shall be assessed (reviewed) by SQ personnel.(reviewed) by SQ personnel. [Include only those documents that exist for your

[Include only those documents that exist for your program/project and that you have program/project and that you have resourcesresources to actually review.

to actually review. Include in section 4.2 knowInclude in section 4.2 known documents from the Software Mn documents from the Software Managementanagement Plan (SMP), Statement of Work (SOW), and

Plan (SMP), Statement of Work (SOW), and Contract Deliverable Requirements List (CDRL).]Contract Deliverable Requirements List (CDRL).]

4.2

4.2 Minimum

Minimum Documentation

Documentation Requirement

Requirement

•

• Quality ManualQuality Manual •

• Software Assurance PlanSoftware Assurance Plan •

• Software Management PlanSoftware Management Plan •

• Configuration Management PlanConfiguration Management Plan •

• Software Requirements SpecificationSoftware Requirements Specification •

• Risk Management PlanRisk Management Plan •

• Software Safety PlanSoftware Safety Plan •

• Test Plans (Verification and Validation)Test Plans (Verification and Validation) •

• Software User’s GuideSoftware User’s Guide •

• Software Maintenance PlanSoftware Maintenance Plan •

• Interface Control Document(s)Interface Control Document(s) •

• Test Reports and ArtifactsTest Reports and Artifacts •

• Software Version Description Document (VDD)Software Version Description Document (VDD) •

• Software Requirements Traceability MatrixSoftware Requirements Traceability Matrix •

• Software Development RecordsSoftware Development Records •

(18)

5.0 Standards, Practices, Conventions, and Metrics

5.1 Purpose

This section highlights the standards, practices, quality requirements, and metrics to

This section highlights the standards, practices, quality requirements, and metrics to be appliedbe applied to ensure a successful software quality program.

to ensure a successful software quality program.

5.2

5.2 Software

Software Quality

Quality Program

Program

Software Quality Programs at GSFC are governed

Software Quality Programs at GSFC are governed by the NASA Software Assurance Policies,by the NASA Software Assurance Policies, the NASA Software Assurance Standard,

the NASA Software Assurance Standard, and the NASA Software Safety Standard. and the NASA Software Safety Standard. Together,Together, these NASA documents establish a common framework for

these NASA documents establish a common framework for software processes and productssoftware processes and products throughout the life of the soft

throughout the life of the software. ware. In addition, SQ personnel are governed by sofIn addition, SQ personnel are governed by software qualitytware quality procedures, work instructions, checklists, and forms developed and approved by

procedures, work instructions, checklists, and forms developed and approved by the AMO.the AMO. These practices and conventions are tools used to ensure a consistent and objective approach These practices and conventions are tools used to ensure a consistent and objective approach to software quality for all GSF

to software quality for all GSFC programs/projects. C programs/projects. SQ personnel are also experienced in theSQ personnel are also experienced in the Software Engineering Institute Capability Maturity Model Integration (SEI-CMMI) methodology Software Engineering Institute Capability Maturity Model Integration (SEI-CMMI) methodology and are applying generic

and are applying generic and specific practices for Process and Product Quality Assuranceand specific practices for Process and Product Quality Assurance (PPQA) in support of GSFC’s Software

(PPQA) in support of GSFC’s Software Process Improvement Program.Process Improvement Program. For details on the specific procedures, work

For details on the specific procedures, work instructions, checklists, and forms used by SQinstructions, checklists, and forms used by SQ personnel, reference

personnel, reference http://sw-assurance.gsfc.nasa.govhttp://sw-assurance.gsfc.nasa.gov.. For details on the development

For details on the development standards for documentation, design, code, and test, referencestandards for documentation, design, code, and test, reference <the developer’s site>.

<the developer’s site>.

5.2.1 5.2.1 Standard

Standard Metrics

Metrics

The following standard metrics are the minimum plann

The following standard metrics are the minimum planned metrics that will be collected, reported,ed metrics that will be collected, reported, and maintained in the area of software quality assurance:

and maintained in the area of software quality assurance: •

• SQ effort and funds expended (Planned vs. Actual)SQ effort and funds expended (Planned vs. Actual) •

• Number of SQ Assessments (Planned vs. Actual)Number of SQ Assessments (Planned vs. Actual) •

• Number of SQ Assessment Findings or Number of SQ Assessment Findings or noncompliances (Open vs. Closed)noncompliances (Open vs. Closed) •

• Number of SQ Assessment ObservationsNumber of SQ Assessment Observations •

• Number of Risks identified as a result of an SQ AssessmentNumber of Risks identified as a result of an SQ Assessment Additional Project metrics may also be collected, reported,

Additional Project metrics may also be collected, reported, and maintained, as required by and maintained, as required by thethe SAM.

SAM. Sample Sample metrics metrics include:include: •

• Number of Peer Reviews (Planned vs. Actual)Number of Peer Reviews (Planned vs. Actual) •

• Number of Open vs. Closed Number of Open vs. Closed Action Items from peer reviewsAction Items from peer reviews •

• Number of Open vs. Closed Software Problem Reports, with aging and trending over aNumber of Open vs. Closed Software Problem Reports, with aging and trending over a specified time frame

specified time frame •

• Number of Open vs. Closed Number of Open vs. Closed IV&V issues (via the Facility’s Project Issue TrackingIV&V issues (via the Facility’s Project Issue Tracking System (PITS))

(19)

•

• Number of Open vs. Closed Number of Open vs. Closed software Requests for Action (RFAs) or Action Items fromsoftware Requests for Action (RFAs) or Action Items from project-level reviews (e.g., mission PDR or CDR)

(20)

6.0 Software Reviews

6.1 Purpose

This section identifies the number and type

This section identifies the number and type of system/subsystem reviews and engineering peerof system/subsystem reviews and engineering peer reviews that will be supported

reviews that will be supported by the SQ Personnel. by the SQ Personnel. The Software Management Plan (SMP),The Software Management Plan (SMP), the project milestone chart, the project’s Engineering Peer Review Plan, and the SQ Personnel the project milestone chart, the project’s Engineering Peer Review Plan, and the SQ Personnel resource levels determine the reviews that are supported.

resource levels determine the reviews that are supported. [Reference only those project plans[Reference only those project plans or schedules that form the basis

or schedules that form the basis of the review schedule.]of the review schedule.] [Identify the location of the software review schedule.] [Identify the location of the software review schedule.]

6.2

6.2 Minimum

Minimum Software

Software Reviews

Reviews

For each review, SQ will

For each review, SQ will assess the review products to assure that review assess the review products to assure that review packages are beingpackages are being developed according to the specified criteria, the

developed according to the specified criteria, the review content is complete, accurate, and ofreview content is complete, accurate, and of sufficient detail, and Request

sufficient detail, and Requests for Action are captured, reviews for Action are captured, reviewed, and tracked to closure. ed, and tracked to closure. InIn addition, SQ will assess the processes used

addition, SQ will assess the processes used to conduct the reviews to determine to conduct the reviews to determine if appropriateif appropriate personnel are in attendance, correct information i

personnel are in attendance, correct information is presented, entry and exit criteria as presented, entry and exit criteria are met,re met, and appropriate documents are identified for update.

and appropriate documents are identified for update. The following software reviews may be assessed by SQ: The following software reviews may be assessed by SQ:

•

• System Concept Review (SCR)System Concept Review (SCR) •

• Software Specification Review (SSR)Software Specification Review (SSR) •

• Preliminary Design Review (PDR)Preliminary Design Review (PDR) •

• Critical Design Review (CDR)Critical Design Review (CDR) •

• Test Readiness Review (TRR)Test Readiness Review (TRR) •

• Acceptance Review (AR)Acceptance Review (AR) •

• Operational Readiness Review (ORR)Operational Readiness Review (ORR) •

• Mission Operations Review (MOR)Mission Operations Review (MOR) •

• Flight Operations Review (FOR)Flight Operations Review (FOR) •

• Peer Reviews (EPR)Peer Reviews (EPR) [Be specific. -- for example, code walkthroughs, design [Be specific. -- for example, code walkthroughs, design reviews,reviews,

etc.] etc.]

See the SQ Activity Schedule for the planned reviews to be supported. See the SQ Activity Schedule for the planned reviews to be supported. [List only those reviews

[List only those reviews you plan to attend and assess. you plan to attend and assess. Add/delete reviews and modify reviewAdd/delete reviews and modify review titles, as appropriate.]

(21)

7.0 Test

SQ personnel will assure that the test management processes and products are being SQ personnel will assure that the test management processes and products are being implemented per the Software Management Plan and

implemented per the Software Management Plan and /or Test Plan(s). /or Test Plan(s). This includes all types ofThis includes all types of testing of software system components as described in the

testing of software system components as described in the test plan, specifically duringtest plan, specifically during integration testing (verification) and acceptance testing (validation).

integration testing (verification) and acceptance testing (validation). SQ personnel will monitor testing e

SQ personnel will monitor testing efforts to assure that test schedules are adhered fforts to assure that test schedules are adhered to andto and maintained to ref

maintained to reflect an aclect an accurate progression curate progression of the of the testing activities. testing activities. SQ will asSQ will assure that sure that teststests are conducted using approved test procedures and appropriate test tools, and that test

are conducted using approved test procedures and appropriate test tools, and that test anomalies are identified, documented, addressed, and

anomalies are identified, documented, addressed, and tracked to closure. tracked to closure. In addition, SQ willIn addition, SQ will assure that assumptions, constraints, and test results are accurately recorded to

assure that assumptions, constraints, and test results are accurately recorded to substantiatesubstantiate the requirements verification/validation status.

the requirements verification/validation status.

SQ personnel will review post-test execution related

SQ personnel will review post-test execution related artifacts including test reports, test results,artifacts including test reports, test results, problem reports, updated requirements verification matrices, etc…

problem reports, updated requirements verification matrices, etc… [Add any additional SQ test[Add any additional SQ test activities (e.g., test witnessing)]

activities (e.g., test witnessing)]

8.0 Problem Reporting and Corrective Action

SQ personnel generate, track, and

SQ personnel generate, track, and trend assessment findings/nonconformances andtrend assessment findings/nonconformances and observations in the centralized Software Quality Engineering

observations in the centralized Software Quality Engineering Repository Database (SQERD),Repository Database (SQERD), available via

available via http://sqerd/gsfc.nasa.govhttp://sqerd/gsfc.nasa.gov /. /. Reference the SQ Assessment Process WI for detailsReference the SQ Assessment Process WI for details on tracking and trending of assessment findings and observations and the reporting escalation on tracking and trending of assessment findings and observations and the reporting escalation process.

process.

[Specify how you communicate your assessment results and corrective action status to

[Specify how you communicate your assessment results and corrective action status to the SAMthe SAM and the

and the project. project. This isThis is critical critical for PPQA.]for PPQA.]

9.0 Tools, Techniques and Methodologies

SQ personnel will require access to the following:

SQ personnel will require access to the following: [Add/delete tools, as appropriate][Add/delete tools, as appropriate]

9.1

9.1 NASA

NASA GSFC

GSFC Tools

Tools

•

• Automated Requirements Measurement (ARM) ToolAutomated Requirements Measurement (ARM) Tool •

• NASA Lessons Learned Information System (LLIS)NASA Lessons Learned Information System (LLIS) •

• Goddard Directives Management System (GDMS)Goddard Directives Management System (GDMS)

9.2

9.2 Software

Software Quality

Quality Tools

Tools

•

• Microsoft Office tools (i.e., Word, Excel, and PowerPoint)Microsoft Office tools (i.e., Word, Excel, and PowerPoint) •

(22)

9.3

9.3 Project

Project Tools

Tools

•

• <Project Name><Project Name> ServerServer •

• <Project Name><Project Name> Risk Management SystemRisk Management System •

• Supplier Web sites and/or Software Development Supplier Web sites and/or Software Development Life cycle Asset/Artifact(s)Life cycle Asset/Artifact(s) Repositories (as applicable)

Repositories (as applicable) •

• Supplier Software Problem Reporting Systems (remote Supplier Software Problem Reporting Systems (remote access preferred)access preferred) •

• On-orbit Anomaly Reporting On-orbit Anomaly Reporting Systems for similar/heritage systems/missionsSystems for similar/heritage systems/missions

10.0 10.0 Media

Media Control

Control

SQ deliverables will be

SQ deliverables will be documented in one of the documented in one of the following Microsoft software applications:following Microsoft software applications: Word, Excel,

Word, Excel, or PowerPoint. or PowerPoint. Deliverables will Deliverables will be in sbe in soft copy, oft copy, unless specified unless specified otherwise. otherwise. SeeSee Section 12 for additional details on the collection and retention of key records.

Section 12 for additional details on the collection and retention of key records. Software Quality deliverables, work products, and data

Software Quality deliverables, work products, and data items shall be maintained in items shall be maintained in accordanceaccordance with the OSSMA Software Quality Assuranc

with the OSSMA Software Quality Assurance Data Management Plan. e Data Management Plan. This plan providesThis plan provides information on the data item, da

information on the data item, data category, owner, location, collection frequency, and datata category, owner, location, collection frequency, and data retention period.

retention period.

11.0 11.0 Supplier

Supplier Control

Control

SQ personnel will conduct off-site surveillance activities at

SQ personnel will conduct off-site surveillance activities at supplier sitessupplier sites <enter suppliers><enter suppliers>onon software development activities.

software development activities. [Specify the various suppliers and how SQ will monitor their[Specify the various suppliers and how SQ will monitor their software processes and products

software processes and products. . Specify whether you intend to utilizSpecify whether you intend to utilize insight, oversight, or ae insight, oversight, or a combination of both.

combination of both. Use the definitions Use the definitions for “insight” and “ovfor “insight” and “oversight”, if needed.]ersight”, if needed.] SQ personnel will conduct a

SQ personnel will conduct a baseline assessment of the supplier(s) Quality Managementbaseline assessment of the supplier(s) Quality Management Systems (QMS) to ensure t

Systems (QMS) to ensure that the supplier(s) have quality processhat the supplier(s) have quality processes in place. es in place. This initialThis initial assessment will help to scope the level

assessment will help to scope the level of effort and follow-on activities in of effort and follow-on activities in the area of softwarethe area of software quality assurance.

quality assurance. [Note: [Note: this baseline assessthis baseline assessment is recommment is recommended, but not a requiremended, but not a requirement.]ent.] Process and product assessments <identify key assessments> will be conducted and

Process and product assessments <identify key assessments> will be conducted and anyany findings will be reported and tracked to resolution.

findings will be reported and tracked to resolution. Insight

Insight: : Surveillance Surveillance mode mode requiring requiring the the monitoring monitoring of of acquirer-identified acquirer-identified metrics metrics andand contracted milestones.

contracted milestones. Insight is a continuum that cInsight is a continuum that can range from low intensity,an range from low intensity, such as reviewing quarterly reports, to high

such as reviewing quarterly reports, to high intensity, such as performing surveysintensity, such as performing surveys and reviews.

and reviews. Oversight:

Oversight: Surveillance mode that is in line with the supplier's processes. The acquirerSurveillance mode that is in line with the supplier's processes. The acquirer retains and exercises the right to concur or nonconcur with the supplier's retains and exercises the right to concur or nonconcur with the supplier's decisions.

decisions. Nonconcurrence must be Nonconcurrence must be resolved before the supplier resolved before the supplier can proceed.can proceed. Oversight is a continuum that can

Oversight is a continuum that can range from low intensity, such as acquirerrange from low intensity, such as acquirer concurrence in reviews (e.g., PDR, CDR), to high i

concurrence in reviews (e.g., PDR, CDR), to high intensity oversight, in which thentensity oversight, in which the customer has day-to-day involvement in the supplier's

customer has day-to-day involvement in the supplier's decision-making processdecision-making process (e.g., software inspections).

(23)

[For previously developed software, this section shall state the

[For previously developed software, this section shall state the methods to be used to methods to be used to ensureensure the suitability of the product for use

the suitability of the product for use with the software items covered by the SQAP.with the software items covered by the SQAP.

For software that is to be developed, the supplier shall be required to prepare and implement an For software that is to be developed, the supplier shall be required to prepare and implement an SQAP in accordance with this standard.

SQAP in accordance with this standard. Discuss the receipt and revDiscuss the receipt and review of that plan and howiew of that plan and how SQ will use the deliverable.

SQ will use the deliverable. Also state the methods to be

Also state the methods to be employed to assure that the suppliers comply employed to assure that the suppliers comply with thewith the requirements of this standard. If software is to be

requirements of this standard. If software is to be developed under contract, then thedeveloped under contract, then the procedures for contract review and update shall be described.]

procedures for contract review and update shall be described.]

12.0 12.0 Record

Record Collection,

Collection, Maintenance,

Maintenance, and

and Retention

Retention

SQ personnel will maintain records

SQ personnel will maintain records that document assessments performed on the project.that document assessments performed on the project. Maintaining these records will provide ob

Maintaining these records will provide objective evidence and traceability of assessmentsjective evidence and traceability of assessments performed throughout the project’s life cy

performed throughout the project’s life cycle. cle. Example records include the process and Example records include the process and productproduct assessments reports, completed checklists, the SQ Activity Schedule, metrics, weekly status assessments reports, completed checklists, the SQ Activity Schedule, metrics, weekly status reports, etc.

reports, etc. For more details on SQ records, their For more details on SQ records, their location, and data retention, referenclocation, and data retention, reference thee the OSSMA Software Quality Assurance Data Management Plan.

OSSMA Software Quality Assurance Data Management Plan.

13.0 Training

SQ personnel shall have fundamental knowledge in the following areas/disciplines through prior SQ personnel shall have fundamental knowledge in the following areas/disciplines through prior experience, training, or certification in methodologies, processes, and

experience, training, or certification in methodologies, processes, and standards:standards: •

• Software Quality Assurance:Software Quality Assurance: •

• Audits and ReviewsAudits and Reviews •

• Risk ManagementRisk Management •

• Configuration ManagementConfiguration Management •

• Software SafetySoftware Safety •

• Contracts/Contractor SurveillanceContracts/Contractor Surveillance •

• CMMICMMI •

• ISO 9001ISO 9001 •

• Project-specific TrainingProject-specific Training •

• ISD Software Engineering DiscussionsISD Software Engineering Discussions

It is the responsibility of the SQ personnel to acquire the necessary skills or knowledge in each It is the responsibility of the SQ personnel to acquire the necessary skills or knowledge in each of the above disciplines.

of the above disciplines. An SQ Training log has been prepared that specifies thAn SQ Training log has been prepared that specifies the type ofe type of training and/or on-the-job experience that has been completed, along with the source of the training and/or on-the-job experience that has been completed, along with the source of the training, and the date of completion.

(24)

[Provide any additional detail regarding review of risks and the SQ relationship with the risk [Provide any additional detail regarding review of risks and the SQ relationship with the risk review team.

review team. Provide link to project’s risk Provide link to project’s risk management system, if applicable.management system, if applicable.]]

15.0 Glossary

Reference 303-PG-7120.2.1, Procedure for Developing an

Reference 303-PG-7120.2.1, Procedure for Developing and Implementing Software Qualityd Implementing Software Quality Programs or the GSFC Software Assurance

Programs or the GSFC Software Assurance web site,web site, http://sw-assurance.gsfc.nasa.govhttp://sw-assurance.gsfc.nasa.gov for thefor the Glossary and software quality acronyms.

Glossary and software quality acronyms.

16.0 16.0 SQA

SQA Plan

Plan Change

Change Procedure

Procedure and

and History

History

SQ personnel are responsible for the maintenance of

SQ personnel are responsible for the maintenance of this plan. this plan. It is expected that thIt is expected that this plan willis plan will be updated throughout the life cycle to reflect any changes in support levels and SQ activities. be updated throughout the life cycle to reflect any changes in support levels and SQ activities. Proposed changes shall be submitted to the

Proposed changes shall be submitted to the <Project Name><Project Name> Systems Assurance ManagerSystems Assurance Manager (SAM), along with supp

(SAM), along with supportive material justifying ortive material justifying the proposed change. the proposed change. Changes to thisChanges to this document require prior approval of the

(25)

Appendix A – Abbreviations & Acronyms

Abbreviation/ Abbreviation/ Acronym Acronym DEFINITION DEFINITION AMO

AMO Assurance Assurance Management Management OfficeOffice AR

AR Acceptance Acceptance ReviewReview ARM

ARM Automated Automated Requirements Requirements ManagementManagement CCB

CCB Configuration Configuration Control Control BoardBoard CDR

CDR Critical Critical Design Design ReviewReview CDRL

CDRL Contract Contract Deliverable Deliverable Requirements Requirements ListList CMMI

CMMI Capability Capability Maturity Maturity Model Model IntegrationIntegration CMP

CMP Configuration Configuration Management Management PlanPlan DCMA

DCMA Defense Defense Contract Contract Management Management AgencyAgency EPR

EPR Engineering Engineering Peer Peer ReviewReview FCA

FCA Functional Functional Configuration Configuration AuditAudit FOR

FOR Flight Flight Operations Operations ReviewReview FTE

FTE Full Full Time Time EquivalentEquivalent GDMS

GDMS Goddard Goddard Directives Directives Management Management SystemsSystems GDS

GDS Ground Ground Data Data SystemSystem

GOV Government

GPG

GPG Goddard Goddard Procedures Procedures and and GuidelinesGuidelines GSFC

GSFC Goddard Goddard Space Space Flight Flight CenterCenter IEEE

(26)

MOA

MOA Memorandum Memorandum of of AgreementAgreement MOR

MOR Mission Mission Operations Operations ReviewReview NASA

NASA National National Aeronautics Aeronautics and and Space Space AdministrationAdministration NPD

NPD NASA NASA Policy Policy DirectiveDirective NPG

NPG NASA NASA Program Program Guideline, Guideline, NASA NASA Policies Policies and and GuidelinesGuidelines NRRS

NRRS NASA NASA Record Record Retention Retention ScheduleSchedule ORR

ORR Operational Operational Readiness Readiness ReviewReview OSSMA

OSSMA Office Office of of Systems Systems Safety Safety and and Mission Mission AssuranceAssurance PAE

PAE Product Product Assurance Assurance EngineerEngineer PCA

PCA Physical Physical Configuration Configuration AuditAudit PDR

PDR Preliminary Preliminary Design Design ReviewReview PG

PG Procedures Procedures and and GuidelinesGuidelines PM

PM Project Project ManagerManager PPQA

PPQA Process Process and and Product Product Quality Quality AssuranceAssurance QAS

QAS Quality Quality Assurance Assurance SpecialistSpecialist QMS

QMS Quality Quality Management Management SystemSystem

REV Revision

SAC

SAC Supplier Supplier Assurance Assurance ContractContract SAM

SAM Systems Systems Assurance Assurance ManagerManager SCR

SCR System System Concept Concept ReviewReview SEI

SEI Software Software Engineering Engineering InstituteInstitute SIP

SIP System System Implementation Implementation PlanPlan SMP

SMP Software Software Management Management PlanPlan SOW

SOW Statement Statement Of Of WorkWork SQ

SQ Software Software QualityQuality SQA

(27)

SQAP

SQAP Software Software Quality Quality Assurance Assurance PlanPlan SSR

SSR Software Software Specifications Specifications ReviewReview

STD Standard

SW Software

TRR

TRR Test Test Readiness Readiness ReviewReview VDD

VDD Version Version Description Description DocumentDocument

VER Version

Vs. Verses

WI

WI Work Work InstructionInstruction WV