Informationsmøde vedrørende Proof of concept for en integrationsplatform

Transkript

1 Informationsmøde vedrørende Proof of concept for en integrationsplatform

2 Dagsorden 1. Velkomst 2. Selve Løsningen 3. Visionen 4. Datamodel 5. Milepæle og prøver 6. Open source 7. Praktisk information

3 Selve Løsningen

4 Proof-of-Concept 2011 Etablere platform i testmiljø Basal integrationsplatform Modtage CPR udtræk og opdateringer Levere CPR data til IT System hos Kunden KOMBIT / Dataadgang 4

5 Rammer for teknisk platform Anvende afprøvede teknologikomponenter Anvende open source baseret software Service-baseret, modulariseret løsning Fokus på aggregering og integration af data Understøtte relevante standarder Best-practice lagdelt arkitektur Robust og skalerbar løsning

6 Løsningskoncept og omfang for POC

7 Arkitekturkomponenter for POC

8 Løsningsdrift for POC

9 Leverancer Kode & licenser Dokumentation Drift i driftsperioden Ingen hardware eller netværksudstyr

10 Visionen

11 Formål med præsentation af visionen Understrege formålet med POC Guide leverandørerne i løsningsarkitektur og design Sætte POC i muligt fremtidigt perspektiv

12 Proof-of-Concept Erfaringsdannelse Udstille fælles data på standardiseret form Afprøvning af arkitekturprincipper Etablering af infrastruktur Brug af open source i løsning Afgrænsninger Midlertidig løsning med (meget) begrænset drift Kun et dataområde til én anvender

13 Efter gennemført POC Erfaringerne fra POC giver Grundlag for videre forløb Input til arkitektur for fremtidig infrastruktur KOMBIT kan definere næste skridt i forhold til Dataadgangsprojektet Fælles infrastruktur for projekter

14 Dataadgangsprojektet Giver anvendere adgang til fælles, standardiserede data Fælles it-platform samt værdiskabende data. Nem, billig og hurtig adgang til relevante data Øget konkurrence mellem it-leverandører på kommunale marked Mulighed for bedre sammenhæng mellem kommunale fagsystemer Omkostningseffektiv og hurtig time-to-market med nye kommunale løsninger vha. fælles KOMBIT infrastruktur

15 Adgang til data Identificerede arketyper Gennemstilling af opslag (og evt. opdatering) Datarepository til opslag Datagrundlag for datawarehouse Fælleskommunalt register IT understøttelse Infrastruktur til integration Fokus på aggregering og udstilling af data

16 Skitse over arkitektur i fremtidig løsning

17 Mulige arkitekturkomponenter

18 Datamodel

19 Datamodel I kontrakten står: Leverandøren skal senest 5 uger før Overtagelsesdagen, levere dokumentation for den anvendte datamodel, inklusiv databeskrivelse, for distribution af CPR-data fra Løsningen til Kunden Formålet med denne formulering er, at vi så tidligt som muligt kan få tilstrækkelig information til, at vi kan forberede det it-system, der skal trække data fra Løsningen (Anvendersystemet)

20 Datamodel Det vil sige, at vi har behov for: En beskrivelse af den logiske datamodel i Løsningen En beskrivelse af den fysiske datamodel i Løsningen En beskrivelse af de operationer, der udstilles i snitfladen (fx handlinger og afhængigheder) En beskrivelse af samtlige data (fx hvilke data transmitteres, obligatoriske vs. valgfrie felter og datasemantik)

21 Datamodel I bilag 2, Kravspecifikationen står: Løsningen skal anvende relevante fællesoffentlige standarder. Særligt relevant er, at CPR-data i videst muligt omfang stilles til rådighed for Anvendersystemet som OIOXML. Der er to årsager til den formulering: Som offentligt ejet virksomhed ønsker vi i videst mulig udstrækning at anvende fællesoffentlige standarder. Konkret i forhold til datamodellen ønsker vi at anvende OIOXML, i det omfang det er muligt

22 Datamodel Vi ønsker, at det bestræbes, at datamodellen overholder OIOs navngivnings- og designregler. Med mindre, der er saglige grunde til at lade være, forventes, at datamodellen anvender skemaer i: 1. Kerneklassen 2. Domæneklasse for OIB 3. Andre relevante skemaer fra OIO

23 Milepæle og prøver

24 Generelt om prøver (1) Der er fire prøver Leverandøren udarbejder som del af sit tilbud en prøveplan for gennemførelse af hver af de fire prøver En prøve gennemføres ved at udføre prøveplanen for den konkrete prøve Efter gennemførelse af en prøve udarbejder Leverandøren en rapport over prøveforløbet med opførelse af eventuelle konstaterede fejl og mangler

25 Generelt om prøver (2) En prøve godkendes, når prøveplanen for den konkrete prøve er gennemført, og det er dokumenteret, at resultatet er som aftalt Alle prøver, undtagen driftsprøven, kan godkendes med mindre betydende fejl og mangler. Alle mindre betydende fejl og mangler skal være rettet inden driftsprøven kan godkendes Prøver, der involverer data, udføres med CPR-data. Kunden foretager de nødvendige aftaler vedr. adgang til CPR-data

26 Prøver Prøve Formål Særlige krav til inddragelse af Kunden Funktionel overtagelsesprøve Sikre, at Kundens funktionelle behov til Løsningen imødekommes i det aftalte omfang Nej Non-funktionel overtagelsesprøve Sikre, at Kundens nonfunktionelle krav til Løsningen imødekommes i det aftalte omfang Nej Dokumentationsprøve Sikre, at Kundens krav til dokumentation imødekommes i det aftalte omfang Kunden skal have 5 arbejdsdage til review af materialet

27 Prøver Prøve Formål Særlige krav til inddragelse af Kunden Driftsprøve Sikre, at Kunden kan hente et totaludtræk og ændringsudtræk fra Løsningen og på den baggrund kan generere et nyt totaludtræk, samt at sikre, at data overholder den valgte datamodel Kunden skal bruge: 10 arbejdsdage til at verificere totaludtrækket 10 arbejdsdage til at verificere ændringsudtrækket. Ændringsudtrækket kan først foretages efter verificering af totaludtrækket Sikre, at Løsningen imødekommer Kundens servicemål i minimum 10 sammenhængende dage Nej Sikre, at alle fundne fejl og mangler er afhjulpet Nej

28 Milepæle og deres sammenhæng Milepæl Deadline Forudgående milepæl Beskrivelse af datamodel indleveret Funktionel overtagelsesprøve gennemført Non-funktionel overtagelsesprøve gennemført Dokumentationsprøve gennemført Driftsprøve gennemført 5 uger før funktionel overtagelsesprøve 10. Maj 2011 Beskrivelse af datamodel 10. Maj 2011 Funktionel overtagelsesprøve 10. Juni 2011 Funktionel og nonfunktionel overtagelsesprøve 10. Juni 2011 Funktionel og nonfunktionel overtagelsesprøve Foretages senest samtidigt med Driftsprøven

29 Open Source

30 Krav om Open Source? Ikke et mindstekrav men et vurderingsparameter Løsningen kan derfor baseres på en kombination af standardprogrammel og Open Source Anvendelse af Open Source i Løsningen vil dog blive tillagt værdi i tilbudsvurderingen (Løsningens kvalitet)

31 Kontraktens definition af Open Source Open Source Programmel: Programmel, hvis licensbetingelser giver Kunden ret til og mulighed for at foretage ændringer i programmet på grundlag af kildekode, der er stillet til rådighed af licensgiveren for Kunden, andre kunder og offentligheden, (kontraktens 2.9)

32 Rettigheder Kunden erhverver alle rettigheder til programmer, interfaces og specifikationer, der er Kundespecifikt Programmel, samt den tilhørende Dokumentation, herunder retten til at ændre og videreoverdrage sådant programmel. (kontraktens 14.1) Kunden skal kunne stille Løsningen til rådighed for danske kommuner samt andre offentlige eller private kunder i Danmark mod betaling eller vederlagsfrit efter eget valg. (kontraktens )

33 Praktisk information

34 Proces for udbud Annoncering Kunden forventer ikke, at de samlede udgifter til Leverandøren i forbindelse med projektet vil overstige 1 mio. kr. eksklusive moms. Leverandøren ikke udelukket fra at byde næste gang

35 Tidsplan -24. januar kl :30 Spørge- og informationsmøde i KOMBIT februar 2011, kl : Frist for modtagelse af leverandørernes tilbud februar 2011: De 3 økonomisk mest fordelagtige tilbud i henhold til kriterierne udvælges til forhandling -2. marts 2011: Forhandlingsrunde med leverandørerne af de 3 økonomisk mest fordelagtige tilbud marts 2011, kl : Frist for modtagelse af reviderede tilbud marts 2011: Leverandørerne vil blive underrettet om Kundens valg marts 2011: Kontraktunderskrift.