KAPITEL 9

Syntese af retlige og datalogiske elementer

I de foregående kapitler er beskrevet en række retlige elementer - i form af henholdsvis retligt materiale og retlige metodeelementer - og en række datalogiske elementer. Kapitlet her vil udgøre scenen, hvor de bliver sat sammen til en systemudviklingsmodel, som kan sikre retlig kvalitet. Styrende for syntesen er de tiltag, som er blevet beskrevet som henholdsvis et innovationstiltag, et integrationstiltag og et kommunikationstiltag.

Det vil fremgå, at der kan skabes flere forskellige syntesemodeller, som hver har sine fordele og ulemper. Når metoden skal anvendes i praksis, bliver man nødt til at foretage et valg. Vælge én af flere mulige veje for det konkrete systemudviklingsprojekt. Her foretages en del af de nødvendige valg. Det gøres primært, fordi det vil være meget enklere at forklare metoden for deltagerne, hvis der ikke skal beskrives alt for mange variationsmuligheder. Men derudover kan denne løsning forsvares med, at det vil være forholdsvist enkelt at foretage modifikationer i systemudviklingsmodellen på grundlag af den analyse, som finder sted i det følgende.

Af fremstillingsmæssige grunde vil syntesen blive anskuet ud fra to forskellige vinkler. En vinkel som fokuserer på løsningen af innovationsproblemet, og en vinkel som fokuserer på løsningen af integrations- og kommunikationsproblemet. Hver vinkel giver anledning til en delløsning, og den endelige systemudviklingsmodel fremkommer da ved at sammenstykke de fundne delløsninger.

I det følgende vil der blive set på, hvilket materiale der er nødvendigt, hvilke aktiviteter der skal udføres, hvornår disse aktiviteter skal udføres, og om de eventuelt skal gentages flere gange.

Syntesens elementer

Syntesens elementer udgøres af de retlige elementer, som er beskrevet i kapitel 3 til 6, samt de datalogiske elementer, som er beskrevet i kapitel 8.

De datalogiske elementer består af metodeelementer, som beskriver aktiviteter betegnet som henholdsvis specifikation, design og implementering samt validering:

De retlige elementer udgøres på den anden side af et grænseafstikkende materiale i form af henholdsvis gældende ret og et prøvelsesgrundlag. Derudover et frihedsskabende materiale i form af retspolitiske mål/hensyn, retssikkerhedshensyn og -krav samt tilsvarende persondatabeskyttelsesretlige⁶⁶⁸⁾. Endelig er der fundet nogle retlige metodeelementer, som knytter sig til det retlige materiale. Her skal specielt fremhæves de metodeelementer, som kan sikre enkelhed, metodeelementer som kan anvendes til at fremfinde frihedsskabende materiale, og prøvelsesprocessen, som kan sikre, at en afgørelse kontrolleres.

Innovationsvinkel

Innovationstiltaget anviser, at innovationsproblemet skal løses på grundlag af et materiale, som giver frihed, og et materiale, som afstikker grænser. Begge grundlag skal være af bred retlig karakter.

Man kan tænke sig situationer, hvor man slet ikke ønsker innovation. Dette vil ofte være tilfældet for så vidt angår de relevante materielle regler. Folkepensionens grundbeløb må være det samme, hvad enten det er en menneskelig sagsbehandler eller et automatiseret system, der sørger for, at en ansøger får tildelt pension. Man kan også forestille sig den situation, at man endnu ikke er klar over på hvilke områder, man ønsker innovation. Eksempelvis fordi det kræver nærmere viden om de tekniske muligheder. Begge disse situationer er udskilt til særskilt behandling nedenfor i afsnittet "retlig status quo".

Retlig innovation

Innovationstiltaget forudsætter, at der findes et frihedsskabende materiale samt et grænseafstikkende materiale. Et materiale, som vil kunne give frihed, er retspolitik og retssikkerhed. Et materiale, som vil kunne afstikke grænser, er gældende ret og prøvelse.

For at finde frem til nogle mere specifikke krav til systemet vil det også være nødvendigt at inddrage ikke-retlige krav til systemet. Konfronteres nu disse med det retlige materiale, som giver frihed, vil det kunne give anledning til opstilling af nogle specifikke krav til systemet i form af en kravspecifikation. Denne aktivitet vil naturligt kunne foregå i specifikationsfasen:

