Wenn Daten das Öl der digitalen Ökonomie sind, dann ist Software der Motor. Schön, stark und ausfallsicher soll er sein, und natürlich intuitiv zu bedienen. Kein Autofahrer würde einen Sportwagen kaufen, für dessen Bedienung er erst einmal ein 500-seitiges Handbuch wälzen muss. Bei Software, besonders den mobilen Apps, verhält es sich heute ganz genauso. Ohne Spass nichts los, könnte man sagen.

„Wir stehen heute in der Ära des akzeptanzgetriebenen Computings“, sagt Michael Sambeth von SAP. Will heissen: Applikationen, die vor den Augen der User keine Gnade finden, fallen durch. Der Anwender, sprich Kunde, hat viel stärkeren Einfluss auf die Software als noch vor Jahren. Und Software-Entwickler programmieren heute sehr eng am Kunden. Dadurch werden Fehlentwicklungen frühzeitig zusammen mit dem Kunden entlarvt und korrigiert.

Trotzdem gehen mehr als die Hälfte der komplexeren Software-Projekte schief. Sie kosten mehr als erwartet und dauern länger als geplant. Auch an der gewünschten Funktionalität müssen Kunden öfter als nötig Abstriche machen. Irgendetwas scheint da falsch zu laufen. com! professional hat deshalb Software-Häuser und Kunden gefragt, welche typischen Fehler den Zeitplan und das anvisierte Investitionsvolumen sprengen. Denn das Ziel von Business-Software-Anbietern und Kunden ist das gleiche: Intuitiv bedienbare, sichere Software, mit der man seine Aufgaben effizient und bestmöglich erledigen kann.

Kunden unterschätzten den Aufwand und die Komplexität der Software-Entwicklung, sagt Gert Brettlecker, Technologieverantwortlicher Enterprise Solutions bei Ergon Informatik. Die Apps in den mobilen Stores suggerierten zwar günstige Preise, aber hochwertige Business-Software gebe es nicht als Fast-Food, betont er.

Mit den Qualitätsansprüchen steigt auch der Aufwand. Kunden könnten durch ein sorgfältiges Requirements Engineering (Anforderungsmanagement) und Fokus auf das Wesentliche sehr viel Komplexität aus dem Projekt nehmen und dadurch Kosten reduzieren. "Lieber etwas weniger, aber das in guter Qualität" – diese Devise gelte nicht nur beim Essen, sondern auch im Software-Geschäft.

Kunden scheinen am Anfang noch nicht so genau zu wissen, was sie eigentlich wollen und packen dann sicherheitshalber alles Mögliche in den Anforderungskatalog, anstatt genauer nachzudenken. "Die Idealvorstellung, wir wüssten genau, wie ein Produkt später aussehen soll, gibt es in der Praxis fast nie", hat Kerry Lothrop beobachtet, der als Principal Consultant für Zühlke arbeitet. Ausnahmen seien allenfalls Software-Projekte im Flugzeugbau oder in der Automobilindustrie, aber im alltäglichen Projektgeschäft komme das sehr selten vor, meint Lothrop.

Software durchläuft den dreistufigen Entwicklungszyklus: Requirements Engineering, Entwicklung, Testing – und auch beim Testen unterlaufen typische Fehler. "Kunden implementieren und testen die Software in einer Umgebung, die nicht dieselbe ist wie die zukünftige Zielumgebung, in der das System später produktiv eingesetzt wird", erzählt Christian Gasser, Geschäftsbereichsleiter Architektur bei Elca. Dadurch würden viele Defekte zu spät entdeckt und die Fehlerbehebung verteuert sich unnötig.

Ein häufiges Defizit bestünde auch darin, Systemfehler – also Fehler in der Software – während der Produktionssetzung direkt manuell zu beheben, ohne dabei ein Änderungsprotokoll (Change Log) zu erstellen. Software-Entwicklung ist Teamarbeit und die Kollegen wissen dann nichts vom ausgebesserten Source Code. Mehr Sorgfalt bei der Vorbereitung und extrem genaues Arbeiten beim Testing, so könnte man die Ratschläge der Software-Häuser für ihre Kunden auf den Punkt bringen. Dann wird Software besser und sicherer.

Die gut gemeinten Ratschläge sind jedoch gar nicht so leicht in die Tat umzusetzen. Insbesondere mobile Applikationen müssen mit einer Vielzahl unterschiedlicher Betriebssysteme, Geräte und Versionen klarkommen. Hinzu kommen Zusatzfunktionen wie Fingerabdruckscanner, Kameras oder Push-Notifications. Das treibt die Testaufwände und -kosten in die Höhe.

Im Regelfall würden gar nicht alle Möglich­keiten komplett ausgetestet, verrät Johannes Bergsmann vom österreichischen Software Quality Lab. Ein höherer Testaufwand – bis zu 80 Prozent des gesamten Projektbudgets – würde dann getrieben, wenn Personenschäden auftreten könnten oder sogar Menschenleben auf dem Spiel stünden. Auch Kernbanken­systeme müssten, aus naheliegenden Gründen, einen aufwendigeren Testparcours absolvieren.

