Anvendelse af edb i akkrediterede laboratorier Nr. : RL 10 Dato : Side : 1 af 12

Transkript

1 Side : 1 af 12 1 Gyldighedsområde Retningslinien er gældende for alt udstyr, der har indflydelse på kvaliteten af den akkrediterede prøvning/kalibrering på alle laboratorier, som er eller ansøger om at blive akkrediteret til prøvning eller kalibrering, og hvor laboratoriet anvender edb som et element i de akkrediterede aktiviteter. 2 Formål DANAK s retningslinier udtrykker DANAK s tolkning af relevante paragraffer i akkrediteringsstandarder m.m. for at sikre en harmonisering af de vilkår, der pålægges de akkrediterede laboratorier. Denne retningslinie omhandler DANAK s tolkning af specifikke paragraffer i DS/EN ISO/IEC i forbindelse med anvendelse af edb. Afsnitsinddelingen i denne retningslinie følger afsnitsinddelingen i ISO 17025, og der er anvendt følgende tekstformat: Tekst, som er med kursiv, er DANAK s fortolkning af standardens tekst. Tekst markeret med en pind og bilagene er DANAK s vejledning til opfyldelse af kravene. Retningslinien omhandler systemer, der i kompleksitet spænder fra brug af regneark i det akkrediterede laboratorium til store systemer, hvor hele laboratoriets arbejdsgang er baseret på anvendelsen af computersystemer. Alle beskrevne krav vil derfor ikke være relevante for ethvert laboratorium. Som for ISO er det op til laboratoriet på kritisk vis at udvælge de krav, der er relevante og således kunne begrunde, hvorfor øvrige krav er blevet fravalgt. Indholdsfortegnelse 1 Gyldighedsområde Formål Definitioner Krav til ledelse Tekniske krav Referencer Litteraturliste Bilag Ikrafttræden... 12

2 Side : 2 af 12 3 Definitioner 3.1 Validering / verifikation Verifikation er den test/undersøgelse, der udføres for at kontrollere, at det enkelte delsystem eller den enkelte enhed fungerer som krævet i kravspecifikation og testkrav. Validering er den test/undersøgelse og konklusion af deltests, der udføres på samlingen af delsystemer og enheder, når disse er sammensat til det komplette system. Valideringen udføres, når systemet er komplet, dvs. at der ved valideringen også tages hensyn til omgivelser og brugere. Endelig behandler valideringen samspillet mellem systemet (bestående af hardware, software, omgivelser og brugere) og systemets interessenter og vurderer, om systemet fungerer tilfredsstillende og passende i forhold til disse. Validering udføres ofte faseopdelt, således at der foretages design-validering, installations-validering, funktionalitets-validering samt validering af det totale system. Valideringen fås som en samlet konklusion af disse delvalideringer. Validering er dokumenteret bevisførelse, der giver en høj grad af sikkerhed for, at en specifik proces fører til et konsistent resultat, som er i overensstemmelse med de forudbestemte specifikationer og kvalitetsegenskaber. ISO afsnit : Validering bekræfter ved undersøgelse og tilvejebringelse af objektivt vidnesbyrd, at de specielle krav til den givne anvendelse er opfyldt. 3.2 Retrospektiv validering Hvis et system er i drift, og der ikke har været foretaget validering i forbindelse med systemets definition, udvikling og idriftsættelse, og det herefter besluttes, at systemet skal valideres, er der tale om retrospektiv validering. 3.3 Black box / white box En black box er en systemkomponent, hvor det ikke vides, hvordan komponenten er opbygget internt, men hvor funktionen er kendt. Der er altså kendte sammenhænge mellem input- og output for komponenten. En white box er en systemkomponent, hvor man ikke alene kender sammenhængen mellem input og output, men hvor man også kender den interne opbygning af komponenten. 3.4 Livscyklus og livscyklusmodel En livscyklusmodel er en skabelon til kronologisk beskrivelse af en funktionel enhed i alle faser af dens levetid, omfattende alt fra koncept, over kravspecifikation, design, udvikling, opbygning, test, godkendelse, ibrugtagning, ændringsstyring, drift og vedligehold frem til den endelige udfasning.

3 Side : 3 af 12 Enhver funktionel enhed vil kunne beskrives ved en livscyklusmodel; det gælder såvel det overordnede system som de enkelte delsystemer, herunder de edb-programmer, der varetager funktionaliteten. Formålet med at opstille en livscyklusmodel er dels at få udarbejdet en struktureret og ensartet beskrivelse af den enkelte enhed, dels at kunne systematisere den verifikation/validering, som enheden efterfølgende underkastes. Når et system og alle dets delsystemer er beskrevet ved individuelle livscyklusmodeller, vil det være lettere at overskue effekten og de gensidige påvirkninger fra rettelser, ændringer, opdateringer og udfasninger. En livscyklusmodel medtager alle de faser, der er relevante. Et udgangspunkt kan være at medtage alle de faser en enhed skal (eller har været) igennem, og så efterfølgende fravælge dem, der ikke anses for relevante. Et vigtigt element i livscyklusmodellen er dens mulighed for at virke som ændringsstyringsværktøj. Ændringer, der skyldes registrerede fejl, vil ofte kun påvirke de faser, der omfatter test og godkendelse, mens ændringer i funktionalitet vil kræve revision af kravspecifikationen og hermed alle de efterfølgende faser. 3.5 Systemtest Ved systemtest forstås test af programmel i det system og i de omgivelser, hvori det fungerer. Systemet omfatter hardware, software, omgivelser og brugere. 3.6 Rådata Rådata er de data i processen, som man endnu ikke er begyndt at behandle i form af beregninger og tilsvarende. Det er altså de data, der er tættest på processen og tilgængelige for registrering. Eksempel: Når et termometer med en PT 100-føler kalibreres på et termometrilaboratorium, vil de elektriske data være rådata. Når samme termometer anvendes til at overvåge en proces i et kalibrerings- eller prøvningslaboratorium, vil den udlæste temperatur være rådata. 3.7 Hyldevarer Hyldevarer er systemer, instrumenter og komponenter, der kan købes direkte hos en forhandler, uden at der foretages tilretninger fra producentens side for at tilpasse produktet til køberen. Ofte sælges hyldevarer i større antal, således at man som bruger kan forvente, at der er mange brugere af det samme produkt. 3.8 Edb-projekter Projekter, der involverer ændringer af software, hardware, omgivelser eller brugere. I denne terminologi er der derfor tale om et projekt, når der specificeres krav, udvikles og testes ofte i form af verifikationer og validering. Det er vigtigt, at der ved edb-projekter tages hensyn til, at projektet kan influere på andre systemer, arbejdsgange, udstyr o.s.v. 3.9 Risikoanalyse En risikoanalyse er en analyse, der klarlægger, hvilken indflydelse en potentiel fejl i et system vil have for systemets interessenter. Risikoanalysen indebærer, at forskellige risici/potentielle fejl (og sandsynligheden for deres optræden) gennemgås, og påvirkningen vurderes. Ud fra effekten for systemets interessenter kan det besluttes, hvilke forholdsregler der bør tages for at undgå/reducere risikoen ved de forskellige fejlt yper.

