En præliminær beskrivelse af projektets tilgang til kravspecifikationen, der giver en kort beskrivelse af de løsningselementer, der vil blive brugt til at opfylde kravene i kravspecifikationen.
Dette dokument giver et overordnet overblik over hvordan de enkelte krav forventes imødekommet. For detaljer henvises til den tekniske dokumentation af produktet, hvor de enkelte løsningselementer er beskrevet i detaljer.
Hvert krav i kravspecs refereres til ved krav-id og overskrift, efterfulgt af enten en tekstuel beskrivelse af hvordan kravet imødekommes, eller en reference til et specifikt løsningselement. For den fulde kravsbeskrivelse henvises til kravspecifikationerne.
Den eksisterende løsning, der kører hos LMS i dag, vil blive genbrugt så vidt som muligt. En stor del af leverancen vil være dokumentation af datamodel, workflow, schemaer m.m.
Stamdata fra kildedataleverandørene bliver leveret af operatøren på forskellige måder. Nogle hentes dagligt af operatøren via FTP, andre leveres af kildedataleverandøren på andre måder. Overførselen afhænger af den enkelte leverandør. Når operatøren har modtaget data, placeres de i Stamdatas data-indbakke for parserne. Driftoperatøren står samtidig for arkivering og backup af indkommende filer, så data i Stamdatas database kan føres tilbage til kilden. Der er ingen afvigelser fra den eksisterende løsning hos LMS.
De eksisterende parsere fra LMS genbruges, og der udvikles 2 nye parsere til hhv “Sikrede” og Doseringsforslag. Løsningen er allerede klargjort til at løbende kunne udvides med nye datakilder, og de enkelte stamdata kilder ender i hver deres tabel, så der er ingen restriktioner på evt. nye datakilder.
Det forventes at den eksisterende stamdata-database kan replikeres fra LMS til NSI regi. Da det er samme driftsleverandør og MySQL der bruges, forventes opgaven at være minimal, omend der skal laves en grundig aftestning af at alle data er korrekt replikeret.
Der eksisterer gratis værktøjer til denne slags sammenligninger. Det vil være op til operatøren at afgøre om en sammenligning overhovedet er nødvendig alt efter hvordan de har kopieret data fra LMS til NSI.
Da hver datakilde ender i sin egen tabel(er), og driftsleverandøren sørger for backup af alle indkommende filer, er det altid muligt at spore en enkelt række i stamdata registeret.
Dette krav er opfyldt af den eksisterende LMS løsning.
Kravet opfyldes af en DGWS 1.0.1 beskyttet webservice, der udstiller de ønskede håntag til kopiering af registre (inkl. historik). Autorisation til registret styres via en simpel web-gui, hvor administratorer kan give adgang på CPR+CVR-niveau, samt oprette nye administratorer.
Ved at lade administrationen foregå på den centrale DoDi vil rettigheder til at tilgå systemet blive propageret ud til alle NSP'er vha. MySQL replikering. Derved skal man kun administrere adgang et sted, og hvis en NSP går ned, kan requests uden videre rediregeres til en anden NSP.
Data kan overføres i to formater, XML og FastInfoset. Der er mulighed for at tilføje andre output formater hvis det bliver nødvendigt. Da de data mængder der skal overføres i nogle tilfælde er meget store (millioner af data rækker), er det nødvendigt at effektivt kunne tilgå sevicen.
DGWS vil blive anvendt som bootstrap af et registerudtræk. DGWS bliver derved brugt til autentifikering og autorisering af anvendersystemer og deres publikationsrettigheder. Når anvendersystemet er godkendt tildeles det en sikker token som bruges til alle kald til servicen. Denne token vil give adgang til et enkelt register og man skal hente en ny token for hvert register man ønsker at tilgå. En adgangstoken er gyldig i samme tidsperiode som det STS ID-kort der blev brugt til bootstrap. Dette sikrer at den høje sikkerhedsgrad fra DGWS bebeholdes mens alle servicekald kan behandles af kopi-register-servicen meget hurtigt.
Der udstilles som nævnt en web-gui til at administrere publikationsrettigheder.
Den ønskede service udstilles som en DGWS 1.0.1 beskyttet webservice. Det antages at input kun er cpr-nummer, og output fra servicen er en liste af autorisationer der er knyttet til cpr-nummeret samt deres tilhørende uddannelseskode. Hvis kravet om navn som søgekriterier fastholdes, vil servicen nødvendigvis skulle returnere en liste af 0-n autorisationer og m mulige personer der matcher forespørgselen.
De nuværende operatørkrav forventes at blive revideret når den nye operatør kommer dertil. Som udgangspunkt forventes det at samtlige krav i det nuværende dokument vil blive opfyldt, dog er der ikke nogen support-aftale på plads endnu. Det anbefales at man starter op på at få en support-aftale på plads inden den endelige idræftssættelse af produktet.
Alle krav til teknisk dokumentation opfyldes, pånær kravet om en brugervejledning til de brugervendte systemer, da der ikke findes nogle af disse.
Der udarbejdes en testplan i samarbejde med kunden, der vil sikre at de nævnte krav til performance vil blive sikret ved faktiske tests.
Når kunden har bestemt sig for hvilken licens der ønskes brugt, sikres det at de rigtige headers vil blive en del af alt sourcekode og dokumentation.
SOSI Seal er den eneste SOSI komponent det giver mening at bruge, men denne bruges selvfølgelig.
Der udstilles en web-baseret monitoreringssnitflade, efter driftens ønske, der kan bruges til at overvåge de enkelte komponenter i stamdata registret.
NSP-Util v2 bruges til at sikre en ensartet SLA logning på tværs af de udstillede services.
Kravet opfyldes.
Kravet opfyldes vha unittests med >80% code coverage, målt i number-of-instructions, og integrationstests, der dækker de user stories der bliver identifiseret i løbet af projektet. Der trækkes rapporter ud af Hudson som dokumentation for både code coverage og funktionalitetsunderstøttelse.
Der udarbejdes en testplan i samarbejde med kunden, der vil sikre at de nævnte krav til performance vil blive sikret ved faktiske tests. Det forventes at alle performancetests vil blive afviklet i 3 miljøer
udviklermiljø
Formål: kvalitetssikring af testen, samt at fange evt. Leaks/bottlenecks tidligt
testmiljø hos operatøren/driften
Formål: afprøvning af komponenterne i et rigtigt NSP setup, for at fange evt. NSP- bottlenecks eller kompatibilitetsproblemer.
præproduktionsmiljø hos operatøren/driften
Formål: endelig trykprøve at komponenterne i forhold til de nævnte load-krav
Som en del af kontrakten mellem Trifork og Kunden er der committet til en tidsplan. Der henvises til kontrakten for de endelige detaljer. De udførende personer på projektet er som følger
Brian Graversen – Projektleder
Thomas Børlum – Udvikler
Det forventes at operatøren/driften stiller de nævnte afviklingsmiljøer til rådighed, og der assisteres med deployment i alle de nævnte miljøer. De endelige tests bliver afviklet i præproduktionsmiljøet som nævnt tidligere.
Dette dokument udgør løsningsbeskrivelsen, og dækker dermed dette krav
Kilden til dette dokument kan findes på:
https://svn.softwareborsen.dk/stamdata/trunk/Dokumentation
Version | Dato | Ændring | Ansvarlig |
1.0 | 27/4-2011 | Initielt Dokument | Trifork |
1.1 | 11/10-2017 | Version udstillet på NSPOP alene | Operatør |