MODTAGELSESERKLÆRING [SKRIV PROJEKTETS NAVN HER] Revisionshistorik. AAU It Services Selma Lagerlöfs Vej Aalborg Ø

Transkript

1 AAU It Services Selma Lagerlöfs Vej Aalborg Ø Revisionshistorik Revisionsdato Version Ændringer Forfatter

2 1 Indhold 1 Indhold Anvendelse Praktisk vejledning Generel information Systemets navn Hvem er systemejeren? Kontaktinformation for systemejeren Formålet med systemet Brugerne af systemet Opstart Opgaver for Infrastruktur Services inden og under opstart Opgaver for Anvendt IT og Udvikling inden og under opstart Opgaver for Support Services inden og under opstart Checkliste før opstart Eksterne aftaler Softwarelicenser og supportkontrakter Aftaler for eksterne konsulenters adgang til systemet Finansiering af drift og support Er nødvendige ressourcer allokeret i Infrastruktur Services? Er nødvendige ressourcer allokeret i Anvendt IT og Udvikling? Er nødvendige ressourcer allokeret i Support Services? Dokumentation Teknisk beskrivelse Arkitekturoversigt Sammenhæng med andre systemer Risikoanalyse Business Case Skal systemet medtages i beredskabsplanen? Driftsdokumentation Logningsplan Overvågning Alarmer Fejlfinding Plan for backup Procedure for re-store og test af dump/re-store Hvem skal godkende re-store af systemdata?... 6 Side 1 af 8

3 9 Adgangskontrol Brugeradgang Administratoradgang Ekstern brugeradgang Ekstern administratoradgang... 7 Side 2 af 8

4 2 Anvendelse Modtagelseserklæringen skal anvendes i forbindelse med projekter drevet af PMO, AIU eller IFS. Projektlederen er ansvarlig for anvendelse af modtagelseserklæringen. Endelig godkendelse af modtagelseserklæringen foretages af Per Bach Sørensen pbs@its.aau.dk 3 Praktisk vejledning Lav en kopi af formularen til modtagelseserklæringen \\aau.dk\its\fileshares\infrastruktur\arkitekt\modtagelseserklæring.dotx Udfyld modtagelseserklæringen Den udfyldte modtagelseserklæring gemmes sammen med systemets øvrige dokumenter i systemets folder i serviceoversigten: \\aau.dk\its\fileshares\infrastruktur\arkitekt\service Når systemet er klart til drift, sendes en med henvisning til modtagelseserklæringen til Per Bach Sørensen pbs@its.aau.dk til endelig godkendelse Punkter som ikke synes relevante for det givne projekt besvares med ikke relevant. Se også forklaring til modtagelseserklæring for yderligere dokumentation og information. 4 Generel information Generel information om systemet og dets overordnede funktion 4.1 Systemets navn Systemets navn i daglig tale 4.2 Hvem er systemejeren? Systemejeren er den person eller enhed, som har ansvaret for det produkt, der leveres til brugerne Kontaktinformation for systemejeren Beskriver hvorledes systemejeren skal kontaktes for dialog om tiltag, som kan påvirke systemets drift eller tilgængelighed. Bør liste en eller flere kontaktpersoners navne og adresser. 4.3 Formålet med systemet Kort beskrivelse af systemets formål og funktion 4.4 Brugerne af systemet Beskriv hvem der er brugere af systemet og/eller bliver direkte påvirkede af driftsforstyrrelser. Hvis der er flere brugergrupper, bør hver af disse listes. Det skal være muligt at estimere, hvem der er berørt af systemets utilgængelighed ud fra beskrivelserne. Side 3 af 8

5 5 Opstart Når et system modtages til drift, går det generelt gennem følgende faser: 1. Allokering af ressourcer for opstart og drift sikres 2. Modtagelseserklæringen udfyldes 3. Systemet sættes i drift i en opstartsfase 4. Systemet testes og godkendes til drift 5.1 Opgaver for Infrastruktur Services inden og under opstart Liste af opgaver som skal udføres af Infrastruktur Services, mens systemet er i opstartsfasen. 5.2 Opgaver for Anvendt IT og Udvikling inden og under opstart Liste af opgaver som skal udføres af Anvendt IT og Udvikling under opstart. 5.3 Opgaver for Support Services inden og under opstart Liste af opgaver som skal udføres af Support Services under opstart. 6 Checkliste før opstart Det skal sikres at de nødvendige ressourcer er allokerede før systemet kan indgå i opstartsfasen. 6.1 Eksterne aftaler Eksterne aftaler som er nødvendige for systemets drift. Udfyldes for systemer med afhængigheder på eksterne databaser og services. Der bør altid foreligge en aftale, hvis systemet er kritisk afhængigt af en ekstern ressource Softwarelicenser og supportkontrakter Liste af relevante licensaftaler og supportkontrakter. Bemærk at der altid skal kunne refereres til en licens for software (også for gratis software) Aftaler for eksterne konsulenters adgang til systemet Hvis personer, som ikke er juridisk bundet af en ansættelse ved AAU, skal have adgang til systemet, skal der foreligge en underskrevet aftale om dette. Dette er særligt vigtigt, hvis eksterne konsulenter kan få adgang til systemets data. 6.2 Finansiering af drift og support Beskrivelse af hvordan drift og support af system er finansieret. Dette hører næppe til i modtagelseserklæringen på sigt, men indtil der kan henvises til andre dokumenter, ønskes det beskrevet her. Hvis der ikke direkte er tale om nogen afregning, bør man skrive motivationen for at vi skal drive systemet (se eksemplerne). Side 4 af 8

6 6.3 Er nødvendige ressourcer allokeret i Infrastruktur Services? Hvis Infrastruktur Services har opgaver under opstart, skal der findes personer til disse. Aftales med relevante teamledere i infrastruktur. Unix og Oracle: Mads Peter Bach mpb@its.aau.dk Windows: Henrik Benner Svendsen hb@its.aau.dk Netværk og Storage: Simon Holm sho@its.aau.dk 6.4 Er nødvendige ressourcer allokeret i Anvendt IT og Udvikling? Hvis Anvendt IT og Udvikling har opgaver under opstart, skal der findes personer til disse. Aftales med Kirsten Hjerrild Nielsen khn@its.aau.dk 6.5 Er nødvendige ressourcer allokeret i Support Services? Hvis Support Services har opgaver under opstart, skal der findes personer til disse. Aftales med Michael Collin michael@its.aau.dk 7 Dokumentation Sikring af systemets dokumentation og referencer til hvor den kan findes. 7.1 Teknisk beskrivelse Teknisk beskrivelse af systemet og dets komponenter eller henvisning til arkitekturdokument. Der skal som minimum laves en arkitekturtegning Arkitekturoversigt Arkitekturoversigten skal som minimum indeholde en arkitekturtegning. Hvis systemet er en komponent i et større system, skal der foreligge en arkitekturtegning for det overordnede system, som viser komponentens afhængigheder Sammenhæng med andre systemer Her skal listes afhængigheder af andre systemer, som ikke direkte fremgår af arkitekturtegningen. Hvis det allerede kendes at andre systemer vil blive afhængige af dette system, bør disse også listes. 7.2 Risikoanalyse Risikoanalyse for systemet eller henvisning til denne. Risikoanalysen skal belyse informationssikkerhed og impact af driftsforstyrrelser. For projekter som anvender procesmodellen findes risikoanalysen som ledelsesprodukt fra analysefasens levering til milepæl M Business Case Motivation for systemet eller henvisning til udarbejdet Business Case Side 5 af 8

7 7.4 Skal systemet medtages i beredskabsplanen? Der skal vurderes om systemet skal være nævnt og prioriteret i beredskabsplanen. 8 Driftsdokumentation Driftsdokumentation for systemet eller henvisning til relevant del af driftshåndbogen. 8.1 Logningsplan Beskrivelse af specifikt logningsbehov for systemet eller henvisning til generel logningsplan fra driftshåndbogen. 8.2 Overvågning Beskrivelse af den løbende overvågning som ønskes eller henvisning til driftshåndbog. Der skal som minimum beskrives hvordan man kan kontrollere at systemet kører. 8.3 Alarmer Beskrivelse af alarmer og deres håndtering. Der bør som minimum etableres alarm for om systemet kører. 8.4 Fejlfinding Der skal foreligge et basis flow for fejlfinding eller henvises til en relevant del af driftshåndbogen. 8.5 Plan for backup Hvad skal gemmes? Med hvilken frekvens skal det gemmes? Hvor længe skal backup bevares? 8.6 Procedure for re-store og test af dump/re-store Der skal foreligge en procedure for hvordan reetablering af det seneste backup kan foretages. Proceduren skal testes Hvem skal godkende re-store af systemdata? Re-store af systemdata er en kritisk og destruktiv funktion som kun må iværksættes efter godkendelse fra system- eller dataejer. Beslutningsvejen for re-store af tidligere versioner skal beskrives (f.eks. en kontaktperson). Side 6 af 8

8 9 Adgangskontrol 9.1 Brugeradgang Brugeradgang giver mulighed for systemniveaulog-in uden administratorrettigheder. Hvis gruppen af brugere ikke kan beskrives generelt, angives i stedet hvem der har kompetence til at godkende en bruger. 9.2 Administratoradgang Administratoradgang giver mulighed for systemniveaulog-in med administratorrettigheder. Hvis gruppen af brugere ikke kan beskrives generelt, angives i stedet hvem der har kompetence til at godkende en bruger. 9.3 Ekstern brugeradgang Eksterne konsulenter kan gives systemniveaulog-in uden administratorrettigheder. Dette kræver at der foreligger en aftale (se 5.1.2). 9.4 Ekstern administratoradgang Eksterne konsulenter kan gives systemniveaulog-in med administratorrettigheder. Dette kræver at der foreligger en aftale (se 5.1.2). Side 7 af 8