Share ZU:
23 April 2013 @ Karsten Krennrich

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 7: Die Produktlinieninfrastruktur und ihre Produkte

This entry is part 7 of 13 in the series Produktlinien

Der 6 .Teil der Blogreihe befasste sich mit der Entstehung bzw. Ableitung eines Produktes aus der Produktlinieninfrastruktur. Heute stellen wir uns die folgenden  Fragen:

Was passiert nachdem ein Produkt spezifiziert wurde? Besteht noch ein Zusammenhang zwischen Produkt und Produktlinieninfrastruktur? Besteht die Notwendigkeit an einem solchen Zusammenhang? Wie lässt sich dieser pflegen und dokumentieren?

Zum Einstieg betrachten wir nochmals das Beispiel des letzten Blogs, in welchem wir ein Attribut „ProduktXY“ definiert haben, das pro Anforderung der Produktlinieninfrastruktur spezifiziert, ob das Produkt die Anforderung erfüllen muss (enthalten) oder nicht (nicht enthalten).

Abbildung 1: Beispiel für die Abbildung eines Produkts

Eine Anforderung der Produktlinieninfrastruktur ändert sich

Was passiert, wenn sich eine Anforderung in der Produktlinieninfrastruktur ändert (eine bestehende Anforderung wird inhaltlich geändert, gelöscht oder eine neue Anforderung wird spezifiziert)? Der kritische Fall, den wir hier betrachten ist der, wenn sich eine bestehende Anforderung, die sich bereits in einem oder mehreren Produkten wiederfindet, ändert. Um eine Auswirkungsanalyse durchzuführen, müssen wir also nachvollziehen können, in welchen Produkten die sich ändernde Anforderung zu erfüllen ist. D.h. wir benötigen eine Referenz, die es erlaubt die betroffene Anforderung aus der Produktlinieninfrastruktur in den jeweiligen Produkten wiederzufinden. – Wenn wir uns die Konzepte von Anforderungsmanagementwerkzeugen anschauen, so könnte man dies mit „Links“ realisieren. – Die Auswirkungsanalyse liefert uns dann das Ergebnis dafür, ob die Änderungen aus der Produktlinieninfrastruktur auch in die bestehenden Produkte übernommen werden soll. Ist dies nicht möglich, so muss die „geänderte Anforderung“ als neue Anforderung in der Produktlinieninfrastruktur definiert werden, um später in neuen Produkten aufgenommen werden zu können. Kann oder muss hingegen die geänderte Anforderung  in allen bisherigen Produkten erfüllt werden, so kann die Änderung direkt in die Anforderung der Produktlinieninfrastruktur integriert werden. Über die Referenz gelangt die Änderung dann in die abgeleiteten Produkte, die sie erfüllen müssen.

Eine Anforderung an das Produkt ändert sich

Der weitaus häufigere Fall, der in der Praxis auftritt ist der, dass ein Produkt neue oder sich ändernde Anforderungen, beispielsweise aufgrund von funktionalen Erweiterungen, erfüllen muss. Ist dieses Produkt nun Teil der Produktlinie (wurde aus der Produktlinieninfrastruktur abgeleitet), so müssen wir nachvollziehen können, ob die sich ändernde Produktanforderung ihren Ursprung in der Produktlinieninfrastruktur hat. Falls ja muss analysiert werden, ob die entsprechende Anforderung bereits in weiteren Produkten der Produktlinie erfüllt werden muss. Mit diesem Ergebnis können wir dann entscheiden, ob die geänderte Anforderung zu einer spezifischen Anforderung für das Produkt wird (die weiteren Produkte bleiben in diesem Fall von der Änderung unberührt) oder die Änderung in die Produktlinieninfrastruktur übernommen werden kann. Dann müssen alle Produkte, welche die ursprüngliche Anforderung erfüllen mussten, nun die entsprechend geänderte Anforderung erfüllen.

 

Wir sehen also, dass auch nach der Ableitung eines Produktes aus der Produktlinieninfrastruktur ein Zusammenhang zwischen diesen gibt. Insbesondere, wenn im Produktlebenszyklus Änderungen in die Produkte oder die Produktlinieninfrastruktur integriert werden müssen.

Durch das oben beschriebene Vorgehen kann die Konsistenz zwischen Produkt und Infrastruktur bewahrt werden.

Im nächsten Teil der Blogreihe möchten wir gerne noch auf Voraussetzungen, die eine Unternehmensstruktur idealerweise erfüllen muss, um eine produktlinienorientiertes Anforderungsmanagement zu betreiben, eingehen.

Series Navigation<< Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 6: Von der Produktlinieninfrastruktur zum ProduktKosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 8: Die Unternehmensstruktur für ein produktlinienorientiertes Anforderungsmanagement >>

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.