4 Side : 4 af Sikker elektronisk kommunikation Ved sikker elektronisk kommunikation forstås overførsel af data, der er sikret mod ændringer, som afsender og modtager ikke er vidende om, og hvor kravet om fortrolighed er overholdt. Kun sikkerhedsforanstaltninger baseret på internationale anerkendte systemer anses for sikre Edb-dokumentation Edb-dokumentation kan f.eks. bestå af: Udstyrsliste Diagram/beskrivelse af edb-netværkskonfigurationen Beskrivelser af adgangsforhold, både fysisk adgang og tilgang til netværket Konfiguration af sikkerhedssystemet Fortegnelse over digitale nøgler og nøgle-certifikater Fortegnelse over software licenser Beskrivelse af konfiguration for kompliceret software Beskrivelse af anvendte algoritmer 4 Krav til ledelse 4.1 Organisation Ad a) og f). Laboratoriet skal udpege en ansvarlig for laboratoriets edb-system. Hvis der er flere personer involveret, skal ansvarsfordelingen være klart defineret. Ad c). Laboratoriet skal have defineret en politik og procedurer for anvendelse af edb, herunder procedurer til beskyttelse af elektronisk opbevaring og overførsel af resultater. Ved indførelse af nye, og ved opdateringer og ændringer af eksisterende edb-systemer, anbefales det at gennemføre edb-projekter som beskrevet i Bilag 1. Denne anbefaling er specielt rettet mod større laboratorier, hvor en sådan organisering er hensigtsmæssig, men kan også anvendes af mindre laboratorier. 4.2 Kvalitetsstyringssystemet Ad Laboratoriets kvalitetssystem skal i nødvendigt omfang omfatte organisation, organisering, brug og drift af laboratoriets edb-system, således at personalet er bekendt med forskrifterne for dette. Laboratoriet bør dokumentere en politik for og procedurer/vejledninger i ansvarlig brug af edb. 4.3 Dokumentstyring Ad Standardens krav til dokumentstyring omfatter alle relevante dokumenter i forbindelse med anvendelse af edb. Ad Hvis der anvendes elektroniske nøgler og/eller nøgle-certifikater, skal der foreligge procedurer for anvendelsen.

5 Side : 5 af 12 Ad Dokumentationen omfatter alle dokumenter, der er relevante, for at edb-systemet kan valideres. Det er laboratoriets ansvar at vurdere og begrunde relevansen. Specifikationer bør versionsstyres, og udviklingsdokumentation og tests bør entydigt vise, hvilken version af testkrav de hidrører fra. Elektronisk arkivering og dokumentstyring kan benyttes, når ovenstående krav om entydighed er opfyldt. Elektronisk signatur på dokumenter kan anvendes, når internationalt anerkendte metoder for elektronisk signering benyttes. Ved transmission af data til kunden, hvor der bruges certificerede nøgle-centre, og hvor loven om ele k- tronisk signatur er overholdt, vil DANAK ikke forlange yderligere dokumentation. 4.4 Gennemgang af forespørgsler, tilbud og kontrakter Ad Stillingtagen til edb er et væsentlig element i forbindelse med standardens krav om gennemgang af forespørgsler, tilbud og kontrakter. Ad a). Laboratoriet skal oplyse kunden om, at elektronisk transmission (ved brug af internettet) uden kryptering ikke opfylder standardens krav om fortrolighed. Ved gennemgangen bør det fastlægges, hvordan rapportering til rekvirenten gennemføres. Der bør aftales regler for arkivering og opbevaring af original rapport samt transmission af data. 4.5 Prøvning og kalibrering udført af underleverandører Ad Ved brug af underleverandør, der ikke er akkrediteret, skal laboratoriet kontrollere, at underleverandøren overholder standardens krav for anvendelse af edb. Ad Hvor resultater fra underleverandør indgår i beregninger til prøvningsrapport eller kalibreringscertifikat, skal transmission og beregninger valideres på samme måde som laboratoriets egne metoder. 4.6 Indkøb af ydelser og varer Ad Standardens krav til indkøb af ydelser og varer omfatter alt relevant edb-udstyr og alle edbydelser i forbindelse med drift af laboratoriet. Ad Hvor dele af laboratoriets edb-arbejde, f.eks. back-up, udføres af leverandører (som kan være laboratoriets egen edb-afdeling), skal det berørte personale være omfattet af de relevante dele af laboratoriets kvalitetssystem. 4.7 Samarbejde med rekvirenten Intet at tilføje.

6 Side : 6 af Klager Intet at tilføje. 4.9 Styring af afvigende prøvninger og/eller kalibreringer Ad Laboratoriet skal have et system til registrering af fejl, når disse optræder. Fejlene og systemets tilstand umiddelbart før og efter fejlens optræden skal registreres, så der med regelmæssige intervaller kan foretages analyse af fejlsituationerne. Disse kan så resultere i korrigerende handlinger, hvor en styret handling defineres, vedtages, implementeres og testes. Ad e). Ansvaret for genoptagelse af drift efter edb-fejl skal være klart defineret. Ad Ved afvigende prøvninger forstås også edb-fejl fundet under drift. Det skal vurderes af bemyndiget personale, om disse fejl er så alvorlige, at fortsat drift ikke er forsvarlig Korrigerende handlinger Ad til Standardens krav for korrigerende handlinger gælder tilsvarende for fejl fundet i edb-systemer. Ad til Der skal tages stilling til, hvorvidt fejl accepteres som de er, om der foretages fejlretninger, eller om brugen af systemet ændres, således at fejltilstandene undgås. Det bemærkes, at et system, der opererer fejlfrit, næsten er umuligt at opnå, hvorimod et system, der opererer med kendte fejl, hvor fejlene enten undgås eller accepteres, er en mere realistisk mulighed. Ad til Fejlretninger skal tilrettelægges, så der ikke sker utilsigtede ændringer andre steder i systemet. En meget væsentlig del af fejlretningen er således testen, hvor den specifikke fejlretning testes, men hvor også de dele af systemet, der vurderes at kunne være påvirket af fejlretningen, gennemgås. Ad til En vigtig del af fejlretningen er at sørge for, at systemets dokumentation opdateres, så det på alle niveauer og i alle livscyklusfaser reflekterer den rettede funktionalitet Forebyggende handlinger Ad til Laboratoriet skal have identificeret potentielle kilder til afvigelser og have defineret, hvilke forebyggende handlinger der er relevante for sikkerheden af edb-systemet. Der er en række forhold, hvor laboratoriet bør være særlig agtpågivende for at forebygge senere problemer med sine eksisterende/nye systemer. Følgende emner kan nævnes: Sikkerhedspolitik Oprette logs for edb-systemets nøglefunktioner Beredskab ved nedbrud Back-up Læsbarhed af back-up også efter systemets udfasning Begrænset adgang til netværk

7 Side : 7 af 12 Firewall Virus beskyttelse Transmission af data på sikker linie Risikovurdering og konsekvensanalyse Sikkerhed Konsekvenser af fravalg og tilvalg Livscyklus Indbrud på laboratoriet: Kan man se, at noget mangler eller er kopieret Anvendelse af log ved brug af edb-netværk Daglig gennemgang af log for brug af edb-netværk Videreførelse af data ved udskiftning af system Afvikling og skrotning af edb 4.12 Styring af registreringer Ad Standardens krav til styring af registreringer, herunder elektroniske registreringer og adgangen til disse, gælder for alle edb-systemer. Ad DANAK s holdning er, at opbevaringstiden for registreringer er mindst 5 år. Ad Hvor der foretages ændringer i elektronisk registrering, skal der i det mindste foreligge en transaktionslog, der viser, at ændringen er foretaget Interne audit Ad til Standardens krav til gennemførelse af interne audit gælder for alle aktiviteter i forbindelse med edb Ledelsens evalueringer Status for anvendelse af edb bør indgå i ledelsens evaluering. Edb-dokumentationen bør være opdateret og tilgængelig ved ledelsens evaluering. Korrigerende og forebyggende handlinger for edb-systemer bør være en del af ledelsens evaluering. 5 Tekniske krav 5.1 Generelt Ad til Mange forhold er bestemmende for rigtigheden og troværdigheden af resultaterne fra de edb-systemer, der benyttes på et laboratorium: Menneskelige faktorer (5.2) Fysiske omgivelser og miljøforhold (5.3) Systemernes validering og verifikation (5.4) Udstyret (5.5)

8 Side : 8 af Personale Ad Ansvaret for laboratoriets systemer, udstyr og metoder skal være definerede og kendte. Ad Personalet skal være uddannet til at betjene det udstyr, de benytter i deres arbejde på laboratoriet. Uddannelsen skal være foretaget, godkendt og registreret af de ansvarlige for systemet, udstyret og metoden, således at en høj grad af sikkerhed for korrekt brug til enhver tid opnås. Ad Der sondres mellem forskellige niveauer, hvorpå medarbejderen kan benytte og betjene systemet, udstyret og metoden, f.eks. som bruger, superbruger, udvikler og administrator. Ad Nye medarbejdere skal gennemgå en uddannelsesrække for at opnå kvalifikationer, så laboratoriets systemer, udstyr og metoder beherskes. Ad Medarbejdernes kvalifikationer skal vedligeholdes, således at edb-systemet altid betjenes korrekt. Ad Der skal foretages løbende registreringer af den enkeltes uddannelse samt indføres tiltag til at sikre, at uddannelsen holdes ajour. Ad Laboratoriet skal foretage en egentlig kursusplanlægning for at sikre laboratoriets evne til at kunne benytte alle systemer, udstyr og metoder samt for at sikre, at personalets kompetence vedligeholdes og udbygges. Ad Laboratoriet skal have ajourførte jobbeskrivelser for personale, der betjener edb-udstyr. 5.3 Fysiske omgivelser og miljøforhold Ad 5.3. Laboratoriets fysiske omgivelser og miljøforhold skal være sådan, at udstyr og personale kan fungere med en høj grad af sikkerhed for, at der ikke optræder fejl på grund af disse faktorer. Dette betyder i praksis, at systemer og udstyr ikke må operere uden for de af fabrikanten specificerede grænser. Det gælder temperatur, fugtighed, EMC-forhold, netspænding osv. Ad Laboratoriet skal kunne dokumentere, at adgangen til det samlede edb-system er under kontrol, såvel fysisk adgangskontrol som tilgang til installationer og netværk. 5.4 Prøvnings- og kalibreringsmetoder og metodevalidering Ad 5.4. Standardens krav til prøvnings- og kalibreringsmetoder og metodevalidering kan, i det omfang laboratoriets brug af edb-systemer er at sidestille med sådanne aktiviteter, principielt anvendes på edbsystemer, -udstyr og software. Ad 5.4. Ethvert system, udstyr og metode skal verificeres og valideres i sin sammenhæng i laboratoriet. Der skal overordnet foretages en dokumenteret bevisførelse, der giver en høj grad af sikkerhed for, at en specifik proces fører til et konsistent resultat, som er i overensstemmelse med de forudbestemte specifik a- tioner og kvalitetsegenskaber.

9 Side : 9 af 12 Ad Laboratoriet skal sikre, at indkøbte edb-systemer ikke tages i brug, før den samlede metode er behørigt verificeret og valideret. Ad Når der er samarbejde mellem laboratoriet og en leverandør, skal man være opmærksom på, at ansvaret for systemets og den samlede metodes verifikation og validering altid er laboratoriets. Et eksempel på validering af software er vist i Bilag 4. Ad Laboratoriet skal verificere og validere sine eksisterende systemer (såkaldt retrospektiv validering). Interessenters behov og krav om pålidelige resultater skal vurderes inden store og bekostelige valideringer initieres. Man bør huske på, at meget af bevisførelsen kan ligge i den omstændighed, at et system har genereret pålidelige resultater igennem et længere stykke tid. 5.5 Udstyr Ad Med udstyr menes systemer og udstyr, der anvendes i laboratoriet, og som på en eller anden måde er en del af processen at generere data til de resultater, som laboratoriet frembringer. Udstyr er således også edb-programmer (software) og firmware, der kan være en integreret del af måleinstrumenter og målesystemer. Udstyr er også programmer (egenudviklede eller kommercielt tilgængelige), der behandler data i form af beregninger og/eller præsentation og lagring af data. Ad Edb-udstyr skal kontrolleres før ibrugtagning. Ad Edb-udstyr skal betjenes af bemyndiget personale, og laboratoriet skal have let tilgængelige brugermanualer for systemer og udstyr. Ad og Alt udstyr, firmware, hardware og software, skal identificeres entydigt. Entydig identifikation af et udstyr indebærer registrering af versionsnummer, serienummer, opsætning og konfiguration m.m. Ad og Laboratoriet skal have systemer, der sikrer registrering og mulighed for genskabelse af tilstande for det enkelte udstyr. Dette krav kan eksempelvis opfyldes ved brug af logbøger og driftsjournaler for alt udstyr. Udstyr skal således være underlagt konfigurationskontrol. Ad og Laboratoriet skal opbevare registreringer og kunne genskabe tilstande for udstyr i mindst lige så lang tid efter udstyret har været i brug, som laboratoriet garanterer mulighed for genskabelse af sine måleresultater. Ad Alt udstyr skal have defineret vedligehold. Det gælder både hardware og software. Ad til Standardens krav til udstyr gælder for al hardware og software, der indgår i laboratoriets edb-system, herunder laboratoriets edb-netværk. Ad til Laboratoriet skal have edb-diagrammer/beskrivelser, der viser opbygningen af laboratoriets edb-netværk.

