PROCEDURE SOFTWARE MANA GEMENT AP-SI.I Q Revision 5 …

Office of Civilian Radioactive Waste Management QA: QA-

PROCEDURE

SOFTWARE MANA GEMENT

AP-SI.I Q

Revision 5 ICN 0

Effective Date: 04/23/2003

Preparer:

Approval:

D.R. TommelaChief Information Officer

ti I OaDate-

Date

-jg / y ,, r

/

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. 1 Q/Rev. 5/ICN 0 Page: 2of57

CHANGE HISTORY

RevisionNumber

0

1

InterimChange No.

EffectiveDate

0 02/15/1999

0 05/05/1999

Description of Change

Initial issue to consolidate software configurationmanagement control within the Office of CivilianRadioactive Waste Management program and tocreate a centralized software library for software thatis subject to the Quality Assurance Requirements andDescription, DOE/RW-0333P. These items wereidentified as recommendations in Corrective ActionRequest LVMO98-C-006. This document replacesQAP-SI-3, Software Configuration Management;LANLYMP-03.20, Software ConfigurationManagement; YMP-LBNL- QIP-SI. 1, SoftwareConfiguration Management; portions of 033-YMP-QP 3.2, Software Quality Assurance; portions ofQAIP 19.1, Software Quality AssuranceRequirements; and portions of YMP-USGS-QMP-3.03, Software.

Major revision to add a standardized software lifecycle development process for Office of CivilianRadioactive Waste Management softwaredevelopment activities controlled by the requirementsof the Quality Assurance Requirements andDescription, DOE/RW-0333P. To reflect thisadditional scope, the title of the procedure is beingchanged from Software Configuration Managementto Software Management. This revision alsoaddresses a consistent software planning process inpreparation for the software life cycle. Thisprocedure revision supersedes the followingprocedures that currently control Office of CivilianRadioactive Waste Management specific quality-affecting software life cycle management: QAP-SI-0,Computer Software Qualification; LANLYMP-QP-03.21, Software Life Cycle; YMP-LBNL-QIP-SI.0,Computer Software Qualification; 033-YMP-QP 3.2,Software Quality Assurance; QAIP 19-1, SoftwareQuality Assurance Requirements; and YMP-USGS-QMP-3.03, Software.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. I /Rev. 5/ICN 0 Pave: 3 of 57

CHANGE HISTORY (Continued)

RevisionNumber

2

2

Interim EffectiveChange No. Date

0 10/15/1999

1 10/29/1999

2 12/15/1999


Complete revision to integrate the SoftwareManagement Process with the new suite ofprocedures developed out of the Process Validationand Reengineering activity. Section added to addresshow to handle discovery of software previously usedon the program whose history is unknown or ofindeterminate pedigree. A new process for handlingsoftware routines and macros has been added. Singleuser software steps added to track user informationfor software where the developer will be the only user(a condition for closure of Deficiency ReportLVMO-98-D-030). A new independent verificationprocess has been implemented to replace theQAP 6.2, Document Review, review process.References have been updated.

This ICN changes Section 5.11 allowing for the useof an impact evaluation for discovered software thatwas acquired/developed under previous qualityprocedures and will be baselined and retired fromuse.

This ICN deletes all references to AP-3.15Q. Theinternal referencing within this procedure of softwaredefining life cycle documentation was never intendedto fall under AP-3.15Q. AP-3.15Q is concerned withmaking links between technical products and inputsto those products so that if the inputs change theresulting "where used" documents can be identified.The ICN also reflects the ownership change from theOffice of Project Execution to Office of InformationManagement.

2

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. 1 /Rev. 5/ICN 0 Page: 4 of 57


RevisionNumber

2

2

Interim EffectiveChange No. Date

3 02/07/2000

4 02/22/2000

0 04/01/2001


This ICN incorporates all changes to bring AP-SI. 1Qinto compliance with QARD, Rev 9 changes. TheICN also provides an additional section coveringsoftware operational considerations, Software use,editorial changes to provide clarification andreadability and assigns responsibility to the softwareCM organization for compilation and submission ofall appropriate records associated with softwaremanagement. Control Point 1 and 2 reviews will beaccomplished by Information Technology staffeffective with this ICN.

This ICN inserts editorial changes not inserted in thefinal version of Rev 2, ICN 3.

Complete revision to incorporate an adaptiveSoftware Life Cycle Methodology, including aSoftware Activity Evaluation and Categorizationprocess, and adding applicable aspects of theSoftware Engineering Institute Capability MaturityModel (CMM). Incorporates Rev 2, ICN 4, ECN 1 tothis procedure.

3

3 1 05/09/2001

1, ECN 1 06/28/2001

ICN to reformat the Software CategorizationChecklist as an Automated Forms System form.

ECN 1 issued to extend the date in Subsection 5.10 tosix months after the Site Recommendationsubmission to the President.

3

3 2 10/25/2001 Procedure revised to incorporate ECN 1 changes toSubsection 5.10 and accepted Document ActionRequests D796, D807, D870, D881, D898, D947, andD1030.

3 2, ECN 1 10/25/2001 ECN 1 issued to change Paragraph 2.1.4 back toRevision 3, ICN 1, ECN 1 terminology.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.lO/Rev. 5/ICN 0 Pa2e: 5 of 57


RevisionNumber

3

InterimChange No.

EffectiveDate Description of Change

3 12/21/2001 ICN incorporates ECN 1 changes to Paragraph 2.1.4and reflects the ownership and accountability changefrom the Office of Civilian Radioactive WasteManagement Chief Information Officer to BechtelSAIC Company, LLC Chief Information Officer.

3

4

4 05/17/2002

0 01/13/2003

0 04/23/2003

ICN clarifies process to follow when a user'soperating system is upgraded (Sections 5.7 and 5.8,and Attachment 8), in response to DAR-D3063. Allnotes in the procedure have been removed to supportclosure of YMSCO-01 -D-064.

Complete revision to address issues raised byBSC-01-C-002 and Management ImprovementInitiative regarding the addition of supplementalprocedures for software management. Also includessoftware categorization process changes and theaddition of software independent verification andvalidation.

Complete revision to address consolidation ofLevel A software activities into AP-SI.2Q,Qualification of Level A Software; rework processflows to address organizational hand-off issues, roleresponsibilities, and provide clearer definition ofwork products and forms; remove most uses ofAP-2.14Q, Review of Technical Products and Data,for IV&V comment resolution activities; and addressthe following Document Action Requests: D7127,D6447, D6449, D6451, D6452, D6487, D6488,D6490, D6508, D6509, D6510, D6511, D6512,D6513, D6927, and D6970.

5

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.1O/Rev. 5/ICN 0 Page: 6 of 57

1.0 PURPOSE

This procedure, with AP-SI.2Q, Qualification of Level A Software, and AP-SI.3Q, SoftwareIndependent Verification and Validation, establishes the processes, identifies the roles, anddefines the responsibilities for management of software to be used in support ofquality-affecting activities. The processes include the use of existing qualified software,software categorization and planning, qualification of acquired and developed software,independent verification and validation (IV&V), operations and maintenance, baselinechange control, software problem reporting and resolution, and continuous operationsoftware. This procedure provides for a centralized control of quality-affecting softwareand qualification documentation that is subject to the Quality Assurance Requirements andDescription (QARD), DOE/RW-0333P, and, as such, in conjunction with AP-SI.2Q andAP-SI.3Q, shall be the Software Quality Assurance Plan for software management.

Supplemental internal organizational controls are allowed and encouraged under thisprocedure.

2.0 APPLICABILITY

This procedure applies to software that is subject to the QARD; individuals within BechtelSAIC Company, LLC; the National Laboratories; the U.S. Geological Survey; BechtelSAIC Company, LLC contractors; and other contractors who acquire, develop, control, ormanage software, or who use software in the Office of Civilian Radioactive WasteManagement (OCRWM) Program.

Applications developed using non-standard functions in commercial off-the-shelf software(see Subsection 3.6) and that are directly used for quality-affecting work shall be qualifiedin accordance with this procedure.

Qualified software in the centralized baseline, as of the effective date of this procedure,shall be considered acceptable and part of the established baseline until the software ischanged.

In-process software development activities that have not reached a Control Point review onthe effective date of this procedure shall transition to meet the requirements of thisprocedure. Software that is in or past a Control Point review upon the date that thisrevision becomes effective may complete the review process in accordance with theprevious revision of this procedure.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. IQ/Rev. 5/lCN 0 Page: 7 of 57

2.1 SOFTWARE NOT REQUIRED TO BE QUALIFIED UNDER THIS PROCEDURE

The following types of support software, when used for quality-affecting work, areconsidered to be controlled under the Software Configuration Management (SCM) system,but are not required to be qualified or documented under this procedure, except as noted:

2.1.1 Software such as operating systems, system utilities, compilers and their associatedlibraries, word processors, spreadsheets, database managers, e-mail, and othertypes of automated office support systems.

2.1.2 Software used solely for visual display or graphical representation of data used in atechnical product, or that controls data acquisition equipment but does not performa calculation or obtain a solution, that is checked and approved in accordance withapplicable procedures, and meets stated acceptance criteria.

2.1.3 Computer aided design systems generating design drawings that are checked andapproved in accordance with AP-3.24Q, Drawings.

2.1.4 Acquired software that is embedded in the equipment or integral to the operations,maintenance, or calibration of measuring and test equipment, and that has not beendeveloped or modified, and is tested and controlled in accordance with AP-12.1Q,Control of Measuring and Test Equipment and Calibration Standards.

2.1.5 Software used in scoping and bounding determinations, feasibility studies,prototype methodology development, or similar activities prior to actual use inquality-affecting activities. Prior to actual use in quality-affecting activities, suchsoftware shall be qualified in accordance with this procedure. Technical productsdeveloped using this type of software cannot be issued or checked until thesoftware has been qualified, issued by SCM, final runs made using the qualifiedsoftware.

2.1.6 Solutions to a calculation or analysis package used to support a technical product(as defined in Subsection 3.38), written using the standard functions of commercialoff-the-shelf software programs (e.g., EXCEL, MATHCAD). The results shall notbe dependent on the software program used (e.g., the same result could be obtainedwhether Excel or another spreadsheet was used). The solution must bedocumented in sufficient detail in a technical product to allow an independentreviewer to reproduce or verify the results by visual inspection or hand calculationwithout recourse to the originator.

2.2 SOFTWARE REQUIRED TO BE QUALIFIED UNDER THIS PROCEDURE

All other software used for quality-affecting activities shall be qualified and documented inaccordance with this procedure.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. I Q/Rev. 5/ICN 0 Page: 8 of 57

3.0 DEFINITIONS

3.1 Acquired Software-Software that was neither developed nor modified by an OCRWM-affected organization, and was obtained from a source outside OCRWM.

3.2 Affected Organizations-An organization performing Program work subject to QARDrequirements whose organizational relationships are defined in OCRWM Programdocuments. (QARD)

3.3 Application (Software)-l) Software designed to fulfill the specific needs of a user.2) Software that are written where the user prescribes one or more instructions to generatedata, manipulate data, or perform calculations. (QARD)

3.4 Baselined Software-An individual software component (e.g., requirements document[RD], design document, source code, etc.) that is under configuration management control.(QARD)

3.5 Baselined Software Changes-Alterations made to software that is under SCM control.

3.6 Commercial Off-The-Shelf Software-Software that a person can buy, ready-made, fromsome supplier's/retailer's store shelf or manufacturer's virtual store shelf (e.g., through acatalog or from a price list) on the basis of specifications set forth in the manufacturer'spublished product description (e.g., a catalog or other published specification).

3.7 Control Point-A point at which the products of a series of life cycle phases are fixed andcontrolled.

3.8 Developed Software-Software that is developed or acquired and that has been modified byan organization, as identified in Section 2.0 of this procedure.

3.9 Developer-An individual who writes software.

3.10 Developing Organization-An organization developing software subject to this procedure.

3.11 Editorial Corrections-Modifications made to a document such as correcting grammar,spelling, or typographical errors; renumbering sections or attachments (as long as therenumbering does not affect the chronological sequence of the work); modifying the title ornumber of the document; or updating organizational titles (as long as responsibilities arenot changed).

3.12 Embedded Software-i) The software associated with firmware that can provide functionand control capabilities. 2) Software that is a fixed part of a larger system and performssome of the requirements of that system.

3.13 Firmware-Software (program or data) that has been written onto read-only memory.

3.14 Independent Verification and Validation (IV& V)- The office, position, or organizationassigned responsibility for the software verification and validation processes that fall underthe scope of this procedure. The IV&V performs systematic evaluation of software

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.IQ/Rev. 5/ICN 0 Page: 9 of 57

products and activities, and is not responsible for developing the product or performing theactivity being evaluated.

3.15 In-Process Change-Change made during the life cycle process, but prior to the softwarebeing baselined.

3.16 Modified Software-Baselined software that is being changed (i.e., modifications topreviously baselined developed software, or modifications made by OCRWM to previouslybaselined acquired software).

3.17 Notification-For the purpose of this procedure, notification is an information-only activityand does not require documented evidence of compellation.

3.18 Operating Environment-The operating environment includes a collection of software,firmware, and hardware elements that provide for the execution of the software.

3.19 Operating System-A collection of software that controls the execution of computerprograms and provides such services as computer resource allocation, job control,input/output, and file management in a complete system.

3.20 Qualified Software-Software that is acquired, developed, or modified, and successfullybaselined and released by SCM.

3.21 Range of Validation-The documented type(s) of functionality and range of input for whichthe software is qualified to be used.

3.22 Regression Testing-Selective retesting of a system or component to verify thatmodifications have not caused unintended effects, and that the system or component stillcomplies with its specified requirements. (QARD)

3.23 Responsible Manager (RM)-The manager with line responsibility for performance of theactivity that the software items will support.

3.24 Software-Computer programs, procedures, rules, and associated documentation pertainingto the operation of a computer system. (QARD)

3.25 Software Configuration Management (SCM)-The office, position, or organizationassigned responsibility for the control of software that falls under the scope of thisprocedure.

3.26 Software Coordinator-l) A person who is the point of contact that coordinates softwareitems and issues and/or, 2) A technically qualified person who should be independent ofthe software development activity and not part of the IV&V, and who conducts anddocuments verifications prior to submission for IV&V.

3.27 Software Item-Source code, object code, job control code, control data, or a collection ofthese items that function as a single unit. (QARD) For purposes of this procedure, software

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.1Q/Rev. 5/ICN 0 Page: 10 of 57

items also include the procedures, rules, associated documentation, and informationpertaining to the operation of a computer system.

3.28 Software Life Cycle-A series of activities that begins when the software product isconceived and ends when the software product is no longer available for routine use. Adefined software life cycle methodology shall address the following phases: requirements,design, implementation, testing, installation and checkout, operations and maintenance, andretirement. The number of phases and relative emphasis placed on each phase of thesoftware life cycle will depend on the nature and complexity of the software. Software lifecycle activities may be performed in an iterative or sequential manner. (QARD)

3.29 Software Media-A device and/or entity (magnetic tape, diskette, CD-ROM, etc.) on whicha software item is stored. Media shall be prepared using work activities/processes/processfunctions evaluated in accordance with AP-SV. 1Q, Control of the Electronic Managementof Information.

3.30 Software Problem-Any failure of a software document, code, data structure, or process tomeet its requirements or standards.

3.31 Software User-The person(s) who operates or interacts directly with the system orsoftware.

3.32 Software Validation-The test and evaluation of completed software to ensure compliancewith software requirements. (QARD)

3.33 Software Verification-The process of determining whether or not the product(s) of a givenphase of the software development cycle fulfills the requirements imposed by the previousphase. (QARD) An example of software verification is the comparison of the proposeddesign against the documented requirements to ensure that all requirements are addressedin the design.

3.34 Status Accounting-a) Management of a centralized software baseline containing uniquesoftware identifiers, chronology of software, and a description of the changes madebetween versions of software. b) Communication of software baseline status, includingproposed, in-process, or approved software.

3.35 Target Platform-The computer(s) on which the software is intended to be used.

3.36 Technical Installer-The individual installing the software on a User's computer inpreparation for software use (normally as a result of Attachment 1, Software User Request,being submitted).

3.37 Technical Product-Any product containing engineering or scientific information withrelevance to the characterization, licensing, design, and/or operations of the CivilianRadioactive Waste Management System. For the purpose of this procedure, this definitionincludes analyses (in accordance with AP-SIII.9Q, Scientific Analyses), model reports (inaccordance with AP-SIII.IOQ, Models), reports (in accordance with AP-3. 1 Q, TechnicalReports), engineering calculations (in accordance with AP-3.1 2Q, Design Calculations and

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.lQ/Rev. 5/ICN 0 Page: 11 of 57

Analyses), and specifications (in accordance with AP-3.19Q, Specifications), or othertechnical documents that are subjected to a review process.

