Inleiding

Het gebruik van mobiele apparaten, zowel zakelijk als privé, beleeft een enorme groei. In het laatste kwartaal van 2011 is het aantal gebruikers van tablets verdubbeld ([IGFK11]). Met de enorme groei aan potentiële gebruikers neemt ook het aantal applicaties dat op deze apparaten gebruikt kan worden toe: eind 2011 waren er al bijna 420.000 applicaties beschikbaar op de Google Market en bijna 460.000 applicaties in Apple app store ([Horn11]). Naast deze applicaties die publiek beschikbaar zijn in de verschillende app stores, wordt er ook een onbekend aantal in-house applicaties ontwikkeld voor gebruik binnen bedrijven. Met dit enorme aantal applicaties dat wordt ontwikkeld rijst de vraagt hoe een typisch ontwikkeltraject van mobiele applicaties wordt vormgegeven, op welke wijze dit traject verschilt van of overeenkomt met ‘traditionele’-softwareontwikkeling en welke keuzes er gemaakt dienen te worden tijdens de ontwikkeling van mobiele applicaties.

Mobiele apparaten worden tegenwoordig veelvuldig gebruikt voor taken die traditioneel op niet-mobiele apparaten werden uitgevoerd. Verschillende bronnen melden dat de personal computer zoals men die kende zal verdwijnen. De ontwikkeling van webbased software is een veelal bekend proces, maar hoe zit het proces voor de ontwikkeling van mobiele (web)applicaties in elkaar en in welke opzichten verschilt dit met het proces van de ontwikkeling van traditionele applicaties?

In dit artikel wordt een standaardontwikkeltraject van ‘traditionele’ software vergeleken met het ontwikkeltraject van mobiele applicaties, waarbij wordt verkend waar verschillen en overeenkomsten zichtbaar zijn. De aspecten die hierbij worden besproken zijn divers en beslaan het hele traject, maar niet uitputtend; hiervoor biedt één artikel niet voldoende ruimte. Dit artikel geeft echter een goed beeld van de verschillende stappen in het proces en benoemt welke keuzes gemaakt moeten worden in de businesscase, op het gebied van het technische platform, distributiestrategie en aanpak van beheer. Dit biedt handvatten voor het aangaan van een uitdagend traject van mobiele-softwareontwikkeling.

Ontwikkeling van (mobiele) applicaties

Voor het ontwikkelen van software worden verschillende methoden gebruikt. Een bekend traditioneel model is het Waterfall Model, maar tegenwoordig genieten agile methoden grote populariteit. Een agile ontwikkelmethode is een methodiek waarbij er in korte iteraties bruikbare delen van de uiteindelijke applicatie worden opgeleverd (een iteratie duurt vaak twee tot drie weken). De vraag is echter of de gekozen ontwikkelmethode van invloed is op een vergelijking tussen mobiele- en traditionele-softwareontwikkeling; deze invloed is vermoedelijk klein. De stappen die men onderscheidt in de ontwikkelmethoden zijn namelijk veelal vergelijkbaar, echter de volgorde van processtappen kan verschillen. Om een goed beeld te krijgen van de verschillen in ontwikkeling voor mobiele applicaties en (web)applicaties wordt er in dit artikel nadruk gelegd op de processtappen en niet op het proces zelf.

Figuur 1 toont de standaardprocesstappen die voorkomen in het complete softwareontwikkeltraject, waarbij de driedeling gemaakt kan worden tussen de businesscase, het daadwerkelijke ontwikkeltraject en de distributie van de software. In de volgende paragrafen wordt per onderdeel een verdere analyse gedaan.

Figuur 1. Stappen in een softwareontwikkeltraject.

Businesscase

Voordat een applicatie wordt ontwikkeld dient er een uitgewerkte businesscase te bestaan, hoewel dit in de praktijk vaak niet het geval is. Voor het ontwikkelen van een mobiele applicatie geldt hetzelfde principe: begin niet met een ontwikkeltraject voordat de waarde voor de business zichtbaar is. Door de eigenschappen van mobiele applicaties, zoals bijvoorbeeld de doelgroep, het toepassingsgebied en de mobiliteit, is het onwaarschijnlijk dat een bestaande businesscase in zijn geheel dupliceerbaar is.

