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

21 Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Manglende recovery test medfører en SLA reduktion/forbehold og krav til projektet / systemejeren om betaling af alle driftsmæssige omkostninger, som måtte kunne henføres til manglende recovery procedure og verifikation af samme. Teknisk Drift It kan ikke tage ansvar for backup og recovery; herunder Disaster /Recovery Driftsleverandørens Managed Server kompetencer og eventuel database og netværks-kompetencer Eventuel 3. part leverandører Sikkerhedsevaluering (penetrationstest) Ultimativt krav Obligatorisk Der skal forefindes en godkendt sikkerhedsevaluaring af It- Sikkerhed Når der findes mulighed for penetration udefra, bør der ske en penetrationstest afhængig af sikkerhedsevalueringen. Test af systemets sårbarhed samt beredskab til at modstå evt. penetration eller følgerne heraf. Teknisk Drift It kan ikke påtage sig ansvaret for systemet, hvis der ikke foreligger en godkendt sikkerhedsevaluering Banedanmarks Sikkerhedsafdeling Driftsleverandørens netværks-kompetencer Eventuel 3. part leverandører Administrativ autorisationstest Ultimativt krav Obligatorisk. Autorisationstest skal sikre, at de enkelte administrative brugere af systemet har rettigheder til at udføre præcist de opgaver i systemet, som de i henhold til deres arbejdsområde er berettiget til. Endvidere at adgange (username og password) er specificeret i rette password stores. I forbindelse med denne test, lukkes adgang for alle andre end Driftsleverandøren. Adgang til systemet er begrænset eller umuliggjort. Driftsleverandøren Verifikation af overvågning Ultimativt krav Obligatorisk. Verifikation af at overvågningsydelsen er implementeret, via praktiske test ved at fremprovokere en række 21

22 Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse fejlsituationer, som overvågningssystemet og den tilhørende driftsorganisation skal reagere på i henhold til udarbejdet overvågningsbeskrivelse. Kan ikke påvise at overvågningsydelsen er implementeret ifølge aftale, og system er ikke i en driftslignende tilstand. Teknisk Drift It kan ikke påtage sig ansvar for at levere overvågning. Driftsleverandøren Verifikation af driftsprocesser Ultimativt krav Obligatorisk. Verifikation af: Verifikation af SLA aftale Verifikation af at drifts-økonomi er aftalt med alle parter og budget foreligger Brugeradministrationsprocesser (hvis det indgår). Månedlige service rapporteringer (hvis der er specielle krav til opfølgning / rapportering) Driftsorganisation - det verificeres, at driftsorganisation har modtaget information og/eller gennemgået uddannelse af drifts- og supportydelsen, og at kerneteamet er bemandet i henhold til krav samt foretagelse af formel overdragelse til drift. Verifikation af, at overvågningsrapporteringsværktøj er installeret og konfigureret (i.e. service level rapportering) kan ikke påvise, at processerne understøttes, og Teknisk Drift It kender ikke de ønskede services og kan følgelig ikke tage ansvar for dette. It Contract Management Repræsentanter for Indkøb og Servicemål Driftsleverandørens Service Desk Driftsleverandørens Service Delivery Management Driftsleverandørens Teknisk Kunde Konsulent Deployment test Betinget Krav Obligatorisk - hvis der er applikationsdrift, som kræver deployment af applikationer, versioner og/eller interfaces. Deployment proceduren skal være dokumenteret og verificeres gennem afprøvning Deploymentmodel: skal først gennemføres fra test / udvikling / sandbox til preproduktion. Ved succesfuld afprøvning hvori der indgår en fuld installationstest, kan der efterfølgende ske en deployment fra preproduktion til produktion kan ikke dokumentere, at en deployment ikke vil medføre nogle afledte konskvenser på servicemål, hvorved 22

23 Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Test type Prioritet: Ansvar: Forventning til gennemførelse Konsekvens ved fravigelse Deltagere Teknisk Drift It ikke kan tage ansvar for servicemål, og projektet må forvente en højere driftsudgift for eventuelle afledte effekter Driftsleverandørens Client Management 3. part som har ansvar for applikationsvedligeholdelse Eventuel Testbrugergruppe Test af klient applikationspakker (MSI/SMS) Betinget krav Obligatorisk hvis der indgår en klient applikation Klient applikationen skal forefindes i en pakke, som kan distribueres via de administrative driftsværktøj (såsom MSI/SMS/RIS). Deployment af pakken skal være testet på standard arbejdespladser, inklusiv test af afinstallation. Der bør udvælges en superbrugergruppe, som evt. kommende tilpasninger af pakken testes hos. Teknisk Drift It kan ikke acceptere drift af klient applikationen Driftsleverandørens Client Management Testbrugergruppe Performancetest Betinget krav Hvis der er krav om svartider og lignende performancekrav, skal der ske en test af systemet/systemernes fortsatte performance mål i forbindelse med vedligeholdelses- eller nyudviklingsændringer Afprøvning skal ske i produktionsmiljøet med produktionslignende data kan ikke påvise, at It-løsningen dækker de performancekrav (belastning, kapacitet og svartider), som er opstillet i forbindelse med udvikling af løsningen. Løsningen kan ikke gå i drift med performance service mål Driftsleverandøren 23

24 5 Driftsprøve (accept test) 5.1 Formål Driftsprøven eller accepttest er Teknisk Drift It s test af systemet ud fra forretnings- og systemmæssige krav. Selve driftsprøven er derfor en kontrol af, at de fremsatte krav er opfyldt, og at løsningen kan driftes som planlagt. er ansvarlig for udbedring af alle fejl og mangler. Hvis driftsprøven ikke kan godkendes af Teknisk Drift It grundet betydende fejl og mangler, kan løsningen ikke overdrages til drift. Alle kritiske og betydende fejl er opsættende for driftsgodkendelse. Ved mindre og kosmetiske alvorlige fejl og mangel kan der ske en betinget godkendelse til drift, hvis der foreligger en gensidig accepteret plan for udbedring af fejl og mangler (herunder økonomi). Hvis applikation support indgår som en del af løsningen, verificeres ligeledes grænsefalden til denne. Derfor foretages driftsprøven efter, at de enkelte leverancer er ibrugtaget og sat i drift. Formålet med driftsprøven er at verificere, at Teknisk Drift It og dennes Driftsleverandør(er) kan levere ydelserne omfattet af kontrakt i den aftalte kvalitet. Med andre ord, driftsprøven måler de aftalte servicemål i en normal driftssituation i en given periode. Driftsprøven (Accepttest) indeholder følgelig: Verifikation af servicemål jævnfør indgået SLA aftale Verifikation af service processer såsom rapportering, fejlhåndtering, dokumentationsprocesser, etc. Verifikation af grænseflade til applikation support 5.2 Hvornår Gennemføres efter driftsovertagelsesprøve. Driftsprøve forløber i en 3 måneders periode for at kunne verificere at systemet er driftsstabilt. 5.3 Ansvar (eller forretningen hvis projektet har overdraget) har det overordnede ansvar for planlægning af driftsprøven. Teknisk Drift It udfører og godkender driftsprøven i henhold til krav og gældende tidsplan; samt udbedrer fejl via Change Management processen. 24

25 5.4 Afprøvningsmiljø Driftsprøve omfatter alle miljøer, som er underlagt service level agreement, og som er i en produktionstilstand og/eller afspejler produktionsmiljøet. 5.5 Indgangs- og udgangskriterium Indgangskriterium: Godkendt driftsovertagelsesprøve og at der er sket en formel overdragelse til Teknik Drift It fra projektet via en godkendt overdragelsesprotokol. Udgangskriterium: Accept fra Teknisk Drift It; i.e. der er sket en formel overdragelse af ansvaret. 5.6 Godkendelseskriterier Målbare, objektive og specifikke godkendelseskriterier fastsættes i forbindelse med planlægning og design af acceptkriterierne og driftsprøverne, som beskrives i teststrategien. Det forventes, at driftsprøven kan godkendes, når driftsleverandøren lever op til faktiske servicemål, ved at projektet rettidig har modtaget og godkendt månedsrapporter / SLA rapporter. Samt at der er ingen graverende fejl i løsningen og/eller, at der foreligger en accept af og plan for kendte fejl 5.7 Styringsdokumenter Dokumentation for opfyldelse af servicemål sker gennem Driftsleverandørens service level rapportering med udgangspunkt i registreringer i det anvendte ItSM, overvågningssystemer og andre relevante driftssystemer. Overdragelsesprotokollen opdateres med test resultat Mangler håndteres via Change Management. 5.8 Hovedaktiviteter Test gennemføres i henhold til de specificerede krav og tilgang til afprøvninger og testplanlægning samt gældende tidsplan for projektet, dog skal driftsprøven forløbe i en 3 måneders periode. Enhver fravigelse skal suppleres med en risikovurdering med tilhørende accept af alle interessenter. 25

26 Testen tager udgangspunkt i normal drift i henhold til service mål og tilhørende rapportering Der foretages ikke nogen specifik test, men der sker udelukkende en verifikation af og måling af aftalte servicemål i henhold til indgået service level aftale gennem normal drift. 26

27 Appendiks: Tjekliste vedrørende overdragelse til drift Nedenstående punkter skal gennemgås, og alle relevante dele skal udføres, forinden et system kan overgå til fuld drift. Alle foruddefinerede Banedanmark skabeloner skal anvendes. Teknisk Drift It og leverandørens driftsorganisation skal inddrages i det omfang, det er nødvendigt, og ellers påhviler det projektet at udarbejde nedenstående dokumenter. Transition er beskrevet yderligere i Transitionskonceptet, som findes i Tracé. Det vil være en fordel, at nedenstående dokumenter, aktions mv. udarbejdes løbende i projektforløbet, og ikke lige inden en overdragelse skal finde sted. Man skal påregne, at det minimum tager 4-6 uger at gennemføre en fuld transition. I forbindelse med overdragelse til drift kontaktes Change Management funktionen for at få initieret en review proces af dokumentationen. Der skal udarbejdes en samlet dokumentation Krav til driftsdokumentation, som er en beskrivelse af stort set alle nedenstående punkter i prosaform. Når alle dokumenter er klar til review, fremsendes de til driftsleverandørens SDM, som tilsikrer at review proces igangsættes. Nedenstående punkter er i ikke prioriteret rækkefølge, men som udgangspunkt skal SLA aftale udarbejdes som noget af det første, og overdragelsesprotokollen udarbejdes til sidst i forløbet. Der er angivet hvem i driftsorganisationen, som kan bidrage med udarbejdelsen af de relevante dokumenter: Udarbejdes af projektet med involvering af SLA Manager: Udarbejdelse af SLA aftale Udarbejdes af projektet med involvering af Kontraktholder & It- Driftschef: Ydelsesbeskrivelse til kontrakten Ydelsestabel med sager og deres prioritering Kontrakter (licens, applikationsvedligeholdelse, hardwarevedligeholdelse etc.) 27

28 Udarbejdelse af allonge til kontrakten Udarbejdelse af governance model Definering af uddannelsesbehov i forhold til brugerne Definering af relevante politikker på området (hvorledes systemet skal anvendes forretningsmæssigt) Udarbejdes af projektet med involvering af SDM driftsleverandør(er): Driftsdokumentation Grænsefladebeskrivelser (imellem leverandører, systemkomponenter etc.) Uddannelse af driftspersonale Driftsprocedurer og driftsrutiner beskrives og implementeres, kan berøre flere parter i driftsorganisationen Udarbejdelse af nødvendige brugerguides, installationsguides etc. Regel administrationsprocedurer beskrives og implementeres (administrationstools, overvågningstools) Beskrivelse af kendte fejl (known errors) Gennemgang af om miljø er patchopdateret inden idriftsættelse Gennemgang af backup opsætning, hvis specifikt i forhold til BDKs standard Test protokol med udførelse af nødvendige driftstests (f.eks. shut down, patchning, failover / redundans, D/R, kapacitet, sikkerhed) Afklaring samt implementering af ønsket overvågning herunder definition af relevante overvågningspunkter). Rapporteringsmuligheder Procedure for håndtering af log filer Capacity management - hvordan måles og hvad er kravene Etablering af kuvertbrugerordning Procesflow for fejlhåndtering (beskrivelse af hvordan fejl tilgår driftsorganisationen, og hvem der gør hvad, når disse modtages) Systemdokumentation Aftale vedrørende stabiliseringsperiode (periode hvor projektressourcer er til rådighed og systemet monitoreres undtagelse fra SLA i denne periode) Costumisering/tilpasning af system f.eks. overflytning af data Udarbejdes af projektet med involvering af Sikkerhedskoordinator: Samarbejdsaftale udarbejdes samt nødvendige brugeroprettelser Sikkerhedsevaluering og godkendelse af system 28

29 Udarbejdes af projektet med involvering af Kontraktsupport: Udarbejdelse af eventuelle nødvendige blanketter Indkøb af reservedele til lager Afledte driftsomkostninger tilgår driftsbudgettet Anskaffelse af nødvendige licenser Beskrivelse af systemlandskab med oversigt over assets (model, serienummer, anskaffelsessum, warranty date m.m.) Udarbejdes af projektet med involvering af Change Management funktion: Udarbejdelse af idriftsættelses RFC'er (inkl. PSP og IO numre) Overdragelsesprotokol inkl. mangelliste med tilhørende aktionspunkter og ansvarlige Information om indflydelse på driftsbudget (e.g. erstatter det nye system nuværende platform eller er det en ny, etc.) 29

30 Appendiks Oversigt over blanketter på Tracé Følgende oversigt skal betragtes som en service for at hjælpe projekterne, men der bør altid checkes i Tracé, om der udviklet nyere version og/eller andre ændrede versioner grundet eksempelvis ændret metodik. SLA aftale >> Skabelon for vedligeholdelseskontrakter >> Driftsdokumentation >> Kan findes under Transition i Tracé og hedder Krav til driftsdokumentation Teststrategi >> Test Rapport >> Skabeloner for RFC idriftsættelse (ændringsanmodning) >> em%20i%20drift%20-%20skabelon%20rfc%20idræftsættelse.docx Bestilling af databaseetablering >> Itsystemudvikling/14%202%202%202%205%20%20databaserbestilling%20for mular.docx Bestilling af serveretablering >> It-systemudvikling/ %20%20Serverbestilling%20blanket-2.docx Overdragelsesprotokol (fra projekt til IT-drift) >> 0projekt%20til%20It-drift).docx Leverancebeskrivelse (del af overdragelsesprotokol) Mangelliste (del af overdragelsesprotokol) Asset liste (del af overdragelsesprotokol) 30

31 Stablitetsperiode forløb (del af overdragelsesprotokol Sikkerhedsevaluering >> >> under afklaring << Skabelon for brugervejledning >> >> under afklaring << 31

32 Appendix: Begrebsoversigt Forkortelse/Begreb RFC RTO RPO SLA aftale UC Beskrivelse Request for Change = en ændringsanmodning Recovery Time Objective = det tidspunkt man skal tilbage til i en recovery situation, altså et udtryk for hvor meget datatab forretningen kan acceptere. Recovery Point Objective = den tid det tager fra recovery processen starter til IT systemet er driftklart Service level agreement. En aftale mellem to partner; i.e. forretningen og Teknisk Drift IT. SLA aftalen beskriver ønskede niveau for IT-servicen og specificerer ansvar for begge parter Underpinning contract; e.g. aftaler om service, support eller vedligeholdelse med eksterne leverandører 32