PROCEDURE QUALIFICATION OFLEVEL A SOFTWARE AP-SIProcedure No.: AP-SI.2Q/Rev. 1/ICN 0 Page: 8 of 28...

�TESd�

Office of Civilian Radioactive Waste Management QA: QA

PROCEDURE

QUALIFICATION OFLEVEL A SOFTWARE

AP-SI.2Q

Revision I ICN 0

Effective Date: 04/23/2003

Preparer:_ _.

Approval:

F.B. Platko I -

D.R. TommelaChief Information Officer

D\>ateolDate

Da-te F---

1. -" / // � �L-

6)

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/ICN 0 Pa2e: 2 of 28

CHANGE HISTORY

Revision Interim EffectiveNumber Change No. Date

0 0 01/13/2003

0 04/23/2003I

Description of Cbange

Initial issue.

Complete revision to address consolidation ofLevel A software activities from AP.SI-1Q, SoftwareManagement; rework process flows to addressorganizational hand-off issues, role responsibilities,and provide clearer definition of work products;remove use of AP-2.14Q, Review of TechnicalProducts and Data, for comment resolution activities;and address the following Document ActionRequests: D6454, D6519, D6520, D6521, andD6522.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. lfICN 0 Page: 3 of 28

1.0 PURPOSE

This procedure establishes the responsibilities and processes for those activities thatconstitute the Level A software qualification process. These activities follow the softwarelife cycle requirements described in the Quality Assurance Requirements and Description(QARD), DOE/RW-0333P, document.

Supplemental internal organizational controls are allowed and encouraged under thisprocedure.

2.0 APPLICABILITY

This procedure shall only be used in conjunction with AP-SI. IQ, Software Management,and AP-SI.3Q, Software Independent Verification and Validation, and applies to thequalification of Level A software.

This process applies to software that is classified as Level A software (see AP-SI. lQ), andintroduces the software management life cycle required to meet the software requirementsof the QARD. The QARD software management life cycle specifies the phases asrequirements, design, implementation, testing, installation and checkout, operations andmaintenance, and retirement. This process applies to Level A software that is developed,modified, or acquired.

3.0 DEFINITIONS

3.1 Unit testing-Testing of individual software modules, or groups of related modules within asource code, that is performed during code development prior to final validation testing.

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 roles):

a) Developerb) Responsible Manager (RM)c) Software Configuration Management (SCM)d) Software Coordinatore) Independent Verification and Validation (IV&V)

5.0 PROCESS

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

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. l/ICN 0 Page: 4of28

Software planning is addressed in AP-SI.lQ, Subsection 5.2, and software retirement isaddressed in AP-SI.IQ, Subsection 5.6.

If the software is to operate in more than one environment (i.e., multiple platforms or isusing different operating systems), then it shall be stated in the documentation.Appropriate tests for each platform and/or operating system shall be included in theInstallation Test Process (ITP) and Validation Test Process (VTP), if a VTP is required,and documented results summarized in the Validation Test Report (VTR).

Software verification shall be performed on the Requirements and Design phases by theSoftware Coordinator. The Software Coordinator should not be associated with thedevelopment of the software; however, if the appropriate level of independence cannot beachieved, the Software Coordinator may perform these activities with managementapproval and documented justification. An IV&V process will be performed in accordancewith AP-SI.3Q.

PROCESS OUTLINEPage

5.1 REQUIREMENTS PHASE ................................................ 45.2 DESIGN PHASE ................................................ 65.3 CONTROL POINT A VERIFICATION AND VALIDATION ........................... 105.4 IMPLEMENTATION PHASE ............................................... 125.5 TESTING PHASE ............................................... 155.6 CONTROL POINT B VERIFICATION AND VALIDATION ........................... 16

5.1 REQUIREMENTS PHASE

This phase of the software management life cycle specifies the development ormodification of requirements to ensure clear and consistent translation of user needs intosoftware functional capabilities prior to software acquisition, development, or modification.Requirements may only be specified if their achievement can and will be verified andvalidated, and are traceable throughout the life cycle phases. Software requirements shallprovide enough detail to either design the software or make an acquisition decision.

The document preparer (Developer or Software Coordinator) shall ensure that the SoftwareTracking Numbers and document identifying numbers are used on required documentationthroughout the software development activity.

