De invloed van artificiële intelligentie op het low-code softwareontwikkelingsproces

DE

INVLOED

VAN

ARTIFICIËLE

INTELLIGENTIE OP HET LOW-CODE

SOFTWAREONTWIKKELINGSPROCES

GESPECIFIEERD TOT DE PRODUCTONTWIKKELINGSFASE

Aantal woorden: 11085

Raad Rogge

Promotor: Prof. dr. Len Lemeire

Masterproef voorgedragen tot het bekomen van de graad van: Master of Science in de Handelswetenschappen

______________________________________________________________________

PERMISSION

Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Naam student: Raad Rogge

Woord vooraf

Dit document bevat mijn masterthesis: “De invloed van artificiële intelligentie op het low-code softwareontwikkelingsproces”. Deze masterthesis is het sluitstuk van mijn opleiding Handelswetenschappen, afstudeerrichting Management en Informatica aan de Universiteit Gent.

Via deze weg zou ik enkele mensen willen bedanken die mij hebben ondersteund bij het schrijven van deze thesis. Ten eerste zou ik graag mijn promotor, professor Len Lemeire, willen bedanken om mij te ondersteunen en telkens nuttige en uitgebreide feedback te leveren indien dit nodig was. Ten tweede zou ik ook graag Bart Claeys willen bedanken. Hij heeft me immers in contact kunnen brengen met verschillende mensen die me nuttige informatie hebben geleverd voor het schrijven van deze thesis. Vervolgens wil ik ook alle respondenten bedanken voor hun kwalitatieve input. Ten slotte wil ik graag een dankwoord richten aan mijn ouders. Zij hebben het mogelijk gemaakt voor mij om deze richting te studeren en zijn mij blijven steunen tot het einde.

Raad Rogge 26/07/20

Impact van Covid-19

De impact van Covid-19 op dit onderzoek was tweezijdig.

Ten eerste werd vooraf besloten om diepte-interviews af te nemen. Door alle maatregelen in verband met Covid-19 was het niet mogelijk om deze interviews face-to-face af te nemen. Uiteindelijk werd besloten om deze diepte-interviews via digitale communicatiekanalen af te leggen.

Ten tweede had ik in samenspraak met Bart Claeys en een medewerker van Mendix afgesproken om eens een dag langs te gaan in het hoofdkantoor van Mendix in Rotterdam. Hierdoor ging het mogelijk zijn om uitgebreide informatie te verzamelen. Daarnaast zou ik tijdens dit bezoek ook de mogelijkheid gehad hebben om Mendix softwareontwikkelaars te contacteren. Dit zou het verzamelen van respondenten een stuk makkelijker gemaakt hebben.

Inhoudsopgave

1. Introductie ... 1

2. Literatuurstudie ... 3

2.1 De software development life cycle ... 3

2.1.1 Traditionele software development life cycles ... 4

2.1.1.1 Waterfall ... 4

2.1.1.2 Rational Unified Process ... 5

2.1.1.3 Spiral model ... 7

2.1.2 Agile software development life cycles ... 8

2.1.2.1 Extreme Programming ... 9

2.1.2.2 Scrum ... 10

2.1.2.3 Feature Driven Development ... 11

2.1.3 Het verschil tussen de traditionele en agile software development life cycles ... 12

2.1.3.1 Projectgrootte ... 13

2.1.3.2 Menselijke factor ... 13

2.1.3.3 Risicofactoren... 14

2.1.4 Algemene software development life cycle ... 15

2.1.4.1 Fase 1: analyse en planning ... 16

2.1.4.2 Fase 2: definiëren van de vereisten ... 16

2.1.4.3 Fase 3: definiëring architectuur en design ... 17

2.1.4.4 Fase 4: productontwikkeling ... 17

2.1.4.5 Fase 5: software testing ... 17

2.1.4.6 Fase 6: marktimplementatie en onderhoud ... 17

2.1.5 Complexiteiten of problemen in de productontwikkelingsfase ... 18

2.2 Artificiële Intelligentie ... 20

2.2.1 Inleiding artificiële intelligentie ... 20

2.2.2 Artificiële intelligentie in de software development life cycle ... 21

2.2.2.1 AI in fase 1: analyse en planning ... 22

2.2.2.2 AI in fase 2: definiëren van de vereisten ... 22

2.2.2.3 AI in fase 3: definiëring architectuur en design ... 23

2.2.2.4 AI in fase 4: productontwikkeling ... 24

2.2.2.5 AI in fase 5: software testing ... 24

3. Methodologie ... 26 3.1 Afbakening onderzoeksdomein ... 26 3.2 Onderzoeksvraag ... 27 3.3 Wetenschappelijke relevantie ... 28 3.4 Maatschappelijke relevantie ... 28 3.5 Onderzoeksprocedure ... 29 3.6 Motivatie onderzoeksprocedure ... 30 3.7 Evaluatiecriteria ... 31 3.7.1 Betrouwbaarheid ... 31

4.2 AI productmanagers Mendix/OutSystems ... 36 4.2.1 AI productmanager Mendix ... 36 4.2.2 AI productmanager OutSystems ... 36 4.3 Mendix/OutSystems softwareontwikkelaars ... 37 4.3.1 Mendix softwareontwikkelaars ... 37 4.3.2 OutSystems softwareontwikkelaars ... 38 5. Discussie ... 40

5.1 Beperkingen en suggesties voor verder onderzoek ... 42

6. Conclusie ... 43 7. Bibliografie ... IX 8. Bijlagen ... XVI

8.1 Interviews software-experts ... XVI 8.1.1 Software-expert 1 (SE1) ... XVI 8.1.2 Software-expert 2 (SE2) ... XIX 8.1.3 Software-expert 3 (SE3) ... XXIII 8.2 Interviews AI productmanagers ... XXVI 8.2.1 AI productmanager Mendix ... XXVI 8.2.2 AI productmanager OutSystems ... XXX 8.3 E-mail correspondenties softwareontwikkelaars ... XXXV 8.3.1 Mendix respondenten ... XXXV

8.3.1.1 Mendix respondent 1 ... XXXVI 8.3.1.2 Mendix respondent 2 ... XXXVII 8.3.1.3 Mendix respondent 3 ... XXXVIII 8.3.1.4 Mendix respondent 4 ... XXXIX 8.3.1.5 Mendix respondent 5 ... XL 8.3.1.6 Mendix respondent 6 ... XLI 8.3.1.7 Mendix respondent 7 ... XLII

8.3.2 OutSystems respondenten ... XLIII

8.3.2.1 OutSystems respondent 1 ... XLIV 8.3.2.2 OutSystems respondent 2 ... XLV 8.3.2.3 OutSystems respondent 3 ... XLVI 8.3.2.4 OutSystems respondent 4 ... XLVII

Lijst van gebruikte afkortingen

Afkorting Beschrijving

AI Artificiële Intelligentie

ACG Automatic Code Generation

FDD LCDP

Feature Driven Development Low-Code Development Platform

ML Machine Learning

MxAssist Mendix Assist

RUP Rational Unified Process

SDLC Software Development Life Cycle

SRS Software Requirement Specification

UML Unified Modeling Language

Lijst van gebruikte figuren

Figuur 1: Waterfall model ... 5

Figuur 2: Rational Unified Process ... 6

Figuur 3: Spiral model ... 8

Figuur 4: De evolutie van iteraties tussen de verschillende methodologieën ... 9

Figuur 5: Extreme Programming methodologie ... 10

Figuur 6: Algemene software development life cycle ... 16

Figuur 7: Magische kwadrant voor low-code applicatie platformen ... 33

Lijst van gebruikte tabellen

1. Introductie

De globalisering van de voorbije decennia heeft als gevolg dat bedrijven steeds meer met elkaar in verbinding staan (Herbsleb & Moitra, 2001). Deze trend gaat gepaard met een alsmaar software-intensievere bedrijfswereld (Herbsleb & Moitra, 2001). Taentzer et al. (2019) stellen dat software een onmisbaar onderdeel van bedrijfsprocessen is geworden. Om softwareontwikkeling beter te begrijpen, ondersteunen en optimaliseren, maken bedrijven gebruik van een Software Development Life Cycle (SDLC) (Taentzer et al., 2019). Een SDLC beschrijft de noodzakelijke te voltooien processen tijdens een softwareproject (Leau, Loo, Tham, & Tan, 2012).

Uit wetenschappelijk onderzoek blijkt echter dat er nog steeds veel softwareprojecten falen (Xia & Lee, 2004). Dit komt omdat softwareontwikkelaars enerzijds de technische complexiteit van softwareprojecten onderschatten (Vidal, Marle & Bocquet, 2011). Technische componenten zijn namelijk onderhevig aan verandering (Xia & Lee, 2004). Anderzijds wordt ook de organisatorische complexiteit van softwareprojecten onderschat (Vidal et al., 2011). Zo krijgen softwareontwikkelaars te maken met steeds dynamischere projecten waardoor sneller op de noden van de klant moet worden ingespeeld (Butler, Vijayasarathy & Roberts, 2019). Algemeen kan gesteld worden dat de oorzaak van deze complexiteiten of problemen te wijten is aan een gebrek van bepaalde kennis (Taentzer et al., 2019). Terwijl de vraag naar software blijft stijgen, blijkt het niet evident om software af te leveren met zowel een hoge graad van integriteit, robuustheid als gebruikersacceptatie (Leau et al., 2012). Om bovenstaande complexiteiten of problemen die zich voordoen tijdens het softwareontwikkelingsproces op te lossen, stelt Harman (2012) dat Artificiële Intelligentie (AI) kan gehanteerd worden. AI is een technologie die een machine de mogelijkheid geeft om cognitieve functies uit te voeren (Jakhar, 2019). Softwareontwikkeling omvat het definiëren en ontwikkelen van sommige van de meest complexe en uitdagende systemen dat de mens ooit heeft willen ontwikkelen (Harman, 2012). AI kan omwille van zijn eigenschappen inspelen op deze complexe zaken

softwareontwikkeling. Low-code is een visuele vorm van softwareontwikkeling die de laatste jaren een sterke opmars doormaakt. Dit onderzoek zal een bijdrage leveren om deze leemte in de wetenschappelijke literatuur op te vullen. Het onderzoek focust zich op de productontwikkelingsfase van de SDLC.

Bovenstaande leemte zal onderzocht worden door AI-assisted development tools op low-code development platformen (LCDPen) te onderzoeken. De onderzoeksvraag van dit onderzoek luidt als volgt: In welke mate kan artificiële intelligentie de productontwikkelingsfase op low-code development platformen verbeteren? Om deze vraag te kunnen beantwoorden, zullen verschillende stappen ondernomen worden. Allereerst zal op basis van diepte-interviews met software-experts bepaald worden wat de specifieke problemen of barrières zijn in de onderzochte fase van de SDLC. Vervolgens zullen twee cases onderzocht worden: ten eerste MxAssist, de AI-tool op het Mendix low-code development platform (LCDP); ten tweede OutSystems.ai, de AI-tool op het OutSystems LCDP. Aan de hand van diepte-interviews met de AI productmanagers van deze bedrijven zal bepaald worden in welke mate de AI-tools inspelen op de vastgestelde problemen. Ten slotte zullen de vaststellingen uit de diepte-interviews met de AI productmanagers worden afgetoetst aan de persoonlijke bevindingen van softwareontwikkelaars die deze AI-tools in de praktijk gebruiken. Zo kan nagegaan worden indien de AI-tools een effectieve impact hebben in de praktijk.

Het verdere verloop van deze paper wordt in deze paragraaf weergegeven. In deel 2 Literatuurstudie zal de theoretische achtergrond in verband met de SDLC en AI uitgebreid worden besproken. Vervolgens worden in deel 3 Methodologie de onderzoeksvraag, onderzoeksmethode en de cases verklaard. Daaropvolgend worden in deel 4 Resultaten de resultaten van het onderzoek weergegeven. Ten slotte worden deze resultaten in deel 5 Discussie geïnterpreteerd.

2. Literatuurstudie

2.1 De software development life cycle

In het begin van de jaren zeventig was er een groeiend bewustzijn omtrent de mogelijke impact van softwaresystemen op de maatschappij (Mens & Demeyer, 2008). Echter

werden er nog veel problemen vastgesteld in het toenmalige

softwareontwikkelingsproces (Mens & Demeyer, 2008). Softwareontwikkelaars hanteerden toen een “code and fix” aanpak (Awad, 2005). Deze aanpak was efficiënt voor eerder kleine softwaresystemen (Lehman, 1980). Naarmate softwaresystemen echter groter en complexer werden, bleek deze aanpak ondermaats en erg kostelijk

(Lehman, 1980). Wetenschappers concludeerden dat de toenmalige

softwareontwikkelingstechnieken minder ad hoc moesten worden (Mens & Demeyer, 2008). Wetenschappers en practici stelden voor om het softwareontwikkelingsproces theoretisch te onderbouwen aan de hand van raamwerken en praktische disciplines (Mens & Demeyer, 2008). Zo ontstonden er methodologieën, Software Development Life Cycles genoemd. Een SDLC is een methodologie die alle fases, zoals het design, bouwen en onderhouden van het softwareontwikkelingsproces omvat met als doel de kwaliteit van software te verhogen (Bassil, 2012). Sommige organisaties hanteren eigen ontwikkelde methodologieën (Stoica, Mircea, Ghilic-Mircu, 2013). Wetenschappers zijn het er echter over eens dat het grootste deel van de methodologieën onder te verdelen is in twee categorieën (Khan, Qureshi & Khan, 2011). Deze categorieën zijn de volgende (Awad, 2005; Stoica et al., 2013):

- De traditionele of heavyweight software development life cycles - De agile of lightweight software development life cycles

Er bestaan verschillende traditionele en agile modellen. Elk model heeft zijn specifieke voordelen, beperkingen en dusdanig ook een ideale omgeving om te hanteren (Stoica et al., 2013). Ongeacht welk model, is het hoofddoel van een SDLC steeds het kaderen van

2.1.1 Traditionele software development life cycles

Traditionele methodologieën werken aan de hand van een sequentiële reeks stappen, bestaande uit de definiëring van de vereisten, het ontwikkelen van de software, een testfase en de implementatie (Awad, 2005). Door deze strikte opvolging van stappen staan deze methodologieën bekend als de heavyweight methodologieën (Awad, 2005). Deze traditionele methodologieën waren bedoeld om softwareontwikkeling efficiënter te laten verlopen (Awad, 2005). Ze hanteren vaak een gedetailleerde documentatie, inclusieve planning en een uitgebreid design (Khan et al., 2011). Vervolgens worden de meest gehanteerde traditionele modellen besproken (Awad, 2005; Stoica et al., 2013):

- Waterfall

- Rational Unified Process (RUP) - Spiral model

2.1.1.1 Waterfall

Het Waterfall model, ook bekend als het lineaire model, is de oudste SDLC (Alshamrani & Bahattab, 2015). Winston Royce ontwikkelde het model in 1970 om een antwoord te bieden op de toenmalige “code and fix” aanpak (Awad, 2005). Het Waterfall model legt de nadruk op een structureel verloop doorheen vooraf vastgelegde fases (Awad, 2005). Elke fase bestaat uit een gedefinieerde set van activiteiten. Alvorens een nieuwe fase kan opgestart worden, moet de voorgaande fase afgerond zijn (Stoica et al., 2013). Dit model gaat samen met een uitgebreide documentatie en een gestructureerd design en is dus gepast voor projecten die een hoge kwaliteitscontrole voorzien (Alshamrani & Bahattab, 2015). Dankzij de starheid van het model is het makkelijk te coördineren. Het Waterfall model wordt vooral aangeraden voor kleinere projecten waarbij de vereisten duidelijk uitgewerkt zijn (Stoica et al, 2013).

Dit model brengt echter ook enkele nadelen met zich mee. Ten eerste biedt het model weinig flexibiliteit (Stoica et al., 2013). Het is moeilijk om veranderingen, zoals nieuwe vereisten, te implementeren (Petersen, Wohlin & Baca, 2009). Dit kan leiden tot extra kosten. Daarnaast worden fouten vaak te laat opgemerkt in het ontwikkelingsproces (Petersen et al., 2009). Ten slotte blijkt het moeilijk om de benodigde tijd en het budget in te schatten (Stoica et al., 2013).

2.1.1.2 Rational Unified Process

Het RUP verloopt aan de hand van werkstromen (Awad, 2005). Deze worden uitgevoerd op een iteratieve en incrementele manier (Awad, 2005). Dit model maakt gebruik van een visuele modelmatige taal, zoals de Unified Modeling Language (UML) (Ruparelia, 2010). UML stelt code schematisch voor, waardoor minder technisch aangelegde individuen het probleem beter kunnen begrijpen en zo ook een inbreng kunnen leveren (Awad, 2005). De cyclus van het RUP is zichtbaar in figuur 2. Om de duur van een project te kunnen bepalen, wordt het project onderverdeeld in vier fases:

- Inception: in deze fase wordt een specifieke businesscase opgesteld. Deze omvat het opstellen van de vereisten of use cases. Daarnaast wordt de scope van het design en de haalbaarheid bepaald (Awad, 2005).

- Construction: in deze fase wordt de software grotendeels geprogrammeerd. Op het einde van deze fase bestaat er een betaversie. Dit is een werkend systeem dat reeds kan getest worden onder realistische condities (Awad, 2005).

- Transition: het systeem wordt geïntroduceerd aan stakeholders en eindgebruikers. Deze fase kan pas bereikt worden indien het ontwikkelingsteam alle objectieven uit de eerste fase heeft bereikt (Awad, 2005).

Dit model brengt verschillende voordelen met zich mee. Ten eerste vergemakkelijkt het RUP het hergebruik van softwareonderdelen omdat onderdelen deel per deel worden geïmplementeerd (Kruchten, 2000). Verder zorgen de verschillende iteraties voor een robuust eindproduct (Kruchten, 2000). Ten slotte ondersteunt het RUP een hoge kwaliteit van software door het inplannen van kwaliteitscontroles doorheen het ganse proces (Awad, 2005). Daartegenover vraagt dit model een strikte aanpak en een uitgebreide documentatie aangezien de iteraties lang duren (Awad, 2005). Het RUP wordt hierdoor aanzien als een complex model (Awad, 2005). Het kan gebruikt worden voor kleinschalige tot middelgrote projecten, op voorwaarde dat risico’s gelimiteerd zijn (Ruparelia, 2010). Voor grootschalige projecten is dit echter geen aanbevolen model (Ruparelia, 2010).

2.1.1.3 Spiral model

Het Spiral model werd gedefinieerd door Barry Boehm. Het model is afgeleid van het Waterfall model (Ruparelia, 2010). De nadelen van het sequentiële verloop van het Waterfall model worden gemilderd door telkens een stap vooruit te kijken (Ruparelia, 2010). Zo wordt een hogere herbruikbaarheidsgraad bekomen en kunnen risico’s beter geanalyseerd worden (Ruparelia, 2010).

Het softwareontwikkelingsproces wordt voorgesteld als een spiraal in plaats van een waterval van sequentiële activiteiten (Khan et al., 2011). Het Spiral model, zichtbaar op figuur 3, bestaat uit vier fases die in elke cyclus terugkomen (Khan et al., 2011). Ten eerste worden alle objectieven of vereisten voor een bepaalde cyclus gedefinieerd. Vervolgens worden alle risico’s geïdentificeerd en opgelost (Awad, 2005). Het model besteedt veel tijd aan risicoschatting en het minimaliseren van risico’s (Alshamrani & Bahattab, 2015). Op het einde van elke cyclus wordt het prototype in de planningsfase gereviseerd. Daarnaast worden nieuwe plannen opgesteld voor de volgende cyclus van de spiraal (Awad, 2005). Dit model wordt soms echter in vraag gesteld omwille van het feit dat er geen onderhoudsfase in vervat is (Ruparelia, 2010). Daarom wordt dit model eerder aanzien als een meta-model (Alshamrani & Bahattab, 2015). Dit wil zeggen dat het kan gebruikt worden in andere modellen.

2.1.2 Agile software development life cycles

Practici bevonden bovenstaande traditionele methodologieën in bepaalde omstandigheden onpraktisch wegens de onbuigzaamheid (Awad, 2005). Het implementeren van veranderingen bij de traditionele methodologieën is namelijk een log proces dat strikt wordt opgevolgd door het change control management (Stoica et al., 2013). Traditionele methodologieën zijn dus niet adaptief (Ruparelia, 2010). Fowler (2001) omschrijft de traditionele methodologieën als bureaucratische methodologieën. Het doel van de agile of leightweight methodologieën is dus om een oplossing te bieden voor de problemen omtrent de traditionele methodologieën (Dybå, Prikladnicki, Rönkkö, Seaman & Sillito, 2011). Agile softwareontwikkeling wordt namelijk gekenschetst door de adaptieve omgang in verband met veranderingen in het softwareontwikkelingsproces (Aitken & Ilange, 2013). Bijgevolg maken deze methodologieën het makkelijker en goedkoper om te reageren op eventuele aanpassingen (Aitken & Ilange, 2013). De agile methodologieën zijn daarnaast gefocust op samenwerking tussen klant en softwareontwikkelaar (Aitken & Ilange, 2013). Dit in tegenstelling tot traditionele methodologieën die gefocust zijn op het contractuele aspect (Aitken & Ilange, 2013).

Vervolgens worden enkele van de meest gehanteerde agile methodologieën besproken (Awad, 2005):

- Extreme Programming (XP) - Scrum

- Feature Driven Development (FDD)

2.1.2.1 Extreme Programming

XP werd op het einde van de jaren 1990 ontwikkeld door Kent Beck (Aitken & Ilange, 2013). In tegenstelling tot het Waterfall model is XP een adaptieve methodologie. Het model werkt aan de hand van korte ontwikkelingscycli, waarbij telkens feedback wordt meegegeven (Beck, 1999).

XP bestaat uit zes fases. In de exploratiefase legt de klant de vereisten, genaamd stories in XP, vast (Beck, 1999). In de planningsfase worden deze stories volgens prioriteit gerangschikt (Awad, 2005). Vervolgens wordt in de derde fase, iterations to release, een systeemarchitectuur ontwikkeld. Hierbij wordt het pair programming principe vaak toegepast (Awad, 2005). De software die in een iteratie werd ontwikkeld, wordt ook telkens getest in deze fase (Awad, 2005). Na elke iteratie geeft de klant feedback op het product in de productionizing fase (Abrahamsson, Salo, Ronkainen, & Warsta, 2002).

Door het adaptieve karakter van dit model kan beter worden gereageerd op een veranderende omgeving (Awad, 2005). Het feit dat XP werkt aan de hand van korte ontwikkelingscycli heeft als gevolg dat het model moeilijk te gebruiken valt bij grote projecten. Daarnaast bemoeilijkt dit ook onderhoud op lange termijn (Aitken & Illange, 2013).

2.1.2.2 Scrum

Scrum voorziet geen specifieke softwareontwikkelingsmethode (Awad, 2005). In plaats daarvan voorziet het praktijken en tools in de verschillende fases van de ontwikkelingscyclus om chaos te minimaliseren (Awad, 2005). Scrum werkt aan de hand van zelforganiserende teams waardoor de Scrum Master of projectmanager het Scrumteam niet constant hoeft te organiseren (Awad, 2005). Hieronder worden de belangrijkste praktijken en tools van Scrum besproken.

- Product Backlog: Een geprioriteerde lijst van alle vereisten of veranderingen die nog moeten gemaakt worden. De product owner is verantwoordelijk voor de Product Backlog.

- Sprint Planning: Tijdens een Sprint Planning wordt in samenspraak met de klant, eindgebruikers, product owner en het Scrumteam vastgelegd welke functionaliteiten in de opkomende sprint moeten worden ontwikkeld.

- Sprints: Een sprint bestaat uit 30 dagen. In elke sprint worden een aantal vereisten voltooid. Uiteindelijk moet een sprint leiden tot een incrementeel deel.

- Sprint Backlog: Een lijst met alle vereisten die in de opkomende sprint moeten ontwikkeld worden.

- Daily Scrum: Een dagelijkse meeting van ongeveer 15 minuten waarbij de progressie en eventuele obstakels worden besproken.

Scrum bleek reeds succesvol in duizenden projecten en leidt tot een hogere productiviteit (Awad, 2005). Deze methodologie is echter niet aan te raden bij grote, complexe teamstructuren (Awad, 2005).

2.1.2.3 Feature Driven Development

Net zoals de andere agile methodologieën, werkt FDD aan de hand van korte iteraties die telkens een tastbaar product opleveren (Fowler, 2001). In tegenstelling tot de andere agile methodologieën focust dit model zich echter niet op het ganse softwareontwikkelingsproces, maar eerder op de design- en ontwikkelingsfase (Awad, 2005). Bij aanvang van een project worden drie fases doorlopen. Ten eerste wordt een algemeen model opgezet. Vervolgens worden de vereisten, features genoemd in FDD, vastgelegd. Ten slotte worden de vereisten gerangschikt volgens prioriteit (Awad, 2005). Hierna volgen de design- en ontwikkelingsfase. Deze laatste twee fases komen telkens terug in iteraties. Elke iteratie bestaat uit verschillende taken zodanig dat de benodigde vereisten worden gebouwd (Fowler, 2001). In FDD bestaan er twee soorten ontwikkelaars: chief programmers en class owners (Fowler, 2001). De chief programmer wordt aanzien als de meest ervaren ontwikkelaar. Hij zal ageren als coördinator, en mentor, terwijl de class owners grotendeels coderen (Fowler, 2001). De code wordt in elke iteratie uitvoerig getest (Fowler, 2001). In FDD wordt de vooruitgang van nabij

2.1.3 Het verschil tussen de traditionele en agile software development life cycles

De traditionele software development life cycles bestaan reeds een lange tijd. Ondanks de successen kennen de traditionele methodologieën ook enkele nadelen zoals lineariteit, de formele processen en daarbij horende inflexibiliteit (Awad, 2005). Kent Beck nam deze nadelen mee in zijn ontwikkeling van het Extreme Programming model, de eerste agile methodologie. Deze methodologieën spelen, zoals vermeld in sectie 2.1.2, in op snel veranderende omgevingen en vereisten en de lineariteit van traditionele methodologieën. Onderstaande tabel toont de verschillen aan tussen de traditionele of heavyweight en de agile of lightweight methodologieën.

