c. Establish the sequencing of events that need to occur to demonstrate the bottom-up development of subfunctions.
d. Determine the degree of work concurrency that can be sup
ported by the project resources and satisfy the needs for devel
opment of the various subfunctions.
2. Integration scheduling
a. Schedule the dates of the events identified in Step 1.
b. Plan for and schedule the durations of both the integration work
and the events.
3. Identifying two objects that are to be integrated (object A) and
(object B)
a. Begin by first specifying the lowest level of integration for a
defined object A, where object A will become a minimum com
ponent necessary to demonstrate an identified subfunction (mul
tiple subfunctions may be possible with the defined object A,
suggesting that the integration team must decide on the integra
tion method and approach to demonstrate single or multiple
subfunctions).
b. Based on the subfunction associated with defined object A,
define an object B that will become the complementary object
that when combined with object A will provide for the demon
stration and testing of the identified subfunction. Depending
on the decision made regarding object A and single or multiple
subfunctions, object B will follow with that decision as its guid
ance for single or multiple subfunctions. However, only object
A and object B should be considered as the objects for that decisions, meaning no additional objects should be allowed to enter
into the subfunction demonstration. Should the level of detail
of the defined object A (or object B) offer more than one “oppor
tunity” for integration, the level of detail is too high and a lower
level of detail needs to be defined and used as object A (or
object B).*
* For upgrading or changing existing products or services, the level of detail for object A is
already specified and built, existing as the “as-is” determinant of object A or object B. In the
case of an upgrade or change to an existing product or service, the object added to the exist
ing product or service (object B) should be integrated one subfunction at a time. Whether the
integration should be as a completed object B with all subfunctions included depends on the
method and approach for integration testing and the desires of the stakeholders of the exist
ing product or service (object A). Should the operations of object A be critical, real-time,
involve issues of safety, then a not-in-service (but fully operational) product or service
should be used for integration. Preferences of the integration team and users (of object A)
should determine the approach for integration. However, if object A cannot be taken out of
service or a not-in-service object A is unavailable, then the subfunction should be integrated
one at a time.
121
Foundations in Systems Integration
d. Determine the degree of work concurrency that can be sup
ported by the project resources and satisfy the needs for devel
opment of the various subfunctions.
2. Integration scheduling
a. Schedule the dates of the events identified in Step 1.
b. Plan for and schedule the durations of both the integration work
and the events.
3. Identifying two objects that are to be integrated (object A) and
(object B)
a. Begin by first specifying the lowest level of integration for a
defined object A, where object A will become a minimum com
ponent necessary to demonstrate an identified subfunction (mul
tiple subfunctions may be possible with the defined object A,
suggesting that the integration team must decide on the integra
tion method and approach to demonstrate single or multiple
subfunctions).
b. Based on the subfunction associated with defined object A,
define an object B that will become the complementary object
that when combined with object A will provide for the demon
stration and testing of the identified subfunction. Depending
on the decision made regarding object A and single or multiple
subfunctions, object B will follow with that decision as its guid
ance for single or multiple subfunctions. However, only object
A and object B should be considered as the objects for that decisions, meaning no additional objects should be allowed to enter
into the subfunction demonstration. Should the level of detail
of the defined object A (or object B) offer more than one “oppor
tunity” for integration, the level of detail is too high and a lower
level of detail needs to be defined and used as object A (or
object B).*
* For upgrading or changing existing products or services, the level of detail for object A is
already specified and built, existing as the “as-is” determinant of object A or object B. In the
case of an upgrade or change to an existing product or service, the object added to the exist
ing product or service (object B) should be integrated one subfunction at a time. Whether the
integration should be as a completed object B with all subfunctions included depends on the
method and approach for integration testing and the desires of the stakeholders of the exist
ing product or service (object A). Should the operations of object A be critical, real-time,
involve issues of safety, then a not-in-service (but fully operational) product or service
should be used for integration. Preferences of the integration team and users (of object A)
should determine the approach for integration. However, if object A cannot be taken out of
service or a not-in-service object A is unavailable, then the subfunction should be integrated
one at a time.
121
Foundations in Systems Integration