mod/techproject/view/concepts/associations

Remarque : cet article est en cours de rédaction. N'hésitez pas à le compléter. Veuillez utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.

Index

Associations

Certaines descriptions collectées en vue de et lors de la réalisation d'un projet visent 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 pour 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érarchies sont utilisées dans le module.

Cas général

Considérons un arbre de descriptions obtenu par rafinements successifs. Le niveau un représente des catégories racines. Le deuxième niveau des sous-catégories. le niveau trois peut être des éléments. Un élément de haut niveau inclue toutes ses dépendances (son sous-arbre). Il est rafiné par ou constitué des descriptions plus fines qui sont énoncées dans les branches inférieures.

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.