Efterhånden som software bliver en større og større del alle systemer, inclusive mekaniske, må man måske få etableret nogle praksisser på markedet der varetager køberes brugeres/operatørers interesser i passende grad.
Der er mange ting der spiller ind, og eksemplet i denne tråd er nok kun én vinkel, omend lidt ekstrem. Set udefra, får man dog et indtryk af at kvaliteten af (software)systemerne og indsigten i den installerede software i et tog en gang imellem kunne bruge lidt konstruktivt input fra kunden (eller en repræsentant) med et vågent øje og tilstrækkelig indsigt i metoder og processer (jvf. f.eks. ICNG/IC5-forsinkelser tilskrevet softwareproblemer). Som med andre ting, jo tidligere i processen, jo bedre.
Jeg skal dog gladeligt indrømme min uvidenhed på området og for at finde et offentligt eksempel på udbudsmateriale downloadede jeg dokumenterne relateret til Lokaltogs udbud af batteritog hvor en link venligst blev publiceret her:
https://www.jernbanen.dk/forum1/index.php/topic,899.msg13318.html#msg13318Jeg er sikker på at dette ikke er det fulde materiale, i og med at der helt sikkert er henvisninger til standarder og normer samt ting der er så åbenlyse at det ville være en fornærmelse at nævne dem i materialet. Men alligevel: I dette eksempel på et sæt udbudsmateriale der oven i købet er blevet trukket tilbage og forbedret har jeg kun været i stand til at finde ordet "software" ét eneste sted, nemlig paragraf 21 i kontrakten (Contract.pdf) omhandlende garantiforpligtelser:
CitatIn the 2-year warranty period, cf. clause 15.2, the Supplier undertakes to remedy the defect within a reasonable response period and at no extra cost to Lokaltog, and the Supplier shall provide documentation to Lokaltog that the defect has been remedied. Further, the Supplier shall update relevant documentation and software, and – if necessary – testing and certificates.
Eftersom de polske skærmydsler vedrører vedligeholdelse, kan man se hvad ovennævnte udbudsmateriale har at sige desangående gennem de oplistede krav til validering og verifikation af det leverede produkt:
Der er et appendix (no. 6) med titlen "Requirements for Validation & Verification plan (V&V)", hvor man nok godt kunne have klemt et punkt om software V&V ind uden at nogen ville have gøet af det.
Nuvel, man kan anføre at softwaresystemet ombord på dette moderne, elektriske og digitaliserede togsæt er alt for detaljeret et emne til at nævne i udbudsmaterialet og V&V-planen. Det skal jeg selvfølgelig ikke argumentere imod, men så kan jeg ikke undlade at bemærke at punktet "
replacement of headlights" er nævnt netop i listen over vedligeholdelsesrelaterede verifikationspunkter. Hvis muligheden for udskiftning af lamper kan gøres til genstand for eksplicit verifikation, kan man måske også tillade sig at forlange af leverandøren at de redegør for og validerer (og verificerer!) deres softwarekvalitetsprocedurer og opdateringsprocesser sammen med kunden.
Og jo, jeg er med på at V&V-punkterne i ovennævnte dokument inkluderer "
train management system and system integration", men ved at betragte softwaren udelukkende som en lille del af det fulde system uden at gå ind i softwaredelens udviklings-, vedligeholdelses- og udrulningsaspekter mister man nok et vigtigt håndtag der kan give nyttig indsigt i det produkt man er ved at indkøbe og forhåbentligt skal leve med i flere årtier.
Ovenstående skal ikke ses som en kritik af nævnte udbudsmateriale, men som lidt observationer på den opmærksomhed der bliver givet til softwaresiden materiellet der indkøbes i disse år. Man efterlades med en nagende fornemmelse af at der er meget mere fokus på og indsigt i det mekaniske end på softwaresiden, og med den teknologiske udvikling i de sidste par årtier (i retning af højere digitalisering) kan man overveje om den balance skal revideres - i de næste udbud, forstås.