5.1.1 Requirements Analysis

5.1.1.1 Developer:

a) Perform an analysis of the requirements (in conjunction with therequester, if required).

b) Prepare a Requirements Document (RD) uniquely identifying eachrequirement. The following outline delineates the elements to beaddressed and documented, as applicable, when developing the

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. l/ICN 0 Paue: 5 of 28

RD. For each section that is not applicable to a specific softwaredevelopment project, provide a brief justification.

1) Functionality-Functions the software is to perform

2) Performance-Time-related issues of software operation, such asspeed, recovery time, response time, etc.

3) Design constraints imposed on implementation phase activities-Any elements that will restrict design options

4) Attributes-Non-time related issues of software operation, suchas portability, acceptance criteria, access control,maintainability, etc.

5) External interfaces-Interactions with people, hardware, andother software.

c) Initiate Attachment 3, Software Requirements Traceability Matrix,completing the Developer actions for requirements elements inaccordance with the form instructions.

d) Identify the RD as the verification copy (e.g., "verification" or"verification copy") on the document cover sheet and assign thealphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g., OOB,OOC, etc.)

e) Submit the verification copy of the RD to the Software Coordinatorfor verification review.

5.1.1.2 Software Coordinator:

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

5.1.1.3 RM:

If the Software Coordinator is associated with the development of thesoftware and will perform the verification review, provide managementapproval and documented justification to the Software Coordinator.


a) Verify and document, in an RD Verification Report, the results ofthe RD verification review to ensure that the requirements arecomplete, consistent, accurate, testable, and traceable.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. l/ICN 0 Page: 6 of 28

b) Coordinate with the Developer to address all comments andre-verify iteratively until all comments have been resolved.Comments and their resolution shall be documented. E-mail maybe used for comments.

c) If a comment cannot be resolved, elevate the dispute to higherlevels of management for the Developer and Software Coordinatoruntil resolution is obtained.

d) If the Software Coordinator is associated with the development ofthe software, attach the management approval and documentedjustification to the RD Verification Report.

e) Attach all comment resolution documentation used in thisverification review process to the RD Verification Report.

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

g) Notify the Developer that the verification review is complete.

5.2 DESIGN PHASE

The decision to acquire or develop software is confirmed during the design phase.Software may be acquired when software that meets the requirements of the RD has beenlocated in the external public domain software inventories or is identified as commercialsoftware.

According to the existing contractual requirements, any software leased or procured solelywith Office of Civilian Radioactive Waste Management funds is considered Projectsoftware and must have any associated license(s) bear the name of U.S. Department ofEnergy as the owner of the software.

There are two methods for acquiring software to be used in support of quality affectingactivities. They are as follows:

a) Software is procured through a quality procurement activity that requires the vendor tohave a program in place that meets the QARD, Supplement 1.2.6. For acquired,unmodified software procured through a quality procurement activity, the documentsrequired in accordance with this procedure are the RD, ITP, VTR, and Users Manual(UM). Vendor documentation may be referenced provided it complies withAP-IM-002, Use of Copyright-Protected Materials. The Design Document (DD) is notrequired. Following acceptance, the software will be controlled by SCM.

-OR-

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. I/ICN 0 Page: 7of28

b) Software is acquired as non-Q and qualified in accordance with this procedure. TheDD is not required.

If the decision is made to develop software or to modify acquired software, therequirements are translated into a set of technical computer design specifications thatare delineated in the DD. In order to ensure traceability, the DD must address the RDrequirements. The design specifies the data structures, processes, interfaces, andprocedures to the level of detail necessary to plan and execute the implementation,validation, and installation of the software project. The VTP is developed or modified,and documented during this phase of the software management life cycle.

The document preparer (Developer or Software Coordinator) shall ensure that theSoftware Tracking Numbers and document identifying numbers are used on requireddocumentation and media throughout the software development activity.

5.2.1 Design

5.2.1.1 Developer:

a) Prepare the DD (not required for acquired, unmodified software).The following delineates the elements to be addressed anddocumented when developing the DD. For each element that is notapplicable to a specific software development project, provide abriefjustification of non-applicability.

1) Purpose

2) Implementation Standards, including performance, andEnvironment Specifications, including system support software

