Agile werken in een safety-omgeving

14 juli 2020

Wie software ontwikkelt die moet functioneren in een veiligheidsomgeving, moet voldoen aan de Europese CENELEC-norm. De CENELEC-normen schrijven voor welke processen je moet volgen om veiligheidsrelevante software te ontwikkelen en zijn gebaseerd op het V-model: eerst bouwen, dan testen. Deze werkwijze is een bewezen en gedegen aanpak voor safety-critical projecten, maar biedt weinig mogelijkheden voor flexibiliteit. Daarom koos ProRail voor de aanpak SafeScrum in combinatie met Model-Based Testen van InTraffic en Axini, waarbij het mogelijk is om aanpassingen in een vroeg stadium door te voeren en tegelijkertijd te voldoen aan de veiligheidseisen. Dit leidt tot hogere kwaliteit en lagere kosten.

 

ProRail gaat het huidige treinbeveiligingssysteem aanpassen aan de Europese standaard ERTMS: European Rail Traffic Management System. Een grootscheepse en complexe opgave. Eind vorig jaar heeft ProRail aan InTraffic de opdracht verstrekt om ETIS, het ERTMS Trein Informatie Systeem, te ontwikkelen. Dit systeem geeft informatie uit de treinen door aan PRL (Procesleiding) en omgekeerd. De ontwikkeling van ETIS is een belangrijk onderdeel van het veel grotere PEIL-project, wat staat voor ProRail ERTMS ICT Logistiek.

Harm van Beek is projectleider ERTMS Treinbesturing bij ProRail en opdrachtgever voor de ontwikkeling van het ETIS-project. Hij vertelt: “Kwaliteitsborging is op het spoor van het allergrootste belang. Niet alleen moeten de verschillende softwaresystemen zelf veilig werken, ook de koppelingen tussen de systemen moeten volgens hele strenge veiligheidseisen worden ontwikkeld. De hele keten moet immers veilig functioneren.”

“SafeScrum is een gecertificeerde methode om software volgens de hoogste veiligheidsnormeringen te ontwikkelen.”

Erik Veldhuis, safety manager project ETIS – InTraffic

SafeScrum: best of both worlds

InTraffic heeft Erik Veldhuis aangesteld om binnen het ETIS-project toe te zien op kwaliteitsborging en safety management. “We hebben een eigen kwaliteitssysteem en we moeten uiteraard voldoen aan de door de EU verplichte CENELEC-normen”, vertelt Erik. “Bij dat laatste ligt een uitdaging, want de veiligheidsnormen van de EU gaan uit van het V-model: je maakt eerst het hele ontwerp van het systeem dat je gaat ontwikkelen, dan schrijf je vervolgens de code en tot slot ga je dit testen. Dat is een heel andere benadering dan de Scrum-methode waar wij als InTraffic graag mee werken. Scrum is een iteratieve werkwijze waarbij je continu voortborduurt op datgene wat je eerder al hebt ontwikkeld. Je werkt met sprints van een aantal weken – in ons geval drie – en in iedere sprint test je de software die je hebt ontwikkeld ook direct.”

Om aan de strenge eisen te voldoen, maar wel flexibiliteit in de ontwikkeling van het project te behouden koos InTraffic voor een aanpak met SafeScrum. Erik: “Bij SafeScrum zit in de methode ingebakken dat je continu door de bril van veiligheid kijkt naar de software die je ontwerpt. Bij de dagelijkse stand-up wordt standaard de vraag aan alle teamleden gesteld: heb je ‘hazards’ gezien die kunnen leiden tot potentiële gevaren of ongelukken? Een hazard is een systeemtoestand die mogelijk kan leiden tot een ongeluk. We houden een ‘hazard log’ bij waarbij we per gevaar opschrijven wat de oorzaken en gevolgen zijn, hoe we het gevaar in de software zouden kunnen wegnemen en welke mitigerende maatregelen kunnen we bedenken als er softwarematig geen oplossing is.” SafeScrum is ontwikkeld door experts en positief beoordeeld door externe Independent Safety Assessors. “Het is dus echt een gecertificeerde methode om software volgens de hoogste veiligheidsnormeringen te ontwikkelen”, zegt Erik.

 

Model-Based Testen

