Aquesta pàgina forma part de la documentació de Moodle en català, tot i que no ha estat traduïda encara. Podeu contribuir obertament a les tasques de traducció. Podeu consultar la Guia d'edició de la documentació i també participar ens els debats del fòrum de traductors de la documentació a moodle.org

mod/techproject/view/concepts/entitiesandunits

De MoodleDocs
Salta a:navegació, cerca
La versió per a impressora ja no és compatible i pot tenir errors de representació. Actualitzeu les adreces d'interès del navegador i utilitzeu la funció d'impressió per defecte del navegador.

Index

Project Entities

The Technical Project Manager module uses a unique representation to store descriptions of what makes a project : the autonumbering tree_shaped entity representation.

A description entity is a treeset of entries, each one able to be indefinitely divided into sub-entites. Thus requirements might be divided into sub-requirements, specifications into sub-specifications, tasks into sub-tasks and deliverable description into sub-deliverables down to a single ressource.

The "Milestone" is the only one which is list-shaped.

Entities are autonumbering i.e. it will renumber automatically entries using a hierarchical numeric numbering starting from 1 within each level. Numbering is uniform :

  • The sub-entry just following a level N entry WILL be at level N+1, and will be locally numbered starting from 1.
  • Numberings of successive entries within the same sub-branch will be in following order.

Thus the tree :

1, 1.1, 1.2, 1.2.1, 1.2.2, 1.3

is legal, conversely to such illegal tree :

1, 1.1, 1.2, 1.2.1.1, 1.2.1.2

in which the subnode 1.2.1 is missing.

Project Units

Entities contain project units. These units are "nodes" within the tree shaped within the entity. Units hold a description, that may be refined by sub-nodes. Units may be leaves of the tree (so they have no subdivisions) or branch nodes.

A leaf entity is so called effective entity. Most commonly, effective units describe simple objects, real effective tasks to be performed, or deliverable resources. Non terminal nodes often will be used as categories, super-categories, and so on, allowing nice semantic and meaningful organization of such final resources.

Advantages and Versatility of Such a Model

We did not even try to formalize or preset in any way the "mapping" of each entity. Each context may apply its own organisation strategy, accounting with the local culture and management habits. Above concepts are commented to help understanding the module organization and behaviour, but may be completely and hopely be twisted out of their initial meaning.