NPD 2820.1A, NASA SOFTWARE POLICIES (REVALIDATED 29 MAY 2004)

NPD 2820.1A, NASA SOFTWARE POLICIES (REVALIDATED 29 MAY 2004)., 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