KAPITEL 8

Systemudvikling

Målet i kapitel 3 til 6 var at udfinde nogle retlige elementer, som kan antages at udgøre en bestanddel af juristernes faglige ballast. På tilsvarende vis er målet i dette kapitel at udfinde nogle datalogiske elementer, som kan antages at udgøre en bestanddel af teknikernes faglige ballast. Kilden er igen et mindre antal litteratursteder, som skønnes at afspejle, hvad der er konsensus om blandt teknikere.

Systemudvikling er en datalogisk disciplin, som beskriver strukturerede metoder for, hvordan man kan udvikle computersystemer⁵⁶⁹⁾. Disciplinen har hentet inspiration i traditionel ingeniørvidenskab, men har siden 70'erne udviklet sig til at være en selvstændig datalogisk disciplin⁵⁷⁰⁾.

Der er ikke tale om nogen eksakt videnskab. De metoder som disciplinen har skabt, må betragtes som gode heuristikker ("best practise"). Systemudvikling er derfor snarere et håndværk end en videnskab⁵⁷¹⁾. Der findes derfor heller ikke kun én systemudviklingsmetode. Forskellige forfattere har givet deres bud på, hvad de betragter som den bedste metode. Men alle metoder har dog visse grundlæggende fællestræk.

I det følgende vil der blive taget udgangspunkt i fællestrækkene, og dernæst givet eksempler på variationen inden for denne ramme. Beskrivelsen vil blive foretaget ud fra to synsvinkler. Først anlægges en aktivitetsvinkel. Under denne ses på, hvilke arbejdsopgaver en systemudvikling kan bestå af. Dernæst anlægges en tidsfølge- og gentagelsessynsvinkel, under hvilken der ses på, hvornår disse arbejdsopgaver skal løses. Endelig vil der på baggrund af beskrivelsen blive opstillet en syntesemodel til brug for sammenvævningen af de datalogiske og retlige elementer.

Aktiviteter i systemudviklingen

Alle systemudviklingsmetoder beskriver en række afgrænsede aktiviteter, hvis udførelse bidrager til det færdige system. Hver af disse afgrænsede aktiviteter har ét eller flere bestemte formål. Selvom der ofte er enighed om, hvilke aktiviteter, der alt i alt skal udføres i et systemudviklingsforløb, er der ikke altid enighed om, hvordan de forskellige aktiviteter skal grupperes under ét eller flere formål. Her vil beskrivelsen af de enkelte aktiviteter blive foretaget på grundlag af den kategorisering, som Ian Sommerville anvender⁵⁷²⁾:

• Specifikation
• Design og implementering
• Validering
• Evolution

Hver af disse aktivitetsforløb betegnes i almindelighed faser. Resultatet af en fase betegnes et faseprodukt⁵⁷³⁾.

Det overordnede mål for specifikationsfasen er at nå frem til en beskrivelse af, hvilke krav systemet skal opfylde. I design- og implementeringsfasen er målet på grundlag af denne beskrivelse at nå frem til en måde, hvorpå disse krav kan honoreres. Der foretages en beskrivelse af opbygningen af et system (designfasen), og på grundlag heraf foretages en programmering af dette system (implementeringsfasen). Valideringsfasen anvendes som betegnelse for aktiviteter, hvor det overordnede mål er at foretage en vurdering af de resultater, som de andre faser giver anledning til⁵⁷⁴⁾. Betegnelsen kan dog også reserveres for de aktiviteter, som indebærer en vurdering af det udviklede system, altså alene det endelige resultat af design- og implementeringsfasen. I evolutionsfasen er målet at foretage ændringer af systemet, enten fordi det ikke lever op til tidligere stillede krav, eller fordi der efter udviklingen af systemet er opstået nye krav, som det findes nødvendigt, at systemet skal leve op til.

Specifikation

Målet i specifikationsfasen er at finde frem til, hvad systemet skal kunne. Derimod skal der ikke i denne fase tages stilling til, hvordan systemet skal konstrueres for at kunne leve op til disse krav⁵⁷⁵⁾. Sidstnævnte aktivitet er henlagt til designfasen. Mere anskueligt kan forskellen mellem specifikationsfasen og designfasen formuleres således, at i specifikationsfasen ser man på systemet udefra, mens man i designfasen ser på systemet indefra. I specifikationsfasen opstilles krav, der fastlægger systemets eksternt observerbare adfærd, mens designfasen tager udgangspunkt i de mulige tekniske konstruktioner og fastlægger, hvordan kravene realiseres på den tekniske platform⁵⁷⁶⁾. Resultatet af specifikationsfasen er en beskrivelse af, hvad systemet skal kunne - en kravspecifikation⁵⁷⁷⁾.