Er det f.eks. et ikke-retligt krav, at systemet skal kunne anvendes over internettet med en almindelig browser, og et retligt krav, at en ansøger bliver identificeret, kan en løsning være, at der skal anvendes digital signatur.

Men dette løsningsforslag⁶⁶⁹⁾ må sammenholdes med det retlige materiale, som afstikker grænser, således at der kan blive taget stilling til, om den konkrete løsning holder sig inden for disse grænser. Eksempelvis kan det være nødvendigt at sammenholde forslaget om anvendelse af digital signatur med et krav i det relevante retsgrundlag om, at en ansøgning skal være underskrevet. Mens konfrontation af det frihedsskabende retlige materiale med de ikke-retlige krav naturligt må finde sted i en specifikationsfase, synes det mere oplagt at henlægge konfrontationen med det grænseafstikkende retlige materiale til en valideringsfase. Dette giver to muligheder. Enten kan valideringen foregå, når der blot er udformet en specifikation af systemet,

eller valideringen kan foregå, når denne specifikation har givet anledning til et kørende program

Hvornår den ene og den anden model er mest hensigtsmæssig, diskuteres nedenfor i afsnittet "kontrol".

Konfrontationen med det retlige materiale, som afstikker grænser, vil kunne bringe for dagen, at den skitserede systemløsning ikke holder sig inden for grænserne. Der må da tages stilling til, om man vil acceptere løsningen eller ej. Accepteres løsningen ikke, vil det være nødvendigt at udvikle en ny løsning. Det betyder, at der kan blive behov for iteration.

Konfrontationen af det retlige materiale, som giver frihed, med de ikke-retlige krav sker i specifikationsfasen. Som udgangspunkt må alle retlige krav og ikke-retlige krav konfronteres på én gang. I praksis er det imidlertid nok mere hensigtsmæssigt at konfrontere færre krav ad gangen. Ellers kan arbejdet blive meget uoverskueligt. Ulempen ved kun at konfrontere færre krav ad gangen er imidlertid, at de løsninger som skabes på grundlag af et mindre antal krav, vil kunne vise sig at komme i konflikt med de resterende krav.

Under konfrontationen skal der skabes gode idéer. Man vil her kunne drage nytte af traditionelle systemudviklingsteknikker såsom synspunktsorienteret fremfindelse af krav, scenarier og etnografi. Men mere hensigtsmæssigt er det nok at udnytte, at der deltager personer med forskellig baggrund i systemudviklingsprocessen. En konfrontation vil således kunne foregå som en dialog mellem de deltagende jurister og teknikere. Under konfrontationen vil det være hensigtsmæssigt at lade juristerne administrere de retlige krav og teknikerne de ikke-retlige.

Retlig status quo

Hvor man ikke ønsker retlig innovation - eller ikke er klar over, på hvilke områder man ønsker retlig innovation - vil indgangsvinklen være et retligt materiale, som afstikker grænser. Et materiale, som afstikker grænser, er gældende ret. Prøvelse kan også bidrage med et materiale, som afstikker grænser. Det vil imidlertid næppe være specielt anvendeligt i denne situation, da grundlaget hænger snævert sammen med hele prøvelsesprocessen, som kræver, at der foreligger en prøvelsesgenstand.

Til systemet vil også foreligge nogle ikke-retlige krav. For at kunne finde frem til, hvilke retlige krav der er realisable, vil det være nødvendigt at tage højde for disse. De retlige og ikke-retlige krav vil naturligt kunne konfronteres i specifikationsfasen. Resultatet af fasen vil herefter være en kravspecifikation, som består af retlige og ikke-retlige krav, som er bragt i harmoni med hinanden. F.eks. kan det være et ikke-retligt krav, at systemet skal kunne bruges over internettet under anvendelse af almindelige browsere og mail-klienter. Er det et retligt krav, at en afgørelse skal meddeles en ansøger, kan disse krav bringes i harmoni med hinanden ved at stille krav om, at systemet sender afgørelsen i en e-mail til ansøgeren.

