Verifiering och validering

Verifiering och validering

Verifiering och validering är två begrepp med olika betydelse.

Verifiering

Verifiering innebär att kontrollera att en produkt uppfyller de krav som den har upphandlats för att uppfylla. Det är alltså en mätning mot en kravspecifikation där varje krav skall kontrolleras om det är uppfyllt eller inte.

Att verifiera att ett krav är uppfyllt kan göras på olika sätt med hjälp av olika verifieringsmetoder.

Nedan är exempel på olika verifieringsmetoder:

  • Analys
    Leverantören gör en analys som dokumenteras i en rapport där det dels framgår att kravet är uppfyllt och dels hur det är uppfyllt.
  • Granskning
    Kravuppfyllnaden avgörs genom att beställaren granskar leveransen. Exempel granskning av kravuppfyllnad mha ritningsunderlag eller granskning av ett MMI, allt beroende på hur kravet är uformat.
  • Provning
    Kravuppfyllnaden mäts med hjälp av provning. Känt data används för att mäta resultatet som ska vara förväntat.
  • Hänvisning
    Leverantören hänvisar till annan dokumentation för att erhålla kravuppfyllnad. Verifieringsmetoden används för att undvika genomföra provning när det redan finns accepterbara resultat från prov som är genomförda av annan part

Det är beställaren som i underlaget inför upphandling väljer verifieringsmetod som respektive krav ska verifieras med i kravspecifikationerna (SSS).  Verifieringsmetoden kan givetvis ändras under projektets gång.

För att kunna genomföra en lyckad verifiering krävs att kraven är formulerade på sådant sätt att kraven är konkreta och framför allt verifieringsbara.

Verifiering är ett stort begrepp och omfattar både planläggning och genomförande. Verifieringsplaner tas också fram, likaså provföreskrifter, analysrapporter och verifieringsprotokoll. I verifieringsprotokollen dokumenteras resultatet utifrån gjorda prov. I analysrapporter hanteras de krav som har analys som verifieringsmetod.

Validering

Validering sker normalt efter leverans och är ett sätt för kunden att kontrollera att det som har beställts uppfyller de faktiska behov som kravspecifikationerna är skrivna utifrån eller – vilket är minst lika vanligt i stora, komplexa och långa projekt – att det som har levererats kan användas under den förändrade behovsbild som uppstått från det att kunden la beställningen tills dess att leverantören levererade.

Validering är mer subjektiv till sin natur än verifiering som är strikt vetenskaplig med spårbarhet mot kravspecifikationerna.

Validering sker i princip alltid när systemet är färdigutvecklat . En validering kan exempelvis ske genom att man startar med att skapa ett antal frågor som man vill ha svar på. Utifrån dessa frågor skapas en provföreskrift som innehåller provfall, oftast ett provfall per fråga. För att kunna svara på frågan kan mätningar behöva göras vars resultat sedan måste analyseras. Det kan i vissa fall bli rätt omfattande att validera och därmed är det viktigt att frågorna är genomtänkta inför genomförandet.

Interop har mångårig erfarenhet av verifiering och validering i olika projekt.

Hantverket

Verifiering är en aktivitet som ofta av naturliga skäl blir koncentrerad till mitten eller mot slutet av ett projekt, vilket nästan alltid är ogynnsamt för en lyckad verifiering. Det som är avgörande för en lyckad verifiering är att istället börja verifieringsförberedelserna med full kraft redan från projektstart.

Det finns en MIL-standard, MIL-STD-1521B som definierar processer som kan användas för att erhålla en lyckad verifiering. Processen behöver ofta anpassas i en åtagandebeskrivning eller Statement of Work (SOW) som är en del av kontraktet.

Nedan följer en populärbeskrivning om hur man kan nyttja MIL-standarden för att kunna erhålla en lyckad verifiering i ett projekt.

SRR – System Requirements Review

Vid projektstart diskuterar kunden och leverantören igenom samtliga krav i specifikationerna och redogör för sina respektive förväntningar på realiseringen av varje krav. Syftet är ett ensa, dvs kommer överens om en gemensam förväntning om vad kravet innebär. 

