Overslaan en naar de inhoud gaan

Complexiteitsexplosie beheersbaar

Wat voor impact heeft complexiteitsgroei op ons dagelijks leven? Worden wij kwetsbaarder? Wat zijn de consequenties van eventueel falende systemen? Wat kunnen we doen? Is er reden voor bezorgdheid? Is toenemende complexiteit eigenlijk wel een probleem?
Tech & Toekomst
Shutterstock
Shutterstock

Vragen die niet één, twee, drie te beantwoorden zijn. Daarvoor moeten we onder meer kijken naar de oorzaken van complexiteitsgroei, de effecten op (de ontwikkeling) van complexe systemen, en uiteraard de mogelijke maatregelen om complexiteit te beheersen. Ten eerste de oorzaken van complexiteitstoename. Een van de hoofdoorzaken is de groeiende omvang van de software in systemen. Softwaresystemen groeien snel. Grote Europese bedrijven als Nokia, Thales, Bosch en Philips publiceren regelmatig de groei van de hoeveelheid en complexiteit van hun software. De algemene trend laat bijvoorbeeld zien dat de hoeveelheid regels code in producten ongeveer ieder jaar verdubbeld. Een ander voorbeeld: in 2002 waren er meer dan 6000 wijzigingen in de specificaties voor UMTS. Iedere wijziging betekent een hoeveelheid softwareontwikkeling en vereist tevens een acceptatietest. Het feit dat nieuwe systemen steeds meer functionaliteit hebben en dat deze functionaliteit in een sterk groeiende hoeveelheid software zit, zorgt ervoor dat de complexiteit van deze software groeit. Software blijkt het ideale ‘productiemateriaal’ te zijn, omdat software de mogelijkheid biedt voor snelle en nieuwe functionaliteit en tegelijkertijd nog relatief goedkoop is ook. Immers, materiaalkosten per product zijn er voor software niet. Extra functionaliteit in hardware maakt de materiaalkosten hoger, extra functionaliteit in software laat de materiaalkosten onveranderd. Naast de toenemende functionaliteit, worden systemen steeds meer aan elkaar gekoppeld en worden ze geacht met elkaar te kunnen samenwerken. Het moge duidelijk zijn dat dit eisen stelt aan deze systemen en zorgt voor een toenemende complexiteit. Deze trend lijkt zich vooralsnog door te zetten. Het ITEA-symposium op 7 en 8 oktober dit jaar, waar de Europese industrie haar onderzoeksontwikkelingen uitwisselde, liet dit wederom duidelijk zien. De ontwikkelingen zijn nog lang niet gestopt. Auto’s bevatten onderhand zoveel elektronica en software dat er dringend actie nodig is om deze systemen te integreren en de interne communicatie te standaardiseren. Een auto die te water gaat is tegenwoordig total loss omdat het vervangen van de beschadigde elektronica duurder is dan een nieuwe auto. Mobiele telefoons ontwikkelen zich tot een persoonlijke assistent waarmee over niet al te lange tijd alle huishoudelijke apparatuur (ook op afstand) kan worden bediend. En voetbalsupporters die zich misdragen worden met gezichtsherkenning geïdentificeerd en uit het stadion geweerd. Kortom, de mogelijkheden van de technologie en de gebruiksmogelijkheden in het dagelijkse leven groeien nog steeds en zorgen voor een toenemende complexiteit. Deze trend zal zich nog wel even voortzetten. Wie een idee wil krijgen over hoe technologie in het dagelijkse leven kan worden toegepast moet eens een kijkje nemen bij ‘Living Tomorrow’, direct naast de Amsterdam Arena. Hier blijkt hoe moeilijk het is om je als ICT’er voor te bereiden op de toekomst, omdat die maar zeer beperkt voorspeld kan worden. De enige mogelijke voorbereiding is je niet te verbazen over de technologische mogelijkheden en ontwikkelingen. Meer geld Ten tweede de consequenties voor het ontwikkelen van complexe systemen. Deze systemen moeten immers gemaakt worden. De toenemende eisen aan systemen betekenen een toenemende inspanning om deze systemen te bouwen. Daarnaast zorgt de groeiende complexiteit voor een toename van de kwaliteitsinspanningen voor deze systemen. Procesbeheersing wordt steeds belangrijker. Het expliciet specificeren van het systeem en het testen van deze systemen legt daarnaast een toenemend beslag op de beschikbare middelen. Als er één belangrijk risico is voor de kwetsbaarheid van systemen is het wel de druk op het proces. Ondanks de toenemende eisen en complexiteit moeten systemen (en dus ook de software in die systemen) steeds sneller gebouwd worden. Daardoor is de kans groot dat er te weinig tijd gestoken wordt in het waarborgen van systeemkwaliteit en het testen van deze systeemkwaliteit. Toenemende functionaliteit en complexiteit vragen om meer inspanning en dus meer geld. De toenemende afhankelijkheid zorgt daarnaast nog eens voor toenemende eisen aan de kwaliteit. Deze trend lijkt zich niet te kunnen continueren binnen de huidige financiële budgetten van organisaties. Toenemende eisen zijn een gegeven. De bereidheid om hier in eenzelfde mate voor te betalen staat ter discussie. Het lijkt dus voor de hand te liggen dat er nieuwe modellen voor systeemontwikkeling moeten komen, die in staat zijn om hier mee om te gaan. Ondanks het belang dat aan kwaliteit wordt toegekend, blijkt kwaliteit toch altijd weer een ondergeschoven kindje ten opzichte van tijd en geld. Wanneer in de praktijk onvoldoende tijd en geld beschikbaar zijn, is de kans groot op slechte en slecht geteste software, met alle gevolgen van dien. Ontwikkelaars worden namelijk beloond voor het op tijd klaar hebben van functionaliteit. De rest komt, ondanks de goede bedoelingen, toch altijd weer op de tweede plaats. Gelukkig komen er steeds meer hulpmiddelen om hier een oplossing voor te bieden. Het genereren van software uit UML-modellen (ook voor embedded systemen) en het automatisch genereren van testsoftware uit deze modellen zal in de toekomst een feit worden. Demonstratieopstellingen waarin dit slaagt zijn al beschikbaar. Naast UML 2.0 zal de internationale standaard TTCN-3 voor geautomatiseerd (en gegenereerd) testen ook een belangrijke rol kunnen gaan vervullen. Deze laatste (TTCN-3) is veelbelovend. TTCN-3 is een van oorsprong uit de Telecom afkomstige standaard voor geautomatiseerd testen. TTCN-3 bevat een testtaal met semantiek en test-specifieke concepten zoals formele verificatie, resultaatafhankelijke testscripts én het geven van een echt oordeel over het geteste systeem. Vooral voor systemen die vaak herhalend moeten worden getest, bijvoorbeeld na wijzigingen, is de business case een ‘no-brainer’ (je hoeft niet slim te zijn om te begrijpen dat hierdoor veel tijd en geld wordt bespaard). Kortom, de toenemende complexiteit stelt eisen aan de manier waarop software wordt gemaakt. Tegelijkertijd zijn veelbelovende oplossingen voorhanden of komen beschikbaar. Oplossingen Tot slot de mogelijke maatregelen om complexiteit te beheersen. Diverse opties zijn beschikbaar om complexiteit in de hand te houden of te verkleinen. Standaardisatie van architecturen, interfaces en componenten bijvoorbeeld. Standaardisatie zorgt voor harde afspraken rond communicatie en afbakening waardoor functies die voorheen onderdeel van de complexiteit uitmaakten, als black box mogen worden beschouwd. Decompositie via standaardisatie (hiërarchisch of gelaagd) zorgt eveneens voor duidelijkheid en werkt complexiteitsverlagend. Die trend zien we al een tijdje voor software. Het gebruik van standaardsoftware of pakketsoftware draagt bij aan complexiteitsbeheersing. Daarnaast komen middlewareoplossingen beschikbaar die helpen om technische platformen en toepassingen van elkaar gescheiden te houden. Middleware kan daarbij uit verschillende lagen worden opgebouwd, zodat ook daar de complexiteit deels een halt wordt toegeroepen. Kortom, de omvang en afhankelijkheid van software en systemen nemen snel toe, er zijn echter mogelijkheden om dit in de hand te houden. Wel is het zo dat deze hulpmiddelen gebruikt moeten worden en dat zou nog wel eens een probleem kunnen worden. Recent onderzoek toont aan dat de snelheid van innovatie in de software-industrie veel langzamer gaat dan de technologische ontwikkelingen. Met andere woorden: nieuwe technologieën komen wel beschikbaar, maar worden niet of pas na lange tijd gebruikt. Een voorbeeld: de meest gebruikte requirements-engineeringmethode in de praktijk blijkt te zijn: geen methode (50 procent), en de meest gebruikte tools voor requirements engineering en ontwerp blijken: MsWord (45 procent) en MsExcel (10 procent). Dit terwijl veel technologieën al vele jaren beschikbaar zijn om de specifieke complexiteitsvraagstukken voor bijvoorbeeld requirements engineering en design te beantwoorden. Oplossingen zijn voorhanden om de complexiteitsexplosie te pareren, echter het gebruik ervan in de dagelijkse praktijk is nog geen feit. Hier zal meer aandacht aan besteed moeten worden. De bottleneck in innovatie ligt namelijk bij gebruik en inpassing in de praktijk. Gebruik en introductie van nieuwe technologieën voor complexiteitsbeheersing verdienen daarom veel meer aandacht. De veel voorkomende aanname dat goede innovatieve hulpmiddelen zichzelf verkopen, en dus automatisch in de praktijk worden gebruikt, is onjuist. Tijdelijk Bovendien is het nog zo, dat de mens en het menselijke brein uitstekend kunnen omgaan met complexiteit. Als zaken namelijk te complex worden zijn mensen in staat deze complexiteit te beheersen door bijvoorbeeld afbakening, opsplitsing en separate aansturing. Het is daarom te verwachten dat de dreigende ‘complexiteitscrisis’ slechts van tijdelijke aard is. Natuurlijk zullen er voorbeelden komen waarin complexiteit de boosdoener van systeemfalen is. Maar er lijkt geen reden voor acute paniek. Tegelijkertijd betekent het wel dat er werk aan de winkel is. Het is tijd voor actie: via innovatie van werkwijzen en via standaardisatie om complexiteit te reduceren. Inspanningen uit het verleden rond bijvoorbeeld de euro of millenniumwisseling hebben aangetoond dat met doelgerichte actieprogramma’s de ICT-industrie uitstekend in staat is problemen het hoofd te bieden. Ook rond de complexiteitsexplosie van software zal dat het geval zijn, maar we moeten het nog wel doen. Rini van Solingen (rini@vansolingen.nl) is principal consultant bij LogicaCMG en deeltijdlector Quality Management Quality Engineering aan de Hogeschool Drenthe. Met dank aan Wim Groenendaal (principal consultant bij LogicaCMG).Inzicht en overzicht Je kunt je afvragen of complexiteit eigenlijk wel het probleem is waar we ons druk over moeten maken. De mens is namelijk van nature uitermate geschikt om met complexe situaties om te gaan, dus waarom zou dit een probleem zijn? Als we iets weten is het wel dat mensen uitstekend in staat zijn te functioneren in situaties die nu juist niet in algoritmische (als ‘dit’ dan ‘dat’, wanneer ‘zus’ dan ‘zo’) regeltjes te vangen zijn. Het omgaan met dergelijke complexiteit zou dus in principe helemaal geen probleem moeten zijn. Waar hebben we het dan over als we het hebben over complexiteit van ICT? Het lijkt erop dat het gaat om: inzicht en overzicht. Zonder overzicht en zonder inzicht is het lastig te weten wat je moet doen of wat er gaat gebeuren als je ingrijpt. Dit gebrek het label ‘complexiteit’ geven lijkt logisch, terwijl het daar misschien eigenlijk helemaal niet om gaat. Een veelgenoemd voorbeeld zijn de bancaire legacy mainframes. Deze worden complex genoemd, zijn moeilijk te onderhouden en daardoor zijn wijzigingen risicovol. Maar zijn deze systemen nu zo lastig te onderhouden door hun complexiteit, of omdat niemand overzicht of inzicht heeft? Een voorbeeld: • Een puzzel van 1 stukje is al opgelost. • -Een puzzel van 10 stukjes is eenvoudig op te lossen. • Een puzzel van 100 stukjes is redelijk te doen. • -Een puzzel van 1000 stukjes vraagt om een gestructureerde aanpak. • -Een puzzel van 10.000 stukjes is er voor de cracks met veel tijd en geduld. • -Een puzzel van 100.000 stukjes bestaat niet omdat hier geen overzicht over is te krijgen. Dit voorbeeld probeert duidelijk te maken dat overzicht een voorwaarde is om problemen op te lossen. Bij het ontbreken van overzicht wordt het moeilijk, echter het heeft niets met de complexiteit van de puzzel te maken. Daarnaast heeft het inzicht van de puzzelaar een belangrijke invloed: voor een kind van 4 kan een puzzel van 100 stukjes namelijk nog best lastig zijn. Met andere woorden: het herformuleren van het probleem in een inzichtprobleem en een overzichtsprobleem is wellicht een betere zienswijze dan het af te doen als een probleem van (te) grote complexiteit. Overzicht krijg je door modellering en decompositieregels en decompositiestandaarden. Inzicht krijg je door mensen gedegen op te leiden en te leren problemen te reduceren en inzichtelijk te maken. Het opleiden van informatici in een door doorlooptijd gedirigeerde onderwijswereld en de effecten daarvan op de kwaliteit van de uitstroom verdienen dan ook veel meer aandacht. Het gat in kennis en kunde, het gebrek aan inzicht en overzicht, en het tekort aan wiskundige en logische basiskennis van uitstromende studenten ten opzichte van behoeften in de markt zijn verontrustend. Het lijkt zinnig eens inhoudelijk in te gaan op het belang van goede ICT-scholing als voorwaarde voor een succesvolle kenniseconomie.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in