Man kan imidlertid også forestille sig den situation, at ét eller flere af de retlige krav ikke harmonerer med de ikke-retlige krav. Herefter foreligger to muligheder. Man kan opgive at udvikle systemet, eller man kan forsøge at få ændret på de retlige krav⁶⁷⁰⁾. Denne aktivitet vil derfor kunne anvendes i en systemudviklingsproces til at finde frem til områder, hvor det kan være nødvendigt med retlig innovation for at få realiseret systemet. F.eks. kan det være et ikke-retligt krav, at der skal anvendes almindelige browsere, og det kan være et retligt krav, at en ansøgning skal underskrives. Når man ved fortolkning frem til, at dette krav må forstås således, at der skal foreligge en sædvanlig underskrift skrevet med kuglepen eller lignende skriveredskab, foreligger der en konflikt mellem de ikke-retlige og retlige krav. Der vil derfor kunne være en pointe i at udføre aktiviteten før den aktivitet, som udføres med henblik på at skabe retlig innovation. Derved vil der kunne findes områder, som kan udgøre grundlaget for den retlige innovation.

Der vil som nævnt kunne være tilfælde, hvor der opstår en decideret konflikt mellem retlige og ikke-retlige krav, forstået på den måde, at det ikke vil være muligt at finde en løsning, som vil kunne tilfredsstille både retlige og ikke-retlige krav. Men selvom der ikke er konflikt mellem retlige og ikke-retlige krav, kan man overveje at udskille nogle af disse retlige krav til innovativ behandling. Der vil særligt have mening, hvor man bliver opmærksom på, at der gives nogle tekniske muligheder, som vil kunne anvendes til at befordre mere hensigtsmæssige retlige løsninger. F.eks. kan det blive bragt for dagen, at det er teknisk enkelt at give en begrundelse for en afgørelse, hvilket kunne føre til et forslag om at begrunde også i tilfælde, hvor en afgørelse giver den pågældende borger fuldt ud medhold. Man kunne også blive opmærksom på, at det er så billigt at lade en computer træffe en afgørelse, at man vil overveje at stille krav om bedre vejledning, hvilket kunne føre til et innovativt forslag om vejledning i form af simulerede afgørelser. En ledetråd for udskillelsen vil som nævnt i kapitel 4 kunne være, om de retlige krav hører til de processuelle regler.

Som udgangspunkt bør der som ved konfrontationen beskrevet ovenfor ske konfrontation af alle krav på én gang. Men også her vil det nok i praksis være hensigtsmæssigt at betragte et begrænset antal krav ad gangen.

I denne fase er det ikke meningen, at der skal ske nogen innovation. Men også her synes en anvendelig strategi at være at lade juristerne administrere de retlige krav og teknikerne de ikke-retlige og få konstateret eventuelle konflikter i en dialog mellem disse parter.

Det er tilstrækkeligt at gennemføre denne aktivitet én gang, for at aktiviteten kan give et endeligt bidrag i form af harmoniserede krav til den videre systemudvikling. Men man kan også vælge at konfrontere udvalgte krav ad gangen, hvilket kan afstedkomme et behov for gentagelse.

Integrations- og kommunikationsvinkel

Integrationsproblemet tænkes løst ved at tilstræbe enkelhed, hvor jurister og teknikere mødes i systemudviklingsprocessen⁶⁷¹⁾. Kommunikationsproblemet tænkes derimod løst ved at anvende kendte faglige tilgangsvinkler og etablere kontrol. De kendte faglige tilgangsvikler er der taget højde for gennem de elementer, som indgår i syntesen. Tilbage resterer derfor at se på henholdsvis enkelhed og kontrol.

Enkelhed

Der er sat fokus på det retlige. Genstanden for bestræbelserne på at skabe enkelhed må derfor angå det retlige materiale. Retligt materiale indgår i specifikationsfasen og valideringsfasen i tre forskellige situationer. Der må ses på hver af disse situationer, når det skal vurderes, i hvilket omfang det retlige materiale kan bibringes enkelhed:

I denne situation anvendes et retligt materiale, som giver frihed. Et sådant materiale vil typisk ikke være så komplekst som et materiale, der afstikker grænser. Derfor er der næppe behov for at foretage specielle forsøg på at gøre materialet mere enkelt.

I denne situation vil et spejlende materiale kunne bruges. Når materialet skal anvendes i specifikationsfasen vil det være mest hensigtsmæssigt, hvis det har en generel karakter. Såfremt det er tanken, at aktiviteten kun skal udføres én gang, er det nødvendigt, at der tages højde for alle retlige krav. Et partielt udsnit af retskilderne vil derfor ikke kunne anvendes. Det vil det derimod, hvis aktiviteten udføres flere gange. I et iterativt forløb kunne man f.eks. forestille sig, at man først opbyggede en prototype på grundlag af loven, og dernæst forfinede dette system ved hjælp af øvrige relevante retskilder. Traditionel systematik og kronologi vil også kunne anvendes.

I denne situation synes det mest nærliggende at anvende traditionel systematik eller kronologi som grundlag for forenklingsbestræbelserne. Men det kan også overvejes, om der ikke vil kunne være fordele forbundet med at anvende et spejlende materiale eller et partielt retskildegrundlag. Ved en kontrolaktivitet vil der ikke være de samme betænkeligheder ved at anvende et partielt retskildegrundlag som ved en specifikation af systemet, idet en fuldstændig test alligevel ikke vil være hverken praktisk eller teoretisk mulig⁶⁷²⁾.

Kontrol

Skal der foretages en kontrol, må dette naturligt kunne ske i valideringsfasen. En kontrol må kræve et valideringsgrundlag - svarende til et prøvelsesgrundlag - og en valideringsgenstand - svarende til en prøvelsesgenstand. Valideringsgrundlaget må udgøres af et materiale, som afstikker grænser. Her vil man som udgangspunkt kunne vælge blandt det retlige materiale, som er nævnt ovenfor.

I princippet ville man også kunne lade valideringsgrundlaget udgøre af kravspecifikationen. Den bør jo afspejle de grænser, som er afstukket af de retlige og ikke-retlige krav til systemet. Gør man det, vil der blive tale om det, som Sommerville betegner en verifikation. I innovationstiltaget forudsættes imidlertid, at de fremfundne innovative løsninger skal sammenholdes med et materiale, som afstikker grænser. Vælger man nu udelukkende at foretage en kontrol med en kravspecifikation som valideringsgrundlag, får man ikke foretaget denne vurdering af de innovative forslag, idet de innovative forslag vil være indarbejdet i kravspecifikationen. Det vil derfor ikke være tilstrækkeligt at foretage en kontrol med kravspecifikationen som valideringsgrundlag. Der må - i Sommervilles terminologi - også finde en validering sted.

Valideringsgenstanden kan enten udgøres af en kravspecifikation eller et program.

Det ses, at de ydre rammer er de samme som ved afstikning af grænser i forbindelse med retlig innovation.

Valideringen kan foretages, hvor der kun er udarbejdet en specifikation. I dette tilfælde vil det kun være muligt at foretage en inspektion. Hvor der er udarbejdet et program på tidspunktet for valideringen, vil der også kunne foretages en programtest. For at validere kravspecifikationen frem for et program taler, at man herved kan undgå at implementere idéer, som viser sig ikke at kunne anvendes. Mod taler, at det kan være enklere at forholde sig til et kørende program.

En validering vil kunne foretages af de interne deltagere i systemudviklingen. I dette tilfælde vil det både kunne have mening at foretage inspektion og programtest. Hvor der er tale om interne deltagere, må valideringsgrundlaget være gældende ret. Hvor valideringen foretages af et prøvelsesorgan, vil der som udgangspunkt også både kunne foretages inspektion og programtest. Her kommer imidlertid spørgsmålet om habilitetsproblemer ind i billedet. Som nævnt kan det i den forbindelse have betydning, hvor generelt det som testes er. En programtest balancerer på kanten af det konkrete. Der er således blot tale om, at faktum ikke er aktualiseret. Derimod vil en inspektion typisk angå et materiale, som har en mere generel karakter. Et prøvelsesorgan bør derfor nok i almindelighed udelukkende foretage inspektioner.

