Het bijgevoegde plaatje is een samenvatting het ontwikkelproces waarbij we:
- SRA: de SMART Requirements Analysis methode gebruiken om wensen van klanten c.q. requirements eenduidig te documenteren documenten (c.q. bestanden) die we ook wel SMART notation requirement specificaties noemen.
- GEARS: deze requirement specificaties vervolgens automatisch omgezet worden naar allerlei benodigde deliverables, zoals bijv. ontwerpen, source code, database definities en configuraties.
- APPLICATION: die op hun beurt weer met conventionele CI/CD technieken en tools omgezet kunnen worden naar een werkende applicatie.
SRA: is een methode afgeleid uit de publiekelijk toegankelijke methode "SMART Requirements 2.0". Deze methode dwingt eenduidigheid af door requirements op een formele maar toch begrijpelijke manier te specificeren in de specificatie taal "SMART notation". Je hoeft enkel te specificeren "Wat" het gewenste resultaat is van een proces en de regels waar dat resultaat aan moet voldoen en niet "Hoe" dit resultaat bereikt moet worden. Hiermee maakt de methode een duidelijke scheiding tussen de requirements versus de oplossing. De methode een meetbare productiviteitsverhoging van gemiddeld een factor 2 aangetoond over de volledige life cycle van software projecten (incl. beheer) gemeten o.b.v. 36 projecten tegen QSM benchmarks van vergelijkbare projecten.
GEARS: een in Scala ontwikkelde tool die volledig automatisch het volgende uitvoert in een paar seconden tot een paar minuten tijd (afhankelijk van de grootte van het systeem):
- Lezen: de in SMART notation gespecificeerde business requirements worden gelezen
- Analyseren: de onderlingen afhankelijkheden hierin worden geanalyseerd
- Transformeren: vervolgens worden een reeks van grafentransformaties uitgevoerd waaruit een een volledig ontwerp voortkomt met daarin alle benodigde bedrijfsprocessen als ook diens benodigde onderliggende systeemprocessen.
- Programmeren: als laatste worden all hiervoor benodigde sources gecreëerd en geplaatst in een regulier Java project folder.
Met reguliere CI/CD tools (bijv. Maven, Azure DevOps, Gitlab Pipelines, etc) kunnen deze sources getransformeerd worden naar een werkende, geteste en op code-quality en security vulnerabilities gescande applicatie, die vervolgens ook in verschillende ontwikkel-, test-, acceptatie en productieomgevingen kunnen worden gedeployed. Dit kan zowel on-premise als in de cloud.
APPLICATION: de applicatie is een Java spring boot application. De gemiddelde grootte hiervan is zo'n 90 MB en bevat zowel de specifieke functionaliteit die afgeleid is uit de business requirements als ook generieke out-of-the-box functionaliteit. Deze generieke functionaliteit is volledig open source en heeft dus ook geen licentiekosten.
De applicatie heeft out-of-the-box een HTML5 grafische user interface gemaakt met JavaScript i.c.m. REACT. Dit is een volledig automatisch gecreëerde responsive designed user inteface die handmatig te stylen of aan te passen is. Het is ook mogelijk handmatig een geheel op maat gemaakte user interface of een native mobile app te maken. Hoewel dit regulier ontwikkelwerk is, hoeft deze enkel front-end functionaliteit te bevatten en de back-end functionaliteit aan te roepen middels GraphQL API calls. Dit scheelt weer in de totale handmatige ontwikkeltijd.
De back-end bevat een breed scala aan out-of-the-box functionaliteit zoals bijv. Workflow management/Execution en eenvoudige Identity Acces Management middels Flowable, geavanceerde SSO Identity Access Management middels OIDC en MSAL, search, import and export met verschillende door o.a. XLRIT gemaakte open source componenten en reporting & document creation met Jasper Reports. Database connectiviteit wordt geregeld middels Hibernate en JDBC. Naast onderhoudbaarheid van de source code levert dit ook het voordeel dat zeer veel verschillende soorten databases gebruikt kunnen worden. Denk aan Oracle, Postgres DB, MySQL, MS SQL, en een legio andere relationele databases.
Aan de applicatie kunnen plug-ins worden toegevoegd. Deze kunnen ingezet worden om allerlei soorten externe functionaliteit toe te voegen aan de applicatie. In het merendeel van de gevallen wordt dit gebruikt om te communiceren met externe systemen of devices. Mocht een plug-in nog niet bestaan zal deze handmatig gemaakt moeten worden. Dit kost weinig werk omdat enkel een mapping gemaakt moet worden tussen de vorm hoe het externe systeem/device de gegevens aanbiedt/ontvangt en hoe GEARS dat doet. De rest van de verwerking van de gegevens van deze interfaces wordt automatisch gecreëerd door GEARS op basis van de business requirements (zie hiervoor ook het antwoord op de vraag Kun je met GEARS ook sneller interfaces maken met andere systemen?).
Voor zowel de gehele applicatie geldt dat deze continue verbetert wordt. Hierdoor krijg zowel bestaande als ook nieuwe GEARS gecreëerde applicaties met een druk op de knop de best mogelijke architectuur en technologie. Dit betekent uiteraard ook dat de architectuur als ook de gebruikte technologieën over de loop van tijd vervangen zou kunnen worden met andere architecturen/technologieën als blijkt dat deze beter zijn. Uiteraard desgewenst in overleg.