imported>Aka: typografische Anführungszeichen, Kleinkram

2024-09-24T17:00:51Z

typografische Anführungszeichen, Kleinkram

Neue Seite

'''Produktlinienentwicklung''' stellt einen methodischen Ansatz zur Softwareentwicklung dar, dessen Ziel das Erzeugen von [[Produktlinie (Software)|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|Software Engineering Institute (SEI)]] der [[Carnegie Mellon|Carnegie Mellon University]].

== Grundprinzipien ==
Die Produktlinienentwicklung beruht wesentlich auf zwei Grundprinzipien:

# Der Beschreibung der [[Variabilität (Software)|Variabilität]] der Produktlinie.
# Der Trennung von Domänenentwicklung und Applikationsentwicklung.

=== Modellierung der Variabilität ===
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 [[Variante (Software)|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 [[Datenbank]]systemen. 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.<ref>Jan Bosch: {{Webarchiv|url=http://www.janbosch.com/Jan_Bosch/Presentations_files/SBQS2009-Keynote.pdf |wayback=20140505200916 |text=''Keynote presentation at the Brazilian Symposium on Software Quality (SBQS 2009).'' |archiv-bot=2019-05-08 06:49:41 InternetArchiveBot }} (PDF; 2,0 MB), June 2009, Ouro Preto, Brazil.</ref>

'''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 ===
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 [[Artefakt (Software)|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 ==
* 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.

== Weblinks ==
* [http://www.sei.cmu.edu/productlines Software Product Lines] Einstiegsseite des ''Carnegie Mellon Software Engineering Institute'' (englisch)
* [http://www.softwareproductlines.com Software Products Lines] englischsprachige Seite rund um Produktlinienentwicklung
* [http://splc.net/ Software Product Line Conference (SPLC)] Konferenz zu Software-Produktlinien, die abwechselnd in [[Amerika]], [[Europa]] oder [[Asien]] stattfindet.
* [http://www.methodsandtools.com/archive/archive.php?id=45 Introduction to the Emerging Practice of Software Product Line Development]

== Einzelnachweise ==
<references />

[[Kategorie:Softwaretechnik]]

Produktlinienentwicklung (Software) - Versionsgeschichte

imported>Aka: typografische Anführungszeichen, Kleinkram