4.0 RESPONSIBILITIES

4.1 The Chief Information Officer is responsible for the preparation, change, and approval ofthis procedure

4.2 The following roles are responsible for activities identified in Section 5.0 of this procedure(individuals may perform one or more of these roles):

a) Software Userb) Software Coordinatorc) SCMd) Technical Installere) RMf) Developerg) IV&V

5.0 PROCESS

Software items subject to QARD requirements cannot be used in quality-affecting activitiesprior to the software being baselined and qualified. The QARD-defined software life cyclemethodology addresses the following phases: requirements, design, implementation,testing, installation and checkout, operations and maintenance, and retirement.

A Software User initiates this process by identifying a need or general requirement. TheSoftware User then checks to see if qualified software on the baseline is available to meetthe identified need. If qualified baseline software is available, use Subsection 5.1.

If qualified baseline software is not available, obtain the category of the software inaccordance with Subsection 5.2 and proceed through the process based on the determinedlevel of software categorization. The RM/Developer should determine if software could beacquired to meet the desired need.

Required independent software verification and software validation is performed usingAP-SI.3Q.

The OCRWM-provided SCM tool should be used, where available, in conjunction with thisprocess.

A functional process flow of this process is depicted in Attachment 2, AP-SI. IQ Flowchart.Acronyms and abbreviations used in this procedure are defined in Attachment 3, Acronymsand Abbreviations, and/or in the flowchart legend.


PROCESS OUTLINEPage

5.1 USE OF QUALIFIED SOFTWARE .......................................................... 12

5.2 SOFTWARE CATEGORIZATION AND PLANNING ....................................... 14

5.3 QUALIFICATION OF LEVEL B SOFTWARE ................................................... 17

5.4 CANCELING SOFTWARE .......................................................... 21

5.5 SCM CONTROL OR RELEASE .......................................................... 22

5.6 RETIRING SOFTWARE .......................................................... 23

5.7 STATUS ACCOUNTING .......................................................... 24

5.8 CHANGES TO QUALIFIED SOFTWARE AND/OR IN OPERATINGSYSTEM .......................................................... 24

5.9 USE OF UNKNOWN OR INDETERMINATE PEDIGREE SOFTWARE ....... 29

5.10 QUALIFIED SOFTWARE PROBLEM REPORTING ANDRESOLUTION .......................................................... 29

5.11 CONTINUOUS OPERATION SOFTWARE .31

5.1 USE OF QUALIFIED SOFTWARE

5.1.1 Requesting Qualified Software

5.1.1.1 Software User:

a) Locate desired software on the Baseline of Qualified SoftwareReport and confirm that the software is qualified for the operatingenvironment and validation range required.

b) If the software is not qualified for the required operatingenvironment, proceed to Paragraph 5.8.2.

c) If the software has not been qualified for the targeted validationrange, proceed to Paragraph 5.8.3.

d) If the software is not on the Baseline of Qualified Software Report,proceed to Subsection 5.2.

e) Prepare Attachment 1, Software User Request, completing theSoftware User/Developer actions in accordance with the forminstructions.

f) Submit the Software User Request (SUR) to the SoftwareCoordinator.


5.1.1.2 Software Coordinator:

Submit the SUR to SCM to request distribution of or access to abaselined software item.

5.1.1.3 SCM:

a) Update Status Accounting.

b) Update the SCM actions on the SUR in accordance with the forminstructions.

c) Provide the installation package for the requested software(installation package includes the software package, installationinstructions, and SCM checklist), along with the SUR, to theSoftware Coordinator.


Provide the installation package and SUR received from SCM to theTechnical Installer.

5.1.1.5 Technical Installer:

a) Install the software on the target platform in accordance with theinstallation package.

b) Confirm proper software installation and readiness for operationaluse.

c) Update the Technical Installer actions on the SUR in accordancewith the form instructions.

d) If installation failures occur, use the Software Problem Reportingand Resolution process in Subsection 5.10.

e) Return the installation package and SUR with supportingdocumentation providing evidence of the installation to theSoftware Coordinator.


a) Notify the Software User that the software is installed, and ensurethat the Software User has access to the appropriate documentationto use the software as determined by the Software User.

b) Return the installation package, and the SUR with supportingdocumentation to SCM.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.lQ/Rev. 5/ICN 0 Pa2e: 14 of 57

5.1.1.7 SCM:


b) Submit the completed SUR and supporting documentation to theRecords Processing Center (RPC) in accordance with Section 6.0of this procedure.

5.1.2 Use of Qualified Software

5.1.2.1 RM:

Ensure that all qualified software being used was obtained from SCM.


Control and document the use of qualified software so that comparableresults can be obtained (with any differences explained) throughindependent replication of the activity or process within the range ofvalidation to which the software was originally qualified. Toaccomplish this, the documentation must record, at a minimum, the useof the software within the Technical Product or activity outputdocumentation.

5.2 SOFTWARE CATEGORIZATION AND PLANNING

The software management life cycle requires that a software quality assurance plan be inplace for each software project, which includes the development, acquisition, ormodification of software. The planning requirements for software quality assurance areincorporated into this procedure by the process described for each software product,AP-SI.2Q, for the required documentation for Level A software; and AP-SI.3Q for IV&Vreviews. The procedure's use of standard and tailored software life cycle methodologiesprovides a planned, traceable, and orderly process for software acquisition,development/modification, operations, and maintenance.

For qualification of Level A developed software, the four software life cycle phases areRequirements, Design, Implementation, and Testing. Independent verification of softwareis conducted:

* At the conclusion of the Requirements Phase (on the RD) by the Software Coordinator

* During the Design Phase (on the design document) by the Software Coordinator

* At Control Point A at the conclusion of the Design Phase (on the Requirements,Design, and Validation Test Process [VTP] documents) by IV&V


* At Control Point B for the Implementation and Testing Phases (on the Installation TestProcess [ITP] and User Manual documents, software media, and any modified ControlPoint A documents) by IV&V.

Checkpoints at Control Point A and Control Point B include independent validationreviews, and the software is baselined by SCM.

For qualification of Level A acquired software, the two software life cycle phases areRequirements and Testing. Independent verification of software is conducted:

* At the conclusion of the Requirements Phase (on the RD) by the Software Coordinator

* At Control Point B for the Testing Phase (on the Requirements, VTP [if the VTP isrequired], ITP, User Manual documents, and software media) by IV&V.

A checkpoint at Control Point B includes an independent validation review, and thesoftware is baselined by SCM.

For qualification of Level B software, there is a single consolidated software life cyclephase. This consolidated phase consists of elements of the Requirements, Design,Implementation, and Testing phases. The Software Management Report (SMR) combinesthe Requirements, Design, VTP, and ITP documents. Independent verification for thisconsolidated phase is conducted prior to Control Point B by the Software Coordinator. Acheckpoint at Control Point B includes an IV&V review, and the software is baselined bySCM.

The RM shall categorize software in order to determine the appropriate level of requiredcontrols, validation, and verification, based on the nature, function, and complexity of thesoftware. Use Paragraph 5.2.1 to identify the category of quality-affecting software as oneof the following:

* Level A* Level B.

Level A is used to describe software that requires a high level of confidence throughvalidation and verification, based on its nature, function, and complexity (e.g., softwarethat is the numerical implementation of a model; mathematical algorithms that may usecomplex numerical methods, approximations, or simulations. Level A software is qualifiedusing AP-SI.2Q, and is subject to AP-SI.3Q for IV&V.

Level B is used to describe all other non-Level A software subject to qualification underthis procedure that requires a level of validation and verification, based upon its nature,function, and complexity (e.g., software that is used to acquire, manipulate, or transformdata, or perform calculations using mathematical algorithms that give exact results).Except for data acquisition software, Level B Software gives identical results when re-run.Level B software is qualified using Subsection 5.3 and is subject to AP-SI.3Q for IV&V.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.IO/Rev. 5/ICN 0 Page: 16 of 57

5.2.1 Software Categorization Evaluation for Software not on the Baseline ofQualified Software Report


Notify the RM that required software is not qualified.

5.2.1.2 RM:

Notify the Developer of the software need.

5.2.1.3 Developer:

a) Initiate page 1 of Attachment 4, Software Configuration ControlRequest, completing the Developer actions in accordance with theform instructions, including information provided by the RM andSoftware User.

