Der Aufruf zum 1. Workshop “Langlebige Softwaresysteme” la¨sst in seiner Sicht darauf, was forschungsseitig fu¨r erfolgreiche Langlebigkeit von Softwaresystemen zu tun ist, vernachla¨ssigte Bereiche erkennen. Dieser Artikel zeigt auf, wo diese liegen, warum die Vernachla¨ssigung problematisch ist und mit welcher Maßnahme eine Bescha¨digung des resultierenden Forschungsprogramms vermutlich vermieden werden kann.
1http://www.fzi.de/index.php/de/forschung/forschungsbereiche/se/6783 ich eine Kritik dieser gefundenen Gewichtung vor und schlage eine Erga¨nzung des Forschungsprogramms vor (Abschnitt 4). 2
Hier eine mo¨gliche Sicht, was insgesamt an Facetten zu bedenken und zu erforschen ist, wenn man die Langlebigkeit von Systemen sta¨rken mo¨chte.
Nicht jedem wird die Einteilung und die Formulierung gefallen – etwa, weil sie vielleicht eine Gewichtung nahelegt, die er oder sie nicht teilt, oder weil manche Themen als nicht softwaretechnischer Art empfunden werden. Ich hoffe aber, dass niemand hierin klaffende Lu¨cken entdeckt oder Eintra¨ge, die er oder sie als komplett falsch einstufen wu¨rde. 1.1 Produktstruktur: Wissenschaftliche Erkenntnis daru¨ber, was langlebigkeitsgeeignete Software-Architekturen ausmacht. 1.2 Entwicklungsmethoden: Wissenschaftliche Erkenntnis daru¨ber, wie man solche Architekturen im gegebenen Einzelfall entwickelt und dauerhaft erha¨lt. Das betrifft alle Teilaufgaben der Softwaretechnik von der Anforderungserhebung u¨ber den Entwurf und die Realisierung bis hin zu Verifikation/Validierung sowie dem Projekt, Prozess-, Qualita¨ts-, Anforderungs- und Risikomanagement. 1.3 Produktinfrastruktur: Wiederverwendbare Technologien, um Strukturen nach 1.1 einfach, verla¨sslich und schnell umsetzen zu ko¨nnen. Dies betrifft geeignete Programmiersprachen, generische Komponenten (wie Betriebssysteme, DBMS, Frameworks, Middleware und andere, deren Natur zum Teil vielleicht noch gar nicht entdeckt ist), sowie bereichsspezifische Komponenten. 1.4 Methodeninfrastruktur: Softwarewerkzeuge zur technischen Unterstu¨tzung der Methoden von 1.2. 2.1 Investitionsentscheidung f u¨r die no¨tigen Einmalkosten, z.B. Beschaffung von Werkzeugen und deren Einfu¨hrung. Dies geschieht bei der jeweils betroffenen Softwareorganisation. Der wissenschaftliche Aspekt daran besteht darin, zu verstehen, wie solche Entscheidungen heute zustande kommen und zu beschreiben, wie sie idealerweise zustande kommen sollten. 2.2 Investitionsentscheidung fu¨ r die no¨tigen Kosten im Einzelfall. Das betrifft insbesondere die Bereitschaft, entsprechend qualifiziertes Personal zu bezahlen und diesem die no¨tige Zeit zum sauberen Verfolgen der Methoden von 1.2 zur Verfu¨gung zu stellen. Wissenschaftlicher Aspekt analog zu 2.1. 3.1 Individuelle Mo¨glichkeiten: Die no¨tigen Fa¨higkeiten (Talent) und Fertigkeiten (Ausbildung und praktische Erfahrung) bei den einzelnen handelnden Softwareingenieur/inn/en, um die Grundlagen nach 1.1 bis 1.4 geeignet einsetzen zu ko¨nnen. Wissenschaftliche Fragestellungen in diesem Bereich betreffen die Beschreibung, welches Maß an Fa¨higkeiten und Fertigkeiten in welchen Bereichen von 1.1 bis 1.4 no¨tig wa¨re, welches Maß an Fa¨higkeiten heute typisch ist und mit welchen Methoden man die Fertigkeiten optimal trainieren kann. 3.2 Individuelle Bereitschaft: Die no¨tige Disziplin bei den einzelnen handelnden Softwareingenieur/inn/en, um die Grundlagen nach 1.1 bis 1.4 im konkreten Einzelfall (insbesondere unter Zeitdruck) auch tatsa¨chlich hinreichend vollsta¨ndig und korrekt einzusetzen. Wissenschaftliche Fragen in diesem Bereich: Wo mangelt es wie sehr an solcher Disziplin? Warum? Wie kann man das reduzieren? 3
Hier gebe ich die Themenliste aus dem Workshop-Aufruf wieder und markiere jeweils, welchen Bereichen der obigen Taxonomie ich die Eintra¨ge zuordne. U¨ber diese Zuordnung mag man hier und da streiten, das ist nicht schlimm: Fu¨r die Zwecke dieses Artikels reicht eine ungefa¨hre Zustimmung aus.
Anpassbarkeit und Evolution – evolutionsfa¨hige Software-Architekturen (1.1) – Anpassbarkeit von Anwendungen an wechselnde Plattformen, sich vera¨ndernde
Anforderungen und Randbedingungen (1.1, 1.2) – Koevolution zw. Anforderungen, Architektur und Implementierung (1.1, 1.2) – Variabilita¨t auf Anforderungs- und Architekturebene wie z.B. in Produktlinienansa¨tzen (1.1, 1.2) Reengineering – Verfahren zur Erkennung von Legacy-Problemen und ihrer Ursachen (1.2) – Metamodelle fu¨r die Integration von Wissen u¨ber Software (1.2) – modellbas. Reengineering und Refactoring bestehender Systeme (1.2, 1.3, 1.4) – Modellextraktion durch Programmverstehen (1.2, 1.4) Entwicklungs-, Betriebs- und Wartungsmethoden – modellbasierte und architekturzentrierte Methoden und Techniken fu¨r (die Integration von) Entwicklung und Betrieb langlebiger Softwaresysteme (1.2, 1.4) – Business-IT-Alignment, gescha¨ftsorientierte Evolution der IT (1.2, evtl. 2.2) – Lebenszyklus-u¨bergreifendes Anforderungsmanagement (1.2) – Roundtrip-Engineering, integrierte Entwicklung auf Modell- und Codeebene (1.2, 1.4) – virtuelle Maschinen zur Erzielung von Plattformunabha¨ngigkeit (1.1, 1.3) – kooperative Entwicklungsmethoden (1.2, evtl. 3.1/3.2), Kommunikations- und Kooperationswerkzeuge und Entwicklungsumgebungen, die die enge Zusammenarbeit von Doma¨nenexperten, Anwendern und Softwareentwicklern unterstu¨tzen (1.4) – Qualita¨tsbewertung langlebiger Softwaresysteme (1.2) – Qualita¨tssicherung beim Betrieb langlebiger Softwaresysteme (1.2) Wie man sieht, deckt der Workshop nur die Bereiche 1.1 bis 1.4 der Taxonomie ab (reine Software-Technik), aber beru¨ hrt allenfalls zart die Sektoren 2.1/2.2 (Verha¨ltnisse in SWOrganisationen) und 3.1/3.2 (individuelle menschliche Faktoren). 4
Dies ist kein U¨bersichtspapier und deshalb werde ich gar nicht erst versuchen, die folgenden Aussagen mit wissenschaftlicher Literatur zu untermauern, sondern sie ganz als perso¨ nliche Ansichten formulieren: