OPTION TIL RM OG RN BILAG 12 TIL KONTRAKT OM EPJ/PAS PRØVER

OPTION TIL RM OG RN BILAG 12 TIL KONTRAKT OM EPJ/PAS PRØVER

INSTRUKTION TIL LEVERANDØR VED UDNYTTELSE AF OPTIONEN: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Bilaget angiver s krav til Prøveprogrammet, Prøver og Tests. Bilaget skal ikke udfyldes af en.

1. Indledning... 1 1.1. Struktur... 1 2. Oversigt over underbilag... 1 3. Prøveprogram... 1 3.1. Generelle retningslinjer for prøveprogrammet... 1 3.2. Risikobaseret tilgang... 2 3.3. Tidsplan... 2 3.4. Sikkerhed... 2 4. Prøver... 2 4.1. Fabriksprøven... 2 4.2. Platformsprøve... 2 4.3. Installationsprøven... 2 4.3.1. Systemacceptprøve... 3 4.3.2. Delleveranceprøve (Driftsprøve type 1)... 3 4.3.3. Overtagelsesprøve... 3 4.3.4. Driftsprøven (Driftsprøve type 2)... 3 5. Prøver og Tests... 3 5.1. Startkriterier, Prøver... 6 5.2. Startkriterier, Tests... 6 5.3. Slutkriterier, Test... 6 5.4. Slutkriterier, Prøver... 6 6. Prøve- og dokumentation... 6 6.1. Teststrategi... 6 6.1.1. Testcases... 7 6.1.2. Regressionscases... 7 6.1.3. Testdata... 7 6.2. Prøveplaner/Testplaner... 7 6.3. Prøverapport/Testrapport... 8 7. Fejlhåndtering... 8 7.1. Fejlhåndteringsproces... 8 7.2. Fejlkategorier for funktionelle Tests... 9 7.2.1. Dokumentations... 10 7.2.2. Brugervenligheds... 10 7.3. Godkendelse af en Prøve... 10 8. Værktøjer... 11

8.1. Testværktøj... 11

1.Indledning Bilaget angiver s krav til afprøvning af Løsningen og beskriver Prøveprogrammets Prøver, herunder sammenhængen til miljøer og typer. Formålet med afprøvninger er at sikre, at ens forpligtelser i forbindelse med Kontrakten er opfyldt, herunder de Servicemål, som er angivet i Bilag 7. Prøveprogrammets struktur skal gøre det muligt at planlægge detaljeret med de ressourcer, der indgår, herunder både personale og IT-udstyr. Samtidig skal Prøveprogrammets struktur til enhver tid understøtte fremdrift i det overordnede Program og gøre det muligt på et vilkårligt tidspunkt at dokumentere status og fremdrift i forhold til Prøveprogrammet. For at sikre den størst mulige fremdrift i det samlede Program er det nødvendigt, at der udarbejdes en dynamisk strategi. Teststrategien udarbejdes af en i samarbejde med og godkendes af inden afslutningen af Afklaringsfasen. Udarbejdelse og godkendelse sker som angivet i Bilag 4 og skal endvidere tage højde for beskrivelsen af ens metoder m.v. i Implementeringsstrategien, jf. Underbilag 1D. Teststrategiens elementer (Prøver og Test) kan, hvis det aftales mellem Parterne, afvikles i parallelle forløb. Dog kan en Prøve ikke godkendes, før den foregående Prøve er godkendt. ens omkostninger til prøver og s skal være indregnet i Leverancevederlaget. 1.1. Struktur Bilag 12 udgør rammerne for udarbejdelse af strategien og Prøveprogrammet i øvrigt. Dokumentet er struktureret omkring følgende Prøver, jf. Kontraktens punkt 8 samt Bilag 1: Fabriksprøve Platformsprøve Installationsprøve Systemacceptprøve Delleveranceprøve (Driftsprøve type 1) Overtagelsesprøven Driftsprøven (Driftsprøve type 2) Hver enkelt prøve er kendetegnet ved en række og aktiviteter, som afvikles i de miljøer, der er specificeret i nærværende Prøveprogram. Som led i udarbejdelsen af strategien kan der aftales ændringer (f.eks. supplerende s) i de enkelte Prøver. Sådanne ændringer håndteres som ændringsanmodninger, jf. Bilag 8. 2.Oversigt over underbilag Bilag 12 har ingen underbilag. 3.Prøveprogram Formålet med Prøveprogrammet er at kontrollere og verificere, at Løsningen er komplet, korrekt installeret og korrekt konfigureret, samt overholder aftalte svartider og øvrige Servicemål, jf. Bilag 7 samt, at alle krav i øvrigt er opfyldt i den aftalte kvalitet. 3.1. Generelle retningslinjer for Prøveprogrammet De generelle retningslinjer for Prøveprogrammet gælder for alle prøver, medmindre andet er specificeret for de enkelte prøver. 1

en har det overordnede ansvar for, at alle aktiviteter i Prøveprogrammet planlægges, igangsættes og afvikles til tiden. bidrager i det aftalte omfang til prøve- og aktiviteter. ens manager skal sammen med s manager forestå al planlægning, opfølgning, rapportering mv. omkring afviklingen af prøver. s deltagelse i aktiviteter skal fremgå af Bilag 1. en kan ikke kræve, at deltager i prøve- og aktiviteter udover det, der fremgår af Bilag 1. en skal være fysisk tilstede under de ttests, som gennemfører, medmindre andet er aftalt. En Prøve skal gennemføres under forhold, der i videst muligt omfang svarer til en normal driftssituation. Det påhviler en, at dokumentere at afvigelser mellem drift og det aktuelle miljø ikke er relevant for den aktuelle Test. 3.2. Risikobaseret tilgang Prøveafviklingen sker ud fra en risikobaseret tilgang således, at det sikres, at de steder hvor risikoen for Fejl er højest, også er de steder, der es tidligt i projektforløbet, og mere grundigt end de områder, der har mindre sandsynlighed for Fejl eller mindre konsekvens ved Fejl. 3.3. Tidsplan Det påhviler en at tilrettelægge Prøveprogrammet således, at tidsplanen jf. Bilag 1, overholdes. Hvis et afprøvningsforløb ikke kan godkendes, skal en levere en revideret tidsplan, jf. bestemmelserne i Bilag 1 og Kontrakten. 3.4. Sikkerhed Det påhviler en at tilrettelægge Prøveprogrammet således, at kravene i Bilag 14, overholdes, herunder krav til anonymisering af data. 4. Prøver 4.1. Fabriksprøven Fabriksprøven gennemføres af en som et led i egen kvalitetssikring af Programmel og programmeringsarbejde og omfatter en afprøvning af Løsningens funktionalitet i ens eget miljø uden tilslutning til s IT-miljø. Formålet med Fabriksprøven er at sikre, at den aftalte Løsning har en kvalitet, som kan give en berettiget forventning om, at Løsningen kan opfylde de kriterier, der er fastlagt i de efterfølgende Prøver. Det er således en forudsætning, at den samlede Løsning er kvalitetssikret hos en og således har bestået Fabriksprøven inden installation og afprøvning hos. Fabriksprøven skal sikre, at det øvrige Prøveprogram kan gennemføres uden unødige gentagelser, forsinkelser og brug af ressourcer under forløbet. 4.2. Platformsprøve Platformsprøven indeholder en gennemgang og Test af Driftsplatformen, således at det sikres, at platformen er klar til installation af Løsningen. Driftsplatformen skal overholde de specifikationer, en har beskrevet i besvarelsen af Bilag 6. Det nærmere forløb aftales mellem en og i Afklaringsfasen og indgår i Teststrategien. Det er ens ansvar, at der specificeres et sådant forløb. 4.3. Installationsprøven Formålet med installationsprøven er at afprøve, om Løsningen kan installeres, konfigureres og bringes til at fungere i et nyt miljø, herunder at eventuelle relevante data kan konverteres korrekt, før en ny type eller Prøve påbegyndes. Prøven gennemføres i s miljø. 2

