Note: You are currently viewing documentation for Moodle 3.3. Up-to-date documentation for the latest stable version of Moodle is probably available here: mod/techproject/view/concepts/associations.

mod/techproject/view/concepts/associations

From MoodleDocs

Index

Mappings (Associations)

Many of the descriptions that are collected while performing a project are describing some identical part of a project. Specifications are often related to requirements, tasks are accomplishing or implementing some specifications, task completion will produce some deliverables.

Mappings describe dependancies between entity units so that automatic checks can be performed about work being done. Assigning units to other will allow smooth browsing within all the project descriptions, and will allow the module to generate overall monitoring views that will provide time and effort control, even on a quite complex job.

Mapping within a tree-shaped entity

Project management concepts are quite tricky to neophyt, and descriptors are often of complex architecture. The module helps getting a better view of such a complexity, and will provide practical tools to manage it.

Mapping within trees needs to know somewhat about how the hierarchies are used.

General Case

Consider a three-level refinement tree. Level one are root categories. Level two are subcategories. Level three are items. A root level element includes all its subtree. It is refined by or made of the more detailed elements within this branch.

techproject tree theory 1.gif

Now let consider another three-level refinement tree, sharing same level concepts than former.

We can now imagine we would like to link any unit of the latter to some unit in the former. If we choose a quite general unit, we consider that nearly all the subelements do contribute to the association with the source unit, even if our source unit is very specialized. If some of the subunits do not cope the association rule, we would not have linked here, but to lower nodes.

techproject tree theory 2.gif

In the above figure, we can affirm that if Node realizes an entity entry, its Subnodes will realize it too as Subnodes are constitutive of the Node.

Here comes an essential conclusion : When a unit from a tree-shaped entity is associated to a unit within another tree, it cannot be associated to any other unit in the descendance nor ascendance of the actual target.

Step one of the techproject module does not check this rule. Step 2 will do.

Mappings : requirements to specifications

Requirements will map to specifications in that sense specifications are descriptions of the technical subset that will realize requirements.

Mappings : specifications to tasks

Specifications will map to tasks in that sense tasks are descriptions of the action we planned for getting some system subset constructed, realizing relevant specifications.

Mappings : tasks to deliverables

Tasks will map to deliverables in that sense deliverables are produced as a result of relevant tasks.

A special case : tasks to tasks

Tasks will map to other tasks because some action may need another one being previously performed. We call this task interdependancy.