I specifikationsfasen anvendes forskellige teknikker. Et fællestræk er, at de tilstræber at spalte den stillede opgave op i mere overskuelige dele. Dele som hver især består af arbejdsopgaver, som det er hensigten skal kunne løses hver for sig. Det er målet, at kravspecifikationen både skal være komplet og konsistent⁵⁷⁸⁾, men vejen hertil går over en opdeling af den tilgrundliggende problemstilling.

Denne opdelingsstrategi finder anvendelse allerede ved indhentelse af krav. Således kan der f.eks. foretages en opdeling af krav i funktionelle og ikke-funktionelle krav⁵⁷⁹⁾. Funktionelle krav angår de funktioner, systemet skal kunne tilbyde. Hvordan det skal reagere i forskellige situationer. Ikke-funktionelle krav er krav til de funktioner, som systemet udfører. Det kan være tidsmæssige krav, standarder etc. Ikke-funktionelle krav kan også være tekniske begrænsninger, såsom f.eks. I/O-enheders ydeevne⁵⁸⁰⁾. Også når kravene skal samles i en kravspecifikationen, vil man typisk foretage en opdeling. Man vil således kunne foretage både en beskrivelse af brugerkrav ("user requirements") og en beskrivelse af systemkrav ("system requirements"). Beskrivelsen af brugerkrav skal kunne forstås af brugere⁵⁸¹⁾ af systemet, som ikke har specielle tekniske forudsætninger⁵⁸²⁾. Beskrivelsen af systemkrav er en mere detaljeret beskrivelse af brugerkravene⁵⁸³⁾.

To grundlæggende aktiviteter vil i almindelighed blive udført for at systemkravene i kravspecifikation kan opstilles: foranalyse⁵⁸⁴⁾ ("feasibility studies") samt kravfremfindelse og -analyse⁵⁸⁵⁾.

Foranalysen har bl.a. som mål at undersøge, om der i det hele taget er behov for at udvikle et system, og i givet fald hvad systemet skal understøtte, og hvad ikke⁵⁸⁶⁾.

Kravfremfindelse og -analyse har som formål at fremfinde de relevante krav til systemet og foretage en nærmere analyse af disse. Kravfremfindelse kan f.eks. foregå ved synspunktorienteret fremfindelse, scenarier og etnografi. Et væsentligt værktøj udgøres også af prototypeudvikling⁵⁸⁷⁾. En prototype er en foreløbig version af systemet⁵⁸⁸⁾. En prototype vil således kun leve op til nogle af de krav, der stilles til det endelige system. En sådan prototype kan gøre det lettere at blive klar over, hvilke (yderligere) krav, der skal stilles til systemet, idet det ofte vil være enklere at forholde sig til et kørende system end til en tekstuel eller grafisk beskrivelse af et system⁵⁸⁹⁾.

Ved analysen anvender man i vidt omfang modellering. Dette er også tilfældet i designfasen, og modellering beskrives derfor samlet nedenfor. En anden væsentlig aktivitet i denne fase er konfliktløsning⁵⁹⁰⁾. Såfremt forskellige krav til systemet er i disharmoni, må der træffes beslutning om, hvordan konflikten skal løses.

Design og implementering

Målet for design- og implementeringsfasen er at beskrive, hvordan systemet skal konstrueres, og på grundlag heraf at konstruere systemet.

Også i designfasen opdeles problemet i mindre, mere overskuelige dele. Dekompositionen foregår skridtvis. Når der foretages arkitektonisk design ("architectural design") af systemet, vil man først opdele systemet i delsystemer⁵⁹¹⁾. Disse delsystemer opdeles herefter igen i mindre dele, moduler⁵⁹²⁾.

Modellering i specifikations- og designfasen

Både i specifikationsfasen og designfasen anvendes sædvanlige sproglige beskrivelser. Men derudover anvendes modeller. En model er karakteriseret ved, at den kun fokuserer på udvalgte dele af et problem eller dets løsning⁵⁹³⁾. En model er således en abstraktion⁵⁹⁴⁾. En model vil typisk fremtræde i grafisk form, men kan også helt eller delvist bestå af tekst.

I forbindelse med analyse og design har særligt to tilgange været anvendt. Det drejer sig om struktureret og objektorienteret analyse/design. Struktureret analyse og design havde sin storhedstid i 70'erne og starten af 80'erne⁵⁹⁵⁾. Disse teknikker har særlig en berettigelse i forbindelse med brugen af funktionsorienterede programmeringssprog som f.eks. Cobol og Fortran. Herefter har objektorienteret analyse og design gjort sit indtog. Disse teknikker knytter specielt an til objektorienterede programmeringssprog som f.eks. C++ og Java.

