Software- Produktlinien

Transkript

1 Software- Produktlinien Informatik- Seminar im Rahmen des Studienganges Master Technische Informatik im Modul Software- Projekt- Management Referent: Prof. Dr. Hans Nissen von Karin Schuster Matrikelnummer: Abgabe: 18. Juni 2007

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Erläuterungen von Grundbegriffen Technische Aspekte Variabilität Was versteht man unter Variabilität? Variabilitäts- Typen Allgemeines Variabilitätsmodell Orthogonale Modellierung Scoping Product Portfolio Scoping Domain Scoping Asset Scoping PuLSE-ECO- Ansatz Requirements Engineering Use Cases Produktableitung Organisatorische Aspekte Organisationsstrukturen Anforderungen Organisationstheorie Organisationsstrukturen Kriterien zur Auswahl Transitionsprozess PLE- Transitionsprozess Strategie und Scope Architektur Prozess und Organisation Fazit Literaturverzeichnis

3 1 Einleitung 1 Einleitung Das heutige Ziel in der Software- Entwicklung ist, in immer kürzerer Zeit, immer bessere Produkte auf den Markt zu bringen. Die Ressourcen in den Firmen bleiben aber in der Regel gleich, d.h. das mehr geleistet werden muss, um dieses Ergebnis zu erreichen. Hier kommen die Software- Produktlinien ins Spiel. Software- Produktlinien unterstützen die Entwicklung von Produkten, die einen gemeinsamen Kern haben und zusätzlich über spezifische Teile verfügen. Die spezifischen Teile können vom Kunden gewählt werden, um so aus einem allgemeinen Produkt ein für sich angepasstes Produkt zusammenzustellen. Als Beispiel kann man hier die Entwicklung von Taschenrechnern nennen. Alle Taschenrechner haben als Basisfunktionen mindestens die Grundrechenarten. Zusätzlich kann ein Taschenrechner mit Matrizen oder komplexen Zahlen umgehen. Der Kern besteht hier aus den implementierten Grundrechenarten für den Taschenrechner. Als variable Teile stehen hier die Implementierungen für den Umgang mit Matrizen und komplexen Zahlen zur Verfügung, aus denen der Kunde dann einen oder mehrere Teile auswählen kann. Zum Kern werden dann die ausgewählten Teile hinzugefügt, so dass der Kunde ein auf ihn angepasstes Produkt erhält. Die Funktionen des Taschenrechners können somit mit geringen Aufwand zu einem Produkt zusammengebaut werden, da alle Teile schon implementiert sind. Die Entwicklung mit Software- Produktlinien soll in einem möglichst wirtschaftlichem Rahmen ablaufen. Hierzu muss sich vorher überlegt werden, welche Gemeinsamkeiten eine solche Produktlinie hat und welches die variablen Punkte sind. Es ist nicht möglich irgendwelche Funktionalitäten zu einer Produktlinien zusammen zu schließen. Diese Auswahl muss anhand verschiedener Kriterien genau getroffen werden. Ansonsten kann es passieren, dass die entwickelte Produktlinie nicht das hält was sie verspricht und somit teuer eine neue, angepasste Produktlinie entwickelt werden muss. Damit wäre der Punkt der Kostenersparnis nicht umgesetzt worden. Um dieses zu vermeiden, werden in dieser Ausarbeitung ein paar grundlegende Aspekte zur Auswahl der Komponenten, die in Produktlinien wiederverwendet werden können, genauer erläutert. Des Weiteren müssen neue organisatorische Aspekte in der Firma eingeführt werden. Auf Grund der neuen Art der Software- Entwicklung entstehen neue Aufgabenbereich, denen Verantwortlichkeiten zugeordnet werden müssen. Die Organisationsstruktur muss angepasst werden, um den Nutzen, die eine Produktlinie mit sich bringt auch einsetzten zu können. Außerdem müssen einige Punkte bei der Überführung der bisherigen Unternehmensstruktur in eine Struktur für Produktlinienentwicklung beachtet werden. Diese Punkte werden im Laufe dieser Arbeit genauer betrachtet. 3

