Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : mod/techproject/view/concepts/associations, celle pour les versions 3.x de Moodle est consultable ici : mod/techproject/view/concepts/associations et celle pour Moodle 4.x est consultable là : mod/techproject/view/concepts/associations.

mod/techproject/view/concepts/associations

De MoodleDocs
Révision datée du 10 mai 2007 à 22:57 par Valery Fremaux (discussion | contributions)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à :navigation, rechercher

Associations

Certaines descriptions collectées en vue de et lors de la rélisation d'un projet vise la même partie du problème. Les spécifications sont très souvent relatives à des attendus du projet, les tâches sont planifiées pour accomplir telle ou telle partie des spécifications, la réalisation d'une tâche peut contribuer à produire tel ou tel livrable.

Les associations permettent de tisser des liens entre les différentes unités d'un projet de telle sorte que des indicateurs puissent être automatiquement calculés et des contrôles effectués sur l'avancement du travail en cours. Assigner des unités à d'autres unités permettre une navigation fluide à travers les descriptions de projet, permettra au module de générer des vues de synthèse sur le projet nécessaire à la maîtrise du temps et de l'effort, même pour des têches complexes.

Associations entre entités arborescentes

Les principes de gestion de projet peuvent paraître obscurs aux néophytes, et l'architecture des descriptions techniques peut se révéler rapidement complexe. Ce module permet d'obtenir une vue plus claire d'une telle complexité, et propose des outils simples et agréables pour la gérer.

La gestion des associations demande néanmoins quelques explications sur la façon dont ces hiérachies sont utilisées dans le module.

Cas général

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.

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 should have not linked here, but to lower nodes.

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

Step one of the techproject module do 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.