DOE G 200.1-1 Ch 9, Installation and Acceptance Stage

Software Engineering Methodology Chapter 9.0 Installation and Acceptance Stage Table of Contents Chapter Page 9.0 Installation and Acceptance Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.0-1 9.1 Perform Installation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1-1 9.2 Conduct Installation Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2-1 9.3 Conduct User Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3-1 9.4 Conduct Acceptance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4-1 9.5 Conclude Acceptance Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5-1 9.6 Transition to Operational Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6-1 9.7 Revise Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7-1 9.8 Conduct In-Stage Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8-1 9.9 Conduct Installation and Acceptance Stage Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.9-1 Installation and Acceptance StageDOE G 200.1-1 Chapter 9.05-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.0-1 Chapter: 9.0 Installation and Acceptance Stage Description: Installation and acceptance of the software product are initiated after the system test has been successfully completed. This stage involves the activities required to install the software, data bases, or data that comprise the software product onto the hardware platform at the site(s) of operation. The objectives of the activities in this stage are to verify that the software product meets design requirements and to obtain the system owner's acceptance and approval of the software product. The activities associated with this stage should be performed each time the software product is installed at an acceptance test site or production site. User training may be required to complete the installation process. A description of the training necessary for programmers, testers, users, and operations staff is provided in the Training Plan. Input: The following items provide input to this stage: C Integration Test Materials C System Test Materials C Operating Documents - Users Manual - Programmers Reference Manual C Training Plan C Installation Plan C Conversion Plan C Acceptance Test Plan C Preacceptance Checklist C Security Checklist C Project Plan (revised) C Software Quality Assurance Plan High-Level Activities: The remainder of this chapter is divided into sections that describe the specific high-level activities performed during this stage. These activities represent the minimum requirements for a large software engineering effort. Notes are provided, as applicable, to assist in customizing these lifecycle stage requirements to accommodate the different sizes of software engineering efforts. The high-level activities are presented in the sections listed below. 9.1 Perform Installation Activities 9.2 Conduct Installation Tests Installation and Acceptance StageDOE G 200.1-1 Chapter 9.05-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.0-2 High-Level Activities, continued: 9.3 Conduct User Training

9.4 Conduct Acceptance Test 9.5 Conclude Acceptance Process 9.6 Transition to Operational Status 9.7 Revise Project Plan 9.8 Conduct In-Stage Assessment 9.9 Conduct Installation and Acceptance Stage Exit Output: Several work products are produced during this stage. The work products listed below are the minimum requirements for a large software project. Deviations in the content and delivery of these work products are determined by the size and complexity of the project. Explanations of the work products are provided under the applicable activities described in the remainder of this chapter. C Converted data or system files C Installation Test materials C User Training materials C Acceptance Test Report C Acceptance Checklist C Operational software product C Operating documents C Project Plan (revised) A matrix showing the work products associated with each high-level activity is provided in Exhibit 9.0-1, Installation and Acceptance Stage Activities and Work Products. The matrix also shows which work products are deliverables and whether they are required or optional for small, medium, and large projects. Review Process: Structured walkthroughs are necessary during this stage to validate work products. The activities that are appropriate for structured walkthroughs are identified throughout the chapter. The time and resources needed to conduct the walkthroughs should be indicated in the project resources, schedule, and work breakdown structure. Reference: Appendix C, Conducting Structured Walkthroughs, provides a procedure and sample forms that can be used for structured walkthroughs. Installation and Acceptance StageDOE G 200.1-1 Chapter 9.05-21-97 Size: L = Large Minimum Requirements: R = Required I = Input to other deliverables M = Medium A = As Appropriate = Completed by reviewer1 S = Small N = Not Appropriate Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.0-3 Exhibit 9.0-1. Installation and Acceptance Stage Activities and Work Products by Project Size Work Activity Size Work Product Scheduled L M S Deliverables L M S 9.1 Perform Installation Activities R R R Converted data or system files I I I 9.2 Conduct Installation Tests R R R Installation Test materials R R R 9.3 Conduct User Training R R R User training materials R R R 9.4 Conduct Acceptance Test R R R Acceptance Test materials R R R Acceptance Test Report R R R 9.5 Conclude Acceptance Process R R A Acceptance Checklist R R A 9.6 Transition to Operational Status R R R Operational software product R R R Operating documents R R R 9.7 Revise Project Plan R R R Project Plan (revised) R R A 9.8 Conduct In-Stage Assessment R R A ISA Report N N N1 9.9 Conduct Installation and Acceptance Stage Exit R R A Stage Exit Meeting Summary N N N Installation and Acceptance StageDOE G 200.1-1 Chapter 9.05-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.0-4 Bibliography: The following materials were used in the preparation of the Installation and Acceptance Stage chapter. 1. The Institute of Electrical and Electronics Engineers, Inc., IEEE Standard for Developing Software Life Cycle Processes, IEEE Std 1074-1991, New York, 1992. 2. U.S. Department of Commerce, National Institute of Standards and Technology, Guide to Software Acceptance, 500-180, Washington, D.C., 1990.

