LMS 7150 Software Engineering Procedural Requirements - Focusing on the LPR and Class C - Presented By: Pat Schuler [email protected] Head, Software

LMS 7150 Software Engineering Procedural Requirements

- Focusing on the LPR and Class C -

Presented By: Pat Schuler

[email protected] Head, Software Engineering Process Group

Phone 757-864-6732

LMS Rollout_LPR_CP_Class C_R0V1 short.ppt1

mailto:[email protected]

Getting the Most Out of This Training

• Primary objective of this course is to train participants on how to perform the procedure as efficiently and easily as possible

• Ask questions if the course doesn’t address areas of confusion• Answer questions posed by the instructors

– This course is intended to be very interactive– The more you ask questions the more you will learn

• You are not expected to be an expert in the LMS 7150 procedures at the close of this training– If you have questions as you apply these procedures to your

own projects/task, ask the Software Engineering Process Group (SEPG) representative from your Directorate for help!

2

Why New LMS 7150 Software Procedures Requirements• These new LMS software procedures adapt, clarify, and flow down new

software requirements from NASA Headquarters (i.e., from NPR 7150.2A, NASA Software Engineering Requirements & Standards from Headquarters Office of Safety and Mission Assurance (OSMA)).

• The new software requirements are intended to support NASA activities, projects, and programs in meeting their goals (e.g., mission success, safety, schedule, and budget) by specifying a systematic, disciplined approach to software.

• Flows down NASA, DOD, and industry Best Practices

• HQ requirements significantly raised the number and level of rigor over the previous LMS software requirement

• Center-wide training should help us come into compliance with the new Headquarters procedure requirements

Good News: The Number of Requirements and Level of Rigor is Determined by Software Classes

• Class A: Human Rated Space Software Systems• Class B: Non-Human Rated Space Software Systems or Large Scale

Aeronautics Vehicles• Class C: Mission Support Software or Aeronautic Vehicles, or

Major Engineering/Research Facility Software• Class D: Basic Science/Engineering Design and Research and

Technology Software• Class E: Small Light Weight Design Concept and Research and

Technology Software

• Definitions in LPR 7150, LaRC Software Engineering Requirements, Appendix D including examples

4

Examples of Software Class

5

Class A Software•Human Rated SoftwareClass A Software•Human Rated Software

Class B Software•Primary Instrument Spacecraft Flight SW•Ground SW That Controls The Spacecraft

Class B Software•Primary Instrument Spacecraft Flight SW•Ground SW That Controls The Spacecraft

Class C Software•Non-primary Instrument Flight SW•Large Scale Facilities Operations/Control•Ground Support Equipment that interfaces to flight hardware

Class C Software•Non-primary Instrument Flight SW•Large Scale Facilities Operations/Control•Ground Support Equipment that interfaces to flight hardware

Safety, Reliability, Complexity Safety, Reliability, Complexity

Other Examples of Software Projects by Class

• Class A: Orion, Space Station…• Class B: ARES I-X, SAGE III on ISS, CLARREO, CALIPSO, …• Class C: IRVE-3, CERES FM-5, National Transonic Facility wind

tunnel software and the Data Acquisition software, Cockpit Motion Facility, Distributed Active Archive Centers …

• Class D: Advanced Radar Project, Ground Secondary Science Processing …

• Class E: Harmonic Balance Codes Project, Research software to explore a design concept or hypothesis …

6

Examples of LaRC Software Applications• algorithm development• control law development• data acquisition / reduction• tool development• technology development• developing models or simulations (or modifying existing

ones for new uses/applications/geometries, etc.)• multidisciplinary analysis and optimization• analysis of real world or simulated data• computational analysis (e.g., aerodynamics, flow field

analysis, trajectory analysis, structural analysis)• computer-human interfaces• avionics systems• evaluation of safety-critical systems• software to control or gain data from mechanical

elements (e.g., sensors and thrusters)• aero-thermodynamics computational codes• flight software for science instruments

7

Note: The new LMS requirements comer all

these software applications

Software Requirement Flowdown

