software ontwikkelingHet succes percentage van  een mobiele software ontwikkeling

Software ontwikkelingen halen vaak de deadline niet, gaan over het budget heen of falen compleet. Het goede nieuws is, mobiele software ontwikkelingen doen het een stuk beter. 69% van mobiele software ontwikkelingen zijn op tijd klaar, blijven binnen het budget en hebben een succesvolle uitkomst. Dat is veel meer in vergelijking met de 29% van niet-mobiele ontwikkelingen (Standish Group Chaos Database, 2015).

"Een software ontwikkeling die technisch haalbaar is, is geen garantie voor een succes in je markt. Het is wél een voorwaarde voor dit succes."

Het hoge percentage is voor een deel te danken aan de mobiele apps voor grote organisaties. Een app maken voor een organisatie kost vaak minder werk voor een app developer omdat er minder integratie met andere systemen nodig is. De app wordt dan gebouwd zodat hij goed samengaat met het IT systeem dat een organisatie al gebruikt. Dit zorgt voor minder kosten en een lagere tijdsinvestering omdat de haalbaarheid goed is in te schatten.

Het slechte nieuws is dat 26% van mobiele projecten bestaat uit apps die te laat geleverd zijn, over het budget zijn gegaan of geen succes hebben geboekt. Het gaat hier over succes op een technische manier. Een software ontwikkeling die technisch haalbaar is, is geen garantie voor een succes in de markt. Het is wél een voorwaarde voor dit succes. De overige 5% zijn apps die nooit gebruikt zijn of vroegtijdig gestopt zijn, voordat de applicatie ontwikkelaar er klaar mee was. Als jij je technische haalbaarheid onderzoekt, zorg je dat jij niet bij deze totale 31% hoort!

"Om de haalbaarheid van je app te weten, moet je onderzoek verrichten."

software ontwikkelingHoe zorg je voor een technisch haalbare software ontwikkeling?

Om de haalbaarheid van je software ontwikkeling te weten, moet je onderzoek verrichten. Idealiter laat je dit doen door een specialist die de technologische kant kent. De specialist moet ook jouw zakelijke- en gebruikersdoelen kennen, daarom moet je deze goed overbrengen. Hierbij is het belangrijk dat de specialist zich met de techniek bezighoudt en jij de doelen bepaald. Laat je dus niet in een bepaalde richting sturen door de specialist.

Als jij een specialist hebt gevonden dan moet je deze voorzien van een gedetailleerd plan met alle doelen, benodigdheden en functies van je app. De specialist gaat nu aan de slag met het onderzoek, bekijkt de opties en schrijft een advies. Neem hier de tijd voor, het kan je veel geld schelen in de toekomst!

Ook kan je zelf op onderzoek gaan. Bekijk hieronder de checklist van pijnpunten de haalbaarheid van je app.

software ontwikkeling10 Pijnpunten bij de haalbaarheid van je software ontwikkeling

De eisen van mobiele ontwikkelingen kunnen ontzettend variëren maar er zijn bepaalde punten die je voor elke app moet checken.
 

1 Ontwikkelplatform ☑

Wat is het geschikte ontwikkelplatform? Windows, Android of iOS? 
Het wereldwijd marktaandeel van Android is zo'n 88%, iOS 12% en Windows 0,3% (Bron: Business Wire / Strategy Anlytics ). Toch kan het handig zijn om bij een kleiner martaandeel te beginnen. Zo heeft iOS veel early adopters en wordt Windows veel gebruikt in de zakelijke markt. Leer vooral wat jóuw doelgroep het meest gebruikt. Het ontwikkelplatform kan een pijnpunt worden als je voor meerdere platformen kiest. Dat vergroot namelijk het werk en ieder platform heeft zijn eigen eigenaardigheden. Hou in dat geval rekening met meer kosten (voor ieder platform moet opnieuw ontwikkelt worden) en lees de voorwaarden van de Apple en Android App Stores.

2 Ontwikkeltaal ☑

