JLab Software Assurance Program A Risk Based Approach to Software Management.

Slides:



Advertisements
Similar presentations
How Will it Help Me Do My Job?
Advertisements

Module N° 4 – ICAO SSP framework
Department of Energy Quality Assurance Updates Frank Russo Deputy Assistant Secretary Office of Corporate Performance Assessment Energy & Environmental.
CIP Cyber Security – Security Management Controls
Safety Software QA at BNL’s Collider-Accelerator Department (C-AD) Accelerator Safety Workshop E. Lessard Collider-Accelerator Department August 12-14,
ANSI/ASQ E Overview Gary L. Johnson U.S. EPA
Chapter 4 Quality Assurance in Context
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
4/30/20151 Quality Assurance Overview. 4/30/20152 Quality Assurance System Overview FY 04/05- new Quality Assurance tools implemented, taking into consideration.
Auditing Concepts.
DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Phase III – Validation Thomas Howard Chris Pierce.
1 Independent Verification and Validation Current Status, Challenges, and Research Opportunities Dan McCaugherty IV&V Program Manager Titan Systems Corporation.
Project Change Management
Stepan Potiyenko ISS Sr.SW Developer.
COSO Framework A company should include IT in all five COSO components: –Control Environment –Risk Assessment –Control activities –Information and communication.
SQM - 1DCS - ANULECTURE Software Quality Management Software Quality Management Processes V & V of Critical Software & Systems Ian Hirst.
10.5 Report Performance The process of collecting and distributing performance information, including status reports, progress measurements and forecasts.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
COMP8130 and 4130Adrian Marshall 8130 and 4130 Test Management Adrian Marshall.
Breakout Group 2: Software Quality Assurance Outcome 8/18/10 1.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Systems Engineering Approach to MPS Risk Management Kelly Mahoney Presented at the Workshop for Machine Protection in Linear Accelerators.
Software Engineering Institute Capability Maturity Model (CMM)
CSSE 375 Software Construction and Evolution: Configuration Management
Chapter 2: Overview of Essentials ISE 443 / ETM 543 Fall 2013.
INTEGRATION OF QA/ISM J. R. Yanek Chair, EFCOG ISM Working Group April 13, 2000.
ISA 562 Internet Security Theory & Practice
QA Requirements for DOE Accelerator Safety System Software K. Mahoney Group Leader, Safety Systems TJNAF Presented at the 2008 DOE Accelerator Safety Workshop.
NIST Special Publication Revision 1
Roles and Responsibilities
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
ETICS2 All Hands Meeting VEGA GmbH INFSOM-RI Uwe Mueller-Wilm Palermo, Oct ETICS Service Management Framework Business Objectives and “Best.
Protecting the Public, Astronauts and Pilots, the NASA Workforce, and High-Value Equipment and Property Mission Success Starts With Safety Believe it or.
Preventing events “…that could not only hurt someone, but hurt someone you know and … could have a dramatic consequence on all of us “ SO’K Mission Success.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
SacProNet An Overview of Project Management Techniques.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Breakout Group 2: Software Quality Assurance Objectives and Goals 8/18/10 1.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
Georgia Institute of Technology CS 4320 Fall 2003.
1 FRENCH PROPOSAL FOR ESARR6 1 - BACKGROUND - 15/02/00 : Kick-off meeting, Presentation of the CAA/SRG input (SW01), Request from the chairman to comment.
Enterprise Risk Management Chapter One Prepared by: Raval, Fichadia Raval Fichadia John Wiley & Sons, Inc
July LEReC Review July 2014 Low Energy RHIC electron Cooling Edward T. Lessard ESHQ.
Presented to: By: Date: Federal Aviation Administration Quality and Standards Team (QST) In-Service Management Gold Standard ATO Acquisition Practices.
Integrating EM QA Performance Metrics with Performance Analysis Processes August 26, 2009 Robert Hinds, Manager, Quality Assurance Engineering & Greg Peterson,
Principles of Computer Security: CompTIA Security + ® and Beyond, Third Edition © 2012 Principles of Computer Security: CompTIA Security+ ® and Beyond,
1 Technology Infusion of the Software Developer’s Assistant (SDA) into the MOD Software Development Process NASA/JSC/MOD/Brian O’Hagan 2008 Software Assurance.
SRR and PDR Charter & Review Team Linda Pacini (GSFC) Review Chair.
Completing the Loop: Linking Software Features to Failures 20 July 2004 Copyright © 2004, Mountain State Information Systems, Inc. All rights reserved.
Dave Passarello DOE Accelerator Safety Workshop August , 2009 Software QA Requirements Breakout Session – Key Points.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Disaster Recovery Planning (DRP) DRP: The definition of business processes, their infrastructure supports and tolerances to interruptions, and formulation.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
1 Security Architecture and Designs  Security Architecture Description and benefits  Definition of Trusted Computing Base (TCB)  System level and Enterprise.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
Internal Audit Quality Assessment Guide
IV&V Facility 7/28/20041 IV&V in NASA Pre-Solicitation Conference/ Industry Day NASA IV&V FACILITY July 28, 2004.
Dr. Ir. Yeffry Handoko Putra
Quality Management System Deliverable Software 9115 revision A Key changes presentation IAQG 9115 Team March 2017.
Auditing Concepts.
DNP Initiative ENG-003 Standard Design Process Overview Configuration Management Benchmarking Group June 12, 2017.
Software Project Configuration Management
Software Engineering (CSI 321)
JSA Enhancements SIS competencies May, 2012.
Identify the Risk of Not Doing BA
Presented to the NASA OSMA SAS ‘01
Project Charter <Project Name>
Use of CMMI in an Acquisition Context Using CMMI for Process Improvement at USAF Space and Missile Systems Center (SMC) Dr. Jack R. Ferguson
DOE Review of the LCLS Project October 2006
Presentation transcript:

JLab Software Assurance Program A Risk Based Approach to Software Management

Outline Software Assurance vs. Software Quality Assurance QA Order Requirements Processes that address software assurance JLab’s SW Assurance Effort Risk Based Model Assessment Method Preliminary Results Path Forward 8/18/20102

DOE 414.1C Applies to ALL Software activities Ten Criteria for Safety SW QA Program Requirements flow-down through CRD QA Order 414.1C QA Order 414.1C QA PLAN CORRECTIVE ACTION MANAGEMENT SUSPECT/COUNT ERFEIT ITEM PROCESS (SAFETY) SOFTWARE QUALITY SOFTWARE ASSURANCE PROCEDURE SOFTWARE ASSURANCE PROCEDURE GENERAL REQUIREMENTS GENERAL REQUIREMENTS 8/18/20103

JLab Software Assurance Procedure Implementation of Requirements of Quality Assurance Plan Implements a process for identifying and classifying the impact SW may have on multiple subject areas, including safety Adaptable to all software activities important to facility mission and goals Implements consistent tiered approach 8/18/20104

Software Quality Assurance  Software Assurance NASA-STD (w/Change 1) July 28, 2004 “Software assurance consists of the following disciplines: Software Quality –Software Quality Assurance –Software Quality Control –Software Quality Engineering Software Safety Software Reliability Software Verification and Validation (V&V) Independent Verification and Validation (IV&V)” NASA-GB NASA Software Safety Guidebook. Implementation guidance for high consequence software 8/18/2010 5

JLab Process SW Assurance team chartered by CIO –Representatives from across site: Scientific –Experimental –Theoretical –Computing Business Controls Cyber Security HR Safety Systems 8/18/20106

JLab SWAP - Table of Contents 1Purpose 1.1Structured Approach 2Scope 2.1Exemptions 3Responsibilities 4Software Control Procedure 4.1Software Risk Assessment Process Steps & Expectations 4.1.1Software critical to JLab safety, operations, and mission 4.1.2Software important to JLab safety, operations, and mission 4.1.3Software Risk Assessment Assumptions: 4.1.4Software Risk Assessment Tool 8/18/20107

Table of Contents - Continued 4. 2Software Assurance 4.2.1Graded Approach 4.2.2Software Assurance Program Requirements Acquirer Software Assurance Basic Requirements for Software Assurance Processes: Software Lifecycle Software Quality Competence Sustainability Configuration Management Assessment 4.3Metrics and Continuous Improvement 5.0DEFINITIONS 6.0REFERENCES 7.0REVISION SUMMARY 8/18/20108

JLab SW Assurance Procedure Clarifies scope: –Applies to all projects, programs, facilities, and activities that may impact JLab mission and goals –Applies to all software developed, or modified for use at JLab. Compliments Cyber Security Program –Reflects SW Enclaves –Applies to security software configuration items only where ineffective security software controls may directly affect operations and safety –Cyber Security Risk Assessment incorporated in to overall risk assessment 8/18/20109

