In een korte sessie van ongeveer een uur geeft u aan welke functionaliteiten u wenst voor de nieuwe of vervangende applicatie. In ongeveer een dag krijgt u een indicatie van de grootte, de beste concurrerende prijs, onze prijs en de doorlooptijd. Na akkoord plannen we werkzaamheden in. We zijn erg flexibel: in overleg kunnen wij eenvoudig wijzigingen doorvoeren. Ook na akkoord. Vaak zonder effect op de prijs. Hieronder in meer detail de werkwijze:

Dit wordt uitgevoerd met behulp van onze eigen schema migratie tool in combinatie met Liquibase. Een groot deel hiervan is geautomatiseerd en een klein deel handmatig.

We hebben een in TypeScript ontwikkelde React Frontend die zich dynamisch aanpast op basis van de specificaties. Binnenkort kunnen gebruikers ook zelf deze frontend aanpassen met drag & drop en het toevoegen van widgets. 

Dit is mogelijk dankzij de "SMART Requirements Analysis" methode. Een gestructureerde methode waarmee je enkel hoeft vast te leggen wat strikt noodzakelijk is om vast te leggen. Zo hoeft ook enkel het gewenste eindresultaat van het bedrijfs- of diens bedrijfsprocessen vastgelegd te worden. Dat scheelt erg veel tekst en daarmee veel werk. Bovendien dwingt de methode eenduidigheid af en legt het ook fouten in je analyse bloot. Hiermee heb je precies wat je nodig hebt, niet meer en niet minder. Dit alles wordt bovendien gecontroleerd door GEARS. Dit voorkomt in essentie alle fouten in de requirements.

Dit wordt gedaan met een combinatie van geautomatiseerde middelen en menselijk ingrijpen die er samen voor zorgen dat de gebruikte libraries altijd up to date zijn en voldoen aan de laatste security eisen.

Een GEARS gecreëerde applicatie is een Java (Spring Boot) executable en kan dus overal draaien en door een willekeurige partij beheerd worden.

GEARS is een 100% generator. Er hoeven dus geen aanpassingen gedaan te worden aan de gegenereerde ontwerpen en source code en dit is ook niet de bedoeling. Echter, je kunt wel veel met GEARS, maar niet alles. Gelukkig is daar een oplossing voor. 

Niet automatisch, maar het is wel relatief eenvoudig om dit handmatig te doen, met de nodige extra voordelen.

GEARS is een vorm van artificiële intelligentie, maar wel "Deterministrische AI". Oftewel, dezelfde requirements zullen ook altijd hetzelfde voorspelbare traceerbare en vooral foutloze designs en source code opleveren. We liggen hierin dus ruim voor op hedendaagse "Generatieve AI", zoals ChatGPT, die niet kan ontwerpen en waarvan de gegenereerde source code alsnog handmatig door een programmeur gecontroleerd en gecorrigeerd moet worden.

Er zijn 4 manieren om performance te optimaliseren: automatisch door GEARS, door het toevoegen van geoptimaliseerde functies, door het aanroepen van externe functionaliteit of door het isoleren van handmatig te optimaliseren source code.

Alle ontwerp- en codeeractiviteiten worden in seconden tot een paar minuten volledig automatisch uitgevoerd. Gehele projecten, van prille wens tot een operationele oplossing, als ook beheer op software, kosten nu in totaal gemiddeld 10x minder FTE. Dit gaat ruim voorbij aan low/no-code tools en AI-supported-coding die enkel de codeeractiviteiten deels automatiseren. 

Onze oplossingen worden ook binnen banken gebruikt en moet dus aan zeer hoge eisen voldoen.  Denk aan o.a. security, performance, schaalbaarheid, onderhoudbaarheid, compliance, etc. Wordt een bepaalde eis toegevoegd of strenger gemaakt, dan zal dit over het algemeen in GEARS opgelost worden. Dat betekent dat alle oplossingen die met GEARS zijn ontwikkeld daarna met een druk op de knop kunnen voldoen aan deze nieuwe of strengere eisen. 

Naar wens krijgt de klant het IP (Intellectual Property). Hij krijgt dan alle requirements en alle ontwerpen, source code en documentatie voor de applicatie die door GEARS zijn gecreëerd. De source code maakt bovendien enkel gebruik van vrij beschikbare open source componenten. Hiermee is een willekeurige programmeur in staat om de applicatie met conventionele middelen verder te ontwikkelen zonder enige afhankelijkheid met GEARS.