Disse tilgange anvender forskellige modeller. I struktureret analyse og design har man traditionelt fokuseret på funktioner, data og datastrømme⁵⁹⁶⁾, mens man i objektorienteret analyse og design fokuserer på objekter, tilstande og adfærd⁵⁹⁷⁾. I struktureret analyse og design spiller dataflowdiagrammet derfor en stor rolle⁵⁹⁸⁾, mens klassediagrammet spiller en tilsvarende betydelig rolle i forbindelse med objektorienteret analyse og design⁵⁹⁹⁾. Selvom man kan hævde, at objektorienteret analyse blot er en udvidelse af funktionsorienteret analyse⁶⁰⁰⁾, afspejler de to modeller en grundlæggende forskellig tilgang til dekompositionen⁶⁰¹⁾.

I det følgende vil der blive beskrevet eksempler på dele af den modellering, som kan foretages ved anvendelse af hver af de to tilgange. Der ses alene på modellering i analysefasen. For så vidt angår den funktionsorienterede analyse tages der udgangspunkt i den metodevariant, som er beskrevet hos Yourdon⁶⁰²⁾, mens der for så vidt angår den objektorienterede analyse tages udgangspunkt i Lars Mathiassen et al.'s beskrivelse⁶⁰³⁾. Netop disse varianter er valgt, fordi beskrivelserne er meget handlingsorienterede. Eksemplerne tjener alene det formål at vise, at aktiviteter i specifikationsfasen (analysefasen) kan indebære skabelsen af vidt forskellige modeller.

Struktureret analyse

Modeller baseret på dataflowdiagrammer er centrale i den funktionsorienterede tilgang. At modellerne anvendes som led i en opspaltningsstrategi illustreres af, at de dataflowdiagrammer, som udarbejdes i analysefasen, også kan udgøre grundlaget for opdelingen af systemet i moduler i designfasen⁶⁰⁴⁾.

Når der skal konstrueres et dataflow-diagram, anbefaler Yourdon at tage udgangspunkt i en hændelsesliste ("event list")⁶⁰⁵⁾. En sådan liste er en tekstuel beskrivelse af de hændelser eller stimuli i omgivelserne, som systemet skal kunne reagere på, og en angivelse af, hvilken person eller system som genererer denne hændelse⁶⁰⁶⁾. Som et eksempel på en sådan liste for et hospitalssystem nævner Yourdon⁶⁰⁷⁾ (i udvalg):

1. Patient joins Nephrology Service
2. Doctor request scheduling of initial treatments
3. Patient signs release form (or not)
4. Supervisor needs test schedule
5. Lab produces test results
6. Patient needs to be weighed

For hver hændelse på listen tegnes en procesboble⁶⁰⁸⁾. Boblen navngives i overensstemmelse med den handling, systemet skal udføre som reaktion på hændelsen. Herefter indtegnes de oplysninger, som er nødvendige for den proces, som den pågældende procesboble repræsenterer, og de resultater, som processen giver. Desuden indtegnes de datalagre, som anvendes i forbindelse med kommunikationen mellem forskellige processer. Dette DFD kan herefter reorganiseres, om nødvendigt i flere niveauer⁶⁰⁹⁾.

Yourdon giver bl.a. følgende eksempel på et DFD⁶¹⁰⁾:

Objektorienteret analyse

Modeller baseret på klassediagrammer er centrale i den objektorienterede metode. At også disse modeller anvendes som led i en opspaltningsstrategi illustreres af, at opdelingen i klasser i analysefasen⁶¹¹⁾ kan danne grundlag for de klasser, systemet konstrueres med i designfasen⁶¹²⁾.

Et klassediagram fremkommer ifølge Mathiassen et al. som resultat af en aktivitet, som først består i at udvælge objektsystemets bestanddele gennem en klassificering⁶¹³⁾, og dernæst i at ordne disse bestanddele i en sammenhængende helhed⁶¹⁴⁾.

Målet med klassificeringen er at finde objekter i det område, som er genstand for systemudviklingen. Et objekt er under analysen en abstraktion over et konkret fænomen. Objektet udgør derfor en model af en del af virkeligheden. Som eksempel på sådanne objekter nævner Mathiassen et al. en bankkunde og en aftale.