3. U.S. Department of Energy, Automated Data Processing Systems Development Methodology, Volume 1, K/CSD/INF/86-3, Vol.1,R3, prepared under contract by Martin Marietta Energy Systems, Inc, at Oak Ridge National Laboratory, August 1987. 4. U.S. Department of Energy, DOE/NV Software Management Plan, Nevada Operations Office, May 1991. 5. U.S. Department of Labor, Directorate of Information Resources Management, Systems Engineering Concepts and Procedures Manual, 1988. 6. U.S. Department of Labor, Directorate of Information Resources Management, Systems Engineering Standards Manual, 1988. Installation and Acceptance StageDOE G 200.1-1 9.1 Perform Installation Activities5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.1-1 Activity: 9.1 Perform Installation Activities Responsibility: Project Team Description: The installation process involves loading, copying, or migrating the software and data, if required, to the production platform and the provision of operating documentation and other support materials at each site. The installation of firmware, hardware, and telecommunications equipment may also be involved. If a current system exists, implement system and data conversion in accordance with the procedures described in the Conversion Plan. Each data and file conversion should include a confirmation of data and file integrity. Determine what the output in the new software product should be compared with the current system, and assure that the data and files are synchronized. At each installation site, inspect the facility to assure that site preparation is complete and in accordance with the Installation Plan. Initiate any actions that are needed to complete the preparations. Conduct an inventory of all vendor provided hardware, software, firmware, and telecommunications equipment in accordance with the Acquisition Plan. Follow the procedure specified in the Installation Plan when installing the software, hardware, and other equipment. Monitor all installation activities including those performed by vendors. Procedure: Use the following procedure to perform the installation activities. C Coordinate the installation with the system owner, users, operations staff, and other affected organizations. C Ensure that any necessary modifications to the physical installation environment are completed. C Inventory and test the hardware that will support the software product. This inventory should be performed in advance of the planned installation date to allow time for missing hardware to be obtained and malfunctioning equipment to be replaced or repaired. C If the software product requires an initial data load or data conversion, install and execute the tested programs to perform this process. C Install the software product onto the hardware platform. Installation and Acceptance StageDOE G 200.1-1 9.2 Conduct Installation Tests5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.2-1 Activity: 9.2 Conduct Installation Tests Responsibility: Project Team Description: Ensure the integrity and quality of the installed software product by executing the installation tests defined in the Installation Plan. Testing is performed to verify that the software product has been properly installed and is fully operational.