4 1 Einleitung Der weitere Aufbau dieser Ausarbeitung sieht wie folgt aus: In dieser Einleitung werden noch ein paar Grundbegriffe erläutert. In Kapitel 2 werden technische Aspekte zur Produktlinien- Entwicklung beschrieben. Auf die Aspekte der Variabilität, des Scopings und des Requirements Engineering wird genauer eingegangen. In Kapitel 3 werden die organisatorischen Aspekte der Produktlinien- Entwicklung beschrieben. Die Punkte der Organisationsstrukturen und des Transitionsprozess werden genauer erläutert. 1.1 Erläuterungen von Grundbegriffen Im folgenden werden noch ein paar Begriffe erklärt, die zum besseren Verständnis dieser Arbeit beitragen sollen. Produktlinie: Eine Produktlinie hat einen gemeinsamen invarianten Teil, zu dem ggfs. zusätzliche Komponenten hinzugefügt werden können. Diese zusätzlichen Komponenten sind fest vorgegeben. Domain Engineering: Im Domain Engineering wird der invarianten Teil entwickelt und verwaltet. Application Engineering: Im Application Engineering wird das eigentliche Produkt entwickelt. Dieses Produkt besteht aus dem Grundgerüst, das im Domain Engineering entwickelt wurde, und zusätzlichen Komponenten, die der Kunde ausgewählt hat. 4

5 2 Technische Aspekte 2 Technische Aspekte 2.1 Variabilität Was versteht man unter Variabilität? Durch Variabilität eröffnet sich die Möglichkeit ein Software- Produkt, mit einheitlichem Kern, an Kundenbedürfnisse individuell anzupassen. Der Kunde kann zu einem festen Kern zusätzliche Komponenten auswählen, die dann mit in das kundenspezifische Produkt integriert werden. Die Komponenten, die sich der Kunde in diesem Fall aussuchen kann, sind nicht willkürlich, sondern es existieren implementierte Zusatzvarianten aus denen ausgewählt werden kann Variabilitäts- Typen Die Variabilitäts- Typen sind: (entnommen aus [1]) Variabilität in Features Variabilität in Abläufen Variabilität in Datenumfang Variabilität in Datenformat Variabilität in Systemzugang Variabilität in Benutzerschnittstellen Variabilität in Systemschnittstellen Variabilität in der Qualität Diese Typen können nicht separat betrachtet werden. Es kann z.b. sein, dass ein Kunde sich ein Datenformat aussucht und sich dadurch auch Änderungen an anderer Stelle ergeben können, z.b. beim Datenumfang. D.h., dass evtl. mehr oder weniger Daten gespeichert werden müssen. Dieses Beispiel zeigt, dass zwischen den Variabilitäts- Typen Abhängigkeiten bestehen, die nicht zu vernachlässigen sind. Um die Abhängigkeiten grafisch darzustellen werden in den nächsten beiden Abschnitten das Allgemeine Variabilitätsmodell und die orthogonale Modellierung vorgestellt. 5

6 2 Technische Aspekte Allgemeines Variabilitätsmodell Das allgemeine Variabilitätsmodell ist in folgender Abbildung dargestellt: In diesem Bild sieht man Variationspunkte, Varianten, Variabilitätsabhängigkeiten und Constraint- Beziehungen, die im Folgenden genauer beschrieben werden. An einem Variationspunkt kann man eine oder mehrere Varianten auswählen und eine Variante kann an mehreren Variationspunkten ausgewählt werden. Die Variante beschreibt die tatsächlichen Möglichkeiten, die später implementiert werden können. Zwischen Variationspunkten und Varianten gibt es verschiedene Arten von Variabilitäsabhängigkeiten. Es gibt optionale Beziehungen, d.h. die Variante kann gewählt werden, alternative Beziehungen, d.h. eine Variante muss aus einer Menge von Varianten gewählt werden. Zwei weitere Abhängigkeitstypen sind die Pflichtbeziehungen, d.h. das eine Variante zu einem Punkt gehören muss und die Ausschlussbeziehungen, d.h. an diesem Punkt darf eine Variante auf gar keinen Fall gewählt werden. Es gibt auch noch zwei Constraint- Beziehungen: Bei der Requires- Beziehung wird eine weitere Variante benötigt und bei der Excludes- Beziehung kann eine andere Variante nicht gewählt werden, wenn schon eine gewählt wurde. (siehe [1]) 6

7 2 Technische Aspekte Orthogonale Modellierung Die Variationspunkte dienen hier als eigene Schicht. Aus den einzelnen Phasen der Software- Produktlinien- Entwicklung, die hier als weitere Schicht dargestellt sind, werden die Komponenten den Variationspunkten zugeordnet. Durch die orthogonale Modellierung kann man Komponenten eines Variationspunktes über die verschiedenen Ebenen der Entwicklung verfolgen. In den verschiedenen Ebenen gibt es unterschiedliche Beschreibungsarten, die in diesem Modell als eigenständige Bestandteile geführt werden. Dieses Modell erlaubt einen gemeinsamen Überblick über die Variabilität in den einzelnen Ebenen, da die Variabilität des Requirements in z.b. der Architektur nur anders dargestellt wird. Im Requirements heißt es z.b., dass es eine Abfrage des Kontostands per Telefon geben soll und in der Architektur bedeutet dieser Punkt, dass es ein Callcenter Server geben muss, der diese Anfragen bearbeiten kann. 7