Generell seien alle Funktionalitäten, die nach aussen zum Kunden gingen, eher kritisch und die Tests fallen entsprechend intensiver aus. Bei nach innen gerichteten Funktionalitäten wie Berichten oder Reports lässt man anscheinend gerne mal fünf gerade sein, und die Firmenmitarbeiter leiden darunter. Denn "ob ein Bericht ein paar Sekunden länger oder kürzer dauert, das beschädigt das Image der Firma nicht", meint Bergsmann. "Die Standardtestverfahren decken nur etwa 10 bis 20 Prozent aller Use Cases ab, aber die typischen, die 95 Prozent aller Endanwender benutzen."

Da bleibt noch viel Raum für Fehler. Firmen stellen eine knallharte Kosten-Nutzen-Kalkulation an und überlegen sich, wie viel ihnen qualitativ hochwertige, intuitiv bedienbare und sichere Software wert ist. Manche Auftraggeber nehmen Fehlfunktionen, die in selteneren Use Cases auftauchen können, billigend in Kauf, weil ihnen sonst das Projekt zu teuer wird. Kostenüberlegungen beeinflussen nicht nur die Testqualität, sondern auch den Entwicklungsprozess.

Es gebe prinzipiell vier Ansätze, mobile Apps für unterschiedliche Geräte und Betriebssystemversionen zu ent­wickeln, sagt Zühlkes Kerry Lothrop. Der zeitaufwendigste und teuerste: Software-Architekten programmieren nativ, also in Objective-C/Swift für iOS, in C# für Windows Phone und in Java für Android. Die App muss also dreimal programmiert werden, nutzt aber die Eigenheiten der jeweiligen Plattform optimal aus.

Der zweite, preiswerte Ansatz, der mittlerweile aus der Mode kommt: Der User ruft die App über einen Browser auf, es handelt sich also eigentlich eher um eine mobile Webseite. Die dritte, elegante Option nutzt sogenannte Cross Compiler (zum Beispiel Xamarin): Programmierer entwickeln die Applikation in der Programmiersprache der einen Plattform und kompilieren sie danach (nativ) auf die anderen.

Der vierte ist der hybride Cross-Plattform-Ansatz, der sich ausschliesslich an Webstandards wie HTML, CSS und JavaScript bedient, die über ein Toolkit in einer nativen App dargestellt werden. Die App läuft dann auf allen Plattformen. Native Funktionen, die es nur auf Apple- oder Android-Geräten gibt, werden über nativ programmierte Plug-Ins eingebunden.

"Es gibt keinen klaren Gewinner, in der Regel erstellen wir eine Feature-Matrix und treffen dann unsere Entscheidung für oder gegen eine bestimmte Entwicklungsmethodik", sagt Bergsmann diplomatisch, gibt aber zu: "Soll die App auf allen Plattformen gleichzeitig laufen, dann führt der hybride Cross-Plattform-Ansatz mit räsonablem Kosten-Nutzen-Verhältnis am schnellsten zum Erfolg."

Sein Kollege Gert Brettlecker von Ergon Informatik vertritt allerdings eine andere Meinung. "Hybride Applikationen schienen die Zauberformel der letzten Jahre zu sein. Heute zeichnet sich jedoch ab, dass native Applikationen immer die beste User-Experience liefern und dass diese von den Smartphone-Besitzern auch immer erwartet wird." Laut Brettlecker ist das Teuerste – der native erste Ansatz – auch das Beste. Kurzum: Software-Qualität, zu der auch Performance und Skalierbarkeit gehören, hat eben ihren Preis.

Schon vor der Entwicklung und dann später beim Testaufwand werden also die Weichen gestellt, ob die Endanwender mit dem einen oder anderen Fehlerchen leben müssen oder aber sich auf tolle Software freuen dürfen.

Komplexere Software-Projekte, die häufig aus dem Ruder laufen, kranken aber noch an einem weiteren Defizit eher organisatorischer Provenienz. Viele Software-Firmen programmieren agil, laut der Studie "Software Development 2015" von SwissQ liegt der agile Anteil bei 41 Prozent. Dabei kommen Methoden wie Scrum zum Einsatz. Scrum sei aber eine Methodik für ein einziges Team und für die Koordination mehrerer agiler Teams, aus denen komplexe Projekte typischerweise bestehen, nicht so gut geeignet, sagt Sascha Czudek, Head of Agile bei SwissQ.

Zwar gebe es agile Vorgehensmodelle wie SAFe, LeSS oder DAD, die genau dieses Problem lösen. Diese Modelle sind aber noch jung und wenig erprobt. Firmen gehen daher die Koordination ihrer Teams individuell an. Die Software-Entwicklung, so scheint es, steckt selbst noch tief in der Entwicklung.