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, 18.104.22.168, 22.214.171.124
in which the subnode 1.2.1 is missing.
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.