b) Forward the Software Configuration Control Request (SCCR) tothe RM for review, categorization, and approval.

5.2.1.4 RM:

a) Review the SCCR.

b) Resolve issues with the Developer.

c) Assign and approve the appropriate category level on the SCCR bycompleting the Responsible Manager actions in accordance withthe form instructions.

d) Submit the SCCR to the Software Coordinator.


a) Request document identifying numbers for software media anddocumentation using page 2 of the SCCR, completing the SoftwareCoordinator actions in accordance with the form instructions.

b) Submit the SCCR (pages 1 and 2) to SCM.

5.2.1.6 SCM:

a) Assign the Software Tracking Number (STN) and software mediaand document number(s) on the SCCR, completing the SCMactions in accordance with the form instructions.

b) Update Status Accounting.


c) Provide copies of the SCCR (page 1 and 2) to the SoftwareCoordinator and IV&V.


Provide the Developer with the STN and document identifying numbers.

5.2.1.8 Developer:

Software life cycle activities may be performed in an iterative orsequential manner.

a) Use AP-SI.2Q for the qualification of the software if it iscategorized as Level A.

b) Use Subsection 5.3 if the software is categorized as Level B.

5.3 QUALIFICATION OF LEVEL B SOFTWARE

Level B developed, or acquired software requires the submittal of an SMR and media, andis validated and verified according to AP-SI.3Q.

5.3.1 Developer:

a) Ensure that the STNs, media numbers, and document identifying numbers areused on required documentation and media throughout the softwaredevelopment activity.

b) Prepare the SMR, using the following outline, to describe the elementsaddressed and documented. Vendor-supplied documentation may beincorporated by reference provided it complies with AP-IM-002, Use ofCopyright-Protected Materials. Any referenced vendor-supplieddocumentation intended for use shall be made available through the TechnicalInformation Center, or through the RPC, as appropriate.

1) Software Identification

* Software name and version number

* The name and version identification of the commercial softwareunder which the software was developed, to the level of detailnormally associated with the operating system on which thecommercial software resides

* SMR document identification number

* Media number.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.lO/Rev. 5/ICN 0 Pame: 18 of 57

2) Description and Testing

* Description of software (e.g., purpose, scope, etc.), includinguniquely identified requirements, operating environment, systemsupport/utility software, and any required training necessary to usethe software.

* Design description and equations of mathematical models,algorithms, and numerical solution techniques, as they relate tosoftware requirements, as applicable.

* Mapping of design element(s) to requirements, as applicable.

* If the software is to operate in more than one environment (i.e., onmultiple platforms or using different operating systems), then thisshall be stated in the documentation. Appropriate tests for eachplatform and/or operating system shall be included.

* Description of the validation test case(s), installation test case(s),including in-use test(s) for continuous operations software (seeSubsection 5.11), along with any necessary instructions to executethe test(s) and associated acceptance criteria. Installation testingshall include validation(s) that demonstrate that the software isready for operational use.

* Instructions adequate for the installation and execution of thesoftware without recourse to the originator or originatingorganization.

* Mapping of validation test case(s) to requirements.

* Description of test results, including acceptance criteria andvalidation results, with mapping to test case.

* Range of input and output parameter values for which results werevalidated.

* Identification of any limitations on applications.

3) Supporting Information (each annotated with software name and versionnumber)

* Directory listing of software files

* Computer listing of source code, if available, and compilationinstructions, if applicable


Computer listing of test data input and output files mapped to testcases.

4) References

Provide a reference list of all documentation relevant to the validationused in the development of the SMR.

c) Clearly identify the software documentation (SMR) as the verification copy(e.g., "verification" or "verification copy") on the document cover sheet andassign the alphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g. OOB, OOC, etc.).

d) Develop and prepare the software media.

e) Update the SMR if required.

f) Complete page 3 of the SCCR, completing the Developer actions inaccordance with the form instructions.

g) Submit page 3 of the SCCR, SMR (verification copy OOA), and media to theSoftware Coordinator for a verification review.

h) Make no changes, external to the verification review, to the software providedto the Software Coordinator.

5.3.2 Software Coordinator:

Notify the RM if the Software Coordinator is associated with the development ofthe software and will perform the verification review.

5.3.3 RM:

If the Software Coordinator is associated with the development of the software andwill perform the verification review, provide management approval anddocumented justification to the Software Coordinator.


a) Verify and document the completeness of the SMR in an SMR VerificationReport.

b) Coordinate with the Developer to address all comments and re-verifyiteratively until all comments have been resolved. Comments and commentresolution shall be documented. E-mail may be used for comments.

c) If a comment cannot be resolved, elevate the dispute to higher levels ofmanagement of the Developer and Software Coordinator until resolution isobtained.


d) If the Software Coordinator is associated with the development of thesoftware, attach the management approval and documented justification to theSMR Verification Report.

e) Attach all comment resolution documentation used in this verification reviewprocess to the SMR Verification Report.

f) Include on the cover sheet of the SMR Verification Report the words"Verified By:," followed by the Software Coordinator's full name, signature,and date of signature.

g) Ensure that the Control Point B package for Level B software consists of theSMR, software media, page 3 of the SCCR, and the SMR Verification Report.

h) Submit the Control Point B package to IV&V.

i) Make no changes, external to the IV&V review, to the Control Point Bpackage provided to IV&V.

5.3.5 IV&V:

Initiate IV&V for Control Point B for Level B Software in accordance withAP-SI.3Q.


a) Coordinate IV&V comments with the Developer and IV&V to address allcomments until all comments have been resolved. E-mail may be used forcomments.

b) If a comment cannot be resolved, elevate the dispute to higher levels ofmanagement of the Developer and IV&V until resolution is obtained.

c) Notify Developer that comment resolution is complete.

5.3.7 Developer:

a) Upon completion of the IV&V process for this control point, produce the finalSMR and remove the alphanumeric designator. The subsequent approvalcopy is "Rev 00."

b) Include on the cover sheet of the final documentation the words "VerifiedBy:," followed by the full name of the person performing the IV&V.

c) Sign and date the cover sheet of the SMR indicating that the SMR meets theminimum mandatory requirements, and that IV&V has been performed andany comments were resolved.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.lQ/Rev. 5/ICN 0 Paue: 21 of 57

d) Submit the SMR, software media (if changed), and page 3 of the SCCR (ifchanged) to the Software Coordinator.


Submit the final Control Point B package to IV&V (SMR; software media, ifchanged; and SCCR, page 3, if changed).

5.3.9 IV&V:

Complete IV&V for Control Point B for Level B Software in accordance withAP-SI.3Q.

5.3.10 SCM:

Upon receipt of the Control Point B records package:

a) Review the SCCR, as appropriate, verifying that the operating system andversion on page 3 of the SCCR are correct.

b) Complete the SCM actions for page 3 of the SCCR in accordance with forminstructions.

c) Update Status Accounting.

d) Process the record copies of the software, SCCR, and all Control Point Bdocumentation.

e) Submit the Control Point B records to the RPC in accordance with Section 6.0of this procedure.

f) Notify the Software Coordinator that Control Point B is complete and providethe Software Coordinator a copy of the SCCR.


Notify the Developer and Software User of the software status.

5.4 CANCELING SOFTWARE

This section applies to the cancellation of software activities after SCM has assignedidentification numbers, but before the software has been baselined.


5.4.1 RM:

a) Identify the need to cancel the software activity.

b) Notify or assign the Developer.

5.4.2 Developer:

a) Prepare page I of an SCCR completing the Developer actions in accordancewith the form instructions.

b) Submit page 1 of the SCCR to RM.

5.4.3 RM:

a) Approve the cancellation by completing the RM actions on page 1 of theSCCR in accordance with the form instructions.

b) Submit the SCCR to the Software Coordinator.


Submit the SCCR to SCM for cancellation.

5.4.5 SCM:

a) Update page 1 of the SCCR by completing the SCM actions in accordancewith the form instructions.


c) Submit the SCCR to the RPC in accordance with Section 6.0 of thisprocedure.

5.5 SCM CONTROL OR RELEASE

SCM:

a) Coordinate any administrative issues regarding baselined software packages with theSoftware Coordinator or IV&V.

b) Make software available for use after documentation and software media have beencompleted, reviewed, and approved for release.

c) Update Status Accounting.

d) Submit the completed software records package and individual records to the RPC inaccordance with Section 6.0 of this procedure.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SVI1O/Rev 5/ICN 0 Page: 23 of 57

5.6 RETIRING SOFTWARE

This section applies to the retirement of qualified software and to software that hascompleted a control point but will not complete the qualification process. Retired softwarethat had been fully qualified may only be used for the purpose of re-performing thesoftware's previously documented results.

Retirement of software shall be handled as a change to the baseline status of the softwareand shall be reflected in the SCCR and in Status Accounting maintained within thecentralized SCM.

5.6.1 RM:

a) Provide rationale for retirement by completing page 1 of the SCCR inaccordance with form instructions for the RM.

b) Request a list of the authorized users of the software from SCM.

5.6.2 SCM:

Provide the list of authorized users to the RM.

5.6.3 RM:

a) Notify authorized users of pending software retirement and obtainconcurrence.

b) Authorize the retirement by signing and dating page 1 of the SCCR.

c) Submit the SCCR and user concurrences to the Software Coordinator.


Submit the SCCR and user concurrences to SCM.

5.6.5 SCM:

a) Complete the SCM actions on the SCCR in accordance with the form

b)

c)

d)

e)

instructions.

Ensure software is not distributed for further use.

Notify all authorized users of the disposition of the software.

Update Status Accounting.

Submit the SCCR and user concurrences to the RPC in accordance withSection 6.0 of this procedure.


5.7 STATUS ACCOUNTING

SCM:

a) Establish and maintain centralized software baseline and status accounting recordscontaining unique software identifiers, a brief chronology of the software items, and adescription of the changes made between versions of the software items.

b) Inform management and users, upon request, of the software baseline status, includingproposed, in-process, or approved changes, through the various SCM reports thatcomprise Status Accounting.

5.8 CHANGES TO QUALIFIED SOFTWARE AND/OR IN OPERATING SYSTEM

This section applies to changes to the following:

* Software listed on the Baseline of Qualified Software Report* Operating System(s) on which that software is qualified.

Changes made to software, including any changes to documentation, shall follow thechange processes in accordance with Paragraph 5.8.1.

Changes in documentation can be annotated as follows:

a) Editorial corrections may be made, as necessary, without invoking any of the changeprocesses in Step 5.8b) as long as the RM initials and dates each editorial correction.

b) Indicate changes to the documentation by using the following:

1 ) A vertical line in the margin of the page, unless an extensive revision is required.

2) Include an explanation in the Change History page that clearly indicates whichindividual section(s) and/or subsection(s) of the affected documentation has beenchanged.

5.8.1 Changes to Software

5.8.1.1 Developer:

a) Prepare the SUR requesting the software for development use onlyby completing the Software User/Developer actions in accordancewith the form instructions.

b) Submit the SUR to the Software Coordinator.


Submit the SUR to SCM to request distribution of or access to thesoftware item.


5.8.1.3 SCM:


b) Update the SUR by completing the SCM actions in accordancewith the form instructions.

c) Provide the software package for the requested software, alongwith the SUR, to the Software Coordinator.


Provide the Developer with the software package and SUR.

5.8.1.5 Developer:

a) Review the software package to ensure that all necessary elementswere provided and coordinate with SCM to acquire neededelements.

b) Install the software by transferring the software elements to thedevelopment environment.

c) Update the Technical Installer actions on the SUR in accordancewith the form instructions.

d) If installation failures occur, use the Software Problem Reportingand Resolution process in Subsection 5.10.

e) Return the software package and SUR with supportingdocumentation, if applicable, to the Software Coordinator.


Return the software package and the SUR with supportingdocumentation, if applicable, to SCM.

5.8.1.7 SCM:


b) Submit the completed SUR and supporting documentation to theRPC in accordance with Section 6.0 of this procedure.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. 1 Q/Rev. 5/ICN 0 Page: 26 of 57

5.8.1.8 Developer:

a) Obtain the software categorization from SCM.

b) Evaluate the changes for impacts on life cycle documentation andproducts, as applicable.

c) Evaluate the need to perform regression testing to detect errorsintroduced during the modification of the software, to verify thatthe modifications have not caused any unintended affects, or toverify that a modified software still meets specified requirements.Changes in software media require regression testing.

d) Prepare page 1 and 2 of the SCCR by completing the Developeractions in accordance with form instructions.

e) Submit the SCCR to the RM for review and approval.

5.8.1.9 RM:

a) Review the SCCR and confirm software categorization andrationale.

b) Resolve issues with the Developer.

c) Approve the software change by completing the RM actions inaccordance with form instructions.

d) Forward the SCCR to the Software Coordinator.


Submit the SCCR to SCM.

5.8.1.11 SCM:

a) Assign the STN and software media and document number(s) bycompleting page 2 of the SCCR for SCM in accordance with theform instructions.


c) Provide a copy of the SCCR to the Software Coordinator andIV&V for planning purposes.


Provide the Developer with the STN and document identifying numbers.


5.8.1.13 Developer:

Conduct software modifications in accordance with this procedure,entering the life cycle as determined on the SCCR.

5.8.2 Change in Operating System

This section is limited to changes in operating systems within the same platformand operating system series (e.g., Sun Solaris 5.6 to Sun Solaris 5.7). When thesoftware must be recompiled or more extensive testing is required, return toParagraph 5.8.1.


Notify the RM of the need to use software on an operating systemversion for which it is not currently qualified.

5.8.2.2 RM:

Assign the Developer to test the software on the targeted operatingsystem.

5.8.2.3 Developer:

a) Prepare the SUR requesting software for development use only bycompleting the Software User/Developer actions in accordancewith the form instructions.

b) Prepare the SCCR page 1 and 3 by completing the Developeractions in accordance with the form instructions.

c) Submit the SCCR and SUR to the Software Coordinator.


Submit the SCCR and SUR to SCM to request distribution of or accessto the software item.

5.8.2.5 SCM:


b) Update page 1 of the SCCR by completing the SCM actions inaccordance with the form instructions.

c) Update the SUR by completing the SCM actions in accordancewith the form instructions.


d) Forward the requested software package and SUR to the SoftwareCoordinator.


Provide the Developer with the software package and SUR.

5.8.2.7 Developer:

a) Install the software on the target platform in accordance with theapplicable installation instructions.

b) Update the Technical Installer actions on the SUR in accordancewith the form instructions.

c) Return the software package and SUR with supportingdocumentation, if applicable, to the Software Coordinator.


a) If installation was not successful, submit the software package,SUR, and supporting documentation to SCM.

b) If installation was successful, submit the software package, SUR,and supporting documentation to IV&V.

5.8.2.9 IV&V:

Initiate IV&V for Operating System Change in accordance withAP-SI.3Q.

5.8.2.10 SCM

a) Review the SCCR, as appropriate, verifying that the operatingsystem and version on page 3 of the SCCR are correct bycompleting the SCM actions in accordance with the forminstructions.


c) Process the record copies of the software, SCCR, SUR, and allOperating System Change documentation.

d) Submit the records to the RPC in accordance with Section 6.0 ofthis procedure.

e) Notify the Software Coordinator that the Operating System changeis complete and provide the Software Coordinator with a copy ofthe SCCR.

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. I O/Rev. 5/ICN 0 Page: 29 of 57


Notify the Developer and Software User of the software status.

5.8.3 Software Not Qualified for the Targeted Validation Range

This section is limited to software already on the Baseline of Qualified SoftwareReport, but that is not qualified for the targeted validation range.


Notify the RM of the need to use software for validation ranges forwhich it is not currently qualified.

5.8.3.2 RM:

Assign the Developer to test the software for the targeted validationrange.

5.8.3.3 Developer:

Proceed to Paragraph 5.8.1.1.

5.9 USE OF UNKNOWN OR INDETERMINATE PEDIGREE SOFTWARE

This subsection describes the steps to be performed to disposition historical software thathas been discovered in the OCRWM data and/or records suite, but whose pedigree isquestionable or unknown. The software is not on the Baseline of Qualified SoftwareReport.

RM:

Qualify unknown or indeterminate pedigree software beginning with Subsection 5.2.

5.10 QUALIFIED SOFTWARE PROBLEM REPORTING AND RESOLUTION

