kelly crumbley

33
NASA Software Engineering Procedural Requirements and related Policy PM Challenge 2010 February 9-10, 2010 John C. Kelly & Tim Crumbley Office of Chief Engineer Used with Permission

Upload: nasapmc

Post on 12-Jan-2015

13.396 views

Category:

Technology


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Kelly crumbley

NASA Software Engineering Procedural Requirements and related

Policy

PM Challenge 2010

February 9-10, 2010

John C. Kelly & Tim Crumbley Office of Chief Engineer

Used with Permission

Page 2: Kelly crumbley

2

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

Page 3: Kelly crumbley

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.

Page 4: Kelly crumbley

4

Office of Chief EngineerPrevious NPD/NPR Architecture

NPD 7120.4Program / Project Mgt

NPR 7120.5Space FltP/P Mgt

NPD 8070.6 Technical Standards.

NPD 2820.1Software

Policy

NPD 8010.2Use of SI

Metric

NPR 7120.7IT & Inst.P/P Mgt

NPR 7120.6Lesson Learned

NPR 7120.8R&T

P/P Mgt

NPR 7123.1Systems

Engineering

NPR 7150.2Software

Engineering

X X

Planned OCE NPR additions:- PLM/PDM- Technical Standards

Page 5: Kelly crumbley

Office of Chief Engineer“Go To Architecture”

5

NPD 7120.4Engineering& P/P Mgt

(in A-Suite)

NPR 7120.5Space FltP/P Mgt

NPR 71xx.xTechnical Standards

(Future)

NPR 7120.7IT & Inst.P/P Mgt

NPR 7120.6Lesson Learned

NPR 7120.8R&T

P/P Mgt

NPR 7123.1Systems

Engineering

NPR 7150.2Software

Engineering

NPR 71xx.xPLM/PDM

(Completed NODIS Review)

Page 6: Kelly crumbley

NPD 1000.0, NASA Governance and Strategic Management Handbook.NPD 1000.3, The NASA Organization.NPD 1000.5, Policy for NASA Acquisition.

1.3.1 Higher Agency-Level Requirements

NPD 7120.4, NASA Engineering and Program/Project Management Policy

1.3.2 Agency-Level Software Policies and Requirements

These NPDs and NPRs elaborate, tailor, and in some cases add requirements to the ones above to address the needs of major multi-Center projects, specific product lines, and specific focus areas.

1.3.3 Agency-Level Multi-Center and Product Line Requirements (non- software specific)

Center-Level Directives are developed by NASA Centers to document their local software policies, requirements, and procedures.

1.3.5 Center-Level Directives (related to software)

Contractors and subcontractors develop in-house policies and procedures to provide quality products and to fulfill the requirements passed down through a contract by a customer.

1.3.7 Contractor and Subcontractor Development

NASA Preferred Industry Software Standards and Guidebooks and NASA Software-Related Standards and Guidebooks are required when invoked by an NPD, NPR, Center-Level Directive, contract clause, specification, or statement of work.

1.3.4 NASA and Industry Software Standards and Guidebooks

Government in-house software development policies and procedures to provide quality products and to fulfill the requirements passed down by a project.

1.3.6 Government In-house Development

NPR 7120.5, NASA Space Flight Program and Project Management Requirements

NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements

NPR 7120.8, NASA Research and Technology Program and Project Management Requirements

NPR 7123.1, NASA Systems Engineering Processes and Requirements

NPR 7150.2,NASA Software Engineering Requirements

NPR 7120.6, Lessons LearnedProcess

Page 7: Kelly crumbley

7

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

Page 8: Kelly crumbley

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

Page 9: Kelly crumbley

9

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

Page 10: Kelly crumbley

10

NPR 7150.2A Development TeamAmes – Cyrus Chow

Joe CoughlanAPL – Steve PereiraDFRC – Keith SchweikhardGRC – Kevin CarmichaelGSFC – Sally Godfrey

Sue SekiraHQ OCE – John Kelly (co-lead)

Tim Crumbley (co-lead)Amy Morusiewicz (CSC)

HQ OSMA – Melissa BodeauMartha Wetherholt

