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

1. LMS 7150 Software Engineering Procedural Requirements- Focusing on the LPR and Class D - Presented By: Pat Schuler M.Pat.Schuler@NASA.gov Head, Software Engineering Process Group Phone 757-864-6732 LMS Rollout_LPR_CP_Class D_R0V8 short.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. What is the General Breakdown of Center Procedures & Their Value • Software Management Requirements • Planning, organizing, technical direction, communication, and control of tasks • Lets 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!) Plan what you do,Do what you plan

10. HQ NPR Based Heavily on Capability Maturity Model Integrated (CMMI) Level 2 & ISO/IEC 12207 Standard for Information Technology - Software LifeCycle Processes CMMI • 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 Cornerstone ISO/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

11. Software Requirements Policies/Laws: Disclosure, Technology Transfer, External Release, Security, Disabilities Formulate, Classification & Acquisition Req. Start Up Plans, Estimates, & Schedules Plan Lifecycle & Stakeholder Reviews Assurance Safety Monitor Monitor, Track, & Control Develop Requirements Design Implementation Testing Operations Maintenance Retirement Requirements Management & Traceability Verification & Validation Configuration Management Supporting Requirements Risk Management Peer Reviews/Inspections Measurement Quality Assurance Training

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

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

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

15. Examples of Software Class • Class C Software • Non-primary Instrument Flight SW • Large Scale Facilities Operations/Control • Ground Support Equipment that interfaces to flight hardware • Class B Software • Primary Instrument Spacecraft Flight SW • Ground SW That Controls The Spacecraft • Class A Software • Human Rated Software Safety, Reliability, Complexity

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

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

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

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

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

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

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

24. 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 the Acquisition Preparation Step 2 • Then Walk through Class D template for the Software Management Plan and the Configuration Management Plan that included acquisition

28. 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 the Acquisition Preparation Step 2 • Then Walk through Class D template for the Software Management Plan and the Configuration Management Plan that includes acquisition

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

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

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

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

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

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

36. Other Related Software Procedures and Forms

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

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

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

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

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

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

44. 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’

45. 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) Make sure you have evidence

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

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

49. - Class D – Any questions? 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