Welke ontwikkeltaal kies je? 
Web gebaseerde- en native ontwikkeling hebben beiden hun voor- en nadelen. Web gebaseerd is goedkoper, native zorgt voor een betere gebruikerservaring. Elke taal heet voor- en nadelen. Schrijf hier onderaan een reactie en ontvang 'De Ontwikkelingsvergelijker', hier zie je alle technieken op een rijtje en de voor- en nadelen van iedere methode.

3 Technieken ☑

Kan je gebruik maken van al beschikbare technieken? Of moeten er nieuwe code geschreven worden? 
Het is mogelijk om het 'jasje' aan te trekken van eerder ontwikkelde apps. Je bouwt dan op de ervaring van eerdere apps. Als je bijvoorbeeld een tijdschrift app wilt maken, dan is het erg makkelijk om zo'n jasje aan te trekken. Wil je een game app maken? Dan zal er waarschijnlijk een nieuwe originele code moeten worden geschreven voor jouw app. Informeer naar reeds bestaande code bij ontwikkelaars die ervaring hebben met dezelfde soort apps en in jouw markt. Daar hebben we een handig blog over geschreven. Het is dus handig als er bestaande en vergelijkbare code is, anders is de investering in je app hoger.

4 Functies ☑

Welke functies zoals een camera of een map zijn er nodig? Wat is de beste manier van dit toepassen?
Bedenk welke functies moeten worden ingebouwd in je app. Waar ga je deze plaatsen en hoe moet de gebruiker deze toepassen? Blijf kernachtig en redeneer vanuit het belang van de gebruiker. Uitgangspunt is dat functies die je bedenkt die je nog (los) niet in andere apps ziet, een pijnpunt kunnen worden.

5 Gebruik ☑

Hoe zorg je ervoor dat je app zo min mogelijk batterij, geheugen of data gebruik kost?
Zet de functies van de app op een rij. Zitten er functies tussen die een grote belasting zijn voor geheugen, batterij of data? Kan dit veranderd of aangepast worden zodat het minder kost? Dat zorgt voor een betere gebruikerservaring en voorkomt klachten van gebruikers.

6 Integratie ☑

Moet de app geïntegreerd worden met een bestaand IT systeem?
Niet bij iedere app is er een integratie met een bestaand systeem of nieuw systeem nodig. Ga na welke informatie er in de app beschikbaar moet zijn en beperk dit zoveel mogelijk. Vaak hebben apps een zeer beperkte functie, waardoor er minder systeem integratie nodig is. Integraties met andere systemen zorgen voor complexiteit en daardoor voor meer kosten en een lagere technische haalbaarheid. Bespaar hierop door bijvoorbeeld in de eerste versie te testen zonder systeem integratie, daarmee maak je veel budget vrij.

7 App content ☑

Gaat er iemand je app content bijvullen of je app bijhouden? Welke toegang hebben zij dan nodig?
Het kan zo zijn dat derde partijen toegang nodig hebben tot jouw app. Als je bijvoorbeeld wilt dat de gebruiker zelf content kan toevoegen of als je iemand inschakeld om de app up to date te houden. Is er een systeem nodig om dit te verwezenlijken? Dit kan uiteraard, maar is een aparte functie en moet niet vergeten worden als je de app gaat beschrijven. Het wordt een pijnpunt als je achteraf erachter komt dat je de content van je app niet kunt aanpassen.

8 Taken uitbesteden ☑

Zijn er al vaardigheden tot je beschikking? Moet je hiervoor iemand in dienst nemen of verschillende taken uit besteden?
Je hoeft niet te kunnen programmeren of designen, maar zorg dat die twee specialisten wel in je team zitten. Zorg in ieder geval voor een toegewijde projectmanager of projectteam. Dat kun je zelf als je genoeg ervaring hebt. Is projectmanagement en ondernemerschap achter een softwareproduct nieuw voor je? Overweeg dan je te laten adviseren.

9 Onderhoud ☑

