|
pragma::tims™ bietet dem Anwender ein unkompliziertes und zugleich flexibles Objektmodell. Die Grundidee des Modells ist es, eine in den meisten Projekten anzutreffende, dreistufige Projekt/System/Subsystem - Struktur zu realisieren, mit der sowohl Anforderungs- als auch Fehlerverwaltung realisiert werden kann. Die nachfolgende Abbildung zeigt in vereinfachter Form die Grundidee des pragma::tims - Objektmodells:
Ein Kunde kann beliebig vielen Projekten zugeordnet werden. Umgekehrt können Projekte auch andere Kunden betreffen (also m:n). Ein Projekt kann mehrere Systeme umfassen, die wiederum beliebig viele Subsysteme enthalten dürfen.
Ein Ticket (Sammelbegriff für Anforderungen, Fehler, Arbeitspakete etc.) ist immer genau einem Projekt zugewiesen. Ein Ticket kann ein System und ein (diesem System zugeordnetes) Subsystem betreffen. Tickets können über Präfixe typisiert werden (z.B. "def1050" würde einen Defect kennzeichnen, "fun1050" eine funktionale Anforderung - die Präfixe sind frei definierbar).
Tickets besitzen einen Standardsatz von Eigenschaften (Eingabe-/Veränderungsdatum, Titelzeile, Langbeschreibung, Kommentare usw.). Darüber hinaus können beliebig viele benutzerdefinierte ("generische") Attribute definiert werden (in Form von Eingabefeldern oder Auswahllisten). Auf diese simple Art ist pragma::tims™ leicht erweiterbar.
Die Zuordnung der Entitäten ist höchst flexibel. Es ist immer möglich, den Tickettyp zu ändern (z.B. von "def" zu "fun", was im Projektalltag als Ergebnis der Diskussion "Bug oder Feature" häufig vorkommt). Es ist also einfach, Anforderungs- und Fehlerverwaltung ohne aufwendige Schnittstellen zu Drittsystemen einfach in einem Werkzeug zu realisieren.
Die in etablierten Qualitätssicherungsmodellen geforderte Traceability zwischen Anforderungen (z.B. Benutzeranforderungen und Systemanforderungen) wird über Ticket-Beziehungen realisiert. Diese m:n - Zuordnung erlaubt eine kompromisslose und simple Nachvollziehbarkeit in einem System! Dabei können beliebige benutzerdefinierte Beziehungen vorkonfiguriert werden (z.B. "ist abgeleitet von" oder "ist Verfeinerung von").
Das Objektmodell ist von Haus aus projektspezifisch benannt. Es ist aber ohne weiteres möglich (und bereits in der Praxis erprobt), die Namensgebung anderen Arbeitsumgebungen anzupassen, die mit Softwareherstellung wenig gemeinsam haben. Beispielsweise ist eine Struktur "Kunde-Bereich-Hauptabteilung-Team" denkbar. Diese Eigenschaft macht pragma::tims™ als Workflow-Engine universell einsetzbar.
|
