22
Engineering Systems Integration
For deterministic scheduling (or pattern scheduling), that is, all that is
known regarding the task durations, the planning can be based on a
sequence vector in a time-domain set, which is optimized for costs, or
alternatively a sequence vector in a cost-domain set, which is optimized for
task times. Deterministic scheduling has the lowest impact on budgets.
Therefore, the sequencing can be defined for every task duration and need
not be dependent on a preference under either the budget or temporal constraints. The sequencing can be modeled as tasks, where every task has the
same duration but with different resource requirements and risks. The
results of such modeling in this simple case are either unrealistically simple or very dependent on the demands for resources (and as reflected in
higher risks). In this manner, integration can be modeled after aggregation
theory (Hildenbrand 2008).
A common variation of the simplest case is to develop a network model,
such as that used to plan projects. Network scheduling techniques that
are based on the theory of constraints and the concept of the critical
chain* (Goldratt and Fox 1984) and are extended by adding additional
tasks to absorb risk have the highest chance of predetermining the integration sequence and schedule. Network scheduling predicts the impacts
on budgets and schedule for various sequences and durations of objects
that are planned to be integrated. Adding additional tasks to accommodate risk is an alternative to simply padding individual task and project
estimates with what is often referred to as “management reserve.”
Management reserve can be swept up by the business enterprise, squandered on “essential” but noncritical issues, and seen as a psychological
cushion to deal with the uncertainties associated with problematic or
inept management. The management reserve is often thought of as “good
enough,” as “insurance sufficient,” or as “the lifeboat to save the project.”
However, if 8% of the management reserve is allocated at the beginning
of the project to the early identified risk areas, with the remaining 20%
retained for a second look at risk before the start of development, then the
network schedule can incorporate risk in terms of additional tasks that
are allocated according to the areas of risks, each task having budgets
and schedules. For integration planning, the sequencing of the objects is
derived from the network schedule in the same manner as with the simplistic deterministic scheduling.
Given the uncertainties associated with object development, many large
systems engineering projects are resigned to on-demand (ad hoc) scheduling with whatever objects become available. In this ad hoc fashion, integration efforts are saddled with emulators that are built to represent what an
in-progress object should be like when completed. Integration to emulators
allows a first look at the issues of integration to build subfunctions. However,
* A critical chain is “the longest chain of dependent events and takes into account both task
dependencies and resource conflicts” (Goldratt and Fox 1984).
Engineering Systems Integration
For deterministic scheduling (or pattern scheduling), that is, all that is
known regarding the task durations, the planning can be based on a
sequence vector in a time-domain set, which is optimized for costs, or
alternatively a sequence vector in a cost-domain set, which is optimized for
task times. Deterministic scheduling has the lowest impact on budgets.
Therefore, the sequencing can be defined for every task duration and need
not be dependent on a preference under either the budget or temporal constraints. The sequencing can be modeled as tasks, where every task has the
same duration but with different resource requirements and risks. The
results of such modeling in this simple case are either unrealistically simple or very dependent on the demands for resources (and as reflected in
higher risks). In this manner, integration can be modeled after aggregation
theory (Hildenbrand 2008).
A common variation of the simplest case is to develop a network model,
such as that used to plan projects. Network scheduling techniques that
are based on the theory of constraints and the concept of the critical
chain* (Goldratt and Fox 1984) and are extended by adding additional
tasks to absorb risk have the highest chance of predetermining the integration sequence and schedule. Network scheduling predicts the impacts
on budgets and schedule for various sequences and durations of objects
that are planned to be integrated. Adding additional tasks to accommodate risk is an alternative to simply padding individual task and project
estimates with what is often referred to as “management reserve.”
Management reserve can be swept up by the business enterprise, squandered on “essential” but noncritical issues, and seen as a psychological
cushion to deal with the uncertainties associated with problematic or
inept management. The management reserve is often thought of as “good
enough,” as “insurance sufficient,” or as “the lifeboat to save the project.”
However, if 8% of the management reserve is allocated at the beginning
of the project to the early identified risk areas, with the remaining 20%
retained for a second look at risk before the start of development, then the
network schedule can incorporate risk in terms of additional tasks that
are allocated according to the areas of risks, each task having budgets
and schedules. For integration planning, the sequencing of the objects is
derived from the network schedule in the same manner as with the simplistic deterministic scheduling.
Given the uncertainties associated with object development, many large
systems engineering projects are resigned to on-demand (ad hoc) scheduling with whatever objects become available. In this ad hoc fashion, integration efforts are saddled with emulators that are built to represent what an
in-progress object should be like when completed. Integration to emulators
allows a first look at the issues of integration to build subfunctions. However,
* A critical chain is “the longest chain of dependent events and takes into account both task
dependencies and resource conflicts” (Goldratt and Fox 1984).