Ongeacht uw branche, een op maat gemaakte softwareoplossing tilt uw bedrijfsvoering naar een geheel nieuw niveau. Met name maatwerksoftware helpt u al uw activiteiten te integreren in één app waarmee u grip krijgt op uw bedrijf en de efficiëntie ervan kunt maximaliseren. Maar hoe worden maatwerksoftwareoplossingen precies gemaakt? In dit artikel geven we een overzicht van alle stappen die nodig zijn voor het ontwerpen, ontwikkelen en onderhouden van een maatwerksoftwareoplossing. Voordat we een nieuwe applicatie ontwikkelen of extra functies toevoegen aan een bestaande app, moeten we eerst een ontwerp en een prototype maken. Hieronder volgen de stappen waaruit de ontwerpfase bestaat:
Ontwerpverkenning
De ontwerpfase begint met een verkenningsproces. Het doel is om de reikwijdte en doelen van het project vast te stellen en een goede start te maken. Het ontwerpproces zelf bestaat uit verschillende stappen:
Kick-offvergadering
Het ontdekkingsproces begint met een kick-offvergadering van uw belangrijkste stakeholders en ons ontwerpteam. Omdat onze klanten zich in verschillende fasen van het proces bevinden, gebruiken we de bijeenkomst om terug te blikken op al het voorgaande werk aan het project en een routekaart te ontwikkelen voor het ontwerpen van de benodigde functionaliteit en functies van uw app.
Concurrentieanalyse
De volgende stap is het analyseren van uw concurrenten om te onderzoeken welke vergelijkbare apps er al bestaan en om de sterke punten en de zwakke of minder sterke punten te identificeren. De resultaten van de analyse geven je inzicht in hoe en op welke gebieden je je mogelijk kunt onderscheiden.
Gebruikerspersonaʼs
In de laatste stap van het ontwerpproces worden verschillende gebruikerspersonaʼs gecreëerd om inzicht te krijgen in de doelgroep van de app. De componenten van deze analyse zijn de motivaties van de gebruiker en wat zij met de app willen bereiken.
Technische ontdekking
De belangrijkste reden voor het uitvoeren van een technische ontdekking in de vroege stadia van softwareontwikkeling is om uw bestaande software (of onderzoek) te begrijpen en vast te leggen en de juiste stack voor het project voor te stellen. Deze stap omvat verschillende takenʼ, waaronder:
- Een gedetailleerde codebeoordeling van een bestaande app
- Onderzoek naar technologische oplossingen voor uw specifieke situatie
- Beoordeling van integratiedocumenten van derden
- Het opstellen van een implementatieplan
Gebruikerservaring
De procedure voor de gebruikerservaring houdt rekening met de behoeften van uw doelgroep en is erop gericht een gebruiksvriendelijke en eenvoudige app te creëren. Deze fase omvat het volgende:
Functiemapping
Ten eerste is een functiemap een overzicht op hoog niveau van de functies van een app. Het primaire doel is om een uitgangspunt te creëren voor het evalueren van mogelijke interacties tussen alle weergaven. Ook wordt de feature map gedurende het hele project bijgewerkt en onderhouden.
Gebruikersstroom
De volgende stap is het creëren van gebruikersstromen die alle acties weergeven die gebruikers uitvoeren om specifieke doelen te bereiken. Gebruikersstromen zijn cruciaal bij complexe, voorwaardelijke workflows. Ze stellen ontwikkelaars, ontwerpers en klanten in staat om dezelfde visie te ontwikkelen op de gewenste resultaten en de werking van de functionaliteiten. De laatste stap in de gebruikerservaring is het maken van wireframes van de belangrijkste weergaven van de app. Dit stelt ons in staat om een algemene indeling van uw scherm te ontwikkelen zonder dat we vooraf hoeven te bepalen welke afbeeldingen en tekst in het uiteindelijke ontwerp zullen worden opgenomen. Wireframes zijn nuttig voor verschillende doeleinden, zoals het waarborgen van een solide onderliggende structuur, het presenteren van gebruikersstromen, het begrijpen van de functionaliteit van het project en het snel maken van prototypes.
Gebruikersinterface
Na het voltooien van de ontdekkings- en gebruikerservaringfasen is de volgende stap het bouwen van een visueel ontwerp. De eerste stap hierbij is het selecteren van een stijlconcept. Zodra dat is gedaan, wordt het stijlconcept de stijlgids voor de toekomst. Hierna volgen de ontwikkeling van gedetailleerde mockups voor elk van de weergaven van de app.
Laten we de stappen in het ontwerp van de gebruikersinterface eens nader bekijken.
Stijlconcepten
Stijlgids
De volgende stap is het ontwikkelen van een stijlgids, gebaseerd op uw voorkeursstijlconcept. Deze gids documenteert alle standaarden voor de typografie, koptekststijlen, knoppen, lettertypen, kleuren en meer van de app. Het resultaat is een uniforme uitstraling in elk onderdeel van uw app, waarbij de stijlgids als referentie dient tijdens de ontwikkeling.
We hebben verschillende opties tot onze beschikking met betrekking tot de stijlgids. Ten eerste kunnen we uw bestaande stijlgids als uitgangspunt gebruiken, de bestaande stijlen consolideren en een nieuwe stijlgids helemaal opnieuw opbouwen. In de laatste fase van het ontwerp van de gebruikersinterface maken we high-fidelity mockups als visuele weergave van hoe de app eruit zal zien – gebaseerd op de wireframes en de stijlgids. Daarnaast bevatten deze mockups visuele elementen zoals iconen, illustraties en fotoʼs om zo nauwkeurig mogelijk weer te geven hoe de app eruit zal zien. Een essentieel onderdeel in deze fase is het tonen van je ontwerp aan de andere teamleden, zodat we waardevolle feedback kunnen verzamelen en eventuele noodzakelijke wijzigingen kunnen aanbrengen. Prototype en schatting. De volgende stap is het uploaden van de mockups naar Figma of Invision. We ontwikkelen vervolgens een klikbaar prototype dat we als uitgangspunt gebruiken voor het opstellen van uw ontwikkelingsraming. We gebruiken klikbare prototypes om interactie met het ontwerp van de app mogelijk te maken en te laten zien hoe uw app zal werken na ontwikkeling. Hiermee kunnen we de app testen voordat we hem daadwerkelijk bouwen en zien of er verbeteringen of uitzonderingen zijn die we mogelijk over het hoofd hebben gezien. Een ander voordeel van klikbare prototypes is de nauwkeurigheid van onze raming. De prototypes zijn uitstekende hulpmiddelen om goedkeuring te krijgen voor de ontwikkeling van de app of om de steun van een investeerder te verkrijgen. Dankzij onze klikbare prototypes en het diepgaande ontwerpproces is iedereen volledig betrokken bij het project en kan iedereen volgen wat we doen. Daarom zullen we een uitgebreide kostenraming opstellen met een gedetailleerde specificatie van de bouwtijd van de app en de bijbehorende kosten. Ons ontwerpproces is in zekere zin zo gestructureerd dat we een nauwkeurige inschatting kunnen maken van de ontwikkelingskosten van onze app.
Ontwikkelingsvoorstel
In deze fase gebruiken we het ontwikkelingsvoorstel om de kosten voor het bouwen van de app, het samenstellen van een ontwikkelingsteam en de planning te communiceren. Indien nodig kunnen we ook een strategie opnemen om de releases van de app gefaseerd uit te brengen, met een overzicht van de geschatte tijdlijn en de kosten voor elke release.
Samenvatting
Hier is een kort overzicht van de ontwerpfase voordat we verdergaan naar de volgende:
- Concurrentieanalyse
- Gebruikersprofielen
- Gebruikers-/functiekaart
- Wireframes
- Stijlconcepten
- High-fidelity mockups
- Klikbaar prototypes
- Ontwikkelingskostenraming en -voorstel
Het ontwikkelen van uw softwareoplossing op maat
We zullen onze aanpak schetsen voor het creëren van uw web-, Android- en iOS-apps. apps tijdens de ontwikkelingsfase. Dit zijn alle stappen die in de ontwikkelingsfase worden genomen:
Voorbereidende ontwikkelingsplannen
Ter voorbereiding op wat komen gaat, stellen we voorbereidende ontwikkelingsplannen op om een efficiënt ontwikkelingsproces te garanderen. De plannen omvatten:
- Het samenstellen van ons ontwikkelteam
- Het afronden van de overdracht van ontwerp naar ontwikkeling
- Het vaststellen van projectmijlpalen
- Het bouwen van user stories
- Het plannen van sprints
Het samenstellen van ons ontwikkelteam
Over het algemeen bestaat ons ontwikkelteam uit zes leden:
- Product owner
- Parttime ontwerper
- Parttime kwaliteitscontroleur
- Parttime projectmanager
- Twee fulltime senior ontwikkelaars
Voor ons team maken we meestal gebruik van een combinatie van professionals in onze kantoren in de VS en Colombia. Daar is een reden voor: we combineren het gemak en de kwaliteit van een team in eigen land met de kostenefficiëntie van een team in de buurt. Dit is zowel voor onze klanten als voor ons zeer goed uitgepakt.
Afronding van de overdracht van ontwerp naar ontwikkeling
Nadat ons ontwikkelteam is samengesteld, zullen ze samenkomen met het ontwerpteam voor de overdracht van ontwerp naar ontwikkeling. Dit zorgt ervoor dat onze ontwikkelaars begrijpen wat ze moeten doen en dat ze alles hebben wat ze daarvoor nodig hebben.
Tijdens deze fase beoordelen het ontwerp- en het ontwikkelteam alle resultaten die uit de ontwerpfase zijn voortgekomen. Dit omvat het doornemen van de volgende details:
- Gebruikerspersonaʼs
- Samenvatting marktonderzoek
- Gebruikersverhalen en stroomschema
- Stijlgids
- High-fidelity mockups
- Klikbare prototypes
Verder zullen de ontwerpers het ontwikkelteam voorzien van alle benodigde iconen en afbeeldingen in de juiste formaten. Ze zullen ook alle workflows, interacties en documenten overdragen die niet adequaat worden weergegeven in het klikbare prototype. Uiteindelijk hebben ontwikkelaars alles wat ze nodig hebben om efficiënt en zonder belemmeringen te beginnen met het bouwen van de app. Daarna stelt onze projectmanager alle belangrijke projectmijlpalen vast, intern ook wel versie-releases genoemd. Het is de bedoeling dat we verschillende versies van de app uitbrengen, die elk meer mogelijkheden bieden dan de vorige, maar niet zoveel nieuwe functies bevatten dat het voor de klant moeilijk wordt om ze te testen. Met andere woorden, we kunnen onze klant een aantal functies presenteren die we momenteel testen. De klant kan de functies bekijken en feedback geven die we zullen gebruiken om waar nodig aanpassingen te maken. Zoals je je kunt voorstellen, is dit misschien niet mogelijk als we maar één versie zouden uitbrengen.
Verhalen bouwen
De volgende stap voor onze projectmanager is het bouwen van verhalen voor de app. Deze verhalen dienen als tickets voor onze ontwikkelaars om te gebruiken in volgende sprints. Het doel is om de ontwikkelaars uit te leggen wat ze moeten bouwen en acceptatiecriteria op te nemen over hoe de functionaliteiten zouden moeten werken, ten behoeve van kwaliteitsborging.
Het bronmateriaal voor de verhalen bestaat uit regelitems en ontwerpen die in de initiële schatting zijn opgenomen. Elk verhaal moet binnen een specifiek aantal uren worden afgerond, wat direct verband houdt met de schatting.
Voor elke sprint krijgen ontwikkelaars meerdere taken toegewezen, waarbij het totale geschatte aantal uren gelijk is aan het totale aantal uren voor de sprint. Dit helpt de projectmanager de efficiëntie en effectiviteit van de ontwikkelaars voor elke sprint bij te houden.
Sprintplanning
Na het bouwen van de user stories assembleren we Deel ze in sprints van twee weken in en probeer er zoveel mogelijk in de beginfase van de ontwikkeling te organiseren. Sommige van de eerste sprints vereisen echter wat meer planning en nauwkeurigheid dan de sprints die later in het ontwikkelingsproces gepland staan. Zodra de user stories aan de sprints zijn toegevoegd, ontvangt elke ontwikkelaar een taak van de projectmanager. Deze taak is afhankelijk van de beschikbare uren in een sprint en het totale aantal uren dat voor elke user story wordt geschat. Actieve ontwikkeling begint zodra de pre-developmentplannen zijn opgesteld. Deze fase bestaat uit sprints van twee weken, retrospectieven na elke voltooide sprint en de lancering van versie-releases volgens projectmijlpalen.
Sprintuitvoering
Zoals beschreven, krijgen ontwikkelaars verschillende user stories toegewezen voor de sprints van twee weken. Onze projectmanager geeft de ontwikkelaars een specifiek aantal uren om de sprints uit te voeren. De user stories bevatten beschrijvingen van de bouwstenen en links naar componenten zoals acceptatiecriteria en iconen. Testdekking is belangrijk omdat het ontwikkelaars waarschuwt voor mogelijke fouten wanneer ze nieuwe code introduceren. Zonder testdekking zouden ontwikkelaars de applicatie handmatig moeten testen om te bepalen of de nieuwe code fouten in de bestaande code veroorzaakt. Handmatig testen is ineffectief, kostbaar en tijdrovend, en daarom onwenselijk. Hier zijn de soorten testen die onze ontwikkelaars gebruiken: Unit testen – We gebruiken unit testen om code te testen op het niveau van de afzonderlijke onderdelen van de app, het kleinste onderdeel dat getest kan worden. Het doel is om te controleren of elke software-eenheid naar behoren functioneert. Integratietesten – Hierbij worden unit tests gecombineerd om ze als geheel te testen. Het doel is om eventuele fouten in de interactie van de geïntegreerde eenheden op te sporen. Continue integratietesten – Deze ontwikkelingsmethode vereist dat onze ontwikkelaars meerdere keren per dag code toevoegen aan een gezamenlijke code repository. Hier verifiëren ontwikkelaars de code met een geautomatiseerde testsuite en een automatisch bouwproces in de repository.
Kwaliteitsborging
Nadat onze ontwikkelaars een user story en de bijbehorende tests hebben afgerond, beoordeelt ons kwaliteitsborgingsteam de story. Als deze voldoet aan de eisen, wordt de story goedgekeurd en naar onze projectmanager gestuurd voor verdere beoordeling. Als het verhaal op enigerlei wijze ontoereikend blijkt te zijn, moeten de ontwikkelaars het herzien. Ons kwaliteitsborgingsteam beoordeelt het verhaal aan de hand van een reeks factoren, zoals: Komt de gebruikersinterface van het verhaal overeen met het ontwerp? Voldoet de code van de app aan alle acceptatiecriteria die in het verhaal zijn vastgelegd? Werkt de code van de app correct op meerdere browsers en apparaten? Is het verhaal mobielvriendelijk? Codebeoordeling en goedkeuring /wp:heading -->
Op dit punt zal onze projectmanager de code van de app controleren op kwaliteit. Ze zullen de code en alle functies ook nog een keer testen. Als alles in orde is, zal de projectmanager de code samenvoegen met de master-branch om het verhaal af te ronden.
Alle code die we produceren moet aan een aantal standaarden voldoen. We beoordelen onze code op:
- Beknoptheid – Onze code moet begrijpelijk en overzichtelijk zijn. Minder code betekent namelijk meestal minder kans op bugs, minder complexiteit en eenvoudiger onderhoud. We houden onze code kort en bondig.
- Gebruiksvriendelijkheid – We zorgen ervoor dat iedereen onze code in begrijpelijke taal kan lezen. Daarom structureren we onze mappen volgens de hoogste standaarden van elk framework en elke gebruikte taal. Dit omvat het expliciet benoemen van parameters, variabelen, functies, methoden, klassen en bestandsnamen, rekening houdend met de intentie en context.
- Linting – Automatisering is een cruciaal onderdeel van programmeren, daarom voeren we code altijd uit met een geautomatiseerde linter.
- Zelfdocumentatie – Commentaar wordt gebruikt wanneer anderen problemen kunnen ondervinden bij het begrijpen van de code. Dit zou echter niet vaak moeten voorkomen. In de meeste gevallen zijn er tal van andere opties, zoals doordachte naamgeving, die gebruikt kunnen worden om de intentie en context van code te communiceren.
- Testdekking – Alle code moet vergezeld gaan van geautomatiseerde testsoftware die de tests moet doorstaan voordat je je branch samenvoegt met master. De beste werkwijzen omvatten unit-, integratie- en end-to-end-testen om een dekking van 95% te bereiken voor elke ontwikkeling.
Retrospectief
Aan het einde van elke sprint komt het team samen voor een sprintretrospectief, waarin ze de volgende details bespreken en vaststellen:
- Was de sprint op tijd afgerond?
- Zijn de user stories correct ingeschat?
- Zijn er onvoorziene uitdagingen of tegenslagen geweest?
- Ligt het project nog steeds op schema?
- Volgt het team het proces?
- correct?
De feedback die na elke sprint wordt ontvangen, geeft het team de nodige informatie voor de volgende sprint. Ons bedrijf houdt de sprintvoltooiing van elke ontwikkelaar bij om ervoor te zorgen dat ze consequent aan alle sprintvereisten voldoen. Mocht een ontwikkelaar de sprintdeadlines niet halen, dan zal onze projectmanager samen met hem of haar een verbeterplan opstellen. Vervolgens wordt het plan vergeleken met de verbetering in de volgende fasen.
Versie-releases
Na elke voltooide sprint hebben ontwikkelaars een versie-release met een klein aantal functies die de klant kan gebruiken voor gebruikersacceptatietesten. Op dit punt kan de klant de nieuwste versie testen en feedback of opmerkingen doorgeven aan de ontwikkelaars.
Lancering
Na verloop van tijd, naarmate we samen met de klant de ene na de andere versie uitbrengen, kan de klant Door elk onderdeel te accepteren, komen we op een punt waar de app klaar is voor bètatesten, gevolgd door een interne of openbare release van de app.
Onderhoud van uw maatwerksoftware
Na de release van uw applicatie kunt u ons bedrijf inschakelen voor doorlopende ondersteuning via een actieve ontwikkelingsovereenkomst of onderhoudsovereenkomst, of beide.
Onderhoudsovereenkomsten
Als uw applicatie beperkte geplande ontwikkeling in de toekomst heeft, hoeft u mogelijk slechts één keer een overeenkomst aan te gaan. Sluit een onderhoudscontract met ons af om ervoor te zorgen dat de app altijd operationeel is. Ons onderhoudscontract omvat:
Bugrapportage en foutmonitoring
We maken gebruik van een aantal programmaʼs van derden waarmee u bugs kunt rapporteren en eventuele fouten kunt monitoren. Deze omvatten de volgende tools:
- Bugsnag
- Sentry
- Eslint
- CodeClimate
Deze programmaʼs stellen ons op de hoogte van fouten en helpen ons de prestaties van uw app te optimaliseren.
Versies bijwerken
De open-sourcegemeenschap werkt open-sourcesoftware regelmatig bij, waarbij elke update een versie wordt genoemd. Voor optimale beveiliging en prestaties werken we uw app regelmatig bij.
Prestaties optimaliseren
Applicaties die veel data verwerken en veel gebruikers hebben, kunnen met name profiteren van prestatieoptimalisatie, die de volgende activiteiten omvat:
- Servers optimaliseren en monitoren
- Loadoptimalisatie en -testen
- Reactie op crashes en rapportage
Afhankelijkheden en updates Integraties
Moderne applicaties maken gebruik van diverse APIʼs en afhankelijkheden van derden, die constant kunnen worden bijgewerkt. Daarom is het cruciaal om uw applicaties regelmatig bij te werken om hiermee gelijke tred te houden.
Doorlopende ontwikkelingscontracten
Als u meer functionaliteiten aan uw applicatie wilt toevoegen en in de loop der tijd wijzigingen wilt aanbrengen, kunt u zich naast het onderhoudscontract aanmelden voor ons doorlopende ontwikkelingscontract. Dit is wat de doorlopende ontwikkelingsovereenkomst contentt:
Productroadmaps
Om u te helpen bij het plannen van uw budget en het prioriteren van functies, werkt ons team met u samen aan het ontwikkelen van een efficiënte productroadmap die de functies specificeert die uw app in de toekomst zal bevatten.
Het ontwerpen van nieuwe functies
Zodra uw nieuwe functies aan de productroadmap zijn toegevoegd, voert ons team een ontwerpproces uit om de nieuwe functies en hoe deze in de huidige versie van de applicatie passen.
Ontwikkelen van nieuwe functies
Na de voltooiing van het ontwerp zal ons team een tijdschatting maken voor de ontwikkeling van de nieuwe functies. Daarna worden de functionaliteiten opgenomen in onze sprints en beginnen we met het ontwikkelingsproces.
Speel op veilig – Kies voor maatwerk
Hoewel er veel bestaande softwareoplossingen zijn die mogelijk geschikt zijn voor uw bedrijfsidee, vallen ze allemaal in het niet bij de mogelijkheden van een softwareoplossing op maat. Om uw tevredenheid en de hoogste kwaliteit te garanderen, werkt ons team nauw samen met uw teamleden, verzamelt feedback en perfectioneert uw app om het best mogelijke product te leveren. Wanneer uw app klaar is, kunt u een verbetering van uw bedrijfsvoering en een hogere waardering van uw klanten verwachten.
