Die Projektkategorien, die Sie definieren, sind systemweit verfügbar. Dieses Konzept ermöglicht eine projektübergreifende Wiederverwendung und konsistente Klassifikation. Kennsätze für Kategorietypen (CategoryType) sind ebenfalls systemweit verfügbar. Kategorien können durch eine Sicherheitsrichtlinie gesichert werden, damit sie für einen bestimmten Benutzer verfügbar oder für diesen nicht sichtbar sind. Mit Kategorien und Kategorietypen können sie Ihr Klassifizierungssystem für Projekte modellieren. Sie können auch eine Gruppe hierarchischer Kategorien definieren, um große Systeme in kleinere, einfacher zu verwaltende Einheiten zu unterteilen.
Sicherheitsrichtlinien werden definiert, indem einem Datensatz für eine ALM-Sicherheitsrichtlinie eine oder mehrere ClearQuest-Gruppen hinzugefügt werden. Nach der Definition der Sicherheitsrichtlinie können Projektmanager ein neues Projekt erstellen und die vorhandene Sicherheitsrichtlinie, die für das Projekt benötigt wird, auswählen. Eine Sicherheitsrichtlinie muss nur dann erstellt werden, wenn eine neue Richtlinie benötigt wird.
Dieser Satztyp bestimmt, wer berechtigt ist, Projekte, Kategorien und Kennsätze zu erstellen.
Typen werden verwendet, um die Spezifik der Arbeit zu definieren. Typen gelten für Anforderungs-, Task- und Aktivitätsdatensätze. Typen werden systemweit festgelegt. Projektteams bestimmen dann durch die Erstellung einer Arbeitskonfiguration (Work Configuration), welche Typen verwendet werden sollen. Einige Beispiele für Typen sind Enhancement (Verbesserung), Defect (Fehler) und New Feature (Neues Feature).
ALMSecurityPolicy-Datensätze werden einer Kategorie und auch Projekten zugeordnet, wenn Projekte erstellt werden, die die Kategorie referenzieren. Teams, die sich mit Komponentenentwicklung befassen, verwenden möglicherweise verschiedene Komponenten, jede mit eigenen Kategorien und Releases, die ein oder mehrere Angebote bilden. In diesem Falle kann eine Eins-zu-eins-Beziehung zwischen einer Kategorie und einer Sicherheitsrichtlinie sich so auswirken, dass bestimmte Datensätze nicht von Personen gesehen werden können, für die diese Datensätze von Interesse sind. Um Probleme dieser Art zu vermeiden, sollte eine Sicherheitsrichtlinie entweder eine einzige große ClearQuest-Benutzergruppe als ratl_context_groups-Referenz enthalten oder für jede Komponente eine Benutzergruppe festlegen, wobei alle Benutzergruppen von der Sicherheitsrichtlinie referenziert werden und die Sicherheitsrichtlinie von allen Entwicklungsteams, die an Komponenten arbeiten, gemeinsam genutzt wird. Wenn Sie, anstatt eine große Gruppe zu verwenden (oder in einer Sicherheitsrichtlinie die Gruppe "Everyone" festzulegen), einen Satz kleinerer Gruppen verwenden und außerdem Gruppen und SecurityPolicy-Datensätze basierend auf der Struktur der Komponenten verwalten, wirkt sich das vorteilhaft auf die Leistung aus.
Jede versionsgesteuerte Arbeitseinheit eines Entwicklers kann ein Projekt sein mit einer Kategorie, die die Komponente angibt, und einem Release, das die Version dieser Kategorie angibt.
Es werden Aktivitäten für die ALM-Task für "ComponentZ" erstellt, und die Lösung wird entwickelt, dokumentiert und getestet. Ein ALMBaseline-Datensatz wird erstellt, wenn die eigentliche Referenzkonfiguration für Projektkategorie "ComponentZ" und Release 3.4 und eine zweite ALM-Referenzkonfiguration für Projektkategorie "OfferingA" und Release 1.1 erstellt werden und der ALMBaseline-Datensatz einen Wert für "ComposedOfBaselines" (d. h. einen anderen Baseline-Datensatz) hat, der der Projektkategorie "ComponentZ" und dem Release 3.4 zugeordnet ist.
Ein BTBuild wird für die ALM-Referenzkonfiguration mit Projektkategorie "OfferingA" und Release 1.1 erstellt. Tester können sehen, dass in den Spalten "Build" und "Composite.Build" der Entwicklungsaktivität (Dev), die im Formularsteuerelement der Taskaktivität mit Projektkategorie OfferingA und Release 1.1 angezeigt wird, ein BTBuild aufgeführt ist. Es ist zumindest die ID eines aus der kombinierten Referenzkonfiguration erstellten Builds aufgeführt, und in der Ergebnisliste der Abfrage wird der Name dieses Builds angezeigt. Sowohl die für die Komponenten zuständigen als auch die für das Angebot zuständigen Tester können sehen, dass es einen Build gibt, der auf der kombinierten Referenzkonfiguration basiert.
Im Datensatz für die kombinierte Referenzkonfiguration ist die Komponente im Feld "ComposedOfBaselines" aufgelistet.