8 2 Technische Aspekte 2.2 Scoping Beim Scoping wird, wie der Name schon sagt, eine Abgrenzung vorgenommen. In diesem Fall muss die Produktlinie abgegrenzt werden. In den folgenden Abschnitten werden Methoden zur Abgrenzung dargestellt Product Portfolio Scoping Beim Product Portfolio Scoping werden die Grenzen der Produktlinien definiert. Es wird geprüft, ob die untersuchten Komponenten in einer Produktlinie zusammengeführt werden können, so dass auch ein effektiver Nutzen davon ausgeht. Sollte diese Komponente nämlich nicht mit den anderen Komponenten in einer Produktlinie vereinigt werden können, so wird diese auch nicht in die Produktlinie aufgenommen. Die Abstimmung, ob eine Komponenten in die Produktlinie aufgenommen werden soll oder nicht, wird in Teamgesprächen diskutiert. Der Aspekt, ob eine Komponente sinnvollerweise aufgenommen werden sollte oder nicht, sollte nicht von einer einzelnen Person getroffen werden, da z.b. Entwickler eine ganz andere Vorstellung davon haben als das Management. Z.B. ist ein Punkt aus technischer Sicht nicht realisierbar, der sonst gut in das Produkt passen würde Domain Scoping Im Domain Scoping werden die Funktionsbereiche, die zu einer Produktlinien gehören, zusammengefasst. Diese Funktionsbereiche müssen gut wiederverwendbar sein. Die Funktionsbereiche sind Teilbereich der Produktlinie Asset Scoping Im Ansatz des Asset Scoping wird die Funktionalität selber weniger betrachtet, sondern die Art und Weise wie diese Funktionalität später realisiert werden soll. Auf die Möglichkeit der Wiederverwendung wird hier großen Wert gelegt, um die Produktlinie effektiv nutzen zu können. Dazu gehört es, die Funktionalität als Gemeinsamkeit oder Variabilität der Produktlinie zu identifizieren. Die Komponenten bzw. Funktionalitäten die in diesem Schritt bestimmt wurden, dienen als Grundlage der weiteren Entwicklung. Sie sind aber nicht so fest, dass sie bei der eigentlichen Realisierung umgesetzt werden müssten. Es kann der Fall auftreten, dass bei der Umsetzung eine Funktionalität so nicht umgesetzt werden kann und somit geändert oder anderweitig angepasst werden muss. 8

9 2 Technische Aspekte Zu den obengenannten Scoping- Arten folgt hier ein Bild, um das Ganze noch zu verdeutlichen: PuLSE-ECO- Ansatz PuLSE-ECO steht für Product Line Software Engineering Economic Scoping. Bei diesem Ansatz spielt der ökonomische Aspekt (ECO, Economic Scoping) eine Rolle. Die Komponenten der Produktlinie werden zusätzlich zur Wiederverwendbarkeit unter diesem Punkt bewertet. PuLSE-ECO beinhaltet drei Punkte, die abgearbeitet werden müssen: Product Line Mapping, Domain Potential Analysis, Reuse Infrastructure Scoping. Das Folgende Bild stellt die Arbeitsschritte beim PuLSE-ECO- Ansatz dar: 9