LMS-CP-4754SW Assurance

for Development and Acquisition

LMS-CP-7150.3Class A, B, and

All Safety Critical Software

LMS-CP-7150.4Class C Software

LMS-CP-7150.5Class D Software

LMS-CP-7150.6Class E Software

NPR 7150.2A

NASA SW Engineering

Requirements

NASA-STD-8739.8

SW Assurance Standard

NASA-STD-8719.13

NASA SW Safety

Standard

NPR 8715.3

NASA General Safety

Program Requirements

LPR-7150.2

SW Engineering

Requirements

8

HQ NPR Based Heavily on Capability Maturity Model Integrated (CMMI) Level 2 & ISO/IEC 12207 Standard for Information Technology - Software Life Cycle

ProcessesCMMI•Project Planning: Establish and maintain plans that define project activities•Project Monitoring : To provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan•Requirements Management: Manage the requirements of the project's products and identify inconsistencies between those requirements and the project's plans and work products•Contract Management: To manage the acquisition of products from suppliers•Configuration Management: To establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits•Measurement and Analysis: To develop and sustain a measurement capability that is used to support management information needs•Process and Product Quality Assurance: To provide staff and management with

objective insight into processes and associated work products CornerstoneISO/IEC 12207 & J-STD-016 was used as the basis of the required content in the Software Documentation and Work Product – this was heavily used for guidance in LMS

9

Develop

Software Requirements

Requirements

Requirements Management & Traceability

Design Implementation Testing

Configuration Management

Risk Management

Peer Reviews/Inspections

Measurement

Quality Assurance

Training

Assurance

Monitor, Track, & Control

Verification & Validation

Plans, Estimates, & Schedules Lifecycle & Stakeholder Reviews

Safety

Formulate, Classification & Acquisition Req.

OperationsMaintenanceRetirement

Policies/Laws: Disclosure, Technology Transfer, External Release, Security, Disabilities

SupportingRequirements

Plan

Start Up

Monitor

10

The Value & General Breakdown of Center Procedures

– Software Management Requirements• Planning, organizing, technical direction, communication, and control of tasks• Let’s test the new rocket engine (shopping center demolished)• Mountain climbers (following the plan may make the difference between life and

death)

– Software Engineering Process Requirements• A systematic series of actions directed to some end• Lack of Configuration process (led to flying the wrong version of the Flight software and the instrument completely failed to operate)• Lack of Configuration process (people leave, where is their software products)• Inadequate testing process (due to software failure – instrument ran only seconds)

– Software Documentation and Work Product Requirements• Provides the details on the required content of document and work products• Lack of Requirements (Contracted software - what was delivered worked, it just took a

day instead of a minute to perform a run, software ended up not being used)• Lack of Interface Requirements (Reverse of least significant bit, almost led to mission

failure, found out by mistake)• Lack of Requirements - Pilot put the wheels up (Oops!) 11

Plan what you do,Do what you plan

LPR 7150 Provides a Single Entry Point to the Software LMS Procedures

12

LPR/CP–Document Breakdown • LPR 7150

– 29 pages total– 6 pages are just required LPR preface material front matter– Only 5 pages are the real technical requirements for software tasks (with

associated guidance)– 17 pages are the appendices which contain definitions, acronyms, references,

associated [laws, policies, requirements,] and table of designated Technical Authority (TA)

• LMS Procedure for Class C– 49 pages total– Procedure with flow diagram is only 8 pages; the bulk of the CP (32 pages) covers

the required content of the lifecycle documents (with guidance included from various IEEE standards source documents) e.g. Software Management Plan, Software Configuration Management Plan, Software Requirements Specification

• LMS Procedure for Class D– 21 pages total– Procedure with flow diagram is only 5 ½ pages; the bulk of the CP (9 pages) covers

the required content of the lifecycle documents (with guidance included from various IEEE standards source documents)

• LMS Procedure for Class E– 6 pages total– Procedure with flow diagram is only 3 pages; with only 1 page that covers the

required content of the Software Management Plan(with guidance included from various IEEE standards source documents) 13