Resultatet protokollförs i en verifieringsmatris med en rad för respektive krav och som svarar kortfattat på frågorna:

  • Vid vilka tillfällen ska kravet testas?
  • Vilken verifieringsmetod ska användas?
  • I vilken omgivande miljö ska provet testas?
  • Hur ska kravet testas?
  • Vad ska uppnås för att kravet ska bli godkänt?

I denna process uppstår diskussioner vilket ofta leder till att otydliga krav formuleras om. Som exempel finns det ett par så kallade funktionsverb som ibland förekommer i kravspecifikationerna som oftast innebär svåra utmaningar vid verifieringen. Här är ett litet urval:

  • Stöjda eller ”ha  stöd för”- vad innebär detta mer konkret, vad är det som ska uppfyllas?
  • ”Hantera” – Vad innebär det konkret, vad är det som ska uppfyllas?
  • ”Övervaka” – Vad ska övervakas och hur ska det övervakas? Vad ska uppnås?
  • ”Ska kunna nyttja” – vad exakt innebär det att nyttja?

Denna granskning ingår alltså i System Requirements Review (SRR). Om det är otydligt vid SRR är SRR tillfället att tillsammans med leverantören skriva om kraven så att de blir tydliga om vad ska uppnås och att det därmed gå att verifiera kraven när det blir dags.

Granskningen inför SRR är helt avgörande för en lyckad verifiering eftersom det är inför och under konstruktionsfasen som det går att påverka den realisering/konstruktion som leverantören ännu inte har gjort.

PDR – Preliminary Design Review

Efter att SRR är genomförd börjar leverantören konstruktionsfasen. Leverantören kallar då till kravrealiseringsmöten där leverantören i text inför mötet redovisar hur respektive krav avses realiseras/konstrueras.

Kunden får under dessa möten uppgiften att ställa frågor kopplade till kravställningen för att säkerställa att kravet blir uppfyllt och att förväntningarna enligt överenskommelsen från SRR överensstämmer med den beskrivna konstruktionen.

Alla krav i den vid SRR överenskomna verifieringsmatrisen gås igenom. Matrisen uppdateras vid behov.

Tanken med att starta kravrealiseringsmöten direkt efter att SRR passerats är att kunna fördela kraven mellan flera kravrealiseringsmöten samt att man startar med de krav som leverantören avser att börja realisera i sin konstruktion. Är det många krav blir det givetvis också många kravrealiseringsmöten, dvs det blir ett iterativt arbete.

Ur ett verifieringsperspektiv är dessa möten viktiga eftersom leverantören redovisar sin tilltänkta konstruktion för att uppfylla respektive krav. Inför PDR börjar man alltså skapa förutsättningarna för att erhålla godkänt i verifieringen.

Kundens utmaning under dessa möten är att ställa rätt frågor så att leverantörens kravrealiseringsbeskrivning blir heltäckande mot både krav och förväntningar. 

Kravrealiseringsbeskrivningen och verifieringsförutsättningarna protokollförs. När ett krav har fått godkänt i protokollet kan leverantören börjar konstruera.

Avsikten är att bli överens under dessa kravrealiseringsmöten. Det är därför en förutsättning att de som deltar på dessa möten har beslutsmandat att fatta beslut eftersom brist på beslut eller uppskjutet beslut ofta innebär att leverantören inte kan starta realiseringen av de kraven som saknar beslut, vilket nästan alltid leder till förseningar och fördyringar.

Denna granskning kallas Preliminary Design Review (PDR) som är en avstämning vid ett visst bestämt datum att man hunnit gå igenom ca 80% av alla krav.

CDR – Critical Design Review

De sista 20% av kraven gås igenom inför Critical Design Review (CDR) som är ett datum då kravrealiseringen för alla krav ska vara granskade och överenskomna. De sista 20% brukar vara de svåraste kraven att komma överens om och här gäller det att ha kvar orken och fokus för blir överens så att verifieringen blir lyckad.

