Software Engineering und Software-Engineering-Forschung im Zeitalter der Digitalisierung

Konkret können wir gegenwärtig wenigstens diese sieben Trends über Software und das Software Engineering beobachten:

Mit der Industrialisierung und der Vergesellschaftung von Software und Daten einhergehend ist auch zu beobachten, dass immer mehr Menschen aktiv in die Entwicklung von Software eingebunden sind, sei es durch die Bereitstellung von Anforderungen, das Testen von Systemen im Feld oder die Teilnahme an der Softwareentwicklung selbst und dass mit immer kürzeren Innovationszyklen auch immer kürzere Entwicklungszyklen einhergehen. Konkret wird Software zur Laufzeit durch nachladbare Komponenten und Apps stark veränderlich, erweiter- und anpassbar. Der Mensch ist als Datenquelle heute (mehr passiv) Teil von Softwareökosystemen. Aber auch zur aktiven Konfiguration (z. B. der vielen einzelnen Geräte im zukünftigen E‑Home) werden immer mehr Menschen die Fähigkeit benötigen, rudimentär Software zu programmieren („Programming as a Commodity“). Zudem rückt der Mensch als User immer mehr in den Fokus der Entwicklung, um durch neue Interfaces wie Sprachein- und -ausgabe oder Augmented Reality die User Experience zu optimieren. Software Engineering muss sich also in Zukunft nicht nur mit der Entwicklung von Software beschäftigen, sondern auch mit deren hoch-adaptiver Konfigurierbarkeit, Benutzerakzeptanz und der Qualitätssicherung von konfigurierter und durch Daten trainierter Software.

Schon aus technischer Perspektive ergeben sich aus den obigen Beobachtungen neue Herausforderungen, die auch eine neue Standortbestimmung der nunmehr 50 Jahre alten Disziplin des Software Engineering [1‐4] erfordern:

Daraus lassen sich einige Konsequenzen für Software Engineering ableiten:

Gemeinsam ist all diesen Herausforderungen, dass zum einen dadurch die Komplexität der Software weiter massiv ansteigen wird, zum anderen, dass immer mehr Menschen in verschiedenen Rollen mit Software und ihrer Entwicklung zu tun haben werden und von ihrer Funktionalität und von ihren Entscheidungen noch stärker als bisher abhängen werden. Insbesondere ist eine oben genannte Konsequenz daraus, dass auch der Bedarf an Nachvollziehbarkeit und Erklärbarkeit von Software steigen wird. Nur so wird auch die notwendige Akzeptanz beim Nutzer, bei Organisationen und in der Gesellschaft insgesamt erreichbar sein. Auch ist klar, dass es noch weniger als heute Personen geben wird, die ein Gesamtverständnis – oder auch nur einen detaillierten Überblick – haben werden. Die Konsistenzhaltung der verschiedenen Sichten auf ein System wird also immer wichtiger.

Wie einleitend, beschrieben wird der Bezug zu anderen Ingenieurswissenschaften gegenwärtig geprägt durch

Letztlich bedingen diese Faktoren einander, sodass wir sie gemeinsam mit dem letzten beginnend ausführen.

Im Vergleich zu den Artefakten anderer Ingenieursdisziplinen ermöglicht die Eigenschaft von Software, nicht materiell zu sein, einen größeren Entwurfsraum, der kaum durch physische Materialeigenschaften eingeschränkt ist. Werkzeuge und Methoden sind unter dem Stichwort Agilität in den letzten Jahren intensiv weiterentwickelt worden, sodass schnelle Feedback- und Innovationszyklen in der Software üblich sind. Seit etwa 2000 wissen wir, dass die Time-to-Market im Internetzeitalter noch viel wichtiger geworden ist und im Internet „ein Jahr nur drei Monate“ dauert. Negative Auswüchse des schnellen Entwickelns, wie etwa der Bananensoftware, die erst beim Kunden reift, sind durch methodische Maßnahmen, wie etwa aktive Beta-Tester, testgetriebene Entwicklung, frühe Reviews (z. B. auch Pair-Programming) oder kontinuierliches Monitoring des Kundenverhaltens und damit auch der Kundenzufriedenheit abgefangen worden.

Wenn Software selbst keine physikalische Manifestation hat, ist ihre „Produktion“ reduziert auf den Build-Prozess, das Deployment und die Konfiguration. Da diese Vorgänge weitgehend automatisierbar sind, ist vor allem der Entwicklungsprozess, um den sich traditionell ja das Software Engineering kümmert, der limitierende Faktor. Dabei spielen die einzelnen entwickelnden Menschen, die Teamstruktur und -zusammensetzung sowie die Randbedingungen durch die Organisation eine größere Rolle als bei anderen Ingenieurswissenschaften. Sie prägen den Prozess der Produktentwicklung erheblich und beeinflussen damit letztlich auch Qualitätseigenschaften des Produkts selbst intensiv. Diese menschlichen und organisatorischen Faktoren sind deshalb ebenfalls ein wichtiger Einflussfaktor und damit Untersuchungsgegenstand des Software Engineering. Darüber hinaus bietet das Software Engineering als Disziplin eine Fülle an Techniken und Methoden, welche die Effizienz und Effektivität der menschlichen Interaktion im Kontext der Softwareentwicklung optimieren.

Dadurch ergeben sich für die Entwicklung softwareintensiver technischer Systeme eine Reihe von Möglichkeiten, Einsichten aus dem Software Engineering zu übertragen. Dazu gehören zum Beispiel Vorgehensmodelle, die nicht mehr von der Vorausplanbarkeit eines ganzen Systems ausgehen, sondern eine dezentrale Entwicklung von Systemen erlauben, die lose gekoppelt sind und keinem gemeinsamen Entwicklungsprozess unterliegen, obwohl sie Systemkomponenten und -schnittstellen teilen. Dazu gehören zum Beispiel auch agile Verfahren zur Unterstützung schneller Innovationszyklen. Da Software letztlich auch ein Modell der Realität mehr oder weniger explizit und ausführlich in sich trägt, sind Verfahren der Modellierung aus dem Software Engineering, wie zum Beispiel die UML, SysML oder Meta-Modellierung, sowie die Synthese, Analyse und Transformation von Modellen von besonderem Interesse für das Systems Engineering, zumal der Umgang mit Modellen und deren Analyse und Simulation ohnehin zum bestehenden Ingenieursvorgehen passt. In der Praxis zeigt sich aber, dass die Modelle der Software Engineering und des Systems Engineering bzw. die zugrunde liegenden Paradigmen nicht einfach vereint werden können und daher noch viel grundlegende Forschung notwendig ist.

Besonders sichtbar ist die Nutzung von Modellierungstechniken, wenn diese nicht nur zur Entwicklung, sondern auch während des Betriebs der Software im Einsatz sind. Traditionell sind das zum Beispiel explizite Datenmodelle oder Geschäftsprozessmodelle, die manchmal in Grenzen, aber öfter auch flexibel anpassbar sein sollen. In der Produktwelt sind das digitale Twins, also rein virtuelle, durch Modelle und Simulationen betriebene „Zwillinge“ physischer Artefakte, die auch Meta-Information enthalten und durch prädiktive Techniken zur Vorhersage von Eigenschaften, aber insbesondere zur Kontrolle und Steuerung ihrer physischen Zwillinge eingesetzt werden können. Die gemeinsame, weil eng verzahnte Entwicklung des physischen Produkts und seines virtuellen Zwillings erfordert neue Techniken. Dies ist auch deshalb notwendig, weil auch viele physische Produkte mit der Zeit ergänzt, erweitert, aktualisiert oder durch Ersatzteile modifiziert werden und ein digitaler Zwilling dies reflektieren und idealerweise sogar antizipieren muss. Hier wird das bestehende Verständnis von „Digital Engineering“ substanziell erweitert, indem nicht „nur“ bestehende Entwicklungsprozesse durch Software unterstützt werden, sondern nun auch softwaretechnische Methoden neue Entwicklungsprozesse ermöglichen. Eine Vision wäre die integrierte Modellierung und Analyse in einem gemeinsamen Entwurfsraum, im dem Software, aber auch physische Artefakte methodisch gemeinsam behandelt werden. Natürlich müssen diese Verfahren systematisch mit Fragen der unterschiedlichen Lebenszyklen von Software und physischen Artefakten umgehen und dabei ihre Konsistenz sicherstellen.

Es ist wie immer im Software Engineering: Die Einführung neuer Systeme verändert die Verhaltensweisen und Aktivitäten (Geschäftsmodelle und -prozesse, Support, etc.) der NutzerInnen. Das muss so sein, denn sonst wäre die Software sinnlos. Die zurzeit massiv voranschreitende Digitalisierung wird daher starke Konsequenzen für Individuen, Organisationen, Unternehmen und die Gesellschaft haben, die durchaus mit denen der Industrialisierung im 19. Jahrhundert vergleichbar sind. Offensichtlich hat sich das Kommunikationsverhalten bereits massiv verändert. Untersuchungen zeigen aber auch Änderungen der menschlichen Kognition durch die allgegenwärtige Nutzbarkeit digitaler Geräte oder der Arbeitsweisen von Teams. Die Auswirkungen neu entstehender Geschäftsmodelle und ihrer gesellschaftlichen Auswirkungen können im sozialen und im Arbeitsleben immens sein, wenn die Wertschöpfung durch Automatisierung und dem damit auch verbundenen Wegfall traditioneller Arbeitsplätze zugunsten neu geschaffener digitaler Arbeitsplätze einhergeht. Dazu kommen Geschäftsmodelle, die aus personenbezogenen Daten Werte schöpfen und Social-Media-Anwendungen, die durch das permanente Feedback zu den Handlungen einzelner auch grundlegende Rechte wie Privatheit oder Gleichbehandlung zumindest neu austarieren.

Die Erforschung dieser Effekte auf Einzelne, Organisationen und die Gesellschaft insgesamt ist in den Sozialwissenschaften als Technologiefolgenabschätzung bereits im Gange und beeinflusst auch das Software Engineering.

Daher gibt es mehrere Schnittstellen des Software Engineering zu den Sozialwissenschaften, die auch deshalb relevant sind, weil viele Möglichkeiten der Digitalisierung und die daraus folgenden Verwendungsformen aktuell noch nicht umgesetzt sind, sondern höchstens angedacht werden. Dazu gehören sowohl Techniken der Speicherung und Verarbeitung personenbezogener Daten im Bereich Data Science als natürlich auch die Methoden der künstlichen Intelligenz, die im aktuellen Hype-Zyklus einige weitere Probleme lösen wird, aber auch dieses Mal alle nicht Probleme, zu deren Lösung Intelligenz notwendig ist, in den Griff bekommen dürfte. Software Engineering steht demnach zu den Sozialwissenschaften in folgenden Wechselwirkungen:

Eigentlich war es schon immer eine Aufgabe des Software Engineering, sicherzustellen, dass Software nachvollziehbar ist. Allerdings steigt die Komplexität von Software, die aus immer umfangreicheren Technologie-Stacks sowie aus immer mehr und stärker vernetzten Anwendungskomponenten entsteht, weiter deutlich an. Es werden immer häufiger selbstlernende Komponenten, aber auch traditionell programmierte intelligentere („smarte“) Komponenten zur Kontrolle immer kritischerer und mit immer mehr Sensorik behafteter und daher unsicherer Systeme eingebaut werden. Machine-Learning-Komponenten komplizieren dies weiter. Die Verstehbarkeit von Software, also insbesondere die Nachvollziehbarkeit der Entscheidungen und Kontrolle, die Software trifft bzw. ausübt, wird daher in der nächsten Zeit deutlich wichtiger. Dabei ist Nachvollziehbarkeit während der Nutzung aber auch „post mortem“, zum Beispiel zur Verbesserung der Software oder für gerichtliche Klärungen, notwendig. Sollte das nicht nachhaltig gelingen, werden roboterpsychologische Analysen für das Verhalten intelligenter Maschinen im Sinne von Asimovs notwendig.

Während die anderen Ingenieurswissenschaften im Wesentlichen die Naturwissenschaften und die Mathematik als Grundlagenwissenschaften nutzen, sind dies für das Software Engineering vor allem die Mathematik, aber auch die Sozialwissenschaften, weshalb eine Befruchtung in beide Richtungen (zwischen Software Engineering und Sozialwissenschaften) sinnvoll und notwendig ist.

Software Engineering und die zugehörige Forschung sind seit langem klar definiert, daran ändern auch aktuelle Diskussionen wie hier oder im Zuge von 50 Jahre Software Engineering [1] nichts. Die folgende, bereits 1990 im IEEE Glossary of Software Engineering Terminology [5] vorgenommene Definition ist auch heute noch gültig und muss aus Sicht der Autoren nicht adaptiert werden:

Sie definiert das Software Engineering als Ingenieursdisziplin („application of engineering to software“) mit einer eigenen Methodik („systematic, disciplined, quantifiable approach“), angewendet auf alle Phasen des Lebenszyklus von Software („development, operation, and maintenance of software“). Der zweiteilige Aufbau der Definition bringt auch die enge Verzahnung von Software Engineering (1) und Software-Engineering-Forschung (2) zum Ausdruck. Die Grenzen zwischen beiden verschwimmen bisweilen. In der Software-Engineering-Forschung ist auf alle Fälle die systematische Reflexion deutlich ausgeprägter und der angestrebte Nutzen sowie die Generalisierbarkeit der Ergebnisse jenseits einzelner Projekte deutlich größer. Eine scharfe Trennung kann jedoch nicht gezogen werden, da zum Beispiel die Entwicklung eines Frameworks, Werkzeugs oder Meta-Modells gleichzeitig sowohl Anwendungs- als auch Forschungscharakter haben kann.

