Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik

Transkript

1 Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik Ausarbeitung zum Seminar Softwaretechnik, Institut für Softwaretechnik, TU Berlin Dozent: Ramin Tavakoli Koligari Autoren: Marcus Besch, Wijaya Sathriawan

2 Die klassische Softwareproduktion Erstellt und vermarktet ein Unternehmen mehrere Softwareprodukte, so stellt sich die klassische Organisation der Softwareproduktion folgender Maßen dar: Für jedes zu erstellendes Produkt wird ein eigenes Projektteam mit einem eigenem Budget aufgestellt. Jedes Team erstellt unter Zeitdruck sein Produkt, ohne nähere Kenntnis der anderen Produkte und ohne Verwendung gemeinsamer Assets. Viele Arbeiten werden von mehreren Projektteams redundant durchgeführt. Dieser klassische Ansatz begrenzt durch Redundanz die Produktionskapazität des Unternehmens und verursacht enorme Kosten. In vielen Fällen kommt es zu Terminschwierigkeiten und den damit verbundenen Imageverlust. Industrialisierung der Produktion durch Produktlinien Obwohl die Informationstechnologie der entscheidende Motor in der Rationalisierung und Effizienzsteigerung in ihren klassischen Anwendungsgebiete ist, vermag sie es nur schwerlich, ihre eigenen Entwicklungsprozesse zu rationalisieren. Ein erheblicher Teil von Software wird dazu hergestellt um in den Anwendungsgebieten manuelle Arbeitsschritte oder Prozesse zu automatisieren und um die Effizienz der Produktion zu steigern. In der Softwaretechnik hingegen werden Rationalisierungen meistens nicht dazu verwendet, Systeme effizienter zu entwickeln, sondern um immer mächtigere und komplexere System herstellen zu können. Wenn man die Entwicklung der Industrialisierung unter dem Gesichtspunkt der Produktionskapazität betrachtet, so ist die erste Entwicklungsstufe vergleichbar mit dem Künstlertum. Das Künstlertum zeichnet sich dadurch aus, das mit vergleichbar hohem Aufwand Einzelstücke (Unikate) angefertigt werden. Dies trifft auf die meisten Projekte in der Softwareentwicklung zu. Einigen Unternehmen in der Softwarebranche gelingt es, die nächste Entwicklungsstufe zu erreichen, wenn sie mehrere unterschiedliche Produkte gleichzeitig produzieren können. Auf dieser Stufe befindet man sich auf einer Ebene mit der Produktionskapazität eines Handwerksbetriebes. Das höchste Stufe der Industialisierung ist bildet die vollautomatisierte und standardisierte Industrieproduktion, mit der eine Vielzahl von Produkten und Produktvarianten effizient entwickelt werden können. Abbildung 1: Entwicklungsstufen der Industrialisierung Das Konzept der Produktlinien stellt einen alternativen Ansatz zu den klassischen Produktionsprozessen dar und ist in den klassischen Anwendungsgebieten der IT, wie beispielsweise der Automobilindustrie, beim Flugzeugbau, in Chemie- oder Pharmaindustrie (in Bereichen, wo in hohen Stückzahlen produziert wird) bereits weit entwickelt. In der Softwareentwicklung hingegen ist das Konzept der Produktlinien noch nicht weit verbreitet und derzeit auch noch ein Forschungsgegenstand. Somit stellt diese Herangehensweise einen Umbruch in der Softwareentwicklung dar und ermöglicht erst den Einstieg in die Industrialisierung der Softwareproduktion. Was sind Software-Produktlinien? Das Software Engineering Institute der Carnegie Mellon Universität in den USA definert, Produktlinien im Kontext der Softwareentwicklung folgendermaßen: A software product line is a set softwareintensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market or mission and that are developed from a common set of core assets in a prescribed way. [Clements & Northrop]

