COMPLIANCE IS MANDATORY



Similar documents
NODIS Library Program Formulation(7000s) Search

SOFTWARE ASSURANCE STANDARD

Software Quality Assurance: VI Standards

Chapter 3, Section 3-2 (B), dated 1/2002 Chapter 3, Section 3-2 (B), dated 7/2008

CMS Policy for Configuration Management

Engineering Standards in Support of

NASA Information Technology Requirement

NASA S PROCESS FOR ACQUIRING INFORMATION TECHNOLOGY SECURITY ASSESSMENT AND MONITORING TOOLS

NASA OFFICE OF INSPECTOR GENERAL

How To Understand And Understand The Cmm

A. Title 44, United States Code, Chapter 35, Coordination of Federal Information Policy

SEI Level 2, 3, 4, & 5 1 Work Breakdown Structure (WBS)

Department of Veterans Affairs VA Directive 6004 CONFIGURATION, CHANGE, AND RELEASE MANAGEMENT PROGRAMS

SOFTWARE QUALITY & SYSTEMS ENGINEERING PROGRAM. Quality Assurance Checklist

A. This Directive applies throughout DHS, unless exempted by statutory authority.

SOFTWARE SAFETY STANDARD

This document is uncontrolled when printed. Before use, check the Master List to verify that this is the current version. Compliance is mandatory.

Personally Identifiable Information (PII) Breach Response Policy

UNITED STATES DEPARTMENT OF THE INTERIOR BUREAU OF LAND MANAGEMENT MANUAL TRANSMITTAL SHEET

CMS Policy for Capability Maturity Model Integration (CMMI)

How To Write A Contract For Software Quality Assurance

Interpreting the Management Process in IEEE/EIA with the Help of PMBOK

<name of project> Software Project Management Plan

U.S. DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT. Issued: September 6, 2002

Capability Maturity Model Integration (CMMI SM ) Fundamentals

A COMPARISON OF FIVE APPROACHES TO SOFTWARE DEVELOPMENT. David J. Schultz. January 21, 2000

A Report on The Capability Maturity Model

Making Process Improvement Work

HHS OCIO Policy for Information Technology (IT) Enterprise Performance Life Cycle (EPLC)

UNITED STATES DEPARTMENT OF THE INTERIOR BUREAU OF LAND MANAGEMENT MANUAL TRANSMITTAL SHEET Data Administration and Management (Public)

EPA Classification No.: CIO P-01.1 CIO Approval Date: 06/10/2013 CIO Transmittal No.: Review Date: 06/10/2016

DIRECTIVE TRANSMITTAL

5 FAM 620 INFORMATION TECHNOLOGY (IT) PROJECT MANAGEMENT

<Project Name> Software Quality Assurance (SQA) Plan. <Document Control Number>

Treasury Board of Canada Secretariat (TBS) IT Project Manager s Handbook. Version 1.1

TITLE III INFORMATION SECURITY

NASA TECHNICAL STANDARD SOFTWARE SAFETY STANDARD

NOTICE: This publication is available at:

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Optimizing Organizational Measurement and Analysis ROI for Small Diverse Projects. Susanna Schwab July 2007

THE STATUS OF ENTERPRISE ARCHITECTURE AND INFORMATION TECHNOLOGY INVESTMENT MANAGEMENT IN THE DEPARTMENT OF JUSTICE

How To Check If Nasa Can Protect Itself From Hackers

NASA S INFRASTRUCTURE AND FACILITIES: AN ASSESSMENT OF THE AGENCY S REAL PROPERTY MASTER PLANNING

AUDIT OF NASA S EFFORTS TO CONTINUOUSLY MONITOR CRITICAL INFORMATION TECHNOLOGY SECURITY CONTROLS

Leveraging CMMI framework for Engineering Services

INDEPENDENT VERIFICATION AND VALIDATION OF EMBEDDED SOFTWARE

Document Control. DOWNLOADED AND/OR HARD COPY UNCONTROLLED Verify that this is the correct version before use.

Configuration Management

Information Resource Management Directive USAP Information Security Risk Management

Get Confidence in Mission Security with IV&V Information Assurance

Distributed and Outsourced Software Engineering. The CMMI Model. Peter Kolb. Software Engineering

Software Engineering Improvement Support Activities

NASA s FY 2014 Management and Performance

Continuous Risk Management at NASA

International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research)

NASA Procedural Requirements

Systems Development Life Cycle (SDLC)

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

Overview Presented by: Boyd L. Summers

How DCMA Helps To Ensure Good Measurements

SYSTEMS ENGINEERING AND MANAGEMENT FOR SUSTAINABLE DEVELOPMENT - Vol. I - Configuration Management - Brouse, Peggy S.

What Good is a HQ Program Executive?

PRIVACY IMPACT ASSESSMENT

Software Process Improvement CMM

The Advantages and Disadvantages of Using Software Engineering Standards

Subject: Information Technology Configuration Management Manual

Configuration Management Plan (CMP) Template

United States Antarctic Program Information Resource Management Directive The USAP Information Security Program

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

Report via OMB s Integrated Data Collection (IDC), 10

CMMI KEY PROCESS AREAS

Capability Maturity Model Integrated (CMMI)

How Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model

W September 14, Final Report on the Audit of Outsourcing of Desktop Computers (Assignment No. A-HA ) Report No.

CONTENTS. Preface. Acknowledgements. 1. Introduction and Overview 1 Introduction 1 Whatis the CMMI"? 2 What the CMMI* is Not 3 What are Standards?

Department of Defense INSTRUCTION

NASA Information Technology Requirement

NDIA CMMI Technology Conference and User Group NASA Experience with CMM and CMMI

ClOP CHAPTER Departmental Information Technology Governance Policy TABLE OF CONTENTS. Section 39.1

IEEE Software Engineering Risk Management: Measurement-Based Life Cycle Risk Management PSM 2001 Aspen, Colorado

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

NATIONAL CREDIT UNION ADMINISTRATION OFFICE OF INSPECTOR GENERAL

Assuring Software Cost Estimates: Is it an Oxymoron?

CENTRE (Common Enterprise Resource)

AUDIT REPORT OFFICE OF INSPECTOR GENERAL IG FASTER, BETTER, CHEAPER: POLICY, STRATEGIC PLANNING, AND HUMAN RESOURCE ALIGNMENT.

US Department of Education Federal Student Aid Integration Leadership Support Contractor June 1, 2007

DATA STANDARDS POLICY

April 30, 2004 Report No Enhancements to the FDIC System Development Life Cycle Methodology AUDIT REPORT

A Lightweight Supplier Evaluation based on CMMI

Software Quality Standards and. from Ontological Point of View SMEF. Konstantina Georgieva

Audit of Veterans Health Administration Blood Bank Modernization Project

Process Improvement. Process improvement. Process improvement stages. Understanding, Modelling and Improving the Software Process

An Overview of IEEE Software Engineering Standards and Knowledge Products

Transmittal Sheet #: Date: July 12, 2005

Information Resource Management Directive The USAP Security Assessment & Authorization Program

Using PRINCE2 to Manage US Federal Government IT Projects

Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

MEMORANDUM FOR THE HEADS OF DEPARTMENTS AND AGENCIES

Future of CMM and Quality Improvement. Roy Ko Hong Kong Productivity Council

Transcription:

NODIS Library Legal Policies(2000s) Search NASA Directive: NPD 2820.1A POLICY Effective Date: May 29, 1998 DIRECTIVE Expiration Date: May 29, 2005 COMPLIANCE IS MANDATORY This Document Is Uncontrolled When Printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: http://nodis3.gsfc.nasa.gov Responsible Office: D / Office of the Chief Engineer Subject: NASA Software Policies (Revalidated 5/29/04) 1. POLICY The following policies cover software created and acquired by or for NASA and also cover Government off-the-shelf (GOTS) software and commercial off-the-shelf (COTS) software when included in a NASA system. These policies shall be applied consistent with sound engineering and risk management practices as determined by cost, size, complexity, life span, risk, and consequences of failure. NASA policy regarding software management, engineering, and assurance is to accomplish the following: a. Manage, engineer, and assure software in accordance with common industry standards, processes, and best practices; document the use of standards, processes, and best practices; and tailor standards, processes, and best practices to the development or acquisition. b. Implement and integrate software engineering processes and practices with other system development and program/project processes and practices. Develop a plan for acquisition and life-cycle management of the software as part of the program/project plan. This plan should be developed prior to selection of the provider and should address, at a minimum, design tradeoff management, risk management, requirements management, software project planning, project tracking and oversight, software product engineering, subcontract management, configuration management, quality assurance, and peer review. c. Develop and maintain a total estimated software life-cycle cost and, where appropriate, perform tradeoff studies which address use of COTS and GOTS software versus created software to satisfy requirements before software is created or acquired. d. Demonstrate that the provider of software to be developed has proven organizational capabilities and experience to deliver quality software on time and within budget; require acceptable evidence of the entity`s software management, engineering, and assurance standards, processes, and practices to produce quality software. Examples of current acceptable evidence include an independent assessment of a software Capability Maturity Model (CMM) rating of 3 or above. The provider shall develop a plan to manage software throughout the program/project life cycle before the software requirements specification is complete and software design and coding takes place. The plan shall address items required in 1.b. e. Document software as to its form and function and verify that such software performs the functions claimed on the platform(s) for which it is 1 of 5 6/9/2004 11:12 AM

designed without harm to the systems or the data contained therein. f. Develop risk analyses and management strategies; identify, analyze, plan, track, control, and communicate risks at each stage of the life cycle; document or reference (i.e., their location specified) the results of risk analyses and management strategies in program/project plans; and employ verification and validation techniques for risk mitigation, including Independent Verification and Validation (IV&V), based risk and consequences of failure. g. Facilitate reuse of NASA-funded software, as well as transfer, consistent with law and applicable agreements, for commercial, industrial, educational, and governmental purposes; and protect NASA-funded or -created software as valuable intellectual property during all phases of the life cycle. 2. APPLICABILITY This Directive applies to NASA Headquarters and Centers, including Component Facilities, and the Jet Propulsion Laboratory to the extent defined in its contract, for all software acquisitions and developments initiated by NASA after the effective date of this directive. This Directive applies to software acquisitions and developments initiated by NASA prior to the effective date when determined by either the responsible Program Associate Administrator or the Center Director of the implementing Center. 3. AUTHORITY a. 42 U.S.C. 2473(c)(1) of the National Aeronautics and Space Act of 1958, as amended. b. Public Law 104-13, Paperwork Reduction Act of 1995. c. 40 U.S.C. 1401, et seq. Section 808 of Public Law 104-208, the Clinger-Cohen Act of 1996 [renaming, in pertinent part, the Information Technology Management Reform Act (ITMRA), Division E of Public Law 104-106. d. OMB Circular A-130, Management of Federal Information Resources. 4. REFERENCES a. See Attachment 1 for references that apply to the management, engineering, and assurance of NASA software. b. See Attachment 2 for references that are relevant to the management, engineering, and assurance of NASA software. 5. RESPONSIBILITY The NASA Chief Information Officer (CIO), the NASA Chief Engineer, and the Associate Administrator for Safety and Mission Assurance (AA-SMA) are responsible for jointly promoting software policies, standards, best practices, and guidance in their areas of responsibility. They shall coordinate efforts to maximize the commonality, clarity, and effectiveness of direction and guidance. Roles and responsibilities for all NASA entities relative to this policy will be carried out within the framework of the Strategic Management Handbook and are not repeated here: a. The NASA CIO shall promote the cost-effective acquisition, development, and operation of software in support of NASA missions, programs, and institutions. This shall be accomplished in conjunction with the Office of Safety and Mission Assurance, the Office of the Chief Engineer, and the Enterprise offices. b. The NASA Chief Engineer shall integrate NASA software management, engineering, and assurance policies, standards, best practices, and guidance into directives applicable to NASA`s systems engineering and 2 of 5 6/9/2004 11:12 AM

program management processes. The NASA Chief Engineer and the Engineering Management Board (EMB) shall charter a Software Working Group (SWG) to advise the Agency on software-related matters and recommend software management, engineering, and assurance policies, standards, best practices, and guidance. c. The AA-SMA shall assure the safety, quality, and reliability of NASA software; review project software processes and make recommendations to the governing Program Management Council (PMC); conduct oversight of NASA's software assurance programs; and conduct Process Verification Reviews of programs/projects to ensure compliance with this Directive and independently assess project software management, engineering, and assurance practices. The AA-SMA shall appoint and support representatives to the SWG. d. The Associate Administrator for Safety and Mission Assurance shall, through its Functional Office role, sponsor the NASA Software IV&V Facility in West Virginia under the management and oversight of the Goddard Space Flight Center. This facility shall support NASA's program for improving software assurance, including conducting IV&V and other trusted verifications. e. Enterprise Associate Administrators and Center Directors shall appoint and support representatives to the SWG. f. The governing PMC shall review program and project software processes and products including, but not limited to evidence of conformance to this policy; use of IV&V and other trusted verifications (e.g., independent assessments and peer reviews); and other risk mitigation processes as appropriate based on program/project cost, size, complexity, life span, risk, and consequences of failure. 7. MEASUREMENTS a. The following shall be evaluated for compliance with this Directive: (1) Evidence of project conformance to this policy. (2) Agency trends on the following: (a) Software cost and schedule baseline deviations; and (b) Degree to which delivered software satisfies its requirements, including safety, quality, and reliability measures. (3) Results of the following: (a) Assessments and audits of conformance to CMM in NASA software creation and acquisition organizations; (b) Other surveys relating to the implementation of this Directive; (c) Improvements resulting from the use of the CMM; (d) Improvements resulting from case studies and shared experiences. b. Specific responsibilities for collecting, analyzing, and reporting metrics are to be contained in NPR 2820. 6. DELEGATION OF AUTHORITY None. /s/ Sean O'Keefe Administrator 3 of 5 6/9/2004 11:12 AM

ATTACHMENT A: (TEXT) ATTACHMENT 1APPLICABLE REFERENCES These references apply to the management, engineering, and assurance of NASA software. (1) NPD 1280.1, NASA Management Systems (2) NPD 2091.1, Inventions Made by Government Employees. (3) NPD 2210.1, External Release of NASA Software. (4) NPD 2800.1, Managing Information Technology. (5) NPD 2810.1, Security of Information Technology. (6) NPD 7120.4, Program/Project Management. (7) NPD 8700.1, NASA Policy for Safety and Mission Success. (8) NPR 2210.1, External Release of NASA Software. (9) NPR 2800.1, Managing Information Technology. (10) NPR 2810.1, Security of Information Technology. (11) NPR 7120.5, NASA Program and Project Management Processes and Requirements. (12) NPD 8730.4, Software Independent Verification and Validation (IV&V) Policy. (13) NASA-STD-8719.13, NASA Software Safety Technical Standard. (14) NASA-STD-2202-93, NASA Software Formal Inspection Process Standard. (15) ISO 9000-3, Quality Management and Quality Assurance - Part 3 Guidelines for the Application of ISO 9001: 1994 to the Design, Development, Supply, Installation, and Maintenance of Computer Software. (16) Carnegie Mellon University/Software Engineering Institute, Continuous Risk Management Guidebook, 1996. (17) OMB Circular No. A-119, Federal Participation in the Development and Use of Voluntary Standards. ATTACHMENT 2 RELEVANT REFERENCES These are relevant to the management, engineering, and assurance of NASA software. (1) CMU/SEI - 93 - TR - 24, The Capability Maturity Model for Software, Version 1.1, February 1993. (2) CMU/SEI - 93 - TR - 25, Key Practices of the Capability Maturity Model, Version 1.1, February 1993. (3) CMU/SEI-2002-TR-010, The Software Acquisition Capability Maturity Model (SA-CMM), Version 1.03, March 2002. (4) CMU/SEI - 2002 - TR - 011, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Version 1.1, Continuous Representation, March 2002. (5) CMU/SEI-2002-TR-012 - CMMISM for Systems Engineering/Software Engineering/Integrated Product and Process Develoment/Supplier Sourcing, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD/SS, V1.1, Staged) March 2002. (6) RTCA/DO-178B - 1992 - Software Considerations in Airborne Systems and Equipment Certification, 3/26/1999. 4 of 5 6/9/2004 11:12 AM

(7) ISO 9001, ANSI/ASQC Q9001-1994, Quality Systems - Model for Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation, and Servicing. (8) IEEE/EIA 12207.0-1996 Industry Implementation of International Standard ISO/IEC 12207: 1995 Standard for Information Technology Software -- Life Cycle Processes. (9) IEEE/EIA 12207.1-1997 Industry Implementation of International Standard ISO/IEC 12207: 1995 Standard for Information Technology Software -- Software Life Cycle Processes - Life Cycle Data. (10) IEEE/EIA 12207.2-1997 Industry Implementation of International Standard ISO/IEC 12207: 1995 Software Life Cycle Processes - Implementation Considerations. (11) IEEE 1012-1998 Standard for Software Verification and Validation. (12) NASA-GB-A201-89, NASA Software Assurance Guidebook, Sept 1989. (13) NASA-GB-1740.13-96, NASA Guidebook for Safety Critical Software - Analysis and Development. (14) NASA-GB-001-94 Software Engineering Program- Software Measurement Guidebook, August 1995. (15) NASA-GB-001-96 Software Engineering Program- Software Management Guidebook, November 1996. (16) NASA/TP-98-208193, Formal Methods Specification and Verification Guidebook for Software and Computer Systems, Volume I: Planning and Technology Insertion, December, 1998. (17) NASA-GB-001-97 NASA Formal Methods Specification and Analysis Guidebook for the Verification of Software and Computer Systems, Volume II: A Practitioner's Companion, May 1997. (18) ISO 9001-2000, ANSI/ISO/ASQ Q9001-2000, American National Standard - Quality management systems-requirements. (URL for Graphic) None. DISTRIBUTION: NODIS This Document Is Uncontrolled When Printed. Check the NASA Online Directives Information System (NODIS) Library to Verify that this is the correct version before use: http://nodis3.gsfc.nasa.gov 5 of 5 6/9/2004 11:12 AM