• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Kelly crumbley
 

Kelly crumbley

on

  • 11,112 views

 

Statistics

Views

Total Views
11,112
Views on SlideShare
11,112
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Kelly crumbley Kelly crumbley Presentation Transcript

    • PM Challenge 2010 NASA Software EngineeringProcedural Requirements and related Policy February 9-10, 2010 John C. Kelly & Tim Crumbley Office of Chief Engineer Used with Permission
    • Overview1. NPD/NPR “Go To” Architecture for the Office of Chief Engineer2. Lessons Learned from previous NPR3. Update of NASA Software Engineering Requirements, NPR 7150.24. Future Work 2
    • Differences between NPDs and 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 NASAs 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
    • Office of Chief Engineer 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 EngineeringPlanned OCE NPR additions: NPR 7150.2- PLM/PDM Software Engineering- Technical Standards 4
    • Office of Chief Engineer “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
    • 1.3.1 Higher Agency-Level Requirements 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 Requirements1.3.3 Agency-Level Multi-Center and Product 1.3.4 NASA and Industry SoftwareLine 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 SubcontractorDevelopment 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.
    • Overview1. NPD/NPR “Go To” Architecture for the Office of Chief Engineer2. Lessons Learned from previous NPR3. Update of NASA Software Engineering Requirements, NPR 7150.24. Future Work 7
    • Lesson Learned from the development of original NPR 7150.21. 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 well7. One size doesn’t fit all, make appropriate accommodations (slide 19)8. It takes a village of reviewers to develop a quality document9. Follow-through is everything (slide 31) 8
    • Overview1. NPD/NPR “Go To” Architecture for the Office of Chief Engineer2. Lessons Learned from previous NPR3. Update of NASA Software Engineering Requirements, NPR 7150.24. Future Work 9
    • NPR 7150.2A Development TeamAmes – Cyrus Chow JPL – Scott Morgan Joe Coughlan Steve FlanaganAPL – Steve Pereira JSC – Charlotte HudginsDFRC – Keith Schweikhard Nick LanceGRC – Kevin Carmichael KSC – Brenda PennGSFC – Sally Godfrey Caren Ensey Sue Sekira LaRC – Pat SchulerHQ OCE – John Kelly (co-lead) Chuck Niles Tim Crumbley (co-lead) MSFC – Pat Benson Amy Morusiewicz (CSC) Cathy WhiteHQ OSMA – Melissa Bodeau NESC – Mike Aguilar Martha Wetherholt NSC – Karen MeinertIV&V – Lisa Montgomery SSC – Phillip Hebert Wallops – Donna SmithOther Key Contributors:Ames - Silvano Colombano JSC - Ken JenksHQ SMD – Rhoda Hornstein Liz StrassnerIV&V - Leigh Gatto LaRC - Michael MaddenJPL - Bob Vargo Dan Dvorak 10
    • Purpose and History of 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 NASAs 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
    • Purpose and History of 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
    • Profile of NPR target audience AdvancesEarly Progressive Slow EntrenchedAdopters Users Adopters Resisters 13
    • Purpose of NPRs Shift NASA SW Community to the left 10 - 25%AdvancesEarly Progressive Slow EntrenchedAdopters Users Adopters Resisters 14
    • 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, andmaintenance 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
    • Top Center Issues/Recommendations for 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 E2 Technical Authority 56% Updated Technical Authority coverage in Chapter 6 with respect to software3 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.84 Application to Contractors & 44% Updated the P.2 Applicability and Scope section Non-NASA Partners5 P(Center) 33% Additional information on the flexibility and meaning of “P(Center)” in the Requirements Mapping Matrix (Appendix D) and Chapter 66 Complex Electronics 33% No change, part of NESC study7 COTS, GOTS, & MOTS 33% Revised the requirement wording and updated the Note associated with requirement number SWE-0278 Small Projects 33% Minor changes, added words in notes to address content coverage required at different classes, will be further addressed in NPR guidance9 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
    • Lesson #5: Get Professional HelpThere 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
    • Changes by the Numbers2004 2009 Total # of Requirements =  Total # of Requirements = 129 132Added (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
    • NPR 7150.2A Requirements Mapping to Software Classificationsall 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 HX 110 106 78 68 73 30 10 106 41 11P (Center) 0 1 0 0 23 25 7 0 65 5Safety Only (SO) 0 0 7 15 0 0 0 0 0 0P (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.
    • Innovations and Improvements incorporated 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
    • New requirements added into 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 RequirementSection 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 isImplementation 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/CSMAODocumentation 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
    • New requirements added into 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 RequirementSection 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 SoftwareImplementation 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/CSMAODocumentation 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
    • Approach on requirements related 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
    • Approach on requirements related 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 andEngineering Safety Standards Requirements for identifyingMinimum SW Engineer and applying SW AssuranceRequirements base on SW methodsClassifications A – H andsoftware safety criticality Requirements to implement a systematic approach forGeneric Engineering Design software safetyRequirement for safety criticalsoftware systems (Minimum SW Engineer Requirements based on software safety criticality)Specific Program andProject Requirements(w/Human Spaceflighttrack record) Partial Solution: Move “goodProgram and Project software engineering/developmentRequirements requirements” related to safety toGeneric Engineering Design NPR 7150.2ARequirement for safety criticalsoftware systems 24
    • Approach on requirements related 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.
    • Structured SW Classification definitions Structured SW Classification definitions:  Improved definition wording  Added examples  Made exclusions explicitClass B: Non-Human Space Rated Software Systems or Large Scale Aeronautics VehiclesSpace Systems*: Flight and ground software that must perform reliably to accomplish primary mission objectives, or major function(s) in Non-HumanSpace 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 ascommanding of the vehicle or asset, or2. required to achieve the primary mission objectives, or3. 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, or2. monitors and controls the cabin environment, or3. 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; thermalsystems; 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 dynamicsand 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/groundcollision 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 suppliedinstruments) or2. systems (e.g., simulators emulators, stimulators, facilities) used in testing Class B systems containing software in a development environment. 26
    • 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
    • Documented allocation and waiver/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 RequirementSection 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
    • 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
    • Overview1. NPD/NPR “Go To” Architecture for the Office of Chief Engineer2. Lessons Learned from previous NPR3. Update of NASA Software Engineering Requirements, NPR 7150.24. Future Work 30
    • FY10 Software Improvement Initiative 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
    • 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” paradigmNESC Request No: TI- 09-00546 32
    • 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