Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
1. SCAPA Software Quality Assurance Guidance Cliff Glantz and Jeremy Rishel
Pacific Northwest National Laboratory
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
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:
Installation, Checkout, & Acceptance Testing
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
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 [email protected]