229
Integration in Systems Engineering Context
different from synthesis to demonstrate the simple, but elegant, demonstration of cyclic, gravity-enabled motion. Following the footfalls of Derek
Hitchins, bottom-up integration (that “mechanistic, building-block approach,
as opposed to a holistic, organismic method, and, as such, is unable to accommodate the internal subsystem trades necessary to satisfy overall system
constraints, . . .” (Hitchins 2003)) fails to achieve a system in an efficient fashion. Integration requires synthesis to advance to a ProtaSystem and holism to
achieve the rights and features of a system. ProtaSystems do not exist without synthesis; systems do not exist without synthesis and integration—the
difference is in the degree of interactions across the boundaries of the objects.
Systems engineering requires both synthesis and integration to deliver product and service systems.
Work of the Systems engineer
The customary work of the systems engineer is to grind through the issues
of integration diligently, identifying the number and types of interfaces, the
quantities and frequencies of exchanges to assure the mechanical and electrical connections are established, the data types and flows are identified,
and the expected behaviors are planned into the work to meet stated requirements. Trying to accomplish integration in this manner is a difficult and
problematic task. Since projects rarely fail during start-up or system design,
integration is usually relegated to early planning with the bulk of the work
scheduled for later in the project. The first opportunity to observe substantial and measurable progress is during the development phase. It is here that
the first objects are built and tested. If those objects do not perform in an
acceptable manner, then the program schedule and budget should be considered at risk. The second opportunity to note significant progress is during
integration. Integration refers to the phase of bringing objects together specifically to enable functions (or their decomposed subfunctions). Nearly half
of the development budget can be spent on integration, with 80% of development and integration costs associated with software (Maier 2006). These
percentages are typical of systems engineering projects, although the actual
amounts vary widely. But as a rule of thumb passed along by systems engineers, there is a consistency across many projects. When planning for integration, the allocation of time and budget for integration often varies between
25% and 40%, indicating that the lessons learned is useful for rough planning. Depending on the amount of software (for an average-sized project),
the percentage of its allocation can be greater than 80%, depending on the
approach taken to develop, integrate, and test software. It seems straightforward to envision integration as the means for consuming a large portion
of expenditures to deliver a product or service. Integration of objects that
are insufficiently mature to have small variances in their performances
(assuming that performances of any sort are achievable) are saddled with
Integration in Systems Engineering Context
different from synthesis to demonstrate the simple, but elegant, demonstration of cyclic, gravity-enabled motion. Following the footfalls of Derek
Hitchins, bottom-up integration (that “mechanistic, building-block approach,
as opposed to a holistic, organismic method, and, as such, is unable to accommodate the internal subsystem trades necessary to satisfy overall system
constraints, . . .” (Hitchins 2003)) fails to achieve a system in an efficient fashion. Integration requires synthesis to advance to a ProtaSystem and holism to
achieve the rights and features of a system. ProtaSystems do not exist without synthesis; systems do not exist without synthesis and integration—the
difference is in the degree of interactions across the boundaries of the objects.
Systems engineering requires both synthesis and integration to deliver product and service systems.
Work of the Systems engineer
The customary work of the systems engineer is to grind through the issues
of integration diligently, identifying the number and types of interfaces, the
quantities and frequencies of exchanges to assure the mechanical and electrical connections are established, the data types and flows are identified,
and the expected behaviors are planned into the work to meet stated requirements. Trying to accomplish integration in this manner is a difficult and
problematic task. Since projects rarely fail during start-up or system design,
integration is usually relegated to early planning with the bulk of the work
scheduled for later in the project. The first opportunity to observe substantial and measurable progress is during the development phase. It is here that
the first objects are built and tested. If those objects do not perform in an
acceptable manner, then the program schedule and budget should be considered at risk. The second opportunity to note significant progress is during
integration. Integration refers to the phase of bringing objects together specifically to enable functions (or their decomposed subfunctions). Nearly half
of the development budget can be spent on integration, with 80% of development and integration costs associated with software (Maier 2006). These
percentages are typical of systems engineering projects, although the actual
amounts vary widely. But as a rule of thumb passed along by systems engineers, there is a consistency across many projects. When planning for integration, the allocation of time and budget for integration often varies between
25% and 40%, indicating that the lessons learned is useful for rough planning. Depending on the amount of software (for an average-sized project),
the percentage of its allocation can be greater than 80%, depending on the
approach taken to develop, integrate, and test software. It seems straightforward to envision integration as the means for consuming a large portion
of expenditures to deliver a product or service. Integration of objects that
are insufficiently mature to have small variances in their performances
(assuming that performances of any sort are achievable) are saddled with