<Project Name>
<Project Name>
Software Quality Assurance (SQA) Plan
Software Quality Assurance (SQA) Plan
<Document Control Number>
<Document Control Number>
Date:
General Tailoring Guidelines
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
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)
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> <Date><Date> <Reviewer Title>
<Reviewer Title>
_________ _________ <Reviewer Name>
<Reviewer Name> <Date><Date> <Reviewer Title> <Reviewer Title> Approved by: Approved by: _______ _______ <Approver Name>
<Approver Name> <Date><Date> <Approver Title>
<Project Name>
<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>
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.1 PurposePurpose ...11...11 5.2
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.1 PurposePurpose ...13...13 6.2
6.2 Minimum Minimum Software Software ReviewsReviews ...13...13 7.0
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
List Of Tables
Table Table Table 3-2
1.0 Purpose
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
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.]
2.0 Reference Documents
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.
3.0 Management
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>
<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
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.]
[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.]
3.2
Tasks
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 •
[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
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
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
Responsibilities include, but are not limited to: Responsibilities include, but are not limited to:
•
• 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 •
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
Responsibilities include, but are not limited to: Responsibilities include, but are not limited to:
•
• 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
Responsibilities include, but are not limited to: Responsibilities include, but are not limited to:
•
• 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
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.
4.0 Documentation
4.0 Documentation
4.1
Purpose
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 •
5.0 Standards, Practices, Conventions, and Metrics
5.0 Standards, Practices, Conventions, and Metrics
5.1
Purpose
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))
•
• 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)
6.0 Software Reviews
6.0 Software Reviews
6.1
Purpose
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.]
7.0 Test
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
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
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) •
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).
[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
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.
[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
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
Appendix A – Abbreviations & Acronyms
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
GOV Government
GPG
GPG Goddard Goddard Procedures Procedures and and GuidelinesGuidelines GSFC
GSFC Goddard Goddard Space Space Flight Flight CenterCenter IEEE
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
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
SQAP
SQAP Software Software Quality Quality Assurance Assurance PlanPlan SSR
SSR Software Software Specifications Specifications ReviewReview
STD Standard
STD Standard
SW Software
SW Software
TRR
TRR Test Test Readiness Readiness ReviewReview VDD
VDD Version Version Description Description DocumentDocument
VER Version
VER Version
Vs. Verses
Vs. Verses
WI
WI Work Work InstructionInstruction WV