IV&V – Lisa Montgomery

JPL – Scott MorganSteve Flanagan

JSC – Charlotte HudginsNick Lance

KSC – Brenda PennCaren Ensey

LaRC – Pat SchulerChuck Niles

MSFC – Pat BensonCathy White

NESC – Mike AguilarNSC – Karen MeinertSSC – Phillip HebertWallops – Donna Smith

Other Key Contributors:Ames - Silvano ColombanoHQ SMD – Rhoda HornsteinIV&V - Leigh GattoJPL - Bob Vargo

Dan Dvorak

JSC - Ken JenksLiz Strassner

LaRC - Michael Madden

Page 11: Kelly crumbley

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

Page 12: Kelly crumbley

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

Page 13: Kelly crumbley

13

Profile of NPR target audience

EarlyAdopters

ProgressiveUsers

SlowAdopters

EntrenchedResisters

Advances

Page 14: Kelly crumbley

14

Purpose of NPRs

EarlyAdopters

ProgressiveUsers

SlowAdopters

EntrenchedResisters

Advances

Shift NASA SW Community to the left 10 - 25%

Page 15: Kelly crumbley

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 ofa. NASA or contractors’ engineering line organizations, orb. 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 verified6. 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 SW9. Supports the software initiative and ongoing improvement activities10. Reasonable confidence that updates will not significantly impact current usage and consistent NPR 7150.2

Center direction in a negative manner11. 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).” –

IEEE Standard Glossary of Software Engineering Terminology. 1990

Page 16: Kelly crumbley

16

Top Center Issues/Recommendations for the Update of NPR 7150.2

Issue % of Centers*

NPR 7150.2A changes:

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 & NPR 7123

44% Improved harmonization with NPR 7123.1, NPR 7120.5, NPR 7120.7, NPR 7120.8, NASA-STD-8719.13, and NASA-STD-8739.8

4 Application to Contractors & Non-NASA Partners

44% Updated the P.2 Applicability and Scope section

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, Duplication, Typos, & Miscellaneous minor problems

44% Corrected duplications, typos, and miscellaneous minor problems, improved clarity, and consistencyUpdated the references and acronyms appendixesUpdated the definitions, primarily using industry standard IEEE definitions

* Issues were as reported out at the NASA SWG Face-to-Face meeting at NASA Plum Brook, August 2008.

Page 17: Kelly crumbley

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

Page 18: Kelly crumbley

Changes by the Numbers

2004 Total # of Requirements =

129

Added (11 total): SW Safety & IV&V Plans (when

applicable) = 3 Independent SW classification

assessment and safety critical determination by SMA = 2

SW safety engineering requirement = 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

2009 Total # of Requirements =

132

Deleted (8 total): Redundant with other documents

= 6 OBE Technical Authority

Requirement = 1 Mission Directorate reporting of

SW metrics to OCE = 1

18

Page 19: Kelly crumbley

NPR 7150.2A Requirements Mapping to Software Classifications

19

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

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

level directives.

SO - "Safety Only". Project is required to meet this

requirement to the extent necessary to satisfy safety

critical aspects of the software.

Page 20: Kelly crumbley

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

Innovations and Improvements incorporated in the updated NPR 7150.2A

Page 21: Kelly crumbley

21

Section of NPRRequirement Descriptor** SW

E #

Responsibility

Class A OR Class A and

Safety Critical Note 2

Class B OR Class B and

Safety Critical Note 2

Classes C thru E and

Safety Critical Note 2

Class C and NOT Safety

Critical

Class D and NOT Safety

Critical

Class E and NOT Safety

Critical Class F Class G Class H

Technical Authority for

NPR 7150.2 by Requirement

(Note 3)

HQ CE/

CSMAO

HQ CE/

CSMAO

HQ CE/

CSMAO

HQ CE/

CSMAO

Safety-critical software requirements 134 Project X P (Center) (see Note 7)

Center Director* (joint

Engineering TA & SMA TA if delegated)

X

(SO if D-E)

X X X (if Note 4 is

true) (if Note 4 is

true) f Note 4 is true

Peer Review/inspections of Software plans

