Docstoc

Software Quality Assurance_1_

Document Sample
Software Quality Assurance_1_ Powered By Docstoc
					              Breakout Group 2:
          Software Quality Assurance
               Objectives and Goals



8/18/10                                1
                                                                Why Worry?




8/18/10                                                                      2
          Adapted from Computer Technik Magazine. Ritsch und Renn
                          Objectives
      • Review 2009 Workshop Outcome.

      • Three talks on SW QA activities at accelerator labs.

      • Identify SW Assurance activities for high impact
        operations at Accelerator Facilities.

      • Recommendations for incorporating value added SW
        Assurance activities into a revised ASO guidance
        document.

8/18/10                                                        3
                     2009 ASW SQA Session
      • M. Cole. “DOE Accelerator Software and Quality Assurance”
          – Injury, property damage, or program interruption are all credibly possible [outcomes] if
            software fails in the operation of an accelerator facility
          – 414.1-4 guidance is intended for nuclear facilities
          – Address the synergism between safety, reliability, and quality
          – Address the integration of the software with hardware and humans
          – One may select a consensus standard that addresses the 10 criteria of 414.1C


      • A. Etkin. “Draft DOE Standard Application of Safety Instrumented Systems
        Used at DOE Non-Reactor Nuclear Facilities”
          – Draft DOE Standard for use of programmable electronics in non-reactor nuclear safety
            systems
          – Consolidation of information for SS & SC safety instrumentation and
          – Safety Significant material Based on ANSI/ISAS84.01-2004
          – Adds Alarm Functions, Fire Protection Systems, Systems that monitor start-up

8/18/10                                                                                                4
                                2009 Recommendations
•    SQA for software identified in ACE
       •   Program shall be developed using 414.1-4 as guidance or be based on a consensus standard
       •   Authority needs to be established to identify/approve equivalent controls/processes when
           requirements can not be implemented as written in order/standards

•    SQA for other software
      •      Should be risk based (Graded Approach)
      •      Specify minimum requirements, e.g. documented design criteria, configuration
             management, testing protocols
      •      Linked to the 10 basic QA criteria in 414.1C

Next revision of QA Order > 414.1D Addresses SQA in non-nuclear facilities
(current status - comment resolution phase)


Suggested Action Plan:
Assess implemented SQA program against requirements in revised order.




                                                                                                      5
                                                                           5
          Ten SQA Work Activities from 414.1C.5d
      (1) Software project management and quality planning
      (2) Software risk management
      (3) Software configuration management
      (4) Procurement and supplier management
      (5) Software requirements identification and management
      (6) Software design and implementation
      (7) Software safety
      (8) Verification and validation
      (9) Problem reporting and corrective action
      (10) Training of personnel in the design, development, use,
         and evaluation of safety software

8/18/10                                                             6
                              SQA for All
      SQASG-TP-10-01-REV. 0 (January, 2010)
      “Systematic Approach to Implementing the Quality
        Requirements of DOE O 414.1C for Software”
          – Safety software, and
          – All other software
             •   Business
             •   Science
             •   Enterprise
             •   Controls…


8/18/10                                                  7
              Software Quality Assurance 
                   Software Assurance

          NASA-STD-8739.8 (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)”
8/18/10                                                                8
                                    New Risks
      •   August 2006 – Network storm freezes PLC based
          control at Brown’s Ferry. Non-safety control. (NRC
          INFORMATION NOTICE: 2007-15)

      •   June 2010 – Triple redundant processor has
          systematic software error. - Fail Safe. Affected
          Safety Significant safety computer at SRS (Rockwell
          Product Notice - 2010-06-002 – 8110)

      •   July 2010 – Stuxnet Trojan used Windows
          vulnerability to infect Siemens PC based software.
          Transferred through USB stick. No damage
          reported. (Siemens Support Entry ID:43876783)

      •   August 2010 – VxWorks (EPICS real time operating
          system) security vulnerability identified by DHS.
          (CERT Advisory ICSA-10-214-01)
8/18/10                                                         9
                         New Help


      • Control Systems Security Program (CSSP)
      cssp@hq.dhs.gov.




8/18/10                                           1
                                                  0
          Alignment with the Safety Order
      DOE Responsibilities                        Major Constituents of the CRD
      •   Facility operations meet DOE mission    •   Accelerator Safety Envelope (ASE)
          and operational objectives                   –   Bounding conditions for safe operations
                                                  •   Safety Assessment Document (SAD)
      •   Operations comply with safety
                                                       –   Describe Engineered and Administrative
          program and objectives                           Controls
      •   Ensure facility safety program          •   Unidentified Safety Issue (USI)
          incorporates:                                –   Configuration Management
           – ASE and SAD                          •   Accelerator Readiness Review (ARR)
           – clearly defined roles and                 –   Contractor Assurance Process
             responsibilities                          –   Configuration Management Program
           – a configuration management process        –   Administrative Processes Related to
                                                           Accelerator Safety
           – readiness review
           – inventory of exempt accelerators



8/18/10                                                                                              1
                                                                                                     1
                 Guidance Content
      Discussion forum




8/18/10                             1
                                    2
                       Outcome
      Scott has asked that the breakout sessions
        produce a set of “outcomes” from the
        breakout sessions.
      • Review
      • Recommended Action Items
      • Recommendations to DOE/Contractors


8/18/10                                            1
                                                   3

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:5/3/2013
language:English
pages:13