Installationsprøven er endvidere en Test (generalprøve) af den drejebog for installation af Løsningen, som en udarbejder og leverer forud for Løsningens Idriftsættelse, herunder en verifikation af tidsangivelser på aktiviteterne i denne drejebog. 4.3.1. Systemacceptprøve Systemacceptprøven skal godtgøre, at alle Kontraktens krav er fuldt ud leveret og overholder det aftalte kvalitetsniveau, herunder om integrationer fungerer samt om data er korrekt konverteret og tilgængeligt i Løsningen. Systemacceptprøven inkluderer endvidere verifikation af, at al Dokumentation for Løsningen er leveret og godkendt. Endelig sker der under Systemacceptprøven en afprøvning af, om de processer og værktøjer, der er aftalt og operationaliseret mellem og en under aktiviteten overgang til forvaltning kan godkendes. Systemacceptprøven af Løsningen gennemføres i s miljø. 4.3.2. Delleveranceprøve (Driftsprøve type 1) Delleveranceprøven foregår i s Produktionsmiljø umiddelbart efter idriftsættelse på hver Sygehusenhed. Delleveranceprøven har bl.a. til formål at e, om Løsningen overholder de Servicemål, der er beskrevet i Kontraktens Bilag 5 og 7. Løsningen skal være i drift i minimum 30 dage under hver Delleveranceprøve, hvor Servicemålene skal have været opfyldt i en sammenhængende periode på 20 dage for, at Prøven bestås. 4.3.3.Overtagelsesprøve Overtagelsesprøven tilrettelægges som et review, hvor via statisk- afprøver, om alle krav til Leverancen er opfyldt, ved at gennemgå alle Testrapporterne fra Delleveranceprøverne samt eventuelle Handlingsplaner. 4.3.4. Driftsprøven (Driftsprøve type 2) Den afsluttende Driftsprøve foregår i s Produktionsmiljø efter Idriftsættelse på sidste Sygehusenhed. Driftsprøven har til formål at e om Løsningen overholder de Servicemål, der er beskrevet i Kontraktens Bilag 5 og 7 efter at Løsningen er rullet ud til alle s Sygehusenheder. Løsningen skal være i drift i minimum 30 dage under Driftsprøven, hvor Servicemålene skal have været opfyldt i en sammenhængende periode på 20 dage for at Prøven bestås. 5. Prøver og Tests Nedenstående Tabel 1 indeholder en oversigt over, hvilke Prøver, der som udgangspunkt indgår i Prøveprogrammet samt de Tests, de enkelte Prøver består af. En Test er således at betragte som et delelement af en Prøve. Tabellen angiver samtidig, hvem der er ansvarlig for de enkelte Prøver og Test, samt hvem der er udførende. Prøv e Fabriksprøve Testtyper Beskrivelse Ansvarlig Type System Kontrollere at ens Løsning er funktionsdygtig og har den forventede kvalitet Tester at alle funktioner beskrevet i kravspecifikationen er til stede, og fungerer efter hensigten. Funktionell e 3

Brugervenlig heds Konvertering Sikkerheds Platformsprøve Afprøver Løsningens brugervenlighed, jf. krav herom i hele Kontrakten. Brugervenli gheds Sikre at konvertering af data gennemføres korrekt. Funktionell e Tester at kravene til sikkerhed er opfyldt. Afprøver om Driftsplatformen er korrekt konfigureret og korrekt opsat, jf. specifikationerne angivet af en i Bilag 6. Platforms Indeholder en gennemgang og af om Driftsplatformen er korrekt konfigureret og korrekt opsat, jf. specifikationerne angivet af en. Installationsprøve Systemacceptprøve Forretningsvendte Test Bruger Integrations Statisk Tekniske Afprøver ved installation i et nyt miljø om Løsningen kan installeres og er i funktionsdygtig stand. Tester om et softwareprodukt kan installeres på et givet miljø. Funktionell e Tester grænseflader og integrationer til andre systemer. Funktionell e Sikrer at konvertering af data gennemføres korrekt. Kontrollerer om den aftalte funktionalitet og Dokumentation er leveret, og om Løsningen er korrekt installeret, konfigureret og overholder Servicemålene. Afprøver Løsningens brugervenlighed, jf. krav herom i hele Kontrakten. Tester funktioner, brugerrettigheder, grænseflader og integrationer til andre systemer. / / Installations Integrations Konverterings Funktionelle Brugervenligheds brugervenligheds Funktionelle Tester grænseflader og integrationer til andre systemer. Funktionelle Sikrer at konvertering af data gennemføres korrekt. Tester om den fremsendte Dokumentation opfylder kravene og fremgår af aktivitetsoversigten. Verificerer om alle krav i forhold til driftsafviklingen er på plads, herunder svartidsmålinger, Rapporter, Planer, Processer osv. / Konverterings Funktionelle Dokumentations Dokumentations og Review 4

