Download as PDF, PPTX
![Designation of Engineering Technical
Authority(s)
6.2.1 The designated Engineering Technical Authority(s) for
requirements in this NPR, which can be waived at the Center level,
shall be approved by the Center Director. [SWE-122]
Note: The designated Engineering Technical Authority(s) for this NPR is a recognized
NASA software engineering expert.
Typically, Center Directors designate an Engineering Technical Authority for software
from their engineering organization for software classes A through E,
from the NASA Headquarters Office of the Chief Information Officer (CIO) for
Class F, and
from their Center CIO organization for classes G through H.
The designation of Engineering Technical Authority(s) is documented in the
Center Technical Authority Implementation Plan.
Appendix D (last column) shows which requirements can be waived at the Center
level.
Allocation of requirements
HQ – 8 Waiver/deviation authority
Centers– 14
Project s & SMA – 110 Center - 72%
HQ - 28%
27](https://image.slidesharecdn.com/kelly-crumbley-111027095103-phpapp02/75/Kelly-crumbley-27-2048.jpg)
More Related Content
Kelly crumbley
- 1. PM Challenge 2010 NASA Software Engineering Procedural Requirements and related Policy February 9-10, 2010 John C. Kelly & Tim Crumbley Office of Chief Engineer Used with Permission
- 2. Overview 1. NPD/NPR “GoTo” Architecture for the Office of Chief Engineer 2. Lessons Learned from previous NPR 3. Update of NASA Software Engineering Requirements, NPR 7150.2 4. Future Work 2
- 3. Differences between NPDsand NPRs according to NASA Regulations NPD 1400.1I, Documentation and Promulgation of Internal NASA Requirements NASA Policy Directive (NPD). NPDs are policy statements that describe what is required by NASA management to achieve NASA's vision, mission, and external mandates and who is responsible for carrying out those requirements. NASA Procedural Requirements (NPR). NPRs provide Agency mandatory instructions and requirements to implement NASA policy as delineated in an associated NPD. NASA Technical Standards. NASA technical standards are NASA documents that contain common and repeated use of rules, conditions, guidelines, or characteristics for products or related processes and production methods and related management systems practices. 3
- 4. Office of ChiefEngineer Previous NPD/NPR Architecture NPD 2820.1 NPD 8070.6 NPD 8010.2 NPD 7120.4 Software Technical Use of SI Program / Policy Standards. Metric Project Mgt X X NPR 7120.5 NPR 7120.6 NPR 7120.7 NPR 7120.8 NPR 7123.1 Space Flt Lesson IT & Inst. R&T Systems P/P Mgt Learned P/P Mgt P/P Mgt Engineering Planned OCE NPR additions: NPR 7150.2 - PLM/PDM Software Engineering - Technical Standards 4
- 5. Office of ChiefEngineer “Go To Architecture” NPD 7120.4 Engineering & P/P Mgt (in A-Suite) NPR 7120.5 NPR 7120.6 NPR 7120.7 NPR 7120.8 NPR 7123.1 Space Flt Lesson IT & Inst. R&T Systems P/P Mgt Learned P/P Mgt P/P Mgt Engineering NPR 71xx.x NPR 71xx.x NPR 7150.2 PLM/PDM Technical Software (Completed Standards Engineering NODIS Review) (Future) 5
- 6. 1.3.1 Higher Agency-LevelRequirements NPD 1000.0, NASA Governance and Strategic Management Handbook. NPD 1000.3, The NASA Organization. NPD 1000.5, Policy for NASA Acquisition. 1.3.2 Agency-Level Software Policies and Requirements NPD 7120.4, NASA Engineering and Program/Project Management Policy NPR 7120.5, NPR NPR 7120.7, NPR 7120.8, NPR 7123.1, NPR 7150.2, NASA Space Flight 7120.6, NASA Information NASA Research and NASA Systems NASA Software Program and Lessons Technology and Technology Program Engineering Engineering Project Learned Institutional and Processes and Requirements Management Process Infrastructure Project Management Requirements Requirements Program and Project Requirements Management Requirements 1.3.3 Agency-Level Multi-Center and Product 1.3.4 NASA and Industry Software Line Requirements (non- software specific) Standards and Guidebooks NASA Preferred Industry Software Standards and These NPDs and NPRs elaborate, tailor, and in some Guidebooks and NASA Software-Related cases add requirements to the ones above to address Standards and Guidebooks are required when the needs of major multi-Center projects, specific invoked by an NPD, NPR, Center-Level Directive, product lines, and specific focus areas. contract clause, specification, or statement of work. 1.3.5 Center-Level Directives (related to software) Center-Level Directives are developed by NASA Centers to document their local software policies, requirements, and procedures. 1.3.6 Government In-house 1.3.7 Contractor and Subcontractor Development Development Contractors and subcontractors develop in-house Government in-house software development policies and policies and procedures to provide quality products and procedures to provide quality products and to fulfill the to fulfill the requirements passed down through a requirements passed down by a project. contract by a customer.
- 7. Overview 1. NPD/NPR “GoTo” Architecture for the Office of Chief Engineer 2. Lessons Learned from previous NPR 3. Update of NASA Software Engineering Requirements, NPR 7150.2 4. Future Work 7
- 8. Lesson Learned fromthe development of original NPR 7150.2 1. Form a strong core development team (slide 10) 2. Select your target audience wisely (slides 13 & 14) 3. Know where the NPR stands in the Agency’s set of directives (slides 5 & 6) 4. Set the criteria for including or excluding requirements early (slides 15 & 16) 5. Get professional help (slides 17 & 18) 6. Design the document well 7. One size doesn’t fit all, make appropriate accommodations (slide 19) 8. It takes a village of reviewers to develop a quality document 9. Follow-through is everything (slide 31) 8
- 9. Overview 1. NPD/NPR “GoTo” Architecture for the Office of Chief Engineer 2. Lessons Learned from previous NPR 3. Update of NASA Software Engineering Requirements, NPR 7150.2 4. Future Work 9
- 10. NPR 7150.2A DevelopmentTeam Ames – Cyrus Chow JPL – Scott Morgan Joe Coughlan Steve Flanagan APL – Steve Pereira JSC – Charlotte Hudgins DFRC – Keith Schweikhard Nick Lance GRC – Kevin Carmichael KSC – Brenda Penn GSFC – Sally Godfrey Caren Ensey Sue Sekira LaRC – Pat Schuler HQ OCE – John Kelly (co-lead) Chuck Niles Tim Crumbley (co-lead) MSFC – Pat Benson Amy Morusiewicz (CSC) Cathy White HQ OSMA – Melissa Bodeau NESC – Mike Aguilar Martha Wetherholt NSC – Karen Meinert IV&V – Lisa Montgomery SSC – Phillip Hebert Wallops – Donna Smith Other Key Contributors: Ames - Silvano Colombano JSC - Ken Jenks HQ SMD – Rhoda Hornstein Liz Strassner IV&V - Leigh Gatto LaRC - Michael Madden JPL - Bob Vargo Dan Dvorak 10
- 11. Purpose and Historyof the NPR The Effective Date of the original NASA Software Engineering Requirements NPR was September 27, 2004 Software engineering is a core capability and a key enabling technology for NASA's missions and supporting infrastructure. This NASA Procedural Requirements (NPR) supports the implementation of the NASA Policy Directive (NPD) 7120.4, NASA Engineering and Program/Project Management Policy. This NPR provides the minimal set of requirements established by the Agency for software acquisition, development, maintenance, retirement, operations, and management. This NPR is intended to support NASA programs and projects to accomplish their planned goals (e.g., mission success, safety, schedule, and budget) while satisfying their specified requirements. 11
- 12. Purpose and Historyof the NPR This NPR provides a set of software engineering requirements in generic terms to be applied throughout NASA and its contractor community. For this NPR Software Engineering is defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software: that is, the application of engineering to software. For this NPR, Software is defined as the computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a computer system. Software includes programs and data. This definition includes commercial-off-the-shelf (COTS) software, government-off-the-shelf (GOTS) software, modified-off-the-shelf (MOTS) software, reused software, auto generated code, embedded software, firmware, and open source software components. 12
- 13. Profile of NPRtarget audience Advances Early Progressive Slow Entrenched Adopters Users Adopters Resisters 13
- 14. Purpose of NPRs Shift NASA SW Community to the left 10 - 25% Advances Early Progressive Slow Entrenched Adopters Users Adopters Resisters 14
- 15. Criteria All additions and modifications to the update of NPR 7150.2 must meet the following primary criteria and/or be of the following nature: 1. Consistent with existing NASA policy a. Updated NPR 7120.5D b. NPD 2820.1C (or document liens against the 2010 NODIS update of this document) c. Current Engineering Technical Authority d. NPR 1400.1D f. CAIB findings 2. Requirements added or modified should have a track record of successful implementation within NASA’s Software Engineering Community 3. Requirements included must be of a software engineering* in nature and within the scope of responsibility of a. NASA or contractors’ engineering line organizations, or b. Implementing programs or projects, or c. Interface to Third Party Value added/functional office requirements 4. Must be a “requirement” denoted by a “shall”, rather than “guidance” 5. Must be able to be verified 6. Allow appropriate deviations and waivers via the Engineering TA process 7. Requirements written at a level that states “what” not “how” (not overly prescriptive) 8. Increase safety, quality & reliability of NASA SW 9. Supports the software initiative and ongoing improvement activities 10. Reasonable confidence that updates will not significantly impact current usage and consistent NPR 7150.2 Center direction in a negative manner 11. The update will address the top issues raised by the Centers and be responsive to the IG recommendations (from the 2007 Report) 12. Avoid changing SWE numbers, if possible. (e.g., keep from having to redo mappings, etc.) 13. Write at the “expert level” 14. Utilize a “one stop” approach for Agency software engineering requirements 15. Update SW Classifications based on: a) Shorter simpler definitions, b) key examples, c) intended use of software, & d) supported with external guidance * “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software: that is, the application of engineering to software. (2) The study of approaches as in (1).” – 15 IEEE Standard Glossary of Software Engineering Terminology. 1990
- 16. Top Center Issues/Recommendationsfor the Update of NPR 7150.2 Issue % of NPR 7150.2A changes: Centers* 1 SW Classifications 78% Improved content, examples, clarity and structure of the Software Class definitions in Appendix E 2 Technical Authority 56% Updated Technical Authority coverage in Chapter 6 with respect to software 3 Interface with NPR 7120 & 44% Improved harmonization with NPR 7123.1, NPR 7120.5, NPR NPR 7123 7120.7, NPR 7120.8, NASA-STD-8719.13, and NASA-STD-8739.8 4 Application to Contractors & 44% Updated the P.2 Applicability and Scope section Non-NASA Partners 5 P(Center) 33% Additional information on the flexibility and meaning of “P(Center)” in the Requirements Mapping Matrix (Appendix D) and Chapter 6 6 Complex Electronics 33% No change, part of NESC study 7 COTS, GOTS, & MOTS 33% Revised the requirement wording and updated the Note associated with requirement number SWE-027 8 Small Projects 33% Minor changes, added words in notes to address content coverage required at different classes, will be further addressed in NPR guidance 9 Clarity, Consistency, 44% Corrected duplications, typos, and miscellaneous minor problems, Duplication, Typos, & improved clarity, and consistency Updated the references and acronyms appendixes Miscellaneous minor Updated the definitions, primarily using industry standard IEEE problems definitions * Issues were as reported out at the NASA SWG Face-to-Face meeting at NASA Plum Brook, August 2008. 16
- 17. Lesson #5: GetProfessional Help There is no substitute for professional editing & assistance Avoid a “big honking binder” An NPR is not a lessons learned data base, an NPR is not a training manual, an NPR is not an encyclopedia, …. Consider the use of “expert mode” (a reminder to well educated and experienced peers of key requirements) The document has to make sense to peers who have not had the benefit of the core team discussions Consider the use of quick reference and supporting material Control the number and use of “shall” statements (numbered requirements, sentence structure, etc.) Utilize chunking principles 17
- 18. Changes by theNumbers 2004 2009 Total # of Requirements = Total # of Requirements = 129 132 Added (11 total): Deleted (8 total): SW Safety & IV&V Plans (when Redundant with other documents applicable) = 3 =6 Independent SW classification OBE Technical Authority assessment and safety critical Requirement = 1 determination by SMA = 2 Mission Directorate reporting of SW safety engineering requirement SW metrics to OCE = 1 =1 Peer review/inspection of plans = 1 Static analysis checking of code = 1 Validation of SW tools for use = 1 “X” & “P(Center)” clarification in the Requirements Mapping Matrix (Appendix D) = 2 18
- 19. NPR 7150.2A RequirementsMapping to Software Classifications all the requirements for which the project has responsibility or part responsibility Safety Critical Non Safety Critical Class A Class B Class C Class D & E Class C Class D Class E Class F Class G Class H X 110 106 78 68 73 30 10 106 41 11 P (Center) 0 1 0 0 23 25 7 0 65 5 Safety Only (SO) 0 0 7 15 0 0 0 0 0 0 P (Center) + SO 0 3 21 21 0 0 0 0 0 0 SO - "Safety Only". Project is required to meet this requirement to the extent necessary to satisfy safety critical aspects of the software. The use of partial Center (i.e., “P(Center)”) requirements allows for local adaptations to suit Center and application unique needs. “P(Center)” requirements are typically documented in Center 19 level directives.
- 20. Innovations and Improvementsincorporated in the updated NPR 7150.2A Added requirements related to the developmental aspects of safety critical software Revised columns in the Requirements Mapping Matrix to include the “sound engineering” practices needed for safety critical software Set of added requirements based on NASA experience which address the design and coding aspect of safety critical software Added requirements for a software safety plans Added a requirement for projects to perform a software safety criticality assessment Added IV&V requirements, Inclusion of top level IV&V plan requirement Added a requirement to verify, validate and accredit software development tools Added clarification and direction on independent software testing Documented allocation and waiver/deviation authority for each requirement Structured SW Classification definitions: Improved definition wording Added examples Made exclusions explicit Addition of static analysis tool usage, based on the 2008 Flight Software Complexity Study recommendation and NASA experience with these tools Class A Software (only): CMM 3 or CMMI 2 CMMI 3 20
- 21. New requirements addedinto NPR 7150.2A Class A OR Class B OR Classes C Technical Class A and Class B and thru E and Authority for Safety Safety Safety Class C and Class D and Class E and NPR 7150.2 by SWE # Requirement Critical Critical Critical NOT Safety NOT Safety NOT Safety Requirement Section of NPR Descriptor** Responsibility Note 2 Note 2 Note 2 Critical Critical Critical Class F Class G Class H (Note 3) HQ CE/ Software safety X (if Safety X (if Safety X (if Safety plan 130 Project X X X Critical) Critical) Critical) CSMAO X X X X HQ CE/ (if selected fo (if selected for(if selected fo (if selected fo IV&V Plan 131 IV&V Program IV&V) IV&V) IV&V) IV&V) CSMAO Independent Software HQ CE/ Classification SMA Assessment 132 organization X X X X X X X X X CSMAO HQ CE/ Software safety Project & SMA determination 133 organization X X X X X X X X X CSMAO Center Director* (joint Software Safety-critical Engineering TA Lifecycle software & SMA TA if Planning requirements 134 Project X P (Center) (see Note 7) delegated) X Static analysis 135 Project X X (SO if D-E) X Center Director* X X X Software (if Note 4 is (if Note 4 is Implementation Validation of soft 136 Project X X true) true) f Note 4 is true Center Director* Software Peer Peer Review/ Reviews/ inspections of P (Center) + Inspections Software plans 137 Project X X SO P (Center) X (not OTS) P (Center) Center Director* Software Software safety X (if Safety X (if Safety X (if Safety 138 Project X X X HQ CE/CSMAO Documentation plan contents Critical) Critical) Critical) Requirements "Shall" statements in this NPR 139 Project, Center X X X X X X X X X HQ CE 21 Meeting Compliance "P(Center)" 140 Project, Center X X X X X X X X X HQ CE
- 22. New requirements addedinto NPR 7150.2A Class A OR Class B OR Classes C Technical Class A and Class B and thru E and Authority for Safety Safety Safety Class C and Class D and Class E and NPR 7150.2 by SWE # Requirement Critical Critical Critical NOT Safety NOT Safety NOT Safety Requirement Section of NPR Descriptor** Responsibility Note 2 Note 2 Note 2 Critical Critical Critical Class F Class G Class H (Note 3) HQ CE/ Software safety X (if Safety X (if Safety X (if Safety plan 130 Project X X X Critical) Critical) Critical) CSMAO X X X X HQ CE/ (if selected fo (if selected for(if selected fo (if selected fo IV&V Plan 131 IV&V Program IV&V) IV&V) IV&V) IV&V) CSMAO The new NPR SoftwareCE/ Independent Software HQ X Engineering requirements Classification SMA Assessment 132 organization X X X X X X X X CSMAO Software safety Project & SMA are focused on improving HQ CE/ software safety, software determination 133 organization X X X X X X X X X CSMAO Center Director* verification and clarifying TA (joint Software Safety-critical Engineering compliance. These changes Lifecycle software & SMA TA if Planning requirements 134 Project X P (Center) (see Note 7) delegated) are targeted to improving X Static analysis 135 Project X X (SO if D-E) X Center Director* X X (if Note 4 is (if Note 4 is Xmission success for software projects Software Implementation Validation of soft 136 Project X X true) true) f Note 4 is true Center Director* Software Peer Peer Review/ Reviews/ inspections of P (Center) + Inspections Software plans 137 Project X X SO P (Center) X (not OTS) P (Center) Center Director* Software Software safety X (if Safety X (if Safety X (if Safety 138 Project X X X HQ CE/CSMAO Documentation plan contents Critical) Critical) Critical) Requirements "Shall" statements in this NPR 139 Project, Center X X X X X X X X X HQ CE 22 Meeting Compliance "P(Center)" 140 Project, Center X X X X X X X X X HQ CE
- 23. Approach on requirementsrelated to the developmental aspects of safety critical software Phase 0 2004 – 2008 (SW engineering requirements related to safety) NPR 7150.2, SW NASA SW Assurance and Engineering Safety Standards Minimum SW Engineer Requirements for identifying Requirements base on SW and applying SW Assurance Classifications A - H. Mute on methods safety related requirements* Requirements to implement a systematic approach for software safety (Minimum SW Engineer Requirements based on software safety criticality) Specific Program and Project Requirements (w/Human Spaceflight track record) Problem: Redundant and distributed “good software engineering/development Program and Project Requirements requirements” related to safety between NPR 7150.2, NASA STD 8737.8 (SW Generic Engineering Design Assurance), NASA STD 8719.13 (SW Requirement for safety critical software systems Safety), and Program/Project Requirements * Only safety requirement was SWE-023 which invokes NASA STD 8719.13 for safety critical software 23
- 24. Approach on requirementsrelated to the developmental aspects of safety critical software Phase 1 2009 (NPR 7150.2A update com pleted ) NPR 7150.2.A, SW NASA SW Assurance and Engineering Safety Standards Requirements for identifying Minimum SW Engineer and applying SW Assurance Requirements base on SW methods Classifications A – H and software safety criticality Requirements to implement a systematic approach for Generic Engineering Design software safety Requirement for safety critical software systems (Minimum SW Engineer Requirements based on software safety criticality) Specific Program and Project Requirements (w/Human Spaceflight track record) Partial Solution: Move “good Program and Project software engineering/development Requirements requirements” related to safety to Generic Engineering Design NPR 7150.2A Requirement for safety critical software systems 24
- 25. Approach on requirementsrelated to the developmental aspects of safety critical software Phase 2 2010 (NASA STD 8719.13 and STD 8739.8 updates) NPR 7150.2.A, SW NASA SW Assurance and Engineering Safety Standards Requirements for identifying Minimum SW Engineer and applying SW Assurance Requirements base on SW methods Classifications A – H and software safety criticality Requirements to implement a systematic approach for Generic Engineering Design software safety* Requirement for safety critical software systems (Minimum SW Engineer Requirements based on software safety criticality) Specific Program and Replace with pointer to NPR Project Requirements 7150.2 A (w/Human Spaceflight track record) Ultimate Solution: NPR 7150.2A Program and Project Requirements becomes the consolidated home for “good software Generic Engineering Design engineering/development Requirement for safety critical software systems requirements” related to safety Replace with pointer to NPR 7150.2A on future programs and projects 25 * Safety identification, assurance, risk & hazards analysis, FMEA,… remain in NASA STD 8719.13.
- 26. Structured SW Classificationdefinitions Structured SW Classification definitions: Improved definition wording Added examples Made exclusions explicit Class B: Non-Human Space Rated Software Systems or Large Scale Aeronautics Vehicles Space Systems*: Flight and ground software that must perform reliably to accomplish primary mission objectives, or major function(s) in Non-Human Space Rated Systems. Limited to software that is: 1. Required to operate the vehicle or space asset (e.g., orbiter, lander, probe, flyby spacecraft, rover, launch vehicle, or primary instrument), such as commanding of the vehicle or asset, or 2. required to achieve the primary mission objectives, or 3. directly prepares resources (data, fuel, power, etc.) that are consumed by the above functions. Airborne Vehicles: Large Scale aeronautic vehicles that are NASA unique in which the software: 1. Is integral to the control of an airborne vehicle, or 2. monitors and controls the cabin environment, or 3. monitors and controls the vehicle’s emergency systems. Examples: Examples of Class B software includes but are not limited to: Space, Launch, Ground, EDL, and Surface Systems: propulsion systems; power systems; guidance navigation and control; fault protection; thermal systems; command and control ground systems; planetary/lunar surface operations; hazard prevention; primary instruments; science sequencing engine; simulations which create operational EDL parameters; subsystems that could cause the loss of science return from multiple instruments; flight dynamics and related data; launch and flight controller stations for non-human spaceflight. Aeronautics Vehicles (Large Scale NASA unique): guidance, navigation, and control; flight management systems; autopilot; propulsion systems; power systems; emergency systems (e.g., fire suppression systems, emergency egress systems; emergency oxygen supply systems, traffic/ground collision avoidance system); cabin pressure and temperature control. Exclusions: Class B does not include: 1. Software that exclusively supports non-primary instruments on Non-Human Space Rated Systems (e.g., low cost non-primary university supplied instruments) or 2. systems (e.g., simulators emulators, stimulators, facilities) used in testing Class B systems containing software in a development environment. 26
- 27. Designation of EngineeringTechnical Authority(s) 6.2.1 The designated Engineering Technical Authority(s) for requirements in this NPR, which can be waived at the Center level, shall be approved by the Center Director. [SWE-122] Note: The designated Engineering Technical Authority(s) for this NPR is a recognized NASA software engineering expert. Typically, Center Directors designate an Engineering Technical Authority for software from their engineering organization for software classes A through E, from the NASA Headquarters Office of the Chief Information Officer (CIO) for Class F, and from their Center CIO organization for classes G through H. The designation of Engineering Technical Authority(s) is documented in the Center Technical Authority Implementation Plan. Appendix D (last column) shows which requirements can be waived at the Center level. Allocation of requirements HQ – 8 Waiver/deviation authority Centers– 14 Project s & SMA – 110 Center - 72% HQ - 28% 27
- 28. Documented allocation andwaiver/deviation authority for each requirement Documented allocation and waiver/deviation authority for each requirement Class A OR Class B OR Classes C Technical Class A and Class B and thru E and Authority for Safety Safety Safety Class C and Class D and Class E and NPR 7150.2 by SWE # Requirement Critical Critical Critical NOT Safety NOT Safety NOT Safety Requirement Section of NPR Descriptor** Responsibility Note 2 Note 2 Note 2 Critical Critical Critical Class F Class G Class H (Note 3) Software plans 13 Project X X X X P (Center) P (Center) X P (Center) HQ CE Execute planning 14 Project X X X X X X X P (Center) Center Director* Cost estimation 15 Project X X X X P (Center) P (Center) X P (Center) Center Director* Schedule 16 Project X X X X P (Center) X P (Center) Center Director* Training 17 Project X X X X X P (Center) Center Director* Reviews 18 Project X X X X X X P (Center) Center Director* Software development life cycle or model 19 Project X X X X P (Center) X (not OTS) P (Center) Center Director* SW Life Cycle Software Planning classification 20 Project X X X X X X X X X HQ CE 28
- 29. NPR 7150.2A Summary The NPR 7150.2A addresses a number of the issues and lessons learned over the last five years The updated NPR will continue to fulfill a need to reduce risks for new projects on the horizon that depend upon software The Office of Chief Engineer appreciates the feedback and active support we have received to establish a workable set of software engineering requirements We are committed to facilitating the implementation of NPR 7150.2A to meet the Agency’s current and future challenges in software engineering We look forward to working with the Centers on implementing the updated NPR 7150.2A on software activities 29
- 30. Overview 1. NPD/NPR “GoTo” Architecture for the Office of Chief Engineer 2. Lessons Learned from previous NPR 3. Update of NASA Software Engineering Requirements, NPR 7150.2 4. Future Work 30
- 31. FY10 Software ImprovementInitiative Structure Policy & Procedural Processes Technology Requirements Ongoing • • NPD 7120.4* update NPR 7150.2A, SW Engineering • • CMMI Appraisals NASA & Center • Tool Shed • Sys & SW Journal Requirements update - com pleted Process Asset • Reviewers and Rep. to OSMA’s • OCE Survey* (5 Centers + HQ) Libraries (PALs) SW Assurance Research • SW Measurement Program (SARP)* SW Engr. Handbook (Electronic) Center processes New for • • Center Compliance with new • updated for • Update SW Technology Strategy for 2011 and beyond 2010 NPR 7150.2A consistency with • Interface to SW Architecture • OSMA’s update to NASA Safety new NPR 7150.2A Review Board effort (NESC)* and Assurance standards • Interface to Multi-Core Flight • R epresentative to help develop computing* new Programmable Logic • Interface to SW Engineering Devices Policy/Std/HB* Research Center (SERC) • Interface to NASA Aviation Safety Program* Crosscutting • • Center SW Improvement Plans Training (including NPR 7150.2A Classroom & NASA SATERN) • NASA Engineering Network*, Software.nasa.gov • Software Inventory, SIMS Tool, Analysis & Suggestions for projects to receive IV&V • SWG F2Fs, Leads Meeting, & Telecons • Communications / Exchanges (CMMI Steering Group, v1.3 CCB, TIMs, etc.) • Interface to Systems Engineering Working Group • Interface to Fault Management Working Group* * Software Engineering portions or contributions
- 32. Programmable Logic Devices (Complex Electronics) NESC Problem Description Non descript discipline terms (“firmware”, “software” & “hardware”) have been used to describe a complicated device, which creates confusion Is an FPGA/ASIC containing a microprocessor function and associated code a hardware or software system? No known single NASA-wide set of procedures, policy and/or guidelines exists for the design, development, test, and evaluation (DDT&E) of FPGA/ASICs for space flight applications. Historically, the application design’s operational speed and complexity has increased concurrently with the size of the circuitry decreasing The single integrated circuit gives the appearance of minimal complexity Past experience has uncovered undesirable features existing in designs This situation has all the ingredients of a pending accident Complex design with critical functions + Difficultly in thoroughly testing all combinational logic modes + Varying DDT&E process + “It is only a chip” paradigm NESC Request No: TI- 09-00546 32
- 33. Programmable Logic Devices (Complex Electronics) NESC Report Recommendations R-1: Recommend the OCE and OSMA direct the development of new NASA policies and standards specifically for CE. R-2: The Center Engineering Organizations and the NASA Technical Fellow for Avionics should consider Complex Electronics technical Experts as a candidate group for a Community of Practice. The Community of Practice will enhance informal networks between NASA Centers and other Government Agencies, industry, and academia to encourage communications, lessons learned, peer reviews, and knowledge transfer. R-3: Center Engineering Directorates should assure development plans for CE devices containing or interfacing to software products address the following. R-4: The ambiguous term “firmware” should be avoided in all official NASA documentation. NESC Request No: TI- 09-00546 33