Krav i forbindelse med idriftsættelse af nye eller ændrede It-løsninger August 2012

Transkript

1 Krav i forbindelse med idriftsættelse af nye eller ændrede It-løsninger August 2012

2 Indholdsfortegnelse Side 1 Baggrund 3 2 Krav til idriftsættelse Formål Inddragelse af Teknisk Drift It i projektet Overdragelse til drift Ansvar for overdragelse Blivende dokumentation i overdragelsen 11 3 Afprøvning i overdragelsen Roller og ansvar i afprøvning Oversigt over testdokumenter 13 4 Driftsovertagelsesprøve Formål Hvornår Ansvar Afprøvningsmiljø Indgangs- og udgangskriterium Godkendelseskriterier Styringsdokumenter Hovedaktiviteter 17 5 Driftsprøve (accept test) Formål Hvornår Ansvar Afprøvningsmiljø Indgangs- og udgangskriterium Godkendelseskriterier Styringsdokumenter Hovedaktiviteter 25 Krav i forbindelse med idriftsættelse August 2012 Banedanmark Teknisk Drift It Amerika Plads København Ø Forfatter: Teknisk Drift It

3 1 Baggrund Projekterne efterspørger i stigende grad kendskab til krav og ensartede retningslinjer til overdragelse og afprøvning fra Teknisk Drift It i forbindelse med transition til drift. Transitionen sker når ansvaret for en løsning går fra projekt til drift. Nærværende dokument har til formål dels at sikre information til projekterne omkring krav ved idriftsættelse og dels at give ensartede retningslinjer i forbindelse med overdragelsen. Med andre ord beskriver dokumentet de overordnede krav, der kan findes til overdragelse og afprøvning, men der kan være behov for yderligere dokumenter, som driftsorganisationen har behov for, og disse skal aftales i henhold til de specifikke løsninger. Bemærk venligst, at når dokumentet omtaler Teknisk Drift It, skal det forstås som dels Banedanmarks driftsorganisation og dels dennes Driftsleverandører. 3

4 2 Krav til idriftsættelse 2.1 Formål Formålet med at udarbejde krav til og koncept for overdragelse af transitionsprojektet er at sikre: at samtlige nye eller ændrede It-løsninger er tilstrækkeligt afprøvede før overlevering fra projekt til drift at der foreligger de rette driftsdokumenter i en kvalitetssikret tilstand at der foreligger de rette aftaler økonomisk som teknisk - mellem projektet og Teknisk Drift It at understøtte Banedanmarks projektmodel og transitionskoncept 2.2 Inddragelse af Teknisk Drift It i projektet It projektet skal følge Banedanmarks gældende projektmodel gennem faserne fra Ide til Realisering. For at sikre en glidende overdragelse, samt at fange og imødegå eventuelle udfordringer så tidligt som muligt, skal Teknisk Drift It inddrages løbende i gennemførelsen af projektet. Det er projektets ansvar at inddrage Teknisk Drift It og Driftsleverandør(erne); herunder tilsikre afregning og allokering af nødvendige ressource. Allokering sker intern i Banedanmark via teamlead organisation og hos driftsleverandøren via Service Delivery Management. 4

5 Figur 1: Banedanmarks projektmodel Alle projekter opdeles i 5 hovedfaser Idé Idéoplæg> Foranalyse Analyse Anskaffelse Gennemførsel Ledelsesfase > Ledelsesfase Specificering > Udbud Ledelsesfase > Ledelsesfase Realisering Formål Idé kvalificeres og beskrives i et projektoplæg Grundlaget for projektet analyseres og defineres i en række styrings- og beslutnings dokumenter (fx PID og BC) Behov og krav til leverancerne beskrives, og anskaffelse gennemføres Kontrakt Produkt driftes og underskrives og gevinster realiseres i design, udvikling henhold til business (test), idriftsættelse case og gevinstrealiseringsplan og implementering gennemføres Output Godkendt projektoplæg Projektejer udpeget Godkendte styrings og beslutnings dokumenter Projektleder udpeget Kravspecifikation udarbejdet Leverance klar til overdragelse Godkendt projektafslutningsrapport Godkendt gevinstrealiseringsrapport I projektforløbet er der krav om minimum 4 møder mellem projektet og Teknisk Drift It Fase Møde formål Deltagere Agenda Ide Uformel dialog mellem projektet og Teknisk Drift It omkring projektet og krav til drift Projektlederen Teknisk Drift It - It Contract Manager og Change Management repræsentant Driftsleverandør(er) Service Delivery Manager Andre relevante efter behov 1. afgiver info til Teknisk Drift It og Driftsleverandøren omkring indhold, forventet omfang, forventet tidsplan, test strategi og varsler om nødvendige It- Infrastruktur 2. Teknisk Drift It vejleder omkring driftskontrakt, anbefalinger til infrastruktur, drift, afprøvninger og økonomi Analyse skal informere Teknisk Drift It om planer, løsning og forventet - projektlederen Teknisk Drift It - It Contract Manager og Change Management 1. s status, planer og organisering 2. Leveret løsning 3. Forventet indflydelse på driftsbudget 5

6 driftsøkonomi via anvendelse af relevant template repræsentant Driftsleverandør(er) Service Delivery Manager (og Projektleder) Andre relevante efter behov 4. Påvirkning af og/eller krav til Itinfrastruktur 5. Afklaring om behov for ydelsesbeskrivelse eller andre aftaler med 3. part (service aftaler) 6. Aftale afprøvninger (test typer) 7. Afklare eventuelle uddannelsesbehov i Teknisk Drift It og Driftsleverandøren 8. Aftale overdragelsesforløb herunder krav til Teknisk Drift It s deltagelse i implementering, ibrugtagning og afprøvningen Gennemførelse (Ibrugtagning) Overdragelse af ansvar fra projektet til Teknisk Drift It projektlederen Systemejer Teknisk Drift It - It Contract Manager og Change Management Repræsentant Driftsleverandør(er) Service Delivery Manager, Teknisk Kunde Konsulent og Projektleder Andre relevante efter behov 1. s status 2. Godkendelser af driftsovertagelsesprø ve 3. Overdragelse til drift fra projektet via gennemgang og accept af overdragelsesprotokol med følgende delleverancer: Indflydelse på driftsbudget Leverancebeskrivelse Mangelliste Asset liste Aftaler om stabilitetsperiode Driftsprøve Formel godkendelse af overdragelsen projektlederen Systemejer Teknisk Drift It - It Contract Manager og Change Management Repræsentant 1. Gennemgang og accept af Service Level Rapport 2. Godkendelse af driftsprøve 3. Gennemgang af mangelliste (i.e. ingen graverende fejl 6

7 Driftsleverandør(er) Service Delivery Manager (og Projektleder) Andre relevante efter behov i løsningen og/eller at der foreligger en accept af og plan for kendte fejl) 4. Formel accept til overdragelse til drift fra projektet 2.3 Overdragelse til drift Ved overgangen mellem (Fasen: Gennemførelse (og Anskaffelse)) til Drift (Fasen: Realisering) sker der et ansvarsskift, hvor den samlede Itløsning er færdig udviklet og skal ibrugtages. Løsningen overgår herved fra projektet til Teknisk Drift It. Der er derfor fra begge sider en gensidig interesse i at kunne aftale, dokumentere og afprøve at løsningen opfylder de aftalte krav og design for den givne It-løsning gældende alle miljøer; e.g. preproduktion og produktion. Nye idriftsættelser (delleverancer) kræver gennemløb af hele transitionsprocessen for hele og/eller delleverance afhængigt af indholdet. Et projekt kan vælge at tage et system ud af drift ved større ændringer, hvilket betyder, at systemet går tilbage i projektdrift, og der kræves et gennemløb af hele transitionsprocessen igen, før der igen kan garanteres fuld service mål. Projektdrift betyder, at har ansvaret for at varetage driften og afholde udgifter i forbindelse med denne; samt Teknisk Drift It og Driftsleverandørerne er ikke forpligtet til at leve op til service mål. I praktisk kan den daglige drift aftales varetaget af driftsleverandøren suppleret med eskalationsveje til projektet og eventuel hypercare support. Produktionsdrift betyder derimod, at Teknisk Drift It og Driftsleverandørerne har accepteret drift og varetager driften i henhold til den aftalte økonomi og service mål. Der stilles krav til It projektet (transitionsprojekter) om, at der foretages test i Service Transition, før et system kan komme i service operation og derved ibrugtages. Omfang og udførelse af konkrete testtyper afhænger af hvilken Itløsning, der sættes i drift. Omfang og indhold aftales mellem projektlederen og Teknisk Drift It ved planlægning af testen, og denne skal være tilstrækkelig for at sikre en stabil drift og løbende vedligeholdelse. Teknisk Drift It stiller krav til alle It projekter om gennemførsel af en Driftsovertagelsesprøve og en Driftsprøve, hvor det sikres, at der ikke er nogen fejl, der er så alvorlige, at systemet ikke kan sættes i drift, og/eller at der foreligger en plan for udbedring. Se endvidere nedenstående figur, der viser et konceptuelt eksempel på et overdragelsesforløb. 7

8 Figur 2: Genetisk overordnet overdragelsesforløb Projektdrift Drift uden SLA RFC for installation s interne tests er afsluttet RFC for idriftsættelse Ibrugtagning afsluttet RFC for systemidriftsættelse Driftsovertagelsesprøve er Godkendt overdragelsesprotokol Driftsprøve er afsluttet = Fuld drift s interne test Ibrugtagning Driftsovertag elsesprøve Driftsprøve Test fasen Stabliseringsfasen Selve forløbet aftales nærmere mellem projektet og Teknisk Drift It i analysefasen, men hovedaktiviteterne er følgende Aktivitet Forventet tidsforbrug Bemærkning Driftsstatus Intern projekttest Afhænger af It løsningens kompleksitet og projektets planer Omfang og forløb planlægges og godkendes ved projektopstart Den interne projekttest kan løbe ind i ibrugtagningsfasen Projekt har ansvaret, og der er ingen drift fra Teknisk Drift It. Dog kan den underliggende infrastruktur være sat helt eller delvis i drift Installation af infrastruktur Afhænger af It løsningens kompleksitet og omfang. Håndteres via installations RFC Installation af server, storage, netværk og lignende. Der er krav om antivirus på serverne inkl. drift af samme. Indpas i patch management, overvågning og backup i projektdriftsperioden er valgfri, men skal Projekt har ansvaret og der er ingen drift fra Teknisk Drift It. Dog kan det vælges, om den underliggende infrastruktur skal sættes delvist i drift være på plads inden aflevering til drift Ibrugtagning Afhænger af It løsningens kompleksitet og projektets planer har ansvar for at sætte den underliggende infrastruktur helt i It-løsningen har status af projektdrift 8

9 Idriftsættelse hos Driftsleverandør Overdragelse til Teknisk Drift It Fasen afsluttes med drift, inklusiv oppatchning, idriftsættelse RFC af den underliggende opsætning af infrastruktur via Change overvågning, backup Management (1 RFC per etc. enhed) Ibrugtagning skal ikke forveksles med deployment til brugere/klienter, hvilket ikke kan ske i projektdrift skal have forankret instruks i Helpdesken, som minimum skal indeholde informationer om hvor brugere kan henvises til ved problemer eller spørgsmål skal forvente Processen starter mindst 1 måned til ved, at projektet idriftsættelse til håndtering henvender sig til af review af Driftsleverandørens driftsdokumentation og Service Delivery driftsovertagelsesprøver Manager og aftaler fra det tidspunkt, at aftaler projekt- og driftsøkonomi og tidsplan. er indgået med Driftsleverandøren. Driftsdokumentation Varigheden af en sættes i review driftsovertagelsesprøven er hos dog afhængig af indhold, Driftsleverandørens kompleksitet, og TKK er (teknisk løsningsstabilitet kunde konsulent) efter aftale er Forløbet falder typisk i 2 indgået tempi med et 14 dags gennemløb med review af driftsdokumentation og driftsovertagelsesprøve afsluttende med feedback møde. Samt 14 dage til 2. iteration afsluttende med systemidriftsættelse RFC via Change Management 1 uge Gennemløb af change management proces for It-løsningen har status af projektdrift It-løsningen har status af projektdrift, 9

10 Håndtering af plan for udbedring af mangelliste Driftsprøve (stabiliseringsfa sen) Formel overdragelse Evt. nedlæggelse af eksisterende miljø og dokumentation Indtil mangellisten er afsluttet idriftsættelse samt afholdelse af overdragelsesmøde med Teknisk Drift It (accept af overtagelsesprotokoll en) og Change Management. Ved overdragelse skal mangler være udbedret, eller der skal foreligge en accepteret plan for udbedring af fejl og mangler Mangelliste skal forankres i Change Management ved at projektet opretter en eller flere RFC er 3 måneder I perioden er der Møde betinget Service Level. Teknisk Drift It skal leve op til SLA, men er ikke forpligtet til at overholde disse. Hvis der sker en ibrugtagning i forbindelse med driftsprøven, afbrydes driftsprøven i denne periode og genoptages efter endt ibrugtagning. Accept af formel overdragelse 1-2 uger Kun hvis systemet afløser eksisterende infrastruktur. Der skal ske en nedtagning af eksisterende miljø og udtagning af gældende driftsdokumentation eventuelt suppleret med en accepteret plan for udbedring af fejl og mangel. Bemærk betaling af driftsvederlag træder i krav ved overdragelsestidspunktet It-løsningen har status af projektdrift, eventuelt suppleret med accepteret plan for udbedring af fejl og mangel It-løsningen har status af drift uden SLA It-løsningen har status af fuld drift (med SLA) Eksisterende løsning tages ud af drift 10

11 sker via It Change Management 2.4 Ansvar for overdragelse (projektlederen) har ansvaret for planlægning, gennemførelse og godkendelse af overdragelsen til drift; herunder bemanding i henhold til projekt- og driftsorganisationen og tilvejebringelse af alle forudsætninger for igangsætning og gennemførelse af overdragelsen. Det inkluderer udarbejdelse af planer, overdragelsesdokumenter og afprøvning. har ligeledes ansvaret for at tilvejebringe det nødvendige grundlag for at foretage godkendelsen af overdragelsen til drift. 2.5 Blivende dokumentation i overdragelsen Det er et krav, at projekter får udarbejdet, implementeret og godkendt følgende dokumenter, som skal foreligge ved overdragelse til Teknisk Drift It: Leverance beskrivelse SLA aftale Driftsdokumentation Systemdokumentation Installationsvejledninger Vedligeholdelsesaftale med underleverandør Dataaftale mellem BDK og support leverandør. Licens betingelser. Kildekode placeret i BDK TFS, hvis der er speciel udviklet software; samt attest på deponering af standard software (i tilfælde af at leverandøren går konkurs) Idriftsættelses RFC Overdragelsesprotokol Brugervejledninger Driftsbudget (godkendt og allokeret til driftsbudget i Teknisk Drift It) Mangelliste (som forankres i RFC er) Asset liste Stabilitetsperiode forløb (herunder eventuelt hypercare) Test dokumentation Alle dokumenter indgår som element i Overdragelsesprotokollen og er dermed et ufravigeligt accept kriterium. Appendiks Oversigt over blanketter på Tracé indeholder en oversigt over links til nogle af ovenstående blanketter og dokumentation 11