14

A1. Software Management Plan

Flow DiagramFlow Diagram

Required Class D DocumentsRequired Class D Documents

Software Requirements SpecificationSoftware Design

DescriptionSoftware Version

Description

Software Management Plan

Software Test Plan

Software Config. Management Plan

STEP ACTION TO TAKE

1 Assess options for software development vs. acquisition a. Perform …[SWE-050]

b. Assess…

2 Acquisition preparation a. Develop … [SWE-050] [SWE-049]

b. Follow …

c. Require …. [LaRC Office of Chief Counsel]

d. Document … [SWE-038][SWE-039]

Compliance Matrix

- Class D -- Class D -

LMS-CP-4754

SACR

SW Class

LPR 7150

Lets Dive In

• Look at the Software Class C Definitions in Appendix D of the LPR 7150 – Which Class applies to work you have done and why– Try to come up with one example software activity

and tell us its Class• And also tell what Directorate did it come under

• Next, lets look at other key elements of LPR 7150

15

Facility software

• What IS a Major Engineering/Research Facility?

• What is NOT a Major Engineering/Research Facility?

• Look at Preliminary LAPD: Facility Software Policy handout– If you have input based on your own facilities that

are not listed, contact Chuck Niles to discuss it.

16

Grandfather ClauseThe following is a quote from LPR 7150.2 Langley Software Engineering Requirements, Section: P.2.d.6, Release date May 14, 2013•If a project predates the LPR release, from the LPR release date forward, the project will follow the LPR requirements for the current and all future project activities •(i.e., if the project started before the LPR was approved and it does not make sense to go back and fulfill requirements from completed phases, then the project complies with the LMS requirements for the present and remaining project phases). •This will be documented in the project’s Compliance Matrix.

17

Grandfather Clause LPR 7150.2 Exclusion P.2.d.6

Examples using Class C

18

# If the project is Then

1 Early in the requirements phase,

The project should comply with all the LPR and associated LMS Center Procedure requirements

2 Just completing the requirements phase,

The project should fulfill the LMS procedure’s required verification and validation activities on the requirements document,

-and all the rest of the LMS procedure requirements for the remaining phases,

-including producing the following documents: Software Management Plan, Software Configuration Management Plan, Software Requirements Specification (partially comply), Software Design Description, etc.

3 Early or midway into the design phase,

The project should fulfill all the LMS procedure’s requirements that pertain to the design phase

-and all the remaining phases,

-including producing the following documents: Software Management Plan, Software Configuration Management Plan, Software Requirements Specification (partially comply), Software Design Description, etc.

Grandfather Clause -LPR 7150.2 Exclusion P.2.d.6Examples using Class C

19

# If the project is Then4 At the end of the

design phase,The project should fulfill all the LMS procedure’s required verification and validation activities on the design document, -and all the rest of the LMS procedure requirements for the remaining phases,

-including producing the following documents: Software Management Plan, Software Configuration Management Plan, Software Requirements Specification (partially comply), Software Design Description (partially comply), Software Test Plan, etc.

5 Completed the software product (i.e. heritage/legacy code)

If you modify the code the full LMS procedure requirements are fulfilledIf asked to release the code then you complete the products for the release phase: -perform Section 1.2 and 1.3 of LPR 7150.2; (Classification & CP determined)

-walk through the LMS-CP and document in the Compliance Matrix what activities from the LMS-CP you did fulfill and which ones you did not;

-complete a simplified Software Management Plan filling out the sections with what you did;

-(depending on your class) put the products under version or configuration control, and produce Software Version Description;

Follow SMS SW Release procedural requirements

-and deliver the completed software product(s) and/or data to the requestor with appropriate documentation.

Software Classification and Safety CriticalityLPR 7150.2 Section 1.2 – 1.3

• Class A: Human Rated Space Software Systems• Class B: Non-Human Rated Space Software Systems or Large Scale Aeronautics Vehicles• Class C: Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research

Facility Software• Class D: Basic Science/Engineering Design and Research and Technology Software• Class E: Small Light Weight Design Concept and Research and Technology Software