3) Software Structure is the description of the major componentsof the software design as they relate to the softwarerequirements, and a technical description of the software withrespect to the theoretical basis, mathematical model, controlflow, data flow, control logic, and data structure

4) Description of the allowable or defined range of System Inputsand Outputs

5) The design described in a manner that can be translated intocode

6) User interfaces

7) System interfaces

8) Security

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. 1/ICN 0 Page: 8 of 28

b) Update the Requirements Traceability Matrix (RTM) to documentthe design elements as they relate to the requirements bycompleting the Developer actions for the design elements inaccordance with the form instructions.

c) Identify the DD as the verification copy (i.e., "verification" or"verification copy") on the document cover sheet(s) and assign analphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g., GOB,OOC, etc.).

d) Submit the verification copy of the DD and a copy of the RTM tothe Software Coordinator for a verification review.


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

5.2.1.3 RM:

If the Software Coordinator is associated with the development of thesoftware and will perform the verification review, provide managementapproval and documented justification to the Software Coordinator.


a) Conduct a DD verification review to verify completeness and toensure that all requirements are addressed in the design and eachrequirement is traceable to a design element. Document the resultsof this review in a DD Verification Report.

b) Coordinate with the Developer to address all comments andre-verify iteratively until all comments have been resolved.Comments and their resolution shall be documented. E-mail maybe used for comments.

c) If a comment cannot be resolved, elevate the dispute to higherlevels of management for the Developer and Software Coordinatoruntil resolution is obtained.

d) If the Software Coordinator is associated with the development ofthe software, attach the management approval and documentedjustification to the DD Verification Report.

e) Attach all comment resolution documentation used in thisverification review process to the DD Verification Report.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. I/ICN 0 Page: 9 of 28

f) Include on the cover sheet(s) of the DD Verification Report thewords "Verified By:," followed by the Software Coordinator's fullname, signature, and date of signature.

g) Notify the Developer that the verification review is complete.

5.2.2 VTP

Appropriate tests for each requirement and/or design element shall be included inthe VTP.

If the software is to operate in more than one environment (i.e., on multipleplatforms or using different operating systems), then this shall be stated in thedocumentation. Appropriate tests for each platform and/or operating system shallbe included in the VTP.

The document preparer (Developer or Software Coordinator) shall ensure that theSoftware Tracking Numbers and document identifying numbers are used onrequired documentation throughout the software development activity.

A VTP is not required if the software is acquired through a quality procurementactivity and is not modified.

5.2.2.1 Developer:

a) Develop the test cases for the requirements addressing eachplatform and/or operating system.

b) Develop a VTP or modify the existing VTP. The VTP reflects therequirements of the RD, as well as the design elements of the DDfor developed software.

The VTP documentation shall include:

1) A description of the requirements-based test case(s), includingsteps to be performed and a unique identifier for each test case(e.g., 1, 2, 3 or Test O1Q, Test 02Q, Test 03Q)

2) The acceptance/rejection criteria for each test case

3) For modifications to qualified software, in addition to the testsfor new requirements, provide instructions for regression testingactivities to detect errors introduced and to verify thatmodifications have not caused unintended effects

4) Instructions for executing the VTP test cases

5) A place to indicate test status that includes pass/fail, initials oftester, and date test was performed (e.g., test log)

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. l/ICN 0 Page: 10of28

6) The alternative methods used to demonstrate technicaladequacy, which may include:

* Analysis without computer assistance (hand calculation)* Other validated computer programs* Experiments and tests* Standard problems with known solutions* Comparisons to confirmed published data correlations.

b) Update the RTM to document the test case identifiers as they relateto the design and requirements by completing the Developeractions for the VTP elements in accordance with the forminstructions.

c) Identify the VTP as the verification copy (e.g., "verification" or"verification copy") on the document cover sheet and assign thealphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g., 00B,QOC, etc.).

5.3 CONTROL POINT A VERIFICATION AND VALIDATION

Developed software requires a Control Point A verification. Control Point A package forLevel A software is the RD, DD, VTP, a copy of the RTM, RD Verification Report, andDD Verification Report.

If qualifying acquired unmodified software (which does not require a Control Point Averification), proceed to Subsection 5.4.

5.3.1 Developer:

a) Submit the verification copy of the RD (if changed), the verification copy ofthe DD (if changed), the verification copy of the VTP, and a copy of the RTMto the Software Coordinator.

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

5.3.2 Software Coordinator:

a) Submit Control Point A package to IV&V.

b) Ensure no changes are made, external to the IV&V review, to the ControlPoint A package provided to IV&V.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. l/ICN 0 Page: 11 of 28

5.3.3 IV&V:

Initiate IV&V for Control Point A for Level A developed software in accordancewith AP-SI.3Q.


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

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

c) Notify the Developer that the comment resolution is complete.

5.3.5 Developer:

a) Upon completion of the IV&V process for this control point, produce the finalControl Point A documentation and remove the alphanumeric designator. Thesubsequent approval copy is "Rev 00."

b) Include on the cover sheets 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 each document indicating that minimummandatory requirements have been met and that all comments have beenresolved.

d) Submit the final Control Point A package to the Software Coordinator.


Submit the final Control Point A package to IV&V.

5.3.7 IV&V:

Complete IV&V for Control Point A for Level A developed software in

accordance with AP-SI.3Q.

5.3.8 SCM:

Upon receipt of the Control Point A records package:

a) Update Status Accounting.

b) Process the record copies of the software, Software Configuration ControlRequest (SCCR), and all Control Point A documentation.


c) Hold the Control Point A records until the Control Point B records areavailable.

d) Notify the Software Coordinator that Control Point A is complete.


Notify the Developer of the software status.

5.4 IMPLEMENTATION PHASE

Implementation is accomplished by developing software code and preparing the ITP.During this phase, the DD is translated into machine-readable code.

5.4.1 Developer:

a) For acquired, unmodified software, proceed to Paragraph 5.4.2.

b) Develop software in accordance with the DD. Attachment 4, SuggestedStandard Coding Conventions, may be used as coding standards.

c) Prepare the software media. At a minimum, the media must contain:

1) "Read-Me" file(s) that describe media content; documentation oncompiler parameters or settings, if applicable; compilation instructions,if applicable; execution commands; script files; or other operatingenvironment settings

2) Source code

3) Executables, if applicable

4) All files necessary to successfully install and perform the ITP and VTP,and to operate the software within the documented range of validation.

5.4.2 ITP

If the software is to operate in more than one environment (i.e., on multipleplatforms or using different operating systems), then this shall be stated in thedocumentation. Appropriate tests for each platform and/or operating system shallbe included in the ITP.



5.4.2.1 Developer:

a) Develop an ITP or modify the existing ITP. The ITP delineates theactivities involved in the validation of the installation of thesoftware product. If an acquired UM or other vendor-supplieddocumentation contains these activities, then the activities may bereferenced, provided the vendor-supplied documentation complieswith AP-IM-002. Any referenced vendor-supplied documentationintended for use shall be made available through the TechnicalInformation Center, or through the Records Processing Center(RPC), as appropriate.

The ITP documentation shall include, as appropriate:

1) Identification of the operating equipment (e.g., hardware andsoftware configurations) and pre-installation tasks(i.e., de-fragmentation of the hard drive, determination of diskstorage capacity) to be performed on the target platform, and adetailed description of all pre-installation tests that may berequired

2) Instructions regarding the installation procedure

3) Actions necessary to complete the transfer of software anddata elements from the distribution media to the targetplatform

4) Tasks to be performed after the software transfer has beencompleted

5) Instructions regarding setting initial operating conditionsautomatically or by manual instructions in the procedure

6) Description of the installation test case(s) with identifiers(e.g., Test Case 1) to accurately confirm a correct installationand ready-for-use condition, or identify and document aninstallation failure and indicate the problem conditions found

7) Expected results/outputs from installation test cases

8) In-use test(s) for continuous operations software, along withany necessary instructions to execute the test(s) and associatedacceptance criteria

9) Installation testing and validation(s) that demonstrate thesoftware is ready for operational use

10) Installation acceptance criteria

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. l/JCN 0 Page: 14 of 28

11) Possible error or warning condition indicators to be examinedby the tester, including errors that do not affect the outcome ofthe software

12) Instructions for uninstalling the software

13) Any additional instructions for performing the ITP.

b) Update the RTM to document the test case identifiers as they relateto the design and requirements by completing the Developeractions for the ITP elements in accordance with the forminstructions.