12 3 Afprøvning i overdragelsen Test af It-løsninger involverer en række forskellige test typer. Hver test type adresserer nogle specifikke test krav, som skal valideres. Indeværende dokument omhandler de afprøvninger, som har relation til en idriftsættelse. Valg af test typer, der gennemføres, afhænger i høj grad af kompleksiteten af systemet samt påvirkningen af forretningen, andre systemer, samt kravet til tilgængelighed og eventuel genetablering. Det aftales mellem projektlederen og Teknisk Drift It, hvilke konkrete test typer, der er behov for i forhold til at sikre en efterfølgende sikker og stabil drift. Afholdelsen af alle prøver fastsættes endvidere i samarbejde mellem og Teknisk Drift It for at sikre koordinering i forhold til driftsorganisationen øvrige aktiviteter. I tilfælde af uenighed omkring afholdelsen af prøver har Teknisk Drift It (Contract Manager) ret til at træffe den afgørende beslutning. 3.1 Roller og ansvar i afprøvning Nedenstående tabel beskriver roller og ansvar i forbindelse med de enkelte tests i overdragelsen. Projekt interne test Driftovertage lsesprøve Godkender Prøve Planlægger Gennemfører Fejludbedr er Miljø Produkti onsmiljø Teknisk Drift It Driftsprøve Teknisk Drift It Teknisk Drift It Teknisk Drift It Produkti onsmiljø Produkti onsmiljø Rollen: Planlægger har ansvaret for planlægning af testforberedelse, testgennemførelse og testgodkendelse; herunder ressourceplanlægning, bemanding i henhold til testorganisationen og tilvejebringelse af alle forudsætninger for igangsætning og gennemførelse af test. Det inkluderer udarbejdelse af test planer, test scripts, test protokoller, etc. Planlæggeren har ligeledes ansvaret for at tilvejebringe det nødvendige grundlag for at foretage godkendelsen; i.e. at der sker en godkendelse af afrapportering og godkendelse af alle testdokumenter, samt afrapportering til relevante interessenter. Opsamling på og udarbejdelse af handlingsplan for at imødekomme alle eventuelle betingelser forbundet med godkendelsen (ved en betinget godkendelse). 12

13 Rollen: Gennemfører har ansvaret for den løbende planlægning, gennemførelse og opfølgning på testplan, herunder genplanlægning, hvor testen ikke kan gennemføres som planlagt; samt afrapportering, opfølgning og løsning af fejl og mangler. Rollen: Godkender har ansvaret for foranstaltning af en godkendelsesproces i henhold til godkendelseskriterierne samt for at godkende eller afvise løsningen i sin helhed eller dele heraf. Rollen: Parten, som udbedrer fejl, har ansvaret for opfølgning og udbedring af kvalificerede fejl samt for at udarbejde en handlingsplan, såfremt en udbedring ikke er umiddelbar. Der gøres opmærksom på, at fejl-udbedrer ikke decideret deltager som en del af den konkrete afprøvning og formelle test organisation, men bliver aktiveret i henhold til planen for udbedring af eventuelle mangler, som skal forankres i Change Management. har ansvaret for, at der udarbejdes en plan for udbedring af mangler i forhold til drift, som Teknisk Drift It vurderer som ikke-kritiske; samt planlægning og udbedring af kritiske fejl. Forhold omkring afprøvingsmiljøet: Afprøvning skal foregå i produktionsmiljøet. Hvis det ikke kan lade sige gøre må testen foretages i et produktionslignende miljø med tilhørende risikobeskrivelse af den manglende test i produktionsmiljøet. I tilfælde af overdragelse af flere miljøer, skal alle tests som minimum foregå i det overdragne produktionsmiljø og selektivt i de andre miljøer. Hvis der indgår ændringer, som påvirker eksisterende produktive miljøer såsom idriftsættelse af et nyt interface på Bizztalk platformen, skal der først ske en testing i ikke-produktive miljøer, før deployment og testning i henholdsvis preproduktion og produktionsmiljøet. 3.2 Oversigt over testdokumenter Følgende dokumenter kan blive anvendt i forbindelse med testgennemførslen: 13