Business goals, user goals en users

Centraal bij de ontwikkeling van software staat het doel van de applicatie: wat is het doel van de software in de context van de business, wat zijn de doelen van de gebruikers en wie zijn deze gebruikers. Hoewel een helder doel in de praktijk niet altijd gesteld wordt, is dit van groot belang voor de uiteindelijke acceptatie van nieuwe software binnen de doelgroep. Het ervaren gebruikersgemak samen met het ervaren nut vormt namelijk de attitude ten opzichte van het gebruik van nieuwe technologie. Dit belang werd reeds in 1989 al omvat in het Technology Acceptance Model ([Davi89]) en vormt een basis voor andere gedragsmodellen met betrekking tot de acceptatie van technologie. Wanneer er geen helder doel of voordeel is, dan zal het nut van de software minder duidelijk zijn en zal de software minder worden geaccepteerd. Dit geldt zowel voor mobiele als traditionele software, maar doordat de context van mobiele applicaties zeer specifiek is, zal het doel extra helder moeten zijn.

Figuur 2. Het Technology Acceptance Model ([Davi89]).

Tijdens het vormen van de businesscase moet er een algemene visie op het gehele softwareontwikkeltraject worden gevormd, omdat stappen in het proces van invloed zijn op de haalbaarheid van het traject. Hierbij moet onder meer in grote lijnen duidelijk worden welke keuzes op het gebied van ontwikkeling, distributie en doelgroep worden gemaakt. Door deze keuzes in de businesscase te omvatten kan antwoord gegeven worden op belangrijke vragen, zoals: bereik ik mijn doelgroep door de ontwikkeling voor dit platform? Welke platforms moeten ondersteund worden? Wordt de applicatie aangeboden in een app store?

Het vormen van deze visie is zowel voor de ontwikkeling van traditionele software als voor de ontwikkeling van mobiele applicaties van essentieel belang. Er zijn echter wel verschillen tussen mobiele en traditionele applicaties als het gaat om de keuzes die gemaakt worden om tot een visie te komen.

Ontwikkeltraject

Het ontwikkeltraject van software kan grofweg worden ingedeeld in de stappen ontwerp, ontwikkeling en testen. De volgorde en het aantal herhalingen van deze stappen zal per ontwikkelmethode verschillen en in de meer agile ontwikkelmethoden parallel doorlopen kunnen worden.

Ontwerp

Ontwerp is een breed begrip in softwareontwikkeling; het kan slaan op een groot aantal verschillende specialismen van ontwerp, zoals grafisch, interactie-, functioneel, architectuur- of technisch ontwerp. Al deze ‘soorten’ ontwerp zijn zichtbaar in zowel mobiele als traditionele software, maar zijn veelal verschillend in invulling.

Grafisch ontwerp

De vormgeving van traditionele applicaties is veelal divers. De vormgeving van mobiele applicaties is meestal meer uniform; vanuit de verschillende platformen, zoals Android of Apple iOS, zijn er standaard interactie-elementen en designrichtlijnen. In verschillende mobiele applicaties is hierdoor een vergelijkbare look and feel terug te zien. Dit heeft als voordeel dat gebruikers door herkenning snel de interface van een nieuwe applicatie leren kennen. De gebruiker van een mobiele applicatie verwacht ten opzichte van desktopapplicaties altijd dat een mobiele applicatie snel en eenvoudig te bedienen is. Om hieraan te voldoen is het van belang dat het ontwerp ook eenvoudig en overzichtelijk is. Het principe ‘Less is more’ is daardoor van een groter belang in mobiele applicaties dan bij desktopapplicaties.

Er is tevens een aantal technische aspecten die van invloed zijn op het grafisch ontwerp voor mobiele apparaten. Deze apparaten hebben bijvoorbeeld de mogelijkheid om te roteren. Dit zorgt ervoor dat er tijdens het grafisch ontwerp goed nagedacht dient te worden over de weergave in landscape en portrait modus en er eventueel verschillende ontwerpen gemaakt moeten worden. Daarnaast is er bijvoorbeeld een grote verscheidenheid in de pixeldichtheid (dpi) van een scherm van een mobiel apparaat, terwijl dit bij een desktopmonitor over het algemeen 72 dpi is. Het resultaat: een icoon ontworpen voor een oudere iPhone lijkt verkleind wanneer deze wordt weergegeven op een iPhone 4.

Gezien het belang van het grafische ontwerp in mobiele applicaties is het aan te raden om, in vergelijking met traditionele software, meer tijd in te ruimen voor het ontwerpen van de applicatie.

Functioneel en interactie

Door de eigenschappen van mobiele apparaten worden de mogelijke functionaliteiten en de interactiemogelijkheden beïnvloed. Het gebruik van mobiele software moet een doel hebben in de specifieke context, waardoor de functionele eisen veelal beperkter zijn dan in traditionele software. De bijkomende interactie binnen de functionaliteit zal aan moeten sluiten bij de interactie van het platform waarop de mobiele software wordt aangeboden, denk bijvoorbeeld aan het ‘swipen’ voor navigatiedoeleinden.

Het mobiele apparaat biedt ook andere interactievormen dan een normale desktop, zoals touch– of spraakbesturing. Daarnaast kan gebruik worden gemaakt van verschillende inputelementen, zoals de beweging van het apparaat, camerabeelden en gps-coördinaten. Met de komst van de nieuwe generatie smartphones is er voor de gebruiker een belangrijke beleving bij gekomen. Het apparaat integreert content van verschillende applicaties met elkaar. Voor de gebruiker is een Facebook- of Skype-contact net zo belangrijk als een adresboekcontact en de telefoon zal deze dan ook in één lijst laten zien. Op het moment dat een mobiele applicatie hiervan afwijkt zal dit door de gebruiker als storend worden ervaren.

De verschillende interactiemogelijkheden bieden de ontwerper een grotere keuze in het ontwerp. Om de eenvoud van een applicatie te garanderen dient een ontwerper een keus te maken welke interactiemethoden de beste oplossing zijn om het doel te bereiken. Een goede interactie en functioneel ontwerp is van groot belang voor het succes van een applicatie en het loont de moeite hier extra tijd in te investeren. De gebruiker heeft, ten opzichte van traditionele software, een hogere verwachting van de gebruiksvriendelijkheid en de interactie van mobiele applicaties.

Architectuur en technisch ontwerp

Zowel bij mobiele als traditionele applicaties kan de inrichting van de architectuur achter de software zeer verschillend zijn. Afgezien van de presentatielaag in de vorm van de applicatie, zijn de mogelijke oplossingen divers. Er zijn echter binnen mobiele applicaties in het technisch ontwerp wel beperkingen, want de applicatie moet op het platform van het mobiele apparaat draaien. Net als bij de ontwikkeling van traditionele software kan ervoor worden gekozen om een webbased applicatie te bouwen, maar hierdoor kan de functionaliteit van een applicatie echter beperkt worden. Op dit moment zijn er nog maar een paar belangrijke spelers op de mobiele markt. Apple met IOS, Google met Android, BlackBerry OS (verliest veel gebruikers aan IOS, Google en Windows) en Windows mobile (wint aan marktsegment maar blijft op dit moment nog ver achter bij de andere spelers).

Het is aan te raden om alvorens de applicatieontwikkeling start goed na te denken voor welke platformen minimaal ontwikkeld wordt. Houd hierbij rekening met de specifieke doelgroep van de mobiele applicatie en onderzoek welke platformen er door de doelgroep gebruikt worden. Deze keuze is van belang, omdat die invloed heeft op het hele ontwikkeltraject.

Ontwikkeling

