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.
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.
Considérons maintenant un autre arbre de rafinement, dont on peut penser que le principe de construction ressemble au précédent.
Nous pouvons maintenant imaginer vouloir associer une unité du deuxième arbre à une unité du premier (par exemple, une spécification définissant la réponse à un attendu). Si nous choisissons d'arriver sur une unité assez générale, nou pouvons penser que toutes ses sous-unités participent à l'association avec la source, même si cette source est un élément très spécialisé. Si certains détails de cette unité d'arrivée ne convenaient pas pour cette association, nous n'aurions pas fait aboutir la liaison à cet endroit, mais à un endroit plus détaillé de cette branche.
C'est là qu'apparait une conslusion essentielle : Lorsqu'une unité d'une entité arborescente par rafinement est associée à une unité d'un autre arbre, elle ne peut plus être liée à une quelconque autre unité sur la même branche (toutes les sous-branches et la portion de branche qui remonte jusqu'à la racine).
La version 1 du module techproject ne vérifie pas cette règle rigoureusement. La version 2 le fera.
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.