"Shall" statements in this NPR 139 Project, Center X X X X X X X X X HQ CE Meeting "P(Center)" 140 Project, Center X X X X X X X X X HQ CE

Software Lifecycle Planning

Software safety plan 130 Project X X X

X (if Safety Critical)

X (if Safety Critical)

X (if Safety Critical)

IV&V Plan 131 IV&V Program

X (if selected foIV&V)

X (if selected forIV&V)

X (if selected foIV&V)

X (if selected foIV&V)

Independent Software Classification Assessment 132

SMA organization X X X X X X X X X

Software safety determination 133

Project & SMA organization X X X X X X X X X

Software Implementation

Static analysis 135 Project X X X Center Director*

Validation of soft 136 Project X X Center Director*

Software Peer Reviews/

Inspections 137 Project X XP (Center) +

SO P (Center) X (not OTS) P (Center) Center Director*

Software Documentation Requirements

Compliance

Software safety plan contents

138 Project X HQ CE/CSMAOX X X (if Safety Critical)

X (if Safety Critical)

X (if Safety Critical)

New requirements added into NPR 7150.2A

Page 22: Kelly crumbley

New requirements added into NPR 7150.2A

22

Section of NPRRequirement Descriptor** SW

E #

Responsibility

Class A OR Class A and

Safety Critical Note 2

Class B OR Class B and

Safety Critical Note 2

Classes C thru E and

Safety Critical Note 2

Class C and NOT Safety

Critical

Class D and NOT Safety

Critical

Class E and NOT Safety

Critical Class F Class G Class H

Technical Authority for

NPR 7150.2 by Requirement

(Note 3)

HQ CE/

CSMAO

HQ CE/

CSMAO

HQ CE/

CSMAO

HQ CE/

CSMAO

Safety-critical software requirements 134 Project X P (Center) (see Note 7)

Center Director* (joint

Engineering TA & SMA TA if delegated)

X

(SO if D-E)

X X X (if Note 4 is

true) (if Note 4 is

true) f Note 4 is true

Peer Review/inspections of Software plans

"Shall" statements in this NPR 139 Project, Center X X X X X X X X X HQ CE Meeting "P(Center)" 140 Project, Center X X X X X X X X X HQ CE

Software Lifecycle Planning

Software safety plan 130 Project X X X

X (if Safety Critical)

X (if Safety Critical)

X (if Safety Critical)

IV&V Plan 131 IV&V Program

X (if selected foIV&V)

X (if selected forIV&V)

X (if selected foIV&V)

X (if selected foIV&V)

Independent Software Classification Assessment 132

SMA organization X X X X X X X X X

Software safety determination 133

Project & SMA organization X X X X X X X X X

Software Implementation

Static analysis 135 Project X X X Center Director*

Validation of soft 136 Project X X Center Director*

Software Peer Reviews/

Inspections 137 Project X XP (Center) +

SO P (Center) X (not OTS) P (Center) Center Director*

Software Documentation Requirements

Compliance

Software safety plan contents

138 Project X HQ CE/CSMAOX X X (if Safety Critical)

X (if Safety Critical)

X (if Safety Critical)

The new NPR Software Engineering requirements are focused on improving software safety, software verification and clarifying

compliance. These changes are targeted to improving

mission success for software projects

Page 23: Kelly crumbley

Problem: Redundant and distributed “good software engineering/development requirements” related to safety between NPR 7150.2, NASA STD 8737.8 (SW Assurance), NASA STD 8719.13 (SW Safety), and Program/Project Requirements

23

Approach on requirements related to the developmental aspects of safety critical software

Phase 02004 – 2008 (SW engineering requirements related to safety)

NPR 7150.2, SW Engineering

Minimum SW Engineer Requirements base on SW Classifications A - H. Mute on safety related requirements*

NASA SW Assurance and Safety Standards

Requirements for identifying and applying SW Assurance methods

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)

Program and Project Requirements

Generic Engineering Design Requirement for safety critical software systems

* Only safety requirement was SWE-023 which invokes NASA STD 8719.13 for safety critical software

Page 24: Kelly crumbley

Partial Solution: Move “good software engineering/development requirements” related to safety to NPR 7150.2A

24

Approach on requirements related to the developmental aspects of safety critical software

Phase 12009 (NPR 7150.2A update completed)

NASA SW Assurance and Safety Standards

Requirements for identifying and applying SW Assurance methods

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)

Program and Project Requirements

Generic Engineering Design Requirement for safety critical software systems

NPR 7150.2.A, SW Engineering

Minimum SW Engineer Requirements base on SW Classifications A – H andsoftware safety criticality

Generic Engineering Design Requirement for safety critical software systems

Page 25: Kelly crumbley

Ultimate Solution: NPR 7150.2A becomes the consolidated home for “good software engineering/development requirements” related to safety

25

Approach on requirements related to the developmental aspects of safety critical software

Phase 22010 (NASA STD 8719.13 and STD 8739.8 updates)

NASA SW Assurance and Safety Standards

Requirements for identifying and applying SW Assurance methods

Requirements to implement a systematic approach for software safety*

(Minimum SW Engineer Requirements based on software safety criticality)Replace with pointer to NPR 7150.2 A

Specific Program and Project Requirements (w/Human Spaceflight track record)

Program and Project Requirements

Generic Engineering Design Requirement for safety critical software systemsReplace with pointer to NPR 7150.2A on future programs and projects

NPR 7150.2.A, SW Engineering

Minimum SW Engineer Requirements base on SW Classifications A – H andsoftware safety criticality

Generic Engineering Design Requirement for safety critical software systems

* Safety identification, assurance, risk & hazards analysis, FMEA,… remain in NASA STD 8719.13.

Page 26: Kelly crumbley

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 VehiclesSpace 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, 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, 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) or2. systems (e.g., simulators emulators, stimulators, facilities) used in testing Class B systems containing software in a development environment.

26

Page 27: Kelly crumbley

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.

27

Waiver/deviation authority

Center - 72%HQ - 28%

Allocation of requirementsHQ – 8Centers– 14Project s & SMA – 110

Page 28: Kelly crumbley

Documented allocation and waiver/deviation authority for each requirement

Documented allocation and waiver/deviation authority for each requirement

28

Section of NPRRequirement Descriptor** S

WE

#

Responsibility

Class A OR Class A and

Safety Critical Note 2

Class B OR Class B and

Safety Critical Note 2

Classes C thru E and

Safety Critical Note 2

Class C and NOT Safety

Critical

Class D and NOT Safety

Critical

Class E and NOT Safety

Critical Class F Class G Class H

Technical Authority for

NPR 7150.2 by Requirement

(Note 3)

Software plans 13 Project X X X X P (Center) P (Center) X P (Center) HQ CEExecute 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*Software classification 20 Project X X X X X X X X X HQ CE

SW Life Cycle Planning

Page 29: Kelly crumbley

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

Page 30: Kelly crumbley

30

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

Page 31: Kelly crumbley

* Software Engineering portions or contributions

Policy & ProceduralRequirements

Processes Technology

Ongoing • NPD 7120.4* update• NPR 7150.2A, SW Engineering

Requirements update - completed• OCE Survey* (5 Centers + HQ)

• CMMI Appraisals• NASA & Center

Process Asset Libraries (PALs)

• SW Measurement

• Tool Shed• Sys & SW Journal• Reviewers and Rep. to OSMA’s

SW Assurance Research Program (SARP)*

New for2010

• SW Engr. Handbook (Electronic)• Center Compliance with new

NPR 7150.2A• OSMA’s update to NASA Safety

and Assurance standards• Representative to help develop

new Programmable Logic Devices Policy/Std/HB*

• Center processesupdated for consistency with new NPR 7150.2A

• Update SW Technology Strategy for 2011 and beyond

• Interface to SW Architecture Review Board effort (NESC)*

• Interface to Multi-Core Flight computing*

• Interface to SW Engineering 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*

FY10 Software Improvement InitiativeStructure

Page 32: Kelly crumbley

NESC Request No: TI- 09-00546 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

Page 33: Kelly crumbley

NESC Request No: TI- 09-00546

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.

33

Programmable Logic Devices (Complex Electronics)

NESC Report Recommendations