Tredjepartsverifikasjon IKT

Transkript

1 Helsebygg Midt-Norge Side: 1 av 33 Tredjepartsverifikasjon IKT Fase 3: Verifikasjon av leverandørens leveranser utført av Capgemini

2 Helsebygg Midt-Norge Side: 2 av 33 Versjonshistorie Versjon Dato Endring Draftversjon sendt HMN (KOS) 0.9a Oppdatert etter kommentarer fra HBMN (AOS, KOS) Oppdatert etter kommentarer fra HBMN, Spm 2 og 4 behandles samlet i nytt spørsmål a Tekst i svarene kortet ned. Tekst flyttet. Oppdatert kap etter svar fra Telenor Oppdatert etter kommentarer fra Telenor og HBMN Gjennomgang og revisjon Dato Navn Rolle Karl Oscar Sandvik HMS- og kvalitetssjef HBMN Arve-Olav Solumsmo Informasjonssjef HBMN Børge Godhavn Prosjektleder HBMN Tore Indreråk IKT sjef HBMN Tore Nordmark Telenor Børge Godhavn og Tore Indreråk HBMN

3 Helsebygg Midt-Norge Side: 3 av 33 Sammendrag I den tredje fasen av oppdraget ønsker Styret i Helsebygg Midt-Norge å få verifisert om leveransen er som spesifisert/beskrevet i design dokumentene. Verifikasjonen har fokus på B6 Datanett som er et underpunkt til Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. (Forkortelser er definert i kapittel 1.1.) I sammendraget er svarene gitt på kortform med symboler etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik I fase 3 (av 3) besvares følgende spørsmål, knyttet til verifikasjon av leverandørens leveranse: 1. Stemmer levert løsning med prosjektets visjon og strategi, byggherrens og rådgivernes funksjonsspesifikasjon og leverandørens design? Svar: Se svar i Fase 1 rapport, spørsmål 4 og Fase 2 rapport, spørsmål Fanget kravanalysen som ble gjennomført ved starten av designfasen opp de kravene som var vitale for prosjektet, og ble oppfyllelsen av disse kravene verifisert før datanettet ble satt i drift? Svar: Kravsporingsprosessen tok sitt utgangspunkt i samtlige 214 krav i B6 Datanett. I første del av prosessen ble det skilt ut 74 krav for videre utredning for å komme frem til en felles kravforståelse mellom HBMN og leverandøren. Etter en gjennomgang av saksbehandlingen av disse 74 kravene slik denne er dokumentert i B06-FDR Vedlegg 2 Sporing er vår oppsummering som følger: Starten på kravanalysen fanget opp alle vitale krav, men vi er ikke sikre på at kravanalysen ble avsluttet med en omforent forståelse av disse kravene ut fra tilgjengelig dokumentasjon. Begge parter er imidlertid enige om at det var en omforent forståelse av kravene. 3. Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen, og dekket testene hele leveransen? Var testing og verifikasjon før idriftsettelse tilstrekkelig? Svar: 3.1. Testregimet og den testingen som ble gjennomført var ikke egnet til virkelig å avdekke svakheter med løsningen. Vår begrunnelse for dette er at testene bare var designet for å sjekke at systemene virket som forutsatt.. Eierne av systemer innen de forskjellige systemområder fikk ikke spørsmål om å beskrive hvilke hendelser som opplevelses som alvorlige driftsforstyrrelser med sikte på at denne informasjonen kunne legges til grunn for å lage reserveløsninger.

4 Helsebygg Midt-Norge Side: 4 av Testene dekket ikke hele leveransen. Vår begrunnelse for dette er: Mangler ved testene til leverandør Mangler ved testene til HBMN 3.3. Testing og verifikasjon før idriftssettelse var ikke tilstrekkelig. Den definerte prosessen for verifikasjon av løsningen var god, men gjennomføringen fulgte ikke prosessen godt nok. De testene HBMN var ansvarlig for var ikke formelt planlagt og dokumentasjon av testresultater i form av testrapporter eksisterer ikke. 4. Var klargjøring for drift tilstrekkelig for å sette løsningen i drift? Svar: Klargjøring for drift var tilstrekkelig for å sette løsningen i drift. Vi ønsker likevel å påpeke følgende: o Leverandøren hadde ikke spesifikke planer hva angår implementering av Continuity management prosessen hos St. Olavs Hospital og NTNU.. o I forbindelse med FSAT savner vi en akseptansetest av IDS-systemet med utgangspunkt i virusangrep, hackerangrep og andre trusler samt hard trafikk belastning. Proxycom [24] og leverandøren uførte sikkerhetstester av datanettet. Vi kan ikke se at Proxycoms test er en akseptansetest av IDS. Rapporten fra leverandørens sikkerhetstest er ikke stilt til vår disposisjon, referanse til møte med testleder [25], og kan derfor ikke uttale oss om denne testen var en akseptansetest av IDS. 5. Er nettet konstruert på en slik måte at kontraktskravet % pr. måned kan oppnås? Svar: Beregninger og design-vurderinger tilsier at kontraktskravet på 99,999% tilgjengelighet kan oppfylles.

5 Helsebygg Midt-Norge Side: 5 av 33 Innhold 1. Innledning Forkortelser Definisjoner Fremgangsmåte Spørsmål i fase Stemmer levert løsning med prosjektets visjon og strategi, byggherrens og rådgivernes funksjonsspesifikasjon og leverandørens design? Fanget kravanalysen som ble gjennomført ved starten av designfasen opp de kravene som var vitale for prosjektet, og ble oppfyllelsen av disse kravene verifisert før datanettet ble satt i drift? Appendix A - Reviderte kravsporingsrapporter.doc B06-FDR Vedlegg 2 Sporing Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen, og dekket testene hele leveransen? Var testing og verifikasjon før idriftsettelse tilstrekkelig? Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen? Dekket testene hele leveransen? Tester utført av leverandøren Tester utført av HBMN Var testing og verifikasjon før idriftsettelse tilstrekkelig? Var klargjøring for drift tilstrekkelig for å sette løsningen i drift? Avtale for drifts- og vedlikeholdsytelser SLA avtale mellom Kunden (St. Olavs Hospital og NTNU) og Leverandøren ITIL Service Management og Service Delivery prosesser ITIL basert organisasjon til å utføre Service Management og Service Delivery prosessene Signert overtakelsesprotokoll SLA rapporter hva angår protokoll fra prøveperioden HBMNs og leverandørens FSAT dokumentasjon hva angår protokoll fra utført sluttkontroll Vedr. 19 overtakelsesmangler samt gjenstående arbeider Er nettet konstruert på en slik måte at kontraktskravet % pr. måned kan oppnås? Vedlegg: Kravsporingsprosess FSAT...32

6 Helsebygg Midt-Norge Side: 6 av Innledning Innledning i Rapport for fase 1 beskriver bakgrunn for verifikasjonen, faseinndeling og omfang. I den tredje fasen av oppdraget ønsker Styret i Helsebygg Midt-Norge å få verifisert om leveransen er som spesifisert/beskrevet i designdokumentene. Verifikasjonen har fokus på B6 Datanett som er et underpunkt til Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. I fase 3 (av 3) besvares følgende spørsmål, knyttet til verifikasjon av leverandørens leveranse: 1. Stemmer levert løsning med prosjektets visjon og strategi, byggherrens og rådgivernes funksjonsspesifikasjon og leverandørens design? 2. Fanget kravanalysen som ble gjennomført ved starten av designfasen opp de kravene som var vitale for prosjektet, og ble oppfyllelsen av disse kravene verifisert før datanettet ble satt i drift? 3. Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen, og dekket testene hele leveransen? Var testing og verifikasjon før idriftsettelse tilstrekkelig? 4. Var klargjøring for drift tilstrekkelig for å sette løsningen i drift? 5. Er nettet konstruert på en slik måte at kontraktskravet % pr. måned kan oppnås? 1.1 Forkortelser Liste over viktige forkortelser i dokumentet: ACS Cisco Secure Access Control Server DNS Domain Name Server DHCP Dynamic Host Configuration Protocol FAT Factory Acceptance Test FDR Final Design Review FDV Forvaltning, Drift og Vedlikehold FSAT Final Site Acceptance Test HBMN Helsebygg Midt-Norge HKR Hovedkommunikasjonsrom sentralt i hvert bygg IDS Intrusion Detection System IKT Informasjons og Kommunikasjonsteknologi IT Informasjonsteknologi ITIL IT Infrastructure Library KR Kommunikasjonsrom (KR) på etasjeplan i hvert senter MTBF Mean Time Between Failure

7 Helsebygg Midt-Norge Side: 7 av 33 MTTR NMS PDR POC ROS SAT SHKR SLA SPOF Mean Time To Repair Network Management System Preliminary design review Proof of concept Risiko og Sårbarhet Site Acceptance Test Sentralt hovedkommunikasjonsrom plassert strategisk i bygningsmassen Service Level Agreement Single point of failure 1.2 Definisjoner Her følger en liste over definisjoner som er benyttet i gjennomgangen. Kontrollmetoder i mottakskontroll Allkontroll (100%) Stikkprøvekontroll (statistikk) Typesjekk (enhet, størrelse, avsløre system feil) Dokumentkontroll (system eller prosess kontroll) Ingen kontroll (god tillit og fast kunde/leverandør forhold) Kvalitet Med kvaliteten av et produkt / en tjeneste, menes produktet-/ tjenestens evne til å tilfredsstile brukerens behov, ønsker, krav og forventninger. Overordnet testplan Et styrende strategidokument for all testvirksomhet i prosjektet Definerer klare ansvarsforhold Fastsatt detaljeringsnivå på testarbeidet Fastsatte kriterier for godkjenning/underkjenning (når skal testen stoppes) Underlag for å estimere testarbeidet Testmodell 1. Lag overordnet testplan (se der) 2. Planlegg test detaljert gjennomføringsplan - testprosedyrer, 3. Forbered test testdata, testmiljø, testressurser 4. Gjennomfør test dokumenter testobservasjoner, teststatus 5. Avslutt test testrapport med evaluering

