243
Integration in Systems Engineering Context
For the purpose of comparing non-like-kind projects, typical of many new,
complex endeavors, integration offers a unique insight into many measures
of development. Specifically, the events of integration represent all that
has transpired during system design, architecting, and development. The
sequence of events can be represented as a Markov chain where the amount
of rework that is necessary for two objects to demonstrate requisite functionality is a strong measure of the progress toward final systems integration.
For these purposes, the amount of rework includes all the iterative actions
found predominantly before integration as well as the recursive thinking
that often occurs once integration begins. If there is a substantial percentage
of rework during physical structures, and hardware and software development, then of the primary suspect causes (i.e., ill-defined requirements and
poor functional decomposition, or poor mapping of functions to physical
entities), partitioning problems are often the most likely to persist until integration reveals the consequences of poor partitioning. This is not to say that
the other root causes of rework have been eliminated. It is only that requirements and functional analysis can be reasonably checked and reviewed to
discover and correct issues. However, poor partitioning with mapping to
physical objects is significantly more difficult to detect and will present
problems such as different coupling or cohesion than is expected across
the physical interfaces between the two objects undergoing integration.
Coupling and cohesion due to poor partitioning of lower-level functions are
not normally completely thought through either at the system design or
shown in architectural views. Rework to correct partitioning or its symptoms,
coupling, and cohesion can occur during integration rather than earlier after
development testing. Since functions are demonstrable when two objects
are integrated, the function either is not shown or is demonstrated with poor
performance. In either case, rework is required for one or both objects.
There is no reasonable, clear dividing line between development and integration and arguably development and systems integration are often one
task after the next as they intertwine during the building of objects. But there
does come a point when the elementary objects are presented and tested,
then brought to the next object for integration. The framework of integration
points out the key measures of coupling and cohesion as symptoms of
improper partitioning. The measure of reworks provides insight into the
intricacies of the development stage—an often enigmatic and vexing morass
of uncertainty and risk for developers.
The practicalities of using rework as the only indicator of progress or for
estimating purposes is much dependent on the ability of the workers to show
consistency in their actions so that their rework as a percentage of work completed can be represented as a distribution function based on the type of
work, the stage of development, their years of experience, or some other measurable variable. We refer to these factors as the unencumbered measures. In
addition, the influence of management or some other identifiable issue to
coerce the workers to deviate from their “natural” tendencies and thwart the
Integration in Systems Engineering Context
For the purpose of comparing non-like-kind projects, typical of many new,
complex endeavors, integration offers a unique insight into many measures
of development. Specifically, the events of integration represent all that
has transpired during system design, architecting, and development. The
sequence of events can be represented as a Markov chain where the amount
of rework that is necessary for two objects to demonstrate requisite functionality is a strong measure of the progress toward final systems integration.
For these purposes, the amount of rework includes all the iterative actions
found predominantly before integration as well as the recursive thinking
that often occurs once integration begins. If there is a substantial percentage
of rework during physical structures, and hardware and software development, then of the primary suspect causes (i.e., ill-defined requirements and
poor functional decomposition, or poor mapping of functions to physical
entities), partitioning problems are often the most likely to persist until integration reveals the consequences of poor partitioning. This is not to say that
the other root causes of rework have been eliminated. It is only that requirements and functional analysis can be reasonably checked and reviewed to
discover and correct issues. However, poor partitioning with mapping to
physical objects is significantly more difficult to detect and will present
problems such as different coupling or cohesion than is expected across
the physical interfaces between the two objects undergoing integration.
Coupling and cohesion due to poor partitioning of lower-level functions are
not normally completely thought through either at the system design or
shown in architectural views. Rework to correct partitioning or its symptoms,
coupling, and cohesion can occur during integration rather than earlier after
development testing. Since functions are demonstrable when two objects
are integrated, the function either is not shown or is demonstrated with poor
performance. In either case, rework is required for one or both objects.
There is no reasonable, clear dividing line between development and integration and arguably development and systems integration are often one
task after the next as they intertwine during the building of objects. But there
does come a point when the elementary objects are presented and tested,
then brought to the next object for integration. The framework of integration
points out the key measures of coupling and cohesion as symptoms of
improper partitioning. The measure of reworks provides insight into the
intricacies of the development stage—an often enigmatic and vexing morass
of uncertainty and risk for developers.
The practicalities of using rework as the only indicator of progress or for
estimating purposes is much dependent on the ability of the workers to show
consistency in their actions so that their rework as a percentage of work completed can be represented as a distribution function based on the type of
work, the stage of development, their years of experience, or some other measurable variable. We refer to these factors as the unencumbered measures. In
addition, the influence of management or some other identifiable issue to
coerce the workers to deviate from their “natural” tendencies and thwart the