Mellan PDR och CDR kan det också hända att PDR-kraven måste gås igenom, för givetvis kan realiseringen ändras då man blivit klokare under vägen.

Efter CDR ska alla frågor vara besvarade. Det som är kvar är kvarvarande produktion och kvarvarande verifiering. Därmed skapas förutsättningar att CDR också blir en avstämning att leverantören kan leverera enligt tidplan.

När kan verifiering starta?

Verifieringen kan faktiskt starta innan PDR passeras , bara parterna är överens om kravrealiseringsbeskrivningarna och verifieringsförutsättningarna för de krav som ska verifieras.

Normalt är dock att verifieringsaktiviteterna startar ganska sent efter PDR eftersom leverantören måste blir klar. Efter att CDR är klart brukar verifieringsaktiviteterna peaka då projektet är på upploppet och alla krav som är kvar ska testas med målet att erhålla OK.

Tidskrävande process?

Ovanstående process kan uppfattas som tidskrävande . Poängen med processen är dels att reda ut alla frågor innan leverantören har gjort sin konstruktion och dels maximera mängden OK (=krav uppfyllt) vid verifieringen. Därmed slipper både leverantören och kunden lägga både tid och pengar på administration, omkonstruktion och omprov som blir konsekvensen när krav erhåller ett NOK (Not OK) i verifieringen.

Följer man processen enligt ovan blir kunden tryggare innan verifieringen med att man får det man betalar för innan det är för sent, dvs efter att konstruktionen är gjord, medan leverantören blir tryggare med att den tilltänkta konstruktionen kommer uppfylla kraven och därigenom finns förutsättningar för att maximera mängden OK vid verifieringen.

Att hantera konsekvenser för de krav som inte blir OK pga skillnad i parternas kravtolkning och förväntning är alltid kostsamt efter att kravet har verifierats till ett NOK jämfört med att ta diskussionen innan eller under konstruktionsfasen och därmed öka chansen att erhålla ett OK.

Härmed sagt att verifieringsarbetet i ett projektet startar när projektet startar.

Begrepp som beskriver status

I verifieringsarbetet hanteras ett antal begrepp som beskriver status för ett krav:

  • OK = kravet är godkänt
  • NOK = kravet är inte godkänt
  • NOT = kravet är inte testat
  • !OK = kravet har annan status än OK

Verifiering är inte bara en verksamhet som genomförs i slutet, insatsen startar från det att projektet startar.

Insatsförmåga Luftvärn

I projekt InsatsFörmåga Luftvärn (IFLv) upphandlade FMV två nya systemenheter EldE 98 och LvC samt uppgraderar de befintliga systemenheterna EldE 97, PS-91 och UndE 23. Upphandlingen omfattar även ett nytt helt ledningssystem anpassat för luftvärnets behov.

Interop har som oberoende leverantör bistått FMV i verifieringsarbetet under hela projekttiden.

LvS 1.0

LvS 1.0 ingår en central ledningsplats för luftvärnet. GBADOC, Ground Based Air Defense Operational Centre som Sverige leasade av Norge.  Konceptet togs fram inför NBG 08 och fanns kvar fram till 2017 då GBADOC avvecklades inför införandet av IFLv.

Interop deltog i valideringen av LvS 1.0 för att kontrollera om GBADOC fungerar med befintliga systemenheter,Rb 70, PS-91, UndE 23 och EldE 97 samt inte minst att LvS 1.0 uppfyllde Försvarsmaktens behov.

Våra andra tjänster

Systemarbete

Systemarbete innebär att utifrån tekniska, taktiska och operativa målsättningsdokument genomföra kravanalys och kravtolkning i syfte att ta fram en sammanställd kravbild i en systemspecifikation.

ILS

Integrated Logistics Support (ILS) är ett samlingsnamn på metoder för att kunna genomföra ett effektivt underhåll.

Ackreditering

Att ackreditera ett system är att godkänna systemet för användning i den kontext för vilken systemet är framtaget för att lösa en uppgift.