Svartids Fail-over Genoprettels es Statisk Delleveranceprøve (Driftsprøve type 1) Drifts Statisk Overtagelsesprøve Statisk Driftsprøve (Driftsprøve type 2) Drifts Statisk Tester om Løsningen overholder de specificerede krav til svartider, jf. Bilag 7. Tester, hvor skalerbar Løsningen er. Tester, hvor stabil Løsningen er over længere tids belastning. Test af fail-over scenarier for at sikre at arbejdet i Løsningen kan fortsætte som forventet efter en fail-over er gennemført. Tester, hvor sikkert et softwareprodukt er i forhold til sikkerhedsmæssige trusler. Tester genoprettelsesproceduren efter et nedbrud, hvor der genindlæses en backup. Verificerer om alle krav i forhold til driftsafviklingen er på plads herunder Servicemål, rapporter, planer, processer osv. Delleveranceprøven har bl.a. til formål at e, om Løsningen overholder de Servicemål, der er beskrevet i Kontraktens Bilag 5 og 7. Afprøver Løsningen i en reel drift situation for at konstatere om Servicemål er overholdt i Drift. Verificerer om alle krav i forhold til driftsafviklingen er på plads herunder Servicemål, rapporter, planer, processer osv. Afvikles som et review af alle rapporter og handleplaner fra forudgående prøver og s. Formålet med driftsprøven (type 2) er at konstatere, at Løsningen opfylder Servicemålene, jf. Bilag 5 og 7 efter fuld udrulning til alle s sygehuse. Afprøver Løsningen i en reel drift situation for at konstatere om Servicemål er overholdt i Drift. Verificerer om alle krav i forhold til driftsafviklingen er på plads herunder Servicemål, rapporter, planer, processer osv. Tabel 1 - Oversigt over Prøver og deres Test / / / / Kunde e n Skalerbarheds Stabilitets Sikkerheds Dokumentations og Review Funktionelle Dokumentations og Review Dokumentations og Review en Funktionelle Dokumentations og Review 5

Andre typer, eksempelvis regressions vil være nødvendige i forbindelse med fejlrettelser og lignende mellem de enkelte Delleverancer. 5.1. Startkriterier, Prøver Før en pprøve kan startes, skal en udarbejde en prøveplan for den pågældende Prøve, som er godkendt af s Testmanager. Indholdet af prøveplanen skal stemme overens med afsnittet 6.2, Prøveplaner/Testplaner. 5.2. Startkriterier, Tests Nedenstående, er anført en række kriterier, der skal være opfyldt, før en Test under en Prøve kan afvikles. Der skal være udarbejdet en plan for Testen, der er godkendt af s Testmanager. Løsningen af Krav skal være reviewet og godkendt af hhv. og Kunde. Det betyder konkret, at: - Alle design af udvikling er afsluttet og reviewet. - Alle bare krav der indgår i Testen er registreret i værktøjet. - Alle krav i Testværktøjet er reviewet og godkendt af ens og s Testmanager. Der er udfærdiget cases således, at alle krav er dækket i overensstemmelse med den risikobaserede tilgang til Testen. Det aktuelle miljø for Testen er installeret med den aktuelle version af Løsningen og klar til Test. Det aktuelle miljø er tilført med de relevante data. De nødvendige Testressourcer er endvidere rettidigt booket og til rådighed. 5.3. Slutkriterier, Test En Test er afsluttet, men ikke godkendt, når nedenstående kriterier alle er opfyldt: Alle cases i alle tilhørende set er afviklet uden blokerende Fejl, og har en status. ens og s manager er enige om status på hver enkelt case. Der foreligger en rapport der er reviewet og godkendt af s manager. Testrapporten indeholder en liste over udestående Fejl og handlingsplaner for fejlretning. 5.4. Slutkriterier, Prøver En Prøve er afsluttet, når alle nedenstående kriterier er opfyldt: Forudgående Prøver er afsluttet og godkendt. Alle Tests i Prøven er afsluttet, jf. slutkriterierne som beskrevet ovenfor. Der foreligger en rapport over alle Tests i Prøven, der er godkendt af s manager. Der forligger en prøverapport over prøveforløbet, der er godkendt af s manager. Prøverapporten indeholder en liste over udestående Fejl samt Handlingsplaner for fejlretning. Når ovenstående er på plads, kan der efterfølgende tages stilling til, om Prøven er Godkendt eller Ikke Godkendt jf. afsnit 7.3 nedenfor. 6. Prøve- og dokumentation 6.1. Teststrategi Teststrategien beskriver endeligt, hvilke typer der indgår som en del af Prøveprogrammet og redegør for et overordnet, sammenhængende forløb. 6