Hoe wordt het project onderhouden? Hoe worden bijvoorbeeld app problemen opgelost?
Blijft de ontwikkelaar werken aan jouw app? Zorgt deze dat alles op orde blijft of kan je dat zelf? Sluit een zogenaamde Service Level Agreement (SLA) met een ontwikkelaar af om afspraken vast te leggen over onderhoud en updates. Slechte of geen SLA's zorgen voor de meeste problemen, dus zorg dat je dit uitgebreid bespreekt met de software ontwikkelaar.

10 Toekomst ☑

Hoe ziet de toekomst eruit voor de app? Wat is het schema met betrekking tot updates?
Maak een planning voor de toekomst. Om een app relevant en actueel te houden zullen er updates moeten plaats vinden. Ook bij de keuze voor de ontwikkeltaal is het belangrijk om rekening te houden met toekomstige uitbreidingen. Nieuwe ontwikkelingen en technologieën integreer je het eenvoudigst in een app die native is ontwikkeld.

prijs

Het kostenplaatje

Als we het hebben over haalbaarheid, gaat het niet alleen over het technische aspect. Jouw app ontwikkeling moet ook financieel haalbaar zijn! Die haalbaarheid kun je ook controleren. Allereerst door in te schatten wat jouw app ongeveer gaat kosten. Pak even de lijst hierboven erbij: hoe ingewikkeld wordt jouw app? Hoeveel maatwerk is er nodig? Alles naast de minimale basis kost geld. En app ontwikkeling is niet bepaald goedkoop. Een gemiddelde app kost zo al gauw tussen de € 15.000 en € 30.000. En dan komen nog de terugkerende kosten van app hosting.

Dat is deel één van de financiële haalbaarheid. Want al kost jouw app slechts € 2.500 of wel € 200.000, zolang het maar betaald kan worden is je app financieel haalbaar. Ga maar na: heb je al een manier om jouw app te financieren? Zijn er geldschieters, heb je al een klantenbasis met vraag naar jouw app of een bedrijf die deze app echt nodig heeft? Dat geld hoeft er niet in één keer te zijn, want app ontwikkeling gebeurt gefaseerd. Maar wees in ieder geval voorbereid op het financiële aspect van de ontwikkeling van jouw app.

software ontwikkeling

Resultaat

Als al deze pijnpunten kunt afvinken, dan kan je de technische haalbaarheid voor je app inschatten. De punten die je niet kunt afvinken, bespreek je met een expert. Hetzelfde geldt voor het financiële gedeelte. Ook de Ontwikkelingsvergelijker PDF kan je een stuk verder helpen. Hiermee kan je de verschillende ontwikkelingen checken en de voor- en nadelen zien.

Vul hieronder je naam en emailadres in om de Ontwikkelingsvergelijker direct in je mail te ontvangen:

Ontwikkelaar om te vergelijken
Hoe wordt je app gemaakt?
Ontwikkelingsvergelijker als PDF
Kom erachter hoe je kosten bespaart én het meeste uit je idee haalt

Met de Ontwikkelingsvergelijker krijg je:

✔️ Welke technieken er zijn om apps te ontwikkelen

✔️ Zie in een overzicht de voor- en nadelen & kosten en baten

✔️ Kom erachter welke techniek past bij jouw app


Toegang tot de Ontwikkelingsvergelijker normaal €7 in de shop, nu GRATIS toegang:

-David van AppSpecialisten

Doel van jouw app
Fase van jouw app
Markten
Geschreven door
David van der Loo

Reacties

Ingediend door Danny op

Mijn grootste inzicht is om na te denken over de toekomst , met name welke nieuwe functionaliteiten en technologieën toegevoegd kunnen worden.

Ingediend door david@appar.nl op

Hoi Danny,

Fijn dat je dit inzicht hebt gehad. De ontwikkelingsvergelijker vind je in je mailbox!

-David

Ingediend door Appie op

Ik ben geholpen met de structuren die je aanreikt. Vanuit mijn functie houd ik me bezig met de inrichting van het Beheer van Apps voor de overheid. Hierbij heb ik te maken met alle facetten rondom Apps, van aanvraag tot uitfaseren.

