Onderzoeker bouwt model voor foutloze ICT

25-01-2013 11:59 | Door Sander Hulsman | Lees meer over het bedrijf: Universiteit Twente | Er zijn 19 reacties op dit artikel | Permalink
wicca glazen bol

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.’

Reacties op dit artikel
De redactie vindt deze reactie: OKRob Koelmans, 25-01-2013 12:41
Goede systematiek is natuurlijk goud waard. Maar kijk naar wat er gebeurde met "Een methode van programmeren" van Dijkstra. Het strak hanteren van een systematische methode heeft ook aanzienlijke nadelen. Het is zoiets als 95% van de academische wereld zeggen dat ze geen wetenschap meer mogen bedrijven als het methodologisch niet verantwoord kan worden (daar zou ook veel voor te zeggen zijn).
 
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).
De redactie vindt deze reactie: OKCpt, 25-01-2013 12:44
Er wordt in het artikel uitgegaan van een volledig getest en onfeilbaar wiskundig model. Met andere woorden: wie heeft met model getest en waarmee?
De redactie vindt deze reactie: OKhk, 25-01-2013 12:44
Dus volgens de UT hoeven we straks helemaal niet meer zelf na te denken.
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.
De redactie vindt deze reactie: OKAtilla Vigh, 25-01-2013 12:56
Ik kan zeker meegaan in het commentaar van Rob.
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
De redactie vindt deze reactie: OKJaap-G, 25-01-2013 13:05
En nu maar afwachten of er bedrijven zijn die werkelijk met dit model gaan werken. Wat ik me dan wel afvraag is of het model op allerlei systemen en processen is toe te passen. Als voorbeeld in het artikel wordt de Fyra genoemd, maar is dat dan niet een brug te ver? De problemen die daarmee zijn ontstaan beperken zich niet tot software alleen, maar bestaan onder meer uit een inferieure kwaliteit van het geleverde materieel en het hoogmoedige gedrag van leverancier en NS, vooral het voor een dubbeltje op de eerste rang willen zitten. Ik vraag me af of het model dat afvangt.
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...
De redactie vindt deze reactie: OKcorne smiesing, 25-01-2013 13:26
Als de NS specificeert dat een trein onder de 40km door rood mag rijden.
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...
De redactie vindt deze reactie: OKgctwnl, 25-01-2013 13:26
De geschiedenis van IT zit vol met dit soort beloftes die komen vanuit universitaire situaties waarin de theorie wordt uitgevoerd in een speel-omgeving. Zeg, vertaalprogramma's die perfect werken met een woordenschat van 200 woorden. En dan extrapoleren dat je het probleem alleen nog maar groter hoeft uit te voeren. In de praktijk blijken dergelijke oplossingen te leiden aan 'combinatorial explosion' en het schaal niet. Denk aan A-Life proponenten die suggereerden dat het kunnen evolueren van redelijke sort-algoritmen op strings van 13 bytes opschaalbaar zouden zijn naar het bouwen van passagiersvliegtuigen (de vraag negerend hoe je de 'grim reaper'in dat geval praktisch invult.
 
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?
De redactie vindt deze reactie: OKJoop, 25-01-2013 13:39
@Corne Smiesing: Je hebt volkomen gelijk Cor.
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
De redactie vindt deze reactie: OKMickel van der Horst, 25-01-2013 13:41
Corne, je haalt me de woorden uit de mond. Buiten het feit dat ik me afvraag of ooit iets foutloos kan zijn, stel ik me altijd gelijk de vraag wat foutloos nu precies is.
 
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...
De redactie vindt deze reactie: OKRuud Mulder, 25-01-2013 13:43
Mickel slaat de spijker op zijn kop. Van fouten leren we en komen we uiteindelijk verder.
 
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.
De redactie vindt deze reactie: OKJan-Hendrik Kuperus, 25-01-2013 13:52
Gezien de reacties die hier voorbijkomen wordt er te zwaar getild aan deze aankondiging. Natuurlijk kan geen enkele methode of tool ervoor zorgen dat software voor 100% doet wat het moet doen. Wat eerder al werd gezegd: dat is afhankelijk van de specificaties.
 
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 :)
De redactie vindt deze reactie: OKEli Diemer, 25-01-2013 14:17
Wordt er vanuit gegaan dat de specificaties volledig juist zijn? Een illusie lijkt me. En hoe kijkt men aan tegen ontwerpgebreken?
 
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.
De redactie vindt deze reactie: OKcorne smiesing, 25-01-2013 14:47
Vraag aan Jan Hendrik Kuperus:
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.
De redactie vindt deze reactie: OKmatthijs, 25-01-2013 15:32
Voor de fans. De thesis staat ook op internet:
http://eprints.eemcs.utwente.nl/22860/
De redactie vindt deze reactie: OKPascal, 25-01-2013 16:28
Ik begrijp uit het verhaal iets heel anders dan de titel van dit artikel verkondigt.
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.
 
De redactie vindt deze reactie: OKErwin van Boven, 25-01-2013 17:23
Prachtig, zo'n wiskundig model, maar in de praktijk moet ik nog zien of het zijn waarde zal bewijzen.
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.
De redactie vindt deze reactie: OKOskar Hendriks, 26-01-2013 8:10
Het artikel onderschrijft ook niet de pretentieuze kop, maar geeft wel aan dat er modellen te maken zijn die HELPEN bij het duiden en filteren van technische oneffenheden. Het artikel geeft duidelijk aan dat het voorkomen van alle funktionele tekortkomingen in software ondoenlijk is. Niet door gebruikers en laat staan door IT-ers. Precies zoals verwoord door Corne Smiesing, met max. 40 kmh mag een trein door een rood sein rijden.
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.
De redactie vindt deze reactie: OKm.rotteveel, 27-01-2013 12:50
NIAM pretendeert al jaren foutloze systemen te kunnen modelleren. En het werkt als je je aan alle voorschriften houd, maar commercieel niet interessant er gaat (te) veel tijd in het ontwerp zitten, het technisch ontwerp en de uitvoering zijn beduidend goedkoper, maar een trechtermodel is commercieel veel interessanter
De redactie vindt deze reactie: OKHenri Koppen, 27-01-2013 14:47
Mooie reactie Oskar. Mee eens.
93 vacatures
Web Developer ASP.NET C# (Medior / Senior)

NiDiDo BV , Barneveld

PHP Programmeur

BWSS B.V. , Deventer

.NET (C#) Programmeur

Let's build IT , Hoorn NH

Pielen in PHP, of on Rails in Ruby?

ForecastXL (via Quoratio BV) , Groningen

Senior SAP BW Specialist - Tilburg

Achmea , Tilburg

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1571 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1271 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 980 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 524 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0