20
Engineering Systems Integration
ments are left unstated, as they are sometimes assumed. Systems engineers
are trained to focus on the task at hand (as reinforced by the systems engineering process models) and most find it expedient to not think too far
ahead as the current work is most demanding. However, planning for integration alleviates problems that surface during integration that are caused
by ineffectual measurements, trade-offs that show preference for one
design or a particular decision versus another, and ill-conceived schedule
or allocation of resources to overcome technical problems. Moreover, if the
allocated baseline changes (occasionally, frequently, or continually), the
integration plan will no longer hold the advantage of being the plan, but
will be subjugated to a piece of historical rhetoric of no utility or value
(Collens and Krause 2004).
Reliability of the product and service is based on the aggregation of the
reliability of the product or service components in addition to the interactions of the components. Developing the aggregate reliability of a group of
objects begins with forethought about the system design. That forethought
includes exploratory thinking about how to produce a system design that
carries with it a set of meaningful alternatives (meaningful from the perspectives of the different stakeholders, such that each alternative emphasizes
a major component of a stakeholder’s needs and position on requirements).
When selecting a system design, these meaningful alternatives help determine the context for further exploration of the design space. Often, these discussions surface additional requirements, modify the concept of operations,
and sometimes suggest not so subtle changes in the systems architecture.
Integration planning carries those system design parameters through architecting and development with the aim of preparing the objects for integration. Incorporating object reliability into the integrated structures is not an
afterthought (Ferris 2007).
In those instances of product or service development of a large effort in
which integration includes a great number of transfers of data across subsystem interfaces or in support of the interfaces with users, integration planning
is substantially more than merely identifying, designing, and managing
interfaces. The semantic architecture (the structures, interactions, and preferences that are made meaningful by data that is made interoperable by the
design and implementation of the system objects) exposes information relevant to the user, a portion of which is presented to the user either in summary fashion or in the form of an analytical depiction of key results. Greater
than half of the software in a project can be integral to the user interface
(Oliver et al. 1997 citing Brown 1988).
At best, this technique of building systems is a guess at building objects
so that performances are met. Support for this practice comes from technology that has been shown to move data at sufficient rates and quantities
that many such transfers are done within reasonable periods. In other
words, the users have not complained too much. Modeling and simulation
certainly help in the determination of meeting performances but the
Engineering Systems Integration
ments are left unstated, as they are sometimes assumed. Systems engineers
are trained to focus on the task at hand (as reinforced by the systems engineering process models) and most find it expedient to not think too far
ahead as the current work is most demanding. However, planning for integration alleviates problems that surface during integration that are caused
by ineffectual measurements, trade-offs that show preference for one
design or a particular decision versus another, and ill-conceived schedule
or allocation of resources to overcome technical problems. Moreover, if the
allocated baseline changes (occasionally, frequently, or continually), the
integration plan will no longer hold the advantage of being the plan, but
will be subjugated to a piece of historical rhetoric of no utility or value
(Collens and Krause 2004).
Reliability of the product and service is based on the aggregation of the
reliability of the product or service components in addition to the interactions of the components. Developing the aggregate reliability of a group of
objects begins with forethought about the system design. That forethought
includes exploratory thinking about how to produce a system design that
carries with it a set of meaningful alternatives (meaningful from the perspectives of the different stakeholders, such that each alternative emphasizes
a major component of a stakeholder’s needs and position on requirements).
When selecting a system design, these meaningful alternatives help determine the context for further exploration of the design space. Often, these discussions surface additional requirements, modify the concept of operations,
and sometimes suggest not so subtle changes in the systems architecture.
Integration planning carries those system design parameters through architecting and development with the aim of preparing the objects for integration. Incorporating object reliability into the integrated structures is not an
afterthought (Ferris 2007).
In those instances of product or service development of a large effort in
which integration includes a great number of transfers of data across subsystem interfaces or in support of the interfaces with users, integration planning
is substantially more than merely identifying, designing, and managing
interfaces. The semantic architecture (the structures, interactions, and preferences that are made meaningful by data that is made interoperable by the
design and implementation of the system objects) exposes information relevant to the user, a portion of which is presented to the user either in summary fashion or in the form of an analytical depiction of key results. Greater
than half of the software in a project can be integral to the user interface
(Oliver et al. 1997 citing Brown 1988).
At best, this technique of building systems is a guess at building objects
so that performances are met. Support for this practice comes from technology that has been shown to move data at sufficient rates and quantities
that many such transfers are done within reasonable periods. In other
words, the users have not complained too much. Modeling and simulation
certainly help in the determination of meeting performances but the