Tager man udgangspunkt i den af Gilb beskrevne metode, vil en produktinspektion kunne foretages med kravspecifikationen som produktdokumentet og ved at lade kildedokumentet udgøre af gældende ret eller det prøvelsesgrundlag, som det eventuelle prøvelsesorgan anvender. Metoden modificeres altså derved, at kildedokumentet ikke nødvendigvis eksisterer som et egentligt dokument. En inspektion vil også kunne foretages med programkoden som produktdokument. Et prøvelsesorgan bør imidlertid nok afholde sig fra inspektion af programkoden, da en sådan aktivitet tangerer det konkrete.

Gilbs metode vil givetvis kunne anvendes som den er, såfremt det er interne deltagere i systemudviklingen, der anvender den. Hvis der derimod er tale om eksterne deltagere, kunne man overveje, om det ikke er spild af et eksternt organs tid, hvis det i forbindelse med udførelsen af den første fase bliver konklusionen, at dokumentet indeholder så mange fejl, at det bedre vil kunne betale sig at lade forfatteren af dokumentet tage sig af disse, inden det underkastes en inspektion. Vægtigere er dog det argument, at hvis man skal have tillid til en kontrol, må det så vidt muligt være kontrolorganet, som har herredømme over genstanden for kontrollen.

·

Kan de retlige krav til systemet beskrives som logiske regler⁶⁷³⁾, vil det have mening at udføre en programtest med testdata, konstrueret med udgangspunkt i den af Beizer beskrevne metode. Da vil reglerne nemlig kunne omformes til en beslutningstabel.

Beizers udgangspunkt for konstruktion af testdata er som nævnt kravspecifikationen. Hvis en kontrol også skal indebære en validering af de innovative forslag, vil en kravspecifikation som anført ikke kunne udgøre valideringsgrundlaget⁶⁷⁴⁾. Selvom man selvfølgelig kan henlægge valideringen af de innovative forslag til inspektionen, vil Beizers metode blive modificeret således, at valideringsgrundlaget udgøres af det materiale, som ovenfor er beskrevet som afstikkende grænser. Som følge af de nævnte mulige habilitetsproblemer, vil det i praksis alene kunne være gældende ret.

Anvendes Beizers strategi for konstruktion af testdata, skal man sikre, at alle mulige kombinationer afprøves⁶⁷⁵⁾. Det indebærer, at det retlige materiale, som afstikker grænser, skal omformes til logik. Beizer beskriver, hvordan dette kan gøres for så vidt angår engelske beskrivelser⁶⁷⁶⁾. Opgaven vil nok i almindelighed være mindre besværlig, end når der er tale om en generel specifikation, idet retsregler i almindelighed må antages at indeholde færre flertydigheder. Men dermed ikke sagt, at det altid er en enkel opgave⁶⁷⁷⁾.

Det kan være nødvendigt at gentage valideringsfasen, hvis resultatet bliver, at der må udarbejdes en ny kravspecifikation.

En samlet udviklingsmodel

Som beskrevet vil det forløb, som sikrer retlig status quo, kunne give anledning til, at der udpeges områder, som skal underkastes retlig innovation. Derfor vil det være hensigtsmæssigt at placere disse faser i rækkefølge. Når der er udarbejdet en kravspecifikation eller et program, må der dernæst finde en validering sted. Denne validering vil blive betegnet kontrol. En samlet model vil derfor kunne se således ud:

Dette forløb kan blot gennemløbes én gang, eller man kan vælge et iterativt forløb, hvor man gentager hele forløbet flere gange i forbindelse med en prototypeudvikling. Foretages en sådan iteration, kan man overveje at undlade at udføre fasen design og implementering i den eller de første iterationer og alene vurdere kravspecifikationen.

Indholdet af de enkelte faser kan nærmere beskrives som følger:

I fasen retlig status quo skal de retlige krav konfronteres med de ikke-retlige. Denne aktivitet vil i datalogiske termer blive betragtet som en del af en specifikationsfase.

Ved konfrontationen kan materialet forenkles ved brug af spejlende materiale, traditionel systematik og kronologi. Hvor aktiviteten gentages, vil man også kunne anvende et partielt retskildegrundlag.

I fasen retlig innovation dannes først et retligt materiale, som giver frihed. Dette konfronteres herefter med de ikke-retlige krav. Disse aktiviteter vil i datalogiske termer også blive betragtet som en del af en specifikationsfase.