Tabel 1: Verschillen tussen traditionele en agile methodologieën (Awad, 2005)

Zowel de traditionele als de agile methodologieën hebben elk hun specifieke voor- en nadelen. Vervolgens worden de hoofdfactoren besproken die bepalen welke methodologie het best gehanteerd kan worden in bepaalde omstandigheden.

Traditionele methodologieën

Agile methodologieën

Aanpak Voorspellend Adaptief

Projectgrootte Groot Klein

Managementstijl Autocratisch Gedecentraliseerd

Verandering Minder geschikt voor verandering

Geschikt voor verandering

Nadruk Process georiënteerd Mens georiënteerd

Cycli Gelimiteerd Meerdere

Voorafgaande planning Uitgebreid Minimaal

ROI Einde van het project Vroeg in het project

Teamgrootte Groot Klein

2.1.3.1 Projectgrootte

De projectgrootte wordt bepaald door het projectbudget, de duur en de teamorganisatie (Awad, 2005). Hoe groter het team of hoe meer budget er nodig is, hoe groter het project is.

Ten eerste komen er bij een groot project meer vereisten, meer mensen en meer coördinatie kijken (Awad, 2005). De traditionele methodologieën ondersteunen bovenstaande benodigdheden door een uitgebreide planning, documentatie en gestandaardiseerde communicatie- en coördinatieprocessen (Awad, 2005). Awad (2005, p.36) stelt dat voor een gegeven probleem, “minder mensen nodig zijn indien een agile methodologie wordt gebruikt en meer mensen nodig zijn indien een traditionele methodologie wordt gebruikt.”. Aansluitend stelt Cockburn (2006) echter dat er een limiet staat op de grootte van een probleem bij een gegeven aantal mensen. Vervolgens heeft de grootte van het project ook een invloed op de communicatie en de effectiviteit per persoon (Awad, 2005).

De agile en traditionele methodologieën hanteren een verschillende aanpak omtrent coördinatie. Hoe meer mensen betrokken zijn bij het project, hoe meer een traditionele methodologie zich opdringt (Cockburn, 2006). Ten slotte moet ook de duur van een project in acht worden genomen bij het uitkiezen van een optimale methodologie (Awad, 2005). Traditionele methodologieën brengen namelijk veel documentatie met zich mee (Awad, 2005). Een agile methodologie is dus meer voorhanden wanneer de tijd gelimiteerd is.

2.1.3.2 Menselijke factor

Teams met ervaren en bekwame mensen zijn een sleutelfactor voor agile methodologieën (Awad, 2005). Daarnaast krijgt de klant bij agile methodologieën de mogelijkheid om de progressie op te volgen en het project bij te sturen na iedere iteratie (Awad, 2005). Deze mate van klantenbetrokkenheid maken agile methodologieën

een geval zullen agile methodologieën moeilijk te integreren zijn. Het tegenovergestelde geldt indien een organisatie zich flexibel opstelt en bijgevolg toegankelijk is voor veranderingen in verband met de bedrijfscultuur.

2.1.3.3 Risicofactoren

De belangrijkste risicofactoren in softwareontwikkeling zijn de kriticiteit van een softwareproject en de mate waarin aan verandering kan beantwoord worden (Awad, 2005). Bij kritische systemen die een hoge mate van security en betrouwbaarheid vergen, wordt beter een traditionele methodologie gehanteerd (Awad, 2005). Indien een softwareproject van kritisch belang is, moeten alle vereisten immers goed omschreven worden. Een slechte documentatie van deze vereisten zou immers kunnen leiden tot onvoorziene schade (Awad, 2005). De agile praktijken, zoals constante feedback en korte iteraties, sluiten dan weer eerder aan bij softwareprojecten waar snel moet worden ingespeeld op verandering.

2.1.4 Algemene software development life cycle

Zoals aangetoond in sectie 2.1.3 hangt de keuze voor een traditionele of agile methodologie af van verscheidene factoren. Hoewel Aitken & Ilange (2013) aanhalen dat de agile methodologieën het laatste decennium meer gebruikt worden, zijn de traditionele methodologieën nog steeds geschikt voor bepaalde softwareprojecten. Daarnaast bestaan er ook verschillende agile en traditionele modellen.

Omwille van bovenstaande redenen wordt in het verdere verloop van dit onderzoek gebruik gemaakt van een algemene SDLC (figuur 6). Onderstaande SDLC definieert geen specifieke ontwikkelingsmethode, maar omschrijft enkel de te doorlopen processen. Deze SDLC sluit aan bij ISO/IEC 12207, de internationale standaard van software development life cycles (Marks, Yilmaz, O’Connor, & Clarke, 2018). Volgens deze standaard bevat een SDLC onderstaande technische processen:

- Business analyse

- Definiëring stakeholder vereisten - Definiëring software vereisten - Definiëring architectuur - Definiëring design - Systeemanalyse - Implementatie - Integratie - Verificatie - Transitie - Validatie - Onderhoud - Afhandeling

2.1.4.1 Fase 1: analyse en planning

De eerste fase omvat ten eerste het inschatten van de nodige inspanningen om het softwareproject succesvol te voltooien. Hierbij worden vooral het budget en de benodigde tijd gekaderd (Baskeles, Turhan, & Bener, 2008). Ten tweede wordt ook de effectieve business case geanalyseerd (Stoica et al., 2013). Vervolgens worden de vereisten van het softwareproject geanalyseerd (Stoica et al., 2013). Om een allesomvattende vereistenanalyse te bekomen, wordt informatie gebruikt van klanten, experten en wordt er ook een marktonderzoek uitgevoerd (Stoica et al., 2013). Deze informatie wordt dan gebruikt om een basisplan op te stellen. Hierna wordt een haalbaarheidsanalyse uitgevoerd vanuit een technisch standpunt (Stoica et al., 2013).

2.1.4.2 Fase 2: definiëren van de vereisten

Nadat de vereisten zijn geanalyseerd, worden deze gedefinieerd en gedocumenteerd (Stoica et al., 2013). Deze moeten hierna door de klant of door een marktanalist aan de hand van een Software Requirement Specification (SRS) document worden goedgekeurd (Stoica et al., 2013). Het SRS-document bevat alle productvereisten (Stoica et al., 2013). Alle vereisten moeten verwerkt worden in een design en uiteindelijk worden ontwikkeld.

2.1.4.3 Fase 3: definiëring architectuur en design

Het SRS-document vormt de basis voor de architectuur van het softwareproduct (Stoica et al., 2013). Nadat een architectuur is opgesteld wordt deze ter goedkeuring voorgelegd aan alle betrokken partijen (Stoica et al., 2013). Daarnaast wordt er voor alle componenten een design opgemaakt (Stoica et al., 2013).

2.1.4.4 Fase 4: productontwikkeling

In deze fase start de effectieve ontwikkeling van het softwareproduct. De software wordt dusdanig geprogrammeerd (Stoica et al., 2013). Indien het design in de vorige fase op een gedetailleerde en georganiseerde manier werd vastgelegd, verloopt deze fase relatief vlot voor softwareontwikkelaars (Stoica et al., 2013).

2.1.4.5 Fase 5: software testing

Software testing is het proces waarbij de kwaliteit van een softwaresysteem getest wordt zodanig deze aansluit bij de vooraf opgestelde vereisten (Noorian, Bagheri, & Du, 2011). In deze fase wordt de ontwikkelde software dus uitvoerig getest zodanig dat eventuele fouten kunnen opgespoord, gerapporteerd, hersteld en opnieuw geanalyseerd worden (Stoica et al., 2013). Na het debuggen wordt de software opnieuw getest en geanalyseerd tot alle vereisten functioneel zijn.

2.1.4.6 Fase 6: marktimplementatie en onderhoud

Eens het finale product getest is, kan het op de markt gebracht worden. Het softwareproduct kan eventueel eerst getest worden in een marktsegment zodanig dat er feedback kan verzameld worden van eindgebruikers (Stoica et al., 2013). Na eventuele aanpassingen wordt het product op de ganse markt gelanceerd (Stoica et al., 2013). Na de lancering van het product zullen er zich regelmatig onderhoudsfases voordoen om de software up-to-date te houden (Stoica et al., 2013).

2.1.5 Complexiteiten of problemen in de productontwikkelingsfase Dit onderzoek focust zich op de productontwikkelingsfase van de SDLC. Het programmeren van software vergt verschillende vaardigheden en kennis. Dit gaat gepaard met complexiteiten of problemen. Vervolgens worden de complexiteiten of problemen, die terug te vinden zijn in de wetenschappelijke literatuur, voorgelegd. Ten eerste wordt de productiviteit van een softwareontwikkelaar aanzien als een complex gegeven in de wetenschappelijke literatuur. Chen (1978) definieert de productiviteit van een programmeur als een input-proces-output structuur. Het identificeren en combineren van de verschillende factoren die de productiviteit beïnvloeden, maakt het meten ervan erg moeilijk (Maxwell, Van Wassenhove, & Dutta, 1996). De benodigde tijd voor het voltooien van een softwareproject is een essentieel onderdeel (Blackburn, Scudder, & Van Wassenhove, 1996). Veel bedrijven bevinden zich namelijk in een competitieve markt waarbij het te laat afleveren van een product een negatieve impact kan betekenen (Blackburn et al., 1996). Vervolgens is ook de kwaliteit van de software een indicatie van de productiviteit (Duncan, 1988). Onderzoek van Gartner (2012) wijst echter uit dat ongeveer de helft van de softwareprojecten faalt om de vooropgestelde doelen omtrent onder andere tijd, kwaliteit en budget te behalen.

Daarnaast is het aanleren van programmeertalen een van de grootste barrières bij softwareontwikkeling (Al-Imamy, Alizadeh, & Nour, 2006). Het leerproces is desoriënterend wanneer men voor de eerste keer hiermee in contact komt (Cazzola & Olivares, 2016). Verschillende practici stellen dat de leercurve van softwareontwikkelaars niet relevant is omdat deze niet rechtstreeks terugkomt in de SDLC (Raccoon, 1996). Het aanleren van een programmeertaal of gerelateerde nieuwe vaardigheden vergt echter tijd en is dus wel degelijk relevant (Raccoon, 1996). Deze tijdinnemende en complexe leerprocessen zorgen ervoor dat het moeilijk is voor softwareontwikkelaars om inzichten te verkrijgen in wat men leert, terwijl dit wel essentieel is (Al-Imamy et al., 2006). Volgens Cazzola & Olivares (2016) ligt het kernprobleem namelijk niet bij het aanleren van het coderen zelf, maar bij het begrijpen van de kerncomponenten en -ideeën van coderen. Zowel beginners als experts blijven vaak dezelfde fouten maken (Stewart, 2006). Deze fouten kunnen erg kostelijk uitdraaien voor bedrijven (Stewart, 2006).

Vervolgens vormt ook de software security vaak een probleem. De software security zorgt ervoor dat de software niet voor verkeerde doeleinden kan gebruikt worden (McGraw, 2004). Technici erkennen dat dit proces vaak nog een probleem vormt in softwareontwikkeling omdat velen uiteindelijk niet begrijpen hoe dit probleem kan aangepakt worden (McGraw, 2004). De groeiende complexiteit van software zorgt ervoor dat dit een groeiend probleem vormt (McGraw, 2004).

Ten slotte treffen organisaties barrières aan omtrent integraties (Ruh, Maginnis & Brown, 2002). Gartner concludeerde in een onderzoek dat organisaties ongeveer 35% van hun IT resources spenderen aan integraties (Ruh et al., 2002). Deze barrière omtrent integraties is doorheen de jaren gegroeid omdat organisaties beseffen dat ze ongelijke systemen met elkaar moeten verbinden om te kunnen voldoen aan de business noden (Ruh, et al., 2002).

2.2 Artificiële Intelligentie

2.2.1 Inleiding artificiële intelligentie

In 1950 voerde Alan Turing in zijn onderzoek, ‘Computing Machinery and Intelligence’, de Turing Test uit (Saygin, Cicekli, & Akman, 2000). In deze test werden een computer en een individu in een aparte ruimte geplaatst. Beiden werden verbonden met een externe ondervrager. Indien de externe ondervrager niet kon bepalen in welke kamer het individu zat, werd de computer als intelligent aanzien (Saygin et al., 2000). Deze test wordt aanzien als de eerste operationele definitie van machine intelligence en was het begin van verder onderzoek naar AI (French, 2012).

Er bestaan verschillende definities van AI en velen verwarren dan ook de volgende termen: AI en Machine Learning (ML). AI verwijst naar het onderzoeksgebied van de computerwetenschappen dat als doel heeft om computersystemen te creëren die cognitieve taken kunnen uitvoeren, zoals probleemoplossend denken (Barr & Feigenbaum, 1982). Deze computersystemen voeren deze taken uit aan de hand van modellen en algoritmes (Barr & Feigenbaum, 1982). ML is een subset van AI. Het is een techniek waarbij computersystemen bijleren uit hun veranderende omgeving en zich ook steeds aanpassen aan deze omgeving zonder hiertoe expliciet geprogrammeerd te zijn (Jakhar, 2019). Een ML-systeem leert dus aan de hand van data (Alpaydin, 2020). De kwaliteit van softwaresystemen verhoogt naarmate er meer kennis beschikbaar is (Meziane & Vadera, 2010). Aangezien ML-technieken constant data vergaren, kunnen deze systemen zorgen voor kwalitatievere software (Meziane & Vadera, 2010; Zhang & Tsai, 2003). Er is dusdanig potentieel om de processen van de SDLC efficiënter te maken aan de hand van AI (Meziane & Vadera, 2010). Doordat AI-technieken krachtdadiger en daarnaast makkelijker te gebruiken worden, worden deze in toenemende mate gehanteerd in moderne softwaresystemen (Feldt, Oliveira Neto, & Torkar, 2018). Het domein maakt dan ook een enorme groei door omwille van de heropgeleefde interesse en verbeterde resulaten in functionele toepassingen (Feldt et al., 2018). Feldt et al. (2018) stellen dat dit zal leiden tot nieuwe functionaliteiten en betere adaptie naar de gebruikersbehoeften toe.

2.2.2 Artificiële intelligentie in de software development life cycle

AI zal de SDLC stap per stap verbeteren, versnellen en ontwrichten (Lo Giudice, 2016). De combinatie van AI-technologieën zoals ML, deep learning en natural language processing zullen uiteindelijk een impact hebben op alle stappen van de SDLC (Lo Giudice, 2016). Hierdoor zullen softwareontwikkelaars sneller software kunnen ontwikkelen (Lo Giudice, 2016). Softwareontwikkelaars zullen zich in de toekomst eerder bezighouden met het selecteren en trainen van algoritmes in plaats van programmacode te schrijven (Lo Giudice, 2016).

Lo Giudice (2016) interviewde in zijn onderzoek 30 softwareontwikkelingsteams over de mogelijkheden van AI in softwareontwikkeling. Onderstaande tabel vat zijn bevindingen samen.

Impact van AI op softwareontwikkeling Business voordelen

Hogere mate van automatisatie Sneller opleveren van kwalitatievere

software

Interactieve natural language in interfaces Verbeteren van de klantenervaring

Voorspellen van het klantenverloop Klanten en inkomsten behouden

Beheren van grote hoeveelheden data in de SDLC

Inzichten verwerven waardoor

softwareontwikkeling beter verloopt Optimaliseren van het toewijzen van

resources

Kosten drukken

Automatiseren van beslissingen Schalen van menselijke beslissingen

Verbeteren van analyses en diagnoses Kwalitatievere software

Verbeteren van de productiviteit van de softwareontwikkelaar

Lagere kosten, meer inkomsten

AI-technieken worden reeds voor verschillende doeleinden gebruikt in softwareontwikkeling (Briand, 2008). In onderstaande paragrafen worden reeds bestaande AI-toepassingen en hun impact op de fases van de SDLC samengevat.

2.2.2.1 AI in fase 1: analyse en planning

Deze fase omvat verschillende aspecten. Naast de benodigde tijd en budget moeten ook de resources en risico’s worden geanalyseerd (Gonsalves, Yamagishi, Kawabata, & Itoh, 2010). Een accurate en correcte inschatting van de benodigde resources heeft een impact op het verdere verloop van het softwareproject (Srinivasan & Fisher, 1995). Een onderschatting kan leiden tot een verhoogde druk op de softwareontwikkelaars wat op zijn beurt kan leiden tot een lagere kwaliteit van de software (Srinivasan & Fisher, 1995). Een overschatting kan leiden tot een te veel aan resources (Srinivasan & Fisher, 1995). Dit brengt onnodige kosten met zich mee (Srinivasan & Fisher, 1995). Naarmate softwareprojecten doorheen de jaren steeds groter en belangrijker werden, werd het ook complexer om het budget en de benodigde resources accuraat in te schatten (Baskeles et al., 2008). Om de accuraatheid van deze schattingen te verbeteren, stelden wetenschappers reeds in 1990 voor om ML te hanteren (Wen, Li, Hu, & Huang, 2012). Het grootste voordeel van ML is dat ze steeds nieuwe data opnemen waardoor de analyses omtrent bovenstaande vermelde factoren accurater worden (Baskeles et al., 2008). ML-systemen zijn dus adaptief en daarnaast ook niet-parametrisch (Srinivasan & Fisher, 1995). Wen et al. (2012) concludeerden in hun onderzoek dat de accuraatheid van de software planning in het algemeen effectief hoger ligt bij gebruik van ML.

2.2.2.2 AI in fase 2: definiëren van de vereisten

Het opstellen van de softwarevereisten omvat vier fases: analyse, formulering, documentatie en verificatie (Iqbal, Elahidoost, & Lúcio, 2018). Uit de wetenschappelijke literatuur blijkt dat er reeds verschillende AI-technieken bestaan die deze fase kunnen ondersteunen. De grootste bijdrages situeren zich in volgende domeinen:

- Het ondubbelzinnig maken van vereisten en deze automatisch vereenvoudigen (Sorte, Joshi, & Jagtap, 2015).

- Computationele intelligentie gebruiken om vaak voorkomende problemen omtrent de vereisten op te lossen, zoals het prioriteren van de vereisten of onvolledige vereisten (Sorte et al., 2015).

De formulering van de vereisten vergt veel resources en is een belangrijke stap om de kwaliteit van de software te garanderen (Iqbal et al., 2018). Zwermintelligentie kan hier gehanteerd worden. Zwermintelligentie linkt softwaredocumenten aan de hand van kernwoorden en hun context (Sorte et al., 2015). Deze technologie werkt aan de hand van een gedecentraliseerd systeem van individuele agenten (Sorte et al., 2015). De collectieve inbreng van deze agenten verduidelijkt relaties tussen documenten waardoor vereisten efficiënter kunnen opgesteld worden (Sorte et al., 2015).

Het prioriteren van de softwarevereisten is een strategisch proces (Perini, Susi, & Avesani, 2013). Het probleem omtrent het prioriteren van softwarevereisten komt neer op het rangschikken van de set van gewenste functionaliteiten, dit in overweging met enkele business aspecten (zoals marktcompetitie, reglementeringen of klantentevredenheid) of technische aspecten (zoals ontwikkelingskosten en –risico’s) (Perini et al., 2013). Het gebruik van ML bij deze taak brengt enkele voordelen met zich mee. ML-technieken maken gebruik van domeinkennis en zijn daarnaast adaptief (Perini et al., 2013). Hierdoor kan de menselijke input verminderd worden, terwijl de accuraatheid van de gerangschikte vereisten behouden blijft of zelfs verbetert (Perini et al., 2013).

Martinez & Cano (2010) stellen in hun onderzoek een Bayesian network voor om vereisten te verifiëren. Het Bayesian network stelt vast indien een vereiste voldoende duidelijk omschreven is (Martinez & Cano, 2010). De technologie is gebaseerd op verschillende bronnen zoals rapporten, standaarden en interactie met experten (Martinez & Cano, 2010).

2.2.2.3 AI in fase 3: definiëring architectuur en design

Het maken van het design vergt technische kennis en ervaring. Normalerwijze hanteert een softwareontwerper een trial-and-error methode tot hij de gewenste oplossing bekomt (Sorte et al., 2015). Sorte et al. (2015) stellen in hun rapport een AI-tool voor dat als

Bij het ontwikkelen van het design kan gebruik gemaakt worden van patronen (Ferenc, Beszedes, Fulop, & Lele, 2005). Indien patronen correct gebruikt worden, leidt dit tot een hogere herbruikbaarheid van software (Ferenc et al., 2005). Daarnaast zorgt dit er ook voor dat de software makkelijker te onderhouden valt (Ferenc et al., 2005). Het probleem bij traditionele systemen is dat deze te permissief zijn (Ferenc et al., 2005). Dit omwille van het feit dat bepaalde patronen erg op mekaar lijken. Ferenc et al. (2005) stellen in hun onderzoek een methode voor, genaamd Columbus, die patronen kan minen. Aan de hand van ML worden accuratere patronen weergegeven. Deze methode houdt telkens rekening met de implementatie van patronen in hun omgeving (Ferenc et al., 2005).

2.2.2.4 AI in fase 4: productontwikkeling

Zoals vermeld in sectie 2.1.5 vergt het programmeren van software een significante kennis van het probleemdomein, een diepgaand inzicht van wat men uitvoert en specifieke programmeervaardigheden (Danilchenko, 2011). Wetenschappers stelden zich snel na het ontstaan van software de vraag indien dit proces kon geautomatiseerd worden (Danilchenko, 2011). Hoewel dit initieel een uitdaging bleek, bestaan er verschillende benaderingen. Deze staan algemeen bekend als Automatic Code Generation (ACG) (Danilchenko, 2011). In zijn onderzoek stelt Danilchenko (2011) zo een ACG voor. Het systeem werkt aan de hand van AI methodologieën, namelijk Case-Based Reasoning, Routine Design en Template-Case-Based Programming. Het doel van dit systeem is om routinematige taken uit te voeren die normaal menselijke intelligentie vergen (Danilchencko, 2011). Automatic Code Generation (ACG) zorgt ervoor dat softwareontwikkelaars beknoptere, duurzamere, simpelere en meer herbruikbare oplossingen kunnen creëren (Danilchenko, 2011). Uit onderzoek blijkt dat de productiviteit van softwareontwikkelaars hierdoor aanzienlijk verbetert (Danilchenko, 2011).

2.2.2.5 AI in fase 5: software testing

Ten slotte worden AI-technieken ook gebruikt bij het testen van software. Software testing staat in voor meer dan 50% van de ontwikkelingskosten van een softwareproject (Kosmatov, 2010). Aangezien softwaresystemen steeds complexer en duurder worden, stijgt de nood voor automatische softwaretestsystemen (Noorian et al., 2011). Onderzoeken tonen aan dat het gebruik van ML een veelbelovende manier is om

software testing te automatiseren (Noorian et al., 2011). Deze technieken drukken zowel de kosten als de benodigde tijd en verhogen de performantie van het testproces (Noorian et al., 2011).

ML kan in verscheidene stadia van het software testing proces geïmplementeerd worden. Noorian et al. (2011) halen drie categorieën aan: test planning, test case management en debugging. Tijdens het plannen van de testen kan ML gebruikt worden om de benodigde testtijd te voorspellen (Noorian et al., 2011). In test case management kunnen deze technieken gebruikt worden om reeds bestaande testreeksen te verfijnen. Dit proces wordt ook wel het herontwikkelen van testcases genoemd en is bedoeld om limitaties of eventuele overbodigheden bij testcases te ontdekken (Noorian et al., 2011). ML kan ook gebruikt worden bij software debugging. Software debugging is het proces waarbij fouten in het programma exact worden gelocaliseerd en opgelost (Noorian et al., 2011). Software bugs komen vaak voor en het is tijdsrovend om ze op te lossen (Elmishali, Stern, & Kalech, 2018). Het grootste deel van de codeerfouten situeren zich bij het programmeren van onbekende of complexe code (Elmishali et al., 2018). Briand (2008) stelt in zijn onderzoek een methode voor die werkt aan de hand van een decision tree algoritme dat potentiële bugs in het softwaresysteem kan analyseren en localiseren zodanig het debugging proces te verkorten. Daarnaast bestaan ook verscheidene technieken om bugs te voorspellen. ML is hier ook toepasselijk voor (Hammouri & Alnabhan, 2018). De mogelijkheid om softwarefouten te voorspellen leidt tot een hogere softwarekwaliteit, betrouwbaarheid en vermindert de ontwikkelingskosten (Hammouri & Alnabhan, 2018). Daarnaast zorgt het voorspellen van bugs ervoor dat software adaptiever wordt (Hammouri & Alnabhan, 2018).

Elmishali et al. (2018) stellen in hun onderzoek een paradigma voor, genaamd Learn, Diagnose and Plan. Dit paradigma heeft als doel om software bugs sneller op te lossen. Het paradigma bestaat uit drie AI-technologieën. Ten eerste wordt ML gebruikt om inzichten te verkrijgen in de code en in voorgaande fouten (Elmishali et al., 2018). Zo

3. Methodologie

3.1 Afbakening onderzoeksdomein

AI-tools worden reeds een aantal jaren gebruikt om softwareontwikkeling te verbeteren (Meziane & Vadera, 2010). Gartner (2017) voorspelt dat meer dan 40% van de applicatieontwikkelingsprojecten tegen 2022 enige vorm van AI zal gebruiken. Dit onderzoek gaat over de mate waarin AI een impact kan hebben in low-code softwareontwikkeling. Er bestaat reeds wetenschappelijke literatuur omtrent de impact van AI-tools op high-code softwareontwikkeling (zie sectie 2.1.4). Zoals vermeld in de Introductie is er echter een gebrek aan wetenschappelijk onderzoek naar de impact van AI op low-code softwareontwikkeling.

Tisi et al. (2019, p.2) omschrijven LCDPen als volgt: “software development platforms on the cloud, provided through a Platform-as-a-service-model, that allows users to build completely operational applications by interacting through dynamic graphical user interfaces, visual diagrams and declarative languages”. Bedrijven die operationeel zijn in de low-code markt bieden hun klanten een allesomvattende omgeving aan voor softwareontwikkeling (Mossou, 2019). Low-code softwareontwikkeling maakt het zo mogelijk voor mensen zonder programmeerervaring, genaamd citizen developers in low-code jargon, om applicaties te ontwikkelen (Tisi et al., 2019).