10 Side : 10 af 12 Ad til Styret og dokumenteret konfiguration af sikkerhedssystemer er en del af den krævede dokumentation for edb-netværk. Ad til Laboratoriet skal have sikker og kontrolleret adgang til edb-netværk. Laboratoriet skal have systemer med adgangskontrol og have sikkerhedssystemer, bl.a. i form af firewalls. Ad til Laboratoriet skal have systemer til backup af sine data samt et beredskab ved nedbrud af sine systemer. Ad til Backups skal være læsbare og kunne geninstalleres, så data kan gendannes også efter at udstyret er afviklet. I dette tilfælde skal data om nødvendigt være konverteret, så andet udstyr kan behandle/genskabe data fra det afviklede udstyr. Ad til Sikkerhedssystemerne skal omfatte fysisk sikkerhed, datamæssig sikkerhed, personalemæssig sikkerhed og sikkerhed mod kriminelle aktiviteter (specielt angreb mod laboratoriets edbsystemer). Ad til Graden af sikkerhed skal være bestemt ud fra risikoanalyser, hvor sikkerheden løbende vurderes som funktion af laboratoriets aktiviteter og omverdenens mulighed for at kompromittere laboratoriets sikkerhed. Der skal rettes speciel opmærksomhed på muligheden for kompromittering af laboratoriets sikkerhed, når der er ekstern adgang til edb-netværket, f.eks. gennem modem-tilslutninger, VPNtilslutninger osv. Sådanne tilslutninger bevirker, at laboratoriets edb-netværk er udvidet til også at dække det udstyr, der er tilsluttet gennem sådanne opkoblinger. Ved overgang fra modem opkobling til fast opkobling på Internettet, f.eks. ADSL opkobling, er det meget vigtigt at montere og konfigurere et sikkerhedssystem, som for eksempel en firewall, korrekt. Ad til Konfigurationen af sikkerhedssystemet skal dokumenteres. 5.6 Målingers sporbarhed Intet at tilføje. 5.7 Prøveudtagning Intet at tilføje. 5.8 Håndtering af prøve- og kalibreringsemner Ad Elektronisk registrering og mærkning af prøve- og kalibreringsemner kan anvendes, hvis det kan godtgøres, at standardens krav er opfyldt. 5.9 Kvalitetssikring af prøvnings- og kalibreringsresultater Intet at tilføje.

11 Side : 11 af Rapportering af resultater Ad Standardens krav til rapportering af resultater omfatter alle former for rapportering genereret og transmitteret af eller ved hjælp af edb. Dette gælder også kravet om fortrolighed. Ad til Hvor laboratoriet anvender elektronisk signatur af rapporter, skal der foreligge dokumenterede procedurer for godkendelse/frigivelse af rapporter. Ad Laboratoriet skal være opmærksom på kravet om fortrolighed, bl.a. i forbindelse med transmission af rapporter og certifikater mellem laboratoriet og kunden (se c). Dette betyder, at laboratoriet skal sikre, at rapporter og certifikater kun kan komme rekvirenten i hænde. Dette skal sikres uafhængigt af, hvordan disse stilles til rådighed for rekvirenten. Det skal understreges, at elektronisk kommunikation er meget udsat for at andre end rekvirenten har mulighed for at få sådanne data til rådighed, samt at rapporter og certifikater usynligt kan ændres. Kravet er således, at data overføres på en sikker linie eller tilsvarende af hensyn til dataintegriteten og fortroligheden. Det anbefales at laboratoriet i sine kontrakter med sine kunder angiver, hvordan transmission af data foregår. 6 Referencer DS/EN ISO/IEC Generelle krav til prøvnings- og kalibreringslaboratoriers kompetence. 7 Litteraturliste DS 484 del DS/EN ISO DS/EN ISO 9001:2000 GAMP guide, version 3 FDA EC GMP, annex 11 Lov om elektronisk signatur, lov nr. 417 af 31. maj 2000 Welmec 7.1 Nordtest metode: "Validering af software til kalibrering og prøvning" 01x699b (p.t. under udarbejdelse) 8 Bilag Bilag 1 : Bilag 2 : Bilag 3 : Bilag 4 : Metode til gennemførelse af edb-projekter Oversigt over krav til laboratoriet Y-modellen Metode til validering af software

12 Side : 12 af 12 9 Ikrafttræden Retningslinien, der erstatter tidligere udgave af , træder i kraft den 15. marts DANAK, den 12. marts 2002 Vagn Andersen / Chef for DANAK Allan Munck / Kvalitetschef

13 Side : Bilag 1 1/8 Bilag 1 Metode til gennemførelse af edb-projekter Fig. A - Projektmodel for edb-projekter RL10 Valideringsplan Brugerkrav Forprojekt: Prototyping Hovedfase A Planlægning Specifikation Review Audit af leverandør Kravspecifikation Projekt og kvalitetsplan Hovedfase B Design Konstruktion Review Udstyr (HW) Software (SW) Omgivelser Uddannelse Hovedfase C Test Godkendelse Review System Godkendelse - Verifikationer System Godkendelse - Validering Hovedfase D Drift Ændringsstyring Vedligehold Uddannelse Udfasning

14 Side : Bilag 1 2/8 Indholdsfortegnelse 1. Projektorganisation Kvalitetsstyringssystemet Dokumentstyring Igangsætning af edb-projekter Gennemførelse af edb-projekter Hovedfase A Planlægning, Specifikation, Review Hovedfase B Design, Konstruktion, Review Hovedfase C Test, Godkendelse, Review Hovedfase D Drift Samarbejde med leverandøren Styring af fejl fundet ved verifikation og/eller validering Korrigerende handling Ændringsstyring Forebyggende handlinger Interne audit Ledelsens evalueringer Projektorganisation I forbindelse med gennemførelse af edb-projekter bør der på laboratoriet opbygges en formel projektorganisation til håndtering af sådanne opgaver, således at roller og ansvar er fastlagt. Bemærk at eksterne personer også kan have roller og ansvar i forbindelse med projektgennemførelsen. Det er muligt, at flere funktioner kan varetages af samme person, men der bør dog i alle tilfælde udpeges en projektleder for projektet. De situationer, hvor der gennemføres projekter, er ved anskaffelse, indkøb og ændringer af edb-systemer. De typiske roller i projektorganisationen er: - Projektleder - Projektdeltager(e) - Kvalitetsansvarlig - Bruger(e) Et projekt starter, når nye behov identificeres. Hyppigt foretages en forundersøgelse, der skal afdække krav og mulige måder at løse behovet på. Når midler er tilvejebragt, nedsættes projektgruppen. Denne skal så sikre, at projektet gennemføres med de beskrevne krav og ressourcer. Det er vigtigt, at projektorganisationen afspejler roller og ansvar, når projektet implementeres, og at der tages hensyn til den totale livscyklus for det nye system, således at roller og ansvar er fordelt i alle projektets faser se fig. A - Projektmodel for edb-projekter.