14 Dokumenter Beskrivelse Teststrategi Overordnet beskrivelse af den samlede teststrategi og scope. Sætter rammerne for testforløbet, samt hvilke forudsætninger og kriterier dette bygger på. Endvidere skitseres hvilke testleverancer, der findes. Overordnet Testplan Detaljeret Testplan Testrapport Testscenarier og testcases Testdata I henhold til den kommende idriftsættelse skal teststrategien inkludere og opfylde følgende mål: Kontrollere at driftskrav er mødt og testet. Sikre opsætning og opfyldelse af acceptkriterier for idriftsættelse. Sikre kritiske processer for idriftsættelse. Bedst muligt undgå at ukendte fejl dukker op efter ibrugtagningen. Kendte fejl skal dokumenteres og accepteres. Som en del af test strategien skal der skal findes en overordnet test plan, som beskriver de generelle tidslinjer og afhængigheder mellem de enkelte test. Der skal findes en detaljeret testplan for hver test type. Testplanen udarbejdes med udgangspunkt i teststrategien, og er den operationelle beskrivelse af hver enkelt test inkl. en konkret tidsplan, der løbende opdateres under testforløbet. Hver test forløb afsluttes med en testrapport, der dokumenterer, om de forudsætninger og krav, der er opsat i test guiden, bliver opfyldt, herunder identificerede fejl og mangler og evt. fremadrettede risici. Desuden indeholder rapporten en overdragelsesprotokol med en handlingsplan for korrigerende handlinger på baggrund af fejl- og mangellisten. Beskrivelse af henholdsvis testscenarier og case, som kan være indeholdt i test planen Beskrivelse af de data, der skal anvendes i testen til projektet. Kan være indeholdt i test planen 14

15 4 Driftsovertagelsesprøve 4.1 Formål At verificere og dokumentere at Teknisk Drift It er i stand til at levere de aftalte overvågnings-, support- og driftsydelser i den aftalte kvalitet, samt at der er adgang til miljøerne, grænseflader er funktionsdygtige, og driftsdokumentationen for den samlede leverance foreligger og er godkendt. Selve driftsovertagelsesprøven består af en række underliggende test typer såsom: Review af Driftsdokumentation Patch verification Crash og recovery test (D&R test) Administrativ autorisationstest Verifikation af overvågning Deployment test Sikkerhedsevaluering (penetrationstest) Redundans/failover test Test af klient applikationspakke (MSI/SMS) Performancetest 4.2 Hvornår Gennemføres i forbindelse med at alle leverancer er klar til at blive sat i drift. Der kan eventuelt regnes med flere driftsovertagelsesprøver, hvis løsningen består af flere delleverancer, men der skal altid ske en afsluttende driftsovertagelsesprøve. 4.3 Ansvar har det overordnede ansvar for planlægning, gennemførelse, rapportering og fejludbedring af driftsovertagelsesprøven i henhold til krav og gældende tidsplan. Teknisk Drift It har ansvaret for godkendelse. s testkoordinator har ansvaret for, at testen planlægges, gennemføres og rapporteres, herunder at der foretages review og godkendelse samt at det tilsikres deltagelse af projektets ressourcer i henhold til afprøvningsplanen. Hvis Teknisk Drift It skal bidrage med at udføre dele af arbejdet er det ligeledes test koordinatorens ansvar at tilsikre deltagelse i henhold til afprøvningsplanen. 15

16 Ved gennemførelse af driftsovertagelsesprøven deltager Teknisk Drift It for at undgå misforståelser i testafviklingen samt for, om nødvendigt, at yde bistand for testerne. 4.4 Afprøvningsmiljø Driftsovertagelsesprøven omfatter alle miljøer, men eventuelle praktiske test på servicemål, overvågnings- og driftsydelser foretages udelukkende i produktionsmiljøet med produktionslignende data. 4.5 Indgangs- og udgangskriterium Indgangskriterium: Godkendte interne projektprøver samt dokumentation for fejl og mangler. Idriftsættelses RFC er rejst, og overdragelsesprotokol er udarbejdet. Udgangskriterium: Ved accept af driftsovertagelsesprøven kan driftsprøven påbegyndes. I overdragelsesprotokollen skal det fremgå hvilke tests, der er gennemført og med hvilket resultat; samt dokumentation for accept fra Teknisk Drift It. Eventuelle mangler skal være forankret i Change Management. 4.6 Godkendelseskriterier Ved aflevering og afslutning af driftsovertagelsesprøven udarbejdes en overdragelsesprotokol med eventuelle korrigerende handlinger (mangelliste), der skal udbedres efterfølgende. Teknisk Drift It afgør på basis af overdragelsesprotokollen, om It-løsningen kan overdrages, og om afprøvningen kan godkendes. 4.7 Styringsdokumenter Se generelt test leverancedokumentationsafsnit 3.2 over forventede styringsdokumenter i afprøvningen. skal aflevere test dokumentation til Teknisk Drift It som en del af overdragelsesprotokollen. Driftsdokumentation opdateres med driftsmæssige test. Eventuelt kendte fejl/mangler suppleres med en plan for udbedring og forankres i Change Management via RFC er. Teknisk Drift It anvender endvidere tjeklister (venligst referer til Appendiks: Tjekliste vedrørende overdragelse til drif) for at sikre, at alle elementer er varetaget i forbindelse med overdragelse til drift, samt der er krav om overdragelsesprotokol. 16