Klassischerweise differenziert sich Software-Engineering-Forschung selbst in die spezifische Betrachtung der unterschiedlichen Aktivitäten im Softwarelebenszyklus. Diese sind Analyse, Design, Implementierung, Testen, Deployment und Wartung. Hinzu kommen Querschnittsaktivitäten wie Projektmanagement, Qualitätsmanagement, Modellierung und Modellierungssprachen oder Variantenmanagement, die ebenfalls Teil der Software-Engineering-Forschung sind. Den zentralen Untersuchungsgegenständen in all diesen Kern- und Querschnittsaktivitäten des Softwarelebenszyklus können vier Bereichen zugeordnet werden:

Als Ingenieursdisziplin folgt das Software Engineering sinnvollerweise einem Design-Science-Ansatz, bei dem Artefakte sich auf alle vorhin genannten Untersuchungsgegenstände des Software Engineering beziehen können. Der Begriff „Artefakt“ ist dabei relativ breit angelegt und schließt Werkzeuge, zum Beispiel automatisierende oder unterstützende Algorithmen etwa zur Testfallgenerierung, Templates zur Dokumentation von Anforderungen oder eine Methodik für die Aufwandsschätzung von Softwareprojekten mit ein. Mit der Durchdringung diverser Produkte und Dienstleistungen mit Software nimmt neben der systematischen Konstruktion von Artefakten die kreative Innovation eine immer bedeutendere Rolle ein und wird auch zunehmend durch Ansätze wie das Design Thinking oder Continuous Experimentation unterstützt. Werkzeuge spielen eine herausragende Rolle im Software Engineering, da sie die entwickelten Artefakte für die praktische Nutzung zugänglich machen. Erst die Existenz bestimmter Arten von Werkzeugen haben moderne Entwicklungsmethoden, wie zum Beispiel agile Entwicklung, möglich gemacht. Extreme Programming wäre ohne leichtgewichtige Testinfrastruktur, schnelle Generatoren und Übersetzer sowie Entwicklungsumgebungen mit integrierten Refactoring-Werkzeugen undenkbar. Der Komfort von spezifischen Editoren für Programmiersprachen (typspezifische Autovervollständigung, Highlighting, Refactoring im Editor) hat die Programmierweise der Entwickler massiv verändert. Hätten wir solche Werkzeuge auch in den früheren Phasen, wären auch Requirements Engineering, Architektur und Design wesentlich effizienter. Auch fehlen uns gute Werkzeuge zur Nachverfolgung von Anforderungen und Designentscheidungen, die man dringend benötigt, um den Impact von Änderungen zu antizipieren.

Software Engineering bzw. die Anwendung in konkreten Projekten beinhaltet typischerweise eine ausgeprägte Reflexion, die sowohl zur Optimierung innerhalb des Projekts als auch zur Weitergabe von projektübergreifendem Wissen genutzt werden. Daraus ergibt sich die Konsequenz, dass ein Teil der Software-Engineering-Forschung notwendigerweise im industriellen Kontext vorgenommen werden muss und es deshalb des Einsatzes empirischer Methoden bedarf, um im industriellen Kontext Evidenz abzuleiten, etwa um Entscheidungen zu unterstützen, welches Prozessmodell in welcher Adaptierung in welchem Kontext am effektivsten funktioniert. Das „Manifest für Agile Softwareentwicklung“ [7] etwa wurde 2001 auf einem Treffen von Praktikern formuliert und von diesen in die Praxis der Softwareentwicklung getragen. Die Aufgabe der Software-Engineering-Forschung ist es, in diesem Zusammenhang die Methoden wissenschaftlich fundiert weiterzuentwickeln und deren praktischen Einsatz kritisch und empirisch fundiert zu hinterfragen und zu bewerten, um sie dadurch abhängig vom Anwendungskontext durch die Bereitstellung von Evidenz zu optimieren.

Aufgrund der Anwendungsorientierung und der durch Software getriebenen Digitalisierung spielen auch Einflussfaktoren und Einflussgruppen für die Software-Engineering-Forschung eine große Rolle. Zu den Einflussfaktoren gehören die Verlässlichkeit („Dependability“), die Nachhaltigkeit („Sustainability“) und die Benutzerfreundlichkeit („Usability“). Verlässlichkeit ist traditionell stark vom Einsatz softwarebasierter Systeme in kritischen Domänen wie der Luftfahrt beeinflusst und umfasst Attribute wie Zuverlässigkeit („Reliability“), Sicherheit („Safety“), Verfügbarkeit („Availability“ und damit letztlich auch Performanz), Wartbarkeit („Maintainability“) und Informationssicherheit („Security“), aber zunehmend auch Nachvollziehbarkeit und Erklärbarkeit, speziell im Kontext moderner datengetriebener Anwendungen. Ausgehend vom ökologisch geprägten schonenden Umgang mit Ressourcen beinhaltet die Nachhaltigkeit auch ethische Aspekte wie die Fairness von Entscheidungsalgorithmen. Usability steht für die Benutzerfreundlichkeit oder Gebrauchstauglichkeit eines softwarebasierten Produkts oder eine Dienstleistung und gewinnt insbesondere mit neuen Benutzerschnittstellen zunehmen an Bedeutung.

Als Einflussgruppen spielen die Wirtschaft, der Staat und die Gesellschaft eine große Rolle, etwa indem sie den rechtlichen Rahmen für die Entwicklung und den Einsatz von Software abstecken, wie zum Beispiel durch die Datenschutzgrundverordnung in Bezug auf die Verarbeitung personenbezogener Daten.

Als Ingenieurswissenschaft ist das Software Engineering wie andere Ingenieurswissenschaften auch auf die Erkenntnisse von Grundlagenwissenschaften angewiesen. Für die anderen Ingenieurswissenschaften sind im Wesentlichen die Naturwissenschaften und die Mathematik die Grundlagenwissenschaften, im Software Engineering ist die Situation durch den immateriellen und den immanent humanen Charakter komplexer. Natürlich sind die Informatik, die etwa genetische Algorithmen für das Search-Based Software Engineering oder die damit verwandte künstliche Intelligenz bereitstellt, und das Data Science als Datenwissenschaft wichtige Grundlagendisziplinen für das Software Engineering. Mit der zunehmenden Bedeutung der cyber-physikalischen Systeme sind auch andere technische Wissenschaften wie die Elektrotechnik oder der Maschinenbau bzw. die Physik als deren Grundlage wichtige Grundlagendisziplinen. Wie bereits erwähnt sind aber auch die Wirtschafts- und Sozialwissenschaften wie die Betriebswirtschaftslehre, die Soziologie oder die Psychologie wichtige Grundlagenwissenschaften für die Software-Engineering-Forschung. Wenn demnächst biologische Informationsverarbeitung stärker eine Rolle spielt, wie das heute Human-Brain-Projekte oder Modellierung biologischer Systeme mit Informatikmethoden andeuten, werden auch Biologie und Chemie als Grundlage noch relevanter.

Der enge Bezug des Software Engineering zu Grundlagenwissenschaften ist bereits im Software Engineering Body of Knowledge (SWEBoK) [6] sichtbar, in dem eigene Kapitel Computing Foundations, Mathematical Foundations und Engineering Foundations im Wesentlichen auf die Grundlagenwissenschaften Informatik, Mathematik und Ingenieurswissenschaften verweisen.

In der Software-Engineering-Forschung entstehen dabei bestimmte Fragestellungen, die mithilfe der Grundlagenwissenschaften adressiert werden. Diese stellen Algorithmen oder Theorien bereit, die formal-mathematischer, physikalischer oder sozialwissenschaftlicher Natur sein können, die im Forschungsprozess des Software Engineering in die Entwicklung und Evaluierung von Lösungen einfließen und die als Artefakte und Evidenz wieder in die Anwendungsdomänen zurückfließen können.

Je nach betrachtetem Untersuchungsgegenstand kann Software Engineering daher sehr mathematiknah und analytisch formal sein, zum Beispiel, um formale Modelle oder Programme zu behandeln, aber auch sehr empirisch und experimentell, um etwa spezifische Hypothesen über den menschlichen Faktor bei der Entwicklung und der Nutzung zu untersuchen. Die dritte große Säule des Erkenntnisgewinns, die Simulation, ist im Software Engineering als Test bereits intensiv im Einsatz und wird bei integrierter Qualitätssicherung von Software (beispielsweise durch Architektur- oder Verhaltenssimulation) in einem komplexen System wie etwa einer Smart City auch in anderen Formen noch intensiver eine Rolle spielen. Im Software Engineering fehlen aber immer noch Eigenschaften klassischer Ingenieursdisziplinen, wie der durchgängigen modellbasierten Simulation vor der Realisierung zur frühen Qualitätsbewertung. Abgesehen von einzelnen Ansätzen (wie Software-Architektursimulation) ist allerdings auch unklar, ob eine solche frühe Simulation auf Modellbasis zur Qualitätsbewertung von den klassischen Ingenieursdisziplinen auf das Software Engineering direkt übertragbar ist, da ja Software selbst im Gegensatz zu physischen Artefakten wie Brücken einen immanenten Modellcharakter hat.