Een global onderzoek waarbij 1000 IT verantwoordelijken en business stakeholders met besluitvormingsverantwoordelijkheden omtrent bedrijfstechnologie werden ondervraagd, vertoonde de volgende resultaten: 77% van de IT verantwoordelijken en 71% van de business stakeholders waren akkoord met het statement dat zowel de IT als de business kant van bedrijven kampen met onvervulde wensen omtrent softwareontwikkeling (Mossou, 2019). De organisaties die een LCDP aanbieden, stellen dat low-code deze leemte tussen de vraag en de capaciteit om applicaties te bouwen kan opvullen (Mossou, 2019). Applicaties kunnen immers sneller gebouwd worden aan de hand van low-code in vergelijking met traditionele ontwikkelingsmethoden (Mossou, 2019).

De afbakening rond LCDP komt dus voort uit het feit dat deze platformen steeds meer gebruikt worden. In een rapport stelde Gartner (2017), een wereldwijd onderzoeks- en

adviesbureau in de informatietechnologiesector, dat tegen 2024 meer dan 65% van activiteiten omtrent applicatieontwikkeling zal gebeuren aan de hand van low-code. De bestaande AI-tools op LCDP zijn geïmplementeerd in de productontwikkelingsfase van de SDLC. In dit onderzoek werd dusdanig onderzocht in welke mate AI een impact heeft op de productontwikkelingsfase op LCDP.

3.2 Onderzoeksvraag

Op basis van bovenstaande afbakening werd volgende onderzoeksvraag geformuleerd: o In welke mate kan artificiële intelligentie de productontwikkelingsfase op

low-code development platformen verbeteren?

Om deze onderzoeksvraag te beantwoorden, zullen volgende deelvragen worden onderzocht:

o Zorgt AI op low-code development platformen voor een hogere productiviteit van een softwareontwikkelaar?

o Zorgt AI op low-code development platformen ervoor dat data-integraties makkelijker uit te voeren zijn?

o Zorgt AI op low-code development platformen ervoor dat applicatie-integraties makkelijker uit te voeren zijn?

o Zorgt AI op low-code development platformen ervoor dat software security beter te beheren is?

o Zorgt AI op low-code development platformen ervoor dat softwareontwikkelaars een sneller leerproces omtrent softwareontwikkeling doormaken?

o Zorgt AI op low-code development platformen ervoor dat softwareontwikkelaars meer inzichten verkrijgen in de software?

o Zorgt AI op low-code development platformen ervoor dat softwareontwikkelaars minder fouten maken?

3.3 Wetenschappelijke relevantie

Het doel van dit onderzoek is om een wetenschappelijke bijdrage te leveren in verband met de invloed van AI op softwareontwikkeling op LCDP. Hoewel de zoekterm artificial intelligence op Web of Science 52233 resultaten oplevert, behoort het grotendeel van deze resultaten niet tot de scope van dit onderzoek, aangezien het grootste deel van onderzoeken in verband met artificiële intelligentie vaak technisch benaderd wordt. Een combinatie van de zoektermen artificial intelligence en software development levert 1203 resultaten op, maar ook hier geldt het feit dat veel resultaten niet tot de scope van dit onderzoek behoren. Vervolgens levert de zoekterm low-code development op Web of Science slechts 27 resultaten op. Echter blijkt maar een van deze resultaten effectief gedetailleerd in te gaan op LCDPen. Geen enkel artikel kan teruggevonden worden in verband met de invloed van AI op softwareontwikkeling op LCDP.

3.4 Maatschappelijke relevantie

Om aan de vraag te voldoen van een steeds meer gedigitaliseerde klant moeten softwarebedrijven in staat zijn om snel kwalitatieve producten te leveren (Milovanov, 2020). Traditionele softwareontwikkeling is niet voldoende geschikt om te voldoen aan de eisen van de klanten (Milovanov, 2020). AI zorgt ervoor dat deze traditionele manier ontwricht wordt door schaalbare en efficiëntere workflows te creëren waardoor de productiviteit opgedreven wordt en de time-to-market verlaagd wordt (Milovanov, 2020). AI zorgt er dus voor dat er betere applicaties kunnen ontwikkeld worden in dezelfde omstandigheden als voordien (Clarion Technologies, s.d.).

Een rapport van Deloitte (2020) stelt dat veel bedrijven overheen de voorbije twee jaar enige soort van AI-tools hebben geïmplementeerd om software efficiënter te ontwikkelen. Deze markt blijft dan ook groeien, stelt het rapport. Zo verwacht Deloitte (2020) dat AI-assisted development tools steeds belangrijker zullen worden door de groeiende vraag naar software. Begrijpen hoe en in welke mate softwareontwikkeling kan veranderd worden door AI is dus essentieel, aangezien de interesse in het domein blijft stijgen (Clarion Technologies, s.d.).

Een onderzoek van Teradata (2017), een leverancier van software, wijst uit dat 91% van de softwarebedrijven die AI implementeert, verwacht dat zij hierbij verscheidene barrières

zullen tegenkomen. Iets meer dan 30% van de respondenten in dit onderzoek haalde aan dat onvoldoende kennis in verband met AI of het onvoldoende begrijpen van de specifieke impact van AI de grootste barrière zal vormen.

3.5 Onderzoeksprocedure

De vooropgestelde onderzoeksvraag en deelvragen uit sectie 3.2 werden onderzocht aan de hand van een tweedelig kwalitatief onderzoek. In het eerste deel van het onderzoek werden diepte-interviews afgenomen bij drie software-experts. Deze diepte-interviews werden op een semi-gestructureerde manier afgenomen. Het doel van deze diepte-interviews was om vastgestelde problemen en barrières van de productontwikkelingsfase af te toetsen bij software-experts. Deze pijnpunten werden vooraf opgesteld op basis van een onderzoek in de wetenschappelijke literatuur (sectie 2.1.5) en in overleg met de promotor. Op deze manier konden de software-experts bevestigen of ontkennen wat effectief pijnpunten zijn in deze fase van de SDLC. Deze informatie was immers niet omvangrijk genoeg terug te vinden in de wetenschappelijke literatuur. In zo een situatie kunnen diepte-interviews met experts een oplossing bieden aangezien deze personen een diepgaande kennis hebben over het betreffende onderwerp (Bogner, Littig, & Menz, 2009). Ten slotte hadden de geïnterviewde experts ook de mogelijkheid om de voorgelegde lijst met pijnpunten aan te vullen. De verzamelde data werden geanalyseerd en gestructureerd aan de hand van coderingen. Zo kon een beter overzicht verkregen worden van de verzamelde data. De resultaten van deze diepte-interviews zijn terug te vinden in sectie 4.1.

In het tweede deel van het onderzoek werden casestudies uitgevoerd. In het totaal werden twee cases onderzocht, namelijk MxAssist en OutSystems.ai. De keuze voor deze cases wordt verklaard in sectie 3.8. Allereerst werd een diepte-interview uitgevoerd met zowel de AI productmanager van Mendix als deze van OutSystems. In deze diepte-interviews werd afgetoetst op welke pijnpunten, die werden vastgesteld in het eerste deel van dit onderzoek, de geïmplementeerde AI-tool inspeelt. Om deze data te verzamelen

Vervolgens werden deze resultaten afgetoetst bij low-code softwareontwikkelaars van Mendix en OutSystems. Zo kon een beeld geschetst worden indien softwareontwikkelaars ook effectief ervaren waar de AI voor bedoeld is. Met andere woorden, als de AI effectief teweegbrengt wat theoretisch vooropgesteld wordt. De respondenten werden bereikt door het rechtstreeks contacteren van Belgische en Nederlandse partners van Mendix en OutSystems via mail. Respondenten kregen een vooraf vastgelegde vragenlijst doorgestuurd. De respondenten hadden de mogelijkheid om enige context te schetsen bij hun antwoorden. In totaal reageerden 7 Mendix softwareontwikkelaars en 4 OutSystems softwareontwikkelaars. De responsgraad bij de Mendix case was 13%. De responsgraad bij de OutSystems case was 24%.

3.6 Motivatie onderzoeksprocedure

