3. Hvordan foregår softwareudvikling i teorien?

I det følgende gennemgås nogle typiske systemudviklingsmodeller, som igennem tidens løb har været foreslået som redskaber i kampen mod softwarekrisen.

Blandt de mange muligheder er valgt Syskon, den strukturerede metode, prototype udvikling, den formalistiske metode samt objektorienteret systemudvikling.

De valgte systemudviklingsmodeller er naturligvis ikke dækkende for alle systemudviklingsmodeller; men de er især valgt, fordi de udgør et repræsentativt udsnit af de modeller, der igennem tiden er blevet foreslået.

Samtidig udgør de valgte modeller et repræsentativt tidsmæssigt udsnit af systemudviklingsmodeller.

3.1 Syskon

Syskon er navnet på en dansk udviklet fremgangsmåde til konstruktion af edb-baserede systemer. Arbejdet med udviklingen af Syskon blev iværksat af Edb-rådet i 1968, og resultatet blev publiceret i slutningen af 1971.

Syskon hører tidsmæssigt til blandt de første systematiske beskrivelser af, hvordan konstruktion af edb-systemer kan gribes an.

Den følgende beskrivelse af metoden er baseret på bogen "Syskon" af Chr. Andersen, Fritz Krogh-Jespersen og Anders Petersen fra 1972.

3.1.1 De grundlæggende ideer og principper

Om de grundlæggende ideer og principper bag Syskon skriver forfatterne på side 15:

"Ifølge den opfattelse, der ligger til grund for Syskon, er følgende spørgsmål særligt vigtige i relation til emnet konstruktion af et datamatisk system:

Hvad forstås ved en databehandlingsopgave, og hvordan beskrives en sådan opgave?

Hvordan skal arbejdet med planlægning og gennemførsel af systemkonstruktionen organiseres?

Hvordan skal konstruktionsarbejdet opdeles i aktiviteter og hvordan skal indholdet af disse aktiviteter beskrives?

Hvordan skal de forskellige dele af systemet dokumenteres?

Hvordan kan man finde de faktorer, der er væsentlige for systemet, og hvordan kan man måle eller bedømme værdierne af hver af disse faktorer?"

Det fremhæves desuden, at hensynet til mennesket er et emne, der behandles særligt omhyggeligt.

Selve konstruktionen af systemet foreslås organiseret i en projektorganisation med styre- og projektgruppe. Arbejdet foreslås inddelt i et antal faser, der repræsenterer den logiske fremadskriden i projektet:

Idéfasen

Analysefasen

Skitsefasen

Projekteringsfasen

Specifikationsfasen

Programmeringsfasen

Der etableres et projekt, hvor arbejdet bliver udført af en projektgruppe efter direktiv fra en styregruppe.

Projektgruppen rapporterer til styregruppen, som evaluerer de opnåede resultater. Denne evaluering skal sikre, at opgaverne i de enkelte faser er løst tilfredsstillende.

Styregruppen skal efter endt evaluering træffe beslutning om, hvorvidt projektet skal fortsætte ind i næste fase, eller om hele eller dele af fasens arbejde skal gøres om, eller om projektet eventuelt skal stoppes.

3.1.2 Faserne

Idéfasen omhandler formål og rammer for det nye system.

Formålet med analysefasen er fremstillingen af en kravspecifikation, som rummer en beskrivelse af de nuværende problemer, samt ønsker, krav og behov, der ønskes opfyldt af det kommende system, indenfor den fastlagte opgaveramme.

I skitsefasen foreslås en række alternative muligheder for løsning af opgaven. Alternativerne er forsynet med projektgruppens vurderinger af tekniske, økonomiske, organisatoriske og tidsmæssige konsekvenser. Alternativerne bør desuden være suppleret med cost-benefit analyser.

Styregruppen vælger herefter en af de alternative skitser, som implementeres i de følgende faser.

Efter projekterings- og specifikationsfaserne foreligger den færdige systemdokumentation, som fuldstændig beskriver det nye system v.h.a. diverse blanketter og diagrammer.

Herefter programmeres, testes og iværksættes det nye system.

3.1.3 Styringen

Dokumentationen er i vid udstrækning bestemt af anvisningerne til fremgangsmåden, og styringsformen sikrer, at omfang og kvalitet af dokumentationen vurderes af styregruppen efter hver fase.

Projektstyringen er yderligere beskrevet i anvisningerne, og består af estimater for tids- og ressourceforbrug, mødereferater, rapporter og direktiver.

Styregruppen er sammensat af ledelsesrepræsentanter fra de berørte områder. Projektgruppen består af brugere og systemkonstruktører med grundigt kendskab til det aktuelle funktionsområde.

Projektlederen vælges eller udpeges blandt projektgruppens medlemmer.

Fremgangsmåden anbefaler, at man anvender et sæt formaliserede planlægnings- og styringsværktøjer i form af standardiserede blanketter. En meget stor del af disse blanketter er standardiseret af Dansk Standardiseringsråd.

3.1.4 Hensynet til mennesker