10 2 Technische Aspekte Im folgenden werden die drei Schritte genauer erklärt: Product Line Mapping: Ausgehend vom Produkt, dass nachher entwickelt werden soll, wird die Produktlinie mit ihren Komponenten beschrieben..in diesem Schritt ist es nicht vorgesehen, die einzelnen Features etc. zu bestimmen. Die Produkte werden in einer Übersicht zusammengestellt, in denen auch der Status festgehalten wird. Als Statusse sind Existiert, In Entwicklung und Potenzielle Produkte (aus [1]). Die Produkte und Funktionalitäten müssen dann noch in Verbindung gebracht werden. Die Funktionalitäten werden somit auf Teilbereiche der Produktlinie aufgeteilt. Domain Potential Analysis: Nach dem im ersten Schritt ein allgemeiner Überblick über die Produktlinie erhoben wurde, wird in diesem Schritt eine Bewertung der Teilbereiche vorgenommen, um festzustellen in welchem Rahmen einzelne Komponenten wiederverwendet werden können. Diese Bewertung kann in drei Schritten durchgeführt werden: Der erste Schritt ist die Vorbereitung. Die Produktlinie, die bewertet werden soll, muss festgelegt werden. Im zweiten Schritt steht die Durchführung der Analyse an, indem Fragebögen ausgegeben und danach ausgewertet werden. Der dritte und letzte Schritt ist die eigentliche Bewertung aufgrund der erhobenen Daten aus den Fragebögen. In diesem Schritt entscheidet sich auch, ob die vorher angedachte Produktlinie für das Unternehmen überhaupt geeignet ist und wenn ja, welche Komponenten der Wiederverwendung zugeführt werden können. Reuse Infrastructure Scoping: Der Ziel des Reuse Infrastructre Scoping ist den ROI (Return on Investment) zu optimieren. Dazu wird der Nutzen bestimmt. Der Nutzen kann z.b. eine höhere Qualität und/oder geringere Entwicklungszeit sein (siehe [1]). Die Komponenten werden auf die Nutzenaspekte hin untersucht, um somit eine Entscheidung über die Entwicklung treffen zu können. Hier soll eine Antwort auf die Frage gefunden werden, ob die Komponente den Nutzen, der für die Produktlinie gewonnen werden soll, erbringen kann oder nicht. Zusätzlich kann noch eine weitere Verfeinerung mit Hilfe von Charakteristiken durchgeführt werden und eine Nutzenfunktion angewandt werden, an deren Anschluss eine Einordnung in eine von sechs Kategorien möglich ist. Diese Kategorien geben eine genaue Auskunft über die Wiederverwendbarkeit. Da das Verfahren des Reuse Infrastructure Scoping aufwendig ist, wird dieser Teil des PuLSE- ECO- Verfahren häufig nicht durchgeführt (siehe [1]). 10

11 2 Technische Aspekte 2.3 Requirements Engineering Nach dem in Kapitel 2.2 die Abgrenzung der Produktlinien vorgenommen wurde, werden im Requirements Engineering die gemeinsamen und variablen Teile der Produktlinie herausgearbeitet und nachdem der Kunde sich für seine benötigten Komponenten entschieden hat wird das spezifische Produkt abgeleitet Use Cases Um den Kunden die gemeinsamen und variablen Teile der Produktlinie zu veranschaulichen, werden sogenannte Use Cases verwendet. Um diese anwenden zu können muss die Analyse der Produktlinien- Variabilität abgeschlossen sein (siehe Kapitel 2.1). In Use Cases kann man mit <<extend>> und <<include>> festlegen, ob eine Variante angewendet werden kann oder angewendet werden muss. Um die Varianten zu markieren, kann man bei der Variante noch <<Variante>> hinzugefügt werden. Um Produklinienvariabilität explizit zu repräsentieren wurde die UML- Standard- Notation minimal erweitert (siehe [1]). Variationspunkte werden hier grafisch dargestellt (Dreieck). Dieser Punkt wird in einen Use Case eingebunden. Variationspunkte können verpflichtend (schwarzes Dreieck) oder optional (graues Dreieck) sein. Verpflichtend ist ein Variationspunkt, wenn eine Variante zwingend angewendet werden muss. Varianten werden wie oben mit <<Variante>> als solche kenntlich gemacht. Eine Beziehung zwischen Variationspunkt und Variante kann entweder zwingend (schwarzer Kreis) oder optional (grauer Kreis) sein. Zusätzlich wird bei der Beziehung noch die Kardinalität angegeben. Die Kardinalität besagt, wie viele der Varianten Anwendung finden können oder müssen. 11