Teststrategien beskriver hvilke metrikker, der anvendes for at afgøre om Prøver og Test er afviklet korrekt. Processer og værktøjer skal på en sammenhængende, effektiv og sikker måde håndtere Programmets Prøveprogram. Teststrategien beskriver de enkelte Prøver og Tests omfang, proces, tilgang, teknikker, kriterier, miljøer, data, værktøjer samt en beskrivelse af s deltagelse inkl. roller og ansvar. 6.1.1. Testcases en skal i samarbejde med i Afklaringsfasen udarbejde en proces for, hvorledes identificering, udarbejdelse og vedligeholdelse af cases kan foregå i samarbejde med således, at der tidligt i processen bliver enighed om, hvilke cases der skal til for, at Løsningen kvalitetssikres bedst muligt, herunder sikre, at processen hænger sammen med den risikobaserede tilgang. Der skal være sporbarhed mellem s krav til Løsningen og de cases, der bliver udarbejdet. Det er ens ansvar, at cases identificeres, udarbejdes og struktureres forud for de enkelte Prøver og Tests, dette skal foregå i samarbejde med s Testmanager. Alle cases skal forefindes i det valgte værktøj og skal til enhver tid være tilgængelig for både og en. 6.1.2.Regressionscases en skal udarbejde en proces for, hvorledes identificering, udarbejdelse og vedligeholdelse af regressionscases kan foregå i samarbejde med. Regressionscases skal afvikles i forbindelse fejlrettelser før hver Delleverance. Regressionsen skal kunne afvikles på alle s miljøer, undtagen driftsmiljøet. Regressionsen skal udarbejdes i samarbejde med, og skal være tilgængelig for til en hver tid. Regressionsen kan indeholde relevante cases fra andre typer, inklusiv cases til integrationer. en skal levere regressions cases til, som skal afvikles i forbindelse med enhver leverance, inklusiv leverancer i forbindelse med forvaltningen (Drift). 6.1.3. Testdata en skal i samarbejde med udarbejde en proces for, hvorledes data, oprettes, vedligeholdes, reserveres og systematiseres. Testdata er en vigtig del af enhver Test, og der er derfor behov for, at der opretholdes og vedligeholdes en større mængde data i miljøerne, som skal dække simple data samt komplekst datasæt; som eksempelvis kan være flere forskellige patienter med mere eller mindre komplekse sygedomshistorik. Det er vigtigt, at data i videst mulig omfang indeholder samme kompleksitet som patientdata i produktionsmiljøet. For nogle Tests kan det være nødvendigt at e på komplette datasæt fra produktion. Derudover skal der tage højde for, at data kan reserveres, således andre ere ikke benytter sig af de samme data. 6.2. Prøveplaner/Testplaner For enhver Prøve og Test, der skal gennemføres, skal der udarbejdes en plan. Ansvarsfordelingen i forhold til udarbejdelse af Testplanen en angivet i Tabel 1 - Oversigt over Prøver og deres Test Processen for udarbejdelse af Testplaner og godkendelse heraf følger Processen for udarbejdelse og godkendelse af Dokumentation, jf. Bilag 4. En plan skal som minimum indeholde følgende oplysninger: 7