I fasen skal der på grundlag af de retlige krav dannes et materiale, som kan give frihed. Det kan ikke udelukkes, at de retlige krav, som ønskes forberedt for innovation, i sig selv har så mange frihedsgrader, at de vil kunne anvendes, som de er. I andre tilfælde må der imidlertid noget mere til. Når udgangspunktet er en række retlige krav, er det umiddelbart Stuer Lauridsens metode, som påkalder sig opmærksomhed. Hos Stuer Lauridsen tager den retspolitiske aktivitet netop afsæt i en række retlige krav, hvoraf der udledes nogle hensyn, som har mange frihedsgrader. Men også de mål, som Ross beskriver er grundlaget for de retspolitiske forslag, vil kunne spille en rolle. Eller de mål, som retssikkerhedshensyn og -krav eller tilsvarende databeskyttelsesretlige afspejler. For at få de sidstnævnte mål frem i lyset, kan man beskrive et område (et domæne), som det pågældende retlige krav regulerer, og herefter finde ud af, hvilke mål som vil kunne sættes for dette område, som enten har politisk rygdækning eller som har et retssikkerhedsmæssigt, persondatabeskyttelsesretligt eller lignende fundament. Herved vil der også kunne sættes mål, som de pågældende retlige krav ikke honorerer.

I fasen kontrol vil det være mest hensigtsmæssigt, at et prøvelsesorgan kun tester kravspecifikationen, mens de interne deltagere vil kunne teste både kravspecifikation og program. Disse aktiviteter vil i datalogiske termer blive betragtet som en del af en valideringsfase.

Ved kontrollen vil kunne anvendes et partielt udsnit af retskilderne, et spejlende materiale, eller et materiale opdelt på grundlag af traditionel systematik eller kronologi.

·

Betingelsen for at aktiviteterne i de tre nævnte faser vil kunne finde sted er, at det forinden er fastlagt, hvilke retlige og hvilke ikke-retlige krav, der stilles. Det kræver bl.a. en stillingtagen til, hvilket område systemet skal dække.

På et tidspunkt bliver det også nødvendigt at tage stilling til, hvilke arbejdsprocesser der skal udføres manuelt, og hvilke der skal automatiseres. En stillingtagen til dette problem vil i princippet kunne ske før systemudviklingsprocessen igangsættes. Men i praksis kan det vise sig nødvendigt at flytte grænserne på et senere tidspunkt. Midt i systemudviklingsprocessen kan man eksempelvis blive klar over, at der skal foretages en skønsmæssig afgørelse, som det vil være umuligt at få systemet til at foretage med de givne tekniske begrænsninger.

Om systemudviklingen skal omfatte en udvikling af manuelle procedurer må bero på et valg i det konkrete udviklingsprojekt. Umiddelbart synes det realistisk at antage, at den beskrevne systemudviklingsmetode også vil kunne håndtere manuelle elementer.

668) Når der i det følgende eksempelvis henvises til, at retspolitik vil kunne bidrage med et materiale som giver frihed, sigtes til de retspolitiske mål/hensyn, som kommer for dagen i forbindelse med udøvelse af retspolitisk virksomhed. Tilsvarende for så vidt angår henvisninger til gældende ret, retssikkerhed og prøvelse. 669) Som også kan betragtes som krav til systemet. 670) Da der er sat fokus på det retlige, overvejes ikke muligheden af at forsøge at få ændret på de tekniske krav. 671) Det forudsættes således, at der deltager både jurister og teknikere i systemudviklingsprocessen. 672) (Beizer 1990, s. 24ff). 673) Denne antagelse vil ikke altid være opfyldt. Eksempelvis er det svært at se, hvordan kravene til et skøn kan beskrives alene med dette hjælpemiddel. 674) Derimod vil der, med kravspecifikationen som grundlag, pr. definition kunne finde en verifikation sted. 675) (Beizer 1990, s. 328f). Men naturligvis kun inden for den ramme som udgøres af valideringsgrundlaget. Dette valideringsgrundlag kan godt udelukkende bestå af et partielt retskildegrundlag. 676) (Beizer 1990, s. 353ff). 677) Den svarer således til at skulle repræsentere en retsregel i et logiksprog, jfr. herved (Zeleznikow et al. 1994).