This subsection describes the steps to be performed upon identification of a problem in anyqualified software item.

5.10.1 RM/Software User/Technical Installer:

a) Note the reproducibility of the problem (whether consistent or intermittent).If the problem report is originated from outside the OCRWM program,attempt to replicate the supplier-identified problem in the local environment.

b) Verify, in conjunction with the developing organization or supplier, that theproblem is an actual software problem and not user induced.


c) If the problem is determined to be user induced, stop the process. If theproblem is not user induced, document the problem and the environmentunder which it occurred, on Attachment 5, Software Problem Report, inaccordance with form instructions.

d) Attach the supplier notification/documentation to the Software ProblemReport (SPR) if the problem was discovered from a source outside of theprogram.

e) Submit the SPR to SCM.

5.10.2 SCM:

a) Assign an SPR number by completing the SCM actions in accordance with theform instructions.

b) Remove software from the baseline until Paragraph 5.10.3 is complete.

c) Identify the affected organizations.

d) Submit a copy of the SPR to the RMs for those Affected Organizations and toany identified users of the software within those Affected Organizations.

e) Coordinate notification to the supplier of acquired, unmodified software, ifapplicable.

f) Provide a copy of the SPR and any supporting documentation to the RM ofthe Developing Organization.

5.10.3 RM:

a) Conduct an impact evaluation and document the results including anypreventative and corrective actions. An impact analysis must be conducted inaccordance with the applicable portions of AP-2.14Q, Review of TechnicalProducts and Data, as it pertains to impact reviews.

b) Conduct a separate evaluation to determine if conditions exist that are adverseto quality that require initiation of corrective action under AP-16.1Q,Management of Conditions Adverse to Quality. Document the determination.

c) If any of the output, generated, or developed data from the software has beensubmitted to the Technical Data Management System and is adverselyaffected, notify the Technical Data Management Organization of the problemand its effect on ongoing and previous quality-affecting work.

d) Determine whether a modification to the software and/or accompanyingbaseline documentation is appropriate if the software problem is determinednot to affect ongoing or previous quality-affecting work.


e) If modification is appropriate, begin in accordance with Paragraph 5.8.1.

f) Submit the copy of the SPR and any supporting documentation to SCM.

5.10.4 SCM:

a) Perform the appropriate Status Accounting activities required to update thesoftware baseline.

b) Submit the completed SPR and supporting documentation to the RPC, inaccordance with Section 6.0 of this procedure, as part of the complete recordspackage compilation.

c) Notify all documented users of the disposition of the software, and includepreventive actions and corrective actions, as applicable.

5.11 CONTINUOUS OPERATION SOFTWARE

Software that is acquired or developed to perform continuous data acquisition or processcontrol functions shall have additional in-use tests in order to provide confirmation ofcorrect results of the software.

5.11.1 RM:

a) Define periodic manual or automatic self-check, in-use tests as an element ofthe software's qualification package. In-use tests shall be performed for anysoftware where computer errors, data errors, computer hardware failures, orinstrument drift can affect the required performance. The frequency of thein-use test is determined by the RM.

b) Document and verify, with reliable evidence, that the tests have beenconducted and the software is still operating as designed and implemented.Documentation shall consist of the following elements:

* Date the test was conducted* Person conducting the test* Test case(s) used* Results of the test.

c) Forward the original or a copy of any in-use test documentation to theSoftware Coordinator.

d) If objective evidence is found that the software is not operating as designedand implemented, follow the steps in Subsection 5. 1 0.


Submit the in-use test documentation to SCM.


5.11.3 SCM:

Submit in-use test documentation to the RPC in accordance with Section 6.0 ofthis procedure as individual records.

6.0 RECORDS

The records listed in Subsection 6.1 shall be collected and submitted to the RPC inaccordance with AP-17.1Q, Record Source Responsibilities for Inclusionary Records, asindividual records or included in a records package, as specified. In the event the RPCrequires editorial corrections per AP-17.1Q, SCM is authorized to make required changesto the baseline documentation.

6.1 QA RECORDS

Control Point B Records Package for Level B Software:

SCCRSMRSMR Verification ReportControl Point B Report

Cancelled Software Records Package:

SCCR

Retired Software Records Package:

SCCRUser Concurrences

Operating System Change Records Package:

SCCRSURSupporting DocumentationOperating System Change Report

Problem Report Records Package:

SPRSupporting Documentation

Individual Records:

SURIn-Use Test Documentation

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.1Q/Rev. 5/ICN 0 Paue: 33 of 57

6.2 NON-QA INCLUSIONARY RECORDS

None

6.3 NON-QA EXCLUSIONARY RECORDS

None

7.0 REFERENCES

a) Quality Assurance Requirements and Description, DOE/RW-0333Pb) AP-2.14Q, Review of Technical Products and Datac) AP-3.1 IQ, Technical Reportsd) AP-3.12Q, Design Calculations and Analysese) AP-3.19Q, Specificationsf) AP-3.24Q, Drawingsg) AP-1 2.1 Q, Control of Measuring and Test Equipment and Calibration Standardsh) AP- 16.1 Q, Management of Conditions Adverse to Qualityi) AP-17.1Q, Record Source Responsibilities for Inclusionary Recordsj) AP-IM-002, Use of Copyright-Protected Materialsk) AP-SI.2Q, Qualification of Level A Software1) AP-SI.3Q, Software Independent Verification and Validationm) AP-SIII.9Q, Scientific Analysesn) AP-SIII.10Q, Modelso) AP-SV.1Q, Control of the Electronic Management of Information

8.0 ATTACHMENTS

Forms attached to this procedure are controlled and distributed as full-size pages separatefrom this procedure and may be copied for use when implementing this procedure.

Attachment I - Software User Request (Form ASII-4)Attachment 2 - AP-SI.1Q FlowchartsAttachment 3 - Acronyms and AbbreviationsAttachment 4 - Software Configuration Control Request (Form ASII-I)Attachment 5 - Software Problem Report (Form ASI1-2)

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.10/Rev. 5/ICN O Pase: 34 of 57

OFFICE OF CIVILIAN RADIOACTIVE WASTE MANAGEMENT QA: QASOFTWARE USER REQUEST Page: 1 of: 1

Complete Only Applicable Items

1. STN 2. Software Name 3. Version

4. Organization S. Software User

6. Use of Software

7.

L Single Computer L Single Server Access Li Multiple (Global) Access

2 Read E Read

E ReadMtrfte [ Reaodbrkte

8. Responsible Manager Name 9. Responsible Manager Organization 10. Date

11. Responsible Manager Telephone

12. SCM Name 13. Date

14.

I lnstallationlReinstallation successful e Installation failed _ Supporting documentation

15. Installer Name 16. Signature 17. Date

AP-SI.10 REV S ICN 0 FORM NO. AS11-4

Attachment I - Software User Request

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.1I/Rev. 5/ICN 0 Page: 35 of 57

INSTRUCTIONS FOR COMPLETING THE SOFTWARE USER REQUEST

Software User/Developer

1. STN - Enter the STN from the Baseline of Qualified Software Report.

2. SOFTWARE NAME - Enter the Software Name.

3. VERSION - Enter the Software Version number.

4. ORGANIZATION - Enter the Software User's Organization.

5. SOFTWARE USER - Enter the Software User's name(s). Attach list of users if more than one.

6. USE OF SOFTWARE - State the intended use of the software, and identify the activities/product(s) thesoftware will be used to support (e.g., an Analysis Model Report, and specify the CPU Identifier[s] [barcode orserial #], platform, and operating system). Indicate if the requested software is for development use only.

7. Mark if the software is to be distributed or installed on a single computer, or is it to be mounted on a server thatcan be accessed by multiple persons. Further indicate if this server access is for a single user (read orread/write) or if the software has been developed for OCRWM-wide, global access (read or read/write).

8. RESPONSIBLE MANAGER NAME - Enter the Responsible Manager's Name (signature is not required).

9. RESPONSIBLE MANAGER ORGANIZATION - Enter the Responsible Manager's Organization.

10. DATE - Enter today's Date.

11. RESPONSIBLE MANAGER TELEPHONE - Enter the Responsible Manager's Telephone number.

Software Configuration Management

12. SCM NAME - Enter SCM Name (signature is not required).

13. DATE - Enter SCM process Date.

Technical Installer

14. After successful installation, check the appropriate boxes; attach any supporting documentation. If theinstallation failed, indicate the failure in block 14 and attach any supporting documentation.

15. INSTALLER NAME - Enter the Installer Name.

16. SIGNATURE - Enter the Signature of Installer.

17. DATE - Enter the Date the Installer signed.

Attachment I - Software User Request (Continued)

It W-311 --0r,

, 2

CL= C/)14 0CD

0: .CD

> 4d

*-4 mCD

C) ElCD�a tjCD

(A

n

0

CDSpIp

CD

-Ilz

(p

lrom

D.A

-ad

It D

=C-)

0 E

0C7)

0CD

-ICD

tJ)

