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.

Uiteraard is dit erg afhankelijk van het soort software wat je exact nodig hebt maar de totale tijd voor een geheel project van prille wens tot een operationele oplossing gaat nu gemiddeld 20x sneller.

Onze oplossingen worden ook binnen banken gebruikt en moet dus aan zeer hoge eisen voldoen.

GEARS produceert dezelfde type producten als bij een gebruikelijke manier van software ontwikkelen. Denk aan bedrijfsprocesontwerpen, technische ontwerpen, diagrammen, source code incl. documentatie die tevens aangeeft uit welke requirements dit deel van de source code voortkomt, structuur van het logisch als ook het technisch data model, test cases, etc. Deze deliverables zijn door onafhankelijke analisten en programmeurs gereviewed op onderhoudbaarheid. Daarnaast maakt de resulterende oplossing enkel gebruik van bekende en kwalitatieve open source frameworks en componenten. Dit alles zorgt ervoor dat je ook zonder GEARS, dus met gebruikelijke ontwerp- en programmeer-tools de oplossing kunt aanpassen.

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:

Dit is een grote vraag, het volgende plaatje geeft een samenvatting van de ontwikkeling van verschillende software ontwikkel-tools:

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.