3 In Anlehnung an diese Definition, ist die Grundlage für die Entwicklung von Software unter Verwendung des Produktlinien-Ansatzes das Konzept der systematischen und strategisch geplanten Wiederverwendung und die Umsetzung organisierter Variabilität einer gemeinsamen Plattform. Systematisch geplante Wiederverwendung bedeutet in diesem Zusammenhang, dass Bestandteile von Produkten zunächst in Form einer gemeinsamen Plattform entwickelt werden und die Produkte durch Wiederverwendung einzelner Bestandteile der Plattform nach fest definierten Regeln erstellt werden. Development) der Produktentwicklung (Product Development) und dem Management-Prozess Alle drei Kernprozesse laufen in der Produktlinienentwicklung parallel und greifen ineinander. Plattform und Core Assets Ein zentraler Bestandteil des Produktlinienkonzeptes ist die Plattform, die alle in Rahmen der Softwareentwicklung erzeugten Artefakte (Core Assets) umfasst. Die Plattform bildet den Bausteinkatalog, der alle Komponenten beinhaltet, die für die Erstellung unterschiedlicher Produkte wiederverwendet werden können. Im Gegensatz zu dem herkömmlichen Ansätzen zur Wiederverwendung von Softwarebestandteilen, schließt die Plattform auch alle nicht-technischen Artefakte ein, die nicht Bestandteil der Implementierung sind. Dazu gehören beispielsweise auch Anforderungen, rechtliche Bestimmungen, Architekturbeschreibungen, Spezifikationen und Testfälle. Darüber hinaus sieht das Produktlinienkonzept neben der Plattform keine weiteren produktoder kundenspezifische Komponenten vor, die nicht Bestandteil der Plattform sind. Folglich ist es nicht möglich, spezielle kundenspezifische Produkte zu entwickeln, die aus Bestandteilen bestehen, die nicht Teil der Plattform sind. Kundenprojekte gibt es in der Produktlinienentwicklung nicht. Produktlinienentwicklung Die Entwicklung von Software-Produkten durch eine Produktlinie wird nach [Clements & Northrop] durch drei parallel verlaufende Kernprozesse realisiert: die Entwicklung der Plattform mit gemeinsam verwendeten Softwareartefakten (Core Asset Abbildung 2: Die 3 Kernprozesse nach [Clements & Northrop] Desweiteren sind neben den drei Kernprozessen weitere orthogonale Aspekte für die Produktentwicklung relevant. Dazu gehören: das Product Scoping die Variabilitätsmodellierung die Architekturmodellierung und die Produktinstanzierung Die 3 Kernprozesse Die Entwicklung der Plattform und der Architektur der Produktlinie erfolgt getrennt von der Produktentwicklung. Im ersten Prozess (Core Asset Development) werden individuelle Softwarebestandteile durch Entwicklerteams erstellt und gewartet, die in den meisten Fällen nicht an der Produktentwicklung beteiligt sind (und umgekehrt). Dabei evolvieren einzelne Softwareartefakte unabhängig von einander und durchlaufen separat die klassischen Entwicklungsphasen von der Anforderungsanalyse bis zur Testdurchführung auf Komponentenebene.

4 Im zweiten Entwicklungsprozess werden die Softwareartefakte der Plattform verwendet, um konkrete Produkt zu erzeugen. In diesem Prozess werden die Anforderungen modelliert, die nur für eine konkrete Produktvariante gelten Die Entwicklerteams entscheiden darüber hinaus, welche Bestandteile der Plattform für die Realisierung des Produktes verwendet werden. Da diese Artefakte bereits durch den ersten Entwicklungsprozess bereitgestellt werden, findet in der Produktentwicklung im wesentlichen keine Produktimplementierung mehr statt, so dass auf technischer Ebene lediglich die Vorschriften für die Synthese ( Bauplan ) der für ein Produkt ausgewählten Bestandteile der Plattform entwickelt werden müssen. Der Managementprozess steuert und überwacht die gesamte Produktlinienentwicklung und sorgt für eine adequate Ressourcenverteilung zwischen den anderen beiden Entwicklungsprozessen. Product Scoping Der Product Scope ist ein Begriff auf aus dem Produktmarketing und umfasst die Menge aller Produkte die von einem Unternehmen entwickelt werden können. Das Bewertungsverfahren, das festlegt, welche Produkte Produkte entwickelt wird, ist in den meisten Softwareprojekten beschränkt auf eine Kosten/Nutzen-Analyse und auf die empirische Bewertung des eigenen fachlichen und technischen Kompetenzbereiches. Bei der Produktlinienentwicklung ist das Product Scoping für die strategische inhaltliche Ausrichtung der Produktlinie von zentraler Bedeutung und legt fest, welche Produkte auf Basis der gewählten Plattform erzeugt werden können (Product Scoping). Zusätzlich wird festgelegt, welche Technologien und Funktionalitäten die Kernkompetenz bilden, auf dessen Basis die Plattform entwickelt wird (Domain Scoping) und welche Komponenten wiederverwendet werden können (Asset Scoping). Variabilitätsmodellierung Obwohl die Plattform einer Produktlinie alle Bestandteile enthält, aus denen innerhalb des gewählten Product Scopes alle Produkte entwickelt werden können, können Produkte nicht aus allen denkbaren Kombinationen der Softwareartefakte erstellt werden. Jede Produktlinie besitzt ein begrenztes Maß an Variabilität, die die Vielfalt der realisierbaren Produktvarianten nach oben beschränkt. Abbildung 3: Schematische Darstellung von Produktvarianten nach [Reiser] Die Variabilitätsmodellierung legt dazu methodologisch fest, welche Komponenten der Plattform miteinander kombinierbar sind. Das zur Variabilitätsmodellierung gehörende Verfahren der Feature-Modellierung sei an dieser Stelle nur namentlich erwähnt und ist ein separates Ausarbeitungsthema. Vorteile, Herausforderungen und Risiken Der Einsatz von Produktlinien in der Softwareentwicklung ermöglicht neue Chancen und vor allen Wettbewerbsvorteile. Abbildung 4: Tendenz der Amortisierung einer Produktlinie Weitere Vorteile sind unter anderem: Kürzere Time to Market Kürzere Time to Revenue Höhere Produktkapazitäten möglich

5 Erhebliche Reduktion der Kosten Erhebliche Qualitätssteigerung Effektivere Ressourcennutzung Höhere Kundenzufriedenheit Motivationssteigerung der Mitarbeiter Entscheidend für den Einsatz von Produktlinien jedoch ist, dass die Produktentwicklung die industrielle Fertigung von Softwareprodukten erst möglich macht. Dem gegenüber stehen eine Reihe von Herausforderungen, die mit der Einführung und dem Betrieb von Produktlinien einhergehen: Hoher Aufwand für die Initialisierung einer Produktlinie Produktentwicklung erfordert eine Organisationsstruktur mit erhöhtem Kommunikationsaufwand Komplexe und robuste Architekturen notwendig Stringente Einhaltung von definierten Prozessen notwendig Hohe Qualitätsanforderungen an Dokumentation Hoher generischer Anteil in der Produkterzeugung Neben der Bewältigung dieser Herausforderungen, bestimmen unter anderem eine Vielzahl von Risiken und deren Vermeidung über den erfolgreichen Einsatz einer Produktlinie, von denen an dieser Stelle nur einige wenige genannt sind: Keine Unterstützung durch das höhere Management Schlechte interne Kommunikation Schlechtes Anforderungsmanagement das Fehlen eines Erfahren Architekten / schlechte Architekturwahl Schlechte Werkzeugwahl Schlechtes Timing zwischen Plattformund Produktentwicklung Schlechte Spezifikationen Schlechtes Variabilitätsmodell Zu viele Abhängigkeiten zwischen Komponenten der Plattform Zusammenfassung Der Ansatz der Produktlinienbasierten Softwareentwicklung setzt voraus, dass das Ziel die effiziente Entwicklung eine Menge unterschiedlicher Produkte ist, die ein hohes Maß an Gemeinsamkeiten haben. Denn in der Produktentwicklung ist die Wiederverwendung strategisch und organisatorisch geplant und vom Management forciert. Die individuelle Produktentwicklung mit Bestandteilen außerhalb der gewählten Plattform ist mit Produktlinien hingegen nicht möglich. Die Produktlinienentwicklung unterscheidet sich in wesentlichen Punkten von der etablierten Softwareentwicklungsprozessen, in dem neue Entwicklungsaspekte, wie beispielsweise das Product Scoping oder die Variabilitätsmodellierung eine wichtig Rolle spielen und in ihrer Handhabung wesentlich zum Erfolg oder Misserfolg der Produktlinienentwicklung beitragen.

6 Quellen Zum Einstieg in das Thema Softwareproduktlinien [Clements & Northrop 2002] Software Product Lines Practices and Patterns, Addison Wesley, 2002 (siehe auch: [Java Magazin 03/07] Die Industrialisierung der Software-Produktion, Java Magazin, Ausgabe 03/2007, S Weitere Quellen [GoPhone 2004] GoPhone A Software Product Line in the Mobile Phone Domain, Frauenhofer Institut für Experimentelles Software Engineering, IESE Report No /E, 05. März 2004 [PESOA 2002] Process Family Engineering in Service-Oriented Applications PESOSA Report No. 02/2004, 06. Februar 200 (siehe auch: [Böckle et al 2004] Software-Produktlinien Methoden, Einführung und Praxis, Günter Böckle, Peter Knauber, Klaus Pohl, Klaus Schmid (Hrsg.), dpunkt Verlag, Mai 2004 [van der Linden 2002] Software Product Families in Europe: The Esaps & Cafe Projects, IEEE Software, Ausgabe Juli/August 2002 [Reiser 2007] Produktlinien, Variabilität und Feature-Modellierung, Mark-Oliver Reiser, in Softwarequalitätsmanagement, TU Berlin, Vortrag vom 22. Mai 2007 [Bühne et al 2004] Anforderungsmanagement in der Automobilindustrie: Variabilität in Zielen, Szenarien und Anforderungen, Stan Bühne, Kim Lauenroth, Klaus Pohl, Informatik 2004 Informatik verbindet, Gesellschaft für Informatik, Ulm 2004, S