Branch Head Responsibilities in Engineering for Software Release
This presentation highlights the key responsibilities of Branch Heads as engineering technical authorities for software release, with a focus on software assurance and required documentation. It covers essential artifacts like SACR and RMM, roles such as NASA Software Lead, and software scope considerations based on NASA's classes. Non-compliance issues in software release processes are also addressed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Branch Head Responsibilities as Engineering Technical Authorities for Software With Emphasis on Software Release Presented by Michael Madden Chief Engineer for Modeling and Simulation 1
Outline Software Release (working backwards) Roles and Responsibilities What software is in scope? What counts as software? LPR 7150.2B Exclusion Limited Exemptions for COTS Required Documentation Software Assurance Classification Report (SACR) Requirements Mapping Matrix (RMM) Requirements Tailoring Noteworthy changes in NPR 7150.2C Project Portfolios Summary of Branch Head Responsibilities 2
Software Release (working backwards) NPR 2210.1C Release of NASA Software requires two software engineering artifacts as a condition of releasing software: The Software Assurance Classification Report (SACR) for the software described in NASA-STD-8739.8 Software Assurance Standard The NPR 7150.2 Requirements Mapping Matrix (RMM) for the project that developed or acquired the software Formerly known as a NPR 7150.2 Compliance Matrix These two artifacts are required of all projects containing software, not just those releasing software Required by NPR 7150.2 NASA Software Engineering Requirements NPR 7150.2 invokes NASA-STD-8739.8 Software Assurance Standard These two artifacts should be created at the beginning of the project! The Center Software Release Authority (SRA) is reporting an increase in projects starting the software release process without a SACR and RMM. 3
Roles and Responsibilities Why does this concern you? The line manager of the LaRC organization responsible for the software task shall assign the role of NASA Software Lead. LPR 7150.2B LSWE-015 A software task in any task that includes one or more software engineering activities For most software tasks at LaRC, the responsible organization is a branch. The NASA Software Lead is responsible for obtaining the SACR and completing the RMM in addition to other responsibilities defined in LPR 7150.2B. The NASA Software Lead can be a branch-wide role or assigned for each project. Directorate Branch Heads are responsible for the guidance of the engineering technical authority process in the branch LPR 7120.4 The Branch Head is the Engineering Technical Authority (TA) for software in the branch Except when the task is an element in a project with an assigned Project Chief Engineer, then the Project Chief Engineer is the Engineering TA Except when the task is an element of a system managed at the directorate level, then the Directorate Director is the Engineering TA unless otherwise delegated NPR 7150.2 assigns responsibilities to the Engineering TA (discussed in later slides) 4
What software is in scope? How do you know when to apply the software engineering requirements? Whenever software developed or acquired by or for NASA is intended for the uses defined in software classes A through F: Class A: human-rated space software Class B: robotic spaceflight or aeronautics demonstrator falling under NPR 7120.5 Class C: mission support software, major facilities, flight test vehicles LaRC Major Facilities listed in LAPD 7150.10 Class D: science data analysis, engineering design, labs, research and technology (R&T) software for ground test or flight test that is independent of the operation of the facility or flight test vehicle, R&T software supporting multiple projects (impact greater than a small group of users) Class E: design concept, R&T software on desktops or board tops, exploratory Class F: General Purpose Computing, Business, and IT Software (CIO) 5
What counts as software? In this directive, software is defined as (1) computer programs, procedures and possibly associated documentation and data pertaining to the operation of a computer system (2) all or a part of the programs, procedures, rules, and associated documentation of an information processing system (3) program or set of programs used to run a computer (4) all or part of the programs which process or support the processing of digital information (5) part of a product that is the computer program or the set of computer programs This definition applies to software developed by NASA, software developed for NASA, software maintained by or for NASA, COTS, GOTS, MOTS, OSS, reused software components, auto-generated code, embedded software, the software executed on processors embedded in programmable logic devices, legacy, heritage, applications, freeware, shareware, trial or demonstration software, and open-source software components. - NPR 7150.2C (with embedded references removed) Decoder: If a product ultimately executes on a processor, it is software. Decoder: Documentation or data is also in scope if it is a software engineering work product or it is necessary to execute the software for its intended purpose Work product example: data used to assess the outcome of software tests Software execution example: configuration files read by the executing software 6
LPR 7150.2B Exclusion This LPR does not apply to non-safety critical, standalone software that: (a) Has no anticipated delivery, and; (b) Is not the subject of a publication or delivered/published analyses, and (c) Is not included in a system that is being delivered, and (d) Will not be used to make decisions on Class A, B, C, or D systems. - LPR 7150.2B Decoder: If the software has value only to its author, it is not in scope The exemption is intended for software that an individual writes at their desk to perform back of the envelope calculations or improve personal productivity In the exemption, the term software does not include the software s output; therefore, the software can be exempt even its outputs are published The software has value to others and the exemption does not apply If the software is delivered, released, shared, or published If the software becomes a reportable item to a project or organization If the software executes in a NASA system (e.g., labs, facilities, ground systems, aircraft, spacecraft) If the software output is used to make decisions on the specification, design, implementation, verification, validation, operation, or maintenance of a NASA system 7
Limited Exemptions for COTS In NPR 7150.2, requirement SWE-027 applies to non-developed software. Such as commercial-off-the-shelf (COTS) software, government-off-the-shelf (GOTS) software, reused software, and open source software (OSS) However, SWE-027 is not applied Class E. Therefore, non-developed software used for a Class E purpose is implicitly exempt from NPR 7150.2. Note: Before NPR 7150.2C, non-developed software was also exempt for Class D. This LPR does not apply if solely acquiring non-developed software for unmodified use outside the context of a NASA system LPR 7150.2B Decoder: LPR/NPR does not apply to embedded software in devices that are not integrated into a NASA system (e.g. a purchased oscilloscope may contain embedded software - not in scope). Decoder: LPR/NPR often does not apply to non-developed software when the software is used out-of-the-box, and the software does not contribute to the engineering or science outcome of the project 8
Required Documentation Every software task is required to have A Software Assurance Classification Report (SACR) A Requirements Mapping Matrix (RMM) A Software Management Plan (SMP) All software tasks except Class E are required to have A Software Test Plan Software Test Procedures Software Test Reports The designated Engineering Technical Authority(s) shall define the content requirements for software documents or records NPR 7150.2C SWE-153 Includes the content of SMPs and Software Test Plans, Procedures, and Reports LPR 7150.2B Appendix E provides guidance on documents and contents The NASA Software Engineering Handbook (https://swehb.nasa.gov) also provides guidance on document contents under D. Topics, Topic 7.18 9
Software Assurance Classification Report The NASA Lead must first make a determination of the software class and safety-critical determination of a software task The NASA Software Lead sends their determination to the Center Software Assurance Manager (Leslie Johnson) who performs an independent assessment Once agreement is reached, the Center Software Assurance Manager creates a Software Assurance Classification Report (SACR) and sends it to the NASA Software Lead If the NASA Software Lead and the Center Software Assurance Manager cannot reach agreement, the Engineering Technical Authority and Safety & Mission Assurance Technical Authority resolve the dispute using the dispute resolution process in LPR 7120.4 10
Requirements Mapping Matrix (1/2) The Requirements Mapping Matrix (RMM) identifies responsible party and level of compliance for each NPR/LPR software engineering requirement for a given class as applied to the software task Documents any requirements tailoring by the project and the tailoring rationale. Identifies the Technical Authority that can approve tailoring (see Tailoring slide) The NASA Software Lead is responsible for the RMM When complete, the Software Lead sends the RMM to the Center Software Assurance Manager for a software assurance review and signature. The Center SRA will not accept the RMM for a software release without the signature Templates available on the LaRC Software Engineering web site. NPR 7150.2C/LPR 7150.2B Compliance Matrix Class: D Project: Add Project Name Technical Authority Req # Requirement Text Responsible Party Applicability Compliance Tailoring Description Tailoring Rationale The project manager shall assess options for software acquisition versus development. SWE-033 EngTA NASA Software Lead X FC The project manager shall develop, maintain, and execute software plans that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring. SWE-013 EngTA X 11
The Requirements Mapping Matrix (2/2) LPR 7150.2B defines three levels of compliance for a requirement: FC full compliance. T tailored. NA not applicable. Limited to requirements with a known applicability restriction. T used to tailor down, tailor out, or replace a requirement Requires technical authority approval NA is limited to requirements with a known applicability restriction Some requirements apply only for spaceflight projects, only when safety-critical (for Class C or Class D), or only for Independent Verification & Validation. Templates identify whether and when NA can be used in Column I NA marking does not require TA approval NA cannot be used against generally applicable requirements. A project uses T (tailor) to remove a generally applicable requirement; this is a tailor-out action. 12
Tailoring: Authorities Technical Authorities must approve tailoring of software engineering requirements in the RMM. Up to four approval authorities may be needed: Engineering Technical Authority (EngTA). Approval needed for tailoring any requirement. Safety & Mission Assurance TA (SMA TA). Not safety-critical: approval needed on tailoring select requirements marked SMA TA. Safety-critical: approval needed on tailoring any requirement Center CIO Tailoring Authority (CIO TA). Approval needed for tailoring cybersecurity requirements. Health and Medical Technical Authority. Tailoring any requirement when the software impacts human health and safety. This is rare. The signature line for this TA isn t provided on the templates. Some requirements need an LMS Waiver to tailor because they require Center Director or Headquarters approval Engineering TA and SMA TA must approve first. Also, Health and Medical TA if applicable. 13
Tailoring: Approval Requirements The Engineering TA assesses the RMM and requirements tailoring by Checking the accuracy of the project s classification of software Evaluating the RMM for commitments to meet requirements for the software class Confirming that requirements marked not applicable or tailored out are not relevant or not capable of being applied Determining whether the project s requests for tailoring requirements and related risks and mitigations are reasonable and acceptable. Approving/disapproving requirements tailoring Facilitating the processing of tailoring approvals from other technical authorities Include the CIO Tailoring Authority in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition and assurance activities. Ensuring that approved RMMs including any tailoring rationale are archived as part of retrievable project records. NPR 7150.2C SWE-126 Paraphrased. 14
Noteworthy Changes in NPR 7150.2C At a glance requirements changes by class not safety-critical software Software Class in NPR 7150.2B in NPR 7150.2C C 94 88 D 47 62 E 14 13 # Requirements # Requirements Percentage Change Reason Requirements consolidation -6% +32% -7% NPR 7150.2C removed safety-critical only Real decrease New cybersecurity requirements, some of which apply to all software classes Tailoring requires approval from a new CIO technical authority Requirements for static analysis tools and for reporting metrics to the Center repository added to Class D. Other new requirements for Testing: configuration management of test products; regression testing (Class A-C) Defect tracking and reporting (Class A-C) Measuring code coverage (Class A-D) 15
Project Portfolio Creating an RMM and an SMP seems like a lot of effort for every project, especially since most of our projects are similar. Is there a better way? Yes, LPR 7150.2B calls it a project portfolio. Projects in a project portfolio can share a RMM(s) and a SMP There is also an advanced alternative that uses a software policy and organizational standard processes A project portfolio can include different classes requiring a RMM for each class and an SMP that addresses the software engineering requirements for all classes Projects in a project portfolio cannot share a SACR. Each project must obtain its own SACR. Create a project portfolio RMM and SMP just as you would for a project SMP must describe the project portfolio with clear boundaries; however, many branches should be able to fit most if not all of their projects in a project portfolio The software class(es) and safety-critical determination of the project portfolio must be independently assessed by the Center Software Assurance Manager (similar to SACR process) 16
Summary of Branch Head Responsibilities Assign the role of NASA Software Lead for the branch or for each project The NASA Software Leads are responsible for the projects SACR and RMM As the Engineering Technical Authority for the branch Determine the software engineering documents and document contents for branch projects containing software Work with the Safety & Mission Assurance Office to resolve disputes over the software classification and safety-critical determination in the SACR Review and approve requests for tailoring engineering requirements in the RMM Assist the project in getting approvals from other technical authorities as needed Keep records of approved RMMs To reduce repetitive creation of RMMs and SMPs, consider the creation of a project portfolio for the branch 17
Questions? Is visualization COTS software like tecplot exempt? When tecplot is used in the production of published or deliverable engineering or science products, then the answer is no based on a plain interpretation of NPR 7150.2. COTS use is governed by NPR 7150.2 SWE-027. However, SWE-027 is not mapped to class E. So, tecplot is implicitly exempt for Class E uses. NPR 7150.2C added SWE-027 to class D. So, tecplot is no longer exempt from class D uses. Nevertheless, these situations can be handled with project tailoring. Therefore, if a branch wanted to effectively exempt products like tecplot, the branch could go through the exercise of tailoring out SWE-027 for these products. The Branch Head, as an Engineering Technical Authority, could use their discretion to decide that tecplot and similar products do not warrant action because a) the branch is using the product out-of-the-box for its as-built purpose and b) the COTS product represents negligible risk to NASAs missions. In other words, do what makes sense for your branch and does not violate the intent of NPR 7150.2 in protecting NASA missions from defective software. 18
