Wie software ontwikkelt die moet functioneren in een veiligheidsomgeving zoals de spoorinfrastructuur, moet voldoen aan de Europese CENELEC-norm. Processen die bedrijven doorgaans moeten volgen op aan deze norm te voldoen bieden weinig ruimte voor flexibiliteit. Om toch flexibel te kunnen zijn, heeft ProRail gekozen voor de SafeScrum-aanpak in combinatie met Model Based Testen van InTraffic en Axini. Dit biedt de mogelijkheid om aanpassingen in een vroeg stadium door te voeren en tegelijkertijd te voldoen aan de veiligheidseisen.

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. Omdat deze werkwijze weinig mogelijkheden voor flexibiliteit biedt, koos ProRail om te werken met SafeScrum in combinatie met Model Based Testen. Volgens leveranciers InTraffic en Axini leidt dit tot hogere kwaliteit en lagere kosten.

ERTMS

ProRail gaat de komende jaren het huidige treinbeveiligingssysteem ATB vervangen door het Europese beveiligingssysteem ERTMS. De spoorbeheerder heeft eind vorig jaar InTraffic de opdracht gegund om ETIS, het ERTMS Trein Informatie Systeem, te ontwikkelen. Dit systeem geeft informatie uit de treinen door aan de 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. “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”, legt Van Beek uit.

Kwaliteitssysteem

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

“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.”

Flexibiliteit

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. Veldhuis: “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 Veldhuis.

Model-Based Testen

InTraffic gebruikt tooling van Axini om de software vervolgens te testen. Axini-oprichter Machiel van der Bijl: “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.”

Van der Bijl: “Bij het gebruik van de Axini-oplossing hoef je de testcases niet meer met de hand te schrijven en te scripten, die worden automatisch gegenereerd. Dat gebeurt 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 veiligheidseisen moet voldoen.”

“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 traceerbaarheid: 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 vereisten. Aan het einde van de sprint zijn daardoor ook alle testen gedaan.”

Volgens Van Beek sluit deze methode aan bij de principes die ProRail gebruikt voor het ETIS-project. “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.”

Oplevermomenten

“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.”

Voor die laatste twee principes werkt het overkoepelende project PEIL op basis van SAFe. Van Beek: “SAFe staat voor Scaled Agile Framework, een realisatiemethode om bij hele grote implementaties ervoor te zorgen dat het werk van meerdere Scrum-teams op elkaar afgestemd blijft. We gebruiken deze methode binnen het grotere PEIL-project om ervoor te zorgen dat de cadans in het project goed blijft.” Hij snapt dat de terminologie voor verwarring kan zorgen. “Het zijn twee verschillende werkwijzen, maar ze sluiten wel heel goed op elkaar aan.”

Voordelen

Met SafeScrum kun je veilig werken combineren met Scrum, en dat biedt volgens de drie experts diverse voordelen. Van Beek: “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 safetywereld 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.”