Bilag til BBR- review

LAKESIDE A/S Marselisborg Havnevej 32, 1 8000 Århus C +4 210 722 cvr-nr.: 24 0442 info@lakeside.dk www.lakeside.dk Bilag til BBR- review Opsummerende reviews

1. Indholdsfortegnelse 1. Indholdsfortegnelse... 2 2. Læsevejledning... 3 3. Review af dokumentation: Overblik... 4 3.1 3.2 3.3 Kapitel 1 - Indledning... 4 Kontrakt KMD-BBR samt bilag (bilag 1-13)... 4 Leverance-kontrakt Nyt BBR samt bilag 1-22 (pånær bilag 2 kravspecifikation)... 4.1 4.2 Kapitel 11 - Overensstemmelsesmatrix krav systembeskrivelse... 9 Leverance-kontrakt Bilag 2 - Kravspecifikation... 9.1 Kapitel 2 - Systemarkitektur... 11.1.2.3.4...7.8.9.10 Kapitel 3 - Forretningslogik... 12 Kapitel 4 - Brugerdialog samt bilag... 13 Kapitel - Udskrifter til borgerne... 13 Kapitel - Dataudveksling... 14 Bilag til kapitel : Energidata ind i BBR... 1 Kapitel 7 - Datamodel... 1 Kapitel 8 - Administrationsdatabase... 17 Kapitel 9 - Sikkerhed... 18 Kapitel 10 - Rapporter (Systembeskrivelse)... 19 Vejledning til snitfladen: AddressGeometryService... 20 7.1 Brugerdokumentation (pakke med 8 dokumenter)... 22 4. Underområde: Krav... 9. Review af dokumentation: Arkitektur og Design... 11. Review af dokumentation: Systemdokumentation... 12 7. Review af dokumentation: Brugerdokumentation... 22 8. Review af dokumentation: Udviklerdokumentation... 24 8.1 Kildekode i Visual Studio projekter med et (større) antal underprojekter. Enkelte udviklerrettede afsnit i systemdokumentationen.... 24 9. Review af dokumentation: Test og performance... 2 9.1 9.2 Resultat af overtagelsesprøve februar 2012 samt bilag... 2 Loadtest februar 2012... 2 10.1 10.2 10.3 10.4 Driftskontrakt samt bilag (pånær bilag 3 Driftshåndbog)... 28 Driftshåndbogen... 28 Installationsvejledning for NYT BBR Applikationsserver... 29 Installationsvejledning for NYT BBR Webserver... 30 10. Review af dokumentation: Driftsdokumentation... 28 2

2. Læsevejledning Dette dokument opsummerer reviewet af Nyt BBR-dokumentationen samt kildekoden til it-systemet. Dokumentet er struktureret efter de dokumentationsområder, som dokumentationen dækker. Hvert område og de tilhørende dokumenter er vurderet i forhold til, hvordan de samlet set løfter opgaven med at beskrive, fastholde og overlevere overblik og forståelse af Nyt BBR-løsningen. Områderne er vurderet efter om dokumentationen er fyldestgørende; om den er forståelig; om den er retvisende og i hvilken grad dokumentation understøtter en eventuel overdragelse af Nyt BBR til en ny udviklingsog driftsleverandør. en er lagt ud efter en skala fra 1-10, hvor 1 repræsenterer den utilstrækkelige og meget mangelfulde dokumentationsgrad og 10 den meget omfattende og stort set perfekte dokumentation. Det bør noteres at selvom 1 ikke bør tilstræbes i forhold til best-practice for system-dokumentation er 10 heller ikke nødvendigvis det optimale mål. Det er både ressource-krævende og måske ikke værdiskabende at investere i denne dokumentationsgrad på alle punkter. 3

3. Review af dokumentation: Overblik 3.1 Kapitel 1 - Indledning Kapitlet indeholder et sammendrag af systemdokumentationen, dens opbygning og sammenhæng. Generelt er kapitlet fyldestgørende som oversigtsdokument. Baggrunden for Nyt BBRløsningen kunne godt belyses mere udfoldet ligesom der i afsnit 1.1 er henvisninger til ordlister og snitflader, der ikke er adgang til (links) eller yderligere referencer til. Velskrevet dokument. Der savnes dog en læsevejledning og evt. en grafisk oversigt over dokumentationen. Kapitlet vurderes til i store træk at være retvisende, dog med skønhedsfejl (forkert overskrift) og referencer til utilgængelige ressourcer. Overblikskapitlet giver en god introduktion til dokumentationen og bidrager trods enkelte fejl og mangler til en eventuel overdragelse. Dokumentet kunne med fordel have en decideret læse-vejledning, der i forhold til de nævnt målgrupper udpegede relevante områder. Dette kunne evt. støtte sig op ad en (grafisk) oversigt over løsningsdokumentationen, der kunne styrke overblikket af dokumentationen. 3.2 Kontrakt KMD-BBR samt bilag (bilag 1-13) Kontrakten samt bilag dækker paralleldrift af det gamle BBR i en overgangsfase. Leverandøren (KMD) bekræfter, at overgangsfasen er afsluttet, og kontrakten og bilag har derfor alene historisk interesse. Der er derfor ikke foretaget vurdering af dette materiale i forhold til overdragelse. Materialet kan evt. fortsat indgå i dokumentationspakken, men nok alene med det formål at forankre et forløb til generel information for eftertiden. - Ikke relevant. 4