15 Side : Bilag 1 3/8 I hver fase er der tale om et samarbejde mellem projektorganisationen og laboratoriets normale tværgående organisation, der varetager laboratoriets kvalitetsstyringssystem. 2. Kvalitetsstyringssystemet Det er vigtigt, at der opbygges et kvalitetsstyringssystem til brug ved projektarbejde. Et sådant system overvåger andre parametre end de daglige kvalitetsaktiviteter, men på samme basis, nemlig PDCA-modellen: At der foretages opstilling af mål (Plan), at processerne gennemføres (Do), at der overvåges, og at data registreres og rapporteres (Check), samt at disse data benyttes som grundlag for korrigerende handlinger (Act). Et projekt bør struktureres, så det består af et antal (sammenhængende) aktiviteter, der kan være serielle og/eller parallelt løbende, men alle med det tilfælles, at der kan opstilles input proces output - beskrivelser som gør dem målbare med hensyn til tid og ressourcer. Endvidere bevirker struktureringen, at der kan opstilles (aktivitets) planer, hvor projektets sammenhænge og ansvar er klart defineret, således at projektet kan opdeles i faser med tilhørende reviews, hvor projektets status, fremskridt og godkendelser kan registreres og overvåges. 3. Dokumentstyring I projektforløbet er det vigtigt, at der dokumenteres, således at projektets forløb i form af beslutningsgrundlag og efterfølgende beslutninger og aktiviteter kan spores. Dokumentation frigives i forbindelse med reviews, hvor det er vigtigt, at der foretages en formel frigivelse, så man ikke er i tvivl om, hvorvidt dokumentation er frigivet eller blot er udarbejdet som oplæg. Det er vigtigt, at specifikationer versionsstyres, og at udviklingsdokumentation og tests entydigt viser hvilken version af krav og testkrav, de hidrører fra. Elektronisk arkivering og dokumentstyring kan benyttes, når ovenstående krav om sikker skelnen mellem oplæg og frigivet dokumentation er opfyldt. Elektronisk signatur på dokumenter kan anvendes, når internationalt anerkendte metoder for elektronisk signering benyttes. 4. Igangsætning af edb-projekter Ofte er edb-projekter startet, fordi laboratoriet ønsker at imødekomme ønsker fra kunder om en ny eller opdateret ydelse. Det er vigtigt at gøre sig klart, hvad det indebærer at skulle levere ydelsen inden tilbud udsendes. Det kan være en fordel at starte et edb-projekt således, at gennemgang og analyse foretages på en styret og kontrolleret måde. 5. Gennemførelse af edb-projekter I fig. A er vist en Projektmodel for edb-projekter. Som det fremgår, bør et edb-projekt være opdelt i et antal hovedfaser, der alle er underinddelt i delfaser. Hovedfaserne bør være:

16 Side : Bilag 1 4/8 A. Planlægning, Specifikation, Review B. Design, Konstruktion, Review C. Test, Godkendelse, Review D. Drift 5.1 Hovedfase A Planlægning, Specifikation, Review I denne fase formuleres projektet baseret på kravene i denne retningslinie, laboratoriets generelle valideringsplan og kravene fra brugere og øvrige interessenter til det nye system. Det kan være nødvendigt at gennemføre et forprojekt, hvor krav og ønsker afprøves i en prototype af det endelige system. (Man skal bemærke, at der tids- og ressourcemæssigt er meget langt fra en fungerende prototype til det endelige validerede og idriftsatte system). Ud fra erfaringerne fra forprojektet kan en foreløbig kravspecifikation sammenfattes, og egnede leverandører søges. Laboratoriet bør være omhyggelig i valget af leverandører, og bør eksempelvis ved pre-audit af de potentielle leverandører sikre sig, at disse er i stand til at levere systemer, der lever op til de funktionelle krav, og som kan valideres af laboratoriet. Kravspecifikationen forbedres løbende under diskussionerne med de potentielle leverandører, således at den når valget af leverandør træffes er færdig og dermed klar til brug for næste fase, Design og Konstruktion. En måde at forbedre kravspecifikationen på er ved løbende at indhente input fra projektets interessenter og ved afholdelse af reviews, hvor projektets interessenter mødes og vedtager de endelige krav. Det skal påpeges, at der parallelt med kravspecifikationen bør udarbejdes en testspecifikation, således at gennemførelse af test efter denne specifikation på det udviklede system gennem objektive målbare tests og testkriterier vil vise, om det endelige system lever op til de stillede krav. Testspecifikationen er, på lige fod med kravspecifikationen, et konfigurationsstyret dokument, der danner grundlag for de senere fasers aktiv i- teter. 5.2 Hovedfase B Design, Konstruktion, Review Delfaserne for Hovedfase B er fokuseret på de parallelle aktiviteter vedrørende hovedbestanddelene i det endelige system og er relateret til Udstyr (Hardware), Program(mer) (Software), Omgivelser (lokaler) og Uddannelse (brugere). Generelt kan det siges, at kravene til det endelige system og dets frigivelse til verifikation og validering skærpes, både som funktion af den betydning systemet har for laboratoriets virke, og som funktion af den betydning resultaterne af laboratoriets arbejde har for liv og død. Det er vigtigt at tage hensyn til Hovedfase A s valideringsplan i forbindelse med Design, Konstruktion og Review, da kravene til disse aktiviteter er forskellige og funktion af den verifikation og validering systemet skal gennemgå i den senere Hovedfase C.