Syskon sætter fokus på hensynet til mennesket i systemet. Emnet berøres især i forbindelse med de faser, hvor det er naturligt at lade de kommende brugere af det nye system deltage aktivt i projektgruppens arbejde.

Men da emnet tillæges stor vægt, har det også fået sit eget kapitel, side 212 - 223, hvor der gives en beskrivelse af emnet i et større perspektiv.

Vi har udvalgt nogle citater, som viser, hvilke tanker man har gjort sig vedrørende hensynet til mennesker:

"Udfra det synspunkt, at databehandlingssystemer er nødvendige for såvel samfundet som virksomheder, kan det spørgsmål, som er væsentligt for hensynet til mennesker formuleres således: Hvordan indretter vi systemerne, således at de kan tilpasses mennesker i stedet for at lade mennesker tilpasse sig systemerne?" [s. 213]

"Som den første og sikkert også største vanskelighed nævner vi menneskets begrænsede viden angående indretningen af et menneskevenligt samfund." [s. 213]

"Sandsynligvis vil forskellige mennesker fortolke den nye viden om problemerne på forskellig måde. Det vil næppe være muligt at nå frem til en tilstand, hvor menneskets erkendelse ikke hænger sammen med en række fordomme, som afviger fra menneske til menneske." [s. 213-214]

"Både nu og i fremtiden vil det hensyn man tager til mennesket i høj grad være baseret på umotiverede fordomme." [s. 214]

Herefter gives der en række konkrete anvisninger på, hvad man kan gøre for at tage det fornødne hensyn til mennesket i systemet.

Kapitlet munder ud i en fremhævelse af betydningen af uddannelse af systemkonstruktører:

"Der er behov for en basisuddannelse vedrørende generelle samfundsforhold. En sådan uddannelse skulle efter vor opfattelse indeholde et begrænset afsnit om datamatiske emner, men helt klart have hovedvægten lagt på sociologiske, psykologiske, økonomiske og styringsmæssige problemer i et moderne samfund."

3.1.5 Løsningsmetoder

Med henblik på spørgsmålet om problemløsningsmetoder nævner Syskon, at en systemkonstruktør har et meget stort behov for at kende til løsningsmetoder fra en lang række fagområder.

Der er opregnet en række fagområder, hvor man kan vente at finde nyttige metoder:

Matematik

Datalogi

Numerisk analyse

Statistik

Operationsanalyse

Virksomhedsledelse og organisation

Administration

Budget- og regnskabsvæsen

Systemteori

Sociologi

Da systemkonstruktøren ikke kan være specialist inden for alle de nævnte fagområder, må han eller hun have mulighed for at inddrage specialister i arbejdet med valg af den rette løsningsmetode.

3.2 Strukturerede metoder

De strukturerede metoder er betegnelsen for et antal metoder, som er udviklet over en fælles idé: den strukturerede top-down nedbrydning.

Metoderne er under fortsat udvikling; men der vil alligevel blive givet et historisk overblik over de vigtigste trin i den hidtidige udvikling.

3.2.1 Historisk udvikling

Udviklingen af de strukturerede metoder tog sin begyndelse i slutningen af 1960'erne. Det startede med struktureret programmering, som var et revolutionerende paradigme på sin tid.

Paradigmet er baseret på en teori fremsat af hollænderen Dijkstra. Teorien går ud på, at enhver programspecifikation kan nedbrydes til tre elementære konstruktionselementer:

sekvenser

iterationer

selektioner

I starten af 1970'erne blev struktureret design tilføjet som en metode, der syntes uundværlig i forbindelse med struktureret programmering.

Med struktureret design følger en række diagrammeringsværktøjer, som er skabt med henblik på fremstilling af strukturerede programmer.

Før struktureret design dokumenteredes problemløsninger ved hjælp af logiske rutediagrammer (flow-charts), beslutningstabeller eller lignende.

Målet med struktureret design er at frembringe løsningsmodeller med følgende egenskaber:

Designet skal afspejle virkeligheden, dvs. problemets struktur skal afspejles i løsningens struktur.

Designet skal sikre et brugervenligt system.

Designet skal være enkelt at modificere (vedligeholde), så systemet til stadighed kan leve op til omgivelsernes krav.

Designet skal sikre, at ressourcerne udnyttes effektivt.

Designet skal sikre en høj grad af pålidelighed (en stabil driftssituation).

[Johansen "Udvikling af edb systemer" s. 10-2 - 10-3]

Integreret systemanalyse er en analysemetode fra slutningen af 1980'erne. Integreret systemanalyse bygger på Ed Yourdon's og Tom DeMarco's strukturerede analysemetode til administrative systemer fra 1978.

DeMarco introducerede begrebet "logisk model". En logisk model er en model, der er struktureret og navngivet ud fra brugerens funktioner og ikke ud fra de tekniske løsninger.

Videreudviklingen af den traditionelle strukturerede analyse blev foretaget af McMenamin og Palmer. De har indført begreberne essentiel systemanalyse og essentielle modeller, idet de bygger videre på DeMarcos tankegang og uddyber retningslinierne for, hvorledes intentionerne kan nås.

De vigtigste forskelle er:

Hændelsesopdeling af modeller og systemer.

Entitetsopdeling af data via informationsanalyse.

Tilstandsdiagrammer til beskrivelse af entiteters tilstande og tilstandsændringer.

En alternativ strategi, der minimerer arbejdet med beskrivelse af det eksisterende system, og letter projektstyringen.

[Delskov & Lange "Struktureret analyse" s. 22-23]

På det eksisterende teorigrundlag har Delskov og Lange i bogen "Struktureret analyse / Integreret systemanalyse" søgt at beskrive og supplere analysemetoden, så den støtter det konkrete praktiske analysearbejde mest muligt. Samtidig er metodens tyngdepunkt flyttet mod informationsanalysen.

Delskov og Lange "tror ikke på en fremgangsmåde, der går ud på, at udvikleren "sætter fingeren i rillen" og lader sig føre blindt fremad som efter en opskrift. Professionelt arbejde bygger på forståelse af formål og indhold af metoden som basis for at tilpasse retningslinierne efter forholdene."

3.2.2 Struktureret programmering

Formålene med struktureret programmering var (og er) mere læselige og overskuelige programmer, højere produktivitet blandt programmører og færre problemer i forbindelse med aftestning af programmet.

En af metoderne til at nå målene med struktureret programmering var at eliminere GO-TO sætninger fra programmerne.

Det lykkedes ret hurtigt at eftervise, at programmer kunne konstrueres udelukkende ved hjælp af de tre elementære konstruktionselementer: sekvens, selektion og iteration.

Senere har analyser vist, at det ikke så meget er brugen af GO-TO sætningen, som den ustrukturerede måde sætningen ofte bruges på, der er det virkelige problem. Hvis man anvender GO-TO sætninger på en disciplineret måde, kan det ligefrem føre til mere overskuelige programmer.

Med struktureret programmering lanceredes et ønske, som i dag har udviklet sig til et egentligt datalogisk begreb: drømmen om, at det ville være muligt at skrive programmer på en sådan måde, at deres korrekthed kunne bevises. [Yourdon "Techniques of Program Structure and Design" s. 136-180]

3.2.3 Struktureret design

Struktureret design er nært forbundet til struktureret programmering, idet en struktureret arbejdsform forud for selve programmeringen er en stor lettelse.

Den grundlæggende filosofi bag struktureret design er top-down, som samtidig er en naturlig fremgangsmåde i forbindelse med nedbrydning af et komplekst problem i mindre og dermed mere overskuelige enheder.

Top-down design findes i et utal af varianter; men fælles for de fleste af disse er det samme mål: at identificere de overordnede funktioner, og derefter fortsætte med identifikation af de underordnede funktioner, der kan udledes af de overordnede.

Den grundlæggende ide bag top-down design er simpel: Man begynder med at forestille sig, at man har en maskine til rådighed, som kan udføre programmets funktion ved hjælp af en enkelt genial instruktion i det aktuelle programmeringssprog.

Desværre findes en sådan genial instruktion ikke i programmeringssproget, og man bliver derfor nødt til at nedbryde programmet i lidt mindre enheder, i håbet om at disse vil kunne udføres direkte i sproget.

Processen fortsætter med nedbrydning af hver operation i stadig mindre primitiver, indtil man endelig når frem til primitiver, som er simple nok til at kunne implementeres direkte i det aktuelle programmeringssprog.

Det bliver hurtigt åbenlyst, at det er særdeles vanskeligt at udvikle et velstruktureret top-down design på basis af usammenhængende, ukomplette og uorganiserede specifikationer.

Kravet om strukturerede specifikationer som input til struktureret design fører til lanceringen af struktureret analyse som den metode, der kan producere en sådan specifikation. [Yourdon "Techniques of Program Structure and Design" s. 36-88]

3.2.4 Struktureret analyse

Den oprindelige strukturerede analyse er virkelig en metode, idet den kun beskæftiger sig med analyse og design og ikke indeholder selvstændige elementer til projektstyring og kvalitetssikring.

3.2.4.1 De grundlæggende ideer og principper

Struktureret analyse gør op med de tidligere anvendte verbale former for beskrivelser, og indfører data-flow diagrammer til beskrivelse af systemets funktioner.

Problemet med de verbale beskrivelser er det naturlige sprogs tvetydige karakter. I stedet tilstræbes den højere grad af formalisme, som et standardiseret diagrammeringsværktøj giver.

Det er vigtigt, at man forstår det gamle og det nye systems virkninger på organisationen, inden implementering af det nye system iværksættes. Denne specifikation er derfor det vigtigste mål for analysen.

Det er således et afledt mål, at design og implementering ikke må komme til at lide under forvirring og ubeslutsomhed, hvad angår systemets virkemåde.

Et andet afledt mål er, at man forpligter sig til i den integrerede analyse at skaffe sig al viden om et system, inden programmering påbegyndes, og at man forpligter sig til at dokumentere denne viden.

Man erkender, at denne indsamling og dokumentation af viden tager lang tid; men det antages, at denne investering betaler sig i form af markant faldende vedligeholdelsesomkostninger.

