1 / 65

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

LMS 7150 Software Engineering Procedural Requirements - Focusing on the LPR and Class C -. Presented By: Pat Schuler M.Pat.Schuler@NASA.gov Head, Software Engineering Process Group Phone 757-864-6732. LMS Rollout_LPR_CP_Class C_R0V1 short.ppt. Getting the Most Out of This Training.

ksusan
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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!

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

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

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

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

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

  8. 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-7150.3 Class A, B, and All Safety Critical Software NASA-STD-8739.8 SW Assurance Standard NASA-STD-8719.13 NASA SW Safety Standard LMS-CP-7150.4 Class C Software LPR-7150.2 SW Engineering Requirements LMS-CP-7150.5 Class D Software LMS-CP-7150.6 Class E Software

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

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

  11. 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!) Plan what you do,Do what you plan

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

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

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

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

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

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

  18. Grandfather ClauseLPR 7150.2 Exclusion P.2.d.6 Examples using Class C

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

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

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

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

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

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

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

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

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

  29. Other Related Software Procedures and Forms

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

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

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

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

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

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

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

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

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

  39. Q&A

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

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

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

  43. Lastly • Please fill out your evaluation Forms • Please make sure you fill out the SIGN IN SHEET

  44. Backup

More Related