Development

Software-ontwikkeling
lopende band

De software-assemblagestraat

Van uren per functiepunt naar functiepunten per uur

24 maart 2017

Van uren per functiepunt naar functiepunten per uur

Door het automatiseren van de softwareproductie kan de productiviteit omhoog. Toch gebeurt het maar mondjesmaat. Waarom? Wat zijn de tegenkrachten? Aan de andere kant is het een kwestie van tijd. We staan aan de vooravond van een doorbraak. Een situatie waarbij we kunnen spreken van functiepunten per uur in plaats van uren per functiepunt.

Productiviteitsfactoren ontwikkelen zich in de meeste industrieën op een manier waarbij het produceren van een extra product steeds minder kost. De meerkosten voor een extra product in een productielijn nemen dus af.

Het bouwen van de duizendste auto is daarmee goedkoper dan het eerste exemplaar. Voor softwareprojecten geldt deze productiviteitsgroei niet, blijkt uit onderzoek van onder anderen prof. Manny Lehman en de Standish Group. Sterker nog, het realiseren en  inpassen van het duizendste softwareproject in eenzelfde IT-landschap kost meer tijd en geld en levert vaak minder op dan één op zichzelf staand project. Ofwel, softwareontwikkeling wordt beheerst door Lehmans wet van toenemende complexiteit. Deze wetmatigheid is vergelijkbaar met de ‘wet van de toenemende (relatieve) kosten’, waarbij het inzetten van steeds meer middelen leidt tot een steeds lagere opbrengst.

Productiviteitsgroei zoals die gerealiseerd wordt in andere industrieën, lijkt nog ver uit het zicht van de software-industrie. De bouwers van IT-hardware is het wel gelukt om in de afgelopen decennia de kosten van processoren in relatie tot hun capaciteit te verlagen. Deze productiviteitswinst staat bekend als de wet van Moore en stelt dat het aantal transistoren op een computerchip door de technologische vooruitgang elke twee jaar verdubbelt. Ook op het gebied van netwerken is een soortgelijke groei bekend onder ‘de wet van Metcalfe’, waarbij de waarde van het netwerk toeneemt naarmate het netwerk groeit. Twee telefoons in de hele wereld zijn weinig waard, maar als iedereen een telefoon heeft is de waarde gigantisch.

Evolueerbare software, zonder technische schuld, is inmiddels haalbaar.

Onderzoek van de afgelopen jaren (onder andere Universiteit Antwerpen) heeft geleid tot het inzicht dat de snelheid van softwareontwikkeling factoren omhoog kan als een groot deel van de bouw wordt geautomatiseerd. Tot op de dag van vandaag heeft de softwarebranche dit echter niet opgepakt en de gewenste productiviteitstoename niet laten zien.

Voorwaarden

De vraag is, waarom niet? Is het, omdat eigenlijk ‘niemand’ in de software-industrie zit te wachten op een technologische innovatie die het huidige verdienmodel, waarbij in uren wordt afgerekend, onhoudbaar maakt? Of zijn het de werknemers in bedrijven die niet zitten te wachten op innovatie die naast een hogere productiviteit mogelijk ook banenverlies oplevert. Hoe zou een bedrijf eruitzien als de productiviteit met een factor 10 toeneemt? Veel organisaties hebben afgelopen decennia een complete bedrijfsstructuur gebouwd rondom het produceren en aanschaffen van software. Hierin bevinden zich informatiemanagers, architecten, ontwerpers, analisten, bouwers, testers, managers, inkopers. De kans is groot dat een deel van dit bouwwerk dan niet meer nodig is. En de vraag die dan natuurlijk als eerste opkomt is: Welke kalkoen zet zichzelf met kerstmis op het menu? Welke leverancier gaat helpen met een oplossing die een factor 10 goedkoper is en waarmee hij zijn eigen verdienmodel om zeep helpt? Wat moeten we met outsourcingscontracten als blijkt dat het meeste werk gaat zitten in het specificeren en de communicatie met de business en dit het beste ‘on site’ kan?

Welke kalkoen zet zichzelf met kerstmis op het menu?

