Product Line Development am Beispiel einer Software-Plattform für den Healthcare-Markt

Inhaltsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Product Line Engineering in Software-Großprojekten
1.2 Problemstellung im Kontext der Plattform syngo ©
1.3 Zielsetzung und Umfang der Arbeit

2 Zugrundeliegende Verfahren und Modelle
2.1 Produktlinienerstellung im Softwaremarkt
2.1.1 Domain Engineering
2.1.2 Application Engineering
2.1.3 Vereinfachtes Kostenmodell
2.1.4 Product Portfolio Scoping
2.2 Die Conjoint-Analyse als Instrument der Präferenzstrukturmessung
2.2.1 Funktionsweise der Conjoint-Analyse
2.2.2 Ausgewählte Verfahrensvarianten

3 Durchführung der Marktsegmentierung
3.1 Prototyping neuer Produkte im Healthcare Markt
3.2 Studiendesign und Kundenbefragung
3.3 Evaluation der Befragungsergebnisse
3.3.1 Hintergrundinformation zu den Teilnehmern
3.3.2 Nutzenwerte der Merkmalsausprägungen
3.4 Rückschlüsse auf Marktsegmente
3.4.1 A-Priori Segmentierung
3.4.2 A-Posteriori Segmentierung
3.4.3 Marktsimulation

4 Diskussion der Ergebnisse
4.1 Product Line Development
4.2 Nutzentheoretische Einordnung
4.3 Problematische Aspekte

5 Zusammenfassung und Ausblick
5.1 Fazit
5.2 Weiterführende Studien

Literaturverzeichnis

Anhang

Abkürzungs- und Akronymverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Plattform und Produkte in einer Produktlinie

Abbildung 2: syngo Plattform

Abbildung 3: Softwareentwicklungsprozess als V-Modell

Abbildung 4: Framework für die Software-Produktlinienentwicklung

Abbildung 5: Starke Interaktion zwischen unterschiedlichen Prozess-Segmenten im Bereich der Anforderungsanalyse

Abbildung 6: Vergleich der kumulativen Kosten

Abbildung 7: Wahrscheinlichkeit für ROI nach 5 Produkten in Normalverteilung

Abbildung 8: Kostenvergleich unter Berücksichtigung der Produktliniendegeneration

Abbildung 9: Einordnung von Features eines Produkts nach Kano

Abbildung 10: Modelltheoretische Einordnung von Produkteigenschaften und Nutzen U mittels Nutzenfunktionen

Abbildung 11: Volles Produktprofil bei der Full Profile Methode

Abbildung 12: Ranking zur Eliminierung von Attributen bei der ACA

Abbildung 13: Rating eines Profilpaars bei der ACA

Abbildung 14: Diskrete Auswahl bei der CBC

Abbildung 15: Prozessdiagramm für Conjoint-Analysen

Abbildung 16: Beispiel für die Präsentation eines Stimulus als Internet Seite in der Umfrage

Abbildung 17: Wie vertraut sind Sie mit Prototyping-Umgebungen, wie z.B. MevisLab, AVS oder OpenXIP?

Abbildung 18: Wie oft verwenden Sie ein derartiges Produkt in Ihrer täglichen Arbeit?

Abbildung 19: Ihre Rolle?

Abbildung 20: Welcher Organisation gehören Sie an?

Abbildung 21: Relative Wichtigkeit von Merkmalen einer Rapid Prototyping-Umgebung (in%)

Abbildung 22: Wie oft verwenden Sie ein derartiges Produkt in Ihrer täglichen Arbeit? (Erfahrener Nutzer)

Abbildung 23: Ihre Rolle? (Erfahrener Nutzer)

Abbildung 24: Relative Wichtigkeit von Merkmalen einer Rapid Prototyping-Umgebung (in%) für erfahrene Nutzer

Abbildung 25: Erfahrung je Cluster

Abbildung 26: Tägliche Verwendung je Cluster

Abbildung 27: Rolle je Cluster

Abbildung 28: Relative Wichtigkeit von Merkmalen einer Rapid Prototyping-Umgebung (in%) je Cluster

Abbildung 29: Mögliche Produktausprägungen für Prototyping-Umgebungen

Tabellenverzeichnis

Tabelle 1: Dateninterpretation der Kano-Methode

Tabelle 2: Beispiel für die Verteilung von Anforderungskategorien je Feature

Tabelle 3: Alternative Produktattribute für einen Computertomographen

Tabelle 4: Präferenz Lebenserwartung - Auflösung Käufer A durch Ranking

Tabelle 5: Präferenz Lebenserwartung - Auflösung Käufer B

Tabelle 6: Präferenz Lebenserwartung - Auflösung in Summe

Tabelle 7: Präferenz Lebenserwartung - Preis in Summe

Tabelle 8: Simulation des Gesamtnutzens von 2 Produkten

Tabelle 9: Kartenliste zur Befragung mittels CVA

Tabelle 10: Teilnutzenwerte des Gesamtsample (N=29)

Tabelle 11: Teilnutzenwerte erfahrener Nutzer (N=16)

Tabelle 12: Teilnutzenwerte je Cluster

Tabelle 13: Marktsimulation Bevorzugungswahrscheinlichkeit (in %)

1 Einleitung

1.1 Product Line Engineering in Software-Großprojekten

Obwohl Produktlinien bei klassischen Konsumentenprodukten, wie Autos, Nahrungsmitteln und Kleidung eine lange Tradition besitzen, sind sie im Bereich der Software-Produktion ein relativ neues Fachgebiet¹. Dies ist möglicherweise durch einen im Verhältnis zur industriellen Konsumgüterproduktion jungen technologischen Reifegrad und Komplexität von Softwaresy- stemen begründet. Beispielsweise sind grundlegende Technologien, wie die objektorientierte Softwareentwicklung erst seit Ende der 1980iger Jahre und die kommerzielle Komponenten- architektur in Form des Microsoft .Net Frameworks seit Januar 2002 verfügbar. Dennoch gab es schon in den 1990iger Jahren Bestrebungen, Vereinfachungen in der Software-Produktion durch wiederverwendbare Klassenbibliotheken zu erlangen. Bedingt durch sich erhöhende Komplexität und dabei immer größer werdenden Druck von Seiten steigender Produktionsko- sten und kurzfristigerer Markteinführungszyklen entwickelte sich die industrielle Fertigung von Softwarekomponenten zu ganzheitlichen Produktionsprozessen, in denen Wiederverwen- dung und sinnvoller Einsatz von Produktionsfaktoren eine immer stärker werdende Rolle spielen. Die Software-Produktlinienerstellung kann dabei sicher als das dominante Paradigma genannt werden². Voraussetzung ist eine auf Verwertbarkeit ausgelegte Plattform, deren abgeleitete Produkte durch Nutzung oder Konfiguration kommunaler Elemente eine Produktfami- lie formen³ (Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Plattform und Produkte in einer Produktlinie

Quelle: Eigene Darstellung nach von der Maßen (2007), S.3

Obwohl die technischen Aspekte im Feld des Product Line Engineerings in der Softwareindu- strie als weitgehend verstanden erscheinen⁴, sind innerhalb der Software-Produktionsprozesse vielfältige Herausforderungen anzutreffen, welche noch erheblichen Erklärungsbedarf bein- halten. Bisher wenig berücksichtigt bleiben beispielsweise Rationalisierungsverfahren im Be- reich des Produktmanagements umfangreicher Plattformen und deren Anforderungen.

Der Softwaremarkt für Plattformen ist sehr heterogen, da nicht nur die Nutzer der zukünftigen Endprodukte als Kunden angesehen werden können, sondern ebenfalls die Nutzer der Platt- formkomponenten, welche eigene Produkte mit diesen formen. Aufgrund unterschiedlicher Marktanforderungen der klinischen Endkunden an die Plattformkunden ergibt sich eine zu- sätzliche Dimension der Heterogenität von Anforderungen. Folglich kann die Plattform einen enormen Umfang annehmen. Daraus ergeben sich Probleme und Engpässe bezüglich der Res- sourcenzuordnung oder des Komplexitätsgrades von Software und Projekt. Insbesondere kann eine mögliche Defokussierung der produktiven Elemente des Software-Erstellungsprozesses eintreten. Dieser besitzt im Kontext eines Großprojektes enorme Auswirkungen auf die Pro- duktivität. Beispielsweise kann die Produktion bestimmter Produkte unterbrochen werden, wenn Abhängigkeiten zu noch nicht fertig gestellten Modulen der Plattform bestehen. Dies führt am Ende zur verspäteten Markteinführung des Teilprodukts oder der Plattform. Um die- sem Ergebnis entgegenzutreten, kann es bei Software-Plattformen von erheblichem Nutzen sein, die Teilkomponenten zu bewerten und für die Produktion in eine Form priorisierter Ar- beitspakete aufzubereiten. Die Ausarbeitung unterschiedlich gewichteter Software- Produktlinien innerhalb der Plattform, welche bestimmte Marktsegmente repräsentieren, scheint einen weiteren Ansatzpunkt zu bieten, um eine Fokussierung auf Komponenten des größten Teilnutzens der Plattformkunden zu ermöglichen, oder einfach die wichtigsten Mark- segmente zu bedienen.

Es ist jedoch sehr herausfordernd, Softwaremodule zu bestimmten Marktsegmenten zuzuord- nen und eine Nutzenbestimmung für den Plattformkunden durchzuführen. Die bekannten Me- thoden können oft nur einen Ausgangspunkt liefern und müssen im Zusammenhang mit der Produktlinienentwicklung erweitert werden.

1.2 Problemstellung im Kontext der Plattform syngo©

Die Firma Siemens AG erkannte früh den Nutzen einer Software-Plattform und verwirklichte den Ansatz in dessen Healthcare Sektor unter dem Namen syngo. Seit 1995 wird an der Platt- form syngo mit großem Aufwand gearbeitet. Bis in das Jahr 2008 haben mehr als 200 medizi- nische Software-Produkte aller Siemens Healthcare Geschäftszweige die Plattform als Basis angenommen⁵. Kumuliert sind etwa 80.000 Lizenzen an Kunden ausgeliefert worden, was eine ebenso hohe Zahl an verkauften Endprodukten nahelegt⁶. Unter Betrachtung dieser Di- mensionen kann die Etablierung von syngo als riesiger Erfolg gewertet werden.

Die Produktion erfolgt in Form modularer Versionspakete innerhalb des Geschäftsgebiets Image & Knowledge Management. Diese werden an andere Geschäftsgebiete geliefert, wel- che beispielsweise klinische Großgeräte produzieren, und dort in speziellen Abteilungen ad- äquat integriert. Die Plattform stellt einerseits fertige Grundfunktionalitäten bereit, wie zum Beispiel eine Patientendatenbank oder Bildverarbeitungsalgorithmen, dient aber anderseits hauptsächlich als Container für eigenständige Software-Produkte der Gerätehersteller (‹ [Abbildung in dieser Leseprobe nicht enthalten] Abbildung 2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: syngo Plattform

Quelle: Siemens AG - Healthcare, Image & Knowlede Management

Es hat sich als großer produktiver Vorteil erwiesen, Softwaremodule in unterschiedlichen klinischen Bereichen und verschiedenen bildgebenden Modalitäten wiederzuverwenden. In- genieure der Geräte-herstellenden Geschäftsgebiete sehen es als Vorteil an, sich nicht mehr mit grundlegender Bildverarbeitung oder Datenverwaltung beschäftigen zu müssen, sondern sich auf die technischen Herausforderungen ihrer konkreten Produkte konzentrieren zu können. Weiterhin wird die Plattform von Endkunden als Alleinstellungsmerkmal der Firma Sie- mens angesehen, da zwar alle namhaften Konkurrenzunternehmen im Healthcare Markt ähn- liche Software-Strategien bewerben⁷, einen vergleichbaren Integrationsgrad jedoch nie er- reicht haben. So wird von klinischem Personal unter anderem die gleichartige Bedienbarkeit unterschiedlicher syngo -Systeme positiv erwähnt. Dies erlaubt beispielsweise medizinisch- technischen Assistenten den Wechsel von einer bildgebenden Modalität zu einer anderen mit minimalem Schulungsaufwand⁸, wie von der Computertomographie zur Magnetresonanzto- mographie.

Als Kunden der Plattform des Geschäftsgebiet Image & Knowledge Management können hauptsächlich die Software-Entwicklungsabteilungen der Gerätehersteller angesehen werden, z.B. Siemens Magnetresonanztomographie oder Siemens Ultraschall Division. Zu einem ge- wissen Anteil trifft dies aber auch auf die klinischen Endkunden zu.

Zur Zeit erlebt syngo einen Generationswechsel, welcher einen enormen monetären und orga- nisatorischen Aufwand impliziert. Es wird der Technologiesprung von der Container- zur Komponentenarchitektur mittels Microsoft .Net gewagt, was kürzere und selektivere Update- zyklen der Plattform ermöglichen wird. Die in Form eines Client-Server basierten Systems geplante vollständige Integration in den Klinik Workflow kann als Paradigmenwechsel ange- sehen werden. Arbeitsabläufe lassen sich somit zentral steuern und dokumentieren, was das Aufzeigen eines verwaltungstechnischen Effizienzpotentials im klinischen Alltag verspricht. Eine serverseitige Bildverarbeitung erlaubt es dem klinischen Kunden, im Gegensatz zu Ein- zelsystemen, enorme Investitionskosten in Hardware einzusparen und die Verfügbarkeit von z.B. 3D Bildgebung zu erhöhen, da jeder herkömmliche Laptop, oder zukünftig sogar Hand- held Computer, als Client unabhängig vom Standort zur visuellen Befundung von Patienten- bilddaten dienen kann.

Bei der Produktion dieses neuen Systems treten insbesondere im Bereich der Produktdefiniti- on Konkretisierungs- und Fokussierungsprobleme zu Tage, welche sich als Effizienzprobleme in den nachgelagerten Softwareentwicklungsbereich fortsetzen. Es existieren etwa 9000 Ein- zelanforderungen an die Plattform, welche schwer überschaubar und priorisierbar sind. Grün- de sind in der heterogenen Kundenstruktur und organisatorischen Aspekten zu finden, auf die im Rahmen dieser Arbeit eingegangen wird. Eine richtige Priorisierung und Einordnung von komplexen Anforderungen stellt jedoch unbestritten den Ausgangspunkt für eine effiziente Produktion von Software dar⁹.

1.3 Zielsetzung und Umfang der Arbeit

Diese Arbeit soll einen neuartigen Ansatz für den Bereich des Product Portfolio Scopings als Teil des Produktmanagements von Software-Produktlinien darlegen. Sie kann in den Grenz- bereich zwischen Marktforschung und Requirements Engineering für Software-Produkte ein- geordnet werden.

Zuerst werden die grundlegenden Methoden und signifikanten Prozesse im Kontext von Pro- duktlinien analysiert. Im Rahmen der Analyse werden Probleme beziehungsweise Lösungen für die Produktdefinition erarbeitet. Die Software-Plattform syngo wird dabei als Basis einer Produktlinie angesehen.

Anschließend erfolgt das eigentliche Product Portfolio Scoping in Form einer multiattributi- ven Nutzwertanalyse. Zu diesem Zweck wird eine Kundenbefragung zu einer aktuellen Pro- blemstellung durchgeführt und die empirischen Daten in diverse Nutzenfunktionen überführt. Eine Conjoint-Analyse bestimmt die Nutzenanteile von Softwaremodulen einer ausgewählten Plattformkomponente. Diese werden für eine Marktsegmentierung von potentiellen Kunden verwendet und deren Präferenzstrukturen zur Definition von Produkten innerhalb einer neuen Produktlinie im Healthcare-Softwaremarkt herangezogen. Um die potentielle Akzeptanz von derartig identifizierten Produkten einschätzen zu können, wird anschließend eine Marktsimu- lation durchgeführt. In einem zweiten Schritt werden die Nutzwerte in eine modellhafte Prio- risierung von Anforderungen der identifizierten Produkte an die Plattform übertragen.

In der Arbeit wird sich mit der Frage auseinandergesetzt, ob die Conjoint-Analyse als Metho- de für das relativ neue Thema des Software-Produktliniendesigns verwendbar ist. Es wird untersucht, ob sie einen Beitrag zur Lösung der Probleme bei Konkretisierung und Priorisie- rung von Anforderungen an Software leisten kann. Schließlich werden mögliche Auswirkun- gen auf strategische Aspekte des Software Business erörtert und die Ergebnisse kritisch evalu- iert.

2 Zugrundeliegende Verfahren und Modelle

Im Folgenden werden die Hintergründe der Produktlinienentwicklung für Softwarefamilien dargelegt. Neben den Produktionsprozessen werden ökonomische Aspekte des Ansatzes erör- tert und der Zusammenhang zur Präferenzstrukturmessung als Entscheidungshilfe für Variabi- litäten ausgeführt.

2.1 Produktlinienerstellung im Softwaremarkt

Für die Produktion von singulären Software-Programmen hat sich der Prozess des V-Modells als industrieller Standard etabliert. Die in Abbildung 3 dargestellten Phasen stellen sicher, dass das fertig gestellte Produkt auch den Anforderungen der Kunden entspricht:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Softwareentwicklungsprozess als V-Modell

Quelle: Eigene Darstellung nach Rupp (2007), S.50

Um Software in Form von Produktlinien zu produzieren, genügt es nicht, einfach nur die Software-Architektur umzustellen. Vielmehr ist die Einführung eines ganzheitlichen Unter- nehmensprozesses mit gleichzeitiger Anpassung der Organisationsstrukturen notwendig. Dies bedingt insbesondere eine Abkehr vom klassischen V-Modell. Das Software Engineering In- stitute der Carnegie Mellon Universität¹⁰ schlägt diesbezüglich eine grundsätzliche Teilung aller organisatorischen Bereiche in ein Plattformsegment, im Folgenden Domain Engineering genannt, und ein Produktentwicklungssegment, im Folgenden als Application Engineering bezeichnet, vor¹¹. Diese Bereiche sind durch Prozesse miteinander assoziiert, erhalten jedoch eine weitgehend eigenständige Verantwortung. In der Literatur wird diese Zweiteilung in zwei Hauptprozesssegmente als Two-Life-Cycle Approach¹² oder Two-Tiered Development Process¹³ referenziert. Einen kompletten Überblick über alle beteiligten Prozesse liefert Abbildung 4:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Framework für die Software-Produktlinienentwicklung

Quelle: Pohl/Böckle/van der Linden (2005), S.22

Von allen ganzheitlichen organisatorischen Aspekten für Unternehmen, soll in dieser Arbeit Abstand genommen werden¹⁴. Im Gegenzug werden die Prozesskomponenten für die Platt- formanalyse bzw. –definition und ihre Interaktionen herausgearbeitet.

2.1.1 Domain Engineering

Das Hauptprozesssegment Domain Engineering ist für die Planung und Umsetzung der Soft- ware-Plattform verantwortlich, in der alle kommunalen Module zusammengefasst sind. Derar- tige Kommunalitäten stellen Gemeinsamkeiten dar, welche in Einzelprodukten kontinuierlich wiederverwendet werden können. Die Produktdefinition ist gekennzeichnet durch die Erfas- sung dieses Gültigkeitsbereichs der Plattform und der Sicherstellung, dass zusätzlich die geforderte Variabilität vorhanden ist, um die gewünschten Produktausprägungen der Plattform- kunden zu unterstützen. Die notwendige Analyse erfolgt im Produktmanagement und ist Aus- druck einer Vision oder Marktstrategie. Weiterhin wird eine Produkt Roadmap mit Daten zur geplanten Fertigstellung der Einzelprodukte erstellt. Damit wird die Basis für das so genannte Domain Requirements Engineering geschaffen, welches sich hauptsächlich mit der Identifikation aller Anforderungen an die Plattformarchitektur und dem Management der Implementie- rung derer befasst. Es können diesbezüglich 5 grundlegende Phasen abgeleitet werden¹⁵:

1. Erhebung aller Features, die von Kunden der Plattform benötigt werden
2. Dokumentation dieser Anforderungen in einer restriktiven und strengen Form
3. Verhandlungen mit den Partnern aus dem Application Engineering, um einen Konsens über die adäquate Fertigungstiefe diverser Plattformanteile zu erzielen, also wie stark sie die Endprodukte beeinflussen
4. Validierung und Verifikation der Anforderungen, um sicherzustellen, dass diese klar, komplett, richtig und verständlich sind
5. Überwachung der Anforderungen während des Implementierungsprozesses und des gesamten Plattform Lebenszyklus

Es ist ersichtlich, dass Produktmanagement und Requirements Engineering der beiden Haupt- prozesssegmente (Domänen- und Produkt Engineering) in starker gegenseitiger Abhängigkeit stehen, weshalb deren Einzelprozesse gut aufeinander abgestimmt und eindeutige Terminolo- gien präsent sein müssen. Andernfalls können Kommunalitäten und Variabilitäten schnell übersehen werden, was sich sehr nachteilig auf Produktionskoeffizienten der späteren End- produkte, wie Entwicklungsdauer oder Softwarequalität, auswirkt. In der Praxis wird häufig auch die Analyse möglicher neuer Kommunalitäten bei einem Übergang zur nächsten Platt- formgeneration vernachlässigt. Dies ist einerseits mit projektspezifischen Parametern zu be- gründen, wie zur Verfügung stehende Analysezeit oder Ressourcen, anderseits aber auch durch organisatorische Einflüsse, da Vertreter einzelner Produkte innerhalb der Plattform da- zu tendieren, die Kommunalitäten zu unterschätzen oder bewusst Funktionalitäten aufgrund vorhandener Detailkenntnisse als Alleinstellungsmerkmal gegenüber anderen Produkten ansehen. Dieses Konkurrenzverhalten kann als „Kannibalisierung“ innerhalb der Produktlinie angesehen werden, dem vom Management Einhalt geboten werden sollte¹⁶. Es ist von Bedeutung, dass für die Plattform innerhalb der Organisation eine Atmosphäre der Gemeinsamkeit etabliert ist, denn nur bei vollständiger Zusammenarbeit kann der Produktlinienansatz zum Markterfolg aller Produkte führen¹⁷. In Phase 3 des Schemas auf Seite 8 sollte sich mit den Vertretern des Application Engineering der Plattformteilnehmer über eine potentielle Priori- sierung der zu erstellenden kommunalen Elemente geeinigt werden, um einen effizienten Produktionsablauf in beiden Prozesssegmenten garantieren zu können. Das Produktmanagement kann dabei die Rolle eines Vermittlers übernehmen und gefundene optimale Reihenfolgen bzw. Prioritäten für das Projektmanagement und die Engineering Prozesse dokumentieren. Einen Eindruck der engen Verzahnung der Parteien innerhalb der Produktdefinition liefert Abbildung 5:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Starke Interaktion zwischen unterschiedlichen Prozess-Segmenten im Bereich der Anforderungsanalyse

Quelle: Eigene Darstellung nach Pohl/Böckle/van der Linden (2005), S.165

Auf die Beschreibung der in Abbildung 4 ersichtlichen technischen Prozesse Domänen- Design, Domänen-Realisierung und Domänen-Test soll an dieser Stelle nicht eingegangen werden, da sie den Rahmen dieser Arbeit sprengen würden. Sie entsprechen jedoch der Denkrichtung der Zweiteilung und besitzen ebenfalls segmentspezifische Teilprozesse und Ver- antwortungsbereiche¹⁸.

2.1.2 Application Engineering

In diesem Bereich werden die kommunalen Plattformanteile kombiniert und dazu genutzt, Einzelprodukte für den Endkunden herzustellen. Durch Einarbeitung spezifischer Funktionali- täten werden die Alleinstellungsmerkmale eines Produkts realisiert. Oberstes Ziel für das Re- quirements Engineering ist die Identifikation von impliziten Kommunalitäten und angebote- nen Variationspunkten in der Plattform, um in der Produktentwicklung den gewünschten ho- hen Grad der Wiederverwendung zu erzielen. Selbstverständlich sind alle Paradigmen, welche für die Anforderungsanalyse von singulären Software-Produkten gelten, weiterhin gültig¹⁹.

Zusätzlich müssen allerdings einige Anpassungen an die signifikante Prozessänderung in der Produktdefinition für Plattformen erfolgen. So müssen spezielle Applikationsanforderungen an das Domain Requirements Engineering kommuniziert werden, um spätestens in folgenden Plattformgenerationen berücksichtigt zu werden. Es ist ebenfalls von hoher Bedeutung, mög- liche Gemeinsamkeiten zu anderen Produkten, welche noch nicht in der Plattform abgebildet sind, als Kommunalität oder Variationspunkt vorzuschlagen, da im Domain Engineering die- ses Detailwissen nicht präsent ist. Mit einer Angabe des Anpassungsaufwands, z.B. in Form von Entwicklungstagen, kann von den Parteien der Produktdefinition entschieden werden, ob es lohnenswert ist, Vorteil aus späterer Wiederverwendung in anderen Produkten zu erzielen. Gleichermaßen sollte durch das Produktmanagement eine Einreihung dieser neuen Anforde- rungen in die Plattformprioritäten erfolgen, da sonst die Gefahr einer Überbewertung besteht und der Verlust des Fokus innerhalb der Software produzierenden Elemente des Domain En- gineerings erfolgen kann.

Von der Darstellung der konkreten technischen Implementierungsprozesse für das Applicati- on Engineering wird sich analog zu Absatz 2.1.1 abgegrenzt.

2.1.3 Vereinfachtes Kostenmodell

Die Wiederverwendung von Softwareteilen hat hohe Einsparungseffekte bei Herstell- und Maintenance-Kosten neuer Produkte innerhalb der Produktlinie zur Folge²⁰. Die monetären Auswirkungen der Wiederverwendung innerhalb von Software-Produktlinien können durch ökonomische Modelle verdeutlicht werden. Im Folgenden werden produktive Aspekte des zuvor erläuterten Produktlinienansatzes mittels unterschiedlicher Kostenfunktionen abgebildet und illustratorisch der Return on Investment (ROI) für mehrere Produktliniengenerationen bestimmt²¹.

Ausgangspunkt für diese Darstellung ist die Einführung einer neuen Software-Plattform als Basis zukünftiger Produktlinien. Bei Einführung und Nutzung fallen folgende vier Kostenar- ten in Form von Teilkostenfunktionen an:

- C org: Kosten für die Etablierung einer Organisation, um den Produktlinienansatz auf be- stehende Produkte anzuwenden. Diese Kosten beinhalten die Reorganisation, Pro- zessanpassung, Training und andere organisatorische Posten.
- C cab: Kosten die entstehen, um eine Software-Kernbibliothek (Core Asset Base, CAB) zu produzieren, welche die abzubildende Produktlinie voll unterstützt. Dies beinhaltet Kosten für die Analyse von Kommunalität und Variabilität, Implementierung einer generischen Softwarearchitektur, deren Dokumentation und Test²².
- C unique: Kosten für die Entwicklung einzigartiger Softwareteile, die nicht auf der Plattform basieren. Normalerweise lässt sich diese Kostenart nur auf einen relativ kleinen Teil eines Produkts abbilden, in Extremfällen kann sie aber ein komplettes Produkt bein- halten.
- C reuse: Die Kosten, die aufgewendet werden müssen, um die CAB wiederzuverwenden. Dies beinhaltet Kosten, um ein kommunales Kernmodul zu lokalisieren, es in den applikationsspezifischen Entwicklungsprozess zu überführen, die produktspezifische Anpassung vorzunehmen und zusätzliche Integrationstests durchzuführen.

Die Gesamtkosten C pl, um die Produktlinie für n Produkte p zu etablieren, können mit folgen- der Kostenfunktion ausgedrückt werden:

Abbildung in dieser Leseprobe nicht enthalten

In Software-Produktionsorganisationen sind die ursprünglichen Herstellkosten eines Produkts im konventionellen Produktionsprozess C prod durch Erfahrungswerte (z.B. Function Point Analyse²³) und Kalkulationen der kaufmännischen Abteilungen meist sehr genau bekannt.

Aus diesen erkennbaren Werten können die Teilkostenfunktionen in Formel (1) hergeleitet und vergleichsweise in folgende vereinfachte schematische Darstellung überführt werden²⁴:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Vergleich der kumulativen Kosten

bei Einzelherstellung (rot) und Produktlinienansatz (schwarz)

Quelle: Eigene Darstellung in Anlehnung an Böckle/Clements/ et al. (2004), S.29

Auffällig sind in der Abbildung die Produktlinien-Fixkosten C PL_fix, welche sich aus den Teilkostenfunktionen C org und C cab zusammensetzen. Diese Kostenarten bedürfen in einer realen Umgebung einer besonderen Beobachtung, da der monetäre Gesamterfolg signifikant durch sie beeinflusst werden kann. Beispielsweise können die Reorganisationskosten in gro- ßen Organisationen teilweise erheblich ausfallen. Es ist außerdem gut ersichtlich, dass C PL_fix sich in diesem Beispiel bereits nach 2 Produkten amortisiert haben.

Die obige Betrachtung entspricht aber nur der ersten Generation der Produktlinie. In der zwei- ten Generation entstehen zusätzlich Anpassungskosten F cab der CAB, da neuartige Technolo- gien auch Eingriffe in die Basisbibliotheken bedingen. Im Gegensatz dazu werden die Reor- ganisationskosten C org geringer ausfallen oder gar nicht mehr auftreten, da die Organisation bereits etabliert ist.

[...]

---

¹ Vgl. von der Maßen (2007), S.1

² Vgl. Clements/Northrop (2001)

³ Vgl. McGregor/Northrop/et al. (2002), S.25: Schlüssel zum Erfolg von Software-Produktlinien

⁴ Vgl. Linden/Schmid/Rommes (2007), S.112 ff.: Der Produktlinienansatz wird anhand von Praxisberichten namhafter Unternehmen der Software Industrie als Erfolgsmodell beschrieben.

⁵ Die Integration umfasst die gesamte Siemens Healthcare Produktpalette, angefangen von Bildmanagementsy- stemen (PACS), den klinischen Bereichen Kardiologie, Neurologie, Onkologie, Pädiatrie, Traumatologie und anderen.

⁶ Quelle: Siemens AG, Image & Knowledge Management, Business Operations

⁷ Vgl. Medical Imaging (2003), Newswatch, o.V.: Erwähnenswert ist an dieser Stelle die Plattformvariante VEQUION der Firma Philips Medical Systems. Diese beschränkt sich im Rahmen der Integration allein auf ein gleichartiges User Interface seiner Produkte. Algorithmen und Verhalten der Anwendungen sind produktspezi- fisch und nicht Teil der Plattform.

⁸ Vgl. Smith (2002)

⁹ Vgl. Rupp (2007), S.476: Ungenügende Priorisierung von Software Artefakten wird allgemein als großer Risikofaktor für Produktionskosten und Produkterfolg angesehen.

¹⁰ Vgl. Northrop, (2008), http://www.sei.cmu.edu/productlines/adopting_spl.html

¹¹ Vgl. Clements/Northrop (2001)

¹² Vgl. Linden/Schmid/Rommes (2007), S.14

¹³ Vgl. Pohl/Böckle/van der Linden (2005), S.20

¹⁴ Vgl. Linden/Schmid/Rommes (2007), S.59 ff.: Das Produktlinienkonzept besitzt tiefgründige Auswirkungen auf unternehmerische Organisationsstrukturen.

¹⁵ Vgl. Linden/Schmid/Rommes (2007), S.49

¹⁶ Vgl. Pohl/Böckle/van der Linden (2005), S.381: Bei einem über die Organisation verteilten Domain Enginee- ring kann die Projektfinanzierung der Produkte problematisch sein. Vertreter eines Produkts fühlen sich mögli- cherweise nur ihrem Kunden verpflichtet, denn dort werden Mittelzuflüsse generiert.

¹⁷ Vgl. Linden/Schmid/Rommes (2007), S.32: Problematik der Konkurrenz mehrerer Produkte einer Familie

¹⁸ Vgl. Pohl/Böckle/van der Linden (2005), S.116 ff.

¹⁹ Vgl. Rupp (2007): Aufgrund der allgemeinen, umfangreichen und gut dokumentierten Natur der Paradigmen soll an dieser Stelle nur auf diese vollständige Abhandlung verwiesen werden.

²⁰ Vgl. Pohl/Böckle/van der Linden (2005), S.56-88: Ein orthogonales Variabilitätsmodell führt zu Vorteilen in allen Bereichen der Software-Produktion. Gut dokumentierte Variabilität kann zur Komposition von Produkt- linien verwendet werden und in Rahmen der Produktdefinition zur Selektion der zu untersuchenden Teilnut- zenattribute herangezogen werden.

²¹ Vgl. Böckle/Clements/et al. (2004): Ein Kostenmodell zur Berechnung des Return of Investment wird zum Vergleich traditioneller Einzelproduktentwicklung und des Produktlinienansatzes erörtert. Mögliche Einspa- rungseffekte für verschiedene Markteinführungsszenarien werden ausgearbeitet.

²² Vgl. Böckle/Clements/et al. (2004), S.24: Es wird vernachlässigt, ob erst die komplette CAB implementiert wird, ohne parallel bereits an Produktartefakten zu arbeiten (proaktive Strategie), oder diese inkrementell bei gleichzeitiger Adaption oder Einführung von Produkten entsteht (reaktive Strategie).

²³ Vgl. Ebert/Dumke/et al. (2005), S.100-106: Die Function Point Analyse von Software-Produkten kann dazu dienen, aus Erfahrungswerten bereits produzierter Softwaremodule Zeitaufwände für abgeleitete und gleich- wertige neue Module abzuschätzen. Damit lassen sich grob auch Produktionskosten ableiten.

²⁴ Es wird unrealistisch angenommen, dass jedes Produkt ungefähr den gleichen Funktionsumfang besitzt und damit die Produktionskosten pro Produkt gleich sind.