234
Engineering Systems Integration
differences between what is delivered and what was required are subtle, but
oftentimes not. For example, specifying the number of lines of code for a
module may improve the overall system performance, but make the development time longer. So a typical rule is not to limit the developers in too many
ways, thereby permitting greater flexibility to achieve early testing of the
work. Once the module demonstrates proficiency in satisfying the specification “passing” the tests, and being verified as both responsive to the needs
and suitable as per the specifications, little concern is shown for reworking
the module to some additional specification (in this instance, the number of
lines of code). The developers and planners assume that if there is a performance issue that surfaces during integration, then work can be directed at
that time to deal with the issues. The particular module that is referred to in
this example may not be the one which is targeted for rework later on. In
other words, the decisions by the engineers are considered to be “good
enough” if the tests, verification, responsiveness, and suitability are demonstrated. It is very difficult to specify all that is important for the system when
the system is not demonstrable, when all the functions and their performances are known, and when all the losses that incur due to achieving those
performances are measured. What lurks in the “completed” and “acceptable”
modules only shows their combined action after the system is integrated and
most likely after it is in the hands of the user(s). It is important for systems
engineering and systems integration to estimate not only the performances
of the system’s functionalities, but also the losses that incur to achieve those
performances (Chapter 1, Principle 7). The lifecycle issues that impact on
the  users are most often of the type that come from implementing the
specifications.
Lifecycle can be seen as a structured progression from an initial beginning
state to an end state, often thought of as from inception (beginning of life) to
disposal (end of life). Lifecycle is not comprised of sequential or successive
processes. Yet, lifecycle discussions are appropriate to all processes and activities. It is instructive to consider the lifecycle of the problem, the stakeholder
needs, the development effort, the product, and the product uses. If either the
lifecycle of the problem exceeds that of the need or the need exceeds that of
the problem, the problem has been solved differently than expected. Either
there is no longer a need to solve the problem (i.e., the problem has changed
from that originally defined) or there is no longer a problem that needs solving (i.e., the problem has vanished due to circumstances). In both cases, the
problem should be redefined to determine the stakeholders who need to solve
the newly defined problem (or if there is a newly defined need that addresses
a new problem). If the lifecycle of the product is greater than that of the need,
the product is overdesigned or the market changed. If the lifecycle of the
need exceeds that of the product (solution), and the problem remains the
same, there is market opportunity for an enterprise—the hallmark of a successful lifecycle product.