Kostentreiber bei der iOS-Entwicklung (Mobile Technology 2/2013)

www.mobiletechmag.de Österreich 9,00 € | Schweiz 15,80 sFr | Luxemburg 9,20 € Deutschland 7,80€Ausgabe 2/2013

Volume

11MOBILE TECHN

OLOGY 1.2013

iOS • Android • Window

s 8 • Automotive • Titanium

• Performance • Business

23. – 27. September 2013Expo 24. – 26. September 2013

Rheingoldhalle Mainz

.NET

WEB

WINDOWS

www.basta.net

Veranstalter:Präsentiert von:Media-Partner:

INETA Deutschland

Gold-Partner: Silber-Partner: Bronze-Partner:

Friends:Agile-Day-Partner:

Testing & Quality-Day-Partner:

bastacon bastacon bastacon bastacon

Kompendium

SPECIAL bis 25. April

Workshops For Free

+ 800 Euro sparen!

MTC, MWC, embedded world: Der mobile Frühling hat begonnen | Viele Fliegen, eine Klappe: Native Cross-Plattform-Apps mit Tabris | Non-native mal anders: Sencha Touch in der Praxis | Time for a REST: RESTful Services unter iOS ansprechen | Mission Possible: WP 8 und die Gunst der Endnutzer | Harte Fakten: Lumia 620, Z10 und BB10 im Test

Das Web erobert mobile BetriebssystemeDas Web erobert mobile Firefox OS

MOBILE- SPECIAL!BUSINESS-

MOBILE TECHN

OLOGY 2.2013

Firefox OS • Mobile Business • iOS • Android • W

indows 8 • BlackBerry • Titanium

Qu

elle

: Mo

zilla

©iStockphoto.com/ryccio

078 Business & Trends | iOS-Entwicklung

www.mobiletechmag.deMobile Technology 2 | 2013

Kostentreiber bei der iOS-Entwicklung

Out of Cash! Die Entwicklung einer App für ein iPhone oder iPad ist im Grunde ganz einfach: Man stellt die benö-tigten gra�schen Elemente im Interface Builder per Drag and Drop zusammen, programmiert die ge-wünschte Funktionalität dazu und bindet im Idealfall bereits bestehende Umsysteme oder Datenquel-len an, fertig ist der nächste Verkaufsschlager für den App Store. Leider müssen viele Projektteams die Erfahrung machen, dass es so einfach eben doch nicht geht, und am Ende der Entwicklung Auf-wand und Kosten weit höher sind als ursprünglich geplant.

von Reto Zenger

Anhand eines �ktiven Beispiels zeigen wir, welche Faktoren die Entwicklung verkomplizieren und somit verteuern können. Wir identi�zieren verschiedene Kos-tentreiber und beschreiben, wie man diese umgehen kann und so von ungeplanten Kosten bei der iOS-Ent-wicklung verschont bleibt.

Eine App für EurAirDie renommierte Fluggesellschaft EurAir will das beste-hende Angebot ausbauen und ihren Kunden eine iPhone-App zur Verfügung stellen. Diese soll das Suchen sowie Buchen und Verwalten von Flügen direkt auf dem iPhone möglich machen. Für die Umsetzung der App wurde aufgrund von mangelndem, internem Know-how ein ex-terner Partner gesucht. Erst letzte Woche haben wir nun den de�nitiven Zuschlag bekommen, zu zweit sollen wir in den nächsten Wochen die mobile Lösung entwickeln. Da die App noch vor den lukrativen Sommermonaten im App Store verfügbar sein soll, wurde vereinbart, mit der Umsetzung so rasch als möglich zu beginnen.

Der Scope und die Rahmenbedingungen des Projekts wurden wie folgt vereinbart: Die EurAir betreibt bereits einen Verkauf ihrer Flüge über ein Webportal. Kunden können sich dort ein Pro�l anlegen und damit Flüge

©iStockphoto.co

m/rycci

o

iOS-Entwicklung | Business & Trends 079

www.mobiletechmag.de 2 | 2013 Mobile Technology

buchen, bereits gebuchte Flüge anschauen oder gegebe-nenfalls umbuchen. Diese Funktionalität soll analog in einer App umgesetzt werden. Es wurde uns im Vorfeld versichert, dass alle benötigten Schnittstellen bereits vorhanden und vorbereitet sind, da sie vom Webportal seit einiger Zeit verwendet werden. Außerdem müssen wir uns nicht um Fragen betreffend Usability und die De�nition der User Interfaces kümmern, da EurAir da-für eine eigene Abteilung unterhält. Ausgenommen ist auch das Testing der App, dafür ist ein Standardprozess sowie geschultes Personal verfügbar. Somit umfasst das Projekt die Umsetzung der gewünschten User Interfaces, die Implementierung der Funktionalität des Buchens, Verwaltens und Umbuchens von Flügen analog dem Webportal sowie die Anbindung an die bestehenden Serverschnittstellen der EurAir.

Interaktion und DesignDie Designabteilung hat große Vorarbeit geleistet, und so stehen sowohl Wireframes wie auch Visual Designs für die komplette App bereits an unserem ersten Ar-beitstag zur Verfügung.

Das in den Wireframes angedachte Interaktionskon-zept der App ist ungewöhnlich für eine iOS-Lösung. Über ein Drop-down-Menü lassen sich verschiedene Funktionalitäten wie beispielsweise das Buchen von Flü-gen, das Verwalten der Buchungen, das persönliche Pro-�l oder News zu EurAir erreichen (Abb. 1). Das Menü lässt sich über einen Menü-Button in der rechten Ecke der UINavigationBar aufrufen und schiebt sich dann von oben nach unten über den aktuellen Inhalt.

Die Visual Designs für die einzelnen Screens sind de-tailliert ausgearbeitet und enthalten genaue Vermes-sungen aller Elemente (Abb. 2). Laut einer Notiz sind die Vermessungen exakt einzuhalten, da den Benut-zern so eine einheitliche und dem Corporate Design entsprechende visuelle Wahrnehmung geboten werden kann.

Wir beschließen, zuerst das Interaktionskonzept prototypisch umzusetzen und dann um die einzelnen Screens zu ergänzen. Erst später wollen wir die eigent-liche Funktionalität hinzu-fügen. Schon bald �nden wir uns jedoch in einer Dis-kussion über die Umsetzung des Interaktionskonzepts, insbesondere des Menüs wieder. Leider gibt es dazu keine Standardkomponente von Apple und so sind wir zu einer eigenen Implemen-tierung gezwungen. Doch welchen UIViewController soll man dafür verwenden? Der UINavigation Control-ler ist wohl am nahelie-gendsten, doch müsste man ihn für unsere Verwendung zweckentfremden. Beim An wählen eines Menü-punkts wäre man nämlich gezwungen, den kompletten Stack an UIViewControllern im UINavigationController auszuwechseln. Oder wollen wir doch lieber eine komplett eigene Implementierung ei-nes UIViewControllers verwenden? Wie auch immer wir das Interaktionskonzept umsetzen, der Aufwand und die Kosten dafür werden höher als notwendig und geplant.

Auch mit den Visual Designs sind wir nicht besonders glücklich, insbesondere die Umsetzung der eingetrage-nen Vermessungen wird einiges an Aufwand mit sich bringen. Die Designer haben dabei nämlich keinerlei Rücksicht auf Einrückungen und Formatierungen der Standard-GUI-Elemente, wie zum Beispiel einer UI-Table View Cell genommen. Eine genaue Umsetzung der Visual Designs hätte somit zur Folge, dass diverse GUI-Elemente von uns überschrieben und angepasst werden müssten.

Abb. 1: Drop-down-Menü

Abb. 2: Visual Designs

Kostentreiber ungeeignetes Interaktionskonzept

