Dokumentasjon, systemutvikling og regelverksutvikling

Transkript

1 Dokumentasjon, systemutvikling og regelverksutvikling Forelesning i Finf4001, 16. oktober 2007 Herbjørn Andresen, stipendiat ved Afin Offentlige organers plikter til å gjøre informasjon tilgjengelig (Boksene markerer plikter og prinsipper som til en viss grad har betydning for tilgjengeliggjøring av kunnskaper om systemers rettslige innhold) Tilgjengelig for alle Tilgjengelig for berørte personer/organisasjoner Tilgjengeliggjøring uten forutgående forespørsel Tilgjengeliggjøring etter forespørsel Publiseringsplikter Publicatio legis -prinsippet, Grl. 84, Lov om Norsk Lovtidend Kommuneloven 4 Fvl 37 (høring og varsling) Offentlighetsprinsippet Offentlighetsloven, - Innsynsrett for enhver - Visse unntak - Plikt til å vurdere meroffentlighet Opplysningsplikter Forelegge saksopplysninger, fvl 17 Informasjon om behandlinger av personopplysninger, pol (Individuell) innsynsrett Partsinnsyn (i saken), fvl 18 Innsyn i registrerte opplysninger, pol 18 Innsyn i regelinnholdet til grunn for helautomatiske beslutninger, pol 22 1

2 Systemtransparens transparen't a2 (også utt -an>g; gj fr fra mlat, av transparere 'være synlig gjennom', av trans- og lat. parere 'være synlig') gjennomsiktig, gjennomskinnelig Hva er systemtransparens? I grove trekk innebærer det at det transformerte, rettslige innholdet skal være tilgjengelig, forståelig og forsvarbart Hvorfor systemtransparens? Et (av mange) midler for å realisere viktige hensyn som Egenskaper rettssikkerhet, demokrati og personvern Mål/idealer Hvordan oppnå systemtransparens? Styring, organisering/medvirkning, dokumentasjon, opplæring osv. Virkemidler/metoder Forståelighet Forvaltningens generelle veiledningsplikt, fvl. 11 å gi parter og andre interesserte adgang til å vareta sitt tarv i bestemte saker på best mulig måte Pol 22, innsyn ved helautomatiske beslutninger Hvis en avgjørelse har rettslig eller annen vesentlig betydning for den registrerte og fullt ut er basert på automatisk behandling av personopplysninger, kan den registrerte som avgjørelsen retter seg mot, kreve at den behandlingsansvarlige gjør rede for regelinnholdet i datamaskinprogrammene som ligger til grunn for avgjørelsen 2

3 Forsvarbarhet Generell begrunnelsesplikt, fvl. 24 og 25 Klagerett, fvl. 28 Alle avgjørelser kan normalt påklages i én instans, som kan prøve alle sider ved saken Reservasjonsretten for helautomatiske avgjørelser, pol 25 Den som en fullt automatisert avgjørelse som nevnt i 22 retter seg mot eller som saken ellers direkte gjelder, kan kreve at avgjørelsen overprøves av en fysisk person. Tilgjengelighet Hvordan kan rettslige systemavgjørelser bli offentlige? 1. Programkoden kan gjøres offentlig tilgjengelig 2. De rettslige systemavgjørelsene kan formuleres som pseudokode 3. De rettslige systemavgjørelsene kan dokumenteres i form av et utvalg av avgjørelser i vanlig språk som a) avklarer tolkningstvil av betydning og b) inneholder supplerende regler i forhold til rettsgrunnlaget 4. De rettslige systemavgjørelsene kan dokumenteres ved at de blir uttrykt som og integrert i det vanlige regelverket (lov, forskrift mv) 5. De rettslige systemavgjørelsene kan dokumenteres ved at selve beslutningssystemet blir offentlig tilgjengelig 3

4 Dokumentasjon som virkemiddel for systemtransparens Systemdokumentasjon som Kinder-egg, løser tre ting på en gang Dokumentasjonen er et håndfast produkt, som er egnet for tilgjengeliggjøring Dokumentasjonen beskriver systemets innhold i naturlig språk, som er mer forståelig Dokumentasjonen kan (forhåpentligvis) beskrive samsvaret mellom rettskilder og transformering, som gjør IT-systemets transformerte regelverk forsvarbart Rettslig dokumentasjon i Schartum 2005 kap. 7: Definert slik: Funksjoner/egenskaper ved systemet som er basert på rettskilder eller som det er påkrevd å bruk juridisk metode for å vurdere kvaliteten av Fire ulike former: Bekreftede systemspesifikasjoner Brukerveiledninger Interne regelverk I form av endringer i rettskildene (Generell legalitetskontroll) (Individuell legalitetskontroll) (Veiledning, presedenser etc.) (Tilbakeføring) 4

5 Krav til rettslig systemdokumentasjon Hvordan kan vi godtgjøre/ verifisere at programkoden er i samsvar med gjeldende rett? Rettslig systemutvikling Samle og fortolke alle relevante rettskilder Beslutte hva som er riktige tolkningresultater uttrykt i naturlig språk Formalisere tolkningsresultatet Beslutte hva som er en riktig representasjon av rettskildene dokumentasjon Dokumentere samsvar E-forvaltning i Norden, kap. 16: Hva skal dokumentasjonen inneholde, og hvordan utforme den? Dokumentasjonens formål Legalitetskontroll, veiledning, vedlikehold (samme perspektiver som i Dags artikkel) Dokumentasjonens målgrupper Mest problematisert. Trenger interne og eksterne ulik dokumentasjon? Bidrar ulike typer dokumentasjon til å sementere forskjellige kunnskaper om transformeringen? Dokumentasjonens systematikk Håndverket, pragmatikk og nytteverdi 5

6 Dokumentasjonsproblem I, hvor i IT-systemet har de ulike rettskildene blitt av Programkodemoduler Databasedefinisjoner Lagrete, formaliserte data Positive definisjoner tabeller attributter projeksjoner skjermbilder, inntasting og visning av data dataverdier Restriksjoner integritetsregler domenerestriksjoner kode som angir kriterier for kontroll av inntastete verdier data som angir kriterier for kontroll av innlastete verdier Oppdatering av data triggere og lagrede prosedyrer kode som setter betingelser for oppdatering data som setter betingelser for oppdatering Algoritmer lagrede prosedyrer kode som inneholder algoritmer for å beregne nye verdier data som inneholder algoritmer for å beregne nye verdier Transformeringsrommet Dokumentasjonsproblem II, i praksis er svært mange IT-systemer underdokumenterte Feil profesjoner som skriver dokumentasjon? Lavt prioritert i utviklingsprosjekter? Bi-produkt av utviklingsprosessen, vedlikeholdes derfor dårlig etter at systemet er tatt i bruk? Gir lite status å skrive dokumentasjon? 6