Et objekt defineres af Mathiassen et al. som en helhed med identitet, tilstand og adfærd⁶¹⁵⁾. At et objekt er en helhed betyder, at det må være noget i sig selv. Identiteten er en egenskab, der adskiller objektet fra alle andre objekter. Et objekts tilstand er de statiske egenskaber, som kendetegner objektet, og de dynamiske eller statiske værdier, som er tilordnet disse egenskaber. Mathiassen et al. nævner som eksempel, at de statiske egenskaber ved en kunde i en bank kan være et navn og et personnummer. For en bestemt kunde vil disse egenskaber være tilordnet bestemte værdier. Endelig er et objekts adfærd de hændelser, som objektet aktivt udfører eller passivt påføres i dets livsforløb. Som eksempel nævner Mathiassen et al., at en bankkundes adfærd er den konkrete sekvens af kontoåbninger og -lukninger og transaktioner, som kunden har udført, siden vedkommende første gang kom ind i banken⁶¹⁶⁾.

Når objekter skal lokaliseres i det område, som er genstand for systemudviklingen, kan der anvendes forskellige teknikker. Grundlæggende ledes der ikke direkte efter objekter, men efter klasser, som defineres som en beskrivelse af en mængde af objekter med samme struktur, adfærdsmønster og attributter⁶¹⁷⁾. Mathiassen et al. anviser bl.a. følgende heuristikker til at finde egnede klassekandidater⁶¹⁸⁾:

• Fokusering på substantiver i brugernes beskrivelse af deres arbejde
• Betragtning af checklister med generelle typer af klasser (eks. fysiske ting, personer og roller, apparater etc.)
• Betragtning af klasser anvendt i tilsvarende IT-systemer
• Betragtning af faglitteratur, som ofte vil indeholde omfattende klassificeringer af problemområdet

Når der blandt disse kandidater skal udvælges klasser anvendes ifølge Mathiassen et al. følgende kriterier⁶¹⁹⁾:

• Klassen skal afspejle et behov for registrering af information
• Klasser skal alene bruges til at modulere den del af omgivelserne, der skal administreres, overvåges eller styres ved hjælp af systemet, ikke brugernes arbejde eller systemet
• Klassen bør omfatte flere objekter
• Klassen bør have en overskuelig mængde hændelser
• Klassen bør indeholde unik information, så objekter kan identificeres entydigt

Næste fase i arbejdet er herefter at finde strukturelle sammenhænge mellem klasser og objekter i objektsystemet. Disse strukturelle sammenhænge afbildes i et klassediagram⁶²⁰⁾. Mathiassen et al. omtaler fire forskellige former for strukturelle sammenhænge. For så vidt angår klasser tales om generaliseringer og klynger. For så vidt angår objekter tales om aggregeringer og associeringer⁶²¹⁾. Her skal alene omtales generaliseringsstrukturer. En generaliseringsstruktur er en relation mellem to eller flere klasser. Den udtrykker, at en eller flere klasser er specialtilfælde af en mere generel klasse⁶²²⁾. Mathiassen et al. nævner som eksempel, at bankbøger, checkkonti og lån udgør specialtilfælde af den mere generelle klasse konto⁶²³⁾. Desuden findes en servicekonto⁶²⁴⁾, som er et specialtilfælde af såvel checkkonto som lån.

Når disse strukturer skal findes, anviser Mathiassen et al., at man først skal udpege egnede kandidater⁶²⁵⁾. Dernæst skal disse kandidater vurderes ud fra forskellige kriterier⁶²⁶⁾. Genereringen af kandidater til generaliseringsstrukturer kan foregå ved for udvalgte par af klasser at overveje, om den ene klasse er en specialisering af den anden, det kan overvejes, om der kan findes en relevant generalisering for udvalgte klasser, og endelig kan der overvejes relevante generaliseringer og specialiseringer af udvalgte klasser⁶²⁷⁾. Kriterierne for vurdering af kandidaterne til strukturer er følgende⁶²⁸⁾:

• Strukturer skal fremme forståelse og overblik
• Strukturer skal være begrebstro
• Strukturer skal være enkle

Når relevante strukturer er udvalgt, kan de afbildes i et klassediagram. Et udsnit heraf kan f.eks. se ud som følger⁶²⁹⁾:

Validering

Målet for valideringsfasen er tvedelt. Det er dels at sikre, at systemet lever op til "kundens"⁶³⁰⁾ krav (validering), dels at sikre at det lever op til specifikationen (verifikation)⁶³¹⁾. En verifikation angår alene en vurdering på grundlag af de krav, der er at finde i kravspecifikationen, mens der i en validering inddrages krav, der supplerer eller er forskellige fra kravene i kravspecifikationen. Målestokken er ikke den samme.

