224
Engineering Systems Integration
studied meticulously and analyzed by the U.S. Government Accountability
Office (GAO 2001). Their summary view is shown in Table 3.1.
Limits of Systems Engineering
The inability to show improvement over time in developing systems is
sometimes perceived as a suggestion (1) that systems engineering lacks a
sufficient theoretical foundation on which its practice is built, (2) that an
improved model of the underpinnings of systems engineering from systems
theory may help ameliorate the above deficiencies; and (3) that systems engineering as it is currently described and enacted does not reflect an accurate
determination of the boundaries and implications of what is possible.
Broadly considered, concepts (associated with a set of properties (Poh 1993)
and context (Aerts and Gabora 2005)) and categories (Draucker et al. 2007)
form the basic components of any structure or classification that describes
work. While some variability in how systems engineering is applied and
how the techniques are presented in books could be an issue in themselves,
there is a generally agreed set of terms in common usage with 60 years of
development history. Systems are built with lessons and practices handed
down from project to project. For example, the systems engineering body of
knowledge is scheduled for release in 2012 as a second draft for review and
broad-based comments. A body of knowledge should point out the boundaries of usefulness, the conditions under which techniques are applicable, and
when practice does not reconcile with the knowledge. The discipline of systems engineering continues in its tradition of refining its practices. Then why
should one question whether, in theory, systems engineering is the panacea
for projects with greater complexities? Is change in what we instruct and
practice necessary? These questions are generally becoming less and less
the norm as systems engineering matures. Returning to the aim of this
book, it is not that systems engineering is flawed and unacceptable, but
rather that the flaws need to be addressed so systems engineering can scale
in robustness to take on the complex problems that inevitably confront decision makers. Arguably, the key to success in any endeavor is being able to
put ideas, people, processes, and things together. That requires interaction
and integration.
The difficult problems faced yesterday have no comparison and little in
common with the problems that must be solved in the future. Systems engineering as currently practiced has great utility and is useful for solving
many problems, but it does not scale to the solutions needed tomorrow. For
example, environmental issues continue to defy solutions that have known
side effects. The populations of planet Earth have the desire for lower-cost
products and services (that challenges our quest for new and appropriate
Engineering Systems Integration
studied meticulously and analyzed by the U.S. Government Accountability
Office (GAO 2001). Their summary view is shown in Table 3.1.
Limits of Systems Engineering
The inability to show improvement over time in developing systems is
sometimes perceived as a suggestion (1) that systems engineering lacks a
sufficient theoretical foundation on which its practice is built, (2) that an
improved model of the underpinnings of systems engineering from systems
theory may help ameliorate the above deficiencies; and (3) that systems engineering as it is currently described and enacted does not reflect an accurate
determination of the boundaries and implications of what is possible.
Broadly considered, concepts (associated with a set of properties (Poh 1993)
and context (Aerts and Gabora 2005)) and categories (Draucker et al. 2007)
form the basic components of any structure or classification that describes
work. While some variability in how systems engineering is applied and
how the techniques are presented in books could be an issue in themselves,
there is a generally agreed set of terms in common usage with 60 years of
development history. Systems are built with lessons and practices handed
down from project to project. For example, the systems engineering body of
knowledge is scheduled for release in 2012 as a second draft for review and
broad-based comments. A body of knowledge should point out the boundaries of usefulness, the conditions under which techniques are applicable, and
when practice does not reconcile with the knowledge. The discipline of systems engineering continues in its tradition of refining its practices. Then why
should one question whether, in theory, systems engineering is the panacea
for projects with greater complexities? Is change in what we instruct and
practice necessary? These questions are generally becoming less and less
the norm as systems engineering matures. Returning to the aim of this
book, it is not that systems engineering is flawed and unacceptable, but
rather that the flaws need to be addressed so systems engineering can scale
in robustness to take on the complex problems that inevitably confront decision makers. Arguably, the key to success in any endeavor is being able to
put ideas, people, processes, and things together. That requires interaction
and integration.
The difficult problems faced yesterday have no comparison and little in
common with the problems that must be solved in the future. Systems engineering as currently practiced has great utility and is useful for solving
many problems, but it does not scale to the solutions needed tomorrow. For
example, environmental issues continue to defy solutions that have known
side effects. The populations of planet Earth have the desire for lower-cost
products and services (that challenges our quest for new and appropriate