12 2 Technische Aspekte Das folgende Bild zeigt ein Beispiel: Die Produktvariabilität, wie sie mit den Use- Case- Diagrammen dargestellt wird, kann dem Kunden bei seinen Entscheidungen unterstützen. Hier können die Möglichkeiten und Grenzen der Produktlinie grafisch dargestellt und erläutert werden. Der Kunde kann sehen, welche Varianten zur Verfügung stehen oder ob es für ihn doch sinnvoller ist eine teurerer Entwicklung der noch fehlenden Komponenten anzustreben. Je nachdem wie viele Anforderungen von der Produktlinie abgedeckt werden, gibt es 7 Kategorien, die den Aufwand bis zum Einsatz des Produktes beschreiben. Diese Kategorien sollen dem Kunden die Entscheidung erleichtern. Von der Kategorie 1 bis zur Kategorie 7 nimmt der Aufwand immer mehr zu. (nach [1]) 1. Vollständige Abdeckung Die Produktlinie erfüllt mit dem invarianten Teil schon alle Anforderungen, so dass keine Änderungen oder Anpassungen durchgeführt werden müssen. 2. Ausnutzung einer Variante Um die Anforderungen zu erfüllen, muss eine existierende Variante zum invarianten Teil hinzugefügt werden. Das Hinzufügen geschieht an einem Variationspunkt. 3. Definition einer neuen Variante Für einen Variationspunkt muss eine neue Variation hinzugefügt werden. Die Variante muss zwar implementiert werden, die Einbindung hat dann aber wieder den Aufwand wie in Punkt 2. 12

13 2 Technische Aspekte 4. Löschen von Funktionalität Soll eine Funktionalität aus dem invarianten Teil gelöscht werden, so muss ein neuer Variationspunkt definiert werden. Die, in diesem Fall, gelöschte Funktionalität, kann dann in einem anderen Produkt als Variante ausgewählt oder auch weggelassen werden. 5. Hinzufügen von Funktionalität Um Funktionalitäten hinzuzufügen, muss ebenfalls ein neuer Variationspunkt definiert werden. Der Variationspunkt hat dann eine Variante, die diese Funktionalität erfüllt. Braucht man für die neue Funktionalität nur eine neue Variante und keinen neuen Variationspunkt, so fällt dieser Aufwand in die dritte Kategorie. 6. Änderung der Architektur Solche Änderungen haben Auswirkungen auf die gesamte Produktlinie, da hier nicht nur ein Variationspunkt hinzugefügt oder entfernt wird. 7. Anforderung kann nicht realisiert werden In diesem Fall müsste die Produktlinie komplett an die Kundenbedürfnisse angepasst werden, incl. des invarianten Teils. Der Aufwand wäre sehr groß, dass es sich hier anbieten würde, das Produkt separat entwickelt zu lassen. Das heißt, das keine, oder nur sehr kleine Komponenten, aus der Produktlinie verwendet werden. 13

14 2 Technische Aspekte Produktableitung Nachdem die Vorarbeiten erledigt sind, muss jetzt das kundenspezifische Produkt abgeleitet werden. Bei der Ableitung von Produkten gibt es zwei Szenarien die angewandt werden: Produktlinienszenarien und Produktszenarien. Die Produktlinienszenarien beschreiben die Arten einer Produktlinie und werden im Domain Engineering festgelegt. Die Produktszenarien erhält man aus den Produktlinienszenarien. Man kann in diese noch weitere Anforderungen des Kunden integrieren. Die daraus resultierende szenariobasierte Produktableitung erfolgt in 3 Schritten (siehe [1]): 1. Abdeckung: In diesem Schritt werden die Produktlinienszenarien mit den Anforderungen des Kunden abgeglichen. Die Abdeckung sind die Anforderungen, die ohne Anpassung der Produktlinie angewendet werden können. 2. Deltas: Die Anforderungen, die nicht ohne Anpassungen der Produktlinie angewendet werden können, werden in diesem Punkt festgehalten. Der Kunde muss hier entscheiden, ob und wie die Umsetzung dieser Deltas durchgeführt werden soll. 3. Rückfluss: Für jeden Unterschied, der in Punkt 2 ermittelt wurde, wird überlegt, über dieser generell in die Produktlinie aufgenommen werden soll oder nicht. Dieser Schritt dient zur Anpassung an die aktuellen Gegebenheit, in der die Produktlinie eingesetzt werden soll. 14