Kort overordnet beskrivelse af Prøven/Testen og dens formål Prøvens/ens omfang og afgrænsning Operationel tidsplan for Prøven/Testen med angivelse af alle aktiviteter og milepæle (drejebog) Beskrivelse af dækning og risikovurdering Beskrivelse af hvordan der sikres sporbarhed mellem krav og cases Beskrivelse af data, herunder omfang og hvordan de frembringes Beskrivelse af hvilke set, der skal gennemføres med præcis reference til, hvor de forefindes. Testset og cases skal være dokumenteret i et styringsværktøj før en kan starte. Beskrivelse af det miljø Prøven/Testen skal udføres i Beskrivelse af eventuelle værktøjer og metoder, der anvendes. Beskrivelse af de metrikker, der anvendes. Beskrivelse af software, herunder versionsnummer og eventuelt hvilken anden software, der skal være til rådighed. Beskrivelse af hvordan Prøven/Testen gennemføres, inklusiv planlægning, afvikling og rapportering. Dokumentation, der udarbejdes som led i Prøven/Test. Personressourcer, herunder hvilke krav der er til s involvering. Start- og slut kriterier Godkendelseskriterier for Prøven/Testen 6.3. Prøverapport/Testrapport Der skal udarbejdes en rapport over forløbet af en Prøve, samt for forløbet af en Test, der på retvisende måde, dokumenterer Prøvens/Testens resultat. Rapporten skal være i fuldstændig overensstemmelse med de data, der er tilgængelige i værktøjet. Den ansvarlige for udarbejdelse af Prøverapporten/Testrapporten for henholdsvis en Prøve og en Test er den ansvarligefor den pågældende Prøve eller Test jf. Tabel 1. Prøverapporten/Testrapporten skal som minimum indeholde følgende: Dokumentation af at alle cases, eller Tests er gennemført samt resultatet deraf. Hvor mange Fejl, der er fundet i alt og i hvilken fejlkategori/status. Er start- og slut kriterierne opfyldt? Eventuelle afvigelser i forhold til Prøveplan/Testplan (inklusive tidspunkter og involverede personer). Prøve-/Testrapporten skal belyse konsekvenser i forhold til øvrige aktiviteter i Programmet. Prøverapporten/Testrapporten skal indeholder en liste over Fejl og Handlingsplaner for fejlretning Evt. øvrige relevante forhold, herunder om Testen har været afbrudt. Prøveraporten/Testrapporten skal indeholde en anbefaling om, hvorvidt Testen kan betragtes som afsluttet, herunder en handlingsplan for de Fejl, der eventuelt er fundet i forbindelse med Testen. Det er ens ansvar at udarbejde handlingsplanen for udestående Fejl, uanset om en er ansvarlig for den pågældende Prøve eller Test. Prøverapporten/Testrapporten skal godkendes af s Testmanager. 7. Fejlhåndtering 7.1.Fejlhåndteringsproces Til håndtering af Fejl, er der behov for en fejlhåndteringsproces, der sikrer, at Fejl håndteres på en effektiv måde. Tabellen herunder beskriver, hvordan en skal reagere på identificerede Fejl. Testperioden er den periode, der er afsat til selve gennemførelsen af en Prøve eller Test. 8

Kategori Kategori Reaktion ved alle typer Test 1 Kritisk Fejl Identificeres en sådan Fejl under en Prøve eller Test, kan vælge at afbryde Prøven/Testen. Hvis ikke vælger at afbryde Prøven/Testen skal en uden ugrundet ophold udbedre den eller de kritiske Fejl. en skal endvidere levere bindende planer til for, hvorledes den/de kritiske Fejl vil blive udbedret inden for -/prøveperioden. 2 Alvorlig Fejl Se ovenfor vedrørende kritiske Fejl. 3 Betydende Fejl 4 Mindre betydende Fejl Tabel 2 - Oversigt over Reaktioner ved fejl en skal uden ugrundet ophold udbedre den eller de betydende Fejl. Hvis en ikke er i stand til at udbedre den/de betydende Fejl inden for inden for perioden dog maksimalt 5 Arbejdsdage, skal en levere bindende planer til, for hvorledes den/de betydende Fejl vil blive udbedret. en skal levere bindende planer til, der beskriver hvorledes alle Mindre betydende Fejl udbedres. 7.2. Fejlkategorier for funktionelle Tests Kategori Beskrivelse K1 Kritisk Fejl Fejl, der medfører, at væsentlige arbejdsprocesser ikke er mulige at gennemføre, ej heller ved ændringer i arbejdsprocessen, eller væsentlige dele af Løsningen er utilgængelig, og omgåelse er ikke mulig. K2 Alvorlig Fejl Fejl, der medfører, at væsentlige arbejdsprocesser kan gennemføres, men kun med væsentlige ændringer i arbejdsgangen eller omgåelse. K3 Betydende Fejl Fejl, der resulterer i, at mindre væsentlige arbejdsprocesser ikke kan gennemføres eller kun kan gennemføres ved ændringer i arbejdsgangen eller omgåelse. K4 Mindre betydende Fejl Fejl, der ikke hindrer arbejdsprocessen i at kunne gennemføres normalt, eventuelt med mindre ændringer i arbejdsprocessen for at omgå Fejlen. Tabel 3 - Fejlkategori for funktionelle Tests 9