0

C)1

0

CD

It0

(ro

0...0=

C/i

z1

0CD)

0D

0

O

CD2

0

10

It

00

LA~

I1-.

=C-)z0

0C-)

00

-ICD

0

0Ti

0

0co

AL

*d

p

To

0

�-dI -0 =m MM ..CL= CIO

f 0m �v�4 :�-0 0

Idwz

60w�-� qQ

CD0 �l

CD0�6 �j-e�-A

�:4nzC:)

0

0

0-

(V-

w

Cr71

El0

0~

tol

w

C

712

ElC

Cj

It

n CDP

C c

-10

0 1

-. 4 C

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. I Q/Rev. 5/ICN 0 Pa2e: 42 of 57

ITP Installation Test ProcessIV&V Independent Verification and Validation

OCRWM Office of Civilian Radioactive Waste Management

QA Quality AssuranceQARD Quality Assurance Requirements and Description

RD Requirements DocumentRM Responsible ManagerRPC Records Processing Center

SCM Software Configuration ManagementSCCR Software Configuration Control RequestSPR Software Problem ReportSMR Software Management ReportSTN Software Tracking NumberSUR Software User Request

VTP Validation Test ProcessVTR Validation Test Report

Attachment 3 - Acronyms and Abbreviations


OFFICE OF CIVILIAN RADIOACTIVE WASTE MANAGEMENT QA: QASOFTWARE CONFIGURATION CONTROL REQUEST Page: 1 of:

Complete Only Applicable items


4. Organization 5. Developer/RM

6. Action 7. Action Type

E] New n Revision8. Category |9. Request Date

t0. Software Source | 1. Vendor/ln-House

E] Acquired 5Developed

12. Software Description

13. Justification (Intended program use)

14. SCM (Printed Name) 15. Signature 16. Date Receied

17. Date Entered

18. RM (Printed Name) 19. Signature 20. Date

APSI.1 OREV 5 ICN 0 FORM NO. ASh1-1

Attachment 4 - Software Configuration Control Request


OFFICE OF CIVILIAN RADIOACTIVE WASTE MANAGEMENT QA: QASOFTWARE CONFIGURATION CONTROL REQUEST Page: 2 of:



4. Organization 1 5. Developer/RM

21. SEL DOCUMENT ACRONYM 22. DOCUMENT ID 23. COMMENTS

Requirements Document RD

Design Document DD

Installation Test Process ITP

Validation Test Process VTP

RD Verification Report

User's Manual UM

Validation Test Report VTR

DD Verification Rep rt A V_

Software Managem nt rebrt A _1 R

SMR Verification RePay L _ _ Li _ _

Media

Control Point A Report WAR

Control Point B Report WBR

Software OS Change Report OSCR

24. Other continuation Information

25. SCM (Printed Name) 26. Signature 27. Date

AP-SI.1 QREV 5 ICN 0 FORM NO. AS11-1

Attachment 4 - Software Configuration Control Request (Continued)

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-S1.l0/Rev. 5/ICN 0 Pane: 45 of 57

OFFICE OF CIVILIAN RADIOACTIVE WASTE MANAGEMENT QA: QASOFTWARE CONFIGURATION CONTROL REQUEST Page 3 of:


1. STN 2. Software Name | 3. Version

4. Organization | 5. DeveloperlRM

28. Limitations on Installation Use (e.g.. passwords to install software, hardware key/use dongle requirements)

29. Software Key? 30. Hardware Key?D Yes No EJ Yes C No

List all platforms and operating systems

31. Plafform(s) 32. Operating System(s)

33. SCM (Pinted Name) | 34 Signature 35. Date

AP-SI.1QREV 5 ICN 0 FORM NO. AS11-1



INSTRUCTIONS FOR COMPLETING THESOFTWARE CONFIGURATION CONTROL REQUEST

SOFTWARE CATEGORIZATION EVALUATION FOR SOFTWARE NOT ON THE BASELINE OFQUALIFIED SOFTWARE REPORT

PAGE 1 INSTRUCTIONS

Developer

2. SOFTWARE NAME - Enter Software Name.

3. VERSION - Enter the Version of the software being used. If unknown, leave blank when initially registeringthe software.

