Datensatzeinstellungen

Sie können systemweite Einstellungen für Satztypen verwenden, um Sicherheitsrichtlinien für Arbeitsprozesse einfacher verwalten, kategorisieren und anwenden zu können.
Die folgenden systemweiten Einstellungen sind für die Verwaltung von Projekten und Arbeitsvorgängen vorgesehen:

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.

Beispiel für Komponentenentwicklung

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.

Angenommen, ein Kunde findet einen Fehler in einem größeren Produkt, das von einem Entwicklungsteam entwickelt wurde. Dieses Produkt, nachfolgend als Angebot bezeichnet, umfasst verschiedene Komponenten, die jeweils von eigenständig arbeitenden Teams entwickelt wurden. Wenn der Kunde den Fehler erkennt, so nimmt er ihn wahrscheinlich als einen Fehler im Angebot wahr und nicht als einen Fehler, der in einer Komponente des Angebots aufgetreten ist. Wenn der Teamleiter den Triage-Prozess für eine Anforderung ausführt, die sich auf dieses Angebot bezieht, wird er Folgendes feststellen:
  • Der Fehler ist einer Komponente aufgetreten, die im Angebot enthalten ist, und muss auch in der Komponente behoben werden. Das Angebot ist möglicherweise nur eine Sammlung von Komponenten und hat abgesehen vom Code der einzelnen Komponenten keinen eigenen Code.
  • Das Angebot muss nach der Fehlerbehebung die neue Version der Komponente angeben. Dem Kunden, der den Fehler entdeckt hat, muss eine neue Version des Angebots zur Verfügung gestellt werden. Wahrscheinlich gilt das auch für alle anderen Kunden.
Das Triage-Team erstellt zwei ALMTask-Datensätze, die der ALM-Anforderung (ALMRequest) zugeordnet sind, die für eine bestimmte Kategorie und ein bestimmtes Release des Projekts eingegeben wurde (z. B. Category = 'OfferingA' und Release = '1.0'):
  • ALMTask mit folgenden Werten: Project Category = 'OfferingA' und Release = '1.1'
  • ALMTask mit folgenden Werten: Project Category = 'ComponentZ' und Release = '3.4'
Das Triage-Team hat zuerst den ALMBaseline-Datensatz für Projektkategorie "OfferingA" und Release 1.0 überprüft, weil diese Werte bei der ALM-Anforderung als "FoundInProject" ermittelt wurden. Dabei hat es festgestellt, dass "ComponentZ" im Feld "ComposedOfBaselines" des ALMBaseline-Datensatzes dem Release 3.3 zugeordnet ist.

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.


Feedback