303
Systems Integration Management
For integration efforts that involve significant software work, a more agile
approach is sometimes adopted (Smartt and Ferreira 2011). The hallmark of
agility is to adapt (self-organize) the engineering activities to compensate for
the delays that have arisen during development. Both the plan-driven and
the agile-driven strategies to integration illustrate the inadequate predictability of increasingly complex system developments. The lack of the systems engineering tools and their abilities to adequately plan and diagnose
the development effort for integration problems is readily apparent in the
strategies and methods currently used. For simple engineering integrations,
the plan-driven strategy suggests that complexity (multiple interactions
across the three kinds of boundaries: physical, functional, and behavioral) is
a key driver. When software is added to the project, neither the engineering
tools nor the systems engineering tools appear adequate. Integration is considered to consume the major portion of expenditures and is held as the most
likely cause of project problems.
To implement a strategy of planned integration while maintaining the
agility to adapt the sequencing of components and subsystems, the strategy
should be considered a policy that delineates all the actions required for integration in the integration plan. Integration planning should be mandatory,
not optional based on a perception of simplicity or fitting within a “normal”
routine. The reason: interactions can lead to integration—some interactions
are desired, perhaps some are not.
Integration Planning Concepts
Planning integration means more than just allocating time to various activities or sequencing those activities. Planning is predicated on the development
team working in an incremental fashion to (1) build the objects that are specified at the onset of the specification stage in the lifecycle process model,
(2) evaluate the functionality and performance(s) of those objects through
testing and modeling, (3) predict the adjustments that need to be made to the
objects associated with the next event (e.g., testing, simulation, and modeling), (4) broaden the scope of what is learned to all threads of objects that are
planned for development, and (5) determine the limit for applying what is
learned. Planning for integration is the distributing of tasks that reflect what
is known to be necessary but includes the ability to adapt to what is sufficient.
As tasks are assigned (according to a model of integration), the task manager
is responsible for ensuring that subtasks are allocated and completed successfully. The task manager must collaborate with other task mangers so that
the lessons learned from the patterns of integration can be shared. Each task
and subtask should have a deliverable, and each task should have an entry in
a log that is maintained current on a daily basis. The accuracy of planning
Systems Integration Management
For integration efforts that involve significant software work, a more agile
approach is sometimes adopted (Smartt and Ferreira 2011). The hallmark of
agility is to adapt (self-organize) the engineering activities to compensate for
the delays that have arisen during development. Both the plan-driven and
the agile-driven strategies to integration illustrate the inadequate predictability of increasingly complex system developments. The lack of the systems engineering tools and their abilities to adequately plan and diagnose
the development effort for integration problems is readily apparent in the
strategies and methods currently used. For simple engineering integrations,
the plan-driven strategy suggests that complexity (multiple interactions
across the three kinds of boundaries: physical, functional, and behavioral) is
a key driver. When software is added to the project, neither the engineering
tools nor the systems engineering tools appear adequate. Integration is considered to consume the major portion of expenditures and is held as the most
likely cause of project problems.
To implement a strategy of planned integration while maintaining the
agility to adapt the sequencing of components and subsystems, the strategy
should be considered a policy that delineates all the actions required for integration in the integration plan. Integration planning should be mandatory,
not optional based on a perception of simplicity or fitting within a “normal”
routine. The reason: interactions can lead to integration—some interactions
are desired, perhaps some are not.
Integration Planning Concepts
Planning integration means more than just allocating time to various activities or sequencing those activities. Planning is predicated on the development
team working in an incremental fashion to (1) build the objects that are specified at the onset of the specification stage in the lifecycle process model,
(2) evaluate the functionality and performance(s) of those objects through
testing and modeling, (3) predict the adjustments that need to be made to the
objects associated with the next event (e.g., testing, simulation, and modeling), (4) broaden the scope of what is learned to all threads of objects that are
planned for development, and (5) determine the limit for applying what is
learned. Planning for integration is the distributing of tasks that reflect what
is known to be necessary but includes the ability to adapt to what is sufficient.
As tasks are assigned (according to a model of integration), the task manager
is responsible for ensuring that subtasks are allocated and completed successfully. The task manager must collaborate with other task mangers so that
the lessons learned from the patterns of integration can be shared. Each task
and subtask should have a deliverable, and each task should have an entry in
a log that is maintained current on a daily basis. The accuracy of planning