InTraffic gebruikt tooling van Axini om de software vervolgens te testen. Axini-oprichter Machiel van der Bijl vertelt: “Een van de tools die we leveren is Model-Based Testen (MBT). Deze aanpak borduurt voort op modelgebaseerd software ontwikkelen. In het model leg je in formele taal eenduidig vast wat er volgens de specificatie moet gebeuren en leg je de link naar de requirements. Met modelgebaseerd testen werk je volautomatisch diverse testscenario’s af om te kijken of alle requirements zijn geraakt. Zo sluit je de lus.”

Het unieke aan de Axini-oplossing is dat je de testcases niet meer met de hand hoeft te schrijven en te scripten, die worden automatisch gegenereerd, op zo’n manier dat ook de meest onwaarschijnlijke scenario’s worden getest. Voor een CENELEC SIL1 systeem dient MBT tooling gevalideerd te zijn om te gebruiken bij de ontwikkeling van software die aan de hoogste safety-eisen moet voldoen.

Machiel: “Je moet beschrijven wat de tool doet en aantonen dat de tool geschikt is voor het ontwikkelen van software die wordt ingezet in veiligheid gerelateerde projecten. Een van de eisen daarbij is traceerbarheid: je moet niet alleen aantonen dat de tests zelf goed werken, maar ook de relatie aantonen met de eisen uit de specificatie. Het prettige van onze modelgebaseerde tool is dat de testscripts automatisch worden gegenereerd op basis van de requirements. Aan het einde van de sprint zijn daardoor ook alle testen gedaan.”

 

Sneller feedback

Deze methode past volledig bij de principes die ProRail gebruikt voor het ETIS-project, vertelt Harm. “We willen graag sneller feedback krijgen op de software die is ontwikkeld. Op die manier is er ook minder onderhanden werk. Je hebt op ieder moment dan bijvoorbeeld nog maximaal 30 testbevindingen waar je wat mee moet in plaats van 300. Ook willen we voorspelbaar worden naar oplevermomenten, zodat er cadans komt in het PEIL-project. Want bij complexe integraties werkt het niet om pas een interface te ontwikkelen als de software klaar is; de integratie moet onderdeel zijn van het ontwikkelproces. Dat lukt alleen als alle betrokken Scrum-teams in dezelfde cadans werken. Tot slot willen we software beschikbaar kunnen stellen naar behoefte. Als we nu een integratie ontwikkelen tussen ETIS en PRL, moet dat nog niet in productie worden genomen want ETIS en ERTMS gaan nog niet live. SafeScrum komt aan al die principes tegemoet.”

“Op heel veel verschillende plekken is al aangetoond dat agile werken – kort-cyclisch met snelle feedback en kleine werkeenheden - leidt tot hogere kwaliteit software tegen lagere kosten.”

Harm van Beek, Projectleider ERTMS Treinbesturing – ProRail

Focus op kwaliteit leidt tot kostenverlaging

Met SafeScrum kun je veilig werken combineren met Scrum, en dat biedt volgens de drie heren diverse voordelen. Harm: “Op heel veel verschillende plekken is al aangetoond dat agile werken – kort-cyclisch met snelle feedback en kleine werkeenheden – leidt tot hogere kwaliteit software tegen lagere kosten. In de safety wereld is lang vastgehouden aan de watervalmethode van software ontwikkelen om dat er nog geen goede manier was om de veiligheid te borgen. Het gevolg van waterval en achteraf testen is dat alle testbevindingen per definitie leiden tot veel rework. Hoe later je een fout vindt, hoe duurder het is om die te herstellen omdat die fout vaak doorwerkt in andere onderdelen van de software. Je moet dan dus niet alleen die ene fout herstellen, maar ook alle gevolgfouten. SafeScrum leidt ertoe dat je fouten eerder vindt en dus eerder kunt herstellen, vaak in de volgende sprint al. Deze manier van werken leidt tot kostenverlaging, doordat de focus ligt op kwaliteit. Kwaliteitsverhoging leidt altijd tot kostenverlaging, terwijl het omgekeerde niet opgaat. Je kunt dus veel beter sturen op kwaliteit dan op kosten. Dat is precies wat we met SafeScrum doen.”

Download het artikel

Klik hier voor de Engelse versie.

 

Lees ook