SCAPA Software Quality Assurance Guidance

1. SCAPA Software Quality Assurance Guidance Cliff Glantz and Jeremy Rishel Pacific Northwest National Laboratory cliff.glantz@pnl.gov 509-375-2166

2. Background Info 2 In 2005 DOE issued an Order and Guide establishing SQA requirements for safety software: DOE Order 414.1c DOE Guide 414.1-4

3. Consequence Assessment Models (CAM) and Safety Software 3 Consequence assessment models are safety software if used for: hazards assessment/safety planning purposes. emergency response purposes that provide a direct hazard control function (e.g., are used to formulate Protection Action Recommendations)

4. CAMs Used for Safety Software 4 The consequence assessment models SCAPA members use for safety software applications: are typically fast-response atmospheric dispersion and dose assessment models Use limited environmental data Use simple, conservative algorithms SQA is priority.

5. CAMS for Other Applications Use complex algorithms and typically have a lot of lines of code Address flows in complex terrain environments Require lots of environmental data Are frequently updated to incorporate new technologies Prioritize realism/technical accuracy and timely innovation as well as SQA 5

6. SQA Drivers Up to Now 6

7. What SCAPA Would Like 7

8. SCAPA�s SQA Guidance Document 8

9. Key Concepts in Our Guidance 9 Achieve an appropriate balance between technological development, timeliness, and SQA. Address all phases of the software lifecycle: Concept Requirements Design Implementation Test Installation, Checkout, & Acceptance Testing Operations Maintenance Retirement

10. Key Concepts (cont.) 10 Address all 10 SQA safety software work activities: Software Project Management and Quality Planning Software Risk Management Software Configuration Management Procurement and Supplier Management Software Requirements ID and Management Software Design and Implementation Software Safety Verification and Validation Problem Reporting and Corrective Action Training of Personnel.

11. Key Concepts (cont.) Set up a minimum expectations in the ten work activities. Allow more flexibility than permitted for safety software Expect the model developers/maintainers to evaluate the potential applications and perform additional SQA work (beyond the minimum expectations) as needed. Assign a relative priority rating for each category of SQA work activity. Model developers/maintainers are encouraged to use the priority rating to focus limited resources on SQA tasks that have higher priorities. 11

12. Key Concepts (cont.) 12

13. Key Concepts (cont.) 13 �Grandfather in� legacy software that has a proven track record in the DOE consequence assessment community Sets minimum requirements for a legacy code�s technical documentation, V&V testing, and problem reporting Require all updates/modifications to the legacy codes be conducted under the new SQA guidelines.

14. Status of Our SQA Guidance 14 A review draft was circulated to select SCAPA members and model owners in the summer of 2009 Near-final draft completed in Dec. 2009 Underwent internal PNNL review Submitted to NA-41 for review in Feb. 2010 Submitted to key DOE/HSS reviewers in April 2010 The near final draft will be discussed at the SCAPA CAM working group meeting on May 4th If remaining reviewer comments are received in May � we will have a final draft ready to roll in early June. Hope to publish on the SCAPA website before the end of June 2010 (I hope!)

15. Questions? Concerns? Contact: Clifford Glantz, SCAPA Chair Pacific Northwest National Laboratory� PO Box 999 902 Battelle Blvd. Richland, WA� 99352�� USA Tel: 509-375-2166 cliff.glantz@pnl.gov   15