15 3 Organisatorische Aspekte 3 Organisatorische Aspekte Zur Software- Produktlinienentwicklung gehören nicht nur die geänderten technischen Aspekte, sondern auch die organisatorischen Aspekte. Durch die neue Herangehensweise bei der Entwicklung treten auch neue Aufgabenfelder und Bereiche auf, die strukturiert und eingeführt werden müssen. In diesem Kapitel werden Organisationsstrukturen und der Transitionsprozess dargestellt. 3.1 Organisationsstrukturen Anforderungen Um mit Hilfe von Software- Produktlinien den gewünschten Erfolg in der Firma zu erzielen, müssen auch die Organisationsstrukturen zu dieser Firma passen. Die sieben generellen Anforderungen an Organisationsstrukturen, nach [1], sind: 1. Die Entscheidungen sollen möglichst schnell und einfach getroffen werden können. Dazu muss die Verantwortung klar festgelegt sein. Für die Produktlinie in ihrem gesamten Umfang und für die Anwendung von dieser müssen die Verantwortlichkeiten verteilt werden. 2. Die Aufgaben und Verantwortungen sollen sich in der Struktur widerspiegeln. 3. Die gemeinsamen Aufgaben sollen sich mit ihren Zuständigkeiten in der Struktur widerspiegeln. 4. Die Besprechungen usw. sollen gering gehalten werden. Notwendig sind sie aber auf jeden Fall, um sich über einzelne Aspekte auszutauschen, da es Abhängigkeiten zwischen den Verantwortungsbereichen geben kann. 5. Es soll kein Unterschied zwischen Mitarbeitern im Domain Engineering und Application Engineering gemacht werden. 6. Der Kontakt mit dem Kunden darf nicht vernachlässigt werden. 7. Die Mitarbeiter sollen motiviert werden. Es kann zum Beispiel sein, dass in einer Firma die Arbeiten im Domain Engineering höher oder niedriger bewertet werden als im Application Engineering. Verantwortlichkeiten können für den Test, für wiederverwendbare Komponenten usw. (nach [1]) vergeben werden. Einer Person können auch mehrere Verantwortlichkeiten übertragen werden. 15

16 3 Organisatorische Aspekte Organisationstheorie Ein Teil der Organisationstheorie besteht aus der Mitarbeitermotivation. In [1] wir ein Maß erwähnt, mit dem die Motivation als Funktion von Charakteristiken der Arbeitsorganisation gemessen wird: der Motivation Potential Score (MPS) (siehe [1]). Als klassische Organisationsstrukturen werden in [1] die Linien- und Stablinien- Organisation genannt. Die Aufteilung kann nach verschiedenen Gesichtspunkten erfolgen: z.b. Region, Produkt. Die Entscheidung, wie diese Aufteilung erfolgt, hängt von den gesetzten Schwerpunkten ab. Wenn man sich ganz auf die Fertigstellung der einzelnen Produkte konzentriert, ist die Aufteilung nach Produkten sinnvoll. Sollen aber z.b. die regionalen Besonderheiten betrachtet werden, z.b. dass ein Produkt für die Zielgruppe der Menschen die in Süddeutschland leben anders entwickelt werden soll, als für Menschen die in Norddeutschland leben, so ist die Aufteilung nach Regionen passend. Die Projektorganisation kann man in einer Matrix darstellen, in deren Zeilen die Projekte stehen und in deren Spalten die Funktionen aufgelistet sind. Jedes Projekt und jede Funktion hat einen Manager. Die Zuordnung der Verantwortlichkeiten an den Schnittpunkten muss geregelt werden Organisationsstrukturen Als erstes werden zwei grundlegenden Organisationsstrukturen betrachtet. Da gibt es einmal die Möglichkeit des verteilten Domain Engineering und einmal die des zentralen Domain Engineering. Beim verteilten Domain Engineering wird die Entwicklung des Domain Engineering, wie der Name schon sagt, verteilt. Die Verteilung erfolgt auf Unterprojekte, die das Domain Engineering für ein bestimmtes Produkt durchführen. Beim zentralen Domain Engineering gibt es eine Einheit, die dafür zuständig ist. Diese Einheit kann nach Bedarf angepasst werden. Diese beiden grundlegenden Organisationsstrukturen unterscheiden sich in der Erfüllung der Anforderungen, die in Kapitel dargestellt wurden. Die genauen Bewertungstabellen stehen in [1]. Beim zentralen Domain Engineering sind die ersten sechs Anforderungen teilweise bis vollständig erfüllt. Nur die Motivation wird nicht erfüllt, aber auch nicht verhindert. Beim verteilten Domain Engineering hingegen wird die Zuordnung der Verantwortung nicht erfüllt, aber auch nicht verhindert, es wird verhindert, dass die Struktur die Aufgaben widerspiegelt. Die Anforderungen 3 7 werden teilweise oder ganz erfüllt. In den drei komplexeren Organisationsstrukturen werden die Domänenaufgaben einmal als Funktion, einmal als Projekt und einmal als separate Einheit betrachtet. Beim letzten Fall des Domain Engineering als separate Aufgabe ist die Anforderung der Motivation nicht erfüllt aber auch nicht verhindert. Die restlichen Anforderungen sind teilweise bis ganz erfüllt. 16