Voor de ontwikkeling van de software dient er, op basis van de requirements die indirect volgen uit de businesscase, een keuze gemaakt te worden welk type software ontwikkeld wordt. De keuze voor de ontwikkeling van software uit één van de volgende categorieën is onder meer afhankelijk van de eisen en het doel van de applicatie. Bij de ontwikkeling van software kan hierin onderscheid gemaakt worden in drie hoofdcategorieën, namelijk stand-alone (ook wel dedicated), web en hybride applicaties. Elke categorie heeft haar eigen voordelen, nadelen en specificaties. In tabel 1 wordt een aantal voor- en nadelen van de verschillende categorieën uiteengezet.

Tabel 1. Een aantal voor- en nadelen van typen applicaties.[Klik hier voor een grotere afbeelding]

De keuze voor het type applicatie heeft grote invloed op het ontwikkeltraject en met name op de mogelijke ontwikkelmethoden. Bij een (mobiele) webapplicatie hoeft de ontwikkelaar geen rekening te houden met het platform waarop de applicatie komt te draaien, zolang de applicatie goed werkt via een browser. Maar let op: de verschillende browsers van de verschillende platformen kunnen de content wel verschillend weergeven. Wordt er echter een applicatie ontwikkeld waarbij een installatie op het apparaat vereist is, dan moet de software ontwikkeld worden in een programmeertaal die door het platform wordt ondersteund. Voor het ontwikkelproces begint, moet duidelijk zijn welke (versies van) platformen ondersteund moeten worden.

Voor de ontwikkeling van mobiele applicaties is het mogelijk interessant om gebruik te maken van frameworks waarin stand-alone applicaties ontwikkeld kunnen worden, zonder te ontwikkelen in de programmeertaal van het platform waarop de applicatie gaat draaien. Hiermee is het mogelijk om in één programmeertaal een applicatie te ontwikkelen, om deze vervolgens door het framework om te laten zetten (compileren) naar verschillende platformen, bijvoorbeeld iOS, BlackBerry, Windows en Android. De kwaliteit, mogelijkheden en prestaties van deze frameworks zijn echter zeer divers, dus onderzoek goed of een framework aansluit bij de eisen van de applicatie.

Test

Het testen van software is een belangrijk en essentieel onderdeel van het ontwikkeltraject. Dit geldt voor alle vormen van softwareontwikkeling. Het soort software (zie tabel 1) dat wordt ontwikkeld is van grote invloed op het testtraject, voornamelijk wanneer er gekozen wordt voor een applicatie waarbij een installatie op een apparaat nodig is.

Het aantal versies en het verloop van mobiele besturingssystemen is groot, de beeldschermresoluties variëren sterk en de hardware in de mobiele apparaten is zeer divers, waardoor er een groot aantal combinaties van hardware en software ontstaat. Dit maakt het complex om goede tests te ontwikkelen. Wanneer er gekozen wordt voor het ontwikkelen van een applicatie die binnen een browser functioneert, dan hoeft men alleen rekening te houden met de eigenschappen van de verschillende webbrowsers, waardoor het testen minder complex wordt.

Het is de moeite waard om te onderzoeken of het voordelig is om het uitvoerig testen van de applicatie uit te besteden. Wanneer het aantal apparaten dat u wilt ondersteunen divers is, dan is het in de praktijk niet eenvoudig om daadwerkelijk tests uit te voeren op de verschillende apparaten. Er zijn bedrijven die hierin gespecialiseerd zijn en het testen voor u uit kunnen voeren. Afhankelijk van de complexiteit van de applicatie en de diversiteit aan mobiele apparaten waarop de applicatie gebruikt gaat worden, kan dit kostenefficiënt zijn.

Aangezien het testen van software voor mobiele apparaten nog redelijk in de kinderschoenen staat is er een kleinere keus aan softwarematige testoplossingen. Van het geïntegreerd testen van de applicatie tijdens de ontwikkeling is nog nauwelijks sprake. Op dit moment zijn er frameworks die geïntegreerd kunnen worden in een mobiele applicatie zodat er inzicht ontstaat over het gebruik van de applicatie. Daarnaast zenden veel gebruikers zogenaamde debug-informatie door wanneer een applicatie vastloopt. Deze twee methoden geven veel inzicht in eventuele fouten in de mobiele software maar zijn afhankelijk van de interactie van de eindgebruiker en verlengen de testperiode aanzienlijk.

Verschillen in het testtraject tussen mobiele applicaties en traditionele applicaties worden voornamelijk veroorzaakt door de hardwarematige diversiteit van mobiele apparaten. Een groot deel van de testcomplexiteit vervalt wanneer er een mobiele webapplicatie (een webapp) wordt ontwikkeld die geen gebruik maakt van specifieke hardwarefuncties, maar alleen draait in de webbrowser van het mobiele apparaat. Hierdoor hoeft er alleen rekening gehouden te worden met de browsers, wat voor traditionele applicaties ook al het geval is.

Distributie

Na de ontwikkeling moet de software worden verspreid, aangeboden aan de doelgroep en moet er een mechanisme ontwikkeld worden om in beheer en onderhoud te voorzien. Bij de ontwikkeling van webapplicaties hoeft de applicatie niet los gedistribueerd te worden of bij de gebruiker geüpdatet te worden, omdat deze vanuit een browser kan worden geopend. Voor het distribueren van (dedicated en hybride) software zijn er verschillen tussen de distributie van desktopapplicaties en mobiele applicaties zichtbaar.

Het distribueren van desktopsoftware is zeer eenvoudig geworden, doordat het mogelijk is om software ter download aan te bieden aan de gebruiker via onlinewinkels of een website. Hierdoor is het gebruik van cd’s, dvd’s of andere media voor distributie in sterke mate afgenomen, maar er kan ook nog gekozen worden voor de distributie via fysieke winkels.

Bij de distributie van mobiele software moet er (bijna) altijd gebruik worden gemaakt van de online ‘winkel’ van de leverancier van het platform waarop de applicatie moet draaien. Hierbij moet rekening gehouden worden met de voorwaarden van deze leverancier, zoals controle op applicatiekwaliteit of provisies over verkoop van de applicatie. Er zijn verschillen tussen mobiele licenties van verschillende leveranciers, deze zijn in kaart gebracht in tabel 2.

Tabel 2. Verschillen tussen app stores van leveranciers.

* Apple biedt wel de mogelijkheid om via een coöperatielicentie een applicatie te verspreiden binnen een bedrijf. Hiervoor dient de licentie wel toegekend te worden aan een bedrijf waarbij een KvK-nummer tot de verplichtingen behoort.

** Apple werkt met jaarlicenties; afhankelijk van de gekozen licentie betaalt men $99 of $299 per jaar. Op het moment dat men zowel een applicatie wil verspreiden via de app store als via het eigen intranet dienen er twee licenties aangeschaft te worden.

*** BlackBerry vraagt per tien applicaties een ontwikkellicentie van $200.

**** Op het moment dat de verkoop boven de $25.000 stijgt wordt er 20% berekend.

Beheer

Het beheerproces van een applicatie is onder te verdelen in het technisch beheer, het functioneel beheer en het applicatiebeheer. De beheeromgeving van een mobiele webapplicatie zal niet verschillen van die van een normale webapplicatie. Op het moment dat de beheerorganisatie ingericht wordt voor hybride of stand-alone applicaties kunnen deze gebruikmaken van dezelfde processen, omdat het verschil zit in de technische oplossing.

Aangezien de kans groter is bij een mobiel apparaat dat dit vergeten of gestolen wordt, is het nog belangrijker om ervoor te zorgen dat de data van een apparaat en de applicaties beveiligd worden. Dit soort beheermaatregelen worden samengevat onder de noemer Mobile Device Management (MDM). MDM-oplossingen bieden over het algemeen de volgende beheermaatregelen:

• op afstand het mobiele apparaat blokkeren;
• op afstand kunnen leegmaken van het apparaat;
• uitvoeren van back-ups;
• traceren van het apparaat;
• afdwingen van extra beveiligingscertificaten;
• uitvoeren van software-updates.