8 Helsebygg Midt-Norge Side: 8 av 33 Testnivåer Det er fire hovednivå av test: Enhetstest Integrasjonstest Systemtest Akseptansetest Validering En evaluering for å fastslå om det som er spesifisert og det som er produsert har de egenskapene som er nødvendige og korrekte i forhold til den tiltenkte bruk. Med andre ord aktiviteter for å kontrollere at riktig løsning blir laget. Validering (NS-ISO 8402): Bekreftelse ved å undersøke og framskaffe objektivt bevis på at de bestemte krav for en spesifikk tilsiktet bruk er oppnådd. Verifikasjon En evaluering for å fastslå om systemet oppfyller gitte kravspesifikasjoner og standarder, samt tilfredsstiller generelle krav til korrekthet, fullstendighet, konsistens og nøyaktighet. Med andre ord aktiviteter for å kontrollere at en løsning blir laget på riktig måte. Verifikasjon (NS-ISO 8402): Bekreftelse ved å undersøke og fremskaffe objektivt bevis på at spesifiserte krav er oppfylt. Verifikasjonsmetoder Eksempler på verifikasjonsmetoder som kan benyttes på testnivåene: Inspeksjon typiske teknikker er skrivebordssjekk, gjennomgang (walkthrough), teknisk review, formell inspeksjon (f. eks. Fagan) Analyse matematisk verifikasjon Testing Strukturell test ( white-box ), Funksjonell test ( black-box )

9 Helsebygg Midt-Norge Side: 9 av Fremgangsmåte For å besvare spørsmålene som reises har vi benyttet dokumentasjon som ble benytte som input til prosessene (eksempelvis leverandørens design dokumenter av kravene til datanettet for det nye universitetssykehuset) eller dokumentasjon som ble produsert i prosessene (eksempelvis kravsporingstabeller og testrapporter). Vi har også hatt møter og telefonsamtaler med personer fra HBMN, Telenor/EDB og St. Olavs Hospital. Spørsmålene angitt i innledningen behandles i neste kapittel i rekkefølge med. bl.a. angivelse av dokumentasjonskilde, svaret og kortversjon av svaret. Som underlag for vurderingen i fase 3 har vi hatt tilgang til følgende dokumentasjon: Kontraktsdokumenter; PDR (Preliminary design review) og FDR (Final design review) dokumenter; As built dokumenter; Rapporter fra sikkerhetsgjennomganger; Evalueringsrapporter etter innflytting Testplaner og testrapporter Servicenivå rapporter Møtereferater og statusrapporter. Vi har konsentrert innsatsen rundt dokumenter relatert til datanettverk og drift. Enkelte av spørsmålene kan være overlappende. Dette fører til at samme argumentasjon kan benyttes til å besvare flere spørsmål. Til å besvare spørsmålene har vi benyttet følgende mal: Kilde: er det formelle navnet på dokumentasjonen vi legger til grunn for å besvare spørsmålet. Dersom vi har benyttet møter eller telefoner, gies det informasjon om det her. svar på spørsmålet; Svar: er kortversjon av svaret. Rapporten beskriver avvik som er avdekket i gjennomgangen. Avvik defineres som manglende samsvar med visjon, strategi, design eller leveranse. I sammendraget er svarene gitt på kortform etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik Rapportene omhandler i hovedsak avvik. Forhold der ingen avvik er avdekket, beskrives normalt ikke. Gjennomgangen er basert på stikkprøver. Det er derfor ikke sikkert at alle forhold er avdekket. Rapporten bør leses med dette i minne. Sluttrapporten vil inneholde forslag til tiltak basert på avvikene.

10 Helsebygg Midt-Norge Side: 10 av Spørsmål i fase 3 Med fase 3 forstår vi perioden etter godkjent design av løsningen av Helsebygg Midt-Norge til idriftsettelse av løsningene. 3.1 Stemmer levert løsning med prosjektets visjon og strategi, byggherrens og rådgivernes funksjonsspesifikasjon og leverandørens design? Kilder: [Fase 1 rapport, spørsmål 4]; [Fase 2 rapport, spørsmål 1]; [ Infrastruktur for IKT Bilag B34 Drift, kontrakten, 1]. I fase 1, spørsmål 4, besvarte vi om spesifikasjonen stemte med det som er nedfelt i visjon og strategi. I fase 2, spørsmål 1, besvarte vi om beskrevet design/arkitektur/konsept stemmer med funksjonsspesifikasjonen. Dette siste spørsmålet ble besvart med utgangspunkt i deler av FDR leveransen begrenset til datanettet (B6.1 Nettverk; B6.2 Trådløst nettverk; B6.3 System for drift, overvåkning og administrasjon ). FDR er inneholdt i As Built og skal i prinsippet, slik vi forstår hensikten med dette dokumentet, være designen av den faktiske leveransen. Hvis vår forståelse er korrekt er dette spørsmålet besvart av spørsmål 4 i fase 1 og spørsmål 1 i fase 2. Tilbudet på driftsytelser etter overtagelse er å betrakte som opsjoner (referanse til B34 Drift [1]), og vil bli behandlet i kapittel 3.4. Svar: Se svar i Fase 1 rapport, spørsmål 4 og Fase 2 rapport, spørsmål 1.

11 Helsebygg Midt-Norge Side: 11 av Fanget kravanalysen som ble gjennomført ved starten av designfasen opp de kravene som var vitale for prosjektet, og ble oppfyllelsen av disse kravene verifisert før datanettet ble satt i drift? Kilder: [B31 Prosjektgjennomføring.doc i kontrakten, 1]; [Appendix A - Reviderte kravsporingsrapporter.doc, 2]; [ B06-FDR Vedlegg 2 Sporing.doc, 3]; [BR-TEL-HBMN-0726, Vedlegg, Rapport Kravsporing FSAT1.pdf, 4]; [ Infrastruktur for IKT Bilag B34 - drift, 5]; [ B34-FDR Drift v2.0.doc, 6]; [ B FDR Vedlegg 2 Sporing B05.1.doc, 7]; [ B FDR Vedlegg 3 Sporing B05.2.doc, 8] Del to av dette spørsmålet «ble oppfyllelsen av disse kravene verifisert før datanettet ble satt i drift» blir behandlet i kapittel 3.3. Kravet om Kravanalyse er gitt i kapittel B i B31 Prosjektgjennomføring [1]. Her heter det bl.a.: Ved avslutning av kravanalysefasen skal Entreprenøren utgi en kravanalyserapport, som har som formål å sikre at krav til de ulike anleggene er fullstendig og nøyaktig identifisert, og at det er en felles forståelse mellom Byggherren og Entreprenøren om disse krav. Vår forståelse av «vitale krav for prosjektet» i denne sammenheng gjelder «vitale krav for datanettet» som er HBMNs k-nummererte krav. Begrunnelsen for det, er at k-kravene pr. definisjon må oppfylles og derfor er vitale for prosjektet. Kravsporing foreligger i følgende dokumenter: Appendix A - Reviderte kravsporingsrapporter.doc [2]; B06-FDR Vedlegg 2 Sporing [3]; Kravsporingsprosess FSAT [4]. Det ble også gjort kravsporingsprosess i FSAT. Spørsmålet vi skal besvare gjelder kravanalyse ved starten av designsfasen og er derfor ikke tatt med i denne vurderingen Appendix A - Reviderte kravsporingsrapporter.doc Denne rapporten har bl.a. en oversikt over samtlige 214 krav 1 i B6. Tabelloppstillingen som benyttes består av følgende kolonner: 1. Kravnummer (Nr) 2. Krav der det fremkommer flere underelementer (Unr) 3. Den opprinnelig kravbeskrivelsen (Tekst) 4. Sidehenvisning i kravtabell (Side) 5. Ja eller nei til om kravet er oppfylt 6. Kommentarer fra opprinnelig kontrakt (Kommentar_Kontrakt) 1 Et krav kan bestå av et antall underelementer.

12 Helsebygg Midt-Norge Side: 12 av INF hvis krav innfridd eller IKK hvis krav ikke innfridd (Telenor_Krav_Innfridd) 8. OK hvis krav omforent eller UTR hvis krav under videre utredning (PDR1_Status) 9. Kommentar fra sporingsprosess (Kommentar_Sporing) Kravene kan deles inn avhengig av PDR1_Status. Hvis PDR1_Status = OK foretas det ingen videre kravsporing. Hvis PDR1_Status = UTR er kravsporingen dokumentert i FDR Vedlegg 2 Sporing.doc [3] som er nærmere beskrevet i kapittel Krav [K6.1-84]: Det tilbudte systemet skal inneha 99,999 % tilgjengelighet innenfor tidsintervall på en måned er et eksempel på et krav med PDR1_Status = OK, dvs. kravet er omforent med Kommentar_Sporing = Ref. B34 Drift. Vi kan imidlertid ikke se at Bilag B34 drift [5] angir en tilgjengelighets-%. Vi finner heller ikke beskrivelse av en tilgjengelighets-% i FDR Drift v2.0 [6]. Vi er derfor usikre på hva «Ref. B34 Drift» egentlig referer til og som er relevant for [K6.1-84] kravet. Appendix A - Reviderte kravsporingsrapporter [2] er komplett i betydningen av at alle krav i Bilag B6, Datanett [2] er dekket, men vi stiller et spørsmål om hvor relevante enkelte referansene er som benyttes som forklaring B06-FDR Vedlegg 2 Sporing Kravsporingstabellen [3] dokumenterer saksbehandling for «kravsporingssaker». Dette er etter hva vi forstår, krav med PDR1_Status = UTR i Appendix A - Reviderte kravsporingsrapporter [2] dvs. krav som er under utredning. Av totalt 214 stk. B6 Datanett hovedkrav, er saksbehandlingen av 74 krav dokumentert i B06-FDR Vedlegg 2 Sporing [3]. Følgende er et eksempel på en kravsporingssak: Tekstkolonnen viser hva som har skjedd i denne saken. Her vises det til et møte (6/5) hvor det ble en avklaring mellom HBMN og leverandøren. Vi har ikke vært i stand til å finne dette møtereferatet som viser formuleringen som det ble enighet om og som avsluttet denne sporingsaktiviteten. Dette er en sporingsaktivitet i seg selv som er ganske tidkrevende med utgangspunkt i den informasjonen som er gjort tilgjengelig for oss. Etter en gjennomgang av kravsporingssakene er dette en oppsummering av våre observasjoner: 1. Uklart hvilken formulering HBMN og leverandøren ble enige om. Eksempel 1 [K6.1-2]: Noe snakk om routing protokoller og standard servere.

13 Helsebygg Midt-Norge Side: 13 av 33 Eksempel 2 [K ]: 2. Avklaring ville skje i fremtiden. Hvem hadde oppfølgingsansvaret? Eksempel [K6.1-3(1)]: Noen Cisco properitære løsninger vil bli benyttet. Så snart løsningene har blitt standardisert vil disse bli benyttet. 3. Uklarhet om kravet er dekket selv om det i kontrakten står at kravet er dekket. Eksempel [K6.1-69(1)]: Landsverk, Gunnar Hewlett: Tiltak: Brev til HBMN vil bli sendt. Dette vil inneholde de gjeldende kravpunkter som vi under kravsporingen hadde svart var dekket men etter nærmere gjennomgang viste seg ikke dekket av NTP leverandøren. 4. Kravsporingen mangler dialogen med HBMN. Eksempel [K6.1-82]: 5. Når en kravsporingssak konkluderte med en anbefaling, hva skjedde videre? Eksempel [K ]:

14 Helsebygg Midt-Norge Side: 14 av 33 Svar: Kravsporingsprosessen tok sitt utgangspunkt i samtlige 214 krav i B6 Datanett. I første del av prosessen ble det skilt ut 74 krav for videre utredning for å komme frem til en felles kravforståelse mellom HBMN og leverandøren. Etter en gjennomgang av saksbehandlingen av disse 74 kravene slik denne er dokumentert i B06-FDR Vedlegg 2 Sporing [2] er vår oppsummering som følger: Starten på kravanalysen fanget opp alle vitale krav, men vi er ikke sikre på at kravanalysen ble avsluttet med en omforent forståelse av disse kravene ut fra tilgjengelig dokumentasjon. Begge parter er imidlertid enige om at de hadde en omforent forståelse av kravene.

15 Helsebygg Midt-Norge Side: 15 av Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen, og dekket testene hele leveransen? Var testing og verifikasjon før idriftsettelse tilstrekkelig? Kilder: [ Infrastruktur for IKT Bilag B6, Datanett, kontrakten, 1] [B31 Prosjektgjennomføring.doc i kontrakten, 2]; [HBMN_B6.xls 2, 3 ] [ Overordnet Testplan-VedleggA.doc, 4]; [Rapport Sikkerhetsgjennomgang labsenter rev pdf, 5]; [Rapport Sikkerhetsgjennomgang kv-barnsenteret pdf, 6]; [Rapport Sikkerhetsgjennomgang Nevrosenteret del2 rev pdf, 7] [ B02-FDR Vedlegg 14 Teststrategi.doc, 8]; [ B02-FDR Vedlegg 11 Overordnet Testplan.doc, 9]; [ B02-FDR Vedlegg 13 Testplan SAT.doc, 10]; [BR-TEL-HBMN-0726, Vedlegg, Rapport Kravsporing FSAT1.pdf, 11]; [Redundanstest, resultatrapport, 12]; [ Test-IST-Testrapport.doc, 13]; [IST_SAT_B6_Tester.htm, 14]; IST_SAT_B6_Tester#2.htm, 15]; [ Testrapport - Varsel om klart for integrerte tester Nevro Midt.doc 3, 16]; [ Detaljerte testbeskrivelser med faktisk resultat FK Nevro Øst.xls, 17]; [FAT_HBMN.zip 4, 18]; [BR-TEL-HBMN-0726, Vedlegg, Rapport Kravsporing FSAT1.pdf, 19]; [B6_req.html 5, 20]; [Testoppfølging.xls 6, 21]; [mangler og endringer IKT i fase 1 v xls, 22]; [Sikkerhetstest ved Helsebygg Midt-Norge v1 1.pdf, 23]; [Resultater fra scanning etter sikkerhetshull.zip, 24]; [Møte med bl.a. testleder for leveransen, 3/10-06, 25]; [Mail 1-4 fase 3 fra prosjektleder IKT HBMN, , 26]; [Møte med prosjektleder IKT HBMN, ; 27]; [Informasjonsmodell, tekniske systemer mot syksehussystemer, 28]; [MP-sertifikat M14 - Omforent GS-dok_signert.pdf, 29]. I følge vanlige krav til kvalitetssikring skal man: Dokumentere hva som skal gjøres, gjøre det, dokumentere hva som er gjort. Det blir da mulig å spore resultater fra arbeidet i ettertid Tilsendt fra Jon Hølland. Varsel om klart for integrerte tester foreligger også for Nevro Øst, KVB, KVB Nord, LAB Vest og Laboratoriesenteret. Tilsendt fra Jon Hølland. Tilsendt fra Jon Hølland. 6 Tilsendt fra Børge Godhavn.

16 Helsebygg Midt-Norge Side: 16 av 33 I forhold til testregimet i prosjektet forventes det at både leverandøren og kunden dokumenterer hva som skal gjøres. Testregimet bør i hovedsak følge en testmodell som definert i kap Det må finnes Overordnet testplan (se kap 1.2), dokumentasjon fra gjennomføringen og Testrapport. Iht. Bilag B6 Datanett [1], kapittel B6.1.7 fremgår det at krav til testing (og dokumentasjon) er gitt i Bilag31 Prosjektgjennomføring [2]. Besvarelsen av spørsmålet er delt i 3: 1. Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen? 2. Dekket testene hele leveransen? 3. Var testing og verifikasjon før idriftsettelse tilstrekkelig? Var testregime og den testingen som ble gjennomført egnet til virkelig å avdekke svakheter med løsningen? Med utgangspunkt i B31 Prosjektgjennomføring [2] har vi satt opp en oversikt over testing og verifikasjon før idriftsettelse: Når Test Ansvarlig Hensikt Designprosess (B31.2.6) Fabrikktest (FAT) / Produksjonskontroll Leverandøren Entreprenøren skal for alle sine systemer/produkter gjennomføre interne produktkontroller i form av FAT. For alle systemer/produkter som inneholder betydelig grad av nyutvikling og eller nye produkter skal gjennomføres formelle FAT hvor Byggherren skal kunne delta. Endelig omfang av hvilke FATer som skal utføres skal avtales Produksjon / bygging (B31.3) Intern systemtest (B ) Leverandør Entreprenøren skal i overensstemmelse med sine kvalitetssikringssystemer utføre intern testing av alt utstyr som han installerer/monterer. Dette skal utføres før SAT iverksettes. Interntestene skal som minimum omfatte slik som angitt i bilag C samt: Produsentens anbefalte tester Alle tester som inngår i SAT Andre tester som Entreprenøren selv spesifiserer På forespørsel fra Byggherren skal utfylte og kvitterte testdokumenter oversendes innen 5 arbeidsdager. Dette skal være grunnlaget for gjennomføring av SAT Utprøving etter installasjon og test (SAT, Site Acceptance Test) (B ) Leverandør Utprøving etter installasjon og etter at leverandør har utført egne tester. Hensikten med testene er å verifisere leveransen ovenfor Byggherren Integrerte systemtester (B ) HBMN ansvarlig for planlegging og organisering Funksjons- og kapasitets test. Testen vil foregå mellom flere systemer og på tvers av kontrollområder og er entreprenøren/leverandørens dokumentasjon på oppfyllelse av kontraktens forutsetninger. Typiske tester 7 vil omfatte f eks at romspesifikt utstyr fungerer i normal drift (alt teknisk utstyr) og ved en serie av ulike feiltilstander som kan opptre hver for seg eller sammen. Samspill mellom eksisterende og nye systemer (B ) Leverandør og eksisterende driftsorganisasjon Leverandøren skal ved planlegging av ulike tester legge vekt på å teste/verifisere funksjonalitet mellom ny og gammel infrastruktur. Funksjonalitet og samspill skal testes både fra eksisterende infrastruktur mot ny infrastruktur og motsatt vei. Det vil bli gjennomført tester av tilgang til eksisterende applikasjonsportefølje fra den nye infrastrukturen. Testene vil bli utført av i regi av eksisterende driftsorganisasjon og Entreprenøren skal bidra med nødvendige ressurser ved uttesting og feilretting. 7 Uthevningen er Capgeminis uthevning.