The installation test(s) are designed to validate all functions of the software product and should specify a standard set of test results and tolerances. If the software product being installed is a modification to an existing system, all remaining functions and code that may be affected by the new software should be tested. Document any problems and identify corrective action. Select a diagnostic package that will pinpoint problems quickly and allow for timely corrections. Retest all equipment and software after a repair, replacement, or modification. Certify each software component on successful completion of installation and checkout. When installation is complete, rerun a portion or all of the system test and dry-run the acceptance test procedures to verify correct operation of the software product. Conduct installation testing to verify the following: C Security functions C Integration with the current software C Interfaces with other systems C System functionality based on the requirements Work Product: Place a copy of all Installation Test materials in the Project File. Installation and Acceptance StageDOE G 200.1-1 9.3 Conduct User Training 5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.3-1 Activity: 9.3 Conduct User Training Responsibility: Project Team Description: User training is an important factor in the success of the operational software product. During training, most users will receive their first hands-on experience with the software product. Operations and maintenance staff may also be trained to use, monitor, and maintain the software product. The objective of the training is to provide the trainee with the basic skills needed to effectively use the software product and to raise the user's confidence and satisfaction with the product. The type of training will depend on the complexity of the software product, and the number and location of the users to be trained. Alternative training formats include formal classroom training, one-on-one training, computer-based instruction, and sophisticated help screens and online documentation. Conduct the training as described in the Training Plan. Consider conducting a pilot test of the training session(s). Include members of the project team, the system owner, and key users. Have all participants evaluate the training content, instruction, and support materials. Make any necessary changes to the training program prior to general user training sessions. If consecutive training classes are conducted, feedback should be requested from the participants and used to continuously improve the training approach, methods, and materials. At the completion of the training, users should have a thorough understanding of the input requirements of each transaction, the processing that takes place, and the types of output that are generated. Work Product: Submit a copy of the training materials to the system owner and user for review and approval. Place a copy of the approved training materials in the Project File. Training materials are subject to the same configuration control procedures as the other operating documents and should remain current with changes to the software product. Installation and Acceptance StageDOE G 200.1-1 9.4 Conduct Acceptance Test5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.4-1 Activity: 9.4 Conduct Acceptance Test Responsibility: Acceptance Test Team

Description: Acceptance of a delivered software product is the ultimate objective of a software development project. Acceptance testing is used to demonstrate the software product's compliance with the system owner's requirements and acceptance criteria. At the system owner's discretion, acceptance testing may be performed by the project team, by the system owner and users with support from the project team, or by an independent verification and validation team. Whenever possible, users should participate in acceptance testing to assure that the software product meets the users' needs and expectations. All acceptance test activities should be coordinated with the system owner, user(s), operations staff, and other affected organizations. Acceptance testing is conducted in the production environment using acceptance test data and test procedures established in the Acceptance Test Plan. Testing is designed to determine whether the software product meets functional, performance, and operational requirements. If acceptance testing is conducted on an incremental release basis, the testing for each release should focus on the capabilities of the new release while verifying the correct operation of the requirements incorporated in the previous release. Acceptance testing usually covers the same requirements as the system test. Acceptance testing may cover additional requirements that are unique to the operational environment. The results of each test should be recorded and included as part of the project test documentation. Subject the test environment to strict, formal configuration control to maintain the stability of the test environment and to assure the validity of all tests. Review the acceptance test environment, including the test procedures and their sequence, with the system owner and user before starting any tests. Testing is complete when all tests have been executed correctly. If one or more tests fail, problems are documented, corrected, and retested. If the failure is significant, the acceptance test process may be halted until the problem is corrected. Installation and Acceptance StageDOE G 200.1-1 9.4 Conduct Acceptance Test5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.4-2 Work Product: Prepare a formal Acceptance Test Report. Summarize the test procedures executed, any problems detected and corrected, and the projected schedule for correcting any open problem reports. Place a copy of all acceptance test materials in the Project Test File. Review Process: Conduct an Operational Readiness Review at the completion of acceptance testing. This review is a combined quality assurance and configuration management activity. It focuses on the results of the acceptance test and the readiness of the software product to go into production. During the Operational Readiness Review examine acceptance test results with the system owner and user. Document any problems, determine solutions to the problems, and implement action plans. Once any problems associated with the acceptance test are resolved, the software product is ready for formal acceptance by the system owner. A successful Operational Readiness Review establishes the operational baseline for the software product. The baseline consists of the software product and the technical documentation that describes the operational software and its characteristics. Installation and Acceptance StageDOE G 200.1-1 9.5 Conclude Acceptance Process5-21-97

Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.5-1 Activity: 9.5 Conclude Acceptance Process Responsibility: Project Manager Description: The acceptance process is used to officially accept new or modified software products that satisfy the users' requirements and are fully operational. The acceptance process is concluded when the acceptance test has been successfully completed, the software product has been installed and is operational at all user sites, and complete operating documentation describing the product has been approved and delivered. At the conclusion of the acceptance process, responsibility for the software product is formally transferred from the project team to the system owner and maintenance staff. Procedure: Use the following procedure to conclude the acceptance process. C The project manager notifies the Quality Assurance representative assigned to the project that the software product is ready to complete the acceptance process. C The Quality Assurance representative sends the Acceptance Checklist to the project manager. C The project manager completes the checklist, obtains the concurrence signature of the system owner (if required), and returns the completed checklist to the Quality Assurance representative. C The Quality Assurance representative schedules an acceptance meeting. More than one meeting may be necessary to accommodate users at different locations or with varying requirements. Work Product: The Acceptance Checklist is completed and submitted to the Quality Assurance representative supporting the project. This list helps to ensure that all necessary acceptance activities have been completed and that the required operating documents were developed and approved. A sample Acceptance Checklist is provided on the following page. A formal written acceptance of the software product is produced by the system owner to verify that the software product is acceptable and ready for production. Installation and Acceptance StageDOE G 200.1-1 9.5 Conclude Acceptance Process5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.5-2 Sample Acceptance Checklist [Software Product Name] The Acceptance Checklist provides a final check to determine that everything is in place prior to the system being turned over to the system owner and maintenance staff. Instructions: The project manager must indicate completion of each item with a checkmark, obtain the concurrence signature of the system owner, and return the completed checklist to the Quality Assurance representative assigned to the project. Any deviations from the checklist must be documented and a copy attached to the checklist. Yes Not Applicable 9 9 Maintenance programmer data base access has been assigned. 9 9 File protection rules have been modified to permit access to the system by maintenance programmers. 9 9 File protection rules have been modified to remove project team and other temporary user access from further access to the system. 9 9 Any software installed on testbeds or other platforms for acceptance testing has been removed and any file modifications such as to autoexec.bat and config.sys have been restored. 9 9 Project team and other individuals having temporary data base access passwords have been deleted. 9 9 Final operating documentation has been distributed. 9 9 List of any planned enhancements has been sent to the Quality Assurance representative.