Software und damit auch das Software Engineering ist seit jeher eine Integrationsdisziplin. Dies gilt natürlich für Produkte ganz besonders, die typischerweise aus Subsystemen und Komponenten integriert werden. Dies gilt aber auch für Entwicklungsmethoden, in denen je nach Art des Subsystems unterschiedlichste Methoden anderer Informatikteildisziplinen zum Einsatz kommen. SoftwareingenieurInnen sind daher Generalisten. Demgegenüber gibt es praktisch für jeden Teilaspekt der Software jeweils eigenständige Spezialistenrollen. Dies ist so im Bereich der Netzwerke, der Betriebssysteme, der Datenbanken, der eingebetteten Systeme, der Cloud, des Übersetzerbaus, des Entwickelns von (domänenspezifischen) Modellierungssprachen, der Nutzerinteraktion und natürlich auch der Sprach- und Bilderkennung mit statistischen Methoden oder maschinellem Lernen. Software Engineering greift deshalb nicht nur auf Grundlagendisziplinen wie die Informatik zu, sondern erweitert und bereichert diese auch. Aus diesem Grund sind die Informatik im Speziellen und Wissenschaft im Allgemeinen auch als Anwendungsdomänen in Abb. 1 angeführt.

Die großen Problemstellungen und Herausforderungen der Softwareentwicklung und damit auch der Software-Engineering-Forschung sind heute stark von der Anwendungsdomäne beeinflusst. Der Begriff Anwendungsdomäne kann dabei relativ breit gefasst werden und umfasst klassische Domänen wie Finanzen, Gesundheitswesen, Mobilität wie Automotive oder Avionik, Logistik, Unterhaltung, Handel oder Produktion. Darüber hinaus kann aber auch jede wissenschaftliche Disziplin wie die Informatik oder jede Sozial‑, Ingenieurs- oder Naturwissenschaft, in denen heute größere Softwaresysteme im Einsatz sind, als Anwendungsdomäne verstanden werden.

Die Anwendungsdomänen stellen den Kontext, d. h. Daten und Problemstellungen aus einem bestimmten Sachzusammenhang, für die Software-Engineering-Forschung bereit. In der Software-Engineering-Forschung werden Artefakte (etwa Werkzeuge oder Entwicklungsmethoden) und/oder Evidenz, d. h. empirisch oder formal fundierte Einsichten bereitgestellt, um die Problemstellung im Anwendungskontext zufriedenstellend zu adressieren.

Mittlerweile ist klar, dass zwar die Fragestellungen für die Softwareentwicklung in allen Domänen sehr verwandt sind, aber die Antworten häufig sehr unterschiedlich ausfallen müssen. Sichtbar wird dies unter anderem bereits an den sehr heterogenen Technologie-Stacks und den verwendeten Programmiersprachen. Dementsprechend gibt es für viele Domänen jeweils eigene Ausprägungen des Software Engineering und damit sinnvollerweise auch der Software-Engineering-Forschung. Domänenspezifisches Software Engineering bedeutet immer auch intensive Zusammenarbeit mit den Domänenexperten.

Die aktuell stattfindende Digitalisierung praktisch aller Domänen erfordert domänenspezifische, effektive Verfahren, Software schnell zu erstellen und wiederverwendbar weiterzuentwickeln. Zu viele Domänen sind heute noch getrieben von den dort üblichen Entwicklungsmethoden, die typischerweise in Konflikt zur Softwareentwicklungsmethodik stehen und daher in Projekten regelmäßig Friktionen produzieren. Dies gilt insbesondere für die klassischen Ingenieursdomänen wie Maschinenbau, Bauingenieurswesen oder Elektrotechnik. Solange die Maschine das dominante Element des Produkts ist, muss natürlich der Entwicklungsprozess entlang der Maschine und ihrer Komponenten definiert werden und daher typischerweise geometrische Dekomposition anbieten. Da aber immer mehr die Softwarefunktionalität ansteigt und die Software der Innovationstreiber wird, ist es sinnvoll, über eine Neuverhandlung der Entwicklungsprozesse nachzudenken, die eine funktionale Dekomposition entlang der Softwarefunktionalität stärker in den Fokus nehmen. Die heute üblichen Softwareentwicklungsmethoden, wie etwa das V‑Modell oder agile Methoden, sind jedoch auch nicht direkt auf andere Disziplinen übertragbar, obwohl die beobachtbare und durchaus berechtigte Hoffnung besteht, dass eine Generalisierung von Software-Engineering-Methoden für andere Domänen funktionieren dürfte. Es ist eine herausragende Aufgabe des Software Engineering in Kooperation mit den traditionellen Ingenieursdisziplinen, integrierte, ganzheitliche Entwicklungsmethoden und darauf aufbauende Werkzeuge zu entwickeln. Allerdings ist die Entwicklung eines Werkzeugs, das von Praktikern zur Anwendung genommen wird, heute keineswegs trivial. Explizite Werkzeugforschung ist notwendig, um den Bau industriell nutzbarer Werkzeuge überhaupt zu ermöglichen, denn moderne und damit oft auch intelligente Werkzeuge könnten die Softwareentwicklung weit jenseits des heutigen Standes unterstützen. Dies gilt allerdings nur, wenn solche Werkzeuge einerseits eine gewisse Reife besitzen und andererseits durch explizit offene Schnittstellen und Modularisierungstechniken Erweiterbarkeit sowie projektspezifische Anpassbarkeit ermöglichen. Das Systems Engineering und speziell der Einsatz von Modellierungs- und Simulationstechniken, speziell in der Qualitätssicherung, ist dabei eine wesentliche Herausforderungen, um die Zeit zur Marktreife sowie die Entwicklungskosten innovativ weiterentwickelter Produkte deutlich zu verkürzen. Dies ist gerade in Hochlohn-Ländern essenziell, um die Innovationsfähigkeit nicht zu verlieren.

Natürlich erhalten auch Daten, die immer mehr domänenspezifische Information in sich tragen, in der Funktionalität von Software eine immer größere Rolle. Bisher wurden Daten zwar als Gegenstand der Softwarefunktionen verarbeitet, sie haben aber nicht selbst wesentlich die Funktionalität bestimmt, wie das zunehmend in modernen datenintensiven Systemen der Fall sein wird. Das ändert sich nun durch Verfahren des maschinellen Lernens. Dadurch entfällt die Möglichkeit, die Software zur Entwicklungszeit vollumfänglich zu analysieren oder zu testen. Deshalb sind Verfahren zur Absicherung selbstlernender, hoch adaptiver Software notwendig, die klären, unter welchen Bedingungen Systeme noch zum Entwurfszeitpunkt analysierbar sind, Verfahren zur Laufzeitabsicherung und Verfahren zur A‑posteriori-Fehleranalyse. Darüber hinaus spielen Daten noch eine weitere Rolle als „first class entities“ bei der Modellierung von Privatheitsanforderungen und allgemeiner Zugriffsregelungen.

Die zunehmende Verfügbarkeit von Daten bietet auch für die Software-Engineering-Forschung eine große Chance, um Hypothesen empirisch zu prüfen. Allerdings birgt die beinahe beliebige Verfügbarkeit bestimmter Arten von Daten etwa aus Open Source Repositories und die sehr schwierige Erhebung anderer Datenarten etwa im Industrie 4.0-Kontext im Software Engineering auch Gefahren für den Forschungsprozess. Zu häufig werden Daten etwa aus Softwarerepositorien oder durch Umfragen generiert und publiziert, ohne diese durch eine Theorie, eine genaue Kontextdefinition oder eine Vision zu fundieren, wodurch der Nutzen dieser Arbeiten für die Disziplin des Software Engineering unklar bleibt. Mit Blick auf die Naturwissenschaften bringt der Philosoph Karl R. Popper mit seiner Aussage „Alle Erkenntnis ist theoriegetränkt, auch unsere Beobachtungen“ [8] zum Ausdruck, dass Experimente zur Erhebung von Daten gemäß einer zu prüfenden Hypothese aufgebaut sein sollen und diese Hypothese aus einer Theorie folgt. Eine Datenerhebung ohne zugrundeliegende Theorie mag zwar der initialen Phase eines Forschungsprozesses als explorative Studie durchaus berechtigt sein, um daraus Hypothesen abzuleiten. Diese sind dann aber durch weitere empirische Studien zu evaluieren. Dazu kommt, dass die Verfügbarkeit von vielen Open-Source-Repositorien den Blick darauf verstellt, dass Software nicht nur auf Code-Artefakten beruht.

Verlässlichkeit (Dependability), also der Grad, in dem darauf vertraut werden kann, dass ein System zugesicherte Leistungen erbringt bzw. zugesicherte Eigenschaften hat, gewinnt in Bezug auf Zuverlässigkeit, Security und Safety von Systemen eine immer größere Bedeutung. Gleichzeitig wird es aber für stark vernetzte, komplexe und autonome Systeme immer schwieriger, Verlässlichkeit und darüber hinaus Nachvollziehbarkeit und Erklärbarkeit von Systemen (etwa auf zur gesellschaftlich notwendigen Klärung von Haftungsfragen bei schädigendem Verhalten autonomer Systeme, was als Nachhaltigkeitsaspekt verstanden werden kann) sicherzustellen. Vielversprechende Ansätze, um dieses Problem zu adressieren, sind Abstraktionstechniken basierend auf Modellen, die helfen, die Komplexität, Vernetztheit, Autonomie und Nachvollziehbarkeit beherrschbar zu machen. Modellbasierte Ansätze sollen dabei sowohl generierende Modelle, beispielsweise für das modellbasierte Testen, als auch prädiktive Modelle, basierend auf maschinellem Lernen, integrieren. Diese Abstraktionstechniken sollten es dann ermöglichen, etwa relevante Eigenschaften des Verhaltens von High-Frequency-Trading-Techniken in der Finanzwirtschaft abzubilden, um das Zusammenwirken von mehreren dieser Algorithmen auf einem offenen Markt mit zugehörigen Analysetechniken zu untersuchen. Eine Herausforderung ist hierbei, wie man zum einen von den konkreten Details der Algorithmen soweit abstrahieren kann, dass Geschäftsgeheimnisse gewahrt werden und die Analyse noch skaliert, aber zum anderen noch aussagekräftige Analyseergebnisse gewonnen werden können, die ein Mensch die Ergebnisse noch nachvollziehen kann. Das Beispiel High-Frequency-Trading aus der Finanzwirtschaft zeigt auch nochmals die Rolle der Domäne.

Anwendungsdomänen entwickeln immer eine Eigendynamik und erfordern jeweils eigene Ausprägungen des Software Engineering und damit sinnvollerweise auch der Software-Engineering-Forschung.

Aus den bisherigen Betrachtungen ergeben sich viele konkrete Fragestellungen, welche die Software-Engineering-Forschung adressieren soll, um das Software Engineering und deren Forschung voranzubringen. Beispiele für konkrete Fragestellungen sind etwa:

Das Software Engineering ist keine Natur-, sondern eine Ingenieurswissenschaft mit starkem Fokus auf die vier Säulen aus Abb. 1:

Diese Säulen heben das Software Engineering von den traditionellen Ingenieurswissenschaften ab. Gerade wegen der am Entwicklungsprozess beteiligten Menschen treten anstelle von naturwissenschaftlichen Theorien oft Hypothesen, die sich aus Methodenvorschlägen ergeben und insbesondere auch menschliche und organisatorische Kontextfaktoren berücksichtigen. Diese Hypothesen über die Eigenschaften einer neu vorgeschlagenen Methode müssen dann empirisch geprüft werden, etwa durch kontrollierte Experimente oder Fallstudien. Um eine neu vorgeschlagene Methode im Software Engineering sinnvoll anwendbar zu machen und der empirischen Überprüfung zu unterziehen, ist es meistens notwendig, diese ganz oder teilweise in Werkzeugen zu implementieren. Nur so kann der Automatisierungsgrad der Methode, der durch ein Werkzeug ermöglicht wird, in Fallstudien eingebracht und empirisch validiert werden. Werkzeugbau ist daher eine notwendige und wichtige die Forschung begleitende Tätigkeit. Dass so zumindest auch Prototypen für Werkzeuge in der Softwareentwicklung entstehen, ist für die Industrialisierung neuer Software-Engineering-Methoden zumindest hilfreich und müsste auch politisch mehr unterstützt werden.

Es ist eine zentrale Aufgabe des Software Engineering, neue Visionen zu entwickeln und diese in Methoden und Werkzeuge zu gießen und begleitend deren Nützlichkeit, Effektivität und Effizienz empirisch zu evaluieren. Nur so ist es möglich, die tragende Rolle des Software Engineering für Wirtschaft und Gesellschaft im Zeitalter der Digitalisierung zu halten und weiter auszubauen. Gemäß der Aussage des Automobilfabrikanten Henry Fords „Wenn ich meine Kunden gefragt hätte, was sie wünschen, hätten sie gesagt: schnellere Pferde“, ist es notwendig, Visionen in praxistauglichen Methoden und Werkzeuge umzusetzen.

Dabei ist die Methodenweiterentwicklung gerade im Zusammenhang mit dem beschriebenen Wandel der Rolle des Software Engineering und ihrer stärkeren Verzahnung mit anderen Disziplinen (insbesondere dem Systems Engineering) außerordentlich spannend. War bisher die Entwicklung von Software ein Teilschritt im übergeordneten Systems Engineering, so wandelt sich dieses Verhältnis bei der enorm zunehmende Rolle von Software bei fast jeder technischen Innovation. Diese zunehmend zentrale Rolle der Software wird sich aus Sicht der Autoren auch in den Methoden zur Systementwicklung niederschlagen – diese werden softwarezentrierter. Gemäß dieser neuen Rolle von Software bei Innovationen wird das Produkt durch seine Software getrieben, die elektrischen oder mechanischen Komponenten sind entweder Commodity oder werden entwickelt entsprechend der Anforderungen aus der Software. Dies bietet eine einzigartige Chance für das Software Engineering, als wichtiger Treiber im Systems Engineering aufzutreten. Diese Chance kann man nur nutzen, wenn sich Software-Engineering-Forscher ihrer Rolle als Ingenieurswissenschaftler und Innovatoren bewusst sind, deren Forschung Visionen für neuen Methoden hervorbringt.