- Briefing Room
U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
A project’s integration and verification strategy is closely tied to the design of the system and its decomposition into sub-systems. The factors that are considered when developing the sub-system design are covered elsewhere in this Guidebook. Whatever the goals were [and they vary from project to project], the Integration Plan needs to be structured to bring the components together to create each sub-system and to bring the various sub-systems together to make the whole system. Further, this needs to be done in a way that supports the deployment strategy. That is the first purpose of an Integration Plan.
The second purpose is to describe to the participants in each integration step what has to be done. The integration team has to assemble various resources for each integration step. The Integration Plan identifies the needed resources. In addition, it identifies when and where the resources will be needed.
Tailoring this Document to Your Project
An Integration Plan, at least as a separate written document, is not always needed. The complexity of the system, the complexity of the eventual deployment of the system, and the complexity of the development effort influence the decision to prepare an Integration Plan. For instance, a deployment strategy that calls for multiple installations at multiple locations can require a complex sequence of integration activities. Another common complexity of integration arises when different teams are developing the sub-systems. This is especially true when the different development teams are comprised of different contractors, each with their own contract. In this case, they need to know more about their required work to support integration than would be the case if the same development team were working both sides of the integration effort. The same type of complexity comes into play when an integration step involves external systems owned by other agencies, or at least other organizations within the agency.
If a separate Integration Plan is not warranted, the necessary planning information can be included in: the Project Plan, the SEMP, the Verification Plan and the software development plans of the development team.
Checklist: Critical Information
|Does the Integration Plan include and cover integration of all of the components and sub-systems, either developed or purchased, of the project?
|Does the Integration Plan account for all external systems to be integrated with the system [for example, communications networks, field equipment, other complete systems owned by the agency or owned by other agencies]?
|Does the Integration Plan fully support the deployment strategy. For example, when and where the sub-systems and system is to be deployed?
|Are the integration steps defined in the Integration Plan consistent with the verification activities defined in the Verification Plan?
|For each integration step, does the Integration Plan define what components and sub-systems are to be integrated?
|For each integration step, does the Integration Plan identify all the needed participants and define what their roles and responsibilities are?
|Does the Integration Plan establish the sequence and schedule for every integration step?
|Does the Integration Plan spell out how integration problems are to be documented and resolved?
INTEGRATION PLAN TEMPLATE
The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:
1.0 Purpose of Document
A brief statement of the purpose of this document. It is, the plan for integrating the components and sub-systems of the project prior to verification.
2.0 Scope of Project
This section gives a brief description of the planned project and the purpose of the system to be built. Special emphasis is placed on the project’s deployment complexities and challenges.
This section may be lifted from earlier documents. It is important only to people [stakeholders] who will be introduced to the project for the first time by this document.
3.0 Integration Strategy
This section informs the reader what the high level plan is for integration and, most importantly, why the integration plan is structured the way it is. As mentioned before, the Integration Plan is subject to several constraints, sometimes conflicting constraints. Also, it is one part of the larger process of build, integrate, verify, and deploy. All of which must be synchronized to support the same project strategy. So, for even a moderately complex project, the integration strategy, based on a clear and concise statement of the project’s goals and objectives, is described here at a high, but all-inclusive, level. It may also be necessary to describe the analysis of alternative strategies to make it clear why this particular strategy was selected.
The same strategy is the basis for the Build Plan, the Verification Plan, and the Deployment Plan. So, it may only be necessary to justify this strategy once, perhaps in the Project Plan, or in the SEMP.
This section covers and describes each step in the integration process. It describes what components are integrated at each step and gives a general idea of what threads of the operational capabilities [requirements] are covered. It ties the plan to the previously identified goals and objectives so the stakeholders can understand the rationale for each integration step. This summary level description also defines the schedule for all the integration efforts.
4.0 Phase 1 Integration
This, and the following sections, define and explain each step in the integration process. The intent here is to identify all the needed participants and to describe to them what they have to do.
In general, the description of each integration step should identify:
5.0 Multiple Phase Integration steps [1 or N steps]
This, and any needed additional sections, follow the format for section 3. Each covers each step in a multiple step integration effort.