220
Engineering Systems Integration
individual items mean (when it is clear what needs to be done), and paperwork that documents processes and functions (when it is clear that when an
expert is hired, all that matters is the result). The author believes it is good
practice to approach systems engineering and systems integration as key to
the science of thinking, which does not depend on luck for their results. To
this end, the systems engineering methodology is prescriptive about what
must be done and how to do it.
The development of systems engineering process models (the structure of
determining which stage of work should be done and for how long) standardized a meaningful way to consider project status, technical progress,
and the impacts of constraints on allocations of resources. There has been
neither any empirical study on the efficacy of systems engineering process
models nor an enduring debate as to the appropriateness of one model versus another given circumstances, constraints, and the kinship of project
variables with technology. The lack of foundation for systems engineering
(other than “it worked better than what was tried before”) is troubling.
Issues with Systems Engineering
As systems engineering is currently instantiated, sometimes it is limited in
terms of its capacity to consistently (1) determine the correct problem (e.g.,
through gap analysis); (2) identify critical stakeholders before architecting
the system; (3) determine the breadth and depth of requirements; (4) integrate
cross-disciplinary knowledge, and (5) account for lifecycle needs, to name a
few. A better set of data and information about the premises and limitations
of the current practice of systems engineering would aid in resolving the
issues. The common practice of systems engineering currently deals with
many problems, five of which are highlighted below:
• If systems engineering processes are employed but result in a product that does not achieve one or more of its goals—performance,
budget, or on-time completions—then the stakeholders have not
received the solution that was intended.
• Since stakeholders drive requirements, it is prudent to identify which
stakeholders most determine the driving requirements. For example, the adversary is often one of the most influential stakeholders,
and is often characterized as a “threat;” the full consideration of all
aspects of the adversary is rarely included. While the interaction
between the adversary’s radar and the surface of an aircraft will be
a paramount issue, the time line for an adversary’s decision process
is not included in the aircraft’s skin design. This time line can be
Engineering Systems Integration
individual items mean (when it is clear what needs to be done), and paperwork that documents processes and functions (when it is clear that when an
expert is hired, all that matters is the result). The author believes it is good
practice to approach systems engineering and systems integration as key to
the science of thinking, which does not depend on luck for their results. To
this end, the systems engineering methodology is prescriptive about what
must be done and how to do it.
The development of systems engineering process models (the structure of
determining which stage of work should be done and for how long) standardized a meaningful way to consider project status, technical progress,
and the impacts of constraints on allocations of resources. There has been
neither any empirical study on the efficacy of systems engineering process
models nor an enduring debate as to the appropriateness of one model versus another given circumstances, constraints, and the kinship of project
variables with technology. The lack of foundation for systems engineering
(other than “it worked better than what was tried before”) is troubling.
Issues with Systems Engineering
As systems engineering is currently instantiated, sometimes it is limited in
terms of its capacity to consistently (1) determine the correct problem (e.g.,
through gap analysis); (2) identify critical stakeholders before architecting
the system; (3) determine the breadth and depth of requirements; (4) integrate
cross-disciplinary knowledge, and (5) account for lifecycle needs, to name a
few. A better set of data and information about the premises and limitations
of the current practice of systems engineering would aid in resolving the
issues. The common practice of systems engineering currently deals with
many problems, five of which are highlighted below:
• If systems engineering processes are employed but result in a product that does not achieve one or more of its goals—performance,
budget, or on-time completions—then the stakeholders have not
received the solution that was intended.
• Since stakeholders drive requirements, it is prudent to identify which
stakeholders most determine the driving requirements. For example, the adversary is often one of the most influential stakeholders,
and is often characterized as a “threat;” the full consideration of all
aspects of the adversary is rarely included. While the interaction
between the adversary’s radar and the surface of an aircraft will be
a paramount issue, the time line for an adversary’s decision process
is not included in the aircraft’s skin design. This time line can be