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
Experienced Software Engineer with a demonstrated history of working in the information technology and services industry. Skilled in ETL , Business Intelligence (BI), Oracle Data Integrator (ODI) , OBIEE , SQL , PLSQL and JAVA. Strong engineering professional with a Bachelor of Engineering (B.E.) focused in Information Technology from B.V.B.C.E.T..
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
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 “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