9 9 Programs, files, and other support software are in the production library and have been deleted from the test library, where appropriate. 9 9 All current program compiles, files, and other software have been reviewed and turned over to the maintenance staff. 9 9 Load library matches source library. System Owner Concurrence (if required) I concur that all of the above items have been completed, the system is acceptable as delivered, and the system is ready to be turned over to the maintenance staff. Any deviations from this checklist have been documented and approved. __________________________________ System Owner Installation and Acceptance StageDOE G 200.1-1 9.6 Transition to Operational Status5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.6-1 Activity: 9.6 Transition to Operational Status Responsibility: Transition Team Description: The transition of the software product to full operational status begins after the formal acceptance by the system owner. Use the procedures described in the Transition Plan to implement the transition processes. Conduct or support stress tests and other operational tests. Determine product tolerances to adverse conditions, failure modes, recovery methods, and specification margins. Complete any training and certification activities. Ensure that support to be provided by contractors begins as planned. The project team is usually expected to provide operational and technical support during the transition. Identify project team personnel with a comprehensive understanding of the software product who can provide assistance in the areas of software installation and maintenance, test, and documentation of changes. Technical support may involve the analysis of problems in software components and operational procedures, the analysis of potential enhancements, and vendor- supplied upgrades to software components (such as the operating system or data base management system). Transition to full operational status should be an event-oriented process that is not complete until all transition activities have been successfully performed. Withdraw the support of the project team personnel in a gradual sequence to ensure the smooth operation of, and user confidence in, the software product. At the conclusion of the transition process, plan a formal transfer of all responsibility to the maintenance staff. All Project File materials, operating documents, and other pertinent records should be turned over to the maintenance staff at this time. For major software systems involving multiple organizations and interfaces with other systems, a formal announcement of the transition to production is recommended. The announcement should be distributed to all affected groups. The names and telephone numbers of the maintenance staff should be included. Installation and Acceptance StageDOE G 200.1-1 9.7 Revise Project Plan5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.7-1 Activity: 9.7 Revise Project Plan Responsibility: Project Manager Description: Once system installation and acceptance are complete, determine if the project estimates for resources, cost, and schedule need to be revised. Work Product: Review the Project Plan for accuracy and completeness of all Installation and Acceptance Stage activities and make any changes needed to update the information. Expand the information for the Maintenance Stage to reflect accurate estimates of resources, costs, and hours. Place a copy of the revised Project Plan in the Project File.