17 Side : Bilag 1 5/8 Det anbefales, at der - parallelt med udarbejdelse af specifikationerne for delsystemer og moduler - udarbejdes testspecifikationer for disse. Specifikationer skal være konfigurationsstyrede dokumenter. Ved Design og Konstruktion indkøbes og udvikles udstyr og programmer, lokaler indrettes til det nye udstyr, og brugere (på forskellige niveauer) uddannes til at varetage brugen af systemet. I løbet af Hovedfase B afholdes et antal reviews, der benyttes til synkronisering af projektets parallelle aktiviteter og til at vedtage justeringer i forhold til planer og krav. Reviews skal være dokumenterede således, at der er sporbarhed med hensyn til opfølgning og justeringer. 5.3 Hovedfase C Test, Godkendelse, Review Hovedfase C benyttes til at verificere og validere, at det nyligt designede og konstruerede system lever op til kravene i den overordnede valideringsplan og i testspecifikationerne der, som beskrevet ovenfor, findes på flere niveauer (system-, delsystem- og modulniveau). Normalt verificeres på delsystem- og modulniveau, mens der valideres på systemniveau. Kravene til verifikation og validering afhænger af systemets resultaters betydning for systemets interessenter. En risikoanalyse udarbejdes til afdækning af denne betydning. Normalt vil der være udarbejdet verifikationsog valideringsprotokoller som en del af testspecifikationerne. Disse protokoller beskriver acceptkriterierne for systemet. For yderligere at bestemme graden af den nødvendige verifikation og validering må man se på systemets totale opbygning i form af udstyr, programmer, omgivelser og uddannelse. Nedenfor er angivet en inddeling i kategorier for hver enkelt af de fire systemelementer. Ud fra disse kategorier besluttes graden af verifikation og validering med skyldig hensyntagen til, at jo højere kategori, jo større krav til verifikation og validering for at sikre at systemet fungerer passende. For Udstyr (Hardware) kan det generelt siges, at der er muligt at inddele i 3 kategorier: Kategori 1: Kategori 2: Kategori 3: Hyldevarer fra anerkendt fabrikant Hyldevarer fra mindre kendt fabrikant Specialfremstillet hardware For Programmer (Software) kan det generelt siges, at det er muligt at inddele i 5 kategorier: Kategori 1: Kategori 2: Kategori 3: Kategori 4: Kategori 5: Operativsystemer Standard Instrumenter med indbygget Software Standard Software Pakker Konfigurerbare Software Pakker Specialudviklet Software

18 Side : Bilag 1 6/8 For Omgivelser kan det generelt siges, at det er muligt at inddele i 3 kategorier: Kategori 1: Kategori 2: Kategori 3: Hvor omgivelserne praktisk taget ikke spiller nogen rolle for systemets funktion Hvor omgivelserne spiller nogen rolle for systemets funktion Hvor omgivelserne spiller en stor rolle for systemets funktion For Uddannelse kan det generelt siges, at det er muligt at inddele i 2 kategorier: Kategori 1: Kategori 2: Hvor uddannelsen spiller en mindre rolle for systemets funktion, altså hvor brugeren kan betjene systemet korrekt efter almindelig uddannelse. Hvor uddannelsen er meget vigtig for korrekt betjening af systemet, altså hvor brugeren ikke blot skal have en almindelig uddannelse, men samtidig være specialist på området for at kunne betjene systemet korrekt. Resultaterne af de udførte verifikationer og valideringer sammenfattes i en valideringsrapport, og godkende l- se finder sted i forbindelse med afholdelsen af reviews. Hovedfase A, B og C kan sammenfattes i den såkaldte Y-model der er en model for specifikation af krav og testkrav samt for implementation og benyttelse af disse krav i forbindelse med verifikation og validering af systemet. Denne er vist i Bilag Hovedfase D Drift Der henvises til afsnit 5 i retningslinien. 6. Samarbejde med leverandøren Når der i edb-projekter er samarbejde mellem laboratoriet og en leverandør, skal man være opmærksom på, at ansvaret for systemet og dets verifikation og validering altid er laboratoriets dette ansvar kan ikke videregives til en leverandør. Det er laboratoriet, der udarbejder og godkender valideringsrapporten leverandøren kan levere resultater, der underbygger, at valideringen kan gennemføres og godkendes. 7. Styring af fejl fundet ved verifikation og/eller validering I forbindelse med udførelsen af tests vil disse enten give acceptable eller afvigende resultater i forhold til det forventede/specificerede. Ved review af testresultater skal der tages stilling til, hvorvidt afvigende resultater skal accepteres som de er, om der skal foretages fejlretninger, eller om brugen af systemet skal ændres således, at fejltilstandene undgås. Det bemærkes, at et system der opererer fejlfrit næsten er umuligt at opnå, hvorimod et system, der opererer med kendte fejl, hvor fejlene enten undgås eller accepteres, er en mere realistisk mulighed.

19 Side : Bilag 1 7/8 8. Korrigerende handling Laboratoriet skal have et system til registrering af fejl, når disse optræder. Fejlene og systemets tilstand umiddelbart før og efter fejlens optræden skal registreres, så der med regelmæssige intervaller kan foretages analyse af fejlsituationerne. Disse kan så resultere i korrigerende handlinger, hvor en styret handling defineres, vedtages, implementeres og testes. Fejlretninger er ofte meget vanskelige at foretage, fordi rettelsens påvirkning af systemet skal vurderes, så der ikke sker utilsigtede ændringer andre steder i systemet. En meget væsentlig del af fejlretningen er således testen, hvor den specifikke fejlretning testes, men hvor også de dele af systemet, der vurderes at kunne være påvirket af fejlretningen, gennemgås. En vigtig del af fejlretningen er at sørge for, at systemets dokumentation opdateres, så det på alle niveauer reflekterer den rettede funktionalitet. 9. Ændringsstyring Registreringer kan benyttes til registrering af ønsker om ny/forbedret funktionalitet i systemet og af udførte ændringer i form af opdateringer etc. Det er vigtigt at identificere påvirkninger af systemet og dets dokumentation i forbindelse med indførelse af ændringer. Laboratoriet skal kunne dokumentere sporbarhed fra de første verifikationer og valideringer af systemet, gennem enhver ændring, opdatering og fornyet validering, til det niveau systemet til enhver tid befinder sig på. 10. Forebyggende handlinger I forbindelse med gennemførelse af edb-projekter er der en række forhold, hvor laboratoriet skal være særlig agtpågivende for at forebygge senere problemer med sine eksisterende/nye systemer. Der skal her nævnes: - Sikkerhedspolitik - Oprette logs for edb-systemets nøglefunktioner - Beredskab ved nedbrud - Back-up - Læsbarhed af back-up også efter systemets udfasning - Begrænset adgang til netværk - Firewall - Virus beskyttelse - Transmission af data på sikker linie - Risikovurdering og konsekvensanalyse - Sikkerhed - Konsekvenser af fravalg og tilvalg - Livscyklus - Indbrud på laboratoriet: Kan man se, at noget mangler eller er kopieret - Anvendelse af log ved brug af edb-netværk - Daglig gennemgang af log for brug af edb-netværk - Videreførelse af data ved udskiftning af system - Afvikling og skrotning af edb

