LMS 7150 Software Engineering Procedural Requirements - Focusing on the LPR and Class E -

1. LMS 7150 Software Engineering Procedural Requirements- Focusing on the LPR and Class E - Presented By: Pat Schuler M.Pat.Schuler@NASA.gov Head, Software Engineering Process Group Phone 757-864-6732 RD_SW_LPR_CP_Aug29_Vx.ppt

2. Getting the Most Out of This Training • 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!

3. Software Engineering Process GroupDirectorate Representatives

4. 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 raise 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 • Primary objective of this course is to train participants on how to perform the procedure as efficiently and easily as possible

5. 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

6. Software Requirement Flowdown NPR 8715.3 NASA General Safety Program Requirements NPR 7150.2A NASA SW Engineering Requirements LMS-CP-4754 SW Assurance for Development and Acquisition LMS-CP-TBD Class A, B, or Safety Critical SW Development NASA-STD-8739.8 SW Assurance Standard NASA-STD-8719.13 NASA SW Safety Standard LMS-CP-TBD Class C SW Development LPR-7150.2A SW Engineering Requirements LMS-CP-TBD Class D SW Development LMS-CP-TBD Class E SW Development

7. 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 • 6pages 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)

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

9. - Class E - Flow Diagram LPR 7150 A1. Software Management Plan LMS-CP-4754 Required Class E Documents SACR Compliance Matrix Software Management Plan Software Requirements SW Class

10. - Class D - LPR 7150 Flow Diagram A1. Software Management Plan Required Class D Documents Software Management Plan Compliance Matrix Software Config. Management Plan SACR Software Test Plan LMS-CP-4754 Software Requirements Specification Software Design Description Software Version Description SW Class

11. 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 …

12. Examples of LaRC Software Applications Note: The new LMS requirements comer all these 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

13. Lets Dive In • Look at the Software Class 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

14. Grandfather ClauseLPR 7150.2 Exclusion P.2.d.6 Examples using Class A and Class B

15. Grandfather Clause -LPR 7150.2 Exclusion P.2.d.6 Examples using Class A and Class B (Continued)

16. 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 Assurance Branch, Leslie Johnson

18. Multi-Party Software ActivitiesLPR 7150.2 Section 1.4 • Document who is going to do what requirements Tailoring and Waivers See LPR 7150.2 Section 2.3 & Appendix F Appendix A. DEFINITIONS & Appendix B. ACRONYMS Note: These Appendices are used by ALL Classes

19. Lets Look at Class E & Some Examples • We will look at the front matter of the Class E procedure • Next we will walk through the procedure side by side with a real Class E 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 • Then Walk through Branch-Level Class E Software Management Plan

23. Lets Look at Class D & Some Examples • We will look at the front matter of the Class D procedure • Next we will walk through the procedure side by side with 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 • Then Walk through Branch-Level Class E Software Management Plan

25. 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

26. 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

27. Steps to help minimize/stream workload associated with new requirements • If the branch routinely has Class E tasks • Then a Class E Branch-level Software Management Plan can be used to define a standard way of doing things with one line in a table of the plan to record task specific information. • Similarly a 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

28. Steps to help minimize/stream workload associated with new requirements • 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.

29. Steps to help minimize/stream workload associated with new requirements • 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 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.

30. Other Related Software Procedures and Forms

31. 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

32. NASA FORM 1707, Section 8 Updates • THIS PROCUREMENT IS NOT SUBJECT TO SOFTWARE ENGINEERING REQUIREMENTS AS SPECIFIED IN LPR 7150.2 LaRC Software Engineering RequirementsSEE: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 ENGINEERINGPROCESS 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 MADEAWARE OF THISPROCUREMENT AND THE PROGRAM/PROJECT/ACTIVITY FOR WHICH IT WILL BE UTILIZED.

33. NASA FORM 1707, Section 8 Updates 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 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, Appendix D include examples and exclusions

34. NASA FORM 1707, Instructions • 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/.

35. Heritage Software The 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. • In the case of completed Heritage Software, the next phase is release.

