لطفا منتظر باشید ...
So far I have considered only dependencies between tasks and resources. Of course, it is possible to consider dependencies that arise among tasks or among resources.
3.5.1 Simultaneity
One dependency that might be considered among tasks is simultaneity: one task might require the concurrent execution of another task, or several tasks might have to be performed all at the same time. For example, all attendees of a meeting must attend at the same time, which might be modeled as several ''attend meeting''tasks joined with a simultaneity constraint. However, this situation might instead be modeled as a ''hold meeting''task that requires multiple resources simultaneously, as discussed earlier. Similarly two people lifting a piano must lift their ends simultaneously, but again this task is probably best modeled as a lifting task that requires multiple people to perform. Uniform application of this approach eliminates the need for simultaneity dependencies, but for some cases might require the conceptual creation of an unnatural aggregate task.Other analyses of task dependencies (e.g., von Martial 1989) include additional relationships, such as a requirement that the two tasks not be performed at the same time. In our typology such relationships would be analyzed by looking for shared resources that create the restriction. For example, it might be that two tasks cannot be performed at the same time because they require the same tool. Again, this strategy eliminates the need for additional dependencies but, for some, might require the conceptual creation of a new shared resource.
3.5.2 Composition
A second possible dependency is a composition dependency: both tasks and resources can be thought of as forming decomposition hierarchies: higher-level tasks can be decomposed into subtasks, and an object into components.Given such a model of a task, planning might be viewed as a way to manage the relationship between tasks and subtasks, that is, a way to choose a set of tasks that accomplish a desired task. In the AI literature, many methods have been investigated for planning (e.g., see Allen, Hendler, and Tate 1990). For example, an engineer with a large change to implement might decompose the work into smaller changes made to several different parts, such as to different modules of the system, and then work on each of those changes independently. Similarly process engineers decompose a design into specific operations that the assembly workers can perform to assemble the cars. Alternately, an actor might proceed one step at a time, choosing a task that appears to move closer to the desired goal, performing it and then reassessing the situation.
Similarly resources might be interdependent by being connected together in some kind of assembly, such as the parts of a car or of a computer system. These interdependencies are clearly important: an essential part of change management, for example, is managing the interfaces between parts to ensure that changes to one part do not interfere with the function of another. If two tasks use different resources that are interdependent in this way, then the two tasks can be analyzed as both depending on a larger common resource. Conversely, two tasks may appear to be using a common resource because they are each dependent on components of a more complex resource. To manage these dependencies though, actors must first identify that they exist, which requires a coordination mechanism. For example, for engineering change management, engineers must spend some effort to identify which other engineers need to be informed of a proposed change to a part.
3.5.3 Integration
Finally, if multiple subtasks are performed to accomplish some effect, it may be necessary to integrate their results. This integration step is frequently viewed as a kind of coordination task. Another view is that integration is simply another part of performing the task, that is, a task is decomposed into multiple subtasks, one of which is to integrate the results. For example, an engineer who decomposes a task and requests changes from other engineers may be responsible for compiling the changes together to be submitted. In any case it is necessary to manage the producer–consumer dependencies between each of the subtasks and the integration task.