Udgangspunktet er, at validering og verifikation angår det færdige system. Men også tidligere faseprodukter vil kunne gøres til genstand for en undersøgelse⁶³²⁾. De tidligere faseprodukter udgør således mere eller mindre færdige repræsentationer af det endelige system. Resultatet af processen kan alene være en konstatering af, at systemet er i harmoni med målestokken. Men ofte vil processen blive kombineret med, at man vil rette eventuelle konstaterede fejl ("debugging")⁶³³⁾.

Teknikkerne kan overordnet inddeles på grundlag af, hvad der er genstand for valideringen eller verifikationen. Inspektioner angår repræsentationer af systemet, mens programtest angår det kørende system⁶³⁴⁾. Inspektioner vil kunne foretages både tidligt og sent i forløbet, idet såvel f.eks. kravspecifikation som programkode vil kunne kontrolleres, hvorimod programtest pr. definition forudsætter et kørende system^{635) 636)}.

Inspektion

I det følgende gennemgås udvalgte dele af den metode til inspektion, som er beskrevet af Tom Gilb et al.⁶³⁷⁾. Metoden giver mulighed for inspektion af alle typer af faseprodukter, der har form af dokumenter. Inspektionen vil således kunne angå en kravspecifikation, et designforslag, testplaner, testdata, kildetekst osv.⁶³⁸⁾. En inspektion kan kun undersøge statiske dokumenter, ikke kørende programmer⁶³⁹⁾.

Formålet med en inspektion er at finde og rette fejl⁶⁴⁰⁾. Inspektionsprocessen består af to dele. En produktinspektion ("product inspection") og en procesforbedring ("process improvement")⁶⁴¹⁾. Formålet med produktinspektionen er at finde og rette fejl i det dokument, der er genstand for inspektionen⁶⁴²⁾. Formålet med procesforbedringen er at foreslå forbedringer til den proces, der har det pågældende produkt som resultat. Altså forslag til forbedring af selve systemudviklingsprocessen⁶⁴³⁾. Her vil der alene blive set på produktinspektionen.

Produktinspektionen består af tre grundlæggende faser: en initieringsfase ("initation"), en checkfase ("checking") og en rette- og opfølgningsfase ("completion").

Initieringsfasen indeholder tre aktiviteter: Først må der tages stilling til, om det i det hele taget vil kunne betale sig at foretage en inspektion. F.eks. kan det være, at dokumentet indeholder så mange små fejl eller en række større fejl, at det bedre vil kunne betale sig at lade forfatteren af dokumentet tage sig af disse, inden det underkastes en inspektion⁶⁴⁴⁾. Viser det sig, at det kan betale sig at foretage en inspektion, er næste skridt at planlægge inspektionen. Dette indbefatter bl.a. en stillingtagen til, hvem der skal foretage inspektionen, identificering af alt relevant materiale og opdeling af materialet⁶⁴⁵⁾. Endelig består den sidste aktivitet i at afholde et "kickoff"-møde, hvor alle deltagere i inspektionen samles, orienteres om deres opgaver og får udleveret relevant materiale⁶⁴⁶⁾.

I checkfasen er målet at få lokaliseret flest mulige fejl. Det dokument som skal checkes for fejl, betegnes produktdokumentet ("product document") og kan f.eks. være en kravspecifikation⁶⁴⁷⁾. Det primære dokument som produktdokumentet sammenholdes med, betegnes kildedokumentet ("source document") og kan f.eks. være en række krav⁶⁴⁸⁾. I prøvelsesterminologi kan produktdokumentet derfor betragtes som prøvelsesgenstanden, mens kildedokumentet kan betragtes som prøvelsesgrundlaget. Selve kontrollen finder sted først som en individuel og dernæst som en kollektiv kontrol. Under den individuelle kontrol foretager de enkelte deltagere i processen en kontrol. Hver deltager vil blive bedt om at se efter en bestemt type af fejl⁶⁴⁹⁾. Dette udelukker imidlertid ikke, at en deltager også kan lokalisere andre typer af fejl⁶⁵⁰⁾. Når den individuelle kontrol er foretaget, samles alle deltagere til et møde ("Logging Meeting"), hvor den kollektive kontrol foretages. På dette møde foretages bl.a. en registrering af de forhold - hvilket vil sige mulige fejl⁶⁵¹⁾ - de enkelte deltagere har lokaliseret samt af andre forhold, som måtte blive opdaget under mødet⁶⁵²⁾. På dette møde skal det derimod ikke diskuteres, om der vitterligt er tale om et problem, og hvordan dette i givet fald skal løses⁶⁵³⁾.