c) Identify the ITP as the verification copy (e.g., "verification" or" verification copy") on the document cover sheet and assign thealphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g., OOB,OOC, etc.).

5.4.3 User Manual Development

If an acquired UM or other vendor-supplied documentation is referenced, thevendor-supplied documentation must comply with AP-IM-002. Any referencedvendor-supplied documentation intended for use also shall be made availablethrough the Technical Information Center or the RPC, as appropriate.


5.4.3.1 Developer:

a) Develop or modify the UM, or supplement the acquired UM,including any applicable, special user instructions. The UM shallprovide instructions for using the software and shall include (or inthe case of acquired software, be supplemented to include) thefollowing sections, as appropriate:

1) Purpose and scope of the software

2) User interactions (e.g., actions the user is required to performto operate the software)

3) Any constraints and/or special instructions to the users

4) Input/output specifications

5) Data files, input and output data, defaults, and file formats

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. I/ICN 0 Page: 15of28

6) Description of the ranges of inputs and outputs for which thesoftware is tested

7) Anticipated errors and how the user can respond

8) Hardware and software environment

9) Description of required training

10) Available sample problems

11) Cross-reference of acquired user manual to UM sections.

b) Update the RTM to document the UM elements as they relate tothe design and requirements by completing the Developer actionsfor the UM elements in accordance with the form instructions.

c) Identify the UM as the verification copy (i.e., "verification" or"verification copy") on the document cover sheet and assign thealphanumeric draft designator OOA. Each subsequent revision isassigned an incremented alphanumeric draft designator (e.g., OOB,OOC, etc.).

5.5 TESTING PHASE

During this phase, developed or acquired, software is validated by executing the test casesin the ITP and VTP (VTP not applicable for acquired, unmodified software procuredthrough a quality procurement activity). The testing process ensures that the softwareproduct adequately and correctly performs all intended functions, and does not perform anyunintended functions either by itself or in combination with other software. The testingprocess combines the results of the testing activities into one VTR. No formal installationor validation testing for the VTR shall be initiated until receipt of notification that theControl Point A IV&V is complete.

If the software is to operate in more than one environment (i.e., on multiple platforms orusing different operating systems), then this shall be stated in the documentation.Appropriate tests for each platform and/or operating system shall be included in the ITPand, if required, the VTP, and results documented in the VTR.

5.5.1 Developer:

a) Perform testing according to the ITP and, if required, the VTP.

b) Document the results of the testing in the VTR. The following shall beaddressed:

1) Software Identification, including version number, platform type(s), andoperating system(s) version.


2) Identification of special tools and equipment used (e.g., type,nomenclature, model numbers, serial numbers).

3) Test results linked to the unique test identifier from the ITP.

4) Test results linked to the unique test identifier from the VTP, if the VTPis required.

5) Documentation of results of execution of the individual test steps withinthe ITP and, if required, the VTP, including results obtained (pass/fail),name of tester, and date test was performed, with the generated outputattached to the VTR. An example test log is provided in Attachment 5,Example Test Log.

6) Description of any failure conditions, how they occurred, and theirresolutions.

7) Documentation and justification for any remaining test exceptions orfailures.

8) Overall conclusions from the test.

9) General remarks.

c) Identify the VTR as the verification copy (i.e., "verification" or "verificationcopy") on the document cover sheet and assign the alphanumeric draftdesignator OOA. Each subsequent revision is assigned an incrementedalphanumeric draft designator (e.g., OOB, OOC, etc.).

d) If there are changes to Control Point A documentation, initiate an SCCR inaccordance with AP-SI.IQ, Paragraph 5.2.1.3 through Paragraph 5.2.1.7, toobtain revision document numbers for the modified documents.

5.6 CONTROL POINT B VERIFICATION AND VALIDATION

Control Point B verification and validation is required for all Level A software.

Control Point B package for Level A developed software will consist of the verificationcopies of the ITP, UM, and VTR; a copy of the RTM; the software media; page 3 of theSCCR; and the verification copies of any modified Control Point A documentation.

Control Point B package for Level A acquired software will consist of the verificationcopies of the RD, UM, ITP, and VTR; the RD Verification Report; a copy of the RTM; thesoftware media; page 3 of the SCCR; and the verification copy of the VTP (VTP notapplicable for acquired, unmodified software procured through a quality procurementactivity).

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/ICN 0 Page: 17 of 28