Note: A Project Plan is an effective management tool that is recommended for all projects regardless of size. The plan can be consolidated for small projects. Review Process: Conduct a structured walkthrough to ensure that the Project Plan reflects the project's current status and adequately estimates the resources, costs, and schedule for the Maintenance Stage. The Project Plan is formally reviewed during the In-Stage Assessment and Stage Exit processes. Installation and Acceptance StageDOE G 200.1-1 9.8 Conduct In-Stage Assessment5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.8-1 Activity: 9.8 Conduct In-Stage Assessment Responsibility: Project Manager and Independent Reviewer Description: An In-Stage Assessment (ISA) is an independent review of the work products and deliverables developed or revised during each stage of the project lifecycle. The independent reviewer is typically a member of the Quality Assurance Team who is assigned to the software project and conducts all of the ISAs for the project. An ISA does not require meetings with, or extra work by, the project team. All of the work products and deliverables needed for the review should be readily available in the Project File. Schedule at least one ISA prior to the Installation and Acceptance Stage Exit process. Additional ISAs can be performed during the stage, as needed. Provide the reviewer with copies of all work products developed or revised during the Installation and Acceptance Stage including the Project Plan. The reviewer assesses the work products and deliverables to verify the following: C The project is complying with the site's software engineering standards/ best practices. C Sound project management practices are being used. C Project risks are identified and mitigated. A description of the ISA process and the ISA report form are provided in the In- Stage Assessment Process Guide. A copy of the guide is provided in Appendix D. Note: An ISA is an effective project management tool that is recommended for all projects regardless of size. Work Product: An ISA report form is prepared by the independent reviewer and is used to identify open issues that need to be resolved in this stage. The report is delivered to the project manager and a copy should be placed in the Project File. Installation and Acceptance StageDOE G 200.1-1 9.9 Conduct Installation and Acceptance Stage Exit5-21-97 Date: March 1996 Installation and Acceptance Stage Page Rev Date: 9.9-1 Activity: 9.9 Conduct Installation and Acceptance Stage Exit Responsibility: Project Manager Description: The Stage Exit is a process for ensuring that projects are on target, within budget, on schedule, and meet the DOE and project standards identified in the Project Plan. The goal of a Stage Exit is to secure the approval of designated key individuals to continue with the project and to move forward into the next lifecycle stage. Schedule the Stage Exit as the last activity of the Installation and Acceptance Stage. It is the responsibility of the project manager to notify the appropriate participants when a project is ready for the Stage Exit process and to schedule the Stage Exit meeting. All functional areas and the Quality Assurance representative involved with the project should receive copies of the work products and deliverables produced in this stage.

During the Stage Exit meeting, participants discuss open issues that will impact the Project Plan. The project manager should ensure that an acceptable action plan is developed for handling all open issues. At the conclusion of the meeting, concurrence is needed from the designated approvers to begin the next stage. A description of the Stage Exit process is provided in the Stage Exit Process Guide. A copy of the guide is provided in Appendix E. Note: A Stage Exit is an effective project management tool that is recommended for all software projects regardless of size. For small software projects, stages can be combined and addressed during one Stage Exit. Work Product: A summary of the Stage Exit meeting is prepared by the project manager or a designee and distributed to the meeting attendees. The summary identifies any issues and action items needed to obtain concurrence prior to proceeding to the Maintenance Stage.