Kwaliteit
Om een project een succes te maken, hanteren wij een gestructureerde methode voor projectmanagement en softwareontwikkeling, waarbij wij nadrukkelijk rekening houden met de kwaliteit van het project.
Zo helpt de projectmanagement methode ons om elk project snel, goed en effectief uit te voeren en waarborgt het ontwikkelhandboek de kwaliteit van de software.
Met deze twee kwaliteitshandleidingen garanderen wij in elke fase van een project de kwaliteit van het project en de software.
Onze methodiek voor projectmanagement
In de methodiek wordt wij hanteren voor onze projectmanagement, staan handvaten en kaders voor onze projectaanpak. Hierin staat onder anderen beschreven welke eisen wij stellen aan de projectopleveringen. Dit stelt ons in staat om het maximale uit elk project te halen, zowel voor onze opdrachtgevers als het werkplezier van onze consultants.
Deze methodiek bevat tevens het regelmatige contact met opdrachtgevers gedurende het traject, onze agile werkmethode, proactieve risico-inventarisatie en een systematische en transparante voortgangsrapportage voor alle stakeholders.
Discovery fase
In deze fase wordt de architectuur van de applicatie en het systeemlandschap vastgesteld en worden mogelijke risico’s in kaart gebracht.
De volgende maatregelen zijn hierbij onder anderen van belang:
De beveiliging van de applicatie en privacy van de gebruikers in de applicatie zijn belangrijke gebieden, waarvoor tijdens de discovery al een Security en Privacy Impact Assessment (SAPIA) wordt uitgevoerd. In de SAPIA wordt gekeken welke informatie de applicatie gaat bevatten en wordt zorgvuldig gekeken naar de privacy gevoeligheid van de data.
Aan de hand van deze analyse worden maatregelen getroffen om de gegevens op een betrouwbare en veilige manier te verwerken en worden de minimaal noodzakelijke beveiligingseisen weergegeven.
Dit omvat onder andere welke inlogmethoden gebruikt moet worden en hoe moet worden omgegaan met de data.
De volgende maatregelen zijn hierbij onder anderen van belang:
- Het implementeren van multifactor-authenticatie.
- Het uitvoeren van een opschoning van de data.
- Het toevoegen van Single Sign-On.
Een risicoanalyse wordt uitgevoerd om het te achterhalen of de applicatie tot de bedrijf kritische applicaties van de organisatie behoord en welke mogelijke risico’s na de implementatie zich kunnen voordoen.
Vanuit daar worden mitigerende maatregelen opgesteld om de impact van deze risico’s te minimaliseren. Na deze analyse wordt de afweging gemaakt in hoeverre prestatie- en geautomatiseerde testen noodzakelijk zijn.
De te ontwikkelen software valt in één van de volgende twee scenario’s:
1. Bedrijf kritische software rondom een core bedrijfsproces.
Voor deze software is het van groot belang dat de prestaties te allen tijde voldoen aan de verwachtingen. In dergelijke gevallen kan besloten worden om geautomatiseerde testen met de Menditect Test Automation tool (MTA) en performance testen met JMeter toe te passen. Om bijvoorbeeld continue te verifiëren of de applicatie in staat is om een hoge dataload aan te kunnen en of de verwerkingstijd voldoet aan de specificaties van de klant.
2. Minder bedrijf kritische toepassing, in mindere mate verantwoordelijk voor het core bedrijfsproces.
Voor deze software is het mogelijk om minder nadruk te leggen op performance testen, aangezien deze tijd en middelen vereisen. Geautomatiseerde testen en unit tests met MTA worden echter altijd uitgevoerd.
Development fase
Tijdens de daadwerkelijk bouw van de software, wordt de kwaliteit op verschillende vlakken continue gemonitord met behulp van verschillende tools en aan de hand van ons ontwikkelhandboek, gebaseerd op ervaring en best practices. Waarmee de CAPE kwaliteit gewaarborgd wordt voor elk project.
Hieronder wordt uitgelegd hoe alle verschillende tools samenhangen om maximale kwaliteit na te streven:
Quality en Security management tool
De eerste kwaliteitstesten worden uitgevoerd met behulp van de Quality en Security management tool (QSM). QSM analyseert de onderlinge samenhang en de interne structuur van de applicatie. QSM maakt een visuele weergave van de applicatie, waarbij het mogelijk is om gedurende de bouw en implementatie fases te analyseren of het plan correct wordt uitgevoerd.
In deze eerste test wordt zorgvuldig gekeken naar de samenhang tussen de verschillende modules, de scheiding van functies binnen de applicatie en het toewijzen van gebruikersrollen. Gebruikersrollen hebben hierbij een grote impact op de security van de te ontwikkelen software, want hier wordt gekeken welke rollen toegang krijgen tot welke functies en data om zo te garanderen dat je juiste gebruikers, bij de juiste data kunnen.
Daarnaast wordt een lang termijnplan opgesteld voor het beheer en de ontwikkeling van de applicatie, om ook de toekomstige kwaliteit van de software te waarborgen.
Application code reviewer (ACR)
De application code reviewer tool richt zich op het controleren van de naleving van best practices, zoals beschreven in ons handboek. Deze tool is met name gericht op de low-code ontwikkeling.
ACR beoordeelt of je model vrij is van fouten op verschillende vlakken, waaronder beveiliging, betrouwbaarheid, onderhoudbaarheid, hygiëne, architectuur en performance.
Dit gebeurt aan de hand van een dashboard, waar specifieke fouten op worden geïdentificeerd.
Elke keer wanneer een nieuw stukje code of feature wordt ontwikkeld, wordt de test uitgevoerd om de kwaliteit te waarborgen en eventuele verbeterpunten tijdig te identificeren en aan te passen.
Menditect Test Automation (MTA)
Zoals hierboven aangegeven wordt in elk project ook de Test automation van Menditect ingezet. Dit doen we om de kwaliteit van de software te garanderen. In de MTA-tool wordt in het begin van de bouwfase een testcase gebouwd, realistisch aan het bedrijfsproces waar de uiteindelijk software in gaat draaien. Met deze realistische weergaves van de werkelijkheid wordt gekeken of de software zich gaat gedragen in het bedrijfsproces zoals hij zich moet gaan gedragen na livegang. Eventuele unhappy flows (processen die nog niet goed worden doorgelopen in de software) worden op deze manier vroegtijdig afgevangen, zodat het na livegang niet voor problemen in het daadwerkelijke bedrijfsproces gaat zorgen.
Om naast de fit met het bedrijfsproces te simuleren, wordt ook de J-Meter ingezet om de dataload die straks door de software moet gaan te testen. Hiermee kijken we of de applicatie de gewenste hoeveelheid data stromen aan kan, zonder afbreuk te doen aan de doorlooptijd.
Quality and Security Management (QSM)
De vierde tool die komt kijken bij het ontwikkelen van de software is Mendix’ Quality and Security Management (QSM).
Deze tooling is gebaseerd op de levensduur van de gebouwde software.
Deze tool beoordeelt of de opbouw en de architectuur van de sotfware dusdanig gebouwd is zodat het onderhoudbaar is voor de komende jaren.
Zo weet je vanaf het begin of de software flexibel genoeg opgebouwd is om gemakkelijk nieuwe features op te bouwen.
CI/CD pipeline
De stappen in de CI/CD-pipeline tool worden aan het begin van de development fase ingesteld om de business consultant te ondersteunen bij het gestructureerd uitvoeren van de bovenstaande testen ACR, MTA en QSM. De CI/CD-pipeline start met de MTA en ACR-testen.
Wanneer een deployment op de planning staat (om de code naar de klantomgeving te brengen), wordt eerst een reeks stappen in de CI/CD-pipeline doorlopen. Dit zorgt ervoor dat de code die wordt uitgerold altijd voldoet aan de benodigde kwaliteitsstandaarden.
Het helpt onder andere te waarborgen dat er geen bedreigingen in de software zitten die de ACR-tool test en dat de testcases in de MTA succesvol zijn afgerond.
Ook worden binnen dit proces de resultaten via dashboards gepresenteerd, zodat de kwaliteit van de release goed wordt gemonitord.
Wanneer er in de development fase wordt gebouwd aan een functionaliteit boven op een bestaande applicatie, dan komt naast bovenstaande kwaliteitstesten ook nog de APM test kijken.
Application performance management (APM)
Bij een nieuwe functionaliteit boven op een bestaande applicatie is het van belang dat deze geen negatieve invloed heeft op de andere reeds bestaande processen in de applicatie.
Daarnaast is het belangrijk te meten welke impact de functionaliteit heeft op het bedrijfsproces wanneer de nieuwe functie live gaat. Wat bijvoorbeeld wordt getest met de APM-test is: hoelang duurt het volledige proces en hoelang duren elke afzonderlijke functies?
APM geeft dit vervolgens weer in een overzichtelijk dashboard. Het is ook essentieel om te weten hoe vaak er microflows worden gebruikt. Dit geeft namelijk een overzicht van mogelijke bottlenecks in de functionaliteit of de applicatie zelf, zodat gerichte verbeteringen doorgevoerd kunnen worden. Het grote voordeel is dat dit dan gebeurt voor de functionaliteit live gaat en de algehele performance van de applicatie gegarandeerd blijft en geoptimaliseerd wordt.
Live applicaties
Zodra een applicatie wordt live gezet, gaat de laatste kwaliteitstool in werking: Sherlock
Sherlock – monitoringsysteem
Sherlock is het door ons ontwikkelde monitoringsysteem, waarin nauwlettend in de gaten wordt gehouden of gestelde kpi’s in de software worden behaald.
Met behulp van een visuele dashboard weergave, geeft Sherlock dag en nacht de performance van de software weer. Hierin kunnen grenzen voor de prestaties worden ingesteld, zodat Sherlock notificaties stuurt wanneer bepaalde onder- en/of overwaardes worden bereikt. Dit stelt onze support en de klant instaat om tijdig in te grijpen wanneer de applicatieperformance dreigen mis te gaan.
Zo worden de prestaties van de CAPE applicaties continue gemonitord en geoptimaliseerd.
Onze kwalitatieve aanpak inzetten
Wil je onze aanpak inzetten voor jouw IT uitdaging?
