The document discusses an update to NASA's software engineering requirements in NPR 7150.2. It provides an overview of the topics to be covered, including the NPD/NPR architecture, lessons learned from the previous NPR, updates to NPR 7150.2, and future work. It then discusses lessons learned from developing the original NPR 7150.2, including forming a strong development team, selecting the target audience, understanding where the NPR fits in directives, setting inclusion/exclusion criteria early, and obtaining professional help. Finally, it summarizes some of the key changes between the original 2004 version and the updated 2009 version of NPR 7150.2, such as improved software classifications and addressing interface with

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 “Go To” 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 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
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 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 Engineering
Planned OCE NPR additions: NPR 7150.2
- PLM/PDM Software
Engineering
- Technical Standards
4

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

6. 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
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 “Go To” 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 from the
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 “Go To” 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 Development Team
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 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
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 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

13. Profile of NPR target
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/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 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: Get Professional 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 the Numbers
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 Requirements Mapping
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 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

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

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

26. Structured SW Classification definitions
 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 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

28. 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 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 “Go To” 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 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

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