4. ORGANIZATION - Enter the appropriate Organizational identifier (e.g., Los Alamos National Laboratory[LANL], Lawrence Berkeley National Laboratory [LBNLI, Lawrence Livermore National Laboratory [LLNLJ,Sandia National Laboratories [SNL], U.S. Geological Survey [USGS], Bechtel SAIC Company, LLC [BSC]).

5. DEVELOPERIRM - Enter the first and last name of the Developer or Responsible Manager.

6. ACTION - Select the applicable action (New or Revision).

7. ACTION TYPE - Enter the Action Type (e.g., New, Modify).

9. REQUEST DATE - Enter the Request Date.

10. SOFTWARE SOURCE - Identify the original source:

* Procurement = Software acquired externally* Development Software developed internally.

11. VENDORIIN-HOUSE DEVELOPER - If the software was acquired from a Vendor, enter the Vendor's name orN/A if unknown. If the software was developed In-House, enter the name of the developer, if available.

12. SOFTWARE DESCRIPTION - Enter a brief description (overall nature, function, and purpose) of the software.When "Action' is 'Revision," enter a description of the change. Information may be continued on page 2(Block 24) of this SCCR.

13. JUSTIFICATION (INTENDED PROGRAM USE) - Enter a brief justification as related to the selected action.Information may be continued on page 2 (Block 24) of this SCCR.

Responsible Manager

8. CATEGORY - Assign an appropriate software Category (A or B).

18. RM - Enter the Name of the Responsible Manager.

19. SIGNATURE - Enter the Signature of the Responsible Manager approving the category assigned.

20. DATE - Enter the Date the Responsible Manager signed.


INSTRUCTIONS FOR COMPLETING THESOFTWARE CONFIGURATION CONTROL REQUEST (CONTINUED)


PAGE 1 INSTRUCTIONS (CONTINUED)


16. DATE RECEIVED - Enter the date received by SCM.

1. STN - Enter the Software Tracking Number.

14. SCM - Enter the Name of SCM.

15. SIGNATURE - Enter the Signature of SCM.

17. DATE ENTERED - Enter the Date SCM updated Status Accounting.


OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.10/Rev. 5/ICN O Page: 48 of 57



PAGE 2 INSTRUCTIONS

Software Coordinator

Ensure that Blocks 2-5 are completed correctly.

21. SEL/DOCUMENT - Check the Documents that will be submitted for the software.



22. DOCUMENT ID - Enter the document ID number.

23. COMMENTS - Enter additional COMMENTS or links to other documents.

24. CONTINUATION INFORMATION - Enter additional information for form fields, if necessary.



27. DATE - Enter the Date SCM signed.


OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. I Q/Rev. 5/ICN 0 Paue: 49 of 57



PAGE 3 INSTRUCTIONS

Developer


28. LIMITATIONS ON INSTALLATION USE - List the limitations on use or N/A. For example, specify any licenserestrictions and/or requirements for installation such as password requirement and/or hardware key/usedongle requirements.

29. SOFTWARE KEY? - Select Yes or No.

30. HARDWARE KEY? - Select Yes or No.

31. PLATFORM(S) - List all hardware platforms that are to be qualified. (Note: Requires test results in ValidationTest Report (VTR) or SMR.)

32. OPERATING SYSTEM(s) - List Operating System(s) that is to be qualified. (Note: Requires test results inVTR or SMR.)





OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI. 1 Q/Rev. 5/ICN 0 Page: 50 of 57


CANCELING SOFTWARE

PAGE 1 INSTRUCTIONS

Developer

1. STN - Enter the Software Tracking Number of the Software to be canceled.

2. SOFTWARE NAME - Enter the Name of the Software to be canceled.

3. VERSION - Enter the Version of the Software to be canceled.

4. ORGANIZATION - Enter the appropriate Organizational identifier.

5. DEVELOPER/RM - Enter the first and last name of the Developer.

6. ACTION - Select the applicable action (Revision).

7. ACTION TYPE - Enter the Action Type (Cancel).

8. CATEGORY - Enter the Software Category (A or B).


10. SOFTWARE SOURCE - Identify the original source.

11. VENDOR/IN-HOUSE DEVELOPER - If the software was acquired from a Vendor, enter the Vendor's name orN/A if unknown. If the software was developed In-House, enter the name of the developer, if available.

12. SOFTWARE DESCRIPTION - Leave blank

13. JUSTIFICATION (INTENDED PROGRAM USE) - Enter the rationale for the cancellation of the Software.

Responsible Manager


19. SIGNATURE - Enter the Signature of the Responsible Manager approving the Software cancellation.







PAGE 2 AND PAGE 3 OF THE SCCR ARE NOT USED FOR CANCELING SOFTWARE

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.IO/Rev. 5/lCNO Pa2e: 51 of 57


RETIRING SOFTWARE

PAGE 1 INSTRUCTIONS

Responsible Manager

1. STN - Enter the Software Tracking Number of the Software to be retired.

2. SOFTWARE NAME - Enter the Name of the Software to be retired.

3. VERSION - Enter the Version of the Software to be retired.


5. DEVELOPER/RM - Enter the first and last name of the Responsible Manager.

6. ACTION - Select the applicable action (New).

7. ACTION TYPE - Enter the Action Type (Retire).





12. SOFTWARE DESCRIPTION - If Software is qualified for multiple environments, identify the environment to beretired (e.g. WIN95), or enter 'ALL."

13. JUSTIFICATION (INTENDED PROGRAM USE) - Enter the rationale for the retirement of the Software.






PAGE 2 AND PAGE 3 OF THE SCCR ARE NOT USED FOR RETIRING SOFTWARE

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.1I/Rev. 5/ICN 0 Page: 52 of 57


CHANGES TO QUALIFIED SOFTWARE

PAGE 1 INSTRUCTIONS

Developer

2. SOFTWARE NAME - Enter the Name of the Software to be changed.

3. VERSION - Enter the "new" Version of the Software.


5. DEVELOPERIRM - Enter the first and last name of the Developer or Responsible Manager.


7. ACTION TYPE - Enter the Action Type (Modify).





12. SOFTWARE DESCRIPTION - Enter a description and scope of the change.

13. JUSTIFICATION (INTENDED PROGRAM USE) - Enter the rationale for the change to the Software.Information may be continued on page 2 (Block 24) of this SCCR.

Responsible Manager


19. SIGNATURE - Enter the Signature of the Responsible Manager approving the Software change.









OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.IQ/Rev. 5/ICN 0 Pa2e: 53 of 57


CHANGES TO QUALIFIED SOFTWARE

PAGE 2 INSTRUCTIONS

Developer


24. CONTINUATION INFORMATION - Document the if regression testing was needed, and if so include theresults.

21. SEUDOCUMENT - Check the Documents changed.

22. DOCUMENT ID - Enter the document ID number(s) for unchanged Documents and/or Software Media.



22. DOCUMENT ID - Enter the document ID number(s) for changed Documents and/or Software Media.

23. COMMENTS - Enter additional COMMENTS or links to other documents.

24. CONTINUATION INFORMATION - Enter additional information for form fields, if necessary.




PAGE 3 OF THE SCCR IS NOT USED FOR CHANGING SOFTWARE




CHANGES TO OPERATING SYSTEM

PAGE 1 INSTRUCTIONS

Developer

2. SOFTWARE NAME - Enter the Name of the Software whose Operating System is to be changed.

3. VERSION - Enter the Version of the Software.


5. DEVELOPER/RM - Enter the first and last name of the Developer or Responsible Manager.


7. ACTION TYPE - Enter the Action Type (New).





12. SOFTWARE DESCRIPTION - Enter a description and scope of the change.

13. JUSTIFICATION (INTENDED PROGRAM USE) - Enter the rationale for the change in Operating System forthe Software.

Responsible Manager


19. SIGNATURE - Enter the Signature of the Responsible Manager approving the Operating System change.








PAGE 2 OF THE SCCR IS NOT USED FOR OPERATING SYSTEM CHANGES

OCRWM ProcedureTitle: Software ManagementProcedure No.: AP-SI.IQ/Rev. 5/ICN 0 Paue: 55 of 57


CHANGES TO OPERATING SYSTEM

PAGE 3 INSTRUCTIONS

Developer


28. LIMITATIONS ON INSTALLATION USE - List the limitations on use or N/A. For example, specify any licenserestrictions and/or requirements for installation such as password requirement and/or hardware keylusedongle requirements.

29. SOFTWARE KEY? - Select Yes or No.

30. HARDWARE KEY? - Select Yes or No.

31. PLATFORM(S) - List hardware platforms that are to be qualified. (Note: Requires test results in VTR orSMR.)

32. OPERATING SYSTEM(s) - List 'new' Operating System(s) that is to be qualified. (Note: Requires test resultsin VTR or SMR.)








OFFICE OF CIVILIAN RADIOACTIVE WASTE MANAGEMENT QA: QA

SOFTWARE PROBLEM REPORT Page: 1 of:


1. Software Tracking Number: 2. Software Name and Version: 3. Software Activity Number:

4. Source of Problem:

E Internal to CRWMS

O Extemal to CRWMS (Supplier or Outside User)

Name (if available)

Address (if available)

Phone (if available)

5. Date Problem Encountered: 6. Has Problem Been Verified?

M]Yes n No

7. Document the environment under which problem occurred (such as Operating System, Switch Settings, Location in the Code, and the Input Rangewhere the problem occurred) or attach a copy of the error noticeidocumentation received from the supplier and include a proposed resolution:

X~A~D

8. User or Developer Name: User or Developer Org.: Date:

9. Software Status Accounting Name and Signature: Software Status Accounting SPR Number: Date:

10. Software Configuration Management Verifier Name and Signature: Date:

1 1. Software Configuration Management Name and Signature: Date:

AP-SI.1 Q REV S ICN 0 FORM NO. AS11-,

Attachment 5 - Software Problem Report


INSTRUCTIONS FOR COMPLETING THESOFTWARE PROBLEM REPORT

RM/Software User/Technical Installer

1. Software Tracking Number - Enter the previously assigned Software Tracking Number.

2. SOFTWARE NAME AND VERSION - Enter the Software Name and Version number.

3. SOFTWARE ACTIVITY NUMBER - Enter the previously assigned Software Activity Number for this software.

4. SOURCE OF PROBLEM - Indicate whether the problem was internally discovered or came from an externalsource by checking the appropriate box. Provide the supplier or outside user name, address, and telephonenumber, if known; otherwise, N/A.

5. DATE PROBLEM ENCOUNTERED - Enter the Date the problem was first discovered or made known to you.

6. HAS THE PROBLEM BEEN VERIFIED? - Indicate if the problem has been verified (reproduced) by checkingYes or No.

7. DOCUMENT THE ENVIRONMENT ... - Provide a description of the problem and give as much detail aspossible, including where in the software code (what module, if any) the problem occurred, and under whatconditions. Attach a copy of the notification/documentation from the supplier and reference the attachment inthis block. Include a proposed resolution.

8. USER OR DEVELOPER NAME - Enter the User or Developer Name (signature is not required), Organization,and Date.


9. SOFTWARE STATUS ACCOUNTING NAME AND SIGNATURE - Enter the Software Status AccountingName and Signature, Software Status Accounting SPR Tracking Number, and Date.

10. SOFTWARE CONFIRGURATION MANAGEMENT VERIFIER NAME AND SIGNATURE - The SCM Verifierwill review the problem and verify the documentation. Fill out the SCCR (page 3) requesting that software beremoved from use until the Responsible Manager has conducted an evaluation and provided a statement ofthe impact of the problem. Attach the SCCR (page 3) to this form and give it to SCM. Enter the SoftwareConfiguration Management Verifier Name, Signature, and Date.

11. SOFTWARE CONFIRGURATION MANAGEMENT NAME AND SIGNATURE - Enter the SoftwareConfiguration Management Name and Signature. Ensure that the software has been removed from theBaseline of Qualified Software Report for approved Project use. Enter the Date SCM signed.

Attachment 5 - Software Problem Report (Continued)