Share ZU:
22 May 2012 @ Karsten Krennrich

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 3: Variabilität innerhalb einer Produktlinie

This entry is part 3 of 13 in the series Produktlinien

In der heutigen Ausgabe dieser Blog-Reihe wollen wir beginnen uns mit dem wohl spannendsten Thema von Produktlinien der Variabilität zu beschäftigen. Viele von Ihnen werden sicherlich meine Erfahrungen teilen, dass in der Definition und Abbildung von Variabilität für Produkte innerhalb einer Produktlinie die Komplexität am größten ist und genau dort die meisten Herausforderungen bei der Produktliniendefinition auf uns warten.

Variationspunkte
Schauen wir uns zunächst an, welche Arten von Variabilität innerhalb der Produktlinieninfrastruktur (siehe Blog Teil 2) möglich sein können. Hierzu nutzen wir das Konzept der sogenannten Variationspunkte mit deren Hilfe Variabilitäten, wie z.B. Alternativen oder Optionen beschrieben werden [Schmid 03].

Mögliche Variationspunkte, die wir hier weiter betrachten (hier sei nochmals angemerkt, dass wir in dieser Blog-Reihe das Ganze aus der Sicht von Anforderungen betrachten) sind:

  • Option (Anforderungen, die einem optionalen Variationspunkt zugeordnet sind, müssen entweder in einem Produkt realisiert werden oder nicht.)
  • Alternative (Aus den Anforderungen einer Alternative muss genaue eine Anforderung oder eine Menge dieser Anforderungen in einem Produkt realisiert werden.)
  • Alternative-Group (Dieser Variationspunkt fasst eine Menge von Anforderungen zu einer Auswahlmöglichkeit innerhalb einer Alternative zusammen.)

Entscheidungsmodell & Entscheidungsvariablen
Wie sieht nun der Entscheidungsprozess aus, der die Variationspunkte nutzt, um ein Produkt in der Produktlinie zu instanzieren bzw. zu spezifizieren?

Hierzu benötigen wir ein weiteres Konzept. Das Konzept von Entscheidungsvariablen: Nach [Schmid 03] sind die Variationspunkte an Entscheidungsvariablen gebunden. Demnach hinterliegt jedem Variationspunkt eine odere mehrere evtl. voneinander abhängige Entscheidungsvariablen. Die Entscheidungsvariablen sind in einem Entscheidungsmodell zusammengefasst. Das Entscheidungsmodell enthält für jede Entscheidungsvariable neben dem Namen noch zusätzliche Informationen, die bei ihrer Definition angegeben werden können. In [Schmid 03] beinhaltet ein Entscheidungsmodell folgende Informationen:

  • Relevanz (gibt an unter welchen Voraussetzungen die Entscheidungsvariable für die Produktinstanziierung relevant ist),
  • Beschreibung (gibt an mit welcher Fragestellung die Entscheidung getroffen werden kann),
  • Wertebereich (legt fest welche Werte die Entscheidungsvariable annehmen kann),
  • Auswahl (gibt die Anzahl der möglichen auswählbaren Werte aus dem definierten Wertebereich an) und
  • Einschränkungen (bestimmen unter welchen Umständen und in welcher Weise der Wertebereich der Entscheidungsvariable eingeschränkt ist; evtl. auch von anderen Entscheidungsvariablen).

Ein Entscheidungsmodell mit den o.g. Informationen kann z. B. folgende Form haben:

Name Relevanz Beschreibung Wertebereich Auswahl Einschränkungen
Zusatzinformationen Sollen Services mit zusaetzlichen Informationen versehen werden koennen? TRUE /FALSE 1
Zusatzinformationsform Zusatzinformationen = TRUE Welche Form sollen die Zusatzinformationen haben? Freitext /Datei 1
Dateityp Zusatzinformationen = TRUE Von welchem Typ soll die Datei sein? pdf / doc 2 Zusatzinformationsform = Datei =>Dateityp = doc | Dateityp = pdf
Servicebestellung Soll der Benutzer Services bestellen können? TRUE /FALSE 1

Abbildung 1: Beispiel für Entscheidungsmodell

Eine Entscheidungsvariable wird benutzt, um einen Variationspunkt der Produktlinieninfrastruktur während der Instanziierung eines Produkts aufzulösen. Dies geschieht, indem der Benutzer einer Entscheidungsvariablen einen oder mehrere Werte aus dem jeweils definierten Wertebereich zuweist. Über die Einschränkungen, die das Entscheidungsmodell beinhaltet, lassen sich auch Abhängigkeiten wie z.B. Anforderungen, die sich gegenseitig bedingen oder ausschließen in der Produktlinieninfrastruktur definieren.

Instanziierung
Die Instanziierung ist der Prozess des Auflösens von Variationspunkten innerhalb der Produktlinieninfrastruktur, um ein spezifisches Produkt aus der Produktlinieninfrastruktur abzuleiten. Dies geschieht, in dem den Entscheidungsvariablen aus dem Entscheidungsmodell Werte zugewiesen werden. Der zugewiesene Wert bestimmt dann darüber welche Anforderungen in dem Produkt realisiert werden müssen. So muss eine Anforderung, die einem optionalen Variationspunkt untergeordnet wurde, mit einer entsprechenden Wertzuweisung in einem neuen Produkt realisiert werden oder nicht. Ein Auto kann z. B. mit einem Radio oder ohne ausgeliefert werden. Ein Beispiel für die Anforderungen, die einer Alternative untergeordnet sind, sind z. B. die Farben in denen ein Auto lackiert sein kann. Der Kunde muss sich dabei aus einer festgelegten Menge von Farben eine Wunschfarbe auswählen. Dabei hat der Kunde nur die Möglichkeit eine Wahl zu treffen. Es ist allerdings auch möglich, dass man aus einer Menge von Auswahlmöglichkeiten mehrere Elemente auswählen kann. So kann sich ein Kunde für sein Auto mehrere Extras wie z. B. Klimaanlage und/oder Sitzheizung aus einer festgelegten Liste auswählen.

In den folgenden Teilen dieser Blog-Reihe wollen wir uns ansehen, wie die beschriebenen Konzepte auch praktisch von Anforderungsmanagementwerkzeugen unterstützt, implementiert und eingesetzt werden können.

Literatur:

[Schmid 03]                Klaus Schmid, Isabel John: A Customizable Approach To Full-Life Cycle Variability Management, 2003

Series Navigation<< Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 2: Die ProduktlinieninfrastrukturKosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 4: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Kriterien) >>

Karsten Krennrich

Kontaktieren Sie Karsten Krennrich

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.