7.2.1.Dokumentations Kategori Betegnelse Fejlkategorier ved statiske Tests: Gælder kun for Dokumentations 1 Kritisk Fejl Dokumentet indeholder Fejl som bevirker, at dokumentet ikke lever op til Kontraktens krav eller til efterfølgende dokumenterede afklaringer. Eller dokumentet indeholder Fejl eller unøjagtigheder, som gør læsningen og forståelsen af dokumentet meget svær eller umulig. 2 Alvorlig Fejl Dokumentet indeholder beskrivelser som er inkonsistente med andre beskrivelser i samme eller andre dokumenter, eller dokumentet indeholder væsentlige Fejl eller formuleringer, som gør det vanskeligt at forstå for den modtagergruppe, dokumentet er tiltænkt. 3 Betydende Fejl Indholdet har behov for uddybning eller præcisering, eller der er andre Fejl, som hverken er kritiske eller væsentlige. 4 Mindre betydende Fejl Tabel 4 - Fejlkategori for Dokumentations 7.2.2. Brugervenligheds Der er mindre Fejl i dokumentet, f.eks. stavefejl, grammatiske fejl eller andre fejl, som ikke hindrer læsning af dokumentet, men som alligevel forstyrrer øjet, der læser. Kategori. Betegnelse Fejlkategorier ved Brugervenligheds 1 Kritisk Fejl Problem af så alvorlig karakter, at det kan risikere at påvirke s troværdighed og/eller patientsikkerheden. Det er svært eller direkte umuligt at gennemføre opgaven eller fortsætte brugen af brugergrænsefladen på en meningsfyldt måde. Brugeren må eksempelvis have hjælp fra andre for at komme videre. Til denne kategori hører også situationer, hvor brugeren synes, at Løsningen forlanger unødvendige oplysninger eller handlinger. 2 Alvorlig Fejl Problem, der er så forstyrrende for brugen af Løsningen, at brugerfejl er uundgåelige samt brugeren benytter uforholdsmæssigt lang tid på at løse en opgave. 3 Betydende Fejl Problem, der er forstyrrende for brugen af Løsningen og indebærer, at brugeren benytter længere tid på at løse en opgave. 4 Mindre betydende Fejl Tabel 5 - Fejlkategori for Brugervenligheds 7.3. Godkendelse af en Prøve Observationer, der ikke har større betydning for brugervenligheden, men som dog generer det generelle indtryk af brugergrænsefladen. En Prøve er godkendt, når godkendelseskriterierne fastsat i dette afsnit er opfyldt. skal senest 10 Arbejdsdage efter at have modtaget rapport med prøveresultatet skriftligt meddele en, om kategoriseringen af Fejl kan godkendes, samt om Prøven er bestået eller ikke bestået med angivelse af Fejl i en mangelliste. En Prøve er bestået, når godkendelseskriterierne er opfyldt. Prøven anses under alle omstændigheder for bestået, hvis ikke inden for 10 Arbejdsdage efter modtagelse af rapport med prøveresultatet har fremsat indsigelser mod prøverapporten. En Prøve er bestået, når Løsningen lever op til følgende krav: 10

Der forefindes ikke flere Fejl end specificeret herunder. Antallet af Fejl i en Prøve er summen af alle åbne Fejl i Prøvens tilhørende Tests: 8. Værktøjer 8.1. Testværktøj - 0 Fejl i kategori 1-0 Fejl i kategori 2-5 Fejl i kategori 3-30 Fejl i kategori 4 en skal benytte et værktøj til planlægning, gennemførelse, styring, sporbarhed og dokumentation af forløbet, herunder oprettelse og styring af fejlrapporter i forbindelse med gennemførelsen. Alle s medarbejdere skal have fuld adgang til værktøjet, således kan benytte værktøjet til at gennemføre de Prøver og Tests, som er ansvarlig for. Ved værktøj forstås software som eksempelvis HP ALM eller tilsvarende. Testværktøjer skal understøtte ens beskrivelse af sine prøvemetoder m.v. i Implementeringskonceptet, jf. Underbilag 3B. 11