KRAVSPESIFIKASJON Standarder for informasjon-, kommunikasjonog telefonisystemer. Fredrikstad kommune Januar 2009 Ver. 2.7 Fredrikstad kommune/it-avdeling/ketil Johansen Side 1 av 15
1 Innhold 1 Innhold... 2 2 Innledning... 3 2.1 Generelt... 3 2.2 Anbud/Leveranse... 3 2.3 Innføring av nye IT-systemer... 3 2.4 Organisering... 3 2.5 Tiltakshaver... 3 3 Systemtekniske krav... 4 3.1 Generelle krav... 4 3.1.1 Windowsplattform... 4 3.1.2 Databasestandarder... 4 3.1.3 Kommunikasjonsprotokoller... 4 3.1.4 Elektronisk post... 4 3.1.5 Intranett/Internett... 5 3.1.6 Serverstruktur... 5 3.1.7 Publisering av applikasjoner... 5 3.1.8 Firewall (Brannmur)... 5 3.1.9 Proxy... 5 3.1.10 DMZ... 6 3.1.11 Interne konvensjoner... 6 3.2 Krav til programmer/applikasjoner... 6 3.2.1 Installasjon... 6 3.2.2 Oppdatering - Nye versjoner... 6 3.2.3 Adresseringer... 6 3.2.4 Programvarelås... 6 3.3 Database regler... 7 3.4 Krav til integrasjon med andre systemer... 7 3.5 Forhold til eksisterende løsninger... 8 3.6 Brukeradministrasjon... 9 3.7 Krav til systemadministrasjon... 9 3.8 Krav til brukergrensesnitt... 9 3.9 Krav til oppgraderineger... 9 4 Standard applikasjoner... 9 5 Krav til opplæring... 10 6 Krav til dokumentasjon... 10 6.1 Systemdokumentasjon... 11 6.2 Brukerdokumentasjon... 11 7 Telefonsentraler... 11 8 Kabling... 11 8.1 Spesifikasjon for installasjon av strukturert kabling for telefoni og data.... 11 8.2 Punktplassering... 12 8.3 Utvendige framføringsveier... 12 9 Datarom... 12 9.1 Sentrale/større rom... 13 9.2 Perifere/små rom... 13 9.3 Undervisningsrom... 13 Fredrikstad kommune/it-avdeling/ketil Johansen Side 2 av 15
2 Innledning 2.1 Generelt Fagområdet informasjonsteknologi, kommunikasjon og telefoni forvaltes av ITavdelingen i Fredrikstad kommune. Dette innebærer følgende: Leverandører som skal innføre IKT-orienterte systemer skal arbeide i samråd med Fredrikstad kommunenes IT-avdeling. Dette dokumentet er utarbeidet for bruk ved: - Anskaffelser av IT-systemer - Vesentlige endringer av eksisterende IT-systemer - Nybygg, bygningsmessige utvidelser eller større restaureringsarbeider som berører kommunikasjonsområder. Det vil være slik at enkelte deler av dokumentet er irrelevant for enkelte leveranser (eksempelvis vil databasestandarder være irrelevant hvis leveransen er fysiske kablingsarbeider). 2.2 Anbud/Leveranse Når en leverandør skal legge inn et anbud etter en forespørsel fra Fredrikstad kommune skal alle forhold stemme med de nedenforstående krav og spesifikasjoner. Mangler leverandøren informasjon kan dette fåes på forespørsel til Fredrikstad kommunes IT-avdeling. 2.3 Innføring av nye IT-systemer Leverandøren skal være klar over at ved nye IT-prosjekter som medfører nyinstallasjoner av IT-systemer har Fredrikstad kommune innført en rekke rutiner som må gjennomgås før installasjonen iverksettes. Herunder også bygningsprosjekter. Dette er i hovedsak regulert i kommunens IT-strategi. I hovedsak medfører dette at et råd (IT-rådet) må godkjenne installasjonen før den anskaffes. 2.4 Organisering Ved etablering av et midlertidig prosjekt skal leverandørene starte et samarbeid med IT-avdelingen. Ved oppstartsmøter skal leverandøren stille med de fagpersonene som skal gjennomføre prosjektet. It-avdelingen stiller ved slike møter. 2.5 Tiltakshaver I de fleste IT-prosjekt finnes en intern tiltakshaver i kommunen. Dette er den som er ansvarlig for den interne prosjektledelsen. Ved innføring/anskaffelse er dette normalt ikke IT-avdelingen. Fredrikstad kommune/it-avdeling/ketil Johansen Side 3 av 15
3 Systemtekniske krav 3.1 Generelle krav 3.1.1 Windowsplattform Det stilles følgende systemtekniske krav: Windows-basert applikasjon 32 bits kode uten inteprenting Alle applikasjoner skal være kjørbare på Citrix Metaframe Presentation Server 4.5 og Microsoft Terminal server (fix er og patcher opplyses ved behov av IT-avdelingen) Alle servere er basert på Windows 2003 og Windows 2008, og alle løsninger skal støtte dette. Flerbrukersystem i praksis ingen begrensning på antall samtidige brukere Det er fordel om systemet er web-basert (plattform spesifisert nedenfor). All oppdatering som ikke er bruker-/handlingsorientert skal gå automatisk og ikke måtte kjøres som vedlikeholdsjobber i bakgrunnen 3.1.2 Databasestandarder Oracle database, ver 10g MS-SQL 8.0 Borland Interbase SQLnet skal benyttes mot databasen Borland Interbase og MS-Sql er i bruk, men ikke preferert og i utgangspunktet diskvalifiserende i en anbudsrunde, der Oracle prefereres. Både ODBC og ADO benyttes som koblinger mellom applikasjonen og databaseinstansen. 3.1.3 Kommunikasjonsprotokoller Det er kun TCP/IP som tillates, systemer må ikke kreve eller generere andre protokoller. De fysiske standardene er beskrevet nedenfor. Hvis andre protokoller benyttes mot annet teknisk utstyr (enn IT-utstyr, - eksempelvis PLS styringer) skal det så nært som mulig NATes fra den propritære protokollen over til IP. 3.1.4 Elektronisk post Standard system for elektronisk post er MS-Outlook 2007 på klientsiden og MS- Exchange 2007 på serversiden Fredrikstad kommune/it-avdeling/ketil Johansen Side 4 av 15
3.1.5 Intranett/Internett Standard Web-server system: System Operativsystem WEB-server system Redigeringsverktøy Programmeringsverkt øy Applikasjon Windows 2008 server MS-Information server EPI-server* Frontpage EnkelWeb** MS-Visual Studio *Et produkt levert av Sem & Stenersen. **Et produkt levert av Integrasjonspartner AS - www.integrasjonspartner.no 3.1.6 Serverstruktur Strukturen på serverne som inngår i den totale løsningen er vist i Vedlegg 1. FRK serverfarm er en delt EDB-løsning og alle løsninger skal dekke Datatilsynets krav. 3.1.7 Publisering av applikasjoner Applikasjoner kjøres under Citrix Publisering, hvilket innebærer at klienten får tilgang til selve plattformen (Windows 2003/Windows 2008 herunder også Internet Explorer, Outlook og MS Office) direkte fra Front End terminalserver. Fagapplikasjoner er tilgjengelige fra terminalservere som kjøres publisert bak terminalserverfarmen. Disse benevnes Applikasjonserverfarmer. Begge type farmer kjøres lastbalansert. Prinsippet er vist i Vedlegg 2. 3.1.8 Firewall (Brannmur) Det benyttes Netscreen og MS-ISA som ytre og indre Firewall. Datatilsynets krav og regler blir overholdt. Det forutsettes at leverandører av programvare holder seg innenfor de samme rammer. Dette gjelder all form for kommunikasjon, slik som: - Talesystemer - Tradisjonelle filoverføringssystemer - Applikasjonsbaserte datastrømmer - Låsesystemer - Andre signalbaserte systemer 3.1.9 Proxy FRK benytter MS-ISA server som proxy for å aksessere Internett på HTTP, HTTPS. FTP benyttes kun i begrenset grad, og leverandører må drøfte slik bruk nærmere, - i utgangspunktet for leveranser oppfattes dette som diskvalifiserende. Fredrikstad kommune/it-avdeling/ketil Johansen Side 5 av 15
3.1.10 DMZ Kommunen benytter en kompleks Demilitær Sone(er) mellom LAN og Internett. Det er etablert 2 soner i DMZ, first- og second defence. Alle systemer som skal kommunisere igjennom fra Internett til LAn eller omvendt har ikke lov til å passere to soner uten å snakke igjennom en ISA/Proxy server. Yttligere informasjon kan fås ved henvendelse til IT-avdelingen. 3.1.11 Interne konvensjoner For all navngiving finnes det interne konvensjoner, tilsvarende også for adressering (eks. IP). Tilbyder skal konferere med IT-avdelingen Fredrikstad kommune å få tildelt navn og IP adresser for løsningene ved implementering. 3.2 Krav til programmer/applikasjoner 3.2.1 Installasjon Alle programmer som skal installeres skal leveres på MSI-fil format. Når en ny applikasjon installeres skal denne først installeres på en test(pakkeserver) og testes under det rette miljøet simulert. Deretter skal den legges på serveren som programmet skal kjøres i produksjon på. Programmene installeres fra MSI filen ved hjelp av Citrix. Bruk av kun setup-filer for installasjon av programmer er diskvalifiserende i forhold til msi. 3.2.2 Oppdatering - Nye versjoner Tilsvarende rutine og krav som under pkt. 3.2.1. Enhver ny versjon av et program skal leveres IT-avdelingen og testes i det simulerte miljøet (testmiljø) får den settes i produksjon. 3.2.3 Adresseringer Program skal kunne kjøres i et stormiljø. Dette innebærer at alle ressurser skal kunne adresseres internt fra programmet. Eksempler på dette kan være: at filområder applikasjonen benytter skal kunne styres til perifere disker, normalt også andre servere. at databaser legges på egne servere ikke annet enn selve den eksekverende delen av programmet finnes på applikasjonsserveren Dette innebærer at all internadressering aksepterer bruk av UNC-path 3.2.4 Programvarelås Det tillates ikke leveranser av programvare med noen form for fysisk programvarelås, dongler eller USB brikke etc. All kontroll av lisensnummer skal skje mot filbaserte løsninger lokalisert på den samme serveren som applikasjonen ligger. Bruk av slik programvare er utelukket. Fredrikstad kommune/it-avdeling/ketil Johansen Side 6 av 15
3.3 Database regler Følgende regler gjelder for implementasjon av relasjonsdatabaser med relasjoner mot eksisterende systemer i Fredrikstad kommune. Når en leverandør skal implementere databasesystemer som skal ha relasjoner, views, triggere eller annen kontakt med eksisterende databaser gjelder følgende hovedregler: Data skal kun finnes et sted Dette innebærer at når systemet har behov for data som finnes i et eksisterende system, skal disse registrene/tabellene ikke dupliseres. Systemet skal hente data fra det eksisterende systemet. Dette gjelder selv om det vil medføre omskrivninger av systemet. Disse data skal hentes i et ekte View (ev. snapshot) mot de eksisterende tabellene. Det tillates ikke at tabeller kopieres over til systemet. Opprettelse av sysposter Når det ikke er mulig å opprette relasjoner kun ved bruk av Views tillates det å kopiere over systempost(er), felter med innhold, som muliggjør opprettelse av relasjoner mot systemets datastruktur. Minst mulig datamengde skal kopieres over. Kopiering av sysposter anses ikke som duplisering av data. Handlinger mot eksisterende systemer All programkode (Triggere, SQL-statement, prosedyrer) som utfører oppslag mot Views eller Snapshot og som sørger for oppdatering av systemposter må ligge i systemet. Det er ikke tillatt å skrive kode inn i de eksisterende systemene. Leverandøren bærer selv ansvaret for at systemet lar seg oppgradere i takt med kommende oppgraderinger av de eksisterende systemene. Når en eksisterende systemtabell får nytt navn og relasjonen forsvinner må leverandøren oppgradere sin egen kode. Leverandøren vil bli kontaktet i hvert enkelt tilfelle. 3.4 Krav til integrasjon med andre systemer Utover de ovenstående reglene for databaserelasjoner gjelder også; Alle utvekslingsprosedyrer skal ligge i systemet. Utveksling av data mellom systemet og eksisterende løsninger skal gå automatisk Tilbys en annen løsning/modell enn dette, må den begrunnes og beskrives spesielt. Tilbys det eksempelvis en form for mellomlagring av eksportdata fra eksisterende system må tilbyderen beskrive hvorledes rutinene for import til nytt system skal foregå. Benyttes det flatfil (ev. et utvekslingsformat) for mellomlagring må både utvekslingen fra eksporterende og importerende system løses og beskrives. Fredrikstad kommune/it-avdeling/ketil Johansen Side 7 av 15
3.5 Forhold til eksisterende løsninger Ved integrasjon av systemet skal ikke eksisterende systemer endres. Trengs eksport/import fra eksisterende systemer skal dette skje fra systemet. Disse eksportprosedyrene skal lagres i systemet og brukeren skal kunne nå disse fra det systemets brukergrensesnitt. Tilbyder er ansvarlig for integrering mot eksisterende systemer. Dette innebærer at tilbyder for eksempel må skaffe databasedefinisjon(er) direkte fra leverandørene av eksisterende systemer. Kommunen kan være behjelpelig med å etablere kontakt med kommunens IT leverandører. Følgende garantier må gis i tilbudet: Leverandøren skal gi garantier for at innlesningsprosedyre(er) fra eksisterende system fungerer tilfredsstillende. Leverandøren skal gi garantier for at eksportering fra systemet fungerer tilfredsstillende. Leverandøren skal gi garantier for at ved endringer av eller i eksisterende system må leverandøren oppgradere systemet slik at det fortsatt fungerer (eksport/import) optimalt. Leverandøren skal gjøre dette etter bestilling fra kommunen. Leverandøren skal legge alle Views, Triggere, Prosedyrer, etc i nytt systemet. Ingen kode må legges i eksisterende system. I motsatt fall, at en annen leverandør trenger opplysninger om det innkjøpte systemet forplikter leverandøren å tilrettelegge slik at en av FK s andre underleverandører for tilgang på nødvendig informasjon. Herunder eksempelvis databasestrukturer, kildekode etc. Likeledes forplikter FK s leverandører seg til å etablere et gjensidig samarbeid med FK s andre aktuelle leverandører. FK er behjelpelig med å etablere kontakt. Fredrikstad kommune/it-avdeling/ketil Johansen Side 8 av 15
3.6 Brukeradministrasjon Det stilles krav til administrasjon av brukere. Systemet skal koble sammen Windows AD slik at man ikke må definere brukere inne i applikasjonen. Man skal kunne legge til tilgangsnivåer og styre rettighetene til de enkelte brukere av systemet. Hvis systemet skal detektere påloggende brukere skal dette korrespondere med ordinær Windows ident. 3.7 Krav til systemadministrasjon Systemet skal benyttes av flere virksomheter. Hver virksomhet har egne driftsmidler og mannskaper og må derfor ha definert egen avdeling/brukerområde i systemet. Alle brukere skal defineres og ha ulike tilgangsrettigheter. Kontroll av brukeridentitet må skje ved pålogging. 3.8 Krav til brukergrensesnitt Systemet skal være brukervennlig og windowsbasert. Systemet skal benytte Graphic User Interface (GUI), og følge standard MS-Windows konvensjoner. Systemet skal ha en lettforståelig struktur av skjermbilder og menyer. Systemet skal også kunne håndteres av brukere som tilbringer liten del av sin arbeidsdag foran en dataskjerm. 3.9 Krav til oppgraderinger Når programvaren oppgraderes for kommende versjoner skal den nye oppgraderingen bestå av en fullverdig installasjon. Dette innebærer at den nye oppgraderingen skal kunne installeres uten å ha den gamle tilgjengelig, enten installert eller på annet lagringsmedium. All programvare skal leveres på godt merket medium. Ved hver programvareleveranse skal det medfølge en installasjonsveiledning. Leveres programvaren over digital linje, plikter leverandøren å sørge for at ITavdelingen blir informert om slikt. Og retningslinjene over følges. 4 Standard applikasjoner Ved tilbud av systemer som krever integrasjon mot øvrige standardapplikasjoner skal nedenforstående liste legges til grunn: Type Produkt Kontorstøtte MS-Office 2007 Internett Browser MS-Internett Explorer 7.0 Bildebehandling MS-Photoeditor Adobe Photoshop 6.0 eller nyere Desk Top Publishing Adobe Indesign CS 2 eller nyere. MS-Publisher Dokumentvisning Adobe Acrobat Fredrikstad kommune/it-avdeling/ketil Johansen Side 9 av 15
Adobe Writer 7.0 eller nyere Konstruksjonstegning AutoCad Tegning Corel Draw 10.0 eller nyere Tegnining Org kart Smartdraw Dørlåssystem Integra Fraværsmarkering Trio Presens Sak/arkiv-system Ephorte *Det kjøres to versjoner av MS-Office. På Front-end Terminalservere kjøres XP, mens det på Back-end Applikasjonsservere kjøres 2003. Hvilket innebærer at benyttes applikasjonen som tilbys MS-Office intern må den kunne benytte ver. 2007. Ved uklarheter konfereres IT-avdelingen Fredrikstad kommune. Skal tilbudt system integreres mot andre standardapplikasjoner må tilbyder ta kontakt med Fredrikstad kommune v/it-avdelingen for å få rede på hvilke øvrige applikasjoner som er standard. Tilsvarende gjelder også for spesielle applikasjoner/fagapplikasjoner. 5 Krav til opplæring Leverandøren må kunne stå for opplæring av brukere og/eller av løsningsansvarlige for systemet, når dette kravspesifiseres av kommunen. Kommunen beslutter endelig omfang av opplæringen. Opplæringen må tilpasses de enkelte brukeres behov, og derfor deles opp i minimum to grupper: Brukere som kun skal ha spørre tilgang Brukere som skal registrere/bruke systemet Kompleksiteten til systemet vil være avgjørende for valg av løsning for opplæring, Det må utarbeides en milepælsplan og ansvarskart for opplæring. Denne må redegjøre for metode, tidsplan, ressursbruk samt kostnader. Leverandører må kunne stille et forhåndsavtalt antall konsulenttimer til rådighet for kommunen til bruk i opplæringsøyemed. Det må påligge leverandøren å utarbeide en komplett opplæringsperm som kommunen kan distribuere til sine brukere. Kommunen vil kunne kreve opplæring av interne superbrukere som igjen står for videre intern opplæring. 6 Krav til dokumentasjon Dokumentasjonen skal omfatte alle deler av systemet og skal være på norsk. Dokumentasjonen/brukerhåndbøkene skal sikre at systemet brukes på en forsvarlig og korrekt måte. Fredrikstad kommune/it-avdeling/ketil Johansen Side 10 av 15
Dokumentasjonen skal foreligge både i papirformat og i form av hjelp-funksjon i systemet. Det er viktig at brukeren i et hvert skjermbilde skal kunne søke på aktuelle hjelpe-ord eller funksjoner. 6.1 Systemdokumentasjon Systemdokumentasjonen skal vise hvordan systemet er bygd opp og hvordan kravene til funksjonalitet i regelverket er ivaretatt slik at brukere på en enkel måte kan sette seg inn i hvordan systemet fungerer. Systemdokumentasjon, oppsettparametere, -regler, maskinelle kontroller og tilgangsrettigheter som er nødvendig for etterprøving, skal fremgå på en oversiktlig måte. Systemdokumentasjonen skal minimum inneholde en datadictionary med beskrivelse av hva de ulike tabeller/felt brukes til og angivelse av eventuelle maskinelle kontroller tilknyttet til de enkelte felt og hvordan systemgenererte feltverdier beregnes. Komplett databasedefinisjon skal leveres. Applikasjonen skal inneholde historikk med entydig identifikasjon, produksjonsdato og periodeangivelse. Det skal være mulig å kontrollere at ingen historikk kan overstyres i ettertid. Historikken skal være implementert i løsningen og kunne leses til enhver tid. 6.2 Brukerdokumentasjon Det skal være system for oppdatering av brukerhåndbøkene. Oppdatering kan skje ved overføring av filer m/dokumentasjon, eller ved fysisk oversendelse av papirbaserte endringsdokumenter. 7 Telefonsentraler Fredrikstad kommune har gått over til IP-telefoni. Nye virksomheter skal derfor ikke ha ordinær telefonsentral. Alle henvendelser til IT-avdelingen. 8 Kabling 8.1 Spesifikasjon for installasjon av strukturert kabling for telefoni og data. Termineringspanel Kabler Kontakter I alle termineringspunkter Kabler til arbeidsplass Det skal benyttes Systimax skal det benyttes Systimax 1071 kabler, Gigaspeed XL Alle kontakter skal være av RJ45. 7 type RJ45 med 568Bstandard på pinneutlegget i ( kat. 6 ) Utstyret skal være tilpasset Kabler som skal kontaktene. 19 profiler tilfredsstille spesielle Alt kontaktmateriell skal Fredrikstad kommune/it-avdeling/ketil Johansen Side 11 av 15
Alt utstyr skal være i Systimax-familien. branntekniske krav skal også være produsert av Avaya. Stamkabler, kobber. Alle stamkabler skal tilfredsstille kat.5e. være av Systimax Gigaspeed familien. Fiber All terminering av fiberkabler skal foretas med LC-konnektorer og fortrinnsvis monteres i 19" fiberpaneler der hvor det finnes denne type rack. Ellers kan fibrene termineres i veggbokser. Merking All merking skal følge merkesystemet som er beskrevet i Systimaxstandarden. Fiber All kabel innvendig, enten det er stamkabler eller til arbeidsplass skal være multimodus, 62,5/125 eller 50/125. (Type velges av ITavd. i hvert enkelt tilfelle). All fiberkabel som legges utvendig mellom bygg skal være singelmodus. Merking All merking skal følge merkesystemet som er beskrevet i Systimaxstandarden. Merking All merking skal følge merkesystemet som er beskrevet i Systimaxstandarden. Det skal tas høyde for et anlegg som er dimensjonert på en slik måte at splitting av punkter ikke skal forekomme. (Det eksisterer rammeavtale med underleverandør for intern kabling. Hvilke dette til en hver tid er opplyses av IT-avdelingen.) 8.2 Punktplassering Plassering av innvendige datapunkter skal gjøres i samråd med IT-avdelingen og aktuell virksomhetsleder for bygget. Tilsvarende gjelder også mengde. 8.3 Utvendige framføringsveier Ved nybygg eller ved endringer av eksisterende framføringsveier av signalkabler skal IT-avdelingen kontaktes. Ved spørsmål eller avgjørelser vedrørende eksterne grensesnitt kan IT-avdelingen kontaktes i hvert enkelt tilfelle. 9 Datarom Det defineres/finnes tre type datarom: Sentrale/større rom Perifere/små rom Undervisningsrom Fredrikstad kommune/it-avdeling/ketil Johansen Side 12 av 15
Hvordan hvert enkelt rom defineres avgjøres i samråd med IT-avdelingen. 9.1 Sentrale/større rom Design og utførelse av datarom skal foretas i samarbeide med IT-avdelingen. Det skal legges datagulv med minimum 15 cm effektiv plass for signalkabling. Videre skal alle sterkstrømskabler og 220V anlegg plasseres i TEK 123 kanaler i taket på anvist plass over server og elektronikk racksystemer. Hvis det er påkrevd med slokkeanlegg skal det benyttes Argonite gass slokkeanlegg dimensjonert med en minste konsentrasjonskoeffisient på 12.5, samt godkjent alarmsender. Hvorvidt slike anlegg skal etableres fremkommer av spesifiseringen av hver enkelt anskaffelse. Kjøling skal monteres med fordampere i taket, og beregnes ut fra avgitt effekt fra det aktuelle utstyret som skal monteres i rommet. Det skal ikke overstige 20 grader Celsius i rommet. Rack (skap) skal være 19 tommer, med en minimums dybde på 55 cm fra monteringsskinnene i forkant til monteringsskinnene i bakkant av skapet. 9.2 Perifere/små rom Minimumskrav på 4 kvadratmeter. Rack (skap) skal være 19 tommer, med en minimums dybde på 55 cm fra monteringsskinnene i forkant til monteringsskinnene i bakkant av skapet. To hyller hører med til standard installasjon. 9.3 Undervisningsrom Forhold som gjelder rundt etablering av dataundervisningsrom er beskrevet i eget dokument, Norm for etablering av dataundervisningsrom. Dokumentet er tilgjengelig hos IT-avdelingen og vil bli gjort tilgjengelig der det er relevant. Utover dette gjelder alle spesifikasjoner gitt i dette dokumentet. Fredrikstad kommune/it-avdeling/ketil Johansen Side 13 av 15
VEDLEGG 1 Serverstruktur Fredrikstad kommune/it-avdeling/ketil Johansen Side 14 av 15
VEDLEGG 2 Applikasjonspublisering Fredrikstad kommune/it-avdeling/ketil Johansen Side 15 av 15