247
Integration in Systems Engineering Context
lifecycle is more than a structured progression; however, we apply our intentions. Rather, lifecycle presents as a piece-wise continuous succession marked
by recursive, iterative processes and not that which is posed as discrete,
independent stages where processes are kempt and respectable. No stage of
a lifecycle or its totality satisfies this Utopian model. Yet, a lifecycle perspective makes sense in this regard if we allow discrete activities to recapitulate
and update previous findings. Posing lifecycle as the primary orchestration
and organization of systems engineering in itself is not new. The systems
engineering process models do in fact regiment the overall view of a product
in terms of lifecycle stages. But what is new is the discussion on lifecycle
through the portal of the fundamentals of integration. Lifecycle is active
within the framework of integration, rather than being the framework in
which integration is performed. While it seems intuitive that integration
occurs throughout the lifecycle, it is more accurate to consider lifecycle as a
continuum of integration. In fact, lifecycle is the result of integration. Without
integration, no process would show emergence, and product functions would
be self-governing and separate. This autonomy would perhaps reinforce
interactions, but would by definition not result in integration. Every process,
every function, and even the physical space that encompasses the domain of
interest exist only because of interaction and integration, both necessary for
a system. Integration requires interaction, but interaction does not imply
integration. Lifecycle is merely the temporal interpretation of integration.
Introduction to Defining the Problem
Systems engineers attach great significance to defining terms. Every project
has a litany of words and phrases that have specific meaning to people working
on the project. The explicit and expressed meaning of a word needs to be
clear and definitive about its uses, its opposites, and its causes, as well as
be descriptive of the thing (Swartz 1997), its model, or its representation.
The results of well-defined (i.e., nonoverlapping, nonunderlapping) terms
will be fewer errors made in judgment, fewer mistakes made due to miscommunication, less cause for variation from expectations, and agreed limitations that will be shown respect. Typical of the interaction between buyer
and seller, defined terms are an agreement, a normative means by which to
work within a zone of comfort. Outside the definition is uncertainty, and
inside the definition is assurance that others will appreciate and understand
the meaning. You might say that without proper limitations and constraints,
the words you use might create a problem for others. But this characterization
of a problem incorrectly attributes the problem to the notion that by not
using an agreed-to (or prerationalized) definition, a problem is created. This
situation by itself does not pose a problem. In fact, the listener might simply
Integration in Systems Engineering Context
lifecycle is more than a structured progression; however, we apply our intentions. Rather, lifecycle presents as a piece-wise continuous succession marked
by recursive, iterative processes and not that which is posed as discrete,
independent stages where processes are kempt and respectable. No stage of
a lifecycle or its totality satisfies this Utopian model. Yet, a lifecycle perspective makes sense in this regard if we allow discrete activities to recapitulate
and update previous findings. Posing lifecycle as the primary orchestration
and organization of systems engineering in itself is not new. The systems
engineering process models do in fact regiment the overall view of a product
in terms of lifecycle stages. But what is new is the discussion on lifecycle
through the portal of the fundamentals of integration. Lifecycle is active
within the framework of integration, rather than being the framework in
which integration is performed. While it seems intuitive that integration
occurs throughout the lifecycle, it is more accurate to consider lifecycle as a
continuum of integration. In fact, lifecycle is the result of integration. Without
integration, no process would show emergence, and product functions would
be self-governing and separate. This autonomy would perhaps reinforce
interactions, but would by definition not result in integration. Every process,
every function, and even the physical space that encompasses the domain of
interest exist only because of interaction and integration, both necessary for
a system. Integration requires interaction, but interaction does not imply
integration. Lifecycle is merely the temporal interpretation of integration.
Introduction to Defining the Problem
Systems engineers attach great significance to defining terms. Every project
has a litany of words and phrases that have specific meaning to people working
on the project. The explicit and expressed meaning of a word needs to be
clear and definitive about its uses, its opposites, and its causes, as well as
be descriptive of the thing (Swartz 1997), its model, or its representation.
The results of well-defined (i.e., nonoverlapping, nonunderlapping) terms
will be fewer errors made in judgment, fewer mistakes made due to miscommunication, less cause for variation from expectations, and agreed limitations that will be shown respect. Typical of the interaction between buyer
and seller, defined terms are an agreement, a normative means by which to
work within a zone of comfort. Outside the definition is uncertainty, and
inside the definition is assurance that others will appreciate and understand
the meaning. You might say that without proper limitations and constraints,
the words you use might create a problem for others. But this characterization
of a problem incorrectly attributes the problem to the notion that by not
using an agreed-to (or prerationalized) definition, a problem is created. This
situation by itself does not pose a problem. In fact, the listener might simply