U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Integration is an iterative process:
Integration planning starts when the project activities are first defined. The next major input occurs when the sub-systems are identified during the high-level design and project architecture step. Finally, integration is performed when the hardware and software components are developed and delivered by the development team. Integration and verification are closely linked processes in which one follows the other until the entire system is ready for operational deployment.
A complex project may need a written Integration Plan. Integration activities are driven by:
Integration activities are performed iteratively along with verification.
CONTEXT OF PROCESS:
Concept of Operations describes the way the system is to operate and will assist in the verification and integration effort.
System and Sub-system Requirementscontain the requirements for the sub-systems / systems.
High Level Design [project architecture] defines the integration activities to be performed.
Component Level Detailed Design contains the design constraints for the sub-systems/systems to be integrated.
Deployment Strategy defines when and where the sub-systems are to be grouped and deployed.
Developed hardware / software components and sub-systems have completed integration and are ready for the next level of verification.
Project Plan/SEMP establishes a high level description of the systems engineering plan for integration.
Configuration Management Plan sets the configuration controls needed during integration.
Stakeholder involvement is needed to assist with integration with external systems and devices.
Integration Master Plan establishes the goals and high level approach to integration.
Integration Plan [optional] documents the high level plan and process for integrating the system. This is part of the Project Plan/System Engineering Management Plan [SEMP].
Integrated sub-systems / system means they are ready for verification.
Plan integration activities:
Planning includes the sequence in which the various components of the system should be integrated, the needed resources, schedule, and coordination activities [if multiple development teams are involved], and the documented plan itself. A number of factors influence the integration sequence, including the order in which components and sub-systems are produced by the development team[s].
Each integration step should produce a product that implements a related set of functionality. For example, an operator interface may be integrated with a loop data collection function before the loop data function is integrated with an incident management function.
Define integration activities:
At the high level design [project level architecture] integration activities are defined. Sub-systems, internal interfaces, and external interfaces are defined. They are the key points for integration. Also, at the high level design, the number of integration/verification cycles are defined.
Perform integration activities:
The first step is to ensure that the integration team has access to the resources needed to support the planned integration step. Special attention has to be paid to resources that come from outside integration team's organization. These could include: support from the developers or manufacturers, support from other agencies with an external interface, a testing environment [e.g. workstations, communications, and interface simulators.], and, of course, the various sub-systems to be integrated.
As integration proceeds, issues are monitored through periodic reviews as follows:
As the cycle of integration and verification is repeated, lessons learned during a verification step may have to be fed into the next round of integration. Integration should be complete enough that subsequent verification proceeds with minimum disruption.
Where does Integration take place in the project timeline?
Is there a policy or standard that talks about integration?
FHWA Final Rule does not specifically mention integration as one of the required systems engineering analysis activities. EIA 731 and CMMI have identified best practices for integration.
Which activities are critical for the system's owner to do?
How do I fit this step to my project? [Tailoring]
There are a number of factors which make a project complex. The same factors that influence other steps in the systems engineering process also influence the integration process.
Integration of sub-systems with external interfaces is nearly always required.
The major impact on tailoring the integration process is the degree of formality needed to verify compliance with requirements to stakeholders. The simpler the system, the smaller the project team and the fewer the number of external stakeholders [stakeholders with systems that interface with the target system], the less formal the integration process needs to be.
What should I track to reduce project risk and to get what is expected? [Metrics]
Checklist: Are all the bases covered?
|Are integration activities included in the master project schedule?|
|Does the plan for integration and verification support the strategy for deployment?|
|Based on project complexity, is a written Integration Plan required?|
|Are the external systems needed to support integration available, or does the interface need to be simulated?|
|Have the components to be integrated been placed under configuration control?|
|Are the development teams available to promptly fix problems uncovered during integration?|
Are there any other recommendations that can help?
The importance of a good strategy and verification of design:
Develop a good integration strategy: A successful integration process is based on a sound strategy which will give it direction and completeness. This same strategy will be needed to guide the verification and initial deployment activities. This strategy is based on a set of goals that were established early in the planning stages of the project. These goals answered the following questions:
Of course that last goal, spending the available funds in the most effective manner, is usually the hardest to solve. Since these goals are related to deployment, this subject will be revisited in Chapter 3.6.4. Nevertheless, the integration plan, as well as the design, must be fashioned to meet these deployment goals.
As has been stated before, "integration is a more informal activity than verification". As such, the preparation of detailed plans and procedures is generally not required. In fact, if such structure is felt to be necessary, the procedures used for subsequent verification can also be used as part of the integration activity. Thus, the verification dry-run [see the verification chapter] could also be seen as part of the integration effort.
Verification of design:
Integration is more than a verification of requirements; it is also a verification of the design. It explores the details of both the hardware and software. It needs, for instance, to look at hardware and software interfaces at a much lower level than just exercising the functional requirement.
Generally, this informal integration approach is effective since it avoids the costs of more formal documentation. Still, it needs to be carefully monitored. It needs adequate project support. It also needs the right people on the integration team.
A closer look at integration and verification and levels of integration
Integration and verification are iterative processes with each other. Integration puts a sub-system [or system] together from components [and/or other sub-systems], and informally assures that everything is working as it should in accordance with the requirements. Verification formally tests the assembled system [or sub-systems] to show that all applicable requirements are met. The figure shows this cycle and how it is repeated until the entire system can be accepted.
Levels of integration means that the levels of integration needed for a system will match the number of levels of the system hierarchy. For example, a traffic control system would have the following 3 levels of hierarchy.
More complex systems may have additional levels of hierarchy and integration. For example, in regional ITS, the traffic control system example above may need to integrate with a freeway ramp metering system for coordination. This would represent a fourth level of integration and so on.
Figure 3-13 Integration and Verification are Iterative