Ga zo door!

Ingediend door Jan De Wit op

Ik lees niets over proprietary versus open source platforms. Hoe zit dat in app-ontwikkel land? Afhankelijkheid van een ontwikkelaar, schaalbaarheid, onderhoud en toekomst lijken mij belangrijke aspecten in telatie tot open source en proprietary.

Ingediend door david@appar.nl op

In reply to by Jan De Wit

Hoi Jan,

Bedankt voor je reactie. 

Het gebruikte platform om een app te ontwikkelen is inderdaad een interessant onderwerp. 

Ter inleiding: proprietary software voor de ontwikkeling van een app is de ontwikkeltool die door de app-ontwikkelaar zelf is gebouwd. Zo werkt deze ontwikkelaar binnen zijn eigen omgeving waardoor hij vaak meer maatwerk kan leveren. Dat voordeel ervaar je als klant ook, maar als je wil overstappen naar andere een ontwikkelaar zit je vast aan deze proprietary tool; deze is nieuw voor een andere ontwikkelaar en weet hij vaak geen raad mee.

Open source platformen* stellen je in staat om eenvoudiger van leverancier te wisselen. Meerdere ontwikkelaars kunnen deze softwre gebruiken ter ontwikkeling, waardoor een volgende leverancier 'verder kan waar de ander was gebleven'. Echter heeft open source software een nadeel: iedereen kan in de broncode kijken. Dat zorgde ervoor dat de Heartbleed bug (https://en.wikipedia.org/wiki/Heartbleed) zo grote impact kon hebben op de beveiliging van veel websites die open source beveiliging gebruikte.

Daarom is bijvoorbeeld het ontwikkelplatform van Service2Media (M2Active) gesloten. Banken gebruiken dit systeem en open source zou een te grote bedreiging zijn.

Stel je wil wel een proprietary systeem gebruiken van een ontwikkelaar, dan kun je natuurlijk vragen of hij het open source wil maken. Dat heeft Kabisa gedaan met haar ontwikkelplatform Maji Mobile (http://www.majimobile.com/).

Je afhankelijkheid van de leverancierzorgt ervoor dat je ook beperkt kan zijn in schaalbaarheid (wanneer voegen ze een nieuwe feature toe aan hun platform).  Zo heeft het systeem van Service2Media de beperking dat het nog geen vingerafdruk sensors ondersteund. Daarom heeft de app van Rabobank (op moment van schrijven) nog geen inlog met vingerafdruk. De ING app bijvoorbeeld wel.

Kortom: zowel een proprietary als een open source ontwikkelplatformen hebben voor- en nadelen. Zoals je aangeeft op basis van afhankelijkheid, schaalbaarheid, onderhoud en toekomst.

Jan, omdat je een reactie hebt achtergelaten stuur ik je de Ontwikkelingsvergelijker. Dat is een PDF met nog meer voor- en nadelen van ontwikkelmethoden.

*Hierbij maak ik voor het gemak geen onderscheid tussen systemen waar veel leveranciers mee aan de slag kunnen zoals de ontwikkelomgevingen van Android en iOs, Xamarin, PhoneGap

Ingediend door Jan De Wit op

In reply to by david@appar.nl

Beste David,

Dank voor je reactie en je mail.
Als groot fan van Open Source en Open Data, hier eerst een Open(bare) reactie in de hoop op een openbare discussie.

Ja, ik hoor het Heartbleed argument vaker.  De kern waar het daar om draait is hoe snel de developer en/of de community reageert op een dergelijk probleem. Als ik kijk naar grote Open Source systemen als Drupal, waar ik voornamelijk in ontwikkel, dan ben ik toch best tevreden met de adequaatheid van handelen. Ik vind dan ook de ontwikkelsnelheid en schaalbaarheid, onder voorwaarde van stabiliteit en reactietijd op calamiteiten, zwaar wegen.

Ik maag graag gebruik van je aanbod om van een vrijblijven gesprek en zal dan melden naar welke systemen ik zoal kijk.