104
Engineering Systems Integration
completed early in the lifetime of the project to develop a new product or
service.* Integration should not be relegated to that effort which results in a
whole by following some set of best practices. † The principles discussed in
Chapter 1 offer specific guidance on how to better perceive integration and
therefore how to apply appropriate practices. Best practices for one type of
work may not work as best practices for a different kind of work. Systems
engineering is quite different from systems integration. The planning is different, the structures are different, and the thinking is different. Systems
engineers (as others) do systems integration planning and object integration
itself. For example, integration of uncannily interactive objects is not amenable to cook-book implementation. The best chefs improve their recipes
each time they prepare a dish of food, sometimes trying new ingredients or
increasing or decreasing their amounts, and revising the cooking times.
Perfection is reached when the recipe in the chef’s head (intellectual object)
is written down (physical object) and is shown to be scalable from small to
large portions, when the customer feedback is strongest, and when the processes and procedures are time-efficient and cost-effective. Once the recipe is
worked through, tested, mapped and synchronized with kitchen processes,
and integrated with the procedures, skills, and habits of the kitchen staff,
then (and only then) will the recipe be considered a success. Unlike developing a new product or service that is (by definition) unlike the previous
project, the project team must instead rely on principles that will be applied
to the specific circumstances of the new project. For integration of a new
product or service, waiting for the component objects to be developed likely
leads to missed opportunities to demonstrate early many low-level subfunctionalities. The essential issue is recognizing when an object is ready for integration at various levels of functionality. The common, but erroneous,
perception is to “perform integration when the hardware and software components are developed and delivered by the development team.” ‡ Citing
principles from Chapter 1, Principle 5: The Principle of Forethought suggests developing a plan that includes early identification and testing of
object subfunctionalities, that is, integration begins as soon as two objects
can be integrated. Implementation of activities supporting Principle 5 can
be derived from Principle 2: The Principle of Partitioning. Identifying the
partitionable subfunctions early lowers the risk of development that results
by waiting until a subsystem or equivalent object has completed development and unit testing.
* The emphasis in this book is on developing new products and services. A few notes have
been added to deal with the differences for upgrading or integrating an existing product or
service with another product or service. These notes are by no means comprehensive or complete. They only serve to point out a few differences with that of new product development.
† For systems engineering, a best practice is iterative development and improvement. For systems engineering integration, a best practice is successive approximation based on recursive
thinking.
‡ Care has been taken to not cite references for such faux pas statements.
Engineering Systems Integration
completed early in the lifetime of the project to develop a new product or
service.* Integration should not be relegated to that effort which results in a
whole by following some set of best practices. † The principles discussed in
Chapter 1 offer specific guidance on how to better perceive integration and
therefore how to apply appropriate practices. Best practices for one type of
work may not work as best practices for a different kind of work. Systems
engineering is quite different from systems integration. The planning is different, the structures are different, and the thinking is different. Systems
engineers (as others) do systems integration planning and object integration
itself. For example, integration of uncannily interactive objects is not amenable to cook-book implementation. The best chefs improve their recipes
each time they prepare a dish of food, sometimes trying new ingredients or
increasing or decreasing their amounts, and revising the cooking times.
Perfection is reached when the recipe in the chef’s head (intellectual object)
is written down (physical object) and is shown to be scalable from small to
large portions, when the customer feedback is strongest, and when the processes and procedures are time-efficient and cost-effective. Once the recipe is
worked through, tested, mapped and synchronized with kitchen processes,
and integrated with the procedures, skills, and habits of the kitchen staff,
then (and only then) will the recipe be considered a success. Unlike developing a new product or service that is (by definition) unlike the previous
project, the project team must instead rely on principles that will be applied
to the specific circumstances of the new project. For integration of a new
product or service, waiting for the component objects to be developed likely
leads to missed opportunities to demonstrate early many low-level subfunctionalities. The essential issue is recognizing when an object is ready for integration at various levels of functionality. The common, but erroneous,
perception is to “perform integration when the hardware and software components are developed and delivered by the development team.” ‡ Citing
principles from Chapter 1, Principle 5: The Principle of Forethought suggests developing a plan that includes early identification and testing of
object subfunctionalities, that is, integration begins as soon as two objects
can be integrated. Implementation of activities supporting Principle 5 can
be derived from Principle 2: The Principle of Partitioning. Identifying the
partitionable subfunctions early lowers the risk of development that results
by waiting until a subsystem or equivalent object has completed development and unit testing.
* The emphasis in this book is on developing new products and services. A few notes have
been added to deal with the differences for upgrading or integrating an existing product or
service with another product or service. These notes are by no means comprehensive or complete. They only serve to point out a few differences with that of new product development.
† For systems engineering, a best practice is iterative development and improvement. For systems engineering integration, a best practice is successive approximation based on recursive
thinking.
‡ Care has been taken to not cite references for such faux pas statements.