System Transition
As part of system deployment, on-site installation, check-out, integration, and testing must be carried out to ensure that the system is fit to be deployed into the field and/or put into an operational context. Transfer is the process that bridges the gap between qualification and use; it deals explicitly with the handoff from development to logistics, operations, maintenance, and support.
Definition & Purpose
There are many different approaches to transition, or deployment, and many different views on what is included within transition. The SEBoK uses the ISO/IEC/IEEE 15288 definition of transition, as seen below (2008):
[The transition] process installs a verified system, together with relevant enabling systems, e.g., operating system, support system, operator training system, user training system, as defined in agreements. This process is used at each level in the system structure and in each stage to complete the criteria established for exiting the stage.
Thinking in a linear fashion, the system is transitioned into operation and then would be used and maintained in the operational environment. However, there are other views on transition. For example, the NASA Systems Engineering Handbook states that transition can include delivery for end-use as well as delivery of components for integration (NASA 2007). Using this view, transition is the mechanism for moving system components from implementation activities into integration activities. The NASA discussion of transition also implies that transition can include sustainment activities:
The act of delivery or moving of a product from the location where the product has been implemented or integrated, as well as verified and validated, to a customer.
Many systems are deployed using an iterative or evolutionary approach where operationally useful capabilities are developed and deployed incrementally. While these operationally useful capabilities are fully deployed and transitioned into operational use, transition of logistics, maintenance, and support may occur incrementally or be delayed until after the full system capability is delivered.
Process Approaches
Just as there are multiple views on the definition of transition and deployment, there are also several ways to divide the activities required for transition. For example, the NASA Systems Engineering Handbook definition of transition states: “This act can include packaging, handling, storing, moving, transporting, installing, and sustainment activities” (2007). However, the SEBoK includes the topic of "sustainment" as separate from transition; this is instead covered under the maintenance and logistics topics. The International Council on Systems Engineering (INCOSE) views the transition process as two-step: planning and performance. Though there are several processes for deployment and transition, most generally include the following activities as a minimum:
- Develop a Deployment/Transition Strategy. Planning for transition activities would ideally begin early in the SE life cycle, though it is possible to conduct these activities concurrently with realization activities. Planning should generally include some consideration of the common lower-level activities of installation, checkout, integration, and testing. Such activities are crucial to demonstrate that the system and the interfaces with the operational environment can function as intended and meet the contractual system specifications. For these activities to be effectively managed and efficiently implemented, the criteria, responsibility, and procedures for carrying out these activities should be clearly established and agreed upon during the planning phase.
- Develop Plans for Transitioning Systems or system capabilities into operational use and support. Transition plans for the system or incremental system capabilities should be consistent with the overall transition strategy and agreed to by relevant stakeholders. Planning for transition will often include establishing a strategy for support, which may include organic support infrastructures, contractor logistics support, or other sources (Bernard 2005, 1-49). It can also include defining the levels of support to be established. The strategy is important because it drives most of the other transition planning activities, as well as product design considerations. Transition plans should include considerations for coordination with the following activities:
- Installation. Installation generally refers to the activities required to physically instate the system; this will likely include connecting interfaces to other systems such as electrical, computer, or security systems, and may include software interfaces as well. Installation planning should generally document the complexity of the system, the range of environmental conditions expected in the operational environment, any interface specifications, and human factors requirements such as safety. When real-world conditions require changes in the installation requirements, these should be documented and discussed with the relevant stakeholders.
- Integration. Though system integration activities will generally be performed prior to installation, there may be additional steps for integrating the system into its operational setting. Additionally, if the system is being delivered incrementally, there will likely be integration steps associated with the transition (for more information on integration, please see the System Realization knowledge area (KA)).
- Verification and Validation (V&V). At this stage, V&V for physical, electrical, and mechanical checks may be performed in order to verify that the system has been appropriately installed. Acceptance tests conducted after delivery may become part of this process (for additional information on V&V, please see the System Realization KA). There are several types of acceptance tests which may be used:
- On-site Acceptance Test (OSAT). This test includes any field acceptance testing and is performed only after the system has successfully been situated in the operational environment. It may consist of functional tests to demonstrate that the system is functioning and performing properly.
- Field Acceptance Test. This test includes flight and sea acceptance tests; it is performed, if applicable, only after the system has successfully passed the OSAT. The purpose of field testing is to demonstrate that the system meets the performance specifications called for in the system specifications in the actual operating environment.
- Operational Test and Evaluation (OT&E). An OT&E consists of a test series designed to estimate the operational effectiveness of the system.
- Evaluate the readiness of the system to transition into operations. This is based upon the transition criteria identified in the transition plan. These criteria should support an objective evaluation of the system’s readiness for transition. The integration, verification, and validation (IV&V) activities associated with transition may be used to gauge whether the system meets transition criteria.
- Analyze the results of transition activities throughout and any necessary actions. As a result of analysis, additional transition activities and actions may be required. The analysis may also identify areas for improvement in future transition activities.
Some common issues that require additional considerations and SE activities are the utilization or replacement of legacy systems. It is also common for an organization to continue testing into the early operational phase. The following activities support these circumstances:
- System Run-in. After the successful completion of the various acceptance tests, the system(s) will be handed over to the user or designated post-deployment support organization. The tested system(s) may have to be verified for a stated period (called the system run-in, normally for one to two years) for the adequacy of reliability and maintainability (R&M) and integrated logistics support (ILS) deliverables. R&M are vital system operational characteristics having a dominant impact upon the operational effectiveness, the economy of in-service maintenance support, and the life cycle cost (LCC).
- Phasing-In/Phasing-Out. The need for phasing-in will usually be identified during the system definition, when it is clear that the new system entails the replacement of an existing system(s) (for additional information, please see the System Definition KA). These activities should help to minimize disruption to operations and, at the same time, minimize the adverse effect on operational readiness. It is also important that the phasing-in of a new system and the phasing-out of an existing system occur in parallel with the systems activities of the system run-in to maximize resource utilization. Other aspects of phasing-in/phasing-out to be considered include
- Proper planning for the phasing out of an existing system (if necessary),
- For multi-user or complex systems, phase-by-phase introduction of the system according to levels of command, formation hierarchy, etc.
- Minimum disruption to the current operations of the users,
- Establishment of a feedback system from users on problems encountered in operation, etc., and
- Disposal process including handling of hazardous items, cost of disposal, approval etc.
Applicable Methods & Tools
A system may have to undergo reliability demonstration testing (RDT) to ensure that it meets its contractual R&M guarantees. RDT is conducted under actual field conditions, especially for large systems purchased in small quantity. During RDT, the system is operated in the field within stated test duration and all field data are systematically recorded. At the end of the test period, analysis of the RDT data is performed. Data analysis should facilitate determination of system reliability. One possible output of this analysis is shown in Figure 1 below.
References
Works Cited
Bernard, S. 2005. An Introduction To Enterprise Architecture: Second Edition. Bloomington, IL, USA: AuthorHouse.
ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
Primary References
INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
Additional References
None.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus