23.02.2017 Der Einfluss von KI, IoT und Industrie 4.0

Software-Entwicklung wird mystisch

Von: Daniela Hoffmann

Die neuen Technologietrends Internet of Things (IoT), ­Industrie 4.0 und Künstliche Intelligenz (KI) beeinflussen die Software-Entwicklung massiv, sodass alte Paradigmen ins Wanken geraten.

Warum die Software-Entwicklung mystisch wird? Neue Technologien wie IoT, Industrie 4.0 und KI üben einen massiven Einfluss auf sie aus.

Wenn die Gesellschaft für Informatik ihre Tagung „Software-Engineering 2017“ mit „Ein neues Bild von Software“ übertitelt, spiegelt das eine Trendwende. Software-Systeme waren traditionell deterministisch ausgelegt: Man weiß also, was an Eingaben möglich ist und was an Output herauskommt. Durch neue Anwendungsbereiche wie Künstliche Intelligenz, Industrie 4.0 und Internet of Things ändern sich die Rahmenbedingungen für Software-Systeme, meint Prof. Peter Liggesmeyer, Präsident der Gesellschaft für Informatik (GI). „Ein typischer Weg beim maschinellen Lernen in der Bilderkennung besteht z. B. darin, die Systeme mit Lerndatensätzen zu trainieren und davon auszugehen, dass diese Systeme nach einer gewissen Zeit in der Lage sind, Situationen zu erkennen. Der Entwickler weiß aber nicht, wie gut genau diese Erkennung funktioniert – das widerspricht dem bisher geforderten Maß an Sicherheit“, erklärt Liggesmeyer. Gleichzeitig übernimmt Software zunehmend kritische Aufgaben – Beispiel autonomes Fahren.

„Wir haben eine dramatische Veränderung hin zu KI-Themen wie Deep Learning. Jetzt überlegen wir auf der Metaebene, wie wir ein System trainieren, und können die Algorithmen und das Systemverhalten im Detail gar nicht mehr nachvollziehen“, stellt auch Prof. Ayelt Komus von der Hochschule Koblenz fest. Das verändere alles, nicht zuletzt die juristische Seite. „Früher hat man sich wie bei einer Anlage, die erst nach der Zertifizierung von Eigenschaften angeschaltet wird, zum Entwicklungszeitpunkt um Themen wie Funktions- und Betriebssicherheit gekümmert. Bei Industrie 4.0 ist das nicht mehr sinnvoll“, erklärt Liggesmeyer. Die Herausforderung liege darin, mit den Unsicherheiten umzugehen, und das erfordere noch ein erhebliches Maß an Forschung.

Jedes Unternehmen muss heute ein Software-Unternehmen werden. Der Spruch von General-Electric-CIO Jeff Immelt ist bekannt, was heißt das aber eigentlich für die Betriebe? Am Beispiel Auto ist das gut sichtbar. Newcomer Tesla hat eine Strategie vorgemacht: Er verbaut günstige Sensorik, eine Grundlage dafür, dass später noch Software-Features hinzugeschaltet werden können. Die Autohersteller müssen jetzt außerdem zu Mobilitätsdienstleistern werden, rund um Navigation, Parkplatzsuche und Einkaufstipps.

VW betreibt in Berlin ein Digital Lab, das solche Mobilitätslösungen entwickelt. Ein bisschen Start-up-Atmo sollen die Räume in der Berliner Fernsehwerft an der Spree atmen, aber am Ende geht es doch ganz schön koordiniert zur Sache. Je ein Mitarbeiter von VW teilt sich den Rechner mit einem Pivotal-Mitarbeiter. Mit der „Extreme Pairing“ genannten agilen Methode, eine Form von Extreme Programming (XP), entwickeln sie gemeinsam Software – ein Ansatz, der die traditionelle Lücke zwischen IT und Fachabteilung überwindet. Bei der Eröffnungsveranstaltung des Labs im Herbst war jedoch deutlich zu spüren, dass man sich dafür rechtfertigen zu müssen meint, sozusagen zwei Leute für den gleichen Job zu bezahlen. VW-CIO Martin Hofmann versicherte jedoch, dass sich die Investition lohnt.

Doch was sind die typischen Probleme von Unternehmen, die mithilfe von Pivotal neue Herangehensweisen in der Software-Entwicklung ausprobieren? „Unternehmen wollen häufig, dass die Software-Entwicklung als Kernkompetenz der Organisation eingeschätzt wird. Wenn vorher aber Kostenstellendenken herrschte und die IT als Klotz am Bein gesehen wurde, dann ist ein beträchtlicher Kulturwandel nötig”, berichtet Dr. Stephan Hagemann, Director Pivotal Labs in München. Wie groß die Veränderungen in der Organisation sein müssen, werde dabei häufig unterschätzt. Das blase dann Sand ins Getriebe – z. B., wenn die neue Kultur auf schnellem Feedback basiert und man darauf bisher gar nicht eingerichtet war.

Die Organisation muss umlernen


Eine weitere Herausforderung: Wenn neue Formen der Software-Entwicklung genutzt werden, muss sich nicht nur die IT umstellen. „Stellt die Business-Organisation ihre Anfragen genauso wie vorher mit externen Partnern und Fixpreisen, dann ist das inkompatibel mit allen Formen agiler Entwicklung”, sagt Hagemann. Aus seiner Sicht ergibt sich häufig die Herausforderung zu priorisieren: Will ich lernen, Software selbst zu bauen, oder will ich eine produktgetriebene Veränderung meines Business erreichen? Wenn man beides zugleich angeht, sei bei Problemen schwieriger zu sagen, ob es daran liegt, dass man etwas Neues macht, oder daran, dass man es auf eine neue Art macht. Hagemanns Rat: Erste Projekte aus einem Bereich wählen, den man schon gut versteht, um daran zunächst die neuen Methoden und Werkzeuge zu erlernen.

Einer der wichtigsten Werte von Pivotal ist Kommunikation, daher das Arbeiten im Paar. Fast ebenso wichtig nimmt man die sogenannten Retrospektiven, wöchentliche Meetings, bei denen besprochen wird, was gut gelaufen ist und was nicht, immer konstruktiv mit dem sicheren Wissen, dass alle ein gutes Produkt abliefern wollen. „Der Wert der Kommunikation wird in einer Weise hochgehalten, dass das Team enger zusammenwächst und bereit ist, immer wieder nach Lösungen zu suchen“, erklärt Hagemann. In puncto Programmiertechniken wird Wert auf den iterativen Ansatz gelegt. Nichts ist am Anfang in Stein gemeißelt, es geht darum, in jedem Schritt mehr über das Produkt, das man baut, zu lernen. Ganz klar ist: Agile Methoden sind der Schlüssel, um Software rund um neue oder disruptive Geschäftsmodelle zu entwickeln.

Studie zeigt: Keine Ausreden mehr


Die aktuelle Studie „Status quo Agile“ der Hochschule Koblenz, scrum.org und der Gesellschaft für Projektmanagement, die im Februar (unter www.status-quo-agile.de) veröffentlicht wird, befragte über 1.000 Teilnehmer aus über 30 Ländern. Das Ergebnis: Agile Methoden zeigen sich auch in der dritten Studie zum Thema deutlich erfolgreicher als klassische Ansätze. Sie haben den „Sandkasten“ von kleinen, isolierten Pilotprojekten verlassen und sind zum Standard geworden, berichtet Ayelt Komus. Die Euphorie sei allerdings nicht mehr so extrem, das spreche für einen Gewöhnungseffekt. Die Untersuchung zeigt, dass rund zwei Drittel der Anwender agile Methoden selektiv oder hybrid einsetzen. Nur 20 Prozent bezeichnen sich demnach als durchgängig agil, nur zwölf Prozent der Studienteilnehmer nutzen weiterhin klassisches Projektmanagement. In der Umfrage ist praktisch niemand mehr der Ansicht, dass agiles Projektmanagement – ein altes Misstrauen – zu geringerer Qualität führen könnte. Über 90 Prozent halten diese Angst für unbegründet. Mehr als zwei Drittel der Befragten – darunter auch Anwender klassischer Methoden – sind der Meinung, dass agile Methoden die Effektivität erhöhen.

Mit 80 Prozent ist Scrum die mit großem Abstand am weitesten verbreitete Methode, gefolgt von IT-Kanban, das 60 Prozent einsetzen. 45 Prozent nutzen Lean-Methoden und immerhin 35 Prozent die in jüngster Zeit viel diskutierte Methode DevOps. Die meisten Anwender setzen auf agile Methoden, um ihre „Time to Market“ zu verbessern, an zweiter Stelle folgt der Wunsch nach besserer Qualität und an dritter Stelle die Reduzierung von Projektrisiken. Erst danach kommen weiche Faktoren wie der Wunsch, die Teammotivation oder Kreativität zu verbessern.

 

Kultur und Methoden im Wandel


Ganz nebenbei hat sich auch das Image der Software-Entwickler verändert. Nicht zuletzt dank der Start-up-Kultur, die mittlerweile große Konzerne wie Autohersteller oder Versicherungen nachzubilden versuchen, indem sie disruptive Ideen aus der starren Konzernstruktur ausgliedern, gilt Programmieren cooler als je zuvor. Kein Workspace ohne Kickertisch! Gefragt sind vor allem Teamplayer, Kreative und Querdenker. Das ist ein guter Moment für Quereinsteiger.

Denn zugleich bieten immer mehr Plattformen das Zusammenbauen von Anwendungen oder Apps auch für Menschen ohne tiefgehende Programmierkenntnisse an. „Es gibt eine ganz starke Tendenz in Richtung modellbasierter Software-Entwicklung, weg von klassischen Kodierungen in General-Purpose-Sprachen“, so Peter Liggesmeyer. So lasse sich Software partiell generieren, denn es sei nicht mehr nötig, alles das, was sich bereits jemand modellbasiert überlegt habe, noch zu kodieren.

Generell wurde das Verwenden fertiger Komponenten in der Entwicklung durch quelloffene Software weiter vorangetrieben. Open-Source-Lösungen spielen beim heutigen Software-Design eine wichtige Rolle. Gerade weil Unternehmen die quelloffenen Komponenten aber auch für eigene Entwicklungen oder in Produkt-Software nutzen, müssten sie sehr genau hinschauen, meint Liggesmeyer: „Open Source Software ist nicht freie Software. Sie unterliegt typischerweise einem Lizenzmodell, in dem  z. B. festgelegt sein kann, dass alle Veränderungen an der Quelle allen Usern zur Verfügung gestellt werden müssen.“ Das könnte mit dem Wunsch kollidieren, mit einer eigenen Lösung Geld zu verdienen. Böse Überraschungen lauern auch, wenn die eingesetzte quelloffene Software nach einigen Jahren nicht mehr weiterentwickelt wird.

Dies ist ein Artikel aus unserer Print-Ausgabe 01-02/2017. Bestellen Sie ein kostenfreies Probe-Abo.

Besonders relevant werden spätestens 2017 solche Entwicklungsplattformen, die es gestatten, Software über den Lebenszyklus hinweg zu entwickeln und Aspekte wie Sicherheit, Laufzeitverhalten oder Testphasen modellbasiert mit „abzuhaken“, prognostiziert der GI-Experte. Stichwort: Application Lifecycle Management. Das ist wichtig für Unternehmen, die Modelle aus dem Anfang der Software-Entwicklung auch in der Wartung weiterverwenden wollen. „Es gibt eine starke Tendenz zu Integration und Durchgängigkeit, singuläre Werkzeuge werden nach und nach verschwinden“, ist sich Peter Liggesmeyer sicher.


DevOps auf dem Vormarsch
DevOps steht für die engere Zusammenarbeit zwischen den getrennten Bereichen der Software-Entwicklung (Develop-ment = Dev) und des IT-Betriebs (Operations = Ops). Beide Bereiche haben teilweise widerstreitende Ziele: Während Dev gerne schnell neue Features für den Anwender im Unternehmen ausrollen will, hat Ops vor allem Interesse an der stabilen Lauffähigkeit einer Anwendung – dabei sorgen neue Features oft für Probleme. Gemeinsame Prozesse und Werkzeuge sollen dafür sorgen, dass die Abstimmung und das Testen besser und effizienter klappen.


Tipps aus der Qualifizierung
Vincent Stüger vom Beratungshaus ROI Management Consulting trainiert und quali-fiziert Manager und Entwickler zum Thema Software-Development. Das rät er seinen Teilnehmern:

  •   Bei den neuen Themen ist die Delivery komplexer geworden, die Verteilung  z. B. über App-Stores, Software as a Service oder Updates over the Air für eingebettete Systeme. Das erfordert andere Design-Prinzipien.
  •   Auch wenn Software ein „geistiges“ und damit flexibleres Produkt ist: Es sollte ein deutlich größerer Fokus auf das Produktmanagement gelegt werden. Was will der Markt, wie verändert er sich, wie kommt die Software zum Kunden, wie sieht es mit Wartung und Weiterentwicklung aus?
  •   Unternehmen müssen verstehen lernen, wie sich ihre Produkte mit Software ausdifferenzieren lassen. Verwendet man  z. B. Software, um im Industrie-4.0-Umfeld Produkte rascher zu entwickeln und bessere Anwendungsdaten zu sammeln?
  •   Es braucht ein durchgängiges Product Lifecycle Management für Software. Außerdem geht es für Entwickler stärker darum, das große Bild zu sehen, zu wissen, in welchem Gesamtkontext ihre Software läuft.
  •   Sicherheit wird noch wichtiger. Dabei muss nicht mehr nur an das Einzelgerät gedacht werden, sondern an den großen Zusammenhang, Stichwort Netzsicherheit.
  •   Das Verstehen dessen, was der Anwender wirklich braucht, wie er arbeitet, bleibt essentiell beim Software-Development. Und das funktioniert nur dort, wo Raum für den nötigen Austausch gegeben wird.


Bildquelle: Thinkstock/Top Photo Group

©2017 Alle Rechte bei MEDIENHAUS Verlag GmbH