20 Side : Bilag 1 8/8 Et laboratorium er en del af en dynamisk verden, og udviklingen i omverdenen kan bevirke, at sikkerheden pludselig bliver utidssvarende. Systemerne og deres sikkerhed må derfor jævnligt revurderes og eventuelt opdateres, så kravene til sikkerhed opfyldes. 11. Interne audit Laboratoriet bør foretage interne audit på det kvalitetssikringssystem, der benyttes til gennemførelse af edbprojekter på linie med de interne audit, der foretages på laboratoriets almindelige kvalitetssikringssystem. Det kan være vanskeligt at planlægge audit på samme måde som i det rutinemæssige arbejde, da projektets forløb i sin natur er en løbende proces. Dette skal der tages højde for ved planlægning af audit, så relevante dele af projektet auditeres, efterhånden som projektet skrider frem. Laboratoriet skal være opmærksom på, at en auditor ikke kan auditere det arbejde, vedkommende selv udfører eller har udført. 12. Ledelsens evalueringer Ethvert edb-projekt bør følges op med et review af projektets gennemførelse. Det vil være projektlederens opgave at konkludere, i hvor høj grad projektet har levet op til de mål og forventninger, laboratoriet havde ved dets specifikation og gennem projektforløbet. Det er meget udviklende for laboratoriets evne til at håndtere projekter effektivt, at denne evaluering foretages grundigt, og at konklusionerne dokumenteres, så laboratoriets erfaring i edb-projekters gennemførelse gradvist øges.

21 Side : Bilag 2 1/1 Bilag 2 Oversigt over krav til laboratoriet 1 Identificér system Hvert system, der er frembringer resultater til laboratoriets interessenter, skal identificeres. 2 Udarbejd valideringsplan 3 Udarbejd kravspecifikation 4 Audit og udvælg leverandør 5 Review og godkend specifikationer 6 Overvåg systemudviklingen 7 Review og godkend testspecifikationer 8 Review og godkend testrapporter 9 Udarbejd valideringsrapport Valideringsplanen er et sammenfattende dokument - udarbejdet af laboratoriet, der definerer aktiviteterne, fremgangsmåden og ansvaret for at etablere en passende virkemåde for systemet. Kravspecifikationen er udarbejdet af laboratoriet for klart og entydigt at definere, hvad laboratoriet kræver, at systemet skal kunne og for at definere begrænsninger, lovmæssige krav og krav til dokumentation. Valget af leverandør bevirker, at laboratoriet skal auditere potentielle leverandører og forklare kravene i forbindelse med Valideringsplan, Kravspecifikation og denne retningslinie til leverandøren. Laboratoriet skal i fællesskab med leverandøren videreudvikle specifikationer for systemets opbygning og virkemåde og godkende disse i forbindelse med afholdelse af reviews. Laboratoriet har det overordnede ansvar og skal deltage i systemudviklingen sådan, at udviklingen overvåges i henhold til implementationsplanen. Testspecifikationerne udarbejdes parallelt med specifikationerne for systemet. Disse skal være godkendt inden udviklingen afsluttes, således at en vedtaget formaliseret test kan ligge til grund for den endelige verifikation og validering. De vedtagne tests gennemføres. Når testen er succesfuldt udført, reviewes og godkendes testrapporterne. Valideringsrapporten er en sammenfattende rapport, der udarbejdes af laboratoriet. Rapporten sammenfatter resultaterne af det udførte arbejde og den udarbejdede dokumentation samt de udførte tests i henhold til valideringsplanen. Rapporten godtgør, at laboratoriet har ført passende bevis for det nye systems virkemåde. 10 Vedligehold systemet Når systemet er valideret og godkendt, skal laboratoriet sikre, at der udføres formel vedligehold og ændringsstyring, samt at sikkerhedsprocedurerne er passende, og at disse følges i praksis. Fig. B - Oversigt over krav til laboratoriet

22 Side : Bilag 3 1/1 Bilag 3 Y-modellen Hovedfase A, B og C i et edb-projekt (Bilag 1Anneks A) kan sammenfattes i den såkaldte Y-model, der er en model for specifikation af krav og testkrav samt for implementation og benyttelse af disse krav i forbindelse med verifikation og validering af systemet. Fig. C Y-modellen Specifikation af krav Overordnede krav og planlægning Test specifikation Valideringsplan Kravspecifikation og system design Systemtest specifikation Modulkrav og højniveau design Integrationstest specifikation Detail design Enhedstest specifikation Implementering Test af enheder Integration og test af integration Systemtest Validering Tid

23 Side : Bilag 4 1/6 Bilag 4 Metode til validering af software Denne metode kan anvendes af medarbejdere, der bruger, udvikler og verificerer/validerer software. Fase 1 Kravspecifikation og systemtestspecifikation Input Output Funktionalitet Platform / systemkrav Særlige krav Dokumentationskrav Service og vedligeholdelse A Fase 2 Design og konstruktion Design- og udviklingsplan Design input / analyse af krav Design output / kodning Design verifikation Design ændringer B Fase 3 Inspektion og test Udarbejdelse af testplan Inspektion og granskning Test og afprøvning C Fase 4 Forholdsregler Registrering og afhjælpning af konstaterede og kendte anomaliteter C Fase 5 Installation Dokumentation af installation Test af installations procedure Test af installeret programmel C Fase 6 Drift, service og ve d- ligeholdelse Problem identifikation / løsning Funktionel vedligeholdelse Forbedring af performance Ændringer Opdatering til nye versioner Udfasning / skrotning D Fig. D - Livscyklusmodel til validering af software Bogstavet i nederste højre hjørne af hver fase viser relationen til Hovedfaserne A, B, C og D i Bilag 1: Metode til gennemførelse af edb-projekter.

24 Side : Bilag 4 2/6 1. Software kategori Udvikling, verifikation og validering Livscyklusmodellen Fase 1 Kravspecifikation og systemtestspecifikation Fase 2 - Design og konstruktion Fase 3 - Inspektion og test Fase 4 - Forholdsregler Fase 5 - Installation Fase 6 - Drift, service og vedligeholdelse Valideringsrapport... 6 Software kategori I bilag 1, pkt. 5.3 inddeles software i 5 kategorier. Denne metode omfatter software i Kategori 5: Specialudviklet Software. Til software i denne kategori hører programmer og regneark, som laboratoriet selv udvikler eller køber. Metoden fokuserer på de forhold, der skal tages i betragtning under udvikling af ny software, men kan også anvendes ved retrospektiv validering. Metoden kan bruges ved validering af: - Indkøbt software, der ikke er standard- eller konfigurerbare softwarepakker - Selvudviklet eller indkøbt software, hvor programkoden er kendt - Nyudviklet software, hvor udviklingen er under laboratoriets kontrol Regneark er programmer, der ofte er udviklet af laboratoriets egne medarbejdere. De skal valideres som alle andre programmer, men der skal særlig opmærksomhed på den omstændighed, at et regneark har en meget åben brugergrænseflade og derfor er meget sårbar. 2. Udvikling, verifikation og validering Under udvikling af ny software er der undervejs behov for at teste hele eller dele af programmet. Test af software under udvikling er derfor de tests/undersøgelser, der godtgør, at udviklingen forløber som planlagt. Software skal valideres. For software opfattet som en isoleret funktionel enhed er validering den test/undersøgelse, der godtgør, at kravspecifikationerne til programmet er overholdt, og at programmet fungerer passende i sit miljø. Software skal valideres i den sammenhæng, hvori det anvendes i laboratoriet. Ved den endelige validering af det samlede computersystem kan de isolerede software tests betragtes som verifikationer af de programmer, der indgår i det samlede system. 3. Livscyklusmodellen I fig. D er vist en Livscyklusmodel til validering af software. Validering bør omfatte alle faser af et programs livscyklus, således at der ikke på noget tidspunkt under brugen indtræffer ubehagelige hændelser, som kan tilskrives fortidens synder. Valideringens omfang og graden af detaljer skal sættes i relation til programmets anvendelse og risikoen ved eventuelle fejl, og den foreslåede model vil kunne udvides eller reduceres som funktion af risikoanalysen. De grundlæggende faser bør være: 1. Kravspecifikation og systemtestspecifikation