***Note: Text in black is required; software activities shall fully comply with statements in black text

***Note: Text in gray is contextual information that provides further description or examples that help clarify the requirement

***You must email a description of what the SW is supposed to do (i.e., its purpose or functions)& its intended use to - Mission AssuranceBranch, Leslie Johnson

20

21

Multi-Party Software ActivitiesLPR 7150.2 Section 1.4

• Document who is going to do what requirements

22

Tailoring and WaiversSee LPR 7150.2 Section 2.3 &

Appendix F

Appendix A. DEFINITIONS & Appendix B. ACRONYMS

Note: These Appendices are used by ALL Classes

Lets Look at Class C & Some Examples• We will look at the front matter of the Class C procedure• Next we will walk through the procedure looking at the

guidance on how to fulfill the requirement.• Next we will look at a real Class D project example from

the web site at:• https://sites-e.larc.nasa.gov/sweng/home_pg/

– All project names have been changed to keep it anonymous

• Look at Software Inventory required data & a Software Assurance Classification Report

23

https://sites-e.larc.nasa.gov/sweng/home_pg/

24

25

26

Lets Look at Class C & Some Examples• We will look at the front matter of the Class C procedure• Next we will walk through the procedure looking at the

guidance on how to fulfill the requirement.• Next we will look at a real Class D project example from

the web site at:• https://sites-e.larc.nasa.gov/sweng/home_pg/

– All project names have been changed to keep it anonymous

• Look at Software Inventory required data & a Software Assurance Classification Report

27


28

Walk through in detail the Software Process Improvement Initiative (SPII) web site

• There is a wealth of information on the web site all aimed at making your work easier

• https://sites-e.larc.nasa.gov/sweng/home_pg/ – Home page – SWE & LMS Supporting Products

• Peer Review Toolkit

– Other parts of the site

29


Steps to help minimize/stream workload associated with new requirements

• To avoid over specification, the LMS does not specify how the requirements are met– That is up to the organization & project

– The LMS just says what the requirements are

• The following slides give examples on how to help small and large software tasks reduce the level of effort to fulfill the new LMS requirements.• These describe some real examples of how

software LMS procedures have been streamlined to date


• Branch-level (for example) Configuration Management Plan can be put in place and followed by each new task with all the products stored on a central server in a folder with the name of the corresponding task.

• Use tables to easily collect required information & cross reference them from other plans/documents


• The branch can designate one person to help each software manager develop their project’s Software Management Plans. – The SEPG tutors the designee on their first plan. – The designee in turn went through the plan jointly with each

software manager in the branch to help them make whatever project specific adjustments were needed for their own project. Then they followed the adjusted plan.

• There is one directorate experimenting with a partly pre-filled-in wiki to improve efficiency in implementing the LMS requirements for small software projects.


• Frequently there are numerous codes in an organization that are complete except for performing maintenance on them– They can be addressed by a single Branch-level Software

Management Plan or Facility Software Management Plan that covers routine maintenance tasks (e.g., correct faults, improve performance, or other attributes )

• On the other hand, many times these tasks are part of a larger project that have already defined some of the things required by the LMS software procedures (e.g., the schedule and resources). – There is no need to duplicate their work if it complies with the LMS

software requirements.

Other Related Software Procedures and Forms

34

LMS-OP-4509, Presolicitation Documents and Solicitation Development/Release

G.4. NF1707 Section 8 - Software Engineering •If it is determined that the procurement involves software within the scope of LPR 7150.2, LaRC Software Engineering Requirements,

– the procurement should be coordinated with “LaRC’s Software Engineering Process Group (SEPG) representative for contracts” in the Center Operations Directorate for review to ensure applicable requirements are identified. (See https://

sites-e.larc.nasa.gov/sweng/home_pg/ for the SEPG representative for contracts name.)

– For human-rated software systems (Class A) and non-human space rated software systems (Class B), the Capability Maturity Model Integration (CMMI) clauses also apply.

– The SEPG rep can be especially helpful for your first contract using the new LMS 7150 procedures

35

