Onderzoeker bouwt model voor foutloze ICT
Universiteit Twente (UT)-promovendus Eduardo Zambon van het CTIT Instituut voor Telematica en Informatietechnologie is gepromoveerd op een zelf ontwikkeld voorspelmodel. Met het concept wordt modelchecken mogelijk, waardoor er fouten uit systemen worden gehaald en deze systemen gegarandeerd foutvrij zijn.
Modelchecken is iets anders dan het testen van computersystemen. Bij testen kunnen wel fouten getraceerd worden in de systemen, maar het is niet te doen om alle mogelijke foutcombinaties vooraf te voorzien. Met modelchecken, bijvoorbeeld door de inzet van de modelleertool Groove, een geavanceerde wiskundige manier van computersystemen checken, lukt dat wel. Op de Universiteit Twente doet men daar al tien jaar onderzoek naar.
Programmeur op weg helpen
‘We willen de wereld graag vertellen dat we hier heel ver mee zijn en dat het bedrijfsleven, maar ook de overheid, op termijn kan profiteren van ons onderzoek’, vertelt Arend Rensink, professor Software Modelling, Transformation and Verification en begeleider van Eduardo Zambon. ‘We helpen de programmeur op weg, zodat hij straks de betrouwbaarheid van zijn software kan garanderen.’
‘Je moet je voorstellen dat er bij computersystemen oneindig veel geanalyseerd kan worden, het aantal mogelijk scenario’s is niet te overzien’, vervolgt Rensink. ‘Er kan van alles misgaan op manieren waaraan je vooraf niet denkt. Als we nu van alles wat mis kan gaan ook altijd van tevoren een waarschuwing krijgen, dan kunnen we zeg maar de toekomst voorspellen. Dat klinkt misschien heel groots, maar met ons onderzoek kan dat bereikt worden. We hebben dan eigenlijk al de oplossing, voordat het probleem ontstaat en dat is wezenlijk voor betrouwbare software.’
NS, Fyra en Albert Heijn
Als voorbeelden noemt Rensink de NS en de Fyra. ‘Wij hadden de NS kunnen helpen bij het tegengaan van seinstoringen en zelfs met het voorkomen van ongelukken op het spoor. Of kijk naar de huidige problemen met de Fyra, dat hadden we kunnen traceren, want het testen van enkel de besturingssystemen is niet voldoende, dat blijkt.’
Maar ook op andere gebieden speelt volgens Rensink hetzelfde. ‘Zo wordt er bij Albert Heijn altijd wel bier besteld, maar in een bepaalde periode (na carnaval) kwamen er geen bierbestellingen. Er ging toen van alles mis in hun computersysteem, wat direct invloed had op de efficiency van het bedrijf. Hadden wij daar onze analyse op toegepast, dan hadden we deze bug in het systeem er al op voorhand weten uit te halen. Dat scheelt een organisatie een hoop tijd, geld en ergernis. We kunnen dus stellen dat we overal waar computersystemen aan te pas komen, een voorspellend model hebben ontwikkeld. We kunnen dan ook niet wachten er volop in de maatschappij mee aan de slag te gaan.’
Het spijt me, maar ik krijg hier een onbehaaglijk gevoel bij. Het lijkt dat er sprake is van geweldige vooruitgang op het gebied van softwareontwikkeling, maar tegelijkertijd impliceert dit een achteruitgang in zelfstandig en verantwoordelijk denken en handelen, zeker als ik dat afmeet aan de genoemde praktijkvoorbeelden. Straks roept de verantwoordelijke voor de Fyra nog dat hij er niets aan kon doen omdat het systeem van de UT nog niet tot zijn beschikking stond.
Ben er nog niet uit of dit zo'n geweldige ontwikkeling is.
We hebben al meer aankondigingen gezien van de fundamentele wetenschap (dat ik overigens een warm hart toedraag) die de wereld compleet op zijn kop zou zetten.
Een toevoeging aan Rob's commentaar:
1. Eerst maar eens zien wanneer het eerste concrete tool/methode beschikbaar komt voor de massa
2. Is het tool/methode te gebruiken zonder eerst te promoveren, en tot de top van een of ander vakgebied te worden, anders begrijp je de tool/methode niet
Maar ik herinner me voorbeelden genoeg uit het verleden waarbij een dergelijke methode waarschijnlijk het project tot een goed einde zou hebben gebracht.
Dan rest de vraag of de toenmalige besluiten, analyses, bouwers en ontwikkelaars dan wel competent waren? Ik denk van wel, men wist niet beter, dacht alle mogelijkheden in kaart te hebben.
Het voorbeeld met het bestellen van (geen) bier bij AH vindt ik een leuke. Iets meer uitleg had het voorbeeld concreter gemaakt, nl. wat ging er mis, mochten filialen ineens geen bier meer bestellen, kon het systeem niet tegen 'nul' bestellingen etc. Nu er staat dat er van alles mis ging, ben ik wel nieuwsgierig wàt er dan mis ging...
Is het model getest en goed bevonden. ICT foutloos, treinongeluk gebeurd nog steeds. Want dat is meestal de oorzaak van een treinongeluk.
Het grootste probleem van ICT zijn niet de bugs maar de specificaties..
Typische techneut oplossing. Zorgen dat de code perfect is maar niet weten of het wel wordt gevraagd...
Maar misschien is het heel handig ik wacht al tientallen jaren op zo'n model want het werd tientallen jaren geleden ook al aangekondigd...
Mijn inschatting is dat als ik het proefschrift lees, ik een situatie aantref van een kleine schaal, met beperkte vrijheidsgraden in de randcondities en daardoor een haalbaar resultaat. De mening dat je dat kunt opschalen naar een probleem als Fyra (waarvan overigens nog niet vaststaat dat er echt een structureel en onoplosbaar probleem met de treinen is) is waarschijnlijk als de grote beloftes van AI in de jaren 60 en 70: op aannames van schaalbaarheid gebaseerd die eerder geloof zijn dan wetenschap.
"Van *alles* wat mis kan gaan van te voren een waarschuwing krijgen" en dus perfecte software kan, b.v. als je in een functionele taal gaat werken. Wel eens gekeken naar de performance van dat soort omgevingen?
Was het niet Barry Boehm die al enkele decennia geleden aantoonde dat er in de specificaties meer fouten voorkwamen dan in de opgeleverde software?
Niettemin, elke verbetering van het ontwerp en bouwproces is natuurlijk welkom maar blijf met beide benen op de grond staan: fouten blijven voorkomen
Je ziet in dit artikel en de reacties dat het een semantische discussie wordt, en de inhoud als een academisch discussie wordt gezien die de werkelijke wereld niet echt raakt.
Nog sterker, fouten zijn volgens mij de basis tot vooruitgang. In een foutloze wereld is als volgens het geen een ieder wil. Deze 2 uitgangspunten kan ik me een hoge waarschijnlijk verwerpen als waar, kortom, het artikel heeft een paar foutjes in haar uitgangspunten ergo...
Foutloze ICT zou tevens erg saai zijn en er zou ook minder voor ons allen te doen zijn.
Dus laten we hopen dat het niet die kant op gaat.
Waar dit onderzoek en deze resultaten over gaan is de volledigheid van het testen van dergelijke specificaties. Ik heb zelf bij mijn afstuderen ook gewerkt aan de Groove-tool en deze stelt een ontwikkelaar (of tester) in staat om voor een gegeven specificatie *alle* mogelijke situaties in een stuk software door te rekenen. Dit betekent effectief dat er dus gegarandeerd een 100% coverage uit voor de tests ontstaat.
De kwaliteit van de software hangt dan natuurlijk nog steeds af van hoe goed de specificaties zijn geformuleerd. Het helpt in ieder geval bij het opsporen van die randgevallen, die vaak lastig zijn te voorspellen en dus wel eens buiten de boot vallen bij het testen.
Ik ben benieuwd of deze tool en aanpak ondertussen al geschikt zijn om zakelijke applicaties mee te analyseren en meld mij bij deze graag aan voor een testtrajectje :)
Ik vermoed dat de voorgestelde benadering uit moet gaan van een gesloten systeem - hoe kun je anders de integratie tussen applicatiesoftware, systeemcomponenten en infrastructuur beheersen?
Testen is in veel gevallen onmisbaar.
Is het ook mogelijk om te testen of b.v. een webservice nog performed bij 1000 gebruikers tegelijk? Want ik denk dat Marktplaats er dan wel interesse in heeft.
En hoe om te gaan met webbased software?
Ik ben serieus geïnteresseerd of hiervoor dan ook een oplossing is.
http://eprints.eemcs.utwente.nl/22860/
Voor zover ik kan overzien meent Zambon aan te kunnen tonen of een bepaald proces foutloos kan verlopen.
Wiskundig bewijzen dat een programma ten alle tijde correct werkt is al langer mogelijk, maar daar zijn wel voorwaarden aan verbonden.
Dit is nog geen foutvrije ICT. immers daarvoor moeten alle deelsystemen ook foutvrij of anders 100% betrouwbaar zijn.
Lijkt me nogal hachelijk als iemand durft te beweren dat een heel kantoornetwerk en daarmede de ICT omgeving van dat kantoor foutvrij is.
Ik zie al aankomen dat we straks mathematisch perfecte systemen hebben waar geen bugs inzitten vanuit programmatechnisch oogpunt, maar die toch volledig onbruikbaar zijn omdat de grilligheid van gebruikerswensen nu eenmaal zeer moeilijk zoniet onmogelijk te vangen is in een wiskundig model. Vooralsnog ben ik redelijk sceptisch t.o.v. een dergelijk model in de werkelijke praktijk in tegenstelling tot de academische praktijk, welke nog wel eens de neiging heeft anders te zijn.
Verder weet natuurlijk elke T-mapper dat er scripts te ontwikkelen zijn per funktionaliteit om foutenreductie te bewerkstelligen. Maar de ideale wereld bestaat niet, processen en procedures zijn mensenwerk. Denk hierbij aan rollback scenario bij een release update en denk hierbij aan de recente web applicatie update bij het UWV (1 volle week niet beschikbaar na release update). Dit is een typisch ITIL/PRINCE2 issue door menselijk handelen. Soms is een rollback de duur en word het risico vooraf aanvaard door management (als ze het snappen en/of op de hoogte zijn gebracht), door de EN NU KOMT HET de 'WAARSCHIJNLIJKE' gevolgen en risico's te aanvaarden en in te calculeren. Dit berust dus op aannames en aannames zijn levensgevaarlijk. Uit veel commentaar maak ik op dat de UT zou uitgaan van aannames maar dat blijkt uit de rest van het artikel niet.
17-05 Infotheek regelt hardwaredonatie via IT4kids
17-05 OpenSesame ICT start eigen CRM-bedrijf
17-05 Rabobank verlengt ook applicatiecontract IBM
17-05 Wadinko investeert in Caase.com
17-05 Leden De Unie verwerpen sociaal plan Ericsson
17-05 3D-model van plaats delict helpt rechercheur
17-05 Rabobank zoekt 100 extra ICT’ers in Nederland
17-05 Google geeft ontwikkelaars nieuwe tools
17-05 HP biedt SAP Hana op server met Intel Xeon
16-05 Mendix betrekt nieuw Rotterdams kantoor
17-05 Rabobank verlengt ook applicatiecontract IBM
17-05 Rabobank zoekt 100 extra ICT’ers in Nederland
17-05 Google geeft ontwikkelaars nieuwe tools
16-05 Mendix betrekt nieuw Rotterdams kantoor
16-05 Siemens PLM komt met nieuwe Teamcenter-apps
15-05 Ordina levert agile ontwikkelteams aan het CAK
15-05 Ministerie V&J gestopt met bouw Pardex-systeem
14-05 Cobol verdwijnt uit curriculum onderwijs
14-05 Rijk geeft minder uit aan grote en risicovolle ICT
13-05 ‘Tekort aan ICT’ers raakt vooral softwaresector’
|
|
08-06-12 Universiteit Twente lanceert EK-app
25-04-12 Universiteit Twente en NS, project Treinplanner
24-02-12 Promovendus Twente laat laptops 'stelen'
28-09-11 Studentes Universiteit Twente krijgen award
In vijf stappen een brug slaan tussen IT en business
![]() |
Van een informatiemanager wordt verwacht dat hij of zij optimaal inspeelt op de wensen van de business. Dat vereist......
Michael Page IT , Oosterhout NB
Carrera Recruitment BV , Ridderkerk
Zorg en Zekerheid , Leiden
NIVEL , Utrecht
Itility , Son



Buiten het eventuele misverstand van een allesomvattende meerwaarde, wil ik niets bij voorbaat relativeren: als een methode daadwerkelijk 'garbage in, garbage out' kan voorkomen, zou dat natuurlijk goud waard zijn. Eventuele toekomstige stokpaardberijders moeten zich ook dan wel blijven realiseren, dat het niet toepassen van een methode niet bij voorbaat 'garbage' oplevert (daar maakten veel ICT-managers in de tachtiger jaren zich nogal eens schuldig aan).