25 Side : Bilag 4 3/6 2. Design og konstruktion 3. Inspektion og test 4. Forholdsregler 5. Installation 6. Drift, service og vedligeholdelse 3.1 Fase 1 Kravspecifikation og systemtestspecifikation Grundlaget for validering af software er krav- og systemtestspecifikationer, som beskriver de krav, der skal være opfyldt, f.eks. krav til funktion, betjening, dokumentation og systemtest. Der vil altid kunne udarbejdes en kravspecifikation. Ved retrospektiv validering, hvor man ikke skal igennem en udviklingsfase, vil man kunne udarbejde en kravspecifikation, der beskriver hvordan programmet rent faktisk fungerer. Ved udarbejdelse af kravspecifikation for regneark, bør man specielt være opmærksom på, at brugergrænsefladen er meget åben, og derfor bør man kræve, at der enten tages programmeringsmæssige skridt til sikring mod forkert betjening, eller at betjeningen beskrives fyldestgørende, f.eks. hvad man må og hvad man ikke må. Regneark bør altid baseres på selvstændige skabeloner ( templates ) og ikke på modificerede udgaver af tidligere anvendte regneark. En kravspecifikation bør omfatte alt, der vedrører brugen af programmet, f.eks.: - Formål (hvad skal programmet bruges til) - Input (beskrivelse af input-data, f.eks. medie, form, grænseværdier osv.) - Output (beskrivelse af output-data, f.eks. medie, form, grænseværdier osv.) - Funktionalitet (faciliteter og valgmuligheder) - Defaults (hvad skal programmets standardopsætninger være) - Begrænsninger (hvilke begrænsninger accepteres i programmet) - Platform (f.eks. hvilken version af Windows og/eller Excel skal understøttes) - Sikkerhed (foranstaltninger til sikring af korrekt input, mod overflow m.m.) - Versionsstyring (hvordan skal forskellige versioner af programmet mærkes) - Hjælp (krav til dokumentation/on-line hjælp m.m. for korrekt betjening) - Særlige krav (f.eks. risiko i forbindelse med fejl i programmet) - Krav til vedligeholdelse og opdatering En systemtestspecifikation skal indeholde objektive kriterier for, hvordan kravspecifikationen kan testes at være opfyldt. 3.2 Fase 2 - Design og konstruktion Designfasen (udviklingsfasen) er relevant, når man skal udvikle ny software, herunder nye regneark. Output fra denne fase vil være et program, der er afprøvet og godkendt til test. Designfasen kan være mere eller mindre omfattende afhængig af, om det er et simpelt regneark eller et stort komplekst program, der skal udvikles, om der er en eller flere personer involveret, om der er særlige krav til robusthed af programmet osv. Designfasen kan opdeles i 5 underfaser:

26 Side : Bilag 4 4/6 Design- og udviklingsplan. Der skal udarbejdes planer for design- og udviklingsaktiviteter således, at ansvar og arbejdsdeling er fastlagt (Bilag 1, pkt. 5.2). Der skal være planer for hvilke dele af programmet, der skal underkastes test, og efter hvilke kriterier disse skal godkendes. Før kodningsarbejdet påbegyndes, skal det være besluttet, hvilke værktøjer der benyttes. Disse beslutninger kan være truffet på forhånd (som en del af laboratoriets kvalitetssystem), kan være angivet i kravspecifikationen/designplanen eller kan træffes af de personer, der skal forestå udviklingen. Man skal gøre sig klart, at valideringskravene til de valgte værktøjer, er de samme som dem, der stilles til software i Kategori 3: Standard Software Pakker og Kategori 4: Konfigurerbare Software Pakker (se Bilag 1, pkt. 5.3). Design input / analyse af krav. I denne underfase udformes, med udgangspunkt i kravspecifikationen, de arbejdspapirer (f.eks. blokdiagrammer, flowcharts m.m.), der skal danne grundlag for den egentlige kodning. Desuden analyseres kravspecifikationen for at konstatere, om kravene er realisable, eller om kravspecifikationen skal revurderes. Design output / kodning. Det forventede output fra denne fase er et testbart program ledsaget af dokumentation i form af kildekode, oplysninger om værktøjer og metoder, samt notater og beskrivelser, der gør det muligt senere at validere det udførte arbejde. F.eks.: - Kodning (anvendte oversættere og kodningsværktøjer, f.eks. debugger ) - Versionsstyring (hvordan ændringer i kildekode er versionsmærket) - Udført test (test, der er gennemført for om muligt at sikre fejlfri kode) - Faciliteter (funktioner, der er indbygget til test af programmet) - Inaktiv kode (afprøvet kode til test og/eller fremtidige forbedringer) - Dokumentation (bruger-manual og -vejledninger) - Testspecifikation (modul- og integrationstest) Design verifikation. Verifikation og godkendelse af hele eller dele af den udviklede software således som beskrevet i design- og udviklingsplanen. Design ændringer. Denne underfase er tænkt som indgang til designfasen, når der er konstateret fejl eller besluttet funktionelle ændringer, som kræver ændring i koden. I denne fase skal omfanget af ændringerne besluttes og konsekvensen vurderes, herunder om ændringerne kræver en revision af krav- og systemtestspecifikationerne. 3.3 Fase 3 - Inspektion og test Første trin i testen kan være inspektion af direkte tilgængeligt materiale, f.eks. den dokumentation, der kommer fra design processen. Medlæsning af kodeudskrifter kan anbefales, men arbejdet kan ofte reduceres til konstatering af dokumenterede dynamiske tests udført under udviklingsforløbet. Dynamisk test er test, der afprøver programsekvenser, som kun aktiveres under omstændigheder, der ikke umiddelbart kan etableres, når programmet er færdigt. Sådanne omstændigheder må derfor simuleres og kan kræve midlertidige (dynamiske) modifikationer af koden. Før software kan testes, skal der udarbejdes en testplan. Testplanen bygger på krav- og systemtestspecifikationer og skal helst udarbejdes af andre personer end dem, der har udviklet programmet. Test som led i retrospektiv validering af programmer, hvor koden ikke er kendt, adskiller sig således ikke fra test af nyudviklet software. En testplan kan f.eks. omfatte følgende områder: - Formål med test (hvad skal testes, hvorfor og hvordan)