3.3 Leverance-kontrakt Nyt BBR samt bilag 1-22 (pånær bilag 2 kravspecifikation) Leverancekontrakten er en modificeret K01 kontrakt, med en lang række supplerende bilag, hvoraf 8 bilag dog er udgået). Materialet vurderes til i høj grad at være fyldestgørende, dog med enkelte skønhedsfejl (se nedenfor). Kontrakt-sproget er enkelt og direkte, hvilket bidrager til at øge den generelle forståelighed af dokumentet. Materialet vurderes til i høj grad at være retvisende. Der er visse konflikter i de generelle forretningsbestemmelser i forhold til de specifikke aftaler på den pågældende løsning. F.eks. 2 Rettigheder i de generelle betingelser fraskrives i Nyt BBR bilag 14. KMD NemAdgang konceptet baserer sig på OCES, net-id og/eller Fælles pin-kode. NemID har idag erstattet disse identifikationsmekanismer og den nye medarbejder-signatur er under udrulning. I kontrakten lægges der vægt på sikring af kvaliteten af dokumentationen (punkt ), herunder ændringshåndtering. Dette trækker op på understøttelsen af overdragelse. Leverandøren (KMD) har i review-interview bekræftet at løsningens anvendelse af KMDs NemAdgang login er udfaset og derfor uaktuel. Bindingen ville ellers repræsentere en både teknisk og kontraktmæssig hård binding, der ville besværliggøre overdrageligheden. (Bilag 14c1) De i bilag 14 omtalte special udviklet programmel også omfatter opsætningsscripts, test-scripts etc., kan være vigtige at have til at understøtte etableringen af udvikling-, afviklings- og test-miljø i en overdragelsessituation. Derfor foreslås en indsats for at