I rette- og opfølgningsfasen vil der først og fremmest blive foretaget rettelser i produktdokumentet. Dette kræver, at der foretages en opdeling af de registreringer deltagerne har gjort i henholdsvis ægte fejl, som skal rettes, og andre, som kræver anden handling⁶⁵⁴⁾. Denne aktivitet vil i almindelighed blive foretaget af forfatteren til det pågældende dokument⁶⁵⁵⁾. Afslutningsvis vil der i denne fase blive taget stilling til, om kvaliteten af dokumentet herefter er acceptabel⁶⁵⁶⁾.

Programtest

En programtest forudsætter, at der er adgang til en kørende version af systemet. Der må derfor være skrevet programkode, og denne kode skal være lagt ind i en computer, som kan afvikle koden. Arbejdet indebærer herefter, at programmet gennemkøres med nogle testdata, og at resultatet af kørslen sammenholdes med et testgrundlag.

Man skelner mellem to former for programtest. Ved "black-box testing" konstrueres testdata uden kendskab til indholdet af programkoden⁶⁵⁷⁾. Ved "white-box testing" konstrueres testdata derimod på grundlag af indholdet af programkoden⁶⁵⁸⁾. "White-box testing" vil f.eks. kunne udføres ved, at man forsøger at teste alle veje gennem programmet⁶⁵⁹⁾.

I det følgende vil blive beskrevet, hvordan testdata kan konstrueres i forbindelse med en metode til "black-box testing", som er beskrevet af Boris Beizer under navnet "logic-based testing"⁶⁶⁰⁾. Udgangspunktet er en (krav)specifikation. For at metoden skal kunne anvendes, er det en betingelse, at denne enten har form af en beslutningstabel eller vil kunne omformes til en sådan. De beslutningstabeller som Beizer beskæftiger sig med, har udseende af formen⁶⁶¹⁾:

Tabellen udtrykker, at såfremt betingelse 1 samt betingelse 2 er opfyldt og betingelse 3 samt betingelse 4 ikke er opfyldt, skal handling 1 udføres (regel 1). Såfremt betingelserne 1, 3 og 4 er opfyldt, og ligegyldigt om betingelse 2 er opfyldt eller ej, skal handling 1 udføres (regel 2). Og så fremdeles.

Metoden består af to aktiviteter⁶⁶²⁾: Der skal først konstrueres en beslutningstabel, som er konsistent og fuldstændig. Dernæst konstrueres testdata, som vil kunne vise, at programmet handler korrekt for alle kombinationer af betingelser.

Evolution

Målet for fasen er at foretage en vedligeholdelse af systemet. En sådan vedligeholdelse kan være nødvendiggjort af, at der er konstateret manglende overensstemmelse med de oprindelige krav til systemet, eller fordi der senere er opstået nye krav⁶⁶³⁾.

Tidsfølge og gentagelse

Inden for systemudvikling findes der forskellige teorier om, hvornår de enkelte faser skal udføres. Traditionelt har man anvendt en model, som betegnes vandfaldsmodellen, hvor man udfører faserne én gang i rækkefølge:

specifikation ® design og implementering ® validering ® evolution

Denne traditionelle model er imidlertid blevet udfordret, idet der findes systemudviklingsmodeller, hvor faserne gentages én eller flere gange⁶⁶⁴⁾. Prototypeudvikling er et eksempel på et forløb, hvor faserne specifikation, design og implementering samt validering gennemløbes cyklisk.

Sammenfatning og opstilling af syntesemodel

Den grundlæggende teknik - eller måske snarere filosofi - bag eksisterende systemudviklingsteori synes at kunne sammenfattes i ordene del og hersk: "The technique of mastering complexity has been known since ancient times: Divide et impera (Divide and rule)."⁶⁶⁵⁾.

Denne filosofi kommer til udtryk ved, at man forsøger at undgå at arbejde med det samlede problemkompleks på én gang. I stedet opdeles systemudviklingsforløbet i en række faser som specifikation, design og implementering, validering samt evolution. Men også inden for disse faser foretages en opbrydning. Således er det som nævnt karakteristisk for specifikations- og designfasen, at man opstiller nogle modeller, som kun anlægger én synsvinkel på problemet eller dets løsning. I valideringsfasen anlægger man også forskellige synsvinkler på arbejdet. Således skelner man grundlæggende mellem en validering, hvor man foretager en programinspektion, og en validering, hvor man tester det kørende program⁶⁶⁶⁾. Disse opbrydninger - baseret på forskellige kriterier - er båret af et ønske om, at det så vidt muligt skal kunne lade sig gøre at arbejde med en del af problemet uden samtidigt at skulle være nødsaget til at bekymre sig om andre dele.

