Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 1
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 2: Die Produktlinieninfrastruktur
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 3: Variabilität innerhalb einer Produktlinie
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 4: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Kriterien)
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 5: Werkzeuge für produktlinienorientiertes Anforderungsmanagement (Implementierung)
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum Produkt
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 7: Die Produktlinieninfrastruktur und ihre Produkte
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 8: Die Unternehmensstruktur für ein produktlinienorientiertes Anforderungsmanagement
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 10: Variabilität und Use Case Beschreibungen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 11: Variabilität und Use Case Diagramme
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 12: Variabilität und Feature Graphen
- Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 13: Variabilität in UML
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
- Formalisiertes Entscheidungsmodell mit Variationspunkten und Entscheidungsvariablen (Diese Art der Beschreibung haben wir bereits im dritten Teil der Blogreihen kennengelernt.)
- Feature Model
- Use Case Beschreibungen
- Use Case Diagrammen
- Feature Graph
- 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.
Diesen Blogbeitrag hat Karsten Krennrich für HOOD geschrieben.
Wissen, das bewegt!
Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.
Jetzt abonnieren und keine wichtigen Insights mehr verpassen!
Diskussion