samle disse scripts, vejledninger (og evt. udarbejde de manglende) til at kvalitetssikre og understøtte denne proces. Kravene til anvendelse af åbne standarder og fælles-offentlige arkitektur-principper, har siden denne kontrakts indgåelse flyttet sig en del ud over snitflader beskrevet med OIOXML (F.eks. snitflader rettet mod integration og udveksling med FESD-løsninger. Således bør Nyt BBR med udgangspunkt i Leverance-kontrakten (især bilag 2 - Kravspecifikation) forholde sig eksplicit til Digitaliseringsstyrelsens opstilling af 7 sæt af obligatoriske åbne standarder. Se bilaget [Åbne Standarder i Offentlige it-systemer]

Kapitel 12 samler alle ændringer til de øvrige dokumenter i ét dokument, der fungerer som en samlet historik over dokumentationen. Dokumentet giver således en god sporbarhed og vidner om en gennemgående kvalitetssikring af dokumentationen. Dokumentet bidrager dog kun i begrænset omfang til den samlede løsnings overdragbarhed. Dokumentet fremstår struktureret og fyldestgørende, idet alle væsentlige ændringer til dokumentationen er opsummeret i kapitlet. 3 Dokumentet har præg af at være forfattet af mange forskellige personer/roller med forskelligt sigte og behov - derfor lider forståeligheden lidt. Dokumentet kunne med fordel og med et bedre udbytte for læsere være blevet udsat for en redaktion med ensretning. Alle ændringer er beskrevet i tekst hvilket i nogle tilfælde gør visse afsnit unødigt komplicerede. Det havde f.eks. været enklere i ændringskapitlet 12.4 om brugerdialog at lade skærmbilleder illustrere ændringerne. Versioneringen for de enkelte dele af Nyt BBR ser ikke ud til at være synkroniserede. Det havde bidraget væsentligt til overskueligheden, hvis der havde været en oversigt over Nyt BBRs komponenter, deres revisionsnummer og historik. Der er blevet foretaget i alt 10 stikprøver i ændringsdokumentationen for at efterprøve korrektheden. Stikprøverne er taget i et bredt ud over systemdokumentationen og ingen af de 10 prøver har vist væsentlige afvigelser fra det opgivne. Kun én stikprøve har vist en afvigelse i forhold til afsnitsnummerering. 3 En del af ændringshistorikken er uaktuel og bidrager i en eksternt rettet anvendelseskontekst ikke væsentligt til overdragbarheden. Dette dokument i sig selv bidrager kun i begrænset omfang til overdrageligheden af løsningen og dokumentationen. Dokumentet 7

kunne med fordel udarbejdes i en ekstern rettet udgave i form af en decideret change log. Det vil klart styrke overdrageligheden, hvis det nuværende meget detaljerede, internt orienterede ændringsdokument blev omarbejdet til et eksternt orienteret revisionsdokument. Dokumentet kunne med fordel baselines således at det kun indeholdt de væsentligste ændringer for de sidste 3-4 versioner og at historikken blev vendt om i forhold til det nuværende, således at change loggen fulgte Nyt BBR løsningens versionering og angav de nyeste versioner først. Det vurderes at dette produkt kunne frembringes med en mindre indsats ved at redigere det foreliggende dokument - Kapitel 12 Ændringer. 8

4. Underområde: Krav 4.1 Kapitel 11 - Overensstemmelsesmatrix krav systembeskrivelse Dokumentet beskriver og opstiller kravspecifikationens funktionelle og nonfunktionelle krav og deres opfyldelse i forhold til systembeskrivelsen. Hvert krav er henvist til specifikke kapitler i systembeskrivelsen. Fin overensstemmelsesmatrix. Dokumentet virker gennemarbejdet. Dokumentet er velstruktureret og har en høj grad af forståelighed. Dokumentet matcher kravsbesvarelsen (bilag 2) alle steder der er foretaget stikprøvekontroller. - Til krav 7.13 nævnes det i kommentaren, at der skal foretages en afklaring (i forhold til kobling til Skattemappen). Det fremgår ikke om denne afklaring er foretaget. - På enkelte af tillægskravene (side 37 og frem) er der ikke angivet eksplicit kilde til yderligere information om kravene, og der må derfor forventes en ukendt indsats fra en ny leverandør til at matche krav og specifikation for disse indgange. Indsæt en læsevejledning. 4.2 Leverance-kontrakt Bilag 2 - Kravspecifikation Dette dokument er BBR-løsningens kravspecifikation. Dokumentet er ganske vist historisk og skal/bør ikke opdateres. Men dokumentet er centralt i et overdragelsesscenarie, da det er en væsentlig kilde for en evt. ny leverandør (og udvikler) til at forstå domæneløsningen, BBR-løsningens scope og omfang. Kravspecifikationen dækker de relevante områder, dog savnes der krav vedr. test (herunder performancetest og stresstest). 9

7 Det er en yderst velstruktureret og forståelig kravspecifikation. Bilaget er primært reviewet i forhold til overdragelighed, med fokus på om der er stillet krav, der låser leverandøren til en bestemt løsningsmodel eller teknologi (også set i lyset af at dokumentet er udarbejdet i 200, og der er sket en vis teknologisk udvikling i mellemtiden). Der er ikke fundet uoverensstemmelser mellem kravspecifikation og den øvriger dokumentation, herunder brugervejledningerne. Dette bilag er af høj vigtighed for en ny leverandør, da det indeholder store mængder (detail)specifikationer af forretningsregler og klassifikationer af feltværdier. Selvom dokumentet også beskæftiger sig med overgangen fra det gamle BBR til det nye BBR er der megen relevant viden indlejret i teksten. Der er meget få issues omkring overdragelighed, idet der er få bindinger og referencer til gamle og proprietære teknologier. I sagens natur kan en kravspecifikation ikke opdateres, men i forbindelse med et evt. nyt udbud af Nyt BBR og eventuelt nye og opdaterede krav vil det være en stor fordel om der blev taget aktivt stilling til Digitaliseringsstyrelsens opstilling af 7 sæt af obligatoriske åbne standarder. 10

. Review af dokumentation: Arkitektur og Design.1 Kapitel 2 - Systemarkitektur Systemarkitekturen for BBR-løsningen er ikke kompliceret og læner sig i væsentlig grad op af det framework, der er valgt til løsningen (.NET). Dokumentationen her beskriver i kort form den overliggende arkitektur og det high-level design, som Nyt BBR baserer sig på. Kapitlet gennemgår systemarkitekturen, primært på overordnet plan. Umiddelbart virker en arkitekturbeskrivelse på 7 sider incl. figurer meget kortfattet til et system af dette omfang, men da arkitekturen læner sig kraftigt op af eksisterende arkitekturer og der ikke er noteret væsentlige afvigelser fra dette designvalg, vurderes omfanget at være passende (dog i den lave ende). Kapitlet er opdelt i to sektioner; dels en overordnet gennemgang af arkitektur- og designvalg, dels en teknisk beskrivelse af enkeltelementer i præsentationsserveren. Denne sammenblanding trækker ned i den samlede forståelighed. Det vurderes at der er høj grad af overensstemmelse mellem den endelige systemarkitektur og den beskrevne systemarkitektur. I forhold til overdragelighed af systemet giver kapitlet anledning til overvejelse omkring hvorvidt teknologivalget er fremtidssikkert, idet der refereres til servere og værktøjer med en del år på bagen (IIS.0,.NET 3.0, Windows Server 2003 R2, Microsoft SQL Server 200, m.v.). Der savnes en beskrivelse af hvor arkitektur og design fraviger de frameworks, der henvises til, alternativt en eksplicit note om at der ikke er foretaget modifikationer. 11

. Review af dokumentation: Systemdokumentation.1 Kapitel 3 - Forretningslogik Bemærk at kapitel 3 refererer til bilag på i alt 107 sider. Bilagene og kapitlet er her reviewet under ét. Ønskes yderligere detaljer henvises til det fulde review, hvor bilag hhv. kapitlet er reviewet hver for sig. Kapitel 3 incl. bilag vurderes at være fyldestgørende i forhold til emnet Forretningslogik. Domænemodel, Service Interface Lag, valideringer samt forretningsregler beskrives i selve kapitlet, og bilagene indeholder en stor del af de nødvendige data. Der er dog huller (se Overdragelse nedenfor). 4 Der savnes sammenhæng og referencer på tværs mellem kapitel og bilag. Læseren er nødt til at have det meste af materialet foran sig for at kunne finde rundt i det. Der er foretaget stikprøver imellem de enkelte elementer i dokumentationen, og disse viser en korrekt sammenhæng. 4 Det er risikabelt med ikke eksplicit dokumenterede variabelnavne og konstanter - selv meget nærliggende tolkninger af gode navne som f.eks. Byggesag:Påbegyndelsesdato kan tolkes forskelligt (påbegyndelse af selve sagen eller påbegyndelse af byggeriet?). Viden om dette og lignende må formodes at ligge hos den enkelte udvikler, hvilket kan medføre en ukendt omkostning i form af opsamling af denne viden hos en ny leverandør. Det fremgår ikke eksplicit om forretningsregler er delvist implementeret i præsentationslaget - hvis dette er tilfældet, kan der ligge en stor omkostning skjult ved et senere teknologiskift. Referencer mellem bilag og kapitler, så læseren hjælpes til at søge information det korrekte sted. 12

Opsætning og formattering af teksten bidrager ikke tilstrækkeligt med overblik, og det vil hjælpe meget med visuel indikation af kontekstskift (f.eks. ved skift til dokumentation af næste entitet i listen). Sikring af at alle datasæt og betydninger dokumenteres (f.eks. hvad de enkelte værdier for SagsType betyder - og hvad er udfaldsrummet)..2 Kapitel 4 - Brugerdialog samt bilag Kapitel 4 samt tilhørende bilag indeholder en teknisk gennemgang af brugerdialog, med fokus på de tekniske aspekter og administration af skærmbilleder. 7 Kapitlet samt bilag vurderes at være fuldt fyldestgørende i forhold til det angivne formål. Materialeter velstruktureret og meget forståeligt, og indeholder og introducerer en del domæne- og forretningsforståelse og fungerer dermed også som overordnet introduktion og overbliksskabende dokument. Det beskrevne lægger sig meget tæt op af kravspecifikationen. Det vurderes at kapitlet bidrager betydeligt med indblik og overblik til brug ved en eventuel overdragelse. Der kunne med fordel udarbejdes en læsevejledning til kapitlet samt tilhørende bilag. F.eks. med en opdeling af brugerdialogen rettet mod forretnings- eller domæne-brugere og bruger- og BBR-administratorer..3 Kapitel - Udskrifter til borgerne Kapitel gennemgår de tre typer af borgervendte meddelelser, der kan udskrives fra Nyt BBR. Gennemgangen er målrettet interne udviklere, samt systemejer og leverandør, og opbygning og administrationsmuligheder er dokumenteret. Dokumentet beskriver på et passende niveau udskrifter til borgerne, og vurderes til i høj grad at være fyldestgørende. 13

Dokumentet er velskrevet, og læsevenligheden løftes i høj grad af en god læsevejledning i første afsnit. Beskrivelsen af udprint ligger tæt op af kravspecifikationen. Der er ikke foretaget stikprøvekontrol i forhold til det faktiske programmel. 4 Der er i dokumentet beskrevet en række forhold, der vurderes at være meget KMDspecifikke (herunder brug af et værktøj til udprint). Der bør udarbejdes en beskrivelse af hvordan kommune-specifikke bilag (afsnit 1.4.3.3) frembringes og lægges ind i løsningen..4 Kapitel - Dataudveksling Kapitel indeholder snitfladebeskrivelser til integrationen mellem Nyt BBR og en lang række omkringliggende it-systemer (+10). Beskrivelserne er holdt på et overordnet niveau, og en udvikler vil med udgangspunkt i kapitel og de relevante WSDL-filer hurtigt kunne danne sig et overblik over integrationen, både i forhold til formål, praktiske vilkår og konkret teknisk implementering. 4 Det vurderes at emnet Dataudveksling (læs: integration til eksterne systemer) er fuldt dækket af beskrivelserne i kapitel, når der samtidig haves adgang til de relevante WSDLfiler. Dog fremstår nogle af nogle af integrationsbeskrivelserne lidt for overordnede. Kapitlet er velstruktureret og sammenhængende, og er holdt i et passende niveau til målgruppen. Der er foretaget stikprøver, der bekræfter kapitlets retvisenhed. Der er kun enkelte afklaringspunkter i dokumentationen, der hindrer eller kunne besvær- 14

liggøre en overdragelse. Disse afklaringspunkter er blevet afklaret i de kvalitative interviews og bilaterale afklaringer. Se bilag [Kvalitativt Interview KMD] Der er tre punkter, hvor der i selve kapitlet nævnes behov for en afklaring - disse bør afklares og kapitlet opdateres med den relevante information. Enkelte af integrationsbeskrivelserne virker lidt for overordnede. Til alle integrationer, hvor BBR tilgår en anden parts service, vil det være en væsentlig støtte for sikring af integrationen og videreudviklingen, at der etableres en reference til en snitfladebeskrivelse af den service, som Nyt BBR tilgår. Det kvalitative interview med leverandøren har afklaret at en række afklaringer allerede er sket og en række af snitflade-beskrivelserne vil blive ajourført samtidig med releasen af BBR 1. i efteråret 2014.. Bilag til kapitel : Energidata ind i BBR Dette bilag udvider snitfladebeskrivelserne i kapitel med en senere tilkommen snitflade, som BBR udstiller til brug for energiselskabers automatiske indberetning af energiforbrug til BBR. Bilaget indeholder både indadvendte og udadvendte afsnit, idet der dokumenteres både ekstern snitflade, use-cases og intern opbygning af servicen. Dokumentet gennemgår alle relevante aspekter ved den tilføjede service. Dokumentet er velstruktureret og giver en god indføring i både arkitektur, design og snitflade. Det trækker en smule ned i forståeligheden at der ikke er skelnet mellem interne og eksterne udviklere, og en ekstern udvikler vil derfor skulle forholde sig til informationer, der ikke er relevante. Der er taget stikprøver i forhold til kildekoden, og beskrivelserne i kapitlet svarer til kildekode, WSDL og tilhørende XSD er. Dokumentet er et værdifuldt element i dokumentationspakken, og vil fremme en eventuel overdragelse. Der er nogle få, ikke så alvorlige mangler (se Forslag til rework nedenfor). 1

Det vil bidrage væsentligt til en entydig forståelse af figurer, at der indsættes en signaturforklaring, alternativt at der blev anvendt et helt ensartet, centralt defineret sæt af symboler. I usecase 03 (Behandl indberetninger) normalforløb på side 1 beskrives en oprettelse af Behandlingsfejl. Håndtering af disse (forventelige) fejl er ikke beskrevet andetsteds, og burde evt. give anledning til en under-use case.. Kapitel 7 - Datamodel Datamodellen er dokumenteret dels i kapitel 7, dels i en autogenereret table report, der er vedlagt kapitlet. Der er en række indbyrdes uoverensstemmelser mellem de to opsummeringer af datamodellen, og det vurderes at der er et stort behov for at få defineret entydigt hvilken af de to opsummeringer der tager præcedens ved uoverensstemmelser, og i det hele taget at få konsekvensrettet bilag og kapitel, så der ikke er tvivl om den faktiske datamodel. Trods uoverensstemmelser de to dokumenter imellem vurderes det, at de tilsammen udgør en fyldestgørende gennemgang af datamodellen. Valget af metode til gennemgang af entiteterne giver et godt overblik over datamodellen. Det trækker ned i vurderingen af forståelighed at læseren pga. de ovennævnte uoverensstemmelser er nødt til at læse hele materialet igennem og evt. slå op i kildekode for at afgøre hvilken beskrivelse der er mest korrekt. 4 Feltkommentarerne i Table Report og i opsummeringerne i selve kapitel 7 er ikke indbyrdes koordinerede, og der er derfor risiko for dels uoverensstemmelser i beskrivelserne, dels dobbeltarbejde og ekstra behov for konsekvensrettelser ved justeringer af datamodellen. En stikprøvekontrol giver indtryk af at det er nødvendigt at læse begge sæt af informationer for at få det fulde billede (f.eks. for felterne BYG.21, BYG.37, BYG.4 og BYG.49), og samtidig at der er forskelle i nuancerne af beskrivelserne. 1

Dokumenterne i deres nuværende form giver trods fejl og mangler et godt udgangspunkt for en eventuel overdragelse, herunder introduktion til en ny udvikler på projektet. Det vurderes, at konsekvensrettelser af de to dokumenter vil tilføre dokumentationspakken meget stor værdi, idet de to dokumenter dermed vil fungere som forankringspunkt for viden om datamodellen og betydningen af felter og klassifikationer. Der er et stort behov for sikring af konsistens mellem de to dokumenter, både i forhold til hvad der står hvor, og at informationer der står begge steder er i indbyrdes overensstemmelse. I kapitlet er der flere figurer dateret langt tilbage i tid (f.eks. er den logiske database dateret 2012-01-09 på figur 7.1, og den fysiske database er dateret 2008-09-19 på figur 7.2). Det bør fremgå tydeligt at der ikke er sket ændringer siden. Alternativt skal figurerne opdateres. Det sidste afsnit ( Denormalisering ) bærer præg af at være kopieret direkte fra tilbudsmaterialet. Det vil fremme forståelsen hvis dette afsnit bliver opdateret, således at det afspejler den aktuelle tilstand af datamodellen. Sprogligt og typografisk set vil både kapitlet og bilaget med fordel løftes, så teksten bedre understøtter læserens forståelse. Der henvises til reviewet af kapitel 7 samt bilag for yderligere informationer og eksempler på steder, der bør tages hånd om..7 Kapitel 8 - Administrationsdatabase Dokumentet gennemgår kort og præcist anvendelsen af Nyt BBRs administrationsdatabase. I kapitlet beskrives den model, der er valgt til at håndtere behovet for styring af metadata, herunder tooltips og koblingen mellem fysiske og logiske felter. Formålet er at gøre det muligt at tilpasse løsningen til de enkelte kommuners behov uden at skulle ændre i grundlæggende elementer som datamodel og funktionalitet. Dokumentet gennemgår kort og præcist modellen bag og anvendelsen af Nyt BBRs administrationsdatabase. 17

Dokumentet fremstår sprogligt enkelt og forståeligt. Dokumentet vurderes at være retvisende. Dokumentet giver et fornuftigt indblik i løsningens administrationskoncept og bistår dermed overordnet i at sikre overdrageligheden af løsningen. Dog udtrykker dokumentet også Nyt BBRs dybe integration med Microsoft-platformen til især logning i løsningen, hvilket kan være en barriere i forhold til en evt. ny leverandør, der måske vælger at basere sin log- og sikkerhedsovervågning på en anden platform eller efter et andet koncept. Der er alene behov for en redigering af pdf-filen, idet kapitlet gentages (2x sider), så forvirring ikke opstår og eventuelle henvisninger til kapitlet bliver præcise og entydige. Bemærk i forhold til overdragelse at den dybe integration med Microsoft-platformen kan give anledning til udfordringer ved et eventuelt leverandørskift (om ikke andet så en binding til Microsoft eller alternativt en ekstraomkostning forbundet med et skift til andet softwareprodukt)..8 Kapitel 9 - Sikkerhed I kapitel 9 beskrives hvordan autentifikation hhv. autorisation håndteres i Nyt BBR, i henhold til DS484. I kapitlet gennemgås begreber, datamodel, administration og rolleprofiler. Beskrivelsen er god, dog hindres forståelsen lidt af spring mellem helt overordnede beskrivelser og tekniske gennemgange af f.eks. tredjepartsbiblioteker. Dokumentet beskriver i passende detaljeringsgrad hvordan sikkerhed (autentifikation og autorisation) håndteres i Nyt BBR. Dokumentet gennemgår de relevante aspekter, men er dog præget af forstyrrende skift i detaljeringsniveauer mellem overordnede beskrivelser og tekniske gennemgange af komponenter. 2 Det vurderes udfra kodereviewet at dokumen- 18

tet på nogen områder kun i begrænset grad er retvisende. Se Indstillinger til rework nedenfor. Dokumentationen foreskriver at designet kræver brug af Microsoft Enterprise Library for.net 2.0. Denne version er Retired (nuværende version.0 er fra 2013) og vedligeholdes ikke længere af Microsoft. Det kvalificerende interview med leverandøren (KMD) har afdækket at den nuværende version af kildekoden bygger på Enterprise Library.0 (som stadig supporteres af Microsoft). Dokumentet vurderes derudover at have en relativt høj grad af overdragelighed. Indstillinger til rework Under reviewet af kildekoden er det blevet bemærket, at den validering der foretages af certifikater bør undergå en mere detaljeret analyse. Især i forhold til hvordan det bliver valideret, at de certifikater, som løsningens klienter anvender, rent faktisk er OCEScertifikater. Overvej evt. at holde dokumentet på højniveauform, og skille kodeeksemplet ud eller helt udelade det (kunne evt. indgå direkte i kodedokumentationen i stedet). Der kunne tilføjes eksempler på admin. vedligehold af roller og rettigheder. Også dette kapitel er dubleret, dvs. samme tekst forekommer to gange (2x33 sider). Der refereres til TDC s revocationlist (burde være enten OCES-operatørens eller Nets-DanId s )..9 Kapitel 10 - Rapporter (Systembeskrivelse) Kapitel 10 beskriver de rapporter, der er tilgængelige gennem Nyt BBR. Systemet er opbygget, således at der er faste rapporter, brugertilpassede rapporter og administrative rapporter. I kapitlet gennemgås de faste og administrative rapporter, og det beskrives hvordan tilpassede rapporter oprettes og håndteres. Dokumentationen er velstruktureret og dækker området i passende omfang. Kapitlet er skrevet i et enkelt og forståeligt sprog med en god opbygning. Det vurderes at dokumentet beskriver den 19

valgte løsning godt. Den valgte teknologi (Reporting services) er en MS specifik ting med stærke platformsbindinger på både klient- og server-del (Windows,.NET etc.). Det bør afklares i hvilket omfang teknologivalget binder løsningen til den angivne platform (både klient og server) - og om bindingerne er afgrænset til reporter, eller om der er afledte bindinger..10 Vejledning til snitfladen: AddressGeometryService Dokumentet beskriver en ekstern snitflade, hvorigennem kommunerne kan fremsøge og ajourføre adgangsadressernes geometri (adressekoordinater) i NYT BBR. Målgruppen er kommunerne og deres koordinatleverandør(er) (interne som eksterne), der varetager registrering og vedligeholdelse af adressekoordinater i NYT BBR. Det vurderes, at dokumentet i høj grad er fyldestgørende, og at alle nødvendige områder er belyst i tilstrækkeligt omfang til at en ekstern udvikler kan anvende snitfladen. Dokumentet er disponeret og skrevet så det fremmer forståelsen af både snitflade og anvendelse af denne. Der savnes dog en henvisning til digitaliser.dk for specifikation af de felter, der har tilknyttet en klassifikation (f.eks. AddressCoordinateQualityClassCode). I dokumentet henvises til et website for yderligere dokumentation; dette kan dog ikke afprøves, da sitet er adgangsbeskyttet. Der henvises til et andet site for demo af servicen, og her er der dokumentation tilgængelig. Dokumentet indeholder nogle få forstyrrende småfejl, f.eks. i navne på felter (StreetBuidlingIdentifier i stedet for StreetBuildingIdentifier). Det vurderes at dokumentet har en meget høj grad af overdragelighed, og at der gives ind- 20

blik af værdi både for en ekstern udvikler (der skal bruge snitfladen fra eksterne systemer) og nye udviklere på BBR projektet. De konstaterede (små)fejl og mangler giver ikke anledning til forslag til rework. 21

7. Review af dokumentation: Brugerdokumentation 7.1 Brugerdokumentation (pakke med 8 dokumenter) De 8 brugerrettede dokumenter er frembragt med udgangspunkt i en fælles skabelon, og er her reviewet som en samlet pakke. Det er følgende dokumenter, der dækkes i reviewet af brugerdokumentationen: Adresser BOB Brugeradministration Generelt Inddataboks Meddelelse Rapporter Systemadministration Dokumenterne er generelt af meget høj kvalitet, og vurderes at yde væsentlig støtte til brugernes anvendelse og forståelse af Nyt BBR. 7 De udarbejdede brugerrettede dokumenter vurderes til at være i høj grad fyldestgørende og til at dække brugernes behov. Bemærk dog at der ikke er foretaget interviews med brugere i forhold til om der savnes yderligere dokumentation. 7 Brugerdokumentationen rummer en stor domæne-viden og formidler denne sammen med anvendelsen af Nyt BBR-systemet. Sproget er direkte henvendt til brugeren i alle dokumenter, instruerende og rigt illustreret med skærmbilleder. 7 Det vurderes at dokumenterne har meget høj grad af intern konsistens, i den forstand at tekstuel vejledning og skærmbilleder stemmer indbyrdes tæt overens. Dokumenterne bistår både enkeltvis og sammen til at lette en overdragelighed af løsningen, da de dels formidler en betydelig 22

domæne-viden og forståelse og dels har struktureret denne viden indenfor en række centrale kategorier (inddata, rapporter, etc.) Baggrundsafsnittene (i nogle kaldet Forord e.lign.) i Brugerdokumentationen (alle dokumenter) bør valideres af en domæneekspert med henblik på om henvisninger til regler, bekendtgørelser, cirkulærer, etc. for ejendomsområdet er opdaterede og korrekte. Man kunne overveje at dele den bruger-rettede dokumentation op i en decideret system-hjælp, der alene dokumenterer og bistår brugeren i den rent anvendelsesmæssige del af Nyt BBR og en super-bruger henvendt dokumentation, der rummer mere baggrunds- og domæne-dokumentation. Det ville dels gøre dokumentationens omfang mere overskuelig og måske enklere at anvende. 23

8. Review af dokumentation: Udviklerdokumentation 8.1 Kildekode i Visual Studio Solutions med et (større) antal underprojekter. Enkelte udviklerrettede afsnit i systemdokumentationen. Dokumentationen der retter sig mod udvikleren og udviklingsmiljøet alene er yderst begrænset. Kildekoden kræver et større arbejde og en stor forhåndsforståelse for domænet at overskue og kunne videreudvikle på som basis. 1 Dokumentationen omkring kildekoden og den udviklerettede dokumentation er mangelfuld og i den afleverede udgave ikke fyldestgørende til at understøtte en effektiv overdragelse. Kan ikke vurderes (se ovenstående) Kan ikke vurderes (se ovenstående) 2 Kildekoden er velstruktureret, generelt letlæselig og i en overdragbar form (Visual Studio Solutions), men den støttende dokumentation er ikke fyldestgørende til at understøtte en effektiv overdragelse. Indstillinger til rework Review-teamet indstiller, at udviklerdokumentationen på væsentlige punkter forbedres for at understøtte en evt. overdragelse til anden udviklingsleverandør samt sikre videreudviklingen af Nyt BBR. Review-teamet har foreslået en brutto-liste af støttedokumenter, som baseret på erfaring og best-practices på området er centrale for en sikker og kvalitetssikret overlevering: Generelt overbliksdokument over kildekoden Byggevejledning(er) Vejledning til opsætning af udviklingsmiljø Vejledninger til diverse kommandolinje-scripts (som indgår i kildekoden) Guide til videreudvikling Oversigt over kendte fejl og mangler De kvalitative interviews med den nuværende leverandør samt supplerende dokumentation, der er tilkommet under review-processen, viser, at kompetencesættet omkring udvikling og deployment er intakt hos leverandøren og dermed at sikringen af den 24

nødvendige udviklerrettede dokumentation til Nyt BBR kan (gen)etableres. Interviewet har også afdækket at det nøje bør afklares hvilke af ovenstående indstillinger, der vil kaste størst reel værdi af sig i forhold til en evt. ny udviklingsleverandør og hvilke der er specifikke i forhold til det lokale udviklingsmiljø. Ingen. 2

9. Review af dokumentation: Test og performance Der foreligger en række dokumenter, der beskriver del de test, der er foretaget i forbindelse med overdragelsen af BBR-løsningen i forbindelse med idriftsættelsen men reviewet har også omfattet relevante rapporter fra løbende load-tests. 9.1 Resultat af overtagelsesprøve februar 2012 samt bilag Dokumentationen for overtagelsesprøven (test-drejebog, referat af test, test-rapporter etc.) tegner et billede af en tilrettelagt og metodisk overdragelse. Overtagelsesprøven dækker det angivne formål, og er veldokumenteret. 7 Dokumentet er velstruktureret og meget velskrevet. 7 Det vurderes, at dokumentet i meget høj grad er retvisende. Dokumentationen bidrager kun begrænset til overdrageligheden, men giver dog et væsentligt indblik i løsningens test-coverage. Dokumentet giver ikke anledning til forslag til justeringer. 9.2 Loadtest februar 2012 Der er udført en loadtest med det formål at Via loadtest sikre, at BBR-systemet performer optimalt, med målet at sikre at en ny release af BBR har acceptable svartider for forretningsprocesser, der belaster systemet. Desuden skal det sikres, at systemet ikke giver memoryleaks. 4 Det vurderes, at testrapporten kun i begrænset omfang opfylder det erklærede formål. Det vurderes endvidere, at loadtesten i til en grad sandsynliggør, at der ikke forekommer memoryleaks, dog er testen udført under vilkår (på en udviklermaskine i en konfiguration der er væsensforskellig fra produktionsmiljøet, og uden sikring af at forstyrrende processer er 2

stoppet på maskinen på forhånd), der kun i meget begrænset omfang kan give anledning til væsentlige konklusioner for BBR i produktionsmiljøet. Testrapporten er velstruktureret og skrevet i et letforståeligt sprog. Det vurderes, at de præsenterede resultater er retvisende, idet der ikke er er tegn på nogen form for datamanipulation. Det trækker ned i vurderingen at testen er foretaget på en maskine, hvor der undervejs i testforløbet - men uafhængigt af testen - eksekveres en cpu- og hukommelseskrævende proces (backup). 4 Loadtesten bidrager kun i begrænset omfang til overdragelighed af Nyt BBR, idet testen kun delvist opfylder det erklærede formål. Der bør gennemføres forskellige typer performancetest, hvor relevante egenskaber af Nyt BBR afdækkes og eventuelle fejl og mangler identificeres. Der kan med fordel søges inspiration i eksisterende litteratur i forhold til hvordan testforløb specificeres, eksekveres og afrapporteres. 27

10. Review af dokumentation: Driftsdokumentation 10.1 Driftskontrakt samt bilag (pånær bilag 3 Driftshåndbog) Driftskontrakten består af et hoveddokument samt en række bilag (18 i alt), og tilsammen beskrives væsentlige områder omkring drift af Nyt BBR, herunder procedurer, aftaler, priser, servicemål, samarbejdsorganisation m.v. Materialet er generelt af meget høj kvalitet, og størstedelen af materialet har ikke givet anledning til reviewkommentarer. 7 Kontrakt og bilag udgør tilsammen en yderst fyldestgørende opsamling af information, krav og vilkår omkring driften af Nyt BBR. Materialet er af høj kvalitet og er - målgruppen taget i betragtning - letforståeligt. Materialet vurderes til i høj grad at være retvisende, dog er der enkelte områder, hvor der er sket udvikling siden udarbejdelsen af materialet (f.eks. Bilag 2, vedr. brugerautentifikation). Materialet som sådan bidrager i høj grad til en eventuel overdragelse. Der er dog beskrevet design- og teknologivalg, der potentielt kan stå i vejen for en overdragelse (f.eks. anvendelse af KMD s inderste sikkerhedszone, og manglende specifikation af protokol for interne services ). Der udestår angivelse af testmiljøer og vilkår/specifikation for disse. Specifikation af protokol for interne services, samt beskrivelse af hvad det indebærer at anvende KMD s inderste sikkerhedszone. 10.2 Driftshåndbogen Generelt rigtig god driftshåndbog som dækker de mest relevante områder. Der savnes dog opdateringer, idet dokumentet og samtlige bilag er dateret 2009 og ikke opdateret siden. Der har siden idriftsættelsen været ugentlige møder mellem leverandøren og KOMBIT, hvorfor der ikke har været fokus på opdatering af driftshåndbogen. 28

Dokumentet og dets bilag fremstår med velvalgt fokus og god dækning af emnet, men virker ikke opdateret. 7 Driftshåndbogen har en meget høj kvalitet og er nem umiddelbart at forstå. Der forudsættes dog kendskab til ITIL (hvilket er ganske rimeligt målgruppen taget i betragtning). 2 Ændringsloggen stemmer ikke overens med dokumentets versionering (1.0). Det sammen med dokumentets ikke helt ajourførte status gør, at man kommer i tvivl om hvor retvisende driftshåndbogen reelt er. Driftshåndbogen har været erstattet af hyppige statusmøder på ugebasis mellem kunden (KOMBIT) og leverandør (KMD) Overordnet klar til overdragelse, men med den kommentar at det kan blive endnu bedre i en opdateret udgave, indeholdende opdaterede processer og procedure. Driftshåndbogen bør opdateres til de aktuelle forhold, og figurtegninger bør opdateres eller kommenteres (så det fremgår eksplicit at der ikke er sket ændringer hvis dateringen af figurerne ligger langt tilbage i forhold til dokumentets overordnede datering). Dokumentet tager udgangspunkt i ITIL processer, og det vil fremme overdrageligheden hvis der blev tilføjet en mere struktureret beskrivelse af hvilke processer og procedurer der anvendes, og hvilke der er fravalgt. Der savnes mere detaljerede procedurebeskrivelser for alle områder, eller specifikke henvisninger til hvor sådanne er placeret, hvis de allerede eksisterer. ITIL processerne Major incident og Change management er beskrevet meget kortfattet. Til at understøtte en evt. overdragelse til anden leverandør bør dette være mere præcist beskrevet, evt. blot med en præcis reference til ekstern beskrivelse af processerne. Der mangler beskrivelse af eskalations- og informationsprocesser samt tilhørende procedurer. KOMBITs krav til sikkerhedspolitikker er indarbejdet med KMD efter de standarder man arbejdede med i 200-2009 (DS484). En opdateret driftshåndbog må forventes at rette sig mod ISO-27001 eller ISO-27002. 10.3 Installationsvejledning for NYT BBR Applikationsserver 29

Installationsvejledningen indeholder en overbliksbeskrivelse af applikationsserveren samt vejledning til installation i form af trinvise gennemgange af processen. Notatet er fra 2008. 4 Vejledningen er meget kortfattet, og testen af om installationen er vellykket består alene i en konstatering af at servicen kører og at der ikke er fejl i logs. Den meget kortfattede form kan give anledning til en række praktiske og tekniske spørgsmål, der ikke findes svar til i vejledningen. Figurtekst til figur 1 er ikke læsbar, og da man ikke kan kopiere fra dokumentet kan det ikke afgøres hvad der står i kasserne. Overordnet set vurderes vejledningen at være retvisende. Det trækker ned at dokumentet ikke er opdateret siden 2008 - og at der er indlejret ubesvarede spørgsmål i teksten (Afsnit 4.3 refererer til to eksterne services med følgeteksten Er ikke taget i anvendelse endnu!!! - dette er ikke i overensstemmelse med kapitel (Dataudveksling), figur i afsnit 1.1). 4 Den kortfattede form samt fravær af fejlscenarier og udbedringsforslag er en hindrende faktor i forhold til en evt. overdragelse til en ny leverandør. Det vurderes at der forudsættes tavs viden hos udførende part eller adgang til kolleger med kendskab til servicen. Test af korrekt installation består alene i at konstatere at servicen kører, og at der ikke er fejl i log og eventlog. En opsamling af kendte fejlscenarier (f.eks. ved opdateringer) ville hjælpe meget på overdrageligheden (og generelt driften af servicen). Vejledningen bør ajourføres til nuværende tilstand, både hvad angår installation på aktuelle miljøer og konsistenstjek i forhold til brug af CPR-services (se ovenfor). 10.4 Installationsvejledning for NYT BBR Webserver Kortfattet installationsvejledning til Nyt BBR Webserver, med fokus på overblik og med trinvise beskrivelser. Notatet er fra 2007. 30

4 Vejledningen er meget kortfattet, og testen af om installationen er vellykket består alene i en konstatering af at servicen kører og at der ikke er fejl i logs. Samme problematik som beskrevet ovenfor vedr. installationsvejledningen til Applikationsserveren. Vejledningen vurderes at være retvisende. Dog trækker det ned, at den øjensynlig ikke er opdateret siden 2007. 4 Der er enkelte eksempler på indforståethed, der mindsker overdrageligheden betragteligt: - Afsnit 2.1: WM-version angives til Dispensation, egen TDM, men uden angivelse af hvad dette betyder i praksis - Ingen angivelse af hvilke certifikater der skal erhverves, herunder hvilke krav der er til certifikaterne (f.eks. om det er et bestemt CVRnummer, der skal udstede certifikaterne) - Det fremgår ikke om testmiljøer og produktionsmiljø adskiller sig fra hinanden Vejledningen bør ajourføres. Ligesom der foreligger en installationsvejledning til web- og applikationsserver, bør der udarbejdes en lignende installationsvejledning til database-server. De indforståede elementer bør udspecificeres så der ikke forudsættes intern KMDviden: - Afsnit 2.1: WM-version angives til Dispensation, egen TDM, men uden angivelse af hvad dette betyder i praksis - Ingen angivelse af hvilke certifikater der skal erhverves, herunder hvilke krav der er til certifikaterne (f.eks. om det er et bestemt CVR-nummer, der skal udstede certifikaterne) - Det fremgår ikke om testmiljøer og produktionsmiljø adskiller sig fra hinanden 31