GEARS wordt blijvend verbeterd. Als er betere technieken komen, zoals bijv. betere frameworks, componenten of architecturen, dan zullen wij GEARS aanpassen zodat met een druk op de knop jouw requirements getransformeerd worden naar een systeem conform deze nieuwe technieken.

Ja, maar dit is op bepaalde punten wel beperkt. Zo kun je wel aanpassen hoe het logisch data model omgezet wordt naar een technisch datamodel, en in welke database je de gegevens wilt opslaan.

Ja. Sterker nog, hoe groter en complexer het systeem hoe relatief groter het voordeel is van het gebruik van GEARS.

Dit gaat grotendeels op gebruikelijke wijze.

Versionering is in essentie hetzelfde als bij conventionele software ontwikkeling. Zo werkt het hele team met Git om alle deliverables geversioneerd in op te slaan.

Ja dat kan. Het betreft dan ook echt een logische data modellering omdat alle technische details door GEARS worden geregeld (zie volgende onderwerp).

In principe kan GEARS aangepast worden om allerlei manieren te ondersteunen waarin logische entiteiten uit de business requirements vertaald worden naar een technische data structuur. Natuurlijk heeft het de voorkeur om zo min mogelijk handwerk te hoeven verrichten. Daarom zal GEARS standaard uitgaan van een consistente manier van vertalen. Op dit moment is dat de volgende:

Een groot deel van het handwerk omtrent interfaces wordt door GEARS automatisch uitgevoerd. Op dit moment zijn dit GraphQL API's. 

Omdat GEARS business requirements foutloos vertaald naar een werkend systeem, is het hebben van hebben van lower level unittests in essentie niet meer nodig. Higher level test gevallen zijn nog wel nodig. Deze zijn bedoeld om de business requirements te testen door verschillende testpaden door de gegenereerde business processen en daarmee ook diens onderliggende systeemprocessen te testen. Hieronder een voorbeeld van een klein bedrijfsproces waarin gebruiker employee1 een proces voor een verlofaanvraag start en de eerste taak (scherm) in het proces vult met de gegevens van de verlofaanvraag. Vervolgens voert gebruiker manager1 het besluit in als ook de reden voor dit besluit.  

Het gebruik van Cucumber Selenium kan maar wordt niet aangeraden omdat het hierboven beschreven equivalent in GEARS veel eenvoudiger is.

De grootste voordelen van de ontwikkelsnelheid van GEARS behaal je in het bijzonder bij het maken van goed geïntegreerde informatieverwerkende bedrijfssystemen zoals die voorkomen in de financiële sector, de dienstverlenende sector, de overheid, de zorg, maar ook in de maakindustrie. Maar omdat GEARS zo veel lijkt en goed integreert met een normale manier van software ontwikkeling kun je in essentie met GEARS alle soorten systemen maken die je ook met een normale manier van software ontwikkeling kunt maken. Maar 

Het bijgevoegde plaatje is een samenvatting het ontwikkelproces waarbij we:

Het korte antwoord is: GEARS is een volledige nieuwe generatie van softwareontwikkeling en biedt, zoals bij iedere nieuwe generatie, een drastische verbetering in softwareontwikkeling, zowel in efficiëntie, als ook in kwaliteit. En dat was ook tijd ook, want de vorige 2 generaties bestaan al sinds 1968 en 1972. Die uit 1968 is nu bekend als low/no-code en die uit 1972 is nu bekend als declaratief of functioneel programmeren. Een meer detailleerd antwoord begint met het volgende overzicht wat niet alleen de historie weergeeft, maar ook welke verbetering dit heeft opgeleverd in efficiëntie en kwaliteit.

De meeste klanten kunnen met een instructie van een paar kwartier en een leeswijzer de business requirements al snel lezen en begrijpen. Eenvoudige aanpassingen doen kan over het algemeen ook in een vergelijkbare tijd. Complexere aanpassingen doen vereist meer vaardigheid, maar is zodanig eenvoudig dat ook dit voor een veel breder groep dan bijv. software developers, binnen een paar dagen haalbaar is.