Når man herefter ser nærmere på, hvilke opbrydninger der foretages, bliver billedet broget. Der er derfor næppe heller nogen eviggyldige sandheder i disse opspaltninger. Der er tale om forskellige bud på løsning af den samme overordnede opgave. Det er således påvist, hvordan den opbrydning, som foretages i designfasen, kan basere sig på vidt forskellige aktiviteter i analysefasen. Dette er næppe et særtilfælde. Det må således antages, at det i almindelighed i vidt omfang vil være muligt at erstatte enkelte elementer i en metode med andre elementer.

Såfremt der skal sikres en genkendelighed hos teknikerne, vil der alt andet lige være størst chance for, at dette vil være muligt, hvis man bibeholder de overordnede inddelinger - om hvilke enigheden er størst - og kun foretager tilpasninger på de underliggende niveauer. Her synes der til gengæld også at være tradition for fornyelse og anvendelse af vidt forskellige kriterier for opbrydning.

I det følgende vil der blive arbejdet med tre overordnede elementer⁶⁶⁷⁾:

• Specifikation
• Design og implementering
• Validering

De modeller som vil blive taget i betragtning, bygger på, at disse elementer vil kunne placeres vilkårligt i forhold til hinanden, og at der vil kunne ske gentagelse af hele aktiviteten. Design- og implementeringsfasen vil der ikke blive gjort noget ud af, idet de tiltag, som betragtes i denne afhandling, ikke skønnes at kunne få lige så stor betydning i denne fase som i de andre. For så vidt angår de aktiviteter, som udføres i specifikationsfasen og i valideringsfasen, vil der alene blive fokuseret på følgende: I specifikationsfasen: opstilling krav og løsning af eventuelle konflikter mellem disse. I valideringsfasen: inspektioner og programtest i form af "black-box testing".