Et centralt punkt i den integrerede systemanalyse er at finde en passende balance mellem modeller, der beskriver funktioner, og modeller, der beskriver data.

I den oprindelige strukturede analyse tog man udgangspunkt i det eksisterende systems funktioner, der ofte var manuelle.

Senere blev man klar over, at virksomhedernes informationer repræsenterer et væsentligt aktiv, både som et selvstændigt produkt og også som kilde til udformning af forbedrede systemer.

Den integrerede systemanalyse drager nytte af begge muligheder, idet metoden lægger vægt på, at systemudviklerne udmønter deres forståelse af informationsbehandlingen i en struktur, der følger problemet fremfor den hidtil anvendte teknologi.

Datagrundlaget spiller således en integreret rolle med det ønskede funktionsomfang, der kan fordre nye informationer lagret eller behandlet i det nye system.

Metoderne beskæftiger sig meget med værktøjsanvendelse og dette har affødt et udbud af edb-baserede værktøjer (CASE) ligesom værktøjsbenyttelsen fylder godt i de fleste bøger om struktureret analyse.

Endvidere spiller psykologi og organisation en vis rolle, idet man er meget bevidst om aktørernes betydning for processen.

3.2.4.2 Faseopdeling

Arbejdets opdeling i faser er ikke så rigoristisk, som man f.eks. så det i forbindelse med Syskon. Opdelingen i faser betegner snarere en række milepæle for processens fremadskriden.

Man kan dog som regel udskille følgende struktur:

Foranalyse

Analyse

Design

Implementering

Vedligeholdelse

3.2.4.3 Vedligeholdelse

Vedligeholdelsen er udnævnt til at være den enkeltfaktor, som udgør den største årsag til softwarekrisen, idet vedligeholdelse beslaglægger flere og flere ressourcer, som kunne have været udnyttet til konstruktion af nye profitable systemer.

Struktureret analyse prøver bevidst at skabe en situation, som gør det nemmere for systemudviklerne at vedligeholde dokumentationen.

3.2.4.4 Fysiske, logiske og essentielle modeller

I den oprindelige strukturede analyse var der tale om, at man beskrev fire modeller af systemet, der skulle forandres.

Gammel fysisk model og gammel logisk model er milepæle i forståelsen af, hvorledes man teknologisk og organisatorisk havde løst opgaven i det gamle system, og de viser samtidig, at udvikleren har genopdaget det gamle systems indre logik.

Den nye logiske model viser først og fremmest krav og ønsker til det nye system. Det nye systems logik skal til slut i den nye fysiske model iklædes en fysisk løsning som tilfredsstiller aktørernes ønsker.

McMenamin og Palmer indførte essentiel modellering og hændelsesmodellering, hvorved man frigjorde sig fra teknologiske bindinger og fokuserede på de essentielle aktiviteter, der er reaktionen på en hændelse. De data, der lagres som resultat af hændelsen, kaldes hændelsesresultatet, og de indgår derfor også i informationsmodellen.

Essentiel modellering er et forsøg på at formindske arbejdsbyrden, idet den essentielle model gøres teknologisk neutral, d.v.s. at det væsentlige i et system ikke forældes eller ikke skal omdokumenteres på grund af ydre omstændigheder.

3.2.4.5 Fordele og ulemper ved struktureret analyse

Forfatterne til bogen "Struktureret analyse og integreret systemanalyse" stiller selv en række kritiske spørgmål til systemanalyse, hvor de prøver at gøre en slags status i forhold til softwarekrisen.

Softwarekrisen kommer til udtryk på den måde, at mindre ændringer og rettelser ikke kan indpasses i det traditionelle systemudviklingsarbejde.

"Systemets dele er godt indfiltret i hinanden, så brugeren skal have en virkelig god grund, hvis nytteværdien skal stå mål med omkostningerne."

En anden ting der fremhæves ved struktureret analyse er værktøjernes enkelhed i kommunikationen mellem interessenterne i projektet. Data-flow diagrammer har således kun 3 symboler, og bør dermed også kunne læses og forstås af ikke-fagfolk.

Den integrerede analyse ser på både processer (funktioner) og informationer (data). Det non-procedurale statiske udtrykkes i datarelationerne mellem entiteterne i E/R-diagrammerne, mens det procedurale dynamiske ydtrykkes i data-flow diagrammer.

Forfatterne har et afslappet syn på formalismen omkring systemudvikling og siger ligefrem at denne har gjort arbejdet mere kompliceret. Der tales om at "bøje" metoden efter tilfældet, således at metoden ikke bliver en eksakt anvisning på, hvad der skal gøres i hvilken rækkefølge.

De hævder at "professionelt arbejde bygger på forståelse af formål og indhold af metoden som basis for at tilpasse retningslinierne efter forholdene".

Metoden anvendes med størst fordel på lidt større og komplekse systemer, hvor målet er et fleksibelt system. Man kan anvende metoden til at kaste lys over et område, men det fulde udbytte fås først, hvis processen føres til ende, og man kan høste fordelene af den lettere vedligeholdelse.

Selv om værktøjerne er ret simple er det ikke særlig enkelt, at skabe en konsistent datamodel og en tilpas detaljeret model af funktioner og hændelser.

Til gengæld regner man med, at det omhyggelige forarbejde vil minimere programmeringsindsatsen, da der ikke bør komme de store overraskelser, hvad angår systemets indre logik.

Brugernes indflydelse og medvirken antages at befordre et brugbart system, som kan give størst nytteværdi i de omåder, hvor det netop er brugernes forventninger og krav, der skal indfries.

3.3 Prototypeudvikling

Ifølge Beyer m.fl. i bogen "Systemudvikling og forandring" kan man ved en prototype forstå "et hurtigt udviklet "pilotsystem", hvormed man kan demonstrere væsentlige facetter af det påtænkte endelige system."

Anvendelse af prototyper giver følgende muligheder:

Mulighed for at eksperimentere med en konkret model af et system for derved at skabe tilstækkelig indsigt til, at et korrekt system kan udvikles.

Letter kommunikation mellem brugere og systemudviklere ved at kommunikere omkring en konkret løsning i stedet for en abstrakt model.

Muligheder for at vurdere reelle alternativer i form af forskellige prototyper.

Mulighed for tidlig afprøvning i en større brugerkreds.

Mulighed for prøvedrift med tilhørende sideløbende uddannelse og træning.

Prototyper kan enten fremstilles som led i et struktureret analyseforløb, eller de kan fremstilles i et egentligt eksperimentelt systemudviklingsforløb.

Connel og Shafer redegør i bogen "Rapid Structured Prototyping" for flere forskellige mulige anvendelser for prototypeudvikling.

En af mulighederne er, at man smider prototypen væk, når man har høstet erfaringerne med den.

En anden mulighed er, at man konstruerer systemet udelukkende ved hjælp af gentagne og stadig forbedrede versioner af prototyper.

En tredje mulighed er den ingeniørmæssige prototype, der først bygges efter traditionelt design. En sådan prototype kan bruges til at verificere, at specifikationer er i orden.

En fjerde mulighed og den, som Connell og Shafer mener, er den bedste, er "evolutionær prototyping". Herved forstås en kørende model af det foreslåede system eller væsentlige dele af det foreslåede system. Den kørende model kan gradvist udvides og tilrettes for at imødekomme det komplette sæt af krav, der stilles til systemet.

I modsætning til de prototyper, som man smider væk efter brug, er det meningen, at disse til slut skal udvikle sig til at blive selve produktet.

Metoden anvendes i forbindelse med struktureret analyse og design, således at man prøver ved hjælp af de strukturerede metoder at undgå at analysere og specificere uønskede elementer.

Desuden tillader et struktureret grundlag, at man på et tidspunkt i udviklingen af systemet kan gå over til at programmere med konventionelle programmeringssprog.

Der kan således arbejdes og eksperimenteres med virkelige data og foretages afprøvninger, som på et tidspunkt kan resultere i traditionelle strukturerede programmer, eller man kan fortsætte udviklingen i et effektivt 4. generations værktøj.

Gennem gradvist stigende præcisering nærmer man sig den endelige applikation.

3.3.1 Rapid Structured Prototyping

Metoden Rapid Structured Prototyping er et eksempel på, hvordan anvendelse af prototyper kan integreres i et struktureret systemudviklingsforløb.

Hvad er prototyping og måske især, hvad er det ikke?

Forfatterne til bogen "Structured Rapid Prototyping", Connell og Shafer, fremhæver i forordet, at man ikke må forledes til at tro, at prototyping er et trick, der hurtigere end andre metoder bringer et resultat, ved at man springer over analyse og design, og går direkte til kodning af et systemforslag, som man så retter på, indtil det er acceptabelt.

Prototyping anses for at være et analyse værktøj, der ikke i sig selv bringer et projekt hurtigere igennem udviklingen.

Det, der er fordelen, er, at den senere vedligeholdelse af systemet lettes. Ressourceforbruget til vedligeholdelse har en tendens til at vokse hastigt i komplekse, integrerede systemer, hvis der ikke er veldefinerede og strukturerede grænseflader.

Prototyping har således to mål :

at skabe modeller af systemet, så brugerne kan tage reelt stilling til funktionaliteten. Processen gentages, indtil man har nået den nødvendige dybde i forståelsen af problemstillingen.

at gøre det let at ændre i systemet.

Det første mål bygger på den antagelse, at de første udgaver af et hvilket som helst produkt er fejlbehæftede.

På grund af anvendelse af effektive og dermed tidsbesparende værktøjer kan man nu lettere tillade sig at kassere førsteudgaven, når man har brugt den til at indsamle erfaringer og evalueringer til næste prototype.

I modsætning til andre systemudviklingsmodeller skal man her ikke tage stilling til et tænkt system, men kan afprøve systemets forskellige aspekter i en virkelig model.

Man risikerer ikke kommunikationsproblemer på grund af problemer med sproglige og dokumentationsmæssige forhold.

Endvidere sikrer gentagelserne af processen, at brugerne hele tiden er med i processen, og at opfattelsen af systemets mål ikke driver i hver sin retning for systemudviklere og brugere.

Det bliver tværtimod en fælles læreproces. Man kan desuden udvælge særligt kritiske og vanskelige elementer for en nærmere undersøgelse, medens mere velkendte opgaver måske ikke behøver at gøres til genstand for så indgående studier.

Det første mål sikrer altså, at man løser problemet, på den rigtige måde og derved sparer tid i senere faser til afklaring af misforståelser og eventuel rettelse af disse.

I det virkelige liv bliver mange af disse rettelser først gennemført efter at systemet er sat i drift, med irritation og tab til følge for brugerorganisationen.

Det andet mål vedrører implementeringen af den endelige prototype. Man ønsker ultimativt, at man kan sætte lighedstegn mellem prototypen, specifikationen og det implementerede produkt.

Den sikreste måde at bevare enheden på, er at lade den sidste prototype være lig med det færdige produkt.

Dette byder dog på en række problemer, som har at gøre med effektiviten af de værktøjer, man udvikler prototypen med, ligesom deres evne til at rumme et helt system ikke altid er til stede. Mange af værktøjerne er fokuseret på f. eks. skærmdialog eller databaseoperationer, men er ikke komplette.

Man kan derfor blive nødt til, at lave den endelige implementation i et traditionelt programmeringssprog, hvorved man risikerer at miste forbindelsen til sin prototype, når der senere skal videreudvikles på systemet.

Ønsker man at prolongere prototypen videre i drift, skal man fra starten have valgt et til formålet komplet værktøj.

Markedet for prototypeværktøjer blomstrer med mange muligheder, så ethvert forsøg på opstilling af modeller, der er egnede til bestemte typer opgaver vil meget hurtigt forældes.

Man kan dog generelt sige, at systemer med funktioner, man er usikre på, udgør et risikomoment for projektet, så prototypen kan være et godt værktøj til at afklare hvad den ønskede funktionalitet skal være.

Der er et utal af forskellige værktøjer for prototype udvikling på markedet, og det kan være vanskeligt at afgøre hvilket værktøj, der er det bedste; men der synes enighed om at værktøjer, der nemt genererer skærmbilleder, programmer, samt forespørgsler og rapporter er et godt udgangspunkt for en tidsbesparende opstilling af modellerne.

Metoden Rapid Structured Prototyping indebærer, at man bruger prototyping som en teknik, der kan sikre, at man kommer frem til beskrivelsen af det rigtige system i analysen. Pointen er, at den kommende bruger har lettere ved at tage stilling til en kørende model af det kommende system end et antal papirmodeller.

3.3.2 Eksperimentel systemudvikling

I bogen "Systemudvikling og forandring" af Beyer m.fl. redegøres der for, hvad der forstås ved eksperimentel systemudvikling.

"Eksperimentel systemudvikling er en iterativ fremgangsmåde for systemudvikling, hvor praktiske eksperimenter udføres på modeller."

"Eksperimenterne giver brugerindsigt og forståelse for det færdige systems konsekvenser og muligheder. Brugeren kan komme til at styre udviklingsprocessen i udstrakt grad, og eksperimenterne sætter endvidere systemudvikleren i stand til at studere og efterse det færdige systems egenskaber, inden det sættes i drift."

"Eksperimentel systemudvikling udføres ikke med en traditionel faseopdeling. I stedet benytter en iterativ fremgangsmåde, hvor praktiske eksperimenter udføres på gradvist mere udbyggede modeller af det ønskede system."

I eksperimentel systemudvikling skelnes mellem tre forskellige typer af modeller:

Skitsen, der kun indeholder få af det endelige systems egenskaber

Prototypen, der indeholder de vigtigste af det endelige systems egenskaber

Driftssystemet, der omfatter alle det endelige systems egenskaber

Som det fremgår, indgår prototype udvikling i eksperimentel systemudvikling som én af tre former for modeller.

3.4 Formalistiske metoder

Indenfor den mere teoretisk/datalogiske del af computerverdenen foregår der en tilsyneladende evig diskussion om, hvorvidt systemudvikling er en videnskab eller en kunstart.

Yderpunkterne i diskussionen rækker fra det synspunkt, at ethvert programs rigtighed kan bevises videnskabeligt gennem systematisk opstilling og reduktion af en række logiske udtryk, og til det synspunkt, at det udelukkende er systemudviklerens erfaring og intuition, som har betydning for et heldigt udfald af systemudviklingen.

Spørgsmålet om de formalistiske metoders rolle er nært forbundet med de filosofiske aspekter af den rolle, matematikken spiller i forhold til opfattelsen af videnskabelighed i al almindelighed.

Som det blev beskrevet i forbindelse med gennemgang af de strukturerede metoder, var en af de bærende ideer bag struktureret programmering oprindelig drømmen om, at det en dag ville være muligt at skrive programmer på en sådan måde, at deres korrekthed kunne bevises. Man kunne også kalde det drømmen om den fejlfrie specifikation.

Afsløringen af fejl må siges at være enhver specifikations fornemste opgave. I de strukturerede metoder er det dog især specifikationens rolle, som dokumentation, der fokuseres på.

3.4.1 Formel specifikation

Formålet med enhver specifikation kan siges at være

at den gennem et antal trinvise forfinelser skal give systemudvikleren en bedre og bedre forståelse af det problem, der analyseres.

at den skal medvirke til at afdække eventuelle fejl og mangler i systemudviklerens forståelse. Afsløring af fejl på et tidligt tidspunkt i systemudviklingen er af stor betydning, da man på denne måde kan undgå kostbare fejltagelser.

En formel specifikation er en særlig form for specifikation, som udtrykkes med et ordforråd, en syntaks og en semantik, som er formelt defineret.

Formel definition medfører, at specifikationen er utvetydig, og derfor er det udelukket, at man kan anvende et naturligt sprog som engelsk eller dansk til specifikationen, fordi naturlige sprog netop er kendetegnet ved tvetydige ordforråd og semantik.

En formel definition er i stedet baseret på en matematisk udtryksform, som er kendetegnet ved sin utvetydighed.

Den formelle specifikation er den naturlige forudsætning for en vigtig datalogisk disciplin kaldet det formelle programbevis.

Ifølge denne disciplin kan man betragte et program som en matematisk ligning. Hvis man kan bevise at denne ligning kan omforme et nærmere specificeret sæt af inputværdier til et sæt outputværdier, som kan leve op til de specifikationer, som fremgår af den formelle programspecifikation, har man samtidig bevist, at programmet er korrekt.

Udgangspunktet for programbeviset er en række påstande vedrørende tilstanden imellem de enkelte programtrin. Man tager udgangspunkt i en påstand, som er sand før en programstumps udførelse. Denne udgangspåstand kaldes også en precondition.

Hvis man kan bevise, at de ændringer, som udførelse af de enkelte programlinier i programstumpen påfører den oprindelige påstand, resulterer i en påstand, som er opfyldt af en i forvejen specificeret slutpåstand, så er programstumpen korrekt. Den specificerede slutpåstand kaldes også en postcondition.

3.4.2 Fordele ved en formel specifikation

Blandt fordelene ved at arbejde med en formel specifikation kan ifølge Sommerville "Software Engineering" nævnes:

at den formelle specifikation danner udgangspunkt for en systematisk omformning af specifikationen til programmer, hvis rigtighed så automatisk vil være formelt bevist.

udviklingen af den formelle specifikation giver indsigt i og forståelse for naturen af det problem, der skal løses.

der kan udvikles softwarepakker og værktøjer, som kan give computerstøtte i forbindelse med udvikling og omformning af formelle specifikationer.

med den rigtige softwarestøtte i form af et passende fjerde generationssprog kan en formel specifikation automatisk omformes til en prototype.

de formelle specifikationer kan studeres og analyseres ved hjælp af matematiske metoder.

de formelle specifikationer rummer vigtige informationer, som kan bruges i forbindelse med planlægning af en effektiv aftestning af en programstump.

3.4.3 Hindringer for formelle specifikationer

På grundlag af det foregående afsnit skulle man umiddelbart tro, at de formelle specifikationer var generelt accepterede. Sådan er det imidlertid ikke i virkeligheden, og følgende årsager er ifølge Sommerville "Software Engineering" medvirkende hertil:

Softwarebranchen er konservativ, når det drejer sig om at tilegne sig og indføre nye teknikker - især når det samtidig er vanskeligt at bevise, at de nye teknikker vil føre til reducerede omkostninger i forbindelse med softwareudviklingen.

Kendskabet til teknikken er ikke særlig udbredt blandt softwareudviklere.

Det er en forudsætning, at man har et vist kendskab til matematik og reglerne for logisk ræsonnement.

Brugerne og dem, der skal betale for projekterne kender ikke teknikken, og de vil derfor hverken kunne verificere eller kontrollere specifikationerne.

Visse typer af systemer (f.eks. on-line systemer) er meget vanskelige at specificere med de kendte formelle metoder.

Der er ikke blevet udviklet det fornødne softwareværktøj til understøttelse af de formelle metoder. Sådanne værktøjer er en forudsætning for en udnyttelse af teknikkerne i større målestok.

Softwareværktøj til fuld-skala implementering af formelle programbeviser er sandsynligvis umuligt at fremstille på en effektiv måde, fordi det problem, der skal løses i forbindelse med fremstillingen af et sådant softwareværktøj, antageligt er et non-polynomielt problem. Det vil sige, at en stigende kompleksitet i inputmaterialet vil medføre en eksponentielt stigende eksekveringstid.

Der eksisterer den udbredte misforståelse blandt visse dataloger, at man kan sætte lighedstegn imellem softwareudvikling og anvendelse af formelle metoder. Selvom denne opfattelse er udtryk for det rene nonsens, får det mange praktisk orienterede professionelle systemudviklere til at stå sammen om at afvise de formelle metoder.

Fronterne er således trukket skarpt op, og det kan være vanskeligt at tro, at det vil kunne lykkes at skabe et kompromis imellem tilhængere og modstandere af de formelle metoder.

3.4.4 Funktionel programmering

Operationerne er specificeret på en sådan måde, at der ikke forekommer modifikation af inputparametrene. Alle operationerne er derfor implementeret som funktioner.

Man kan også udtrykke det på den måde, at sideeffekter ikke tillades. En sideeffekt fremkommer, når man som i traditionelle programmeringssprog tillader en parameter både at være input- og outputparameter for en funktion, og når det derved bliver muligt at ændre i den tilhørende aktuelle variabels værdi fra funktionen.

Et andet særkende ved funktionel programmering er, at man foretrækker rekursion fremfor iteration. Der findes et større antal kendte rekursive løsninger på almindeligt forekommende problemer. Desværre kan det være en uhyre vanskelig opgave at fremstille rekursive løsninger til banale dagligdags problemer.

Når man foretrækker rekursive løsninger fremfor iterative, hænger det sammen med, at man kan bevise rigtigheden af rekursive løsninger, hvilket ikke altid er muligt ved de tilsvarende iterative løsninger.

3.5 Objekt-orienteret systemudvikling

Objekt-orienteret systemudvikling betragtes af mange som den mest lovende strategi til bekæmpelse af softwarekrisen; men måske skal den største betydning af objekt-orientering søges i det forhold, at den tvinger erfarne systemudviklere til at reflektere over deres eget arbejde.

De tankeprocesser, der herved sættes i gang, kan resultere i vigtig ny erkendelse for den enkelte systemudvikler. Efterhånden vil denne nye erkendelse kunne føre til en dybere forståelse for naturen af systemudviklerens arbejde.

Det er meget vanskeligt at definere præcist, hvad objekt-orienteret systemudvikling er. I stedet har man forsøgt at give forskellige beskrivelser af nogle egenskaber, som kendetegner objekt-orienteret systemudvikling.

Der kan identificeres i hvert fald fire af disse egenskaber eller grundprincipper.

Man må nok erkende, at der ikke er noget epokegørende ved nogle af disse grundprincipper, når de betragtes isoleret. Hver for sig har grundprincipperne været kendte i adskillige år. Det er først når principperne sættes i den fælles referenceramme, at de bliver et alternativ til de øvrige systemudviklingsmetoder.

3.5.1 Dataabstraktion

Objekt-orienteret systemudvikling er først og fremmest baseret på dataabstraktioner. En dataabstraktion består af et antal variabler, der definerer en tilstandsmængde, og et sæt af operationer til manipulation på denne tilstandsmængde. I objekt-orienteret systemudvikling kaldes en dataabstraktion for en objektklasse.

Operationerne og variablerne definerer objektklassens adfærd i forhold til omverdenen. Forskellige objektklasser kan arbejde sammen, således at den ene objektklasse udnytter faciliteter, som indgår i den anden objektklasses adfærd.

På denne måde kan der opbygges et netværk af samarbejdende objektklasser, hvorimellem der udveksles informationer efter veldefinerede og formaliserede regler. Det er dette netværk, som til syvende og sidst udgør den objekt-orienterede software applikation.

3.5.2 Fælles adfærd

Begrebet fælles adfærd dækker over den grundlæggende idé, at man skal tilstræbe at flere objektklasser har den samme adfærd. Herved lettes systemudvikleren i den opgave, der består i at bevare overblikket over de muligheder, der er indbygget i objektklasserne.

Ønsket om at kunne definere fælles adfærd mellem flere forskellige objektklasser giver grundlag for at inddrage begreberne arv og polymorfi som naturlige elementer i objekt-orienteret systemudvikling.

Opstilling af arvehierarkier eller taksonomier giver mulighed for at beskrive og udnytte det slægtskab, der naturligt forekommer imellem objektklasser, der er generaliseringer eller specialiseringer af hinanden.

Polymorfi er et begreb, som i virkeligheden er en fællesbetegnelse for en række vidt forskellige faciliteter i forskellige programmeringssprog.

Polymorf betyder noget, der kan antage forskellige former, og der hentydes derved til, at en bestemt algoritme eller adfærd kan udformes generelt uden kendskab til den eksakte udformning af den aktuelle objektklasse.

3.5.3 Udvikling

En tredie karakteristisk egenskab ved objekt-orienteret systemudvikling er, at man betragter enhver objektklasse og ethvert system som trin i en udviklingshistorie.

Herved kommer genbrug af tidligere udviklede dele af systemer til at udgøre vigtige elementer i systemudviklingsstrategien. Det er egentlig denne idé, der ligger til grund for den artikel af Cox, som udgør denne hovedopgaves udgangspunkt.

3.5.4 Softwarekvalitet

Den fjerde karakteristiske egenskab ved objekt-orienteret systemudvikling er fokuseringen på softwarekvalitet.

Der er mange faktorer, som kan siges at påvirke kvaliteten af den færdige software; men hvis man skulle pege på en enkelt faktor, som man især er opmærksom på, er det kompleksitet.

Ethvert initiativ, som kan reducere kompleksiteten, vil bidrage til, at den resulterende software bliver mere korrekt.

Indlagt 27. april 1997