5.6.1 Developer:

a) Complete the Developer actions on page 3 of the SCCR in accordance withthe form instructions.

b) Submit Control Point B package to the Software Coordinator.

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


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

b) Ensure no changes are made, external to the IV&V review, to the ControlPoint B package provided to IV&V.

5.6.3 IV&V:

Initiate IV&V for Control Point B for Level A developed software or Level Aacquired software, as appropriate, in accordance with AP-SI.3Q.


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

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

c) Notify the Developer that comment resolution is complete.

5.6.5 Developer:

a) Upon completion of the IV&V process for this control point, produce the finaldocumentation by removing the alphanumeric designators. The subsequentapproval copy is "Rev 00."

b) Include on the cover sheets 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 each document indicating that minimummandatory requirements have been met and that all comments have beenresolved.

d) Submit the final Control Point B package to the Software Coordinator.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/ICN 0 Paue: 18of28


Submit the final Control Point B package to IV&V.

5.6.7 IV&V:

Complete IV&V for Control Point B for Level A developed software or Level Aacquired software, as appropriate, in accordance with AP-SI.3Q.

5.6.8 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 theform instructions.

c) Update Status Accounting.

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

e) Submit the Control Point A, if applicable, and Control Point B records to theRPC in accordance with Section 6.0 of 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 of the software status.

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, the SCM is authorized to make requiredchanges to the baseline documentation.

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.2Q/Rev. l/ICN 0 Page: 19 of 28

6.1 QA RECORDS

Records Package for Level A developed software:

Control Point A

RDRD Verification ReportDDDD Verification ReportVTPControl Point A Report

Control Point B

SCCRAny modified Control Point A DocumentationUMITPRTMVTRControl Point B Report

Records Package for Level A acquired software:

SCCRRDRD Verification ReportVTP, if the VTP is requiredITPUMRTMVTRControl Point B Report

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- 17.1 Q, Record Source Responsibilities for Inclusionary Recordsc) AP-IM-002, Use of Copyright-Protected Materials


d) AP-SI.1Q, Software Managemente) AP-SI.3Q, Software Independent Verification and Validation

8.0 ATTACHMENTS

Procedure attachments attached to this procedure are controlled and distributed as full-sizepages separate from this procedure and may be copied for use when implementing thisprocedure.

Attachment 1 - AP-SI.2Q FlowchartAttachment 2 - Acronyms and AbbreviationsAttachment 3 - Software Requirements Traceability Matrix (PAASI2-1)Attachment 4 - Suggested Standard Coding ConventionsAttachment 5 - Example Test Log

0

CD)

z0

10

9i~0

0

-t

n

00

-t

0

ty)

C

0

0

00

0

m0.

tC,'

CD

z~n

0I0

r-

W

0

Fr'

0CD

coo

0

-o0

0

0

CD

CD

3

0

0

CD

To

Cao

ADq

Q0It

0

00

*0

C.

CD.zt

0

Ri

C)

0

'-1

CD

0

0

Cl)

-tC)

0

CD~7I

C~)

10

It

evw

folDj

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/ICN 0 Paue: 24 of 28

DD Design Document

ITP Installation Test ProcessIV&V Independent Verification and Validation

QARD Quality Assurance Requirements and Description

RD Requirements DocumentRM Responsible ManagerRPC Records Processing CenterRTM Requirements Traceability Matrix

SCCR Software Configuration Control RequestSCM Software Configuration Management

UM Users Manual

VTP Validation Test ProcessVTR Validation Test Report

Attachment 2 - Acronyms and Abbreviations

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/JCN 0 Page: 25 of 28

QA: QA

OCRWM SOFTWARE REQUIREMENTS TRACEABILITY MATRIX Page 1 of 1

1. STN 2. Software Name | 3. RevisionNersion

4. Requirements 5. Design 6. Validation Test 7. Installation Test 8. User ManualCases Cases

Av :

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __- -_ _ _ _- -_ _ _ _ _ _ _ __I

+ +

-I I I-

AP-SI.20 REV 1 ICN 0 PA AS12-1

Attachment 3 - Software Requirements Traceability Matrix

OCRWM ProcedureTitle: Qualification of Level A SoftwareProcedure No.: AP-SI.20/Rev. 1/ICN 0 Pave: 26 of 2R

INSTRUCTIONS FOR COMPLETING THESOFTWARE REQUIREMENTS TRACEABILITY MATRIX

Developer:

1. STN - Enter the assigned Software Tracking Number.

2. SOFTWARE NAME - Enter the Software Name.

3. REVISIONNERSION - Enter the Software Version number.

4. REQUIREMENTS - Enter the unique identifier for each requirement from the RD in ascending order.

5. DESIGN - Enter the unique identifier for the design element(s) from the DD that addresses the requirements.

6. VALIDATION TEST CASES - Enter the unique identifier for the validation test case(s) from the VTP thataddresses the requirement, if a VTP is required. If acquired documentation contains this information, thenreference the acquired or vendor supplied documentation.

7. INSTALLATION TEST CASES - Enter the unique identifier for the installation test case(s) from the ITP thataddresses the requirement, as applicable. If acquired documentation contains this information, then referencethe acquired or vendor supplied documentation.

8. USER MANUAL - Enter the unique identifier for the user manual element(s) from the UM that addresses therequirement, as applicable. If acquired documentation contains this information, then reference the acquiredor vendor supplied documentation.

Attachment 3 - Software Requirements Traceability Matrix (Continued)


SUGGESTED STANDARD CODING CONVENTIONS

These are suggestions for coding standards:

1) Standardize presentation (e.g., header information and comment layout).

2) Standardize the naming of programs, subprograms, files, variables, and data within anapplication.

3) Standardize the versioning convention to MM.I1.BB, where MM corresponds to the Majorreleases, II corresponds to the Intermediate releases, and BB corresponds to the Bug Fixes.

4) Limit the size of modules by using library routines, such as operating system routines,commercial library routines (e.g., numerical analysis), project specific utility routines,defining constants, using compiler specific features not in the language standard, errorhandling, etc.

5) Provide a standard header to be made available so that it can be edited, completed, and theninserted back at the top of each module.

6) Develop the code as consistently as possible to reduce complexity.

7) Enforce precise adherence to coding conventions to ensure consistency.

8) Adopt and use the same solutions to the same problems encountered during development.Do not insert quick fixes, workarounds, etc., to speed up the project.

9) Safeguard code consistency so changes and modifications will follow the same style as theoriginal code.

10) Coding should be structured. Structured techniques reduce errors and enhance systemmaintainability.

11) The coding process includes compilation that will produce the object code needed fortesting run-time behavior of selected modules. This is the first step in verifying the code.

12) When a module has been documented and successfully compiled, unit testing can begin.

13) Retain design information as commentary in the source code. Any additional codeincluded to assist in the testing process should be readily identifiable and easy to disable, orremove, after successful testing. Care should be taken to ensure that such code does notobscure the module logic.

Attachment 4 - Suggested Standard Coding Conventions


EXAMPLE TEST LOG

1.0 Abstracted from

Test Case

1.1, 1.2, 2.0,2.1 (a, 2.2 (b

1.3

Test Process

Comments Pass/Fail

pass

Date Initials

1/2/02

1/2/02Case generated database error"Ambiguous Replace"

fail

3.0, 3.1, 3.2,3.3, 3.4, 3.5,3.6, 3.7, 4.0

. .. . ..i

2.0 Embedded in Test Process

pass 1/3/02

1.0 Each Widget will be associated with a Category only once.

TEST: Attempt to add a Widget to a second Category.

EXPECTED RESULT: Category Link attempt will Fail with error message stating onlyone category per Widget.

FAIL: Link is added or link fails but error message fails to show.

TESTER:

1.3 Resolved this failure by adding additional coding to trap for this error.

Tested On: Tested By: Pass/Fail:

Attachment 5 - Example Test Log

PROCEDURE QUALIFICATION OFLEVEL A SOFTWARE AP-SIProcedure No.: AP-SI.2Q/Rev. 1/ICN 0 Page: 8 of 28...

Documents

Transcript of PROCEDURE QUALIFICATION OFLEVEL A SOFTWARE AP-SIProcedure No.: AP-SI.2Q/Rev. 1/ICN 0 Page: 8 of 28...