Dit soort vragen zijn uitingen van een ander vraagstuk, namelijk van de voorwaarden die nodig zijn, om innovatie geadopteerd te krijgen. Bovenstaande en andere vragen zullen dus eerst beantwoord moeten worden voordat de gewenste innovatie doorgang kan vinden.

Natuurlijk is het een kwestie van tijd dat deze manier van softwareontwikkeling op grote schaal haar intrede doet, maar dat werd ook jaren geleden beweerd van de elektrische auto. Een markante uitspraak van de ANWB in de Kampioen van meer dan 118 jaar geleden (1898) illustreert de lange weg: ‘Het is te voorzien, dat het vervoermiddel der toekomst voornamelijk door elektrische drijfkracht zal worden bewogen.’ Pas met de komst van de lithium-ion batterij aan het begin van de eenentwintigste eeuw, een uitgebreid netwerk van laadpalen en subsidies van de overheid, krijgt de elektrische auto een nieuwe kans.

Doorbraak

Inmiddels lijken we op de drempel te staan van een echte doorbraak. Evolueerbare software, zonder technische schuld, met hergebruik en daardoor hoge productiviteit is inmiddels haalbaar. Echter, ook is duidelijk dat – net zoals de elektrische auto – er een worsteling nodig is voordat de technische, bedrijfseconomische en kennisinfrastructuur een kritische massa heeft bereikt die de software-industrie zal transformeren.

Normalized Systems

De term Normalized Systems verwijst naar een theoretisch raamwerk voor de ontwikkeling van evolueerbare informatiesystemen, zoals in 2016 beschreven door Herwig Mannaert, Jan Verelst en Peter De Bruyn. Dit raamwerk is gebaseerd op een analyse van de modulaire structuur van softwarearchitecturen, gebaseerd op concepten zoals stabiliteit uit de systeemtheorie en entropie uit de thermodynamica. Deze modulaire structuur bestaat in programmeertalen uit instanties van constructen, zoals procedures, functies, klassen, services en recentelijk aspecten. Het kader bestaat uit vier principes gerelateerd aan stabiliteit, die aangeven wanneer combinatorische effecten voorkomen. Een combinatorisch effect bestaat wanneer de grootte van een impact van een wijziging aan de software-architectuur afhankelijk is van de grootte van het informatiesysteem. Combinatorische effecten vertegenwoordigen een bijzonder nadelig soort koppeling in softwarearchitectuur. Dergelijke effecten zorgen ervoor dat informatiesystemen tijdens hun levenscyclus moeilijker onderhoudbaar worden naarmate de tijd vordert, tot ze niet meer kostenefficiënt kunnen worden aangepast en uiteindelijk vervangen moeten worden door een informatiesysteem met gelijkwaardige functionaliteit. In deze zin verklaren de principes van Normalized Systems de wet van de toenemende complexiteit van Lehman.

Onafhankelijk

Combinatorische effecten hebben verder een negatieve invloed op andere kwaliteitsfactoren zoals herbruikbaarheid en testbaarheid. De doelstelling is om informatiesystemen te bouwen die geen combinatorische effecten bevatten. Daartoe bevat het theoretisch kader als tweede component vijf elementen, waarmee de basisfunctionaliteit van informatiesystemen gebouwd kan worden. Een applicatie bestaat dan uit N-instanties van deze elementen. Deze instanties zijn geparametriseerde kopieën van de vijf elementen, en kunnen daardoor aangemaakt worden door middel van een soort codegeneratie door softwarerobots, die wordt aangeduid met de term expansie. Hierdoor kunnen applicaties zeer snel ontwikkeld worden. Aangezien van deze elementen kan worden bewezen dat ze geen combinatorische effecten meer bevatten, is ook de applicatie vrij van combinatorische effecten, en dus uiterst evolueerbaar en herbruikbaar. Het theoretisch kader van Normalized Systems is volledig onafhankelijk van programmeertalen, pakketten of frameworks. De elementen kunnen dus in elke technologiecombinatie van programmeertalen, pakketten en frameworks worden gebouwd. Het kader is immers van toepassing op elk systeem bestaande uit modulaire structuren. De essentie is dat systematisch bepaalde ‘fouten tegen evolueerbaarheid’, de combinatorische effecten, uit deze structuren verwijderd worden, waardoor een ‘evolueerbare modulariteit’ ontstaat, los van de technologie.

Op basis van de laatste inzichten is een aanpak ontstaan waarbij uitgekristalliseerde fijnmazige softwarebouwblokjes – analoog aan lego – door softwarerobots in elkaar worden gezet in een software-assemblagestraat. Hoewel deze aanpak niet nieuw is – op de NATO-softwareconferentie in 1968 reeds aangekondigd – en al jaren ‘veelbelovend’ wordt genoemd, bleek deze tot op heden niet duurzaam. Óf het landschap van ‘ontelbare’ bouwblokjes werd onoverzichtelijk werd óf – het andere uiterste – de bouwblokken bleken toch te groot, wat de onderhoudbaarheid en aanpasbaarheid beperkte. Met andere woorden: de introductie van het ontwerp van de bouwblokken- en generatorenaanpak leidde tot problemen (bekend als technische schuld) met de onderhoudbaarheid en aanpasbaarheid of op termijn met de prestaties van het systeem.

Dat verandert als gebruik wordt gemaakt van fijnmazige ‘genormaliseerde’ blokjes die voor een groot deel door softwarerobots kunnen worden gerealiseerd zonder additionele complexiteit die leidt tot technische schuld. Dan ontstaat er een software-assemblagestraat analoog aan een productiestraat zoals gebruikt wordt in andere industrieën. Een dergelijke manier van softwarebouw stelt de bouwers samen met gebruikers in staat om snel software te ontwikkelen door middel van evolutionaire prototyping. Immers de softwarerobots bewaken binnen de architectuur of een nieuw bouwblokje technisch past als een puzzelstukje in het landschap. Deze softwarerobots construeren, in vaktermen ‘expanderen’ (wat ongelijk is aan genereren van code uit functionele specificaties), dan de – automatisch geteste – software.

Softwarerobots bewaken of een nieuw bouwblokje technisch past.

Combineer de bovenstaande aanpak met reeds beschikbare halfproducten, zoals business rule engines, business proces engines en de best practices die zich momenteel vormen rondom continuous delivery pipelines, en er ontstaat een situatie waarbij we kunnen spreken van functiepunten per uur in plaats van de huidige uren per functiepunt.

De aanpak combineert meerdere zaken. Enerzijds is een bepaalde maturiteit ontstaan in de kwaliteit van producten uit de software-industrie, die als een soort halffabricaat kunnen worden ingezet. Anderzijds is een soortgelijke maturiteit ontstaan binnen het wetenschappelijke domein van software, die vrij is van technische schuld met de Normalized Systems Theory (zie kader) en de inzet van de DEMO-methodiek van Jan Dietz (zie http://www.ee-institute.org/) voor het ontwerpen van de organisatie en het standaardiseren van de requirements.

Feitelijk gezien is de aanpak niet meer dan een ‘best of breed’-aanpak, waarbij de lessen van de afgelopen veertig jaar toegepast worden, gecombineerd met wetenschappelijke en praktische inzichten op basis van onderzoek. Dus geen Big Design Upfront, geen megalomane projecten, maar: theoretische onderbouwing, meten, teamwork, verbeteren, klantwaarde leveren en in kleine stapjes vooruit.

Lees meer over Development OP AG Intelligence
3
Reacties
Kitty 27 maart 2017 12:57

Ik heb in 1984 een in Fortan geschreven Cobol-generator geschreven. Om een Cobol-programma te genereren moesten veldnamen, veldlengtes en modulenamen opgegeven worden. Heb ik zelf ook nog enige tijd gebruikt. Werkte wel prettig. En in plaats van eventuele fouten te verbeteren in de programma's hoefden alleen de modules aangepast worden en de programma's opnieuw gegenereerd. Na een paar jaar niet meer gebruikt omdat Cobol niet meer gebruikt werd.

Bas 24 maart 2017 15:49

Die vergelijking met de auto-industrie gaat toch helemaal mank? Het ontwikkelen van een nieuw model kost jaren, het bouwen uren/dagen/weken, maar dat is te vergelijken met het kopiëren van een CD.

Anoniem 24 maart 2017 12:45

Is er 1 voorbeeld waarin dit in de praktijk gewerkt heeft voor een niet triviale oplossing die langer dan een jaar ook echt gebruikt is?

Reactie toevoegen