17 3 Organisatorische Aspekte Kriterien zur Auswahl Die Punkte (siehe [1]) die in diesem Abschnitt genannt werden, soll die Entscheidung zur Wahl einer Organisationsstruktur unterstützen: Wenige Produkte oder wenige (im Allgemeinen gut bekannte) Kunden Viele Produkte in der Produktlinie und/oder viele (meist unbekannte) Kunden Ausgeprägte Kultur der Organisation Viele bzw. häufige Änderungen der Artefakte Inkrementelle oder parallele Entwicklung Viele alte Artefakte, die wiederverwendet werden Viele Gemeinsamkeiten Kunden fordern ein common look and feel der Produkte der Produktlinie (oder dies ergibt sich unter Wiederverwendungsaspekten) Starke Technologie- Abhängigkeit 17

18 3 Organisatorische Aspekte 3.2 Transitionsprozess Nachdem die Entscheidung für eine Organisationsstruktur getroffen wurde, muss die Produktlinienentwicklung in die Firma eingeführt werden PLE- Transitionsprozess PLE steht für Produktlinienentwicklung. Der PLE- Transitionsprozess dient dazu, einem Unternehmen bei der Umwandlung seines derzeitigen Status hin zur Produktlinienentwicklung zu unterstützen. Allein aus der Vielzahl der Firmen mit den verschiedensten Anwendungsbereichen lässt sich erkennen, dass es keinen einheitlichen, festen Weg gibt, um zur Produktlinienentwicklung zu kommen. Der PLE- Transitionsprozess, wie er hier beschrieben ist, zeigt die grundlegenden Schritte auf, die vorgenommen werden müssen. Bei diesem Prozess muss als erstes der aktuelle Status des Unternehmens ermittelt werden. In den nächsten beiden Schritten werden dann die Schritte bestimmt, die das Unternehmen gehen muss und zusätzlich werden diese Schritte detailliert entwickelt. Im vierten Schritt werden dann z.b. die Anwender geschult. Das nächste Bild zeigt den PLE- Transitionsprozess in einer Übersicht. 18

19 3 Organisatorische Aspekte Strategie und Scope Im ersten Schritt muss herausgefunden werden, was die Firma durch die Entwicklung mit Hilfe von Produktlinien erreichen möchte. Als nächstes wird dann der aktuelle Status festgestellt. Hier wird sich über die Produkte unterhalten, die die Firma in ihrem Sortiment hat. Die Unterschiede und Gemeinsamkeiten der Produkte werden analysiert und daraus wird die Grenze der Produktlinie und ihre Bestandteile ermittelt. Der nächste Punkt beinhaltet die Überprüfung des Prozesses und der Organisation. Der Ist- Status der Firma wird erhoben und es werden Überlegungen zur Änderung und Anpassung für die Produktlinienentwicklung angestellt. Danach muss sich noch über die neue Architektur Gedanken gemacht werden. Hier wird festgelegt, welche Features in die Architektur aufgenommen werden. Die nachfolgenden Aufgabe besteht aus einer Kosten- Nutzen- Analyse und einer Bestimmung der Risiken. Aus den vorher analysierten Punkten, der Ist- und Soll- Situation wird eine Abschätzung der Kosten und Nutzen gemacht. Zusätzlich werden hier noch Risiken identifiziert, die während dieses Prozesses auftreten können und welche Maßnahmen ergriffen werden müssen. Als Ergebnis der oben genannten Aktivitäten erhält man eine Strategie für diesen Transitionsprozess. Im zweiten und dritten Schritt wird die Planung und Implementierung vorgenommen. Die Planung hat einen so genannten PLE Action Plan zum Ergebnis, mit konkreten Maßnahmen zur Anpassung der vorhanden Strukturen hin zum Produktlinien- Entwicklungs- Ansatz. Im vierten Schritt erfolgt die Institutionalisierung, in dem in der Firma an einem Projekt die ersten Erfahrungen mit der Produktlinie gesammelt werden können. Als Ergebnis dieses Schrittes sieht man, ob und wenn ja, in welchem Umfang, noch Anpassungen vorgenommen werden müssen, um die Produktlinie effektiv in der Firma einsetzten zu können. Zusätzlich müssen die Mitarbeiter in der Anwendung von Produktlinien geschult werden. Es bringt keinen Vorteil, wenn die Produktlinie entwickelt und optimiert wurde, was auch schon Geld gekostet hat, und die Entwickler diese Produktlinie nicht verwenden können oder wollen. Danach erfolgt dann eine Breiteneinführung. Die Einführung muss überwacht werden, so dass rechtzeitig Maßnahmen ergriffen werden können, um den Erfolg der Transition nicht zu gefährden. Die Überwachung erfolgt durch Berichte an das Management Architektur In die Architektur werden von den existierenden Funktionalitäten die übernommen, die auch weiterhin erhalten bleiben sollen und die neuen Funktionalitäten werden ergänzt. Die Änderungen, die noch durchgeführt werden müssen, werden festgehalten. Danach werden für die einzelnen Komponenten Interfaces definiert. Die Komponenten werden genau definiert und evtl. in einem Prototypen implementiert. Einzelne Komponenten können, wenn sie zusammen effizient eingesetzt werden können, zu einem Ganzen zusammengefasst werden. Zum Schluss wird noch ein Repository, eine Zusammenfassung der einzelnen Komponenten und zusammengefassten Komponenten erstellt, um ein leichteres auffinden dieser zu ermöglichen. Zu diesem Repository gehören auch Regeln, wie mit diesem umgegangen werden muss, um eine möglichst hohe Effektivität zu erreichen. 19