17 Helsebygg Midt-Norge Side: 17 av 33 Når Test Ansvarlig Hensikt Samtester (B ) HBMN og leverandøren etter behov Etter at brukerutstyr er ferdig montert skal det gjennomføres nye integrerte systemteste (samtester). Samtestene er i prinsippet det samme som integrert test med tester i normal drift og ved ulike feiltilstander 8, men med brukerutstyr (spesielt medisinsk utstyr) på plass og i drift. Totaltester (B ) HBMN planlegger og gjennomfører Dette er en test av total funksjonalitet for hele bygget som f.eks. brann (med røyk), rømning, operasjonsstue, laboratorier, pasientmottak. Det vil bli gjennomført separate tester pr senter. Hensikten er å bekrefte at hele senteret er ferdigstilt i henhold til kontraktens forutsetninger og er klart for overtagelse. Entreprenøren skal delta i totaltester etter behov og vil bli godtgjort for dette i samsvar med kontraktens bestemmelser for regningsarbeider Driftsperiode (B31.4) Avsluttende tester - Final Site Acceptance Test (B31.4.2) HBMN I løpet av den ordinære prøveperioden skal det gjennomføres en samlet akseptansetest (FSA) hvor alle utestående feil/mangler skal sjekkes ut og eventuelt gjenstående tester skal utføres. Under FSA skal det utføres tester på anleggenes samlede funksjonalitet og stabilitet på tvers av alle senter. I tillegg skal ulike driftsrutiner og FDV leveranser kontrolleres. Denne tabellen viser et omfattende testregime hvor strategien er å teste «bottom up» med utgangspunkt i produktkontroller og en avsluttende «Final Site Acceptance Test». Mellom disse testene er det bl.a. lagt inn tester av ulike typer feilsituasjoner som kan opptre hver for seg eller sammen. Omfanget av tester som er definert dekker det som forventes i et prosjekt av en slik størrelse og kompleksitet. Det vil være innholdet i de enkelte testene og hva som testes, som avgjør hvor egnet de vil være til å verifisere løsningen mot kravene. Vi savner imidlertid test av alvorlige driftsforstyrrelser utover problem med strømtilførselen. For å bedømme om testregimet virkelig var egnet til å avdekke svakheter i løsningen, har derfor vårt fokus vært å identifisere hvilke alvorlige driftforstyrrelse scenarier og hvilke katastrofe scenarier er blitt testet og som løsningen derfor vil være forberedt for. B6 [1] i kapittel B6.1.7 beskriver et eksempel på driftsforstyrrelse som skal testes: Et eksempel på test vedrørende redundanstiltak, er at løsning for redundant strømforsyning skal uttestes og verifiseres ved akseptansetest. Det innebærer at strømkilder skal frakobles og det skal dokumenteres at utstyret fungerer i henhold til kravene i kap. B (Strømforsyning). Test av alvorlige driftforstyrrelser er dokumentert i resultatrapport fra Redundanstesten [12]. Hensikten med disse testene var å verifisere at redundanskravene ved strømbrudd i serverrommene og kommunikasjonsrommene var oppfylt for det utstyret som befant seg i serverrommene og kommunikasjonsrommene.. I møte med Telenor angående test [25] ble vi informert om at andre alvorlige driftforstyrrelser og katastrofescenarier ikke er testet. For at St. Olavs Hospital bedre skal være forberedt på alvorlige driftsforstyrrelser savner vi en klargjøring av: Systemeiernes 9 opplevelse av alvorlige driftforstyrrelser, dvs. hva er alvorlig driftsforstyrrelser for systemeierne; systemeiernes utsagn om kritisk nedetid og reserveløsninger som må være på plass dersom de alvorlige driftforstyrrelsene varer lengre enn kritisk nedetid. 8 9 Se fotnote 7. Informasjonsmodelldokumentet [28] beskriver eierskapet til HBMNs forskjellige systemer.

18 Helsebygg Midt-Norge Side: 18 av 33 Sikkerhetsgjennomganger før innflytting: St. Olavs Hospital Flytteprosjektet gjennomførte sikkerhetsgjennomganger, med deltakelse bl.a. fra HBMN og Telenor, før innflytting i sentrene ref [5], [6] og [7]. Sikkerhetsgjennomgangene fokuserte på å sjekke at ting virket som forutsatt. Det ble ikke definert krav til test av driftsforstyrrelser og katastrofesituasjoner. Svar 3.3.1: Testregimet og den testingen som ble gjennomført var ikke egnet til virkelig å avdekke svakheter med løsningen. Vår begrunnelse for dette er at testene bare var designet for å sjekke at systemene virket som forutsatt. Eierne av systemer innen de forskjellige systemområder fikk ikke spørsmål om å beskrive hvilke hendelser som opplevelses som alvorlige driftsforstyrrelser med sikte på at denne informasjonen kunne legges til grunn for å lage reserveløsninger Dekket testene hele leveransen? I tabellen i kapittel fremgår det hvilke tester som skulle utføres av Leverandør og HBMN Tester utført av leverandøren Leverandøren skulle utføre følgende tester (se tabellen i kapittel 3.3.1): Fabrikktest (FAT, Factory Acceptance Test); intern systemtest; utprøving etter installasjon og test (SAT, Site Acceptance Test), og samspill mellom eksisterende og nye systemer. I testing av leveransen forventes det at testnivåene definert i kapittel 1.2 ble gjennomført: Enhetstest dekkes av FAT, der enhetene testes hver for seg; integrasjonstest dekkes av intern systemtest og samspill mellom eksisterende og nye systemer; systemtest dekkes av intern systemtest, og akseptansetest dekkes av SAT og FSAT. Leverandøren har beskrevet sin teststrategi og overordnet testplan i hhv. [8] og [9]. Dokumentasjonen følger i hovedsak prinsippene i testmodellen som er beskrevet i kapittel 1.2. Teststrategi kap Planlegging av test sier: Testspesifikasjonene og gjennomføringen av testen vil ha størst fokus på de områdene i løsningen som kan gi størst konsekvenser og høyest risiko ved eventuelle feil/mangler. I møte med Telenor angående test [25], fikk vi informasjon om at risikovurdering som var gjort i prosjektet (for eksempel FDR Vedlegg 8 Sikkerhets og risikoanalyse og andre rapporter referert i spørsmål 3.3 rapport fase 2) ikke ble benyttet som input til testplanlegging og testgjennomføring. I kommentarer pr har Telenor gitt følgende oppdatering: ROS analysen som ble gjennomført, la grunnlaget for testplan og gjennomføring men vi aksepterer at dette ikke kan direkte spores direkte i dokumentasjon. Av Overordnet testplan [4] fremgår det at krav kategoriseres i hhv. testbare krav og ikke testbare krav: Et krav er testbart (TB) dersom det ikke er av ren administrativ eller merkantil art.