https://lms.larc.nasa.gov/search.cfm?cont=yes&keywords=&num=7150.2&class=&search=Search





NASA FORM 1707, Section 8 Updates

36

• THIS PROCUREMENT IS NOT SUBJECT TO SOFTWARE ENGINEERING REQUIREMENTS AS SPECIFIED IN LPR 7150.2 LaRC Software Engineering Requirements SEE: https://lms.larc.nasa.gov/index.cfm

OR• THIS PROCUREMENT IS SUBJECT TO SOFTWARE ENGINEERING

REQUIREMENTS AS SPECIFIED IN LPR 7150.2 LaRC Software Engineering Requirements

• LaRC SOFTWARE ENGINEERING PROCESS GROUP (SEPG) REPRESENTATIVE (Insert the name of ‘LaRC’s SEPG representative for contracts’. See https://sites-e.larc.nasa.gov/sweng/home_pg/) HAS BEEN MADE AWARE OF THIS PROCUREMENT AND THE PROGRAM/PROJECT/ACTIVITY FOR WHICH IT WILL BE UTILIZED.

https://lms.larc.nasa.gov/index.cfm

NASA FORM 1707, Section 8 Updates

37

SOFTWARE CLASS (check appropriate class as specified in the Software Assurance Classification Report; see LMS LMS-CP-4754, Software Assurance (SA) for Development and Acquisition)Class A: Human Rated Space Software SystemsClass B: Non-Human Rated Space Software Systems or Large Scale Aeronautics VehiclesClass C: Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility SoftwareClass D: Basic Science/Engineering Design and Research and Technology SoftwareClass E: Small Light Weight Design Concept and Research and Technology Software*Definitions in LPR 7150, Appendix D include examples and exclusions

NASA FORM 1707, Instructions

38

• B. DETAILED INSTRUCTIONS• Section 8. Software Engineering• The requestor must indicate if the procurement is subject to

the software engineering requirements specified in LPR 7150.2 LaRC Software Engineering Requirements.

• If it is, then the requestor must identify and coordinate with the ‘LaRC’s SEPG representative for contracts’ whose name is identified at https://sites-e.larc.nasa.gov/sweng/home_pg/.

Langley Repeat Audit Findings• The 2009 IPS/OCE Joint Assessment / Audit Had Finding on:

– “The local LaRC LMS software requirements (LMS-CP-5528) are out of date and do not fully comply with NPR 7150.2”

– Other software findings (e.g., “A significant number of other projects at LaRC are also lacking Software Assurance Classification reports, ” and “Technical Authorities, …not fully aware of their responsibilities with regard to… NPR 7150.2” )

• The 2011 OCE Assessment / Audit had repeat findings on the same area of LMS software procedures not complying with NPR 7150.2 and also others new findings (e.g. software release procedures)

• Systemic Corrective Action Plans for Software Findings included:– Bring LaRC LMS software procedures into compliance with defined NASA

Procedural Requirements (NPRs) and Standards (Assurance and Safety)– All software LMS procedures fall under one LPR 7150.2 LaRC Software

Engineering Requirements and associated LMS-CPs– The Software Engineering Process Group (SEPG) provides Center-wide rollout

training and mentoring• Only projects in compliance with LMS procedures can apply for the ‘Software on

The Year Award’39

How to Show Evidence of Compliance• Many of you may already be in compliance by your current activities• It is not enough to be in compliance

– You have to show you are in compliance

• Be sure to identify the “auditable” artifacts/work products that are produced by your plans to show compliance

• Provide access to the CM system, server directories/folders, or repository that houses your development artifacts/work products

• As artifacts are completed, and placed under CM, (or version control for Class E) add the associated identifier to the compliance matrix (or task list for Class E Branch Level Software Management Plans)

40

Make sure you have evidence

Each LMS-CP-7150 Requires the Following of Line Managers

• Line Manager reviews and approves the Compliance Matrix and the Software Management Plan to ensure

• they are in compliance with this procedure, • to approve the allocation of the Line Manager’s

staff and resources, • to approve any tailoring requests in the Compliance

Matrix.

Software ClassesA. Human Rated Space Software SystemsB. Non-Human Space Rated Software Systems or Large

Scale Aeronautics VehiclesC. Mission Support Software or Aeronautic Vehicles, or

Major Engineering/Research Facility SoftwareD. Basic Science/Engineering Design and Research and

Technology SoftwareE. Small Light Weight Design Concept and Research and

Technology Software

F. General Purpose Computing Software (Multi-Center or Multi-Program/Project)

G. General Purpose Computing Software (Single Center or Project)

H. General Purpose Desktop Software

42

Engineering-Related Software-- Mission-- Science

-- Research

Engineering-Related Software-- Mission-- Science

-- Research

Business and IT Software-- Center Applications-- Business Software

-- Desktop Applications

Business and IT Software-- Center Applications-- Business Software

-- Desktop Applications

Workshop 1

43

44

A1. Software Management Plan

Flow DiagramFlow Diagram

Required Class D DocumentsRequired Class D Documents

Software Requirements SpecificationSoftware Design

DescriptionSoftware Version

Description

Software Management Plan

Software Test Plan

Software Config. Management Plan

STEP ACTION TO TAKE

1 Assess options for software development vs. acquisition a. Perform …[SWE-050]

b. Assess…

2 Acquisition preparation a. Develop … [SWE-050] [SWE-049]

b. Follow …

c. Require …. [LaRC Office of Chief Counsel]

d. Document … [SWE-038][SWE-039]

Compliance Matrix

- Class D – Any questions?- Class D – Any questions?

LMS-CP-4754

SACR

SW Class

LPR 7150

Q&A

Q & A• Q: Who is my Technical Authority• A: Technical Authority (i.e., the software

manager’s Directorate Head).***

46

Final Thoughts• LPR 7150.2 and the supporting procedures are mostly

comprised of things we are already doing or things that make good sense to do

• I recommend you utilize the examples on the SPII web site• The Software Engineering Process Group (SEPG) members are

available to assist you in– Navigating the requirement (and the SPII web page), and – To help you avoid the risk of overcomplicating your efforts

to comply• Remember each Directorate has a member on the SEPG that

is there to help you!

47

Final Thoughts

• Please email additional question/feedback to:– larc-dl-support-sepg-help

• OR– Contact your Directorate SEPG representative

• In COD that is Chuck Niles (46979)

• OR– Call the LMS Software Procedure Helpdesk phone

number: 864-839948

Lastly

• Please fill out your evaluation Forms

• Please make sure you fill out the SIGN IN SHEET

49

Backup

50

Software Engineering Process GroupDirectorate Representatives

51

Representative Phone Organization Represented

Michael Madden (Co-Chair)

48399 D1/Research Services Directorate

Chuck Niles 46979 D4/Center Operations Directorate

Kevin Earl 41913 E4/Systems Analysis and Concepts DirectorateLeslie Johnson 49409 C2/Safety and Mission Assurance Office

Bill Wood (Research)

48355 D3/Research Directorate

Paul Morris (ROME) (Facilities)

224-7826

D3/Research Directorate

Kevin Kempton

41797 D2/Engineering Directorate

Jonathan Gleason 44190 E3/Science Directorate

Clay Eckles 42441 B7/Office of Chief Information Officer

Twelve Essential Attributes of Successful Software Projects

"What was surprising was that all of the successful projects tend to follow a similar pattern even though they were created by different companies, in different countries, and within different sub-industries, and had different business and technical purposes for creation... The pattern is this: there are myriad ways to fail when building large software systems. There are only a very few ways to succeed. All of the paths that lead to successful software have these twelve essential attributes: “

Patterns of Software Systems Failure and Success, Capers Jones, International Thomson Computer Press, Boston, MA, 199652

• effective project planningeffective project planning• effective project cost effective project cost estimatingestimating • effective project measurementseffective project measurements• effective project quality controleffective project quality control• effective development processeseffective development processes• capable technical personnelcapable technical personnel• capable project managerscapable project managers

• effective project costeffective project cost• effective project milestone trackingeffective project milestone tracking• effective project change managementeffective project change management• effective communicationseffective communications

Form 7: NASA Software Release Request Authorization

• This form is completed for each software item that has not previously gone through the release process

• This form must be completed before you release the code to anyone other then a LaRC civil servant or a fellow project civil servant

• You cannot release to another Center’s civil servant, one of your contractors, a university, a company, etc. without completing this Form 7; it is illegal to do a release with out this form completed

• For heritage codes completed prior to May 14, 2013, you should follow the Checklist in the following example to help you complete the form & required products

53

Software Release Requirements

Presented by

Stuart Pendleton

LaRC Software Release Authority

Background

• Releases are governed by NPD 2210.1C Release of NASA Software

• Each Center has one Software Release Authority (SRA) that is responsible to the policy

• All releases of non-classified software are subject to the requirements except:– Transfers on originating Center between Civil

Servants only– Transfers by developing project office to Civil

Servants in the same project (not program) regardless of Center

Excerpts from NPR 2210.1C

Preface•P.1. PurposeThis NASA Procedural Requirements (NPR) establishes procedures and responsibilities for the reporting, review, assessment, and release of software created by or for NASA. These procedures ensure that NASA software is reported and released according to law and NASA policies, with appropriate restrictions on the use and redistribution of the software. The unrestricted release of NASA software, as defined in Appendix A at paragraph A.2.7, is prohibited.

Excerpts from NPR 2210.1C

• A.1.11 “Software” is defined in NPD 7120.4. In

accordance with NPD 7120.4, Software as used in this NPR for purpose of the reporting, review, and assessment requirements of this NPR includes computer programs in both source and object code but does not include computer databases, software documentation, or technical papers unless they disclose source code. Applicable software documentation may be released with the software.

“Software” as defined in NPD 7120.4

• A.16 SoftwareComputer programs, procedures, rules, and associated

documentation and data pertaining to the development and operation of a computer system. Software also includes COTS, GOTS, MOTS, embedded software, reuse, heritage, legacy, auto generated code, firmware, and open source software components.

Note 1: Only for purposes of the NASA Software Release program, the term "software," as re-defined in NPR 2210.1 does not include computer databases or software documentation.

Note 2: Definitions for the terms COTS, GOTS, heritage software, MOTS, legacy software, software reuse, and classes of software are provided in NPR 7150.2.

Process is Evolving• NPR 2210.1C was recently implemented at LaRC and there are

changes to our process

• These changes are tied to processes not owned by the Software Release Authority (SRA)

– The SRA must have evidence of compliance with the other processes prior to release authorization

• Requirements were prescribed by various HQ Offices• These cannot be waived or relaxed by the SRA• NPR specifies that the originating organization is responsible for providing the

required information to the SRA

– LaRC has chosen to implement via a new form• Langley Form 7, Software Release Request Authorization• This simplifies the data gathering process, and specifies the requirements for

release that are captured from the NPR

– Meet Section 508 Requirements– Review for Personally Identifiable Information– Review for Sensitive But Unclassified Information– Meet the Safety Assurance Standards– Meet the Software Engineering Requirements– Meet the IT Security Requirements– Meet the Export Control Requirements– Meet programmatic restrictions– Determine Intellectual Property rights– List of all files to be released (including documents and data such as

models or examples)

This information must be collected by the requesting organization and its validity must be certified by the organizational management as well as the POC for the software.

What is required for a review?

How much of this is new?

• Section 508 requirements are a federal law, but until recently, no Agency policy existed

• PII and SBU requirements existed, but were not called out in NPR 2210

• Safety assurance and engineering requirements were not called out

• IT Security requirements were expanded• Requirement to list all components of a

transfer were not levied

64

Summary

• All releases (with few exceptions) are covered by the NPR

• All versions must be handled separately in the process• The request to release software cannot be processed

until the required information is provided through the LF7

• LF7 submission must include the software compliance matrix for the appropriate class of software and a safety assurance assessment as well as any waivers or deviations that were approved

• Management must validate the LF7