Hugo Melis
|
Laatste update 31-01-2023
|
Nederlands
Allemaal leuk en aardig dat ontwerp van de app, maar nu komt het echte werk: de ontwikkeling. Bij deze fase komt veel expertise kijken en dit is niet iets wat ‘even gedaan’ kan worden. Het is belangrijk om goed stil te staan bij de uitvoering van deze fase, zodat deze zo soepel mogelijk verloopt.
Wanneer je denkt aan app ontwikkeling, verlies je jezelf mogelijk in je hoofd met alle software en programmeertalen. Maar, voor een goede ontwikkeling van je app, dien je ook andere taken uit te voeren dan alleen programmering. We hebben daarom verschillende onderwerpen uiteengezet die jou zullen helpen bij een goede ontwikkeling. Zo vertellen we je hoe je het beste jouw project kunt managen, verdiepen we ons nog eens in de technische kant van de app, lopen we door de versies waarin je app zich zal verkeren, en leggen we uit hoe je je app het beste kunt testen voordat deze wordt gelanceerd op de markt.
Dit is hoofdstuk 4 in de
Beginners handleiding voor App Ontwikkeling
Tijdens de ontwikkeling van een app is projectmanagement een belangrijk onderdeel van het proces (en nee, het probleem is niet uitstelgedrag). Daarom hebben we wat concrete tips voor je op een rijtje gezet, die zorgen voor een mega soepel verloop!
Er zijn verschillende methoden en technieken die je kunt toepassen op het gebied van projectmanagement. Daarnaast zijn er een aantal tools beschikbaar die gebaseerd zijn op één of meerdere van deze methoden. Overweeg de opties en kies de juiste methode en tool die aansluit bij jouw project. Een aantal van deze methoden en tools hebben we hieronder voor je op een rijtje gezet.
Methoden
Tools
Wanneer je naar apps kijkt lijkt het misschien simpel, maar if you take a closer look, zit er nog veel meer techniek achter (dan wat de gebruiker alleen ziet). Wanneer je hier als buitenstaander induikt, lijkt het misschien een ingewikkeld groot web van software. Dus, once and for all, laten we je zien en leggen we je uit hoe dit in elkaar zit.
Om te beginnen met ontleden, maken we alvast een splitsing tussen:
In figuur 4.1 is te zien hoe een app eruit ziet ‘behind the scenes’. Een app bestaat uit een front-end en een back-end. In principe is de front-end het deel van de app wat de gebruiker ziet. De back-end is het deel van de app wat de gebruiker niet ziet en wat ervoor zorgt dat de functionaliteiten van de app werken.
De front-end van een app wordt in programmeertaal geschreven op een IDE (ontwikkelomgeving). Zowel de IDE als de programmeertaal zijn afhankelijk van het besturingssysteem waarop de app beschikbaar wordt gesteld. De IDE van besturingssysteem IOS is xcode, met (meest voorkomende) bijbehorende programmeertaal SWIFT. De IDE van besturingssysteem Android is Android studio, met (meest voorkomende) bijbehorende programmeertalen Java of Kotlin.
De back-end van een app bestaat uit middleware (waaronder API’s), een database (met eventueel een gekoppeld CMS-systeem). Al deze software is gevestigd op een server.
De middleware zorgt voor de communicatie tussen verschillende softwaresystemen. Dit is eigenlijk dus de tussenkoppeling van de front-end en verschillende onderdelen van de back-end. Een van de onderdelen van middleware kan bijvoorbeeld zijn: API (Application Programming Interface). Een API transporteert en verwerkt data en zorgt dat deze op de juiste manier wordt weergegeven in de User Interface (UI) van de front-end.
De database is eigenlijk simpelweg de plek waar gegevens van de app worden opgeslagen. Hier kan een CMS-systeem aan worden gekoppeld, welke het makkelijk maakt om de app eenvoudig zelf te beheren en te bewerken.
De server is een hardware of software die diensten levert aan andere technologische apparaten. Deze maakt het eigenlijk mogelijk dat de overige taken van de back-end goed werken en goed kunnen worden uitgevoerd.
Wanneer het duidelijk is hoe een app in elkaar zit en wat voor software hierbij komen kijken, is de volgende stap: het kiezen van de software waarmee je gaat werken. De samenstelling van al deze software en technologieën vormt samen je tech stack. Zoals je misschien ook al hebt gelezen in hoofdstuk 3 (ontwerp), bestaat je tech stack bestaat uit:
In hoofdstuk 3 heb je namelijk al een aantal keuzes gemaakt, zoals besturingssystemen, platforms en API’s. Dan is het nu aan jou om de rest van je tech stack te kiezen, zodat je ontwikkeling voort kan zetten! Heb je deze eerdere stap overgeslagen? Lees dit dan even terug in hoofdstuk 3 (ontwerp & validatie).
Back-end
Je kunt ervoor kiezen om de back-end zelf te ontwikkelen of gebruik te maken van een (M)BaaS.
Back-end zelf ontwikkelen: Wanneer je kiest voor een eigen back-end, moet je de volledige back-end structuur zelf ontwikkelen en onderhouden. Dit is tijdrovend en een (min of meer) eenmalige flinke investering.
(M)BaaS: Wanneer je gebruik maakt van een (M)BaaS, wordt de back-end voor je ontwikkeld en onderhouden door een aanbieder van deze service (zoals Google Firebase). De kosten van een (M)BaaS worden bepaald aan de hand van het aantal gebruikers. Deze nemen dus toe wanneer jouw app meer gebruikers genereert.
Het is in veel gevallen verstandig om in eerste instantie gebruik te maken van een (M)BaaS om de investeringskosten te verminderen. Je kunt dan, wanneer jouw app als het waren heeft ‘bewezen’ dat er vraag naar is, ervoor kiezen om alsnog een eigen back-end te bouwen. Zo voorkom je dat de kosten hoger worden bij meer gebruikers. Dit is ook te zien in figuur 4.2.
Wanneer je je app gaat ontwikkelen zal deze niet uit het niks pats boom staan als een huis. Er zijn een aantal fases die je app zal doorlopen. Voor het gemak hebben we deze fases/versies waarin je app zich op een zeker moment zal verkeren, even weergegeven in figuur 4.3. Lees in onze blogs meer over wireframes, mock-ups, bèta build en production build.
De programmering van een app is nog best een opgave. Het is niet mogelijk om in een paar zinnen uit te leggen hoe je een app programmeert: daarvoor zul je minimaal een paar cursussen moeten hebben gedaan. Wél kunnen we je een paar relevante tips geven, waarmee je rekening kunt houden tijdens het programmeren van je app, namelijk:
Het is verstandig om je app op verschillende momenten in het proces te valideren/testen. Dit hebben we bijvoorbeeld ook al gezien in de design fase. Maar, waarom was dat ook alweer verstandig? Nou, bij deze:
Wanneer je je app test in de ontwikkelingsfase, ziet dit er net even iets anders uit als in de design fase, zoals je hebt gezien in hoofdstuk 3 (ontwerp). In principe zou je een onderscheid kunnen maken tussen twee soorten testen, namelijk: Technische testen (ondervinden van bugs) en gebruiksvriendelijkheid (usability).
Er zijn verschillende manieren om deze tests uit te voeren. Voor sommige soorten tests zijn gebruikers betrokken en voor sommige niet. Voorbeelden van soorten testen die je kunt uitvoeren zijn:
Technische testen
Gebruiksvriendelijkheid testen
Technische testen zijn voornamelijk bedoeld om issues te ondervinden voordat de gebruiker hiermee geconfronteerd wordt. In deze paragraaf lichten we verschillende methoden en tools toe die dit mogelijk maken.
Er zijn verschillende tools beschikbaar op de markt die automatisch bugs tracken. Er wordt dan vanuit een SDK wat code opgenomen jouw app. Deze code zorgt ervoor dat de tool in staat is om de app te monitoren en bugs te detecteren.
Het is als ontwikkelaar belangrijk om voor ogen te houden dat het (bijna) onmogelijk is om een score van 100% te krijgen. Al helemaal wanneer de gebruikersgroep groot en divers is. Daarnaast, houd er rekening mee dat bug tracking tools een enorme hoeveelheid aan data terugkoppelen, welke niet allemaal even relevant is. Stel daarom prioriteiten: Kijk waar gebruikers écht last van hebben en focus op IOS en Android toestellen.
Voorbeelden van tools zijn:
Er zijn inmiddels ontelbaar verschillende devices op de markt, en zoals eerder genoemd werkt je app op iedere device anders. Omdat de meeste mensen zelf geen geld, tijd (en zin) hebben om op iedere soort device hun app te installeren en handmatig te testen, zijn er een aantal aanbieders die deze dienst op zich hebben genomen. Op deze manier kun je je app op zoveel mogelijk verschillende smartphones en devices testen.
Hoe werkt dit?
Voorbeelden van aanbieders zijn:
Er zijn verschillende methoden om de gebruiksvriendelijkheid van je app te testen, zoals usability tests, pilot tests en beta tests. Deze helpen jouw om je app te optimaliseren voordat deze op de markt wordt gebracht.
Usability tests zijn bedoeld om de gebruiksvriendelijkheid van een app te testen (duhh, usability). Bij een usability test worden gebruikers gevraagd om bepaalde handelingen te verrichten bij het gebruiken van jouw app. Deze handelingen zijn vooraf opgesteld en aan de gebruikers geïnstrueerd. Tijdens het inzetten van usability tests kun je focussen op bepaalde specifieke onderwerpen, zoals het inlogproces, de navigatie door de app, of de duidelijkheid van iconen in de app. Gebruikers kunnen bijvoorbeeld worden gevraagd om in te loggen, of om een bepaalde pagina te zoeken.
Usability tests bestaan uit 3 onderdelen, namelijk:
De tests worden gemonitord door bijvoorbeeld een camera te richten op het scherm, of door de gebruikers na afloop een vragenlijst in te laten vullen. Deze informatie kan vervolgens worden geanalyseerd, waardoor conclusies kunnen worden getrokken en je app kan worden aangepast.
Tijdens een pilot wordt de app getest door een aantal gebruikers, om feedback te verzamelen en eventuele issues te ondervinden die gebruikers ervaren. In tegenstelling tot usability tests, zijn pilot tests meer gefocust op lange termijn. Zo maken gebruikers voor langere tijd gebruik van de app om issues te ondervinden.
Een pilotstudy bestaat uit de volgende stappen:
Bèta tests kunnen erg lijken op pilot tests. Tóch is dit net even iets anders. Bij een bèta test wordt je bèta app (de nagenoeg definitieve versie) beschikbaar gesteld voor een beperkt aantal gebruikers. App stores bieden de mogelijkheid om de app beschikbaar te stellen voor download, maar alleen voor personen die een exclusieve e-mail hebben ontvangen. In de App Store heet dit onderdeel Testflight.
Bij het inzetten van bèta tests worden gebruikers juist weinig geïnstrueerd, zodat zij vrij zijn om zoveel mogelijk feedback en problemen te noteren. Er wordt in de app stores onderscheid gemaakt tussen twee soorten testers:
Interne testers/alfatesters zijn voornamelijk direct betrokkenen en externe testers/bètatesters zijn overige gebruikers. Bij externe testers/bètatesters kan onderscheid worden gemaakt tussen verschillende subgroepen die een andere versie ontvangen van de app. De App Store hanteert een limiet van 25 voor interne testers en van 10.000 voor externe testers. Google Play Store heeft hier geen limiet voor, enkel de vereiste om te beschikken over een gmail adres.
Hugo Melis
App Strateeg @ Glamorous Goat (of, in gewoon Nederlands, ik ga met klanten in gesprek over hun app idee en kom met strategieën om er samen de beste app van te maken).
Deel Artikel
Artikel geschreven door
Hugo Melis
App Strateeg @ Glamorous Goat (of, in gewoon Nederlands, ik ga met klanten in gesprek over hun app idee en kom met strategieën om er samen de beste app van te maken).
Vind je dit goede content? Kom voor ons schrijven…