Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschen

Im dritten Teil dieser Blog Reihe haben wir uns mit dem Thema der „Variabilität innerhalb der Produktlinie“ beschäftigt. Da dies, wie damals schon beschrieben, die größte Komplexität in sich birgt, möchte ich dieses Thema an dieser Stelle nochmals aufgreifen.

Wir erinnern uns, dass die Variabilität innerhalb der Produktlinieninfrastruktur beschrieben und abgebildet wird, um daraus Produkte ableiten zu können. Die Herausforderung ist es, die Variabilität einzelner Anforderungen eindeutig zu beschreiben und gleichzeitig den Entscheidungsprozess bei der Ableitung eines Produkts zu unterstützen. Da wir im dritten Teil nur eine Möglichkeit betrachtet haben, möchte ich hier gerne einige weitere Möglichkeiten mit Ihnen diskutieren.

Die Notationen, die wir bereits beschrieben haben bzw. die wir uns heute und in weiteren Teilen anschauen wollen, sind die folgenden:

Notationen zur Beschreibung von Variabilität

1. Formalisiertes Entscheidungsmodell mit Variationspunkten und Entscheidungsvariablen (Diese Art der Beschreibung haben wir bereits im dritten Teil der Blogreihen kennengelernt.)
2. Feature Model
3. Use Case Beschreibungen
4. Use Case Diagrammen
5. Feature Graph
6. Variabilität in UML

Beschreibung von Variabilität durch ein Feature Model

Da ein Bild bekanntlich mehr als tausend Wort sagt, soll direkt ein Beispiel zur Veranschaulichung dieser Notation dienen:

Abbildung 1: Beispiel für ein Feature Model

Die Abbildung zeigt, dass die Systemanforderungen hierarchisch als Features und Sub-Features inklusive deren Beziehungen und Abhängigkeiten untereinander in einer Baumstruktur beschrieben sind.

Das Beispiel spezifiziert einen Wecker mit einer Zeitanzeige und einem Batteriefach. Optional kann der Wecker auch mit einem Radio ausgestattet sein. Ein Radio erfordert allerdings ein Batteriefach für sechs Batterien. Die Zeitanzeige kann entweder rote oder blaue Schrift haben. Wenn die Zeitanzeige mit blauer Schrift gewählt wird, so hat der Wecker kein Radio.

Durch ein derartiges Modell kann somit eine komplette Produktlinieninfrastruktur, aus der unterschiedliche Produkte abgeleitet werden, abgebildet werden.

Feature Modelle haben den großen Vorteil, dass sie einfach zu verstehen sind. Sowohl ein „weniger technisch versierter“ Kunde als auch ein „tief im Detail steckender“ Entwickler können diese Art von Modell verstehen und damit Anforderungen an das zu entwickelnde System gemeinsam abstimmen.

Im nächsten Teil werden wir uns der Beschreibung von Variabilität mit Hilfe von Use Case Beschreibungen und Use Case Diagrammen widmen.

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.