Ein ungeeignetes Interaktionskonzept treibt die Entwick-lungskosten in die Höhe. Kann man nicht Plattformstandard verwenden, so ist man zu meist aufwändigen Eigenimple-mentierungen gezwungen. Da das eigene Interaktionskon-zept den Benutzern jedoch wenig vertraut ist, besteht die Gefahr, dass es als nicht intuitiv wahrgenommen wird. Der zusätzliche Entwicklungsaufwand lohnt sich somit in vielen Fällen nicht. Konventionen und Standards der Plattform soll-ten nur umgangen werden, wenn man sie sehr gut kennt und sich bewusst und aus guten Gründen dagegen entscheidet.



Da diese Lösung für uns jedoch nicht befriedigend ist und außerdem den Aufwand unnötig vergrößert, beschließen wir, uns mit den Designern abzusprechen, um allenfalls Anpassungen vornehmen zu dürfen. Doch leider stoßen wir nicht auf große Resonanz, das Design-team ist bereits an seinem nächsten Projekt und kann keine Ressourcen mehr für die Erstellung der App ab-stellen.

Wir beschließen, uns mit den identi�zierten Proble-men an den Projektleiter zu wenden. In einem Gespräch wollen wir ihn darum bitten, ein Standardinteraktions-konzept prototypisch umsetzen zu dürfen und später mit ihm und den Designern zu diskutieren. Außerdem wollen wir ihn darum ersuchen, zusätzliche Designres-sourcen zu bewilligen. Gerne würden wir mit einem De-signer in agiler Vorgehensweise iterativ die erhaltenen Visual Designs optimieren. Durch das Aufzeigen der versteckten Aufwände und Kosten können wir den Pro-jektleiter von unserem Vorhaben überzeugen. In weni-gen Tagen erstellen wir den versprochenen Prototypen des Interaktionskonzepts (Abb. 3).

Unter Verwendung des UITabBarControllers haben wir mit vergleichsweise wenig Auf-wand eine Lösung bereit, die sowohl die Projektleitung als auch die Desi-gner zu überzeugen vermag und uns mehrere Tage Entwicklungsaufwand erspart. Die einzelnen Screens realisie-ren wir Stück für Stück, wo möglich gemäß den Visual Designs, wo nötig mit kleinen Anpassungen, um unnö-tige Aufwände zu vermeiden. Regel-mäßige Reviews mit den Designern und der Projektleitung stellen sicher, dass unsere Umsetzung den Vorstel-lungen entspricht und wir zusätzliche Aufwände nur dort investieren, wo es ausdrücklich gewünscht ist.

Technische AspekteNach einigen Tagen Entwicklung ist eine erste Version des visuellen

Grundgerüsts der App implementiert. Jegliche Funktiona-lität fehlt aber noch komplett und alle dargestellten Daten und Informationen sind statisch. So beginnen wir mit dem zweiten großen Arbeitspaket, der Anbindung der Umsys-teme. (Die komplette Trennung von Implementierung der visuellen Komponenten und Anbindung der Umsysteme ist in der Praxis wahrscheinlich nicht geeignet und dient hier der Strukturierung des Artikels.)

Ein Backend-Entwickler der EurAir soll uns dabei hel-fen. Er kennt die bestehenden Schnittstellen und kann uns allfällige Fragen dazu beantworten. Während einer ersten Einführung wird uns klar, dass die bestehenden Schnitt-stellen auf die heutige Weblösung zugeschnitten sind.

Als wir zusammen mit dem Backend-Entwickler ver-suchen, die verfügbaren Schnittstellen auf die Use Cases der App abzubilden, stellen wir fest, dass es eine relativ große Diskrepanz gibt. Wir sind gezwungen, in der App eine Zwischenschicht einzubauen, um die Serverschnitt-stelle verwenden zu können. Die Implementierung die-ser zusätzlichen Logik generiert Aufwand, der nicht vorgesehen und abgeschätzt war.

Der Backend-Entwickler ist nach kurzer Diskussion mit uns einverstanden, dass die Anpassung nicht in der App, sondern serverseitig geschehen soll. Er beantragt dies bei der Projektleitung. Kurze Zeit später wird für die Anpassung grünes Licht gegeben, die Schnittstellen werden in den kommenden Wochen zu feingranularen REST-Services umgebaut, die von beliebigen Clients be-nutzt werden können.

Da die Bereitstellung der neuen Schnittstellen einige Tage in Anspruch nehmen wird, beginnen wir mit der Implementierung des Log-ins und der Authenti�zie-rung. Die Kunden der EurAir sollen in der Lage sein, sich mit ihrem Pro�l anzumelden, damit sie Buchungen zu einem späteren Zeitpunkt anschauen und gegebenen-falls anpassen können. Auch hier sollen wir die bereits bestehende Infrastruktur anbinden. Die Weblösung im-plementiert die Authenti�zierung gegenüber dem Server mittels Cookie. Ein Log-in-Aufruf mit Benutzername und Passwort liefert ein Session-Cookie zurück, das für 30 Minuten gültig ist und bei allen weiteren Serverauf-rufen mitgeschickt werden soll. Bleibt die Webseite län-ger als die de�nierten 30 Minuten inaktiv und versucht danach Daten abzufragen oder an den Server zu schi-cken, erscheint eine Meldung, dass die Session abgelau-fen ist und der Benutzer wird automatisch zum Log-in umgeleitet.

Abb. 3: Prototyp des Interaktions-konzepts

Kostentreiber fehlende Zusammen- arbeit zwischen Designern und Entwicklern

Fehlt die Zusammenarbeit zwischen Designern und Ent-wicklern, so besteht die Gefahr, dass Designs umgesetzt werden müssen, die unnötigen Aufwand mit sich bringen. Einfachere und vielleicht auch bessere Lösungen können mangels technischem und plattformspezi�schem Know-how der Designer nicht berücksichtigt werden. Zudem ist die Pro-jektleitung nicht in der Lage, sich aufgrund einer Aufwand-Ertrag-Analyse zwischen verschiedenen Designvarianten zu entscheiden.

Kostentreiber unpassende Schnittstellen

Bieten Umsysteme Schnittstellen an, die nicht auf die Use Cases der App passen, so muss die App zusätzlich ange-passt werden. Es wird Logik benötigt, die die vorhandenen Daten auf die verfügbaren Schnittstellen abbildet. Dies führt bei der Entwicklung zu meist ungeplantem Aufwand.

8. Kongress für Zahlsysteme und Zahlungsprozesse

www.payment-kongress.de

14. und 15. Mai 2013 in Frankfurt am Main

Jetzt anmelden!

PAYMENT

AUSZUG AUS DEM PROGRAMM

Weitere Informationen zum Programm unter www.payment-kongress.de

Torsten Hubert

Head of Consulting, Web Arts AG

Oliver Behrens

Card Manager, ORLEN Deutschland GmbH

Dr. Andreas Schauer

Senior Product Marketing Manager Payment and Transit, Giesecke & Devrient

www.deutsche-kongress.de

V E R A N S T A L T E RKooperationspartner Wir beraten Sie gerne:

069 / 63006-900

» Mobile Payment und NFC-Payment

» Payment-Portfolios und Konversionsoptimierung

» Perspektiven für Multi-Channel-Strategien und Mobile Commerce

» SEPA-Ready bis 2014: Was ist zu tun?

Konversionsoptimierung – Psychologische Mechanismen von der Shop-Gestaltung bis zum Payment-Prozess

» Warum emotionale Resonanz die Grundlage für den Kauf bildet

» Psychologische Mechanismen und was wir für uns daraus lernen können

» Praxisbeispiele aus dem Persuasion-Toolkit

3 Jahre kontaktlos an star Tank-stellen – Erfahrungen und Perspektiven für das kontaktlose Bezahlen

» Übersicht über die generellen Kartenakzeptanzen an star Tankstellen

» MasterCard PayPass an über 500 Star Stationen: Erfahrungen aus 3 Jahren Praxis

» Wurden Erwartungen erfüllt – aus Sicht der Kunden und ORLEN

» Mobile: Perspektiven für Marke-ting und Payment via Smartphone

Sicherheit beim Mobilen Bezahlen

» Von der Geldbörse zum Mobile Wallet

» Sicherheitsanforderungen verschiedener Anwendungen

» Angriffsmöglichkeiten auf Mobil-telefone

» Betrachtungen zum Gesamt-system



Diese Lösung ist für eine iOS-App jedoch ungeeig-net. Einem Benutzer nach 30 Minuten Inaktivität ein erneutes Log-in anzuzeigen, ist aus Sicht der Benutzer-freundlichkeit einer App inakzeptabel. Ist man trotzdem gezwungen, die Authenti�zierung bei Serveraufrufen mittels Cookie zu implementieren, sollte zumindest das Ablaufen des Cookies und der danach nötige Log-in vor dem Benutzer verborgen werden. Wir erreichen das durch ein Abfangen von Serverantworten mit dem HTTP-Status-Code 401. Diesen verwendet der Server, um eine fehlgeschlagene Authenti�zierung beim Abfra-gen oder Senden von Daten zu melden. Erhalten wir in der App auf eine Anfrage eine solche Antwort, so führen wir vom Benutzer unbemerkt im Hintergrund mit zu Be-ginn abgespeichertem Benutzername und Passwort ein erneutes Log-in durch. Damit bekommen wir ein neues Session-Cookie und führen damit die ursprüngliche An-frage an den Server erneut durch (Abb. 4).

Diese Lösung ist jedoch höchstens temporär akzep-tabel, bis eine passendere Möglichkeit zur Authen-ti�zierung bei Serveraufrufen verfügbar ist. Negativ auswirken können sich dabei die zusätzlich benötigten Serveraufrufe. Um eine einfache Datenabfrage zu ma-chen, benötigen wir nun drei Aufrufe, wenn das Coo-kie abgelaufen ist (ursprüngliche Abfrage, Log-in im Hintergrund und erneut die ursprüngliche Abfrage). Im Falle einer schlechten Datenverbindung kann das zu un-nötig langen Warte- und Ladezeiten führen.

Die Benutzung des Session-Cookies als Authenti�zie-rungsmittel ist für eine iOS-App nicht empfehlenswert. Sie generiert zusätzlichen Aufwand bei der Implemen-tierung, da der Aspekt des abgelaufenen Cookies dem Benutzer verborgen bleiben soll. Außerdem führt sie dazu, dass bei einer schlechten Verbindung die App als langsam wahrgenommen wird, was die Gefahr der Ab-lehnung der App vergrößert.

Die von uns umgesetzte Adaption der Authenti�zierung des Session-Cookies ist zwar nicht optimal und technisch hässlich, wird aber von der Projektleitung für eine erste Version akzeptiert. Auf unser Drängen hin wird aber be-reits ein Change Request für die nächste Version der App verfasst. Dieser sieht eine Authenti�zierung mittels nicht ablaufender Token vor und macht dadurch das in einer App unnötige Behandeln von Sessions über�üssig.

RückwärtskompatibilitätDie App soll den Kunden der EurAir die Möglich-keit bieten, attraktive Angebote mittels einer Shar-ing-Funktionalität weiterzuempfehlen. Die EurAir verfolgt bei ihrem Onlineauftritt die Richtlinie, alle Benutzer mit jeglicher Hard- und Software möglichst optimal zu bedienen. Dieser Grundsatz gilt auch für uns und hat zur Folge, dass die App auf iOS-Betriebs-systemen bis zurück zu Version 4.0 einwandfrei laufen und alle Funktionen anbieten muss. Insbesondere bei der Shar ing-Funktionalität bringt das einen großen zusätzlichen Aufwand mit sich. Die systemweite In-tegration von Facebook (erst ab iOS 6 verfügbar) und Twitter (ab iOS 5) kann somit nicht oder nur teilweise genutzt werden, dasselbe gilt auch für die bekannte Sharing-Funktion, die den UIActivityViewController (ab iOS 6) voraussetzt. Uns bleibt die Entscheidung, entweder die neuen Frameworks dort zu verwenden, wo sie verfügbar sind, und für ältere iOS-Versionen einen Fallback zu programmieren oder als Alternative gleich vollständig auf die Frameworks zu verzichten. So oder so entsteht großer zusätzlicher Aufwand für die alternative Implementierung. Alleine im Falle von Twitter werden je nach Implementierung drei exter-ne Bibliotheken benötigt, die App muss bei Twitter registriert werden und das User Interface muss kom-plett selbst gebaut werden. Eine Integration von Face-

Abb. 4: Anfrage an den Server via Session-Cookie

Kostentreiber ungeeignete technische Lösungen

Ist man gezwungen, ungeeignete Lösungen aus anderen Technologie-Stacks auf iOS zu adaptieren, kann dies zu größerem Aufwand bei der Implementierung führen. Oftmals ist es nötig, zusätzliche Logik zur Einbindung der technolo-giefremden Lösung zu implementieren. Trotzdem führt das in vielen Fällen zu einer schlechteren Benutzerfreundlichkeit der App. Wo möglich sollte man sich einer Lösung bedie-nen, die auf die Plattform zugeschnitten ist.

iOS-Entwicklung | Business & Trends 083

www.mobiletechmag.de 2 | 2013 Mobile Technology

book ist nicht minder komplex, außerdem müssen zusätzliche Kanäle wie Mail oder Message separat an-gebunden werden. Dem gegenüber steht die Sharing-Funktionalität unter iOS 6. Deren Umsetzung für das Teilen von Inhalten über alle auf dem Gerät verfüg-baren und registrierten Kanälen benötigt gut ein Dut-zend Codezeilen.

Eine Intervention bei der Projektleitung bringt in die-sem Streitpunkt für uns jedoch keine Verbesserung. Die EurAir hält an ihrer Richtlinie fest. Immerhin gelingt es uns, die Projektleitung für das Thema zu sensibili-sieren und unsere zusätzlichen Aufwände aufzuzeigen. Wir beschließen gemeinsam, eine Bibliothek zur Mes-sung von Verwendungszahlen in die App zu integrie-ren. Anhand dieser Zahlen will die EurAir in Zukunft entscheiden können, ob sich die Unterstützung von älteren iOS-Versionen noch lohnt. Grundsätzlich lässt sich sagen, dass sich neue iOS-Versionen extrem schnell durchsetzen. Einen Monat nach dem Release war iOS 6 bereits auf über 60 Prozent der Geräte der Benutzer in-stalliert, die bestimmte populäre Webseiten in Nord-amerika besucht haben [1]. Ein manuelles Nachbauen eines neuen API für alte iOS-Versionen lohnt sich nur in ganz bestimmten Fällen, zum Beispiel wenn die Funktionalität für den Anbieter absolut zentral und unumgänglich ist. Wo immer möglich halten wir uns bezüglich Rückwärtskompatibilität an Matt Gemmell: Er emp�ehlt nur die jeweils letzte Version von iOS zu unterstützen [2].

TestingEinige Wochen später sind wir mit der Entwicklung der App bis auf wenige Details fertig. Wie zu Beginn vereinbart, wird nun parallel zur Fertigstellung die Testing-Abteilung involviert, um die Implementie-rung auf Herz und Nieren zu prüfen. Da jedoch die REST-Schnittstellen noch nicht komplett fertig und die Backend-Server aufgrund der laufenden Anpassungen temporär schlecht verfügbar sind, ist es den Testern beinahe unmöglich, das vorbereitete Testhandbuch ab-zuarbeiten. Regelmäßig erhalten wir Tickets aus dem Bug-Tracking-System, die keine Probleme in der App, sondern ausgefallene Server betreffen. Dadurch wird das Testing in die Länge gezogen und unsere Entwick-lung gebremst.

Nach einigen Tagen erhalten wir Rückmeldung über einen Bug, der den Grundablauf der App betrifft. Beim Zeichnen der Wireframes wurde ein Spezialfall ausge-lassen, der nun bei der Entwicklung nicht berücksich-tigt wurde. Die Nachentwicklung dieses Spezialfalls hat größere Umstellungen zur Folge, ein gesamter Use Case muss von Grund auf neu implementiert werden.

Um solche Probleme in Zukunft früher erkennen zu können, vereinbaren wir mit der Projektleitung und dem Testing-Team, bei zukünftigen Entwicklungen den Prozess anzupassen. Parallel zum nächtlichen Build aller Umsysteme soll auch die App auf der Continuous-In-tegration-(CI-)Infrastruktur gebaut werden. Tools wie beispielsweise Test�ight [3] ermöglichen das automati-sierte und von der CI initiierte Versenden der App an ausgewählte Tester. Somit ist es möglich, dass fortlau-fend der neueste Stand der App getestet wird und Prob-leme so früh als möglich detektiert werden.

Wenige Tage vor dem Einreichen der App bei Apple zeigt uns der Projektleiter in einem Meeting die eingefro-rene App. Er hat sie auf dem Arbeitsweg im Zug auspro-biert und in einem Tunnel plötzlich seltsames Verhalten entdeckt. Wenig später ist die App komplett eingefroren. Die Analyse des Problems bringt rasch die Ursache ans Licht: Ein kleiner Fehler bei der Behandlung von verlore-ner Netzverbindung hat die App in einen ungewünschten Zustand versetzt, der dann in einem kompletten Einfrie-ren des Bildschirms gegipfelt hat. Überrascht stellen wir fest, dass trotz beinahe abgeschlossener Testphase nie-mand diesen grundlegenden Fehler gefunden hat.

Kostentreiber Rückwärtskom- patibilität

Sobald ältere Versionen von iOS komplett unterstützt wer-den müssen, fallen für verschiedene Funktionen zusätzliche Aufwände an. Ein neueres API kann nicht verwendet oder muss manuell nachgebaut werden. Im schlimmsten Fall müssen für verschiedene iOS-Versionen unterschiedliche Codepfade implementiert und unterhalten werden.

Kostentreiber Testsysteme

Stehen keine für die App dedizierten Testserver zur Verfügung, erschwert sich das Testing, was den Aufwand für Testing und Bug�xing erhöht.

Kostentreiber Entwicklung nach Wasserfallmodell

Wenn nach Wasserfallmodell erst ganz zum Schluss des Projekts getestet wird, bleiben Fehler möglicherweise lange unbemerkt. Betreffen diese Fehler die Grundfunktionalität, ist der Aufwand einer Behebung unnötig hoch.

Kostentreiber Testing am Arbeitsplatz

Eine mobile App sollte auch mobil getestet werden. Wird die App nicht unter realistischen Bedingungen, wie wechselnder Netzabdeckung, schwacher oder fehlender Verbindung oder auch Roaming getestet, werden Fehler erst kurz vor der Liveschaltung entdeckt. Je später ein Fehler gefunden wird, desto aufwändiger ist dessen Behebung.



WartungTrotz dem nicht optimalen Testverfahren konnte die Testing- und Bug�xing-Phase nach kurzer Zeit erfolg-reich abgeschlossen werden. Auch die neuen Schnittstel-len konnten wir problemlos integrieren und die fertige App wenige Wochen vor dem Start der für EurAir wich-tigen Saison bei Apple zum Review einreichen.

Beim Abschlussmeeting zeigt sich die Projektleitung froh, dass die App jetzt fertig entwickelt ist und kein weiterer Aufwand mehr auf die EurAir zukommt. Doch da widersprechen wir vehement: Wird eine iOS-App nicht gewartet, verliert sie schnell an Attraktivität. Be-reits nach einem Jahr wirkt eine nicht gewartete App veraltet und nach zwei Jahren erinnert sie mehr an das verstaubte Hochzeitsfoto von Onkel Gerhard als an eine dem aktuellen Stand der Technik entsprechende App. Anhand von Beispielen versuchen wir deshalb aufzuzei-gen, wie rasch sich die iOS-Plattform weiterentwickelt, und argumentieren, dass eine App diese Entwicklung mitmachen muss. Neue Frameworks und visuelle Ele-mente von neuen iOS-Versionen müssen evaluiert und falls passend integriert werden, ansonsten werden die Benutzer möglicherweise ein Konkurrenzprodukt vor-ziehen.

Wir können die Projektleitung schlussendlich über-zeugen, ein jährliches Wartungsbudget in der Höhe von 15 Prozent des Projektbudgets zu beantragen. Damit ist es möglich, die App aktuell und am Puls der Zeit zu halten.

FazitViele iOS-Entwicklungen resultieren in höheren Kos-ten als ursprünglich geplant. Anhand des Beispiels der EurAir haben wir aufgezeigt, welche Faktoren dafür verantwortlich sein können. Viele aufgezeigte Kos-tentreiber hängen mit Besonderheiten der mobilen Plattform und im Speziellen mit iOS zusammen. Um zusätzliche Aufwände zu umgehen, ist es wichtig, dass auch Designer, Projektleitung und Tester von diesen Ei-genheiten wissen, beziehungsweise sie sogar detailliert kennen. Noch besser ist es, wenn die Zusammenarbeit mit den iOS-Entwicklern eng gestaltet wird und im Ide-alfall auf agile Art statt�ndet. Speziell wenn Designer, Projektleitung und Tester keine große Erfahrung mit iOS-Projekten haben oder wenig fundiertes Wissen über die Besonderheiten der Plattform mit sich bringen, kann das plattformspezi�sche und dringend benötigte Wissen der Entwickler auf diese Weise während der gesamten Dauer des Projekts eingesetzt werden.

Ein iOS-Projekt unterscheidet sich doch in einigen Be-reichen von anderen Entwicklungsprojekten und kann nur erfolgreich und im Rahmen des Budgets durchge-führt werden, wenn diesen Unterschieden Rechnung getragen wird.

Reto Zenger ist Software Engineer bei Zühlke Engineering. Er hat an der Universität Zürich Wirtschaftsinformatik studiert und arbei-tet seither in Projekten mit den Schwerpunkten Java, Webtechno-logie und native iPhone-Entwicklung.

Links & Literatur

[1] http://chitika.com/insights/2012/ios-6-adoption-one-month

[2] http://mattgemmell.com/2011/12/05/latest-version

[3] https://test�ightapp.com

Kostentreiber Wartung

Die Wartung einer iOS-App wird oft unterschätzt. Da sich die Plattform sehr schnell entwickelt, sollte eine App regelmäßig gewartet und an die neuesten Frameworks angepasst werden. Auch kümmert sich Apple nicht um Legacy-Software. Es scheint im Gegenteil das Ziel zu sein, Entwickler zu möglichst raschen Updates auf die neueste Technologie zu bewegen. Ein �xes Budget für Wartung muss also von vorneweg einberechnet werden. Ansonsten besteht die Gefahr, dass Anpassungen im Zuge von zukünftigen Change Requests oder Bug�xes gemacht werden müssen, was dann wiederum zu Budgetengpässen führen wird.

Viele iOS-Entwicklungen resultieren in höheren Kosten als ursprünglich geplant. Viele der hier aufgezeigten Kostentreiber hängen im Speziellen mit iOS zusammen.

Immer und überall

MobileTechMag

Immer und überall

Kostentreiber bei der iOS-Entwicklung (Mobile Technology 2/2013)

Technology

Transcript of Kostentreiber bei der iOS-Entwicklung (Mobile Technology 2/2013)