| Related: |  |
|
OBJECTIVES |
· Successful installation · Operations team ready to operate and maintain the system · Uneventful deployment of the new system |
|---|---|
|
Description |
The system is installed in the operational environment and the system is transferred from the project development team to the organization that will own and operate the system. The transfer also includes support equipment, documentation, operator training, and other enabling products that support on-going system operation and maintenance. Acceptance tests are performed as part of this step to confirm that the system performs as intended in the operational environment before control is transferred. |
|
ContexT |
|
|
INPUT Sources of Information |
· Verified system, ready for installation · Acceptance Criteria |
|
PROCESS Key Activities |
· Plan for system installation and deployment · Install the system · Perform acceptance tests · Document results · Formally accept system · Deploy the new system |
|
OUTPUT Process Results |
· Installation plan and procedures · Deployment strategy · Acceptance results |
Deployment and Acceptance involves releasing the deployed system to its users. The users could be operations, maintenance, facilities, or another function at the “owner” agency. At this point, the development of the system is complete; the development team has integrated and verified they system against the requirements. While the focus shifts to the team that will operate and maintain the operational system, the development team will often have a continuing role supporting system operation through a warranty period and the development team may also play a role in validating the system in operation. Optional elements of the deployment process might include training (and delivering training materials) for specific stakeholder groups regarding the operation and/or maintenance of the new system.
Up to this point, the system may have been tested primarily in a lab environment. In this step, the system is shipped to the actual deployment site(s), installed, accepted, and transitioned to system operations and maintenance (O&M), as shown in Figure 21. Note that the nature of deployment and acceptance can vary with the type of project. For example, cloud-based software projects will have little effort in delivery, site prep, or installation. Projects that contract O&M may not have the transition between distinct teams as shown in the figure. Projects that contract separate system integrator and systems engineering contracts may have more than one “development team” to coordinate with.
Figure 21: Transition from Development Team to O&M Team
(Source: FHWA)
Larger systems may be installed in stages. For example, a closed-circuit television (CCTV) camera network may be built out incrementally over the course of several years and several projects. This may be done to spread the costs across several fiscal years or to synchronize with other construction projects in the region. In other cases, phased deployment may be performed to mitigate risk by deploying the essential core of the system and then adding features over time. If it is necessary to deploy the system in stages, whether due to funding constraints, to mitigate risk, or to synchronize with other projects, it is important to understand the dependencies between successive deployments and to prioritize the projects accordingly.
System does not successfully become operational: The risk to be managed in the deployment process is that the system is operable and maintainable by the receiving entity staffs.
This step represents the handoff of the tested system from the project team to the operations and maintenance team in the field. The following tasks are cooperatively performed to deliver, install, and deploy the system to full operational status:
Plan for system installation and deployment
Key to the systems engineering process is the advance planning, and this is especially true for delivery and installation since the system may actually change hands from the engineering team to the system owner. The first step is to create a deployment plan that clearly defines how the site will be prepared and how system will be installed, tested, and transitioned to operational status. The plan should include the validation criteria; that is, how are you going to know that the system is operating correctly? It is a good idea to include a series of checklists in the deployment plan that identify all the key pieces that must be in place and working prior to switching over to full operation. If there are still any open issues found during system test (and there likely will be), evaluate each of them to determine whether or not they should be fixed or a work-around created prior to placing the system into full operation. A formal review of the deployment plan should be held, and include the deployer, the operations team, and other key personnel.
The Deployment Plan should take into consideration
the complexity of the system, whether it will be deployed at multiple sites,
and, if so, the order of the deployments. It might be a good idea to bring up a
minimal configuration or a single installation at first and to add further
functionality and other sites once the initial installation is operational.
There are many war stories about the delivery of a system that doesn’t quite fit the installation site (e.g. server racks that wouldn’t fit through the equipment room door). For this reason, part of the planning process is to perform a site survey (physical, electrical, communications, and lighting) and possibly prepare a site survey report and site installation plan. There might be some modifications required to the site or facility in order to accommodate the system, or perhaps additional seating for personnel to operate the system. You should document any necessary site modifications in a site plan, execute the plan, and make sure the facility is ready to receive the system.
If the new system is replacing an existing system, a smooth transition should be planned, including a backup strategy to revert to the existing system just in case the new system does not operate as intended.
Install the System
The system must be physically moved from the development and test labs to the actual deployment site(s). In preparation for this, a complete set of documentation will be developed by the engineering team and coordinated with the site O&M team. This documentation will include all the logistical details for transporting the hardware and software, any facility modifications that may be necessary, personnel assignments for installation, and installation instructions.
Prior to system installation, the deployment sites must be prepared, the system must be installed at each site and tested, and operations and maintenance staff must be trained. A deployment plan should address each of these steps.
Until delivery, the system’s components – the hardware and software – were inventoried and under version control by the engineering team. Once delivered, however, ownership may change hands to the agency who will operate and maintain the system. Regardless, the engineering and operating agencies should come to agreement regarding who will maintain the inventory, the version of the software and hardware, any vendor maintenance agreements, and maintenance records.
When the system is installed at each deployment site, the operations and maintenance team should perform an initial inspection and preliminarily accept the system. This could be a formal review of the hardware/software inventory, a check of the documentation, or perhaps a start-up test. More extensive formal acceptance tests will be conducted once the system is fully installed.
Following delivery of the system to a site that has been properly prepared and modified as necessary, the system will be installed. Sometimes, problems occur during system installation – make sure you’ve included a contingency for backing out all or part of the installed system in your installation plan. Following installation, installation tests should be run to verify the system was installed correctly using documented test procedures, also included in the installation plan. You could consider including the system operators in the installation tests since they’ll be objective and will get a chance to learn more about the system.
Perform Acceptance Tests
Once the systems is installed, formal acceptance tests should be run by the customer agency It’s a good idea to tie some funding to a successful outcome.
The acceptance tests to be performed should be clearly documented in advance and agreed to by all parties. Detailed test procedures should be defined for each test to be performed. The acceptance test documentation should clearly define expected results for each test and cover what should be done in event of a test failure.
The team that will routinely operate the system
should participate in Acceptance Testing. Ideally, they should perform most or
all of the tests because developers are vulnerable to “Designer’s Bias” (e.g.,
they will never mis-interpret a system display, or hit a wrong key, etc.). If
the O&M team is to perform the acceptance tests, they should be trained on
the new system in advance.
Once the system has been initially deployed, acceptance testing will be performed to show that the system meets all the acceptance criteria defined during the Requirements step. In order to do this, acceptance test plan and procedures may need to be defined and once tests are completed, the results documented. The acceptance test plan could build upon the acceptance criteria defined earlier.
Transition to Operations
After the system has been installed successfully at the final deployment site and accepted, the next step is to transition to full operation. If this is a new, standalone system, this can be a relatively uncomplicated effort. However, if the system must interoperate with other systems – such as the case when installing new AVL software on an existing computer-aided dispatch system – additional integration and testing may be necessary. Or perhaps the new system is replacing an existing system – perhaps you are replacing an older signal control system – careful deployment planning must take place to minimize the disruption to ongoing signal operations.
When transitioning to operations,
especially when replacing an existing system, a contingency back-out plan
should be included as part of the deployment plan so that in the event the new
system does not operate correctly, you can revert to the older system until the
issues have been sorted out.
All operations and maintenance staff should be in place and properly trained. The maintenance plans for the system should be reviewed by the operations and maintenance team – check to make sure that all maintenance procedures and hardware/software maintenance records are in place, and that they are adequate to properly maintain the system.
The operational procedures and any special equipment needed to operate or monitor the system should be ready, tested, and operating correctly. It’s a good idea to take some performance measurements on the system at this stage so that you can estimate performance following transition to full operational status. Establish user accounts (if necessary), initialize databases or files as identified in the transition plan, and make sure all test data has been removed or erased. The system should be all set to begin operations.
Some transitions to full operation can
be complex, especially when replacing an existing system that many people use.
Just as we get annoyed when we can’t access the Internet for a few hours, users
may also get annoyed if your system is down for any period of time. You might
want to consider planning the transition on a weekend or in the evening, if
possible, to cause the least disruption to system users. Also consider holding
a “dry-run” so that everyone knows their role during the transition period and
performs their assigned task to make the transition as smooth as possible. If
the public may be impacted during the transition, notify them in advance and
during using all available tools (media releases, website notifications,
social-media postings) and be sure to monitor public responses. If it’s a new
system, consider a “soft-launch” strategy.
Finally, a deployment readiness review meeting should be held with the operations and maintenance team, the support personnel who are on-hand to address last-minute issues, and representatives from other interfacing systems, the project sponsor, and other key personnel. Use the checklist in the deployment plan to assess the system readiness. Only after all checklist items have been declared as “ready” should the go-ahead be given for the system to transition to full operational status.
Following transition, the team will ramp down to include only the operations and maintenance personnel with potential continued support from the development team if there is a warranty period. It might be advisable to keep a few support personnel around through the validation period so that any issues that come up in the early stages can be resolved quickly.
The primary output of this step is a completely installed product or system in a facility or site, modified as needed to meet the requirements of the product or system, and transitioned to operational status. To support this effort, the following outputs should be generated:
· A hardware and software inventory, under configuration control, including versioning information, maintenance records and plans, and other property management information
· Delivery and installation plan, including shipping notices
· Acceptance test plan and procedures
· Deployment plan with checklists
· Contingency plans
· Test issues and resolutions
· Trained O&M personnel
· Operational and maintenance procedures
Depending on various factors of the project, deployment can range from very simple to very complex. The number of deployment steps and the number of stakeholders involved in deployment are the best indicators of complexity, although there may be others of equal importance. If either of these factors warrant, then project management may decide that the expense of preparing, reviewing, and approving a Deployment Plan document is justified. For simple projects, the guidance in the PMP and in the SEMP, plus a qualified person in charge of deployment, may be sufficient.
The FHWA Regulation (23 CFR940.11) does not specifically mention initial system deployment as one of the required systems engineering analysis activities.
Acceptance documentation that shows all system requirements have been met and the O&M team is prepared to support operation and maintenance of the new system in the expected operational environment.
From a systems engineering perspective, there will be traceability or testing artifacts of this process for the system acceptance. The key artifact or deliverable of this process will be results of the acceptance testing following which there will likely be a written agreement stating that the ownership, responsibility for operation and maintenance of the system has transitioned from the development team to the system owner, subject to warranty periods and ongoing maintenance requirements.
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Has a comprehensive set of deployment goals been developed?
R Can those deployment goals be traced into the deployment strategy?
R Does the deployment strategy consider available funding?
R Does each step in the deployment strategy produce an operationally useful and maintainable deployed system?
R Does the deployment strategy minimize the risk of interference to on-going operations?
R Does the deployment strategy offer a viable operational fallback at each step of the process?
R Are all stakeholders in a deployment step aware of their roles and responsibilities?
R Are all resources needed for a deployment step available?
R Has a work-around plan been developed in case a needed resource is not available?
R Has acceptance testing been defined based on the acceptance criteria?
| Related: | |
