D1 4.1, 4.2 - Activity networks and precedence tables
Build activity-on-arc networks from immediate-precedence tables and read those tables back from networks. You will use dummy activities only where needed, preserving the dependencies without accidentally creating new ones.
Activities are arrows; events are milestones
A team can begin editing after filming, while a clearance meeting must wait for both filming and a rights check. How can one network show that difference without making editing wait for the rights check too? A zero-duration dummy arrow can carry the extra dependency without representing extra work.
You already know
An arrow has a direction. A project rule such as “publish after filming and the rights check” means both tasks must have finished before publishing starts. No earlier Decision Mathematics lesson is needed here.
An activity is a task. In an activity-on-arc network, each real activity is represented by a labelled directed arc. A node represents an event, a milestone reached only when every activity entering it has finished.
The number beside an event is an identifier, not a task duration. Later we will place early and late event times in stacked boxes; here the event numbers simply let us describe the connections precisely.
Immediate precedence
An immediate predecessor of an activity is an activity whose completion is required directly before that activity can start. A precedence table lists immediate predecessors, not every earlier ancestor.
A dash means there is no predecessor. A list such as means both must finish; it does not mean a choice between them.
Use one start event and one finish event. Put an arrowhead on every arc, including a dummy. There must be no directed cycle: following dependencies cannot bring a task back to waiting for itself. In the standard representation, two activities must not have the same starting and finishing event pair.
Arcs can cross on paper without joining. A connection exists only at a marked event; positions and drawn lengths do not set durations.
Key idea
An event is an “all finished” junction. Merging two activities' end events makes every activity leaving that junction wait for both.
Check the meaning of a merge before drawing one.
Build the direct dependencies first
Start with the activities having no predecessors. Work through the remaining rows, choosing an event that represents exactly the required completed activities. Join the terminal branches at one finish.
The construction rules are not supplied in the formula booklet. Learn to check them by tracing dependencies, rather than memorising a particular drawing.
[DIAGRAM: asset_name: Two precedence networks without dummy activities; asset_slug: 9fm0-d1172-basic-networks; caption: An extra activity can share a start event without changing the other dependencies; description: Two labelled activity-on-arc networks are shown. The left has event arcs A from 1 to 2, B from 1 to 3, C from 2 to 3 and D from 3 to 4. The right adds E from 2 to 4. Every solid arc has an arrowhead and activity label. Events are numbered circles, with one start and one finish in each panel. B takes the lower horizontal route, clear of the diagonal A and C arcs.]
Worked example 1: a merge with no dummy
Question. Draw the network for this immediate-precedence table.
| Activity | Immediately preceding activities |
|---|---|
| — | |
| — | |
Plan. Start together; put after ; merge before .
An arc list defining the left-hand network is
| Activity | Start event | Finish event |
|---|---|---|
Why this step? Event waits for , exactly as 's row requires. Event waits only for , so can start independently of .
Answer. The left-hand pictured network, with no dummy activities.
Check. Reading backwards from each activity gives the four original rows. is an ancestor of , but not an additional immediate predecessor because is between them.
Add only one activity, , immediately after . It can share 's start event without being made to wait for .
Worked example 2: an extra branch
Question. Add the row to the previous table and draw the new network.
Plan. Keep the four existing arcs and draw from the event reached after to the common finish.
The existing arcs remain .
Why this step? Starting from event would incorrectly make it wait for . Its only required predecessor is .
Answer. The right-hand pictured network, with no dummy.
Check. Event finishes the project only after both terminal activities finish; it imposes no dependency between those activities.
Readiness to start and the project being finished are different milestones. Sharing a finish event does not mean two tasks have to finish at the same clock time; the event waits for the later completion.
Watch out
Wrong: turn a precedence row into a chain by placing every listed predecessor one after another. Right: listed predecessors may run in parallel; the successor simply waits for all of them.
Move the extra activity to a different place in the original four-activity project.
A dummy carries a dependency without adding work
A dummy activity is a dashed directed arc of zero duration. It uses no worker and represents no real task. Its job is to carry a precedence requirement or distinguish two activity event pairs.
Suppose requires only, while requires . Merging the ends of immediately would incorrectly make depend on . Keep the end of separate and send a dummy from it to the event where starts.
The dummy's zero-duration convention and construction rules are not in the formula booklet.
[DIAGRAM: asset_name: A dummy preserves a partial dependency; asset_slug: 9fm0-d1172-dependency-dummies; caption: C can follow A alone while D waits for both A and B; description: The left directed network has A from 1 to 2, B from 1 to 3, a dashed dummy from 2 to 3, C from 2 to 4 and D from 3 to 4. The right network adds E after D by using D from 3 to 4, E from 4 to 5 and C from 2 to 5, retaining the same dummy. All dummy and real arcs have arrowheads. The separated end of A is clearly visible.]
Worked example 3: the opening dependency pattern
Question. Draw a network with the minimum number of dummies for initially available, immediately after , and immediately after both .
Plan. Preserve an event for alone, then use a dummy to create the later merge.
| Arc | Start | Finish |
|---|---|---|
| Dummy | ||
Why this step? The dummy points from the completed- event towards the merge. Reversing it would make 's end event wait for , spoiling 's independence.
Answer. The left-hand pictured network, with exactly one dummy.
Check. can start as soon as finishes, even if is unfinished; cannot. Zero dummies cannot preserve both requirements with distinct events, while the one shown is sufficient.
Add only a final task after ; remains a terminal branch.
Worked example 4: the dependency survives an extension
Question. Extend the previous project with immediately after , using the minimum number of dummies.
Plan. Keep the dummy and split 's end from the final project finish.
Why this step? must wait for , but must not wait for . The common finish is therefore after , not before .
Answer. The right-hand pictured network, still with just one dummy.
Check. The new row is ; all original immediate-precedence rows remain unchanged.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account