272
Engineering Systems Integration
System design focuses on the functional nature of the interactions between
the product or service and the user. While system design does not impose an
architecture (which establishes the relations between the structural components, e.g., physical entities, computer hardware, and computer software),
system design poses alternatives that could be considered as solving the
stated problem to some varying degrees. The match of the system design
alternatives to the most effective solution to the posed problem is a matter for
analyses and evaluations which then become some of the guidance for the
architectural alternatives. System design will tend to provide a general-level
perspective of the product or service through varying levels of detail down
to the component level. The iterations of design will result in the allocation
of requirements first to subsystems, then to assemblies, then to subassemblies, and then to components.*
An item that is a unit (the lowest level of an object that results from work)
can be tested. The decision to test at the unit level is fundamentally based on
the model of testing used on the project. Based on a study of development
teams across several industries, Wheelwright and Clark (Wheelwright and
Clark 1992) suggest that a design–build–test strategy seems to be more effective in creating an air of confidence in people’s work. This confidence is clearly
ill-founded as substantial amounts of rework are necessary throughout a
development cycle. Consequently, projects must develop a rework strategy
with procedures, inspections, and accommodations for revising work plans,
schedule, milestones, and budgets. Selecting an aggregation of units and
components for testing at a higher level eliminates low-level tests. The counterargument from the engineer is that testing provides visibility into how
well the work matches with expectations. The point is that expectations are
often incorrect and while correcting work to match with expectations is satisfying, it is ruinous with regard to schedule and budget. From an object’s
point of view, its design and implementation are only testable in conjunction
with another object, whose combination results in a function. If both objects
were built and tested to expectations, but the desired function was not demonstrated, then one or both objects have a problem with mechanism(s), outputs, or inputs. With perfect execution of the work (as assumed in this
discussion), the design is faulty. Detecting faulty designs quickly is essential
for remaining within schedule and budget constraints and argues for building to functionality. The argument that without perfect execution the functions were not demonstrable is specious. Poor execution of the work to build
an object that is deficient in some way may only reduce the performance
value of the functions, but may still demonstrate the function. The key issue
of what to test is not determined by testing all that can be tested, but rather
testing what needs to be tested. Sometimes it is simply better to plug the
* Projects vary as per their terminology for different levels of work. Here, components are
meant to be an element of a larger whole, that is above the individual part and the aggregation of parts into a unit. Components are aggregations of units.
Engineering Systems Integration
System design focuses on the functional nature of the interactions between
the product or service and the user. While system design does not impose an
architecture (which establishes the relations between the structural components, e.g., physical entities, computer hardware, and computer software),
system design poses alternatives that could be considered as solving the
stated problem to some varying degrees. The match of the system design
alternatives to the most effective solution to the posed problem is a matter for
analyses and evaluations which then become some of the guidance for the
architectural alternatives. System design will tend to provide a general-level
perspective of the product or service through varying levels of detail down
to the component level. The iterations of design will result in the allocation
of requirements first to subsystems, then to assemblies, then to subassemblies, and then to components.*
An item that is a unit (the lowest level of an object that results from work)
can be tested. The decision to test at the unit level is fundamentally based on
the model of testing used on the project. Based on a study of development
teams across several industries, Wheelwright and Clark (Wheelwright and
Clark 1992) suggest that a design–build–test strategy seems to be more effective in creating an air of confidence in people’s work. This confidence is clearly
ill-founded as substantial amounts of rework are necessary throughout a
development cycle. Consequently, projects must develop a rework strategy
with procedures, inspections, and accommodations for revising work plans,
schedule, milestones, and budgets. Selecting an aggregation of units and
components for testing at a higher level eliminates low-level tests. The counterargument from the engineer is that testing provides visibility into how
well the work matches with expectations. The point is that expectations are
often incorrect and while correcting work to match with expectations is satisfying, it is ruinous with regard to schedule and budget. From an object’s
point of view, its design and implementation are only testable in conjunction
with another object, whose combination results in a function. If both objects
were built and tested to expectations, but the desired function was not demonstrated, then one or both objects have a problem with mechanism(s), outputs, or inputs. With perfect execution of the work (as assumed in this
discussion), the design is faulty. Detecting faulty designs quickly is essential
for remaining within schedule and budget constraints and argues for building to functionality. The argument that without perfect execution the functions were not demonstrable is specious. Poor execution of the work to build
an object that is deficient in some way may only reduce the performance
value of the functions, but may still demonstrate the function. The key issue
of what to test is not determined by testing all that can be tested, but rather
testing what needs to be tested. Sometimes it is simply better to plug the
* Projects vary as per their terminology for different levels of work. Here, components are
meant to be an element of a larger whole, that is above the individual part and the aggregation of parts into a unit. Components are aggregations of units.