Op dit moment zijn er tal van leveranciers die oplossingen aanbieden om MDM in te richten. Alvorens men begint met de ontwikkeling van een mobiele applicatie is het van belang goed stil te staan bij de vraag op welke wijze MDM ingericht dient te worden.

Een ander belangrijk aspect van de software lifecycle is de doorontwikkeling van de software. Pas na de distributie van de applicatie komen er vaak nieuwe wensen vanuit de gebruikers. Hierin ziet men geen verschil tussen de ontwikkeling van reguliere en mobiele software. Het verschil doet zich voor in de wijze waarop de gebruikers feedback geven. Doordat men gebruikmaakt van een mobiele telefoon is men eerder geneigd om zowel positieve als negatieve bevindingen van een mobiele applicatie direct te delen via verschillende social mediakanalen. Het is noodzakelijk om deze kanalen te gebruiken om een completer inzicht te krijgen in de wensen van de gebruikers.

Als er gekeken wordt naar de releasecycle van software dan is er een verschil zichtbaar in de doorlooptijd voor de ingebruikname van een nieuwe versie van de mobiele applicatie. De meeste gebruikers updaten niet gelijk wanneer er een nieuwe versie van de app geïnstalleerd wordt. Om het gedrag van de gebruikers positief te beïnvloeden kan er bijvoorbeeld nagedacht worden over het vanuit de app zelf aankondigen van nieuwe updates. Er dient van tevoren goed nagedacht te worden over hoe hiermee omgegaan wordt aangezien dit gevolgen kan hebben voor het ontwikkelproces.

Conclusie

In dit artikel is een standaard-softwareontwikkeltraject uiteengezet, waarbij is gekeken naar verschillen en overeenkomsten tussen het ontwikkelen van traditionele applicaties en mobiele applicaties. Hieruit blijkt dat de stappen die in het proces voorkomen vergelijkbaar zijn, maar dat er in de invulling van de stappen een aantal duidelijke verschillen zichtbaar is. Kernpunten hierin zijn onder meer:

• Door de eigenschappen van mobiele applicaties, zoals bijvoorbeeld de doelgroep, het toepassingsgebied en de mobiliteit, is het onwaarschijnlijk dat een bestaande businesscase in zijn geheel dupliceerbaar is. Onderzoek de mogelijkheden.
• De gebruiker van een mobiele applicatie verwacht ten opzichte van desktopapplicaties altijd dat een mobiele applicatie snel en eenvoudig te bedienen is. Om hieraan te voldoen is het van belang dat het ontwerp ook eenvoudig en overzichtelijk is: less is more!
• Het gebruik van mobiele software moet een doel hebben in de specifieke context, waardoor de functionele eisen veelal beperkter zijn dan in traditionele software. Door de eigenschappen van mobiele apparaten worden de mogelijke functionaliteiten en de interactiemogelijkheden beïnvloed.
• De keuze voor het type applicatie heeft grote invloed op het ontwikkeltraject en met name op de mogelijke ontwikkelmethoden.
• Voor de ontwikkeling van mobiele applicaties is het mogelijk interessant om gebruik te maken van een framework waarin dedicated stand-alone applicaties ontwikkeld kunnen worden, zonder te ontwikkelen in de programmeertaal van het platform waarop de applicatie gaat draaien.
• Het is de moeite waard om te onderzoeken of het voordelig is om het uitvoerig testen van een mobiele applicatie uit te besteden.
• Bij de distributie van mobiele software moet er vaak gebruik worden gemaakt van de online ‘winkel’ van de leverancier van het platform waarop de applicatie moet draaien. Houd rekening met de beperkingen en kosten.
• Besteed aandacht aan het inrichten van een Mobile Device Management-oplossing en de releasecycle.

Kortom: er zijn verschillen en aandachtspunten bij het ontwikkelen van mobiele applicaties, maar zij vormen leuke uitdagingen ten opzichte van het ontwikkeltraject van traditionele software, en bieden juist volop kansen.