19 Helsebygg Midt-Norge Side: 19 av 33 Oversikt over testbare / ikke testbare krav opprinnelig dokumentert i Overordnet testplan [4], er erstattet med regnearket HBMN_B6 [3]. TestDirector fra Mercury ( er benyttet av leverandøren som testverktøy. Dette testverktøyet er benyttet i hele testprosessen fra dokumentasjon av krav som skal testes, planlegging og utføring av tester, analyse av testresultatene, håndtering av feil og mangler og generering av testrapporter. Til å verifisere om testene dekket hele leveransen av alle testbare krav, forligger følgende rapport(er): Test Dokumentasjon Kommentarer Verifikasjon av testbare krav IST_SAT_B6_Tester.htm [14] IST_SAT_B6_Tester#2.htm [15] B6_req.html [20] Disse rapportene skal kunne benyttes til å sjekke om alle testbare krav er testet. En kontroll viser at bare 40 testbare B6krav er testet. Iht. leverandør er øvrige krav enten overordnet design krav, verifikasjon i design dokumenter eller As built dokumenter. En B6 Requirement rapport [20] gir en krav test oversikt med til dels motsigende informasjon sammenlignet med informasjonen i [14]. Dette kan skyldes at disse rapportene viser status ved forskjellige tidspunkt. FAT FAT_HBMN.zip [18] Denne ZIP filen inneholder innkalling til FAT, mal på protokoll som ble fylt ut skriftlig og oversendt kunden og kjørte tester med test script og testresultater. Intern systemtest SAT Samspill mellom eksisterende og nye systemer Intern systemtest, testrapport, [13] Testrapport - Varsel om klart for integrerte tester Nevro Midt.do, [16] Detaljerte testbeskrivelser med faktisk resultat FK Nevro Øst.xls [17] Det er ut fra Testrapporten ikke mulig å sjekke hvilke kontraktskrav som er testet. Status pr var som følger: Av totalt 388 krav ble 206 testet med vellykket resultat, 88 tester var mislykket, 63 tester ble ikke utført og 31 tester ble ikke avsluttet. For oppdatert status vises det til som ikke er tilgjengelig for Capgemini. SAT dokumentasjon er beskrevet som «Melding om klart for integrerte tester» og testbeskrivelse med faktiske resultater. SAT dokumentasjonen er produsert pr. site. I hht. mail [26]: Kapittel B3 i kontrakten definerer Telenors rolle hva angår grensesnitt. Telenor leverte ved milepæl M14 en kontrakt for hvert grensesnitt hvor alle aksjoner og tester er beskrevet og signert av begge parter. Påfølgende aktivitet var å følge opp aksjonene og Telenor har så levert grensesnittdokumenter som er utkvittert av alle parter. Eksempel på et slikt dokument er MP-sertifikat M14 - Omforent GSdok_signert [29]: Redundanstest Redundanstest, resultatrapport [12] Test av alvorlige driftforstyrrelser er dokumentert i rapporten. Dette er bare en test av at redundanskravene ved strømbrudd i serverrommene og kommunikasjonsrommene var oppfylt. Krav K Sykehusets datanett skal være konfigurert slik at man ikke har noen single point of failures som kan føre til at hele datanettet går ned testes i Test ID (717) - T_IST_SAT_FK_578.01_REDUNDANS [14]. Dette er en 15 trins test som ikke inneholder utfall av firewall, ACS, DNS og DHCP. Redundanstesten [12] er en 13 trins prosess som ble utført etter at strømmen ble avslått i serverrom og kommunikasjonsrom. Av denne testen har vi vanskeligheter med å se om pålogging på nettverket gikk OK når strømmen til primary ACS var koplet ut. Vi kan ikke se at løsningen var designet med reserveløsninger for softwareproblem som medfører stans av samme komponent i infrastrukturen uavhengig av hardwareredundans, typisk problem med samtlige firewalls, ACS, DNS, DHCP; svitsjer med samme programvare (mest kritisk er kjernesvitsjene), og rutere med samme programvare,

20 Helsebygg Midt-Norge Side: 20 av 33 når programvaren benyttes i virksomhetskritiske funksjoner. Kontrakten sier imidlertid ikke noe om at leverandøren skulle laget reserveløsninger for totalt havari ved softwareproblem. Dette ville medført en komplett infrastruktur basert på andre produkter fra andre leverandører. Dette er iht. leverandøren ikke realiserbart mht. økonomiske årsaker. Leverandøren med sin kompetanse og erfaring i den valgte løsningen burde signalisert hvilke alvorlige driftforstyrrelser som kunne oppstå ved softwareproblem som beskrevet her Tester utført av HBMN HBMN skulle utføre følgende tester (se tabellen i kapittel 3.2.1): Integrerte systemtester, samtester, totaltester, og FSAT. Vi har ikke funnet at HBMN har hatt interne krav til dokumentasjon av testprosessen. De har ikke fulgt forventninger til dokumentasjon av testprosessen som beskrevet i starten av kapittel 3.3. Det fins ingen dokumentasjon tilsvarende Overordnet testplan (se kapittel 1.2) eller Testrapporter som oppsummerer resultatet av testingen. Gjennomføring av tester og oppfølging av funn er dokumentert i egne regneark. Integrerte systemtester: HBMN sier i mail [26] Integrerte systemtester følger logikken til andre tekniske entrepriser som har faste installasjoner på det enkelte rom i bygget som må testes. For IKT er ikke dette like aktuelt da brukerutstyr som PCer og telefoner på det tidspunktet ikke er utplassert. Det man sitter igjen med da er sentrale komponenter (servere, telefonsentral, nettverk osv), samt pasientsignal. Det ble derfor besluttet på avdelingsnivå at integrerte tester for IKT skulle inngå i testene som ble utført for kontrakt Dette betyr at pasientsignal ble testet 100% av Utenom dette foretok vi befaringer på byggeplass for å få verifisert at sentrale komponenter var på plass, samt at vi fikk verifisert at nettverket var oppe gjennom at de andre tekniske entreprisene brukte nettverket for sine anlegg. Testrapporter pr. bygg fra integrerte tester bestod av sjekklister der det ble merket av om for eksempel data og telefoni var OK eller ikke. For eksempel viser rapport fra Nevrosentret Sør Nivå 1 også at pasientsignal var OK, men det er ikke funnet dokumentasjon av hvordan det ble testet. Samtester: HBMN sier i mail [26] Gjennomføringen av Samtester ble planlagt i møte 25. april I møtet ble kontraktens kapittel fordelt mellom de i Helsebygg som jobbet med IKT kontrakten: <navn 10 >. Metodikken som ble avtalt var å ta utgangspunkt i kontrakten og legge opp tester for å få bekreftet leveransen gjennom funksjonalitet. I møtet ble det notert på flip-over og det ble sendt ut mail i ettertid, men dette er dessverre ikke tilgjengelig lenger. Metodikken gjorde at en test kunne dekke flere krav, mens andre krav kanskje trengte flere tester. Ut fra vår kjennskap til kontrakten la vi 10 Navn på 4 ansvarlige personer er fjernet fra teksten

21 Helsebygg Midt-Norge Side: 21 av 33 opp til å kjøre dypere tester på de områdene som vi trodde kunne inneholde feil enn de områdene som var rene produktleveranser. For å begrense ressursbruken på dokumentasjon valgte vi å kun dokumentere avvikene avdekt i våre tester. Ble det funnet avvik ble disse skrevet ned i egne dokument som ble fulgt opp mot Telenor. Etter at Telenor hadde meldt tilbake om utbedring ble tester på disse områdene gjentatt. Det ble i den sammenheng også utført tester på tilgrensende områder som vi mente kunne bli påvirket av disse utbedringene. Helsebygg mente på samtest-tidspunktet at Telenor ikke hadde kjørt tilstrekkelig med tester hva angår funksjonalitet på tvers av krav og på tvers av kapittel i leveransen. Telenor administrerte derfor i løpet av samtestperioden en rekke funksjonstester som inkluderte personell fra St Olav/NTNU og Helsebygg. Både Helsebygg og Telenor dokumenterte og fulgte opp avvik fra disse testene. De dokumenterte avvikene ble fulgt opp kapittelvis til et visst nivå før de ble samlet i en felles oppfølging. Avvikene inngår også med en oppdatert samlet status i overtakelsesprotokollene fra det enkelte senter. Underlagsdokumentene er å anse som arbeidsdokumenter, så den endelige status på den enkelte sak er ikke oppdatert i det enkelte dokument, men foreligger i de aggregerte oversiktene. Totaltester: HBMN sier i mail [26] Totaltester foretatt av Helsebygg hadde som hensikt å teste byggenes funksjonalitet i forskjellige scenarier. Testene ble i alle hovedsak gjennomført ved å koble ut strøm i forskjellig omfang for å se at de nødvendige failover-mekanismer og reservekraftløsninger fungerte som forutsatt. IKT deltok på testene på linje med de andre tekniske entreprisene som forutsatt. Det var aldri planlagt eller forutsatt at IKT skulle gjøre spesielle totaltester. FSAT: Final Site Acceptance Test ble gjennomført som kravsporing [11] 11. Mangelfull testdokumentasjon for planlegging og sluttrapporter viser at testene HBMN hadde ansvar for, ikke ble gjennomført på en strukturert måte med formell dokumentasjon. I møte [27] kom det frem at IKT-prosjektet hos HBMN ikke hadde dokumentert prosjektplan/kvalitetsplan (utover B31 Prosjektgjennomføring [2]) som kunne beskrevet krav til test- og godkjenningsprosess nærmere. Vi mener at dette er en mangel i prosjektgjennomføringen, og gjør at den ble svært avhengig av sentrale personers kompetanse og tilgjengelig tid til testaktiviteter. Det fremkom også at ressurser fra St. Olavs Hospital som deltok på tester benyttet leverandørens tester som utgangspunkt, men gjorde også en god del ad-hoc testing. Slik testing vil være nyttig, men det er vanskelig å spore hvilke tester som er gjennomført (testdekning), og hva som fører til feilsituasjoner. Re-test etter feilretting vil også måtte gjøres basert på hva vedkommende tester husket fra forrige test. Regnearkene [21] og [22] ble benyttet for å følge opp status for aksjoner fra testaktiviteter, mangler og endringer i prosjektet. De mottatte rapportene inneholder flere punkter som ikke er lukket. Det er ikke klart hvordan de åpne punktene er fulgt opp videre, selv om vi kan anta at de er lukket i godkjenningsperioden. Mangelfull dokumentasjon gjør det vanskelig i ettertid å spore hvilke tester som ble gjort når og men hvilke resultater. 11 Se gjennomgang av FSAT i kap 4 Vedlegg

22 Helsebygg Midt-Norge Side: 22 av 33 Sikkerhetstest ved HBMN: Den 31. august 2005 forelå en rapport fra HBMN [23] etter en sjekk av sikkerhetshull eller sårbarheter i «det nye sykehusnettverket», bl.a. Gjestenett/tankenett, Internt sykehusnett og IPtelefoninettet. I tillegg foreligger det 4 stk. Nessus ( ) genererte rapporter [24] som viser antall servere/hoster som ble testet, antall sikkerhetshull som ble identifisert og antall sikkerhetsadvarsler. Dette er oppsummert i tabellen under. Nettverk Antall servere Sikkerhetshull Sikkerhetsadvarsler x x x x Dette store antall av sikkerhetshull er høyt fordi denne testen ble utført av Proxycom etter at en liknende test ble utført at leverandøren. Problemet med tilgang fra tanke/gjestenettverket og DMF-nettverket inn mot servernettverket der de interne sykehusserverne som var det alvorligste problemet, er løst. [Leverandør mail VS: Utestående tilbakemelding fra Telenor pr av 2/11-07, 30]. I leverandør mail [Leverandør mail SV: HBMN, Sikkerhetstest ved HBMN, oppfølging fra Telenor av 10/11-06] er vi informert om at dersom Proxycom hadde gjentatt samme test i dag, ville alle sikkerhetshull vært tettet, gitt at penetrasjonsverktøy som ble benyttet hadde brukt samme test med samme «regelsett» eller «signaturer» som Proxycom benyttet. Driftsleverandøren oppdaterer kontinuerlig programvaren med sikkerhetspatcher for de gjeldene systemene som benyttes når disse blir publisert og etter at de blir testet/verifisert av driftsleverandøren. Dette skjer iht. prosedyrer (typisk change og release management). Oppsummering: Testene dekket ikke hele leveransen. Vår begrunnelse for dette er: Kommentarer vedr. testene til leverandør: Leverandøren gjennomførte testprosessen på en profesjonell måte og prosessen var i henhold til kontraktens krav. Testdekning var tilstrekkelig for test av funksjonalitet. Vi savner imidlertid at leverandøren informerte HBMN om konsekvensene ved alvorlige softwareproblem som medfører stans av samme komponent i infrastrukturen uavhengig av hardwareredundans. Denne type softwareproblem er mest kritisk for kjernesvitsjene. Kontrakten sier ikke noe om dette, men vår begrunnelsen for dette punktet er at leverandørens kompetanse og erfaring i den valgte løsningen overstiger kunden HBMNs kunnskap om teknologien som er lagt til grunn. Hva angår alvorlige driftforstyrrelser burde systemeierne blitt rådspurt. Vi har vansker med å verifisere om leverandøren har testet samtlige testbare krav. Dette skyldes at et fåtall av testrapportene viser en sammenheng mellom krav og test. Mangler ved testene til HBMN: HBMN har ikke tilstrekkelig dokumentert sine tester i henhold til beskrivelse i B31 Prosjektgjennomføring [2] og leverandørens Teststrategi [8]. Formell planlegging manglet, og gjennomføringen var for en god del basert på udokumentert testing. Det er ikke mulig i ettertid å kontrollere hva som ble testet.

23 Helsebygg Midt-Norge Side: 23 av 33 Det kan stilles spørsmål til om ikke leverandøren som profesjonell part burde stilt strengere krav til formalitet i HBMNs testgjennomføring for å sikre bedre sporbarhet i testgjennomføring og godkjenning. Svar 3.3.2: Testene dekket ikke hele leveransen. Vår begrunnelse for dette er: Mangler ved testene til leverandør Mangler ved testene til HBMN Var testing og verifikasjon før idriftsettelse tilstrekkelig? Kilder: [B31 Prosjektgjennomføring.doc i kontrakten, 1]; [ B02-FDR Vedlegg 14 Teststrategi.doc,2]; [ B02-FDR Vedlegg 11 Overordnet Testplan.doc,3]; [ B02-FDR Vedlegg 13 Testplan SAT.doc,4]; [Rapport Sikkerhetsgjennomgang labsenter rev pdf, 5]; [Rapport Sikkerhetsgjennomgang kv-barnsenteret pdf, 6]; [Rapport Sikkerhetsgjennomgang Nevrosenteret del2 rev pdf, 7]; [Eval. Lab Rapport Kopi k2000 u.off.doc ( ), 8]; [Evaluering Innflytting Ibruktakelse kopi K 2000 u off.doc ( ), 9]; [Evaluering Innflytting Nevro Rapport versjon 0.1 K 2000.doc ( ), 10]. B31 Prosjektgjennomføring [1] gir en samlet oversikt over tester og verifikasjoner. Generelt krav vedrørende test (B ) er: Alle tester skal gjennomføres på bakgrunn av en godkjent prosedyre, testplan. Denne skal som et minimum inneholde beskrivelse av: o Formål med testen o Omfang av testen o Omgivelser, testmiljø o Forberedelse til testen og nødvendig utstyr og fasiliteter o Gjennomføring av testen o Rapporteringsformat o Forventede resultater o Akseptansekriterier Entreprenøren skal dokumentere testplan i eget dokument sammen med utfylte skjema for hver enkelt test som skal gjennomføres. Entreprenøren skal lage forslag til tester og Byggherren kan fritt foreslå supplerende tester som Entreprenøren skal innarbeide i testplanen. Etter at tester er gjennomført skal Entreprenøren sammenstille resultatene fra testen i egen rapport og utarbeide problemrapporter for alle uregelmessigheter som blir registrert.

24 Helsebygg Midt-Norge Side: 24 av 33 Følgende er en oversikt av testing og verifikasjon før idriftsettelse fra Teststrategi [2]: Entreprenøren skal gjennomføre følgende tester: FAT Hensikt Innhold Verifisere at produktene i leveransen er i overensstemmelse med krav til produktet. Produkter kan være pasientterminal, Tablet PC, MDA osv. FAT gjennomføres på spesifikke produkter som er valgt ut i samarbeid med HBMN Intern systemtest Hensikt Innhold Verifisere at systemer, integrasjon mellom systemer, og funksjoner har korrekt kvalitet i et simulert produksjonsmiljø før implementering på sentrene Intern systemtest inkluderer alle produkter og systemer som er mulig å teste i intern testlab. Testen inkluderer Systemkontroll, Integrasjonstest, Funksjonskontroll, Ytelse, Sikkerhet og Drift og overvåking. SAT Hensikt Innhold FSAT Hensikt Innhold Verifisere at systemer, integrasjon mellom systemer, og funksjoner fungerer i senteret ihht krav SAT inkluderer alle produkter og systemer i leveransen. Testen inkluderer Systemkontroll, Integrasjonstest, Funksjon&bruker, Ytelse, Sikkerhet og Drift og overvåking. Testen vil bli utført pr Kontrollområde og pr Senter ihht utbyggingsplanene. Verifisere alle utestående feil/mangler evt gjennomføre gjenstående tester Testene utføres på anleggenes samlede funksjonalitet på tvers av alle senter. Inkluderer driftsrutiner og FDV leveranser For FSAT er det uoverensstemmelse mellom B31 Prosjektgjennomføring [1] som sier at HBMN er ansvarlig for FSAT og Teststrategi.doc [2] som sier at Leverandøren er ansvarlig. Vi antar at Teststrategi beskriver omforent forståelse, selv om det ikke er funnet dokumentasjon på at det er formelt avtalt. I følge kommentar fra Telenor er kontraktens formulering gjeldende. Testregimet som er beskrevet i Teststrategi [2], Overordnet testplan [3], Testplan for SAT [4] er i henhold til god praksis for testdokumentasjon. Se kapittel Tester utført av leverandøren for kommentarer til planlegging og gjennomføring. HBMN er ansvarlig for å gjennomføre følgende tester: Integrerte systemtester Hensikt Innhold Samtester Verifisere at systemer, integrasjon mellom systemer, og funksjoner fungerer i senteret på tvers av kontrollområder. Integrerte systemtester inkluderer alle produkter og systemer i leveransen. Dette er en funksjons- og kapasitetstest, gjennomført med byggutstyr eksklusiv brukerutstyr. Hensikt Innhold Verifisere at systemer, integrasjon mellom systemer, og funksjoner fungerer i senteret på tvers av kontrollområder. Samtester inkluderer alle produkter og systemer i leveransen. Funksjons- og kapasitetstest, gjennomført med byggutstyr inklusiv brukerutstyr. Totaltest Hensikt Innhold Verifisere leveransen for hele senteret. Testen skal bekrefte at hele senteret er ferdigstilt ihht kontraktens forutsetninger og er klart for overtagelse. Totaltest inkluderer test av full funksjonalitet for et helt senter med tung integrasjon mot Teknisk infrastruktur og øvrige sentre. Deler av medisinsk virksomhet deltar på testen. Se kapittel Tester utført av HBMN for kommentarer til planlegging og gjennomføring.

25 Helsebygg Midt-Norge Side: 25 av 33 Sikkerhetsgjennomganger før innflytting: St. Olavs Hospital Flytteprosjektet gjennomførte sikkerhetsgjennomganger før innflytting i sentrene ref [5],[6],[7]. Sikkerhetsgjennomgangene ble gjennomført i perioden august-05 til februar-06. Dokumentasjonen viser at status for test bedret seg i perioden. Vi har imidlertid ikke tilgang til dokumentasjon som viser om alle aksjonspunktene er håndtert og er lukket. Integrerte tester (begrepet verdikjedetester er også benyttet) for kritiske prosesser er sannsynligvis ikke gjennomført i tilstrekkelig grad. Slike tester er nødvendige for å verifisere at leveransen er i henhold til kravene. Evaluering av ibruktakelse/innflytting: Enhet for Nytt Sykehus, St. Olavs Hospital, har i samarbeid med St. Olavs Eiendom gjennomført evaluering [8, 9, 10] av alle prosessene som omfattes av ibruktakelse/innflytting i de nye sentrene, deriblant testing og IKT. Formålet var å kartlegge de involverte aktørers erfaringer i forhold til ferdigstillelse, overtagelse, innflytting, ibruktakelse, organisering, drift, driftsplanlegging osv. Evalueringsrapportene ble skrevet i perioden januar-06 til juni-06. Møtereferatet er fra tidspunkt etter innflytting i Labsenteret. I rapportene ble det hevdet at tester ikke ble gjennomført i tilstrekkelig grad før innflytting og ibruktakelse. Oppsummering Testing og verifikasjon før idriftssettelse var ikke tilstrekkelig. Den definerte prosessen for verifikasjon av løsningen var god, men gjennomføringen fulgte ikke prosessen godt nok. Telenor testet de enkelte delene av systemet og integrasjon mellom dem. Testdekning for avvikssituasjoner var for dårlig. HBMN deltok på noen av Telenors tester. FSAT ble gjennomført som en kravsporing. Test av driftsrutiner ble ikke gjort på annen måte enn ved dokumentgjennomgang før de ble tatt i bruk i prøvedriftsfasen.. De testene HBMN var ansvarlig for var ikke formelt planlagt, avvik som ble registrert ble fulgt opp i egne regneark, men oppsummering av testaktiviteter, erfaring og testresultater i testrapporter eksisterer ikke. St. Olavs Hospital deltok på test av løsningen, men fokus for testene var å sjekke om tjenestene og funksjonaliteten virket som forutsatt, og ikke test av avvikssituasjoner. Rolle- og ansvarsfordeling mellom HBMN og St. Olavs Hospital var ikke klar. I evalueringsrapportene fremkom det meninger om at kvaliteten (se definisjon kap 1.1) av de leverte systemene ikke var god nok.. Svar 3.3.3: Testing og verifikasjon før idriftssettelse var ikke tilstrekkelig. Den definerte prosessen for verifikasjon av løsningen var god, men gjennomføringen fulgte ikke prosessen godt nok. De testene HBMN var ansvarlig for var ikke formelt planlagt og dokumentasjon av testresultater i form av testrapporter eksisterer ikke.

26 Helsebygg Midt-Norge Side: 26 av Var klargjøring for drift tilstrekkelig for å sette løsningen i drift? Kilder: [B2 Overordnet beskrivelse i kontrakten, 1]; [ B02-FDR Overordnet systembeskrivelse, 2]; [Avtale om drifts- og vedlikeholdsytelser mellom HMN v/st. Olavs Hospital og Telenor Telecom Solutions, 3]; [ R.01.SP.007 Spesifikasjon for ferdigstillelse, funksjonsprøving, prøveperiode og overtakelse, 4]; [Overtakelsesprotokoll IKT-endelig.doc, 5]; [ B34-SLA rapport januar 06_oppdatert.doc, 6]; [ B34-SLA rapport FEBRUAR 06.doc, 7]; [ B34-SLA rapport MARS_ doc, 8]; [ B34-SLA rapport_april_revidert_06.doc, 9]; [ B34-Revidert _SLA rapport_mai_06.doc, 10]; [Mail fra Dag Erling Stakvik, EDB , 11] [Mail fra Børge Godhavn, HBMN , 12]. I kapittel B2.5.1 Overordnede målsetninger og retningslinjer i B2 Overordnet beskrivelse [1] heter det angående forvaltning, drift og vedlikehold: Entreprenøren skal utvikle en overordnet driftsarkitektur med definerte krav innenfor følgende områder: o Feilhåndtering (klassifisering, kategorisering, håndtering) o Avregning og bruk o Konfigurasjonsstyring (endringsprosedyrer, dokumentasjon og vedlikehold av denne) o Ytelses- og kvalitetsovervåking (måleparametre, ressursbruk, tilgjengelighet, pålitelighet) o Sikkerhet (autentisering, autorisering, kryptering, tilgjengelighet) Entreprenøren skal søke, standardisere og konsolidere driftsverktøy og tilhørende driftsrutiner innenfor sitt leveringsomfang. Entreprenøren skal etablere Tjenesteavtaler (SLA) mellom Entreprenør og HBMN med et veldefinert og målbart servicenivå for hensiktsmessige deler av leveransene. Utforming av disse skal være basert på de samme prinsippene som de som benyttes ved St. Olavs Hospital HF og/eller i HMN. Entreprenøren skal som minimum etablere dokumenterte driftsrutiner for alle typer aktiviteter som kan påvirke drifts- og IT-sikkerheten til alle kritiske systemer. Entreprenøren skal etablere og vedlikeholde en utstyrsdatabase med oversikt over installasjonstidspunkt, garantiperiode, utstyrskonfigurasjon (hardware og software), serviceavtaler og tilhørende standard dokumentasjon. Entreprenøren skal etablere prosedyrer for å håndtere overgang mellom leveranse og drift for å sikre rett kvalitet på systemer som skal i driftsettes. Tilsvarende rutiner skal benyttes ved oppgradering til nye versjoner/releaser av systemer som er i drift.

27 Helsebygg Midt-Norge Side: 27 av 33 I kapittel Drift i B02-FDR Overordnet systembeskrivelse [2] heter det: Driftskonseptet er basert på solid erfaring og best practice. Forutsetninger for effektiv drift er: o Standardisert maskinvare og maskinvare-konfigurasjoner på skalerbar plattform. o Etablerte prosesser rundt endrings- og avvikshåndtering o Øvrige definerte prosesser i henhold til ITIL. Klargjøring for drift forutsetter bl.a.: 1. Avtale for drifts- og vedlikeholdsytelser; 2. en SLA avtale mellom Kunden (St. Olavs Hospital og NTNU) og Leverandøren; 3. signert overtakelsesprotokoll. Med «klargjøring for drift» forstår vi derfor hvorvidt disse kravene er oppfylt i tillegg til spørsmålet som reises i kapittel Avtale for drifts- og vedlikeholdsytelser Den 23. mars 2006 ble det signert en Avtale for drifts- og vedlikeholdsytelser mellom Telenor Telecom Solutions som Leverandør og St. Olavs Hospital samt NTNU som Kunde. Avtalen [3] er basert på Statens standardavtale om vedlikehold og service av utstyr og programmer av september 2003 og har følgende vedlegg: Bilag 1: Utstyr som skal vedlikeholdes. Bilag 2: Programmer som omfattes av ytelsen. Bilag 3A: Utdypende spesifikasjon av ytelsene. Bilag 3B: Service Level Agreement (SLA). Bilag 4: Samlet oversikt over priser og betalingsbestemmelser. (Bilag 5: Vedlikehold av senere anskaffelser, ikke inkludert.) Bilag 6: Leverandørens forutsetninger ovenfor Kunden. Bilag 7: Endring i forhold til den generelle avtaleteksten. Bilag 8: Endringer og tilføyelser etter avtaleinngåelsen. Bilag 9: Samhandling og eskalering SLA avtale mellom Kunden (St. Olavs Hospital og NTNU) og Leverandøren SLA avtalen er inneholdt i Bilag 3A Utdypende spesifikasjon av ytelsene og innholder en beskrivelse av rammeverket for drift, driftsmodell, driftsløsning og driftsytelser som er avtalt mellom Kunde og Leverandør. SLA avtalen er basert på ITIL og forutsetter: Operative ITIL Service Management og Service Delivery prosesser, og en operativ ITIL basert organisasjon til å utføre Service Management og Service Delivery prosessene.

28 Helsebygg Midt-Norge Side: 28 av ITIL Service Management og Service Delivery prosesser Leverandørens rammeverk for drift er basert på ITIL som består av bl.a. følgende prosesser: Service Management (reaktiv drift) fokuserer på at brukerne av IT teknologi har løpende tilgang på nødvendige IT baserte funksjoner/tjenester for støtte av virksomhetsprosessene: o Service desk o Incident management o Problem management o Configuration management o Change management o Release management Service Delivery (proaktiv drift) fokuserer på nødvendige forebyggende prosesser for at IT teknologien skal kunne gi forventet støtte til brukerne av denne IT teknologien: o Service level management o Capacity management o IT service continuity management o Availiability management o Financial management for IT services o Security management I Bilag 3A savner vi beskrivelse av følgende ITIL prosesser: Service level management for overvåkning og rapportering av ytelsene spesifisert i SLAavtalen Availiability management for bl.a. overvåkning og rapportering av tilgjengelighet Finacial management for bl.a. avregning og bruk og Security management som beskriver styringssystemet for informasjossikkerhet hos leverandøren basert på Code of practice for information security management kjent under betegnelsen ISO/IEC 17799, tidligere kalt BS Vi har også forsøkt å lete i prosjektdokumentasjonen etter driftsprosedyrer som støtter opp om disse ITIL prosessene uten å lykkes med det. SLA rapportene [6; 7; 8; 9; 10] viser imidlertid at tilgjengelighet av tjenester og hendelser ble rapportert, men som nevnt driftsprosedyrene har ikke vært tilgjengelig for oss. Om Continuity management heter det bl.a.: Leverandøren har etablert prosess for kontinuitetsplanlegging (Continuity Management). Prosessen som omfatter katastrofeplanlegging, risikoanalyser og sårbarhetsanalyser vil forhindre at hendelser av bestemte typer fører til krise ved at det avtales og etableres kontinuitetsløsninger for våre kunder. I tillegg sikre at planer eksisterer og fungerer til enhver tid, at det finnes administrative kontinuitetsplaner pr. lokasjon hvor det finnes teknisk utrustning eller viktig personell for drifting av kunders applikasjoner.

29 Helsebygg Midt-Norge Side: 29 av 33 Prosessen vil også sikre at det finnes administrative kontinuitetsplaner og tekniske kontinuitetsløsninger for hvert miljø som drifter kunders applikasjoner eller tjenester i tillegg til tekniske tester med en frekvens iht. avtaler med kunder. Vi har ikke mottatt informasjon fra leverandøren om hvilke planer som forelå hva angår implementering av Continuity management prosessen hos St. Olavs Hospital og NTNU. Vi er usikre på om slike planer faktisk forelå. EDB har informert om at EDBs kvalitetssystem er en implementering av Continuity management for EDB virksomhet [11] ITIL basert organisasjon til å utføre Service Management og Service Delivery prosessene I mail [11] har vi fått informasjon om prosjektdeltagerne ved oppstart av LAB og drift med bl.a.: Service manager; feilmottak og bestilling; Onsite; nettv/fw; server/app.drift; leveranse; overvåkning; sikkerhet, og produkt løsningsarkitekt. Incident Manager hos EDB var ikke en del av prosjektet. Change management ble håndtert i prosjektet. I tillegg til disse personene hadde den enkelte systemeier også et ansvar for å bistå B34. Denne organisasjonen skulle iht. B34 Drift i kontrakten [2] yte drifts- og tilleggstjenester til: B4 Strukturert kabling B5 Kommunikasjonssystemer o B5.1 Telefoni o B5.2 Trådløs telefoni o B5.3 Meldingstjener o B5.4 Pasientsignal o B5.5 Alarmering og gjenfinning o B5.6 Digital Diktering o B5.7 Pålogging og Autentisering B6 Datanett B7 Sentralutstyr for Tv-distribusjon B8 AV-anlegg B9 Pasientterminaler B10 MDA/PDA

30 Helsebygg Midt-Norge Side: 30 av 33 B11 Annet Periferiutstyr B12 Katalogtjeneste Signert overtakelsesprotokoll Dette er et dokument som bekrefter at krav til overlevering fra prosjektorganisasjonen til driftsorganisasjonen er tilfredstilt, og at leveransen er akseptert av driftsorganisasjonen. Formalia for overtakelse er beskrevet i Spesifikasjon for ferdigstillelse, funksjonsprøving, prøveperiode og overtakelse [4]. Overtakelsesprotokoll IKT-endelig [5] datert viser til: SLA rapporter hva angår protokoll fra prøveperioden; HBMNs og leverandørens FSAT dokumentasjon hva angår protokoll fra utført sluttkontroll; milepælsdokumenter for Opplæring hva angår skriftlig status for opplæring; sent mottatt, ikke gjennomgått/godkjent komplettering av all sluttdokumentasjon (FDV og som bygget dokumentasjon); kontraktsarbeidene som har vært besiktiget gjennom SAT, FSAT og SLA-rapporter; 19 mangler samt gjenstående arbeider (status pr ) SLA rapporter hva angår protokoll fra prøveperioden Vi har lest SLA rapportene for perioden januar 2006 mai 2006 [6; 7; 8; 9; 19] som bl.a. viser en tilgjengelighet av nettverket bedre enn kravet i 4 av månedene. Fra og med april måned innholder SLA rapportene også årsak, konsekvens og tiltak for hendelser som påvirker oppetiden av tjenestene. Dette dokumenterer leverandørens evne og vilje til å bedre brukeropplevelsen av løsningen HBMNs og leverandørens FSAT dokumentasjon hva angår protokoll fra utført sluttkontroll Se kapittel 4 for gjennomgang av FSAT som viser at av totalt 12 krav, ble 5 stk. krav testet med tilfredsstillende resultat i FSAT, og 7 stk. ikke verifiserte krav. Dette var status Pr. mail [12] er vi blitt informert om at det er en pågående prosess mellom HBMN og leverandøren for å komme til enighet om disse utestående kravene. Oppsummert er status at så godt som alle enten er lukket eller besluttet løst økonomisk. Proxycom [24] og leverandøren uførte sikkerhetstester av datanettet. Vi kan ikke se at Proxycoms test er en akseptansetest av IDS. Rapporten fra leverandørens sikkerhetstest er ikke stilt til vår disposisjon, referanse til møte med testleder [25]. Vi savner derfor en test av IDS-systemet med utgangspunkt i virusangrep, hackerangrep og andre trusler samt hard trafikk belastning Vedr. 19 overtakelsesmangler samt gjenstående arbeider Overtakelsesprotokollen [5] viser at det var 19 overtakelsesmangler samt gjenstående arbeider ved overtakelsen Pr. mail [12] er vi informert om at ikke lenge etter overtakelsen sendte leverandøren et brev om sitt syn på disse manglene. HBMN var ikke enig i leverandørens syn. Det er for tiden løpende kontakt mellom partene. Noen krav er lagt døde på den måten at de bringes inn som et motkrav i sluttoppgjøret. Oppsummert er status at så godt som alle enten lukket eller besluttet løst økonomisk.

31 Helsebygg Midt-Norge Side: 31 av 33 Det ble utført en risikovurdering av manglene som ble dokumentert ved overtakelsen. Konklusjonen fra denne vurderingen ble at det var forsvarlig å overta leveransen for idriftsetting. Svar: Klargjøring for drift var tilstrekkelig for å sette løsningen i drift. Vi ønsker likevel å påpeke følgende: Leverandøren hadde ikke spesifikke planer hva angår implementering av Continuity management prosessen hos St. Olavs Hospital og NTNU.. I forbindelse med FSAT savner vi en test av IDS-systemet med utgangspunkt i virusangrep, hackerangrep og andre trusler samt hard trafikkbelastning. Proxycom [24] og leverandøren uførte sikkerhetstester av datanettet. Vi kan ikke se at Proxycoms test er en akseptansetest av IDS. Rapporten fra leverandørens sikkerhetstest er ikke stilt til vår disposisjon, referanse til møte med testleder [25], og kan derfor ikke uttale oss om denne testen var en akseptansetest av IDS. 3.5 Er nettet konstruert på en slik måte at kontraktskravet % pr. måned kan oppnås? Se egen rapport fra Datametrix for detaljer. Svar: Beregninger og designvurderinger tilsier at kontraktskravet på 99,999 % tilgjengelighet kan oppfylles.

32 Helsebygg Midt-Norge Side: 32 av Vedlegg: Kravsporingsprosess FSAT Kilde: [BR-TEL-HBMN-0726, Vedlegg, Rapport Kravsporing FSAT1.pdf, 1] 12. Følgende er en oppsummering av kravsporingssaker for B6 beskrevet i Kravsporingsprosess FSAT rapporten [1] etter avsluttende tester (FSAT, Final Site Acceptance Test): A) [K6.1-1 (4)]: Løsningen skal være fundamentert på internasjonale standarder/industristandarder. Hvilke internasjonale standarder/industristandarder som er benyttet er ikke beskrevet. Det fremgår ikke at dette kravet er avklart B) [K6.1-8]: Rutere og stamnettsvitsjer skal støtte protokollstakk både for IPv4 og IPv6. Det fremgår ikke at dette kravet er avklart. C) [K6.1-27]: Det må være støtte for SNMP og RMON. Tilsynelatende er dette kravet avklart. D) [K6.1-77]: Antall omstart av programvaren i alle nettverkskomponenter på grunn av feil skal ikke overstige 2 pr. år for alle komponenter. Dette gjelder omstart som fører til totalfeil (se punktet "Tilgjengelighet"). Det fremgår ikke at dette kravet er avklart. E) [K6.1-84]: Det tilbudte systemet skal inneha 99,999% tilgjengelighet innenfor tidsintervall på en måned. Det fremgår ikke at dette kravet er avklart. F) [K6.1-97] IP-telefoni og TV-/underholdningsdistribusjon skal kunne mottas på terminaler i alle sikkerhetssoner over hele sykehuset. Entreprenøren skal sørge for at dette ivaretas i sikkerhetsløsningen. Multicast gjennom brannmur. Det fremgår ikke at dette kravet er avklart. G) [K ]: Det skal tilbys et IDS-system for å sikre datanettet ved Nye St. Olavs Hospital mot eksterne trusler (virusangrep, hackerangrep og andre trusler). Tilsynelatende er dette kravet avklart. (Vi har nå gjennomgått visning av IDS, og Knut Carlsen er fornøyd. Han ba meg kontakte deg og godkjenne IDS entyet i FSAT. Ref mail fra Bjørn Hval, B6 sikkerhet.) Vi savner en akseptansetest at IDS-systemet med utgangspunkt i virusangrep, hackerangrep og andre trusler samt hard trafikk belastning. Det fremgår ikke hvorfor Knut Carlsen ble fornøyd. H) [K (4)]: Systemet må ha et godt grafisk grensesnitt for blant annet : - Presentasjon av statistikker (sanntid, time, dag, uke, måned, år) - Meldinger (når terskelverdier krysses) Trender (f.eks når bør en enhet oppgraderes med mer CPU) Overblikk over enheter og visualisere trafikk mellom disse) Tilsynelatende er dette kravet avklart. I) [K ]: Grafisk presentasjon av historisk trafikkmengde, feilpakker og protokollfordeling over lengre intervall, for eksempel opp til 60 dager. Tidsintervall skal kunne velges fritt. 12 Dette er versjonen som vi er gjort kjent med. Telenor sier i kommentar at det ikke er siste versjon, men har ikke sendt oss nyere versjon.

33 Helsebygg Midt-Norge Side: 33 av 33 Grafisk presentasjon av trafikkmengde og protokollfordeling mellom noder på alle segmenter eller angitte segmenter. Tilsynelatende er dette kravet avklart. J) [K ]: Følgende skal minimum inngå ved overvåking av utstyr: Ytelsesovervåking (CPU, memory, porter o.l.) Kvalitetsovervåking (Feilrater på porter og forbindelser o.l.) Feilovervåking (Feil på utstyr, strømforsyning, vifter, forbindelser o.l.) Tilsynelatende er dette kravet avklart. K) [K ]: Det skal finnes tilsvarende RMON agent for monitorering av hver port. RMON agenten bør støtte alle 9 RMON-informasjonsklasser. Det fremgår ikke at dette kravet er avklart. L) Helsebygg viser til kontraktens kapittel B : B IP-plan Det fremgår ikke at dette kravet er avklart. Av totalt 12 krav, ble 5 stk. krav testet med tilfredsstillende resultat i FSAT, og 7 stk. ikke verifiserte krav.