20 3 Organisatorische Aspekte Prozess und Organisation Um Produktlinienentwicklung im Prozess- und Organisationsbereich einzuführen, Bedarf es vier Schritte (nach [1]): 1. Es müssen einige Themengebiete geändert oder neu hinzugefügt werden. Dazu gehören z.b. Domain Engineering, Application Engineering, Testen, und Produktlinienmanagement (nach [1]). 2. Nach dem der Transitionsprozess abgeschlossen ist, müssen für die einzelnen Bereiche die Verantwortlichkeiten festgelegt werden. (siehe dazu auch Kapitel 3.1) 3. Der Transitionsprozess muss überwacht werden, um frühzeitig eingreifen zu können, wenn Probleme auftreten. Überwacht werden müssen zusätzlich noch der Entwicklungsprozess und das Ergebnis, was daraus entsteht. Evtl. müssen noch neue Komponenten erstellt werden oder Komponenten müssen angepasst werden. 4. Der Kostenfaktor der Produktlinienentwicklung spielt auch eine Rolle bei der Einführung. Es muss geklärt werden, woher die Gelder kommen, um die wiederverwendbaren Komponenten zu entwickeln und wie diese Komponenten nachher beim Verkauf mit eingerechnet werden müssen. 20

21 4 Fazit 4 Fazit Die Entwicklung einer Software- Produktlinie erfordert eine genaue Analyse, um später effektiv eingesetzt werden zu können. Hierbei ist entscheidend, dass man die gemeinsamen und variablen Komponenten der Produktlinie identifiziert. Werden bei einer Produktlinie zu viele Komponenten als gemeinsamer Teil angenommen, so ist diese evtl. nicht mehr effektiv einsetzbar, da der Einsatzbereich sehr eingeschränkt ist. Sind die Gemeinsamkeiten auf der anderen Seite zu gering, so kann man keine Produktlinie daraus ableiten, oder die zusammengefassten Bereiche sind so gering, dass dies auch nicht zum schnelleren entwickeln und somit Kostenersparnis beiträgt. In der Organisation der Firma muss neu strukturiert werden, um an den Entwicklungsprozess einer Produktlinie angepasst zu werden. Es stehen verschiedene Organisationsstrukturen zur Verfügung, die in den verschiedenen Anforderungen (siehe Kapitel 3.1.1) unterschiedlich gut erfüllen. Um für die Firma die beste Struktur zu finden, wurden verschiedene Strukturen und Kriterien zur Auswahl betrachtet. Um das, was in den bisherigen Schritten an Entscheidungen getroffen wurde, in der Firma umsetzen, wurde ein Transitionsprozess vorgestellt. Dieser beschreibt die Einführung der Software- Produktlinien- Entwicklung in eine Firma. Zusammenfassend ist zu sagen, dass Software- Produktlinien eine gute Möglichkeit sind, auf dem Markt der Softwarefirmen zu bestehen. Als wesentliche Punkte sind nochmal die immer kürzere Zeit in der die Produkte auf den Markt kommen und die immer besseren Produkte zu nennen. 21

22 5 Literaturverzeichnis 5 Literaturverzeichnis [1] G. Böckle, P. Knauber, K. Pohl, K.Schmid (Hrsg.): Software- Produktlinien, Methoden, Einführung und Praxis. dpunkt.verlag, Heidelberg, 2004 [2] letzter Aufruf: [1] wurde in dieser Arbeit als Hauptquelle benutzt. Alle Abbildungen stammen aus dieser Quelle. 22