Issue Tracking in Produktlinien

Viele Firmen organisieren ihre Produktpalette in Produktlinien, d.h. Gruppen von zusammengehörigen Produkten. Produkte bestehen dann aus gemeinsam genutzten Teilen (“Commonalities”) sowie produkt-spezifischen Teilen (“Specialities”). Dieser Artikel beleuchtet die Herausforderung eines systematischen Issue Tracking in solchen Produktlinien.

Tritt in einem Produkt ein Fehler auf, können davon auch andere Produkte betroffen sein. Dies ist der Fall, wenn Fehler ihre Ursache in einem Bestandteil haben, der in mehreren Produkten eingesetzt wird, also zu den “Commonalities” gehört. Das Fehlermanagement in Produktlinien erfordert deshalb besondere Sorgfalt.

Beispiel für Issue Tracking in Produktlinien

Im Beispiel in Abb. 1 gibt es zwei Produkte A und C in den Versionen A1, A2 bzw. C1, C2, die aus den speziellen Teilen G bzw. R sowie den gemeinsam genutzten Bestandteilen B und Y aufgebaut sind.

Wenn in Komponente B in der Version B1 ein Fehler festgestellt wird, sind davon nach Abb. 2 die Komponenten A1, C1 und C2 betroffen. Eine Fehlerbehebung kann mit B2 erfolgen, was die Produktvariante A in der Version A2 betrifft. Es gibt also in diesem Kontext drei Arten von Assoziationen zwischen Komponenten:

1. “Komponente wird eingesetzt in”
2. “Fehler propagiert nach” (rote Linien in Abb. 2)
3. “Fehlerbehebung propagiert nach” (grüne Linien in Abb. 2)

Alle Arten dieser Assoziationen sind 1:n, d.h. ein Fehler kann in n Produkten bzw. Teilprodukten Auswirkungen haben. Für eine Impaktanalyse und zur Nachverfolgung von Fehlerbehebung genügt die erste Assoziation; die beiden anderen lassen sich daraus ableiten.

Fehlermanagement Modellierung

Um die oben beschriebene Konstellation mit gemeinsam genutzten Produktkomponenten abbilden zu können, benötigt man ein System, das

• Versionen von Elementen unterscheiden kann
• Beziehungen zwischen Elementen erstellen kann
• Beziehungen zwischen Elementen auch über mehrere Ebenen hinweg nachvollziehbar machen kann

Voraussetzung für eine Impaktanalyse ist die Modellierung der Beziehungen gemeinsam genutzter Komponenten zu den verwendenden Komponenten. Dazu kann man unter Nutzung einer entsprechend konfigurierbaren Issue Tracking-Software oder Projektmanagement-Software wie folgt vorgehen:

1. Für jede Komponente wird ein eigenes Projekt (Bereich) angelegt.
2. In diesem Bereich wird hierarchisch ganz oben genau ein Element vom Typ “Komponenten-Info” (Issue Type, Vorgangstyp) angelegt.
3. Wenn die verwendete Software keine Versionen unterstützt, müssen diese über ein Element-Attribut (z.B. “Release”) verwaltet werden. Dann muss entsprechend für jede Version eine Komponenten-Info angelegt werden, z.B. als Kind-Element einer übergeordneten Sammel-Komponenten-Info.
4. Wird die Teilkomponente nun in einer anderen Komponente in einer bestimmten Version verwendet, wird eine Beziehung (Verknüpfung, Link) mit einem entsprechenden Verknüpfungstyp erstellt.

Abbildung der Komponenten und Produkte auf Bereiche im Issue Tracking System

Für jede Komponente und jedes Produkt wird zuerst ein Projekt oder Arbeitsbereich angelegt. Hier hilft es, wenn man ein System hat, dass Bereiche hierarchisch verwalten kann, um bessere Übersicht zu behalten (die Beispiele hier kommen aus der Allegra Projektmanagement-Software).

In Abb. 3 haben wir die gemeinsam genutzten Komponenten unter dem Bereich “Plattform” angeordnet und die Produkte unter dem Bereich “Produkte”. Hat man sehr viele Komponenten und Produkte, ist eine weitere Strukturierung vorstellbar.

Assoziationspunkte in Bereichen anlegen

Um die Beziehungen zwischen den Elementen abbilden zu können, wird für jeden Bereich ein Assoziationspunkt erstellt. Das kann ein Vorgang (item, issue) mit einem entsprechenden Vorgangstyp sein. Unterstützt die Software Baselines von Bereichen, genügt ein Assoziationspunkt pro Bereich. Ansonsten müssen die Versionen über ein Vorgangsattribut (z.B. “Release”) mit einer entsprechend im Issue Tracking System hinterlegten Liste von Versionen abgebildet werden.

Die Komponenten und Produkte gehören immer zu einer Baseline (A in Abb. 4). Innerhalb einer Komponente bzw. eines Produktes haben die Assoziationspunkte Versionen (B in Abb. 4). Die Verknüpfungen erfolgen immer versionsbezogen.

Unterstützt das System keine Versionierung von Vorgängen, muss man unter den Komponenten- bzw. Produkt-Assoziationspunkten für jede Version einen eigenen Assoziationspunkt anlegen, also in Abb. 4 z.B. unter KY-1.

Im Grunde muss hier ein Teil einer Stückliste nachgebildet werden und es ist zu überlegen, ob nicht Informationen aus einer Stücklistenverwaltung genutzt werden können, um die Beziehungen in einem Fehlermanagement-System (Issue Tracking System) automatisch zu erstellen.

Weitere Informationen

Falls Sie interessiert sind mehr über Help Desk Software zu lesen, können Sie dies hier tun. In diesem Artikel können Sie eine Übersicht zu Ticketsystemen sehen.