Dit onderzoek werd uitgevoerd aan de hand van kwalitatieve onderzoeksmethoden. Kwalitatieve onderzoeksmethoden worden steeds meer gebruikt in studies naar computersystemen en informatietechnologieën (Kaplan & Maxwell, 2005). Wetenschappers en IT-specialisten stellen namelijk problemen vast bij het kwantificeren van technische zaken in het IT-veld (Kaplan & Duchon, 1988). Kaplan & Duchon (1988) halen hieromtrent aan dat er bij het kwantificeren van data soms bepaalde informatie verloren gaat waardoor onderzoekers perspectieven ontgaan. Kwalitatieve onderzoeksmethoden spelen in op deze problemen. Aan de hand van kwalitatief onderzoek kunnen inzichten verkregen worden in verband met welke specifieke factoren effectief verder onderzocht kunnen worden (Kaplan & Maxwell, 2005). Daarnaast is het bij kwalitatief onderzoek mogelijk om naast de kernzaken ook contexten te verzamelen (Kaplan & Maxwell, 2005). Hierdoor kunnen de voordelen van technologieën naar de mens toe soms beter worden geschetst (Kaplan & Maxwell, 2005). Ten slotte zijn kwalitatieve onderzoeken ook geschikt om evoluerende processen te bestuderen (Kaplan & Maxwell, 2005).

Kwalitatief onderzoek kan aan de hand van verschillende methoden uitgevoerd worden. Het eerste deel van dit onderzoek werd uitgevoerd aan de hand van diepte-interviews, een vaak gehanteerde kwalitatieve methode (Mack, Woodsong, MacQueen, Guest, & Namey, 2005). Diepte-interviews worden ook wel face-to-face interviews genoemd (Mack et al., 2005). Het doel van diepte-interviews is om individuele perspectieven en ervaringen

te verzamelen rond de vooropgestelde vragen (Mack et al., 2005). Daarnaast kan de interviewer eventueel bijkomende vragen stellen om waardevolle informatie te verzamelen (Mack et al., 2005).

Het tweede deel van dit onderzoek werd gevoerd aan de hand van casestudies. Yin (2011) omschrijft een case als een entiteit, een individu of een analyse-eenheid. Casestudies zijn in het bijzonder interessant wanneer men een specifiek probleem of domein wil onderzoeken en hierover informatie uit verschillende rijke bronnen kan verzamelen (Patton, 1988). Anderson & Arsenault (1998) vult hierbij aan dat casestudies een goede manier zijn om bepaalde vooropgestelde factoren te onderzoeken aangezien verschillende cases tegenover mekaar kunnen worden afgewogen. In dit onderzoek werden de LCDPen als cases gehanteerd (sectie 3.8). Het gebruik van casestudies in dit onderzoek laat toe om de omgeving en activiteiten van softwareontwikkelaars te onderzoeken aan de hand van verschillende bronnen zodanig correcte resultaten te bekomen (Noor, 2008).

3.7 Evaluatiecriteria

Om de algemene betrouwbaarheid en correctheid van een kwalitatief onderzoek te garanderen, moet het onderzoek worden afgetoetst aan de onderstaande evaluatiecriteria (William, 2004).

3.7.1 Betrouwbaarheid

De betrouwbaarheid van het eerste deel van dit onderzoek werd gegarandeerd door het afnemen van interviews bij meerdere software-experts aan de hand van een vooraf opgesteld interviewprotocol. Zowel de respondent als de onderzoeker hadden tijdens het interview de mogelijkheid om dieper in te gaan op bepaalde aspecten. De betrouwbaarheid van de diepte-interviews met de AI productmanagers werd op dezelfde manier gegarandeerd. Om de betrouwbaarheid van de interviews via mail te waarborgen, werd gepeild naar persoonlijke meningen en percepties.

van Mendix als van OutSystems. Vervolgens werden deze resultaten voorgelegd aan softwareontwikkelaars die de onderzochte AI-tools in praktijk gebruiken. Zo konden overeenkomsten of eventuele tegenstrijdigheden worden vastgesteld.

3.7.3 Externe validiteit

De grootste beperking van dit onderzoek is het feit dat er tot vandaag maar twee LCDP bestaan die AI hebben geïmplementeerd in de softwareontwikkelingscyclus. Beide cases werden dan ook onderzocht in dit onderzoek. Het onderzoek zou echter van hogere kwaliteit zijn indien meerdere cases konden onderzocht worden. Om de externe validiteit beter te waarborgen werden de resultaten van de diepte-interviews met de AI productmanagers afgetoetst met de percepties van low-code softwareontwikkelaars.

3.8 Cases

Om een doorgronde keuze te kunnen maken in verband met mogelijke cases was het noodzakelijk om eerst en vooral een overzicht te verkrijgen van alle bestaande LCDPen. Hiervoor werd gebruik gemaakt van het magische kwadrant voor LCDPen uit 2019, opgesteld door Gartner. Hieruit bleek dat er tot nu toe 18 low-code platformen bestaan. Geen enkel platform dat gesitueerd is in het niche players, challengers of visionaries kwadrant gebruikt enige vorm van AI op het platform tot op heden. In het leaders kwadrant bestaan er wel verschillende platformen, namelijk Salesforce, Appian en Microsoft Power Apps, waarbij AI kan geïmplementeerd worden in applicaties. Echter konden deze platformen niet gebruikt worden in dit onderzoek aangezien AI niet als ondersteunende tool geïmplementeerd is in het softwareontwikkelingsproces. Enkel platformen die AI gebruiken in het softwareontwikkelingsproces waren geschikt voor dit onderzoek. De enige twee platformen die hieraan voldeden waren enerzijds Mendix en anderzijds Outsystems.

3.8.1 Mendix

Mendix is een Nederlands softwarebedrijf. Het hoofdkantoor van Mendix is gevestigd in Rotterdam. Mendix biedt een LCDP aan waar gebruikers applicaties kunnen ontwikkelen in twee verschillende omgevingen: Mendix Studio en Mendix Studio Pro (Mossou, 2019). Mendix Studio is gecreëerd voor mensen die geen programmeerervaring hebben. Dit is de no code (visueel modeleren) omgeving. Mendix Studio Pro is de low-code (visueel modeleren en coderen) omgeving voor de meer ervaren gebruikers.

In 2018 werd een AI-tool toegevoegd aan zowel Mendix Studio als Mendix Studio Pro (Mossou, 2019). Deze tool staat bekend als Mendix Assist (MxAssist). MxAssist kan

(Mossou, 2019). De AI-assisted development tool heeft een accuraatheid van meer dan 90%.

3.8.2 OutSystems

OutSystems is een softwarebedrijf dat in 2001 werd opgericht in Lissabon, Portugal. Het hoofdkantoor van OutSystems is gevestigd in Boston. Het bedrijf biedt een LCDP aan dat

bedrijven tools aanreikt om omnichannel bedrijfsapplicaties te maken.

Softwareontwikkelaars kunnen dit doen op een geïntegreerde ontwikkelingsomgeving dat de volledige SDLC omvat.

Eind 2018 introduceerde OutSystems een AI-tool, OutSystems.ai. Het doel van deze AI is om het softwareontwikkelingsproces efficiënter te maken en ervoor te zorgen dat softwareontwikkelaars minder repetitieve taken moeten uitvoeren zodat zij zich kunnen concentreren op creatieve zaken. OutSystems.ai assisteert de softwareontwikkelaar bij het opzetten van applicatieflows door een mogelijke volgende stap aan te raden (OutSystems, s.d.). Deze voorspellingen zijn gebaseerd op de analyse van meer dan 15 miljoen patronen en applicatieflows en zijn telkens geconfigureerd en aangepast aan de ontwikkelingsomgeving van de softwareontwikkelaar (OutSystems, s.d.).

4. Resultaten

4.1 Software-experts

Over het algemeen bleken de software-experts het eens over de voorgelegde complexiteiten of problemen die zich kunnen voordoen in de productontwikkelingsfase. Vervolgens worden de resultaten gedetailleerd besproken.

De productiviteit van een softwareontwikkelaar kan in bepaalde situaties zeker naar een hoger niveau getild worden (SE1, SE2, SE3). Zo beweerde software-expert 2 het volgende: “… vaak heb je in ontwikkeltrajecten dat er heel wat externe factoren, …, zijn waarin je moet samenwerken en hier komen vaak technische problemen voor die niet 100% duidelijk waren in het begin. Hierdoor blijkt dat wat een softwareontwikkelaar normaal op een paar dagen, uren of weken kon implementeren, hier toch een tijd langer over doet dan voorzien omdat hij vast komt te zitten op onvoorziene zaken.”.

Alle drie de respondenten stelden dat er vandaag de dag nog veel fouten worden gemaakt in softwareontwikkeling. Zo stelde software-expert 2 stelde dat “…er zowel in klassieke softwareontwikkeling als in low-code softwareontwikkeling nog heel veel fouten worden gemaakt.”.

Vervolgens stelden de respondenten dat het aanleren van de vaardigheden omtrent softwareontwikkeling en het begrijpen van achterliggende logica’s een moeilijk en langdurig proces is (SE1, SE2, SE3). Software-expert 2 ging wat dieper in op deze factoren: “Ten eerste is de taal leren een enorme barrière die ondertussen wel kleiner en kleiner wordt, …. Maar hoe eenvoudiger de taal wordt, en dat zie ik ook heel vaak gebeuren in het low-code verhaal,…, hoe minder de developers echt weten wat er achter de schermen gebeurt.”.