569) Et system defineres som en gruppe af komponenter, som arbejder sammen med henblik på at løse en bestemt opgave, (Sommerville 2001, s. 21). 570) Jfr. (Sommerville 2001, s. 11). 571) (Mathiassen 2001, s. 3). 572) (Sommerville 2001, s. 43). Blandt andre opdelinger kan f.eks. nævnes: kravspecifikation, analyse, logisk design, fysisk design, implementering og test samt vedligeholdelse, (Flynn 1998, s. 100). 573) Jfr. (Flynn 1998, s. 100). 574) Jfr. (Sommerville 2001, s. 420). 575) (Sommerville 2001, s. 109). 576) Jfr. (Mathiassen 1998, s. 4). 577) (Sommerville 2001, s. 98). 578) (Sommerville 2001, s. 101, s. 104 og s. 125). 579) Jfr. (Sommerville 2001, s. 100). 580) Jfr. (Sommerville 2001, s. 101). 581) Begrebet "brugere" er hyppigt anvendt i forbindelse med systemudvikling. Herved forstås de personer, som det nye system vil komme til at interagere med, jfr. (Mathiassen 2001, s. 13). 582) (Sommerville 2001, s. 106). 583) (Sommerville 2001, s. 109). 584) Betegnelsen er hentet fra (Delskov 1991, s. 29f). 585) (Sommerville 2001, s. 122). 586) (Sommerville 2001, s. 123). 587) (Sommerville 2001, s. 125). 588) (Sommerville 2001, s. 172). 589) Man sondrer mellem to former for prototyper, (Sommerville 2001, s. 174). "Throw-away" prototyper bruges alene til at støtte arbejdet med at få fastlagt en anvendelig kravspecifikation. Når det er sket, kasseres prototypen, og der opbygges et nyt system. Den evolutionære prototype udvides derimod gradvist, således at den i sidste ende vil kunne finde praktisk anvendelse. 590) (Sommerville 2001, s. 125). 591) (Sommerville 2001, s. 216). 592) (Sommerville 2001, s. 217). Der er ikke skarpe skillelinier mellem delsystemer og moduler, (Sommerville 2001, s. 229). 593) (Sommerville 2001, s. 150). 594) (Rumbaugh 1991, s. 15). 595) (Sommerville 2001, s. 588). 596) Jfr. (Mathiassen 1998, s. 8). 597) Jfr. (Mathiassen 1998, s. 7). 598) Jfr. f.eks. (Yourdon 1988, s. 14). 599) Jfr. (Mathiassen 2001, kap. 4). 600) (Mathiassen 1998, s. 6). 601) Mere generelt kan man pege på, at struktureret analyse indfører en top-down-strategi, mens den objektorienterede analyse indfører en bottom-up-strategi. 602) I (Yourdon 1988). 603) Jfr. (Mathiassen 1998) og (Mathiassen 2001). 604) Jfr. (Yourdon 1988, s. 107). Se hertil specielt fig. 6.7 (a-b) og 6.8 (a-b). 605) (Yourdon 1988, s. 87). 606) (Yourdon 1988, s. 84). 607) (Yourdon 1988, s. 85). 608) Se (DeMarco 1978, s. 47ff) for en nøjere beskrivelse af notationen og konstruktionen af et DFD. 609) (Yourdon 1988, s. 87). Som et eksempel herpå kan betragtes det DFD, som er gengivet i bogens fig. 2.3. Dette DFD udgør (en del af) andet niveau af det DFD, som er gengivet som fig. 2.2. 610) (Yourdon 1988, s. 15). 611) Der som nævnt er en del af specifikationsfasen. 612) Jfr. (Mathiassen 2001, s. 229). 613) Jfr. (Mathiassen 2001, kap. 3). 614) Jfr. (Mathiassen 2001, kap. 4). 615) (Mathiassen 2001, s. 49). 616) (Mathiassen 2001, s. 50). 617) (Mathiassen 2001, s. 51). 618) (Mathiassen 2001, s. 54). 619) (Mathiassen 2001, s. 58f). Se hertil også (Booch 1997, s. 155ff). 620) Jfr. (Mathiassen 2001, s. 67). 621) (Mathiassen 2001, s. 67). 622) (Mathiassen 2001, s. 70). 623) (Mathiassen 2001, s. 81f). 624) Mathiesen et al. tænker givetvis på en kassekredit. 625) (Mathiassen 2001, s. 75). 626) (Mathiassen 2001, s. 81f). 627) (Mathiassen 2001, s. 76). 628) (Mathiassen 2001, s. 82ff). Ud over det nævnte anføres, at strukturerne skal anvendes rigtigt, (Mathiassen 2001, 3. udg. s. 82). 629) Jfr. (Mathiassen 2001, s. 72). 630) Hvem der er "kunde" synes ikke klart. Det afgørende er heller ikke personen, men at de krav som vurderingen bygger på, kan være nogle andre end dem, som fremgår af kravspecifikationen. 631) (Sommerville 2001, s. 420). 632) (Sommerville 2001, s. 420). 633) (Sommerville 2001, s. 422). 634) (Sommerville 2001, s. 420). 635) (Sommerville 2001, s. 420). 636) Sommerville gør en del ud af at skelne mellem, om man forsøger at finde fejl, eller om man forsøger at vise korrekthed, jfr. (Sommerville 2001, s. 442). Der vil ikke her blive gjort noget ud af denne sondring. Det må blot konstateres, at det ofte er vanskeligt at bevise korrekthed, hvorfor man tit må nøjes med at sandsynliggøre korrekthed ved at vise, at man forgæves har søgt efter fejl. 637) I (Gilb 1994). 638) (Gilb 1994, s. 8). 639) (Gilb 1994, s. 10). 640) (Gilb 1994, s. 8). Der er således tale om et eksempel på, at debugging kan være integreret i valideringsfasen. 641) (Gilb 1994, s. 31). 642) (Gilb 1994, s. 31 og s. 36). 643) (Gilb 1994, s. 37). 644) (Gilb 1994, s. 42). 645) (Gilb 1994, s. 42f). 646) (Gilb 1994, s. 67). 647) (Gilb 1994, s. 45). 648) (Gilb 1994, s. 46). Derudover omtales også regler ("rules"), som er anvisninger på, hvordan kildedokumentet skal transformeres til produktdokumentet, (Gilb 1994, s. 49), samt checklister ("checklister"), som er lister over forhold, som skal kontrolleres, (Gilb 1994, s. 58). 649) (Gilb 1994, s. 70). 650) (Gilb 1994, s. 77). 651) Jfr. (Gilb 1994, s. 96f). 652) (Gilb 1994, s. 81). 653) (Gilb 1994, s. 84). 654) (Gilb 1994, s. 98). 655) (Gilb 1994, s. 98). 656) (Gilb 1994, s. 106). 657) (Sommerville 2001, s. 443). Denne form for test kaldes også "functional testing", (Beizer 1990, s. 10). 658) (Sommerville 2001, s. 447). Denne form for test kaldes også "structural testing", (Beizer 1990, s. 2). 659) (Sommerville 2001, s. 450). 660) (Beizer 1990, s. 320ff). 661) Jfr. (Beizer 1990, s. 323, table 10.1). 662) (Beizer 1990, s. 328). 663) (Sommerville 2001, s. 605). 664) Derudover vil der også kunne finde gentagelse af aktiviteter sted inden for den enkelte fase. 665) (Dijkstra 1979, s. 5). Vel efter Niccolò Machiavelli. 666) Jfr. (Sommerville 2001, s. 420). 667) Der ses bort fra den evolutionære fase, som først kommer i spil, når systemet er i drift.