17 4.8 Hovedaktiviteter Processen starter ved, at projektet henvender sig til Driftsleverandørens Service Delivery Manager og aftaler økonomi og tidsplan. Derefter skal der forventes en varighed på mindst 1 måned, men perioden er afhængig af indhold, kompleksitet og løsningsstabilitet. Selve driftsovertagelsesprøven vil forløbe i flere tempi, da der skal forventes fejludbedring og derefter gentest. Der skal eksempelvis forventes flere review iterationer af Driftsdokumentation. Nedenfor er specificeret de test typer, som kan indgå i driftsovertagelsesprøven. Disse skal endvidere overvejes ved design af driftsovertagelsesprøven. For hver test type er der angivet en prioritet Ultimativt krav = ufravigeligt krav, hvis Teknisk Drift It skal tage fuldt driftsansvar Betinget krav = vigtigt krav men afhængig af kondition og arkitekturen af It-løsningen Enhver fravigelse af test med høj prioritet skal dokumenteres i driftsdokumentationen, overdragelsesprotokollen og SLA aftalen, at det er systemejerens beslutning suppleret med en risikoevaluering. Test type Prioritet: Ansvar: Forventning til gennemførelse Projekt interne test Ultimativt krav Obligatorisk skal være gennemført før driftsovertagelsesprøven kan iværksættes. Det er et ufravigeligt krav, at der skal foreligge en godkendt funktionel test, førend Driftsovertagelsesprøven kan igangsættes. leverer ved driftsoverdragelse en testrapport over foretagne test i projektforløbet; eksempelvis Datakonverteringstest Unit/komponenttest Funktionstest Autorisationstest Interfacetest Integrationstest/Regressionstest (Funktionel driftsovertagelsesprøve) Pilottest Brugertest 17

18 Følgende elementer i transitionen er nogle af de vigtigste at få styr på, inden at den pågældende It-løsning frigives til driftsovertagelsesprøven: Fysisk gennemgang af udstyr samt geografisk placering. Asset registrering og mærkning SLA aftale (Service level agreement) aftaler om levering af services med forretningen. UC (Underpinning contract) aftaler om vedligeholdelse med eksterne leverandører. Overdragelsesprotokol er udført med beskrivelse af dokumentation og test Eventuel plan for og risikoevaluering af nedtagning af overflødige systemer og enheder, som det overdragne system eventuelt må medføre. Uddannelse af modtagende organisation (drift og support): det verificeres, at driftsorganisation har modtaget information og/eller gennemgået uddannelse af driftsydelsen, og at kerneteamet er bemandet og certificeret i henhold til krav samt foretagelse af formel overdragelse til drift. Brugervejledninger forefindes, og der findes en plan for kommunikation til slutbrugerne Driftsbudget og økonomi er aftalt og allokeret, hvor der skal tages stilling til følgende o Drift af server, applikation og database (driftsleverandør) o Vedligeholdelse og videreudvikling af applikation (vedligeholdelsesleverandør) o Uddannelse af brugere o Uddannelse af driftspersonale o Licenser inkl. 1 års vedligeholdelse o Indkøb af reservedele til beredskabslager o Udarbejdelse af brugerguides o Omkostninger til selve transitionen (driftens ressourcer i projektet) eksempelvis: Afholdelse af diverse tests Opsætning af overvågning på applikationsniveau Udarbejdelse og udførelse af nødvendige RFC er Asset mærkning og registrering Udarbejdelse af driftsdokumentation Konsekvens ved fravigelse Deltagere leverer en ikke testet løsning til drift, hvilket betyder, at eventuel fejl ikke er kendte. Dette vil medføre driftsmæssige SLA reduktioner og forbehold. Samt projektet / systemejeren skal forudse en øget udgift til håndtering og løsning af de fejl, som kunne være fanget ved testning. 18

