|
pragma::tims™ offers a straight-forward object model. Its philosophy is based on the observation that the vast majority of software development projects need three object layers: project, system and sub-system. This structure is sufficient for requirements management as well as for defect tracking. The following illustration shows the simplified pragma::tims object model:
A customer can be assigned to many projects. Inversely, a project may also concern many different customers (thus we have a “m:n” relationship). A project may manage one or more systems, which in turn may consist of one or more sub-systems. A ticket ("ticket" means any token, like requirements, defects, tasks etc.) is always assigned to exactly one project. It can concern a system and a sub-system, both being components of the main system. Tickets classes are defined through their prefixes (e.g. “def1050” would stand for a “defect ID 1050”; if changed to “fun,” the ticket 1050 would nominally become a functional requirement). Tickets possess a standard set of attributes (input/change date, headline, long description, comments, etc.). In addition, the administrator can define an arbitrary number of additional “generic” attributes (each being a text field or a customized dropdown list). This makes pragma::tims nearly limitlessly extendible.
The flexible prefix-based ticket classification is one of the greatest benefits of pragma::tims. It makes it possible at anytime to change the ticket class from “feature” to “defect” – making it easy to quickly re-define any ticket's class. Just think of the never-ending discussions: “is it a defect or a feature?” Since all ticket types are managed in just one tool, no costly and error-prone interfaces are needed (e.g., between requirements management and defect tracking tools) because here is only one tool for all tasks.
The prefix-based ticket classes and the advanced pragma::tims ticket reference management feature (it is shown in the above illustration as a m:n cyclical relationship on the ticket symbol) implement the requirements' traceability, e.g., between features and the derived system requirements. Thus, pragma::tims meets the requirements of the established quality assurance models, such as CMMI. The pragma::tims ticket references resolve this requirement in an elegant way. In addition, ticket-to-ticket-relationships can be freely customized and classified, e.g., the administrator can define a new reference type as “is from” or “is a derived refinement of” for traceability purposes.
The pragma::tims object label names are designed to support any software development project. It is, however, easy (and already in practice tested) to adapt the naming to other working environments which have little to do with the software industry. For example the standard structure may be renamed to “customer/organizational unit/department/team.” This feature makes pragma::tims universally applicable as a workflow engine.
|