36. 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

38. 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 findingson 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” work products that are produced by your plans to show compliance • Provide access to the version control system, server directories/folders, or repository that houses your development work products • As artifacts are completed, and placed under version control add the associated identifier to the compliance matrix (or task list for Class E Branch Level Software Management Plans) Make sure you have evidence

40. 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.

41. Software Classes • Human Rated Space Software Systems • Non-Human Space Rated Software Systems or Large Scale Aeronautics Vehicles • Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility Software • Basic Science/Engineering Design and Research and Technology Software • Small Light Weight Design Concept and Research and Technology Software • General Purpose Computing Software (Multi-Center or Multi-Program/Project) • General Purpose Computing Software (Single Center or Project) • General Purpose Desktop Software Engineering-Related Software -- Mission -- Science -- Research Business and IT Software -- Center Applications -- Business Software -- Desktop Applications

43. 3 1 2 4

44. Q&A

45. Q & A • Q: Who is my Technical Authority • A: Technical Authority (i.e., the software manager’s Directorate Head).***

46. Q & A • Q: The software I development is Class E code to explore hypothesis, but not used to make decisions for an operational Class A, B, or C system. Do I need a separate plan for every related code I write? (E.g., models, simulation codes, plotting routines, data formatter or converter.) • A: No, see the following examples on the web site on how to put in place a streamlined plan to cover all the separate codes collectively: • - “Class E Example 1 - Branch Level Class E SMP” (covers all the Class E software for the whole Branch under one plan) • - “Class E Example 2 – Completed Documents from a Real Project” ” (covers all the Class E software used/developed/ modified by a single person under one plan)

47. Q & A on Branch-Level SMP • Q: On the Compliance Matrix (Appendix A), of the Branch Class E SMP, am I correct that this matrix as written would cover all class E software used in the branch and we don't need a separate table for each project?   • A: Yes you are correct – that is the beauty of this approach. Instead on one plan and compliance matrix for each project (like the other Software Classes will have to do), there is just one Compliance Matrix in the whole branch for  Class E Software Management Plan. That is why it is signed by all Class E Project/Task Leads – that way it covers all Class E software projects in the branch since they all signed.

48. Q & A on Branch-Level SMP • Q: What if sometime down the road an individual task would include software with required tailoring?  Not sure how that would be documented on the matrix. • Good question. The project would make a copy of Appendix A Compliance Matrix, change the name & date at the top, fill in all the columns and put it in a separate Appendices in the Branch Software Management Plan once the tailoring was approved. •  Q: And wouldn't each tailoring step need an individual sign off on the additional approvals?   • A: No all deviations for the one particular project are put on one Compliance Matrix for approval. • Q: Would we need one table for all non-tailored projects and a separate matrix for each product that includes tailoring? • A: Yes that is true.

49. Q & A on Branch-Level SMP • Q: The following concerns the Branch Level Software Management Plan (SMP) example on the web. I noticed in the preamble to Attachment 1, that 'each individual software item used by the task does not have to be listed in the table as long as they are all used to perform the Class E task requirements.'   So, do I read this correctly as individual software items do not need to be listed, just the task title?  • A: Yes – but – the descriptions of the all the separate codes should (at least once) be sent to Mission Assurance for independent classification assessment even if they are utilities used to analyze the data (e.g., Plotting codes, data conversion codes, visual basic scripts/macros used in excel to create custom functions used in data analysis)

50. Q & A • Q: For Class D/E tools that are used as GOTS to produce thousands of result data sets per year, what is required under the LMS software procedures. • A:This situation should be addressed as follows: • While the tools are under development they are in scope of all the Class D or E requirements. Once the scope/requirements of application of the tool is defined and testing, simulation, inspection, analysis or other verification and validation is complete for the tools scope/requirements • It becomes Government Off The Shelf (GOTS) software that any Langley civil servant or fellow project civil servant can use. • LMS requirements on use of GOTS do not apply to Class E and are optional for Class D. • HOWEVER