19 Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Driftsdokumentation Ultimativt krav Obligatorisk Der skal findes en driftsdokumentation iht. Banedanmark standard og skabelon Driftsdokumentation skal gennemløbe en review / godkendelses proces med de modtagne organisationer, der indgår som Driftsleverandører Der skal ske afprøvning af driftsdokumentationen såsom driftsvejledninger verifikation af sikkerhedsprocesser (antivirus og lignende) verifikation af at procedure for tilkald af Driftsleverandører (tredjepartsleverandører) eksisterer verifikation af at konfigurationsstyring (assets) er implementeret verifikation af at certifikat håndtering er implementeret verifikation af at licens eksisterer verifikation af at service og vedligeholdelsesaftaler eksisterer verifikation af at den modtagne driftsorganisation er udpeget og på plads Capacity Management (hvis der er specielle krav til opfølgning / rapportering) samt påvirkning på datamængde (af hensyn til fremtidig backup) Kendte fejl og deres håndtering er beskrevet Brugeradministration er beskrevet detaljeret med proces (inkl. en eventuel godkendelsesprocedure), vejledning, og udfører (e.g. helpdesken, superbruger, forvalter, etc.) kan ikke garantere, at driftsdokumentationen er fuldstændig og dækkende for løsningen. Teknisk Drift It kan ikke tage fuldt ansvar Driftsleverandørens Teknisk Kunde Konsulent (som involverer andre relevante bidragsydere) Driftsleverandørens Service Delivery Manager It Contract Management Change Management Eventuel 3. part leverandører Patch verification Ultimativt krav Obligatorisk Systemet er patch et til seneste niveau af alle komponenter; e.g. OS, antivirus, applikation, middleware, etc. 19

20 Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Et eventuelt krav om speciel håndtering af nedlukning / opstart er beskrevet. Der skal ske en fuld og fejlfri genstart af system på baggrund af driftsdokumentation Drift kan ikke accepteres, eller projektet må betale alle omkostninger i forbindelse med eller som følge af oppatchning foretaget af driftsorganisationen. Driftsleverandøren Eventuel 3. part leverandører Redundans/failover test Ultimativt krav Obligatorisk - hvis der er indbygget redundans i løsning, e.g. cluster, load balancer, etc. Denne test skal være gennemført på det system, som overdrages til drift, og der skal tages stilling til hvilke failover test, der skal foretages (manuelt eller automatisk) med en beskrivelse af succeskriterierne. Medfører en driftsmæssigt SLA reduktion/forbehold og krav. Samt projektet / systemejeren skal forudse en øget udgift til håndtering og løsning af de fejl, som kunne være fanget ved testning. Driftsleverandørens Eventuel 3. part leverandører Crash og recovery test (D/R) Ultimativt krav Obligatorisk Recovery proceduren skal være beskrevet i driftsdokumentationen. Recovery testen er en genetableringstest, som skal verificere den tekniske gen-etablering efter et simuleret nedbrud eller via at foretage en mere destruktive test, hvor eksempelvis et netværks- og/eller strømstik fjernes fra serveren mens den kører. Indgår interfaces til øvrige services: skal testen opsættes således, at den afprøver etablering af de eksterne filer, adgang og datastrømme til /fra eksterne enheder/systemer Indgår databaser: validering af at anvendte databaser kan genskabes til et bestemt tidspunkt (RTO og RPO skal være beskrevet og testet). Verifikation af backup er implementeret i henhold til definerede service mål. Eventuel verifikation af beredskabs- / katastrofeplanen hvis idriftsættelsen påvirker katastrofeplanen / beredskabsplanen; i.e. er systemet / applikationen kritisk, er der særlige restore/recovery scenario, etc. 20