JLab SW Assurance Defines SW Risk Assessment Procedure: –Identifies pre- and post-mitigation Risk –Applicable to ALL SW within scope of process Defines Requirements for Owner Organization SW –Requirements for lifecycle model –Requirements for 8/18/201010

Structured Approach Identify important JLab software configuration items and activities Identify roles and responsibilities for software control activities within the context of this procedure Perform a software risk assessment on applicable configuration items Apply a risk-based graded approach to software assurance activities Apply a value added continuous improvement process to the software assurance processes 8/18/201011

Exemptions “This procedure does not apply to unmodified general purpose computing software, unmodified enterprise software, and general purpose desk-top software managed under the IT/CIO Division. Examples include office productivity software, public web pages, and LAN/WAN networking software.” 8/18/201012

Roles and Responsibilities Defines roles, responsibilities, and authority for –COO –CIO –ESH&Q AD –Division Management –Line Management –Software Owner –Oversight committees 8/18/201013

Scope internal software development software used to collect and manage data startup and configuration scripts incorporation of open source software modified off the shelf (MOTS) software used to design, analyze, or control safety or mission essential aspects of JLab operations commercial off the shelf (COTS) software used to design, analyze, or control safety or mission essential aspects of JLab operations programs and firmware for monitoring or control, including IOCs and PLCs modifiable embedded software and firmware including PICs and PC104 type SBCs programs and development software for field programmable integrated circuits such as Field Programmable Gate Arrays Other software as defined by the JLab Chief Information Officer

SW Risk Assessment Software is scored (1-5) in each of six areas of impact –Direct Risk of Financial Loss –Direct Risk of Loss of Tangible Equipment/Property –Direct Risk of Harm to People –Direct Risk of Harm to the Environment –Direct Risk of Loss of Continuity of Operations/Organization/Mission –Direct Risk of Enforcement Action Scoring is reviewed at both the individual and cumulative level

Data Collection SW Application/Information Example Worst Credible Error/Event/IncidentOwnerType Assigned JLab Cyber Security LevelPlatform Application, information, or SW configuration item Briefly describe event and consequences of SW error Organization that owns the performance/requirements for the application Major SW application type HW/SW platform running the application Augerlost productivity (physics "farm")IT - SCIJavaLowLinux Scoring Direct Risk of Financial Loss, Includes Cost of Unplanned Labor Direct Risk of Loss of Tangible Equipment/Material Direct Risk of Harm to People Direct Risk of Harm to the Environment Direct Risk of Loss of Continuity of Operations/ Organization Mission Direct Risk of Enforcement Action Number from 0 to 5 (See Table- Definitions) Analysis Recommendations TotalPre MitigationSW QA Mitigation(s)Post Mitigation Risk Acceptance SW QA practices used for this application Risk Acceptance 5 Tolerable Testing prior to release; testing by users Acceptable

Types of Software Assessed –Lattice QCD Modeling –Experiment Data Management –MIS Accounting –MIS Procurement –Corrective Action Tracking System –Facilities Work Order System –Travel –-Timesheets –Facilities Work Order System –Accelerator Physics Model –Machine Protection –Personnel Safety System PLC Firmware PLC Program –Radiation Instrumentation –Beam Position Monitor

Risk Acceptance Criteria – Pre Mitigation

SW Assurance as a Mitigation Each Owning Organization responsible for tailoring requirements in to their own SA program Procedure provides consensus standard references for generally accepted good practice Procedure provides references for incorporation in to organization’s individual process

Lifecycle Model Requirements

Metrics Recommended for Acceptable and Tolerable Risk Required for Intolerable and Unacceptable Risk Assessments go back to central repository for analysis Allows comparison of mitigations vs. claimed effectiveness Refers to existing SW metric processes Guidance refers to CMMI process

–Pilot project complete –In process of implementing procedure lab wide –Feedback (mostly) positive –Expanding Risk Assessment data Status

Conclusions JLab is implementing a risk based software assurance process Consensus based procedure with buy-in from all SW enclaves Tools, e.g. risk assessment spreadsheet, are integrated in to the process Provides minimum requirements for SW lifecycle Incorporates resources and guidance for application Process incorporates metrics