Produktlinienentwicklung (Software)

methodischer Ansatz zur Softwareentwicklung

Produktlinienentwicklung stellt einen methodischen Ansatz zur Softwareentwicklung dar, dessen Ziel das Erzeugen von Software-Produktlinien ist (engl. Software Product Lines, teilw. auch Software Families).

Hierbei werden sowohl die Wiederverwendung als auch die Variabilität auf Basis einer gemeinsamen sog. Plattform organisiert.

Der Begriff Software Product Lines wurde eingeführt vom Software Engineering Institute (SEI) der Carnegie Mellon University.

Grundprinzipien

Bearbeiten

Die Produktlinienentwicklung beruht wesentlich auf zwei Grundprinzipien:

  1. Der Beschreibung der Variabilität der Produktlinie.
  2. Der Trennung von Domänenentwicklung und Applikationsentwicklung.

Modellierung der Variabilität

Bearbeiten

Wichtigste Grundmethodik der Produktlinienentwicklung ist die Modellierung der Variabilität. Diese wird orthogonal in allen Entwicklungsphasen eines Produktlinienprojekts bestimmt, vorgehalten und geändert. Grob umrissen sind die Entwicklungsphasen eines Produktlinienprojekts

  • die Anforderungsphase;
  • die Architekturphase und
  • die Implementierungsphase.

Die in der Anforderungsphase (engl. Requirements Phase) identifizierten Varianten werden in den Produkten der Architekturphase berücksichtigt. Dies werden insbesondere Varianten im Funktionsumfang sein, die sich aufgrund von Kundenwünschen oder Geschäftszielen herausbilden. Zusätzlich können Varianten während der Architekturphase identifiziert werden. Beispielsweise könnte die Integration mit Software von anderen Herstellern Varianten ausbilden. Schließlich werden die Varianten aus der Anforderungs- und aus der Architekturphase in der Implementierungsphase berücksichtigt, in der weitere Varianten entstehen können, wie z. B. die individualisierte Berücksichtigung von bestimmten Datenbanksystemen. Die Entwicklung hin zu Produktlinien, die über Unternehmensgrenzen entwickelt werden, führt zu einem komplexen Software-Ökosystem in dem Kundenwünsche einen noch größeren Einfluss auf die Entwicklung haben als bei rein durch einzelne Unternehmen getriebene Produktlinien.[1]

Vorteile der orthogonalen Variabilitätsmodellierung sind unter anderem, dass Varianten und ihre Abhängigkeiten übergreifend verfolgbar sind. Auch bleibt die Wiederverwendbarkeit bereits identifizierter Varianten erhalten. Schließlich kann der Implementierungsaufwand für eine konkrete Produktlinie teils drastisch reduziert sein: Da normalerweise nur eine Untermenge der möglichen Varianten implementiert wird, brauchen nur die für die Produktlinie identifizierten Varianten implementiert zu werden. Diese Implementierungen, wenigstens aber die Domänenartefakte der Plattformen, kann man normalerweise auch wiederverwenden.

Getrennte Domänen- und Applikationsentwicklung

Bearbeiten

Um Varianten von Produktlinien identifizieren zu können, muss zunächst ermittelt werden, welche Bestandteile einer Software tatsächlich nicht nur einmalig zu erstellen sind (z. B. um einem Kundenwunsch zu genügen), sondern mehrfach verwendet werden können. Dieser Prozess wird Scoping genannt.

Diese Wiederverwendungsanalyse ist Ausgangspunkt eines Produktlinien-Projekts. Normalerweise erfolgt das Scoping, nachdem Klarheit über die zu entwickelnden Produktlinien herrscht, also ein „Produkt-Portfolio“ oder eine „Produkt-Roadmap“ von der Geschäftsseite erstellt worden ist.

Basierend darauf werden die domänenspezifisch wiederverwendbaren Artefakte entwickelt (z. B. Anforderungs- und Architekturdokumente, Testfälle), die für die Implementierungsphase maßgeblich sind. Als methodischer Ansatz ist die Produktlinienentwicklung deshalb auch als architekturzentriert (siehe Softwarearchitektur) zu bezeichnen.

Literatur

Bearbeiten
  • Böckle, Knauber, Pohl, Schmid (Hrsg.): Software-Produktlinien. dpunkt, 2004, ISBN 3-89864-257-7.
  • Van der Linden, Schmid, Rommes: Software Product Lines in Action. Springer-Verlag, 2007, ISBN 978-3-540-71436-1.
Bearbeiten

Einzelnachweise

Bearbeiten
  1. Jan Bosch: Keynote presentation at the Brazilian Symposium on Software Quality (SBQS 2009). (Memento des Originals vom 5. Mai 2014 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.janbosch.com (PDF; 2,0 MB), June 2009, Ouro Preto, Brazil.