4. Systemudvikling i virkeligheden

Efter gennemgangen i kapitel 3 af en række typiske eksempler på teoretiske systemudviklingsmodeller, der igennem tiden er foreslået som løsninger på softwarekrisen, skal der i dette kapitel fokuseres på, i hvilken udstrækning disse metoder har vundet indpas i det professionelle systemudviklingsarbejde.

Efter gennemgang af en række skrevne kilder vedrørende dette emne, beskrives en række egne iagttagelser.

4.1 "Round-Trip Gestalt Design"

I bogen "Object Oriented Design with Applications" af Grady Booch beskrives en undersøgelse af den typiske adfærd blandt professionelle systemudviklere i en systemudviklingsafdeling i en større amerikansk virksomhed.

Forinden fremkommer Booch med nogle mere generelle bemærkninger vedrørende de problemer man møder, når man skal designe systemer.

Booch siger: "At designe er ikke bare at tegne et diagram. Et diagram kan kun bruges til at fastholde et design. Uanset hvordan man vender eller drejer det, kan man fastslå, at det eneste sted design foregår, er inde i hovedet på designeren."

"Selvom diagrammer altså ikke spiller nogen rolle i forbindelse med design, er det alligevel vigtigt, at man har nogle veldefinerede og udtryksfulde notationsformer:

1. Standardnotation tillader kommunikation af designet.

2. En god notation tillader designeren at "glemme" designet, så han kan koncentrere sig om mere avancerede problemer.

3. En god notation tillader automatiseret konsistenscheck af designet via CASE værktøjer."

Booch gør en vigtig iagttagelse vedrørende de mangler, der er ved enhver type diagram: "Det er umuligt at fastholde alle de finere detaljer i et komplekst softwaresystem ved hjælp af en enkelt type diagram."

"Det faktum, at et notationsværktøj er detaljeret, betyder ikke, at man skal anvende det i sin fulde udstrækning hver gang. Hvis man gør et diagram for detaljeret, løber man en risiko for at overspecificere."

I øvrigt gør Booch opmærksom på behovet for flere typer diagrammer til beskrivelse af et system. Det hænger sammen med, at den fulde forståelse af et system kræver indsigt i både den statiske og den dynamiske side af systemet.

De fleste notationsformer fastholder alene det statiske perspektiv, hvorimod de dynamiske forhold, der viser programmets opførsel under kørsel, kræver nogle andre diagrammer. F.eks. tilstandsdiagrammer eller timingdiagrammer.

Godt design skyldes gode designere - ikke gode værktøjer. Værktøjer giver blot den enkelte systemudvikler større frihed til at kunne koncentrere sig om de virkeligt kreative aspekter ved design.

Booch rejser et spørgsmål, som faktisk mere er et filosofisk problem, end et spørgsmål, der kan besvares:

"Er design en top-down eller en bottom-up proces? Erfaringen viser, at design hverken er ren top-down eller ren bottom-up. Tværtimod skabes velstrukturerede komplekse systemer bedst ved hjælp af "round-trip gestalt design". Denne metode fremhæver det iterative og udviklende aspekt i systemudviklingen gennem forfinelse af forskellige konsistente logiske og fysiske syn på systemet som helhed."

"Problemet i den strukturerede systemudviklingsmetode er, at man ikke kan diktere kreativitet blot ved at definere nogle metodetrin, man skal gennemgå eller nogle produkter, man skal fremstille. Tværtimod er det sådan, at jo mere man ved om problemet, des nemmere er det at løse."

"Studier af professionelle systemudviklere har vist at:

softwaredesign synes at være en samling af overlappende iterative, løst organiserede processer under opportunistisk kontrol.

top-down udvikling forekommer; men som et specialtilfælde, der kan opstå, når en relevant designskabelon forekommer, eller når der er tale om et lille problem.

gode designere arbejder med flere forskellige abstraktionsniveauer og detaljer simultant."

"De fleste softwaresystemer er helt unikke og systemudviklerens erfaringsgrundlag vil derfor ofte være stærkt begrænset. I sådanne situationer kan man ikke gøre andet end at tage en chance med et foreløbigt design, hvorefter man træder et skridt tilbage og analyserer resultatet. Derefter kan man vende tilbage til designproduktet og lave forbedringer baseret på den nye forståelse, som man nu har opnået. Denne proces gentages indtil man er overbevist om korrektheden og fuldkommenheden ved designet."

"Den ideelle systemudvikling kan beskrives som en spiralmodel, hvor fremgangsmåden er baseret på en chance- eller risikobaseret strategi fremfor en ren specifikationsbaseret eller prototypebaseret strategi."

4.2 Bjarne Stroustrup

I bogen "The C++ Programming Language - 2. ed." af Bjarne Stroustrup giver forfatteren sit syn på, hvordan softwareudvikling bør foregå, og hvad systemudvikleren skal være opmærksom på.

"Konstruktion af enhver stump ikke-triviel software er en kompliceret og ofte skræmmende opgave."

"Hverken detaljerne eller helheden må gå tabt i hastværket med at få systemet færdigt - selvom det ofte er lige præcis, hvad der sker."

"Der kan ikke laves nogen kogebogsmetode for udvikling af god software. Detaljerede beskrivelser af, hvordan det kan gøres, eksisterer kun for specifikke og meget velkendte typer applikationer; men ikke for mere generelle applikationsområder."

"Intelligens, erfaring og personligt præg kan ikke erstattes af noget."

"Betragt altid dine observationer med sund skepsis."

"Design og programmering er menneskelige aktiviteter - hvis man glemmer det, er alt tabt."

Resumé af nogle væsentlige temaer, som Bjarne Stroustrup fremhæver:

Det vigtigste i forbindelse med softwareudvikling er at være klar over, hvad det er, man vil forsøge at lave.

Succesfuld softwareudvikling er en langsigtet aktivitet.

Der er en tendens til, at man konstruerer systemer med en kompleksitet på grænsen af, hvad man selv og værktøjerne kan håndtere.

Der findes ingen "kogebogsmetode", som kan erstatte intelligens, erfaring og gode vaner i design og programmering.

Udførelse af eksperimenter er en væsentlig aktivitet i al ikke-triviel softwareudvikling.

Design og programmering er iterative aktiviteter.

De forskellige faser i et softwareprojekt (design, programmering og test) kan ikke adskilles klart.

Programmering og design kan ikke diskuteres, uden at man samtidig overvejer styringen af disse aktiviteter.

 

Det mest fundamentale problem i forbindelse med softwareudvikling er ifølge Bjarne Stroustrup kompleksitet.

Denne kompleksitet kan kun håndteres på én grundlæggende måde: Del og hersk (Divide and conquer). Det forunderlige er, at denne deling kan foretages på et utal af forskellige måder. F.eks. deler et modul eller en objektklasse problemet i to dele - implementeringen og brugeren - som kun er forbundet med en (ideelt set) veldefineret grænseflade.

På tilsvarende måde kan systemudviklingsprocessen opdeles i et antal forskellige aktiviteter med veldefinerede vekselvirkninger mellem de involverede personer.

I alle tilfælde er det opsplitningen og definitionen af snitfladerne mellem delene, som kræver erfaring og gode vaner.

Valget af elementer i opsplitningen er ikke nogen simpel mekanisk proces; men kræver typisk en indsigt, som kun kan opnås gennem en dyb forståelse af et system på passende abstraktionsniveauer.

Det gælder om at finde en passende balance mellem mangelen på et overordnet design som det ene yderpunkt, og overspecifikation som det andet yderpunkt.

Mangelen på overordnet design fører til, at der hele tiden bliver "skåret hjørner". Overspecifikation fører til, at det væsentlige går tabt i formalisme.

Denne balancegang er det vanskeligste aspekt ved softwareudvikling, og samtidig det punkt hvor talent og erfaring tydeligst kommer til sin ret.

Softwareudvikling og vedligeholdelse skal kunne foregå i en organisation, hvor der løbende sker ændringer i personalesammensætning, strategisk retning og ledelsesstruktur.

Men på den anden side er det heller ikke en løsning at opbygge et større system uden en eller anden form for formel struktur og dokumentation.

Det er en balancegang styret af den "sunde fornuft". Den enkeltes dilemma består i, at man skal vælge, hvornår man skal være kreativ, og hvornår man simpelthen bare skal "gøre det efter bogen".

Det er ikke en løsning at opsplitte softwareudviklingen i en række delaktiviteter, som udføres af forskellige personer. Det er vigtigt, at analyse, design og implementation ikke bliver betragtet som adskilte delaktiviteter, og at de involverede systemudviklere deler en "kultur", som sætter dem i stand til at kommunikere effektivt.

Den bedste måde til overføring af mere subtile detaljer om projektet er inde i en persons hoved (hjerne)!

Ofte er der allerede fremstillet så meget papirarbejde (dokumentation) vedrørende projektet, at ændringen af denne dokumentation vil vare betydelig længere end ændringen af koden. Hvis systemudvikling får lov til at udvikle sig sådan, har papirarbejdet udviklet sig til at være det største problem i softwareudviklingen.

At beslutte hvilke egenskaber, der er ønskelige - eller endnu bedre: at give en relativt simpel anvisning på hvordan man beslutter, hvilke egenskaber der er ønskværdige - er ofte den vanskeligste del af et projekt.

Når det bliver gjort godt, er det som regel resultatet af en enkelt indsigtsfuld persons indsats - og det kaldes ofte for en vision.

Anvendelse af eksisterende systemer som modeller for nyt design er reglen snarere end undtagelsen. Det er sundt, at man på denne måde får indskrænket valgmulighederne.

Softwareudvikling er svært, og man har brug for al den hjælp, man kan få.

Ved begyndelsen af et ambitiøst udviklingsprojekt ved man ikke, hvordan det vil være bedst at strukturere systemet. Tit ved man heller ikke præcist, hvad systemet skal kunne, fordi detaljerne vedrørende systemet først bliver endeligt afklaret i forbindelse med udarbejdelsen af systemet.

Men da man er nødt til at have en eller anden form for rettesnor, for at kunne identificere, hvilke designbeslutninger der er væsentlige, og for at kunne vurdere konsekvenserne af disse beslutninger, må man udføre nogle eksperimenter.

I langt de fleste tilfælde er design en social aktivitet, hvor designet udvikles gennem præsentationer og diskussioner.

Et eksperiment udføres ofte i form af en prototype. Ved hjælp af prototyper udforskes design- og implementeringsvalg.

Udført rigtigt er dette en meget succesfuld strategi; men den kan også være en undskyldning for sjusk. Målet med at lave en prototype er den indsigt, som arbejdet med udviklingen giver - ikke prototypen selv.

De fleste mennesker gør, hvad de får besked på. Det er kun ekceptionelle systemudviklere, som vil risikere deres karriere ved at sige, hvad de mener er det rigtige på trods af ledelsens opfattelse.

Hvis man vil opnå en radikal ændring i programmeringsstil, er man nødt til at lave tilsvarende ændringer i ledelsesstrategi. Mental og organisationel inerti er en trussel mod forandringer.

Personer og organisationer er ofte meget optaget af "at gøre det rigtigt". Det fører desværre ofte til, at almindelig sund fornuft bliver "glemt" i forsøget på at finde den rigtige metode.

Standardisering kan være en afgørende succesfaktor i større projekter; men det bør ikke føre til, at man forsøger at presse en standardisering ned over et mindre projekt. Det kan føre til absurde begrænsninger og ekstra omkostninger, hvor papirarbejdet erstatter produktivt arbejde som mål for fremskridt og succes. Hvis det kommer så vidt, forlader de "rigtige" systemudviklere projektet og bliver erstattet af bureaukrater.

Man må overlade det til en enkelt eller nogle få at beholde det totale overblik over projektets mål.

Meget afhænger af de enkelte systemudvikleres evner. Ledelsen glemmer tit, at organisationen består af enkelte individer. Det er populært at sige, at alle programmører er ens og derfor udskiftelige. Det gælder i hvert fald kun, hvis programmørerne ikke udnytter deres evner fuldt ud.

4.3 Paul Lindgreens systemanalyse

Under vignetten: "The truth will wait for you" starter Paul Lindgreen sin analyse af softwarekrisen, som han giver følgende baggrunde for:

de mest påtrængende problemer gives ikke højest prioritet.

edb-systemerne er for stive, og afspejler ikke den virkelighed, hvor de skal benyttes.

medarbejderreaktioner på edb-systemets resultater fører til yderligere fejlsituationer.

datamatens potentiale udnyttes dårligt.

edb-systemet er implementeret, så det er svært at rette fejl og uhensigtsmæssigheder.

uhensigtsmæssighederne betyder, at ulemper og omkostninger totalt set overstiger den lokale besparelse.

Paul Lindgreen nævner tre årsager hertil:

edb-fortalerne har den opfattelse, at det ikke er særligt svært at fremstille datamatiske systemer. Man har jo metoderne og værktøjerne. Vægtningen mellem det antal projekter, der igangsættes og investeringerne i maskinel kontra de ressourcer, der afsættes til en forudgående analyse af systemets totale virkning på organisationen, er ikke i harmoni.

Der fokuseres for meget på teknikken, og de datamatiske tænkemåder dominerer udviklingsforløbet på bekostning af alt andet.

Datamatanvendelse er så ny en foreteelse, at erfaringer og teori ikke har kunnet nå at manifestere sig. Manglen på indsigt giver plads for tro på dogmer.

Der har naturligvis været ønsker fra organisationen om at få indflydelse på det datamatiske systems udformning. Denne brugerdeltagelse har i mange tilfælde kun ført til en form for gidseltagning, idet brugeren ikke har været med til at sætte dagsordenen.

Tendensen forstærkes iøvrigt af, at prisen på maskinel falder, hvorimod udviklingsomkostninger er stigende i systemer med stigende kompleksitet.

Vor fælles viden om systemudvikling begrænses yderligere af nye smarte tekniske måder at understøtte systemudvikling på.

Fra opfindere eller sælgere af nye produkter eller fra branchens guruer lyder det hele tiden: "Prøv denne metode. Spild ikke tiden på problemet. Her er løsningen!".

"Mange falder for det letkøbte og opdager for sent, at man måske burde have tænkt lidt mere - at det måske nok er en løsning, man får, men ikke nødvendigvis på det mest fremherskende problem, eller man får forstørret det oprindelige problem". [Paul Lindgreen "Systemanalyse" s. 31]

Sandheden om datalogien er ifølge Paul Lindgreen, at datalogien arbejder sig baglæns igennem problemstillingen, således at boolsk algebra er fuldt ud beskrevet, medens man først for nylig har fået hold på sproglige fænomener, som entydige og flertydige sprog.

Hvor datalogien kan siges at have sit udspring i det naturvidenskabelige område, ligger systemudvikling i grænseområdet mellem det naturvidenskabelige og det samfundsvidenskabelige område.

Erkendelse tager tid. Der går mange år, før erfaringer empirisk udkrystalliseres i brugbare regler og modeller, og normalt vil disse modeller først meget senere blive underbygget med en videnskabelig forklaring.

Det kræver normalt også en vis stabilitet, d.v.s. længere perioder, hvor de samme vanskeligheder er fremherskende, og hvor de samme paradigmer er gældende.

Disse stabile vilkår har desværre endnu ikke været gældende på edb- og systemudviklingsområdet.

Af yderligere problemer nævnes sammenblanding af begreber som:

data og information.

udviklingsmodel og projektstyringsmodel.

metode og værktøj.

adgang til værktøjer og beherskelse af værktøjet.

værktøjer til forståelse og værktøjer til dokumentation.

virkeligheden selv og forskellige opfattelser af virkeligheden.

I et afsnit med overskriften "Myter og Illusioner" gør Paul Lindgreen op med forkerte forestillinger og forældede principper.

Det er relativt let at igangsætte og gennemføre projekter. Alligevel oplever man gang på gang, at ideer sælges, udgifter budgetteres, konsekvenser vurderes, projekter igangsættes og ressourcer afsættes ud fra forestillingen om, at det hele er relativt let og ligetil. Man forestiller sig, at det kan gøres på kort tid, og at det ikke koster ret meget.

Manglende kvalififikationer og erfaring kan få et ethvert projekt afsporet. Det er desværre ikke særligt ualmindeligt, at man sætter novicer til at gennemføre større projekter på egen hånd.

Planer tager ikke højde for gentagelser og fejl. Ledelsen bør planlægge ud fra principper om, at fejltagelser og iterationer i udviklingsarbejdet er det normale, mens tilfredsstillende afslutning af en aktivitet er undtagelsen. De fleste lever i en illusion om det modsatte.

Forventningerne om at venstrehåndsarbejde fra de involverede brugerrepræsentanter er tilstrækkeligt til at gennemføre et tilfredsstillende projekt.

En af Paul Lindgreens hovedkonklusioner er, at det på nuværende tidspunkt ikke er rimeligt som professionel seriøst at foreskrive systemanalysemetoder.

Det bør man ikke gøre, før man har fået mere erfaring med de virkelige problemer, og frem for alt ikke før man har fået langt mere indsigt i de underliggende begreber. [Paul Lindgreen "Systemanalyse" s. 506].

Man skal altid være tilstrækkelig ydmyg overfor de begrænsninger, der ligger i den formalisering, beskrivelserne bygger på. Disse begrænsninger skyldes bl.a., at et så ungt fag som systemudvikling endnu ikke har en gennemarbejdet og accepteret teori for fagområdet, ligesom den empiriske begrebsafklaring heller ikke er overstået endnu.

Paul Lindgreen udtrykker dyb skepsis overfor standardmetoder. Her følger hans skudsmål for nogle af dem.

Eksperimentel systemudvikling som alternativ bliver forkastet af følgende grunde:

Integrerede systemer blev kraftigt udfordret af decentrale systemer, hvilket førte til 4. generations værktøjer, der muliggjorde eksperimentel systemudvikling.

Fascinationen ved den hurtige frembringelse af datastøttede funktioner, får folk til ukritisk at give efter over for fortalerne.

Man overser, at eksperimentel systemudvikling som princip ikke er et alternativ til integreret systemudvikling - den udviklingsform, hvor man ser på organisationen som et hele.

Der er intet holdbart argument for, at medarbejderne bedre eller hurtigere skulle erkende og forstå deres arbejdsopgaver og funktionelle betydning i organisationen ved at interessere sig for nye måder, at lave den databehandlingsmæssige del af arbejdet på. I de fleste tilfælde udfører medarbejderen jo andet end det, der kan udføres af datamater.

Det er ikke sikkert at medarbejderens viden er bevidst, og uden videre kan formuleres og nedskrives. Desuden påpeges den svaghed, der kaldes "ølkassesyndromet", hvorved man forstår, at en løsning videreføres i andre sammenhænge, hvor den ikke nødvendigvis er velegnet.

Endelig påpeges svagheden ved lokal optimering, hvorved fordele et sted (der hvor der eksperimenteres) kan skabe større ulemper andre steder, hvor de først erkendes langt senere. [Paul Lindgreen "Systemanalyse" s. 41-42].

Formalisme betragtes ofte som en mere videnskabelig fremgangsmåde end mere uformelle metoder. Det er da også rigtigt, at der sikres en konsekvent og systematisk behandling af problemstillingen.

I sig selv garanterer det dog ikke, at beskrivelsen bliver god i den sammenhæng, den skal anvendes.

Der sikres heller ikke nødvendigvis, at den virkelighedsopfattelse, der ligger bag formalismen er korrekt.

Man skal anvende formalismen korrekt på en kvalificeret måde. Paul Lindgreen skriver på side 82: "Egentlig kan man ikke udtrykke sig mere præcist ved at anvende særlige formaliserede udtryksformer. Når alt kommer til alt, hviler det alligevel kun på intuition og fornemmelse. Den matematiske notation for eksempel, som de fleste opfatter som et slags højdepunkt, når det drejer sig om at udtrykke sig præcist, er ultimativt kun baseret på uformelle udsagn i alment sprog. I virkeligheden er enhver formalisme en umulighed".

Årsagen hertil forklares som den gentagne definition af de bestandele, der definerer et højere niveau.

Ifølge Paul Lindgreen gælder om den oprindelige og i Danmark mest anvendte udgave af metoden struktureret analyse det grundlæggende princip, at data "flyder" mellem processer.

Endvidere gælder, at enhver proces kan nedbrydes til processer på lavere niveauer med tilsvarende datastrømme på disse niveauer.

Der er ikke redegjort for et teoretisk grundlag for metoden, men søger man at uddrage elementerne af en model, må opfattelsen blive den besynderlige, at såvel datastrømme som processer er kontinuerte, og at begge dele sker, uden at nogen eller noget udfører aktiviteterne. [Paul Lindgreen "Systemanalyse" s. 35].

Paul Lindgreen fremsætter selv en systemmodel, hvortil der er konstrueret et systemsprog, som definerer typer, klasser, begreber og notationsformer, på en måde der er mere præcis og dækkende end det almindelige sprog.

Det nærmeste Paul Lindgreen kommer en anbefaling af en metode, er de meget generelle anvisninger:

Vær opmærksom på "verdensbilledet".

Hav fokus på organisationen.

Betragt organisationen som en helhed. Systemudvikling bør anskue aktører som kommunikerer indbyrdes.

Udviklingsmodellen består af 3 hovedaktiviteter:

Analyse af eksisterende forhold.

Afgrænsning af problemer og beslutningstagning vedrørende ændringer.

Konstruer forbedrede og evt. datamatstøttede forretningsgange.

Herved opnår man at:

udvikling indebærer formålsrettet ændring

formålsrettet ændring følger dybtgående analyse

kreativitet tilgodeses ved åbenhed

udviklingen er baseret på planlagte iterative forløb.

Det sidste er vanskeligt at planlægge, for hvordan kan man på forhånd vide, om omkostningerne ved en ny iteration er større end værdien af den indhøstede erfaring?

På en konference for datamatikerlærere 30/9 til 1/10 1992 gav Paul Lindgreen udtryk for, at de kendte systemudviklingsmodeller efter hans mening havde spillet fallit, og at man i stedet burde søge efter de mere generelle principper, der lå bag system- og organisationsbegreberne.

Herved ville man komme frem til en erkendelse af, at mange af de principper, som man i dag antager for at være generelle i virkeligheden er specialtilfælde af endnu mere generelle principper.

4.4 Professionel systemudvikling

En af de få tilgængelige undersøgelser af systemarbejdet i det virkelige liv findes i bogen Professionel Systemudvikling, som bl.a. er et resultat af MARS-projektet. MARS-projektet står for "Metodiske ARbejdsformer i Systemudvikling".

Projektet er udført af forskere og studenter på Datalogisk Afdeling, Aarhus Universitet og Institut for Geografi, Samfundsanalyse og Datalogi, Roskilde Universitets Center i samarbejde med systemudviklere på Jydsk Telefon Aktieselskab, Regnecentralen af 1979, Sparekassernes Datacenter og ØK Data.

I bogens afsnit om ideal og virkelighed beskrives et af paradokserne i systemudvikling. Paradokset består i, at der eksisterer en opfattelse af, at der eksisterer fælles, klare mål for et projekt.

I paradokset indgår også forestillingen om den rationelle systemudvikler. I virkeligheden går det ofte anderledes, idet man starter systemudviklingen uden at have klart definerede mål, og man træffer derfor ofte designbeslutninger på et utilstrækkeligt grundlag.

Dette skyldes fundamentale forhold som :

Brugerorganisationen kan ikke beskrive sine ønsker på forhånd.

Sent kendskab til væsentlige detaljer kan kræve projektændringer.

Kompleksiteten af problemstillingen kan kræve eksperimenter for at opnå tilstækkelig forståelse.

Projekt-eksterne forhold og menneskelige fejl kan kræve ændringer.

Er man ikke opmærksom på disse forhold kan man meget vel miste kontrollen med projektet.

En anden vigtig faktor, man bør være opmærksom på, er den usikkerhed, der råder i en given udviklingssituation. Der skelnes mellem forskellige grader af usikkerhed og imellem det at være i en kendt eller mindre kendt situation.

Dette skal sammenholdes med udviklernes erfaring og bør påvirke valget af arbejdsform. Der er et konstant samspil mellem situationer, arbejdsformer og betingelser.

Det er således et gennemgående træk i bogen Professionel Systemudvikling, at man ikke tror på nogen kogebogsmetode, når det gælder systemudvikling.

Man gør sig også nogle overvejelser om systemudvikleres kvalifikationer, idet denne skal kunne beherske mange dicipliner. Systemudvikling er en flerfaglig diciplin.

En systemudvikler skal bl.a. beherske de matematiske sider af programmering, de sociologiske sider af organisationsudvikling og de psykologiske sider af udformning af brugergrænseflader.

En systemudvikler skal være en dygtig designer, der kan sætte nye ting sammen, en dygtig analytiker, der kan sætte sig ind i andres arbejdssituation, og en dygtig politiker, der kan håndtere et projekt præget af usikkerhed og konflikter.

Der siges i bogens forord:

"En systemudvikleres virkelighed er præget lige så meget af problemer, fejl og konflikter som af succes og fremgang. Et af de vigtigste aktiver i et systemudviklingsprojekt er erfaring. Systemudvikling er en kreativ aktivitet, hvor det er vigtigt at forestille sig muligheder. Målet med bogen er at udvide systemudviklernes egen opfattelse af deres muligheder for at handle. Et andet mål er at inspirere og provokere til forandringer af arbejdsformen som et skridt imod en idealtilstand."

Et andet vigtigt aspekt er, at en enhver systemudvikling er en erkendelsesproces, hvor der skal læres om de tekniske og organisatoriske muligheder. Erkendelsesprocesser kan ikke reduceres til rutinearbejde, de kræver eksperimenter, åbenhed og inspiration. ["Professionel systemudvikling" s. 61]

En professionel systemudvikler er både stolt over de muligheder, der ligger i faget, og ydmyg over for dets begrænsninger.

Professionelle systemudviklere tilrettelægger arbejdsformen ud fra situationen ved at vælge blandt det repertoire af teknikker de råder over.

Der findes ingen standardmetode, der løser alle problemer; men det er muligt at vælge en metode og ud fra den tilrettelægge arbejdsformen i det enkelte projekt.

Det bliver desuden pointeret, at systemudviklerne skal være opmærksomme på projektets omgivelser og skart skelne mellem :

det produktrettede kontra det procesrettede,

det reflekterende kontra det forandrende,

det eksisterende kontra visionerne.

["Professionel systemudvikling" s. 47]

Analyse resulterer i forståelse, design i visioner og realisering skaber forandring. Analyse, design og realisering er derfor aktiviteter, der forudsætter hinanden, og de bør derfor også udføres i gensidigt samspil.

Kvaliteten af analysen er afhængig af samarbejdet med brugeren. Godt design handler om at kunne flyve højt med begge ben på jorden.

Teknisk orienteret analyse kan føre til perfekte løsninger på de forkerte problemer. Kvalificeret analyse og design kræver såvel teknisk som organisatorisk og social kompetence og forskellige perspektiver. Man kan ikke bevæge sig ensidigt fra helhed mod detalje, eller fra detalje mod helhed. ["Professionel systemudvikling s.53]

En systemudviklingsmetode bør karakteriseres gennem dens anvendelseområde, gennem det bagvedliggende perspektiv og gennem selve retningslinierne for processen. Retninglinierne omfatter teknikker, værktøjer og principper for organisering af arbejdet. ["Professionel systemudvikling" s. 63]

4.5 Gerald Weinbergs "General Systems Thinking"

I bogen "Rethinking Systems Analysis and Design" fremkommer Gerald Weinberg med en række iagttagelser af de præmisser, hvorunder systemudvikling foregår. Disse iagttagelser udgør samtidig en mulig forklaring på softwarekrisen.

Indtil for få år siden bestod systemudviklerens arbejde i at konvertere eksisterende - ofte manuelle - systemer til ny teknologi; men arbejdet har siden ændret karakter, fordi systemudviklerens opgave nu ofte består i at anvende den ny teknologi til at udvikle systemer, som kan udføre funktioner, der var utænkelige i et manuelt system.

Heraf følger uvægerligt en stigende kompleksitet, som så igen fører til en øget fejlhyppighed, forsinkelser og budgetoverskridelser.

Efterhånden vil disse forhold blive opdaget af ledelsen, som vil søge efter forklaringer på problemerne. Ofte henføres problemerne til forhold som manglende arbejdsprocedurer, dårlig motivation hos medarbejderne eller manglende kvalitetskontrol.

Weinberg mener nok at disse faktorer har en vis indflydelse; men den virkelige årsag er og bliver kompleksiteten.

En anden vigtig iagttagelse er, at de involverede mennesker - i form af brugere og andre interessenter - også bidrager til kompleksiteten.

En af de vigtigste lovmæssigheder, der styrer menneskelig adfærd, er loven om menneskelig inerti (også kaldet loven om modstand mod forandring). I betragtning heraf er det efter Weinbergs mening yderst vigtigt, at en kommende systemudvikler i højere grad studerer menneskelig adfærd fremfor teknologiske løsninger.

En tredie iagttagelse vedrører, hvordan man som menneske kan håndtere kompleksiteten. Omkring systemanalyse kan man sige, at erfaringen har vist, at det, der er bedst til håndtering af uoverskuelig kompleksitet er en kombination af

erfaringer fra analoge situationer udenfor den aktuelle situation.

erfaringer for, hvordan mennesker tænker, og kombinerer denne tænkning med facts og forudfattede meninger, når der skal vælges en passende handling.

Weinberg kalder studiet af forholdene omkring disse iagttagelser for "General Systems Thinking".

Et spørgsmål, man som underviser i systemudvikling bør stille sig, er, hvad skal en god systemudvikler egentlig kunne? Weinberg angiver som svar hertil en række egenskaber, der kendetegner en god systemudvikler:

De vigtigste dimensioner i systemudvikling er defineret ved de mennesker, der er involveret i systemet, enten som dem, der som systemudvikleren selv påvirker det, eller som dem, der som brugeren påvirkes af det. Det menneskelige aspekt spiller en stor rolle.

Identifikation af påvirkende og påvirkede faktorer er en af de vigtigste opgaver.

Man skal kunne skelne mellem væsentligt og uvæsentligt.

Iblandt det, der skilles fra som værende uvæsentligt, vil der givetvis være en masse interessante løsninger på alverdens problemer; men systemudvikleren er hverken politiker eller filosof, han er blot en person, som lever af at udarbejde specifikke handlingsplaner, og som ofte er med til at realisere og justere disse planer.

Man skal kunne absorbere store mængder nyt stof på kort tid. Denne evne sætter systemudvikleren i stand til at bevæge sig hurtigt til helt nye områder af viden, og i løbet af en ugestid at begynde at tale med i områdets terminologi på en kompetent måde. Studier af naturlige sprog antages at lette indlæring af ny viden. Studiet af matematik anses for at være nødvendigt, hvis ikke systemudvikleren skal blive intimideret af de skyer af matematisk tåge, som omgiver visse videnområder.

Det er væsentligt, at man er i stand til at observere omhyggeligt og præcist. Det er en god teknik at lade systemudvikleren leve sig ind i et problemområde, for på den måde at undgå, at man observerer ud fra forudfattede meninger.

Man skal kunne udføre selvransagelse og refleksion over ens egen rolle og adfærd i forbindelse med systemudvikling. Weinberg er i tvivl om, hvorvidt denne evne kan læres, eller om den er en del af en persons karakter.

Om de strukturerede metoder udtaler Weinberg sig skeptisk. Hans konklusion efter at have gennemført mere end 1000 formelle og uformelle interviews med professionelle systemudviklere er, at effekten af de strukturerede metoder er langt mindre end pressen og flere af branchens guruer vil have os til at tro.

Undersøgelserne har bl.a. vist, at der er vidt forskellige meninger om, hvad begrebet "velstruktureret" egentlig indebærer. Der er også en klar tendens til, at den enkelte endog har svært ved at leve op til sine egne normer.

4.6 Egne iagttagelser

Når man taler med professionelle systemudviklere om, hvordan de udfører deres arbejde, skal man være opmærksom på, at de ofte vil være påvirket af at have modtaget ganske omfattende undervisning i forskellige formelle systemudviklingsmetoder.

Det kræver desuden et vist personligt mod at stå frem med kritik af de metoder, som der skrives og tales så meget om i branchen.

Danske systemudviklere er generelt veluddannede, og kender ofte flere af de systemudviklingsmetoder, som er beskrevet i kapitel 3 i denne afhandling.

I praksis er brugen af de formelle systemudviklingsmetoder dog ikke særlig udbredt. På trods af den massive markedsføring af de formelle systemudviklingsmetoder, tvivler de professionelle systemudviklere altså på, at metoderne i praksis kan holde, hvad der loves.

En anden vigtig iagttagelse, som mange systemudviklere har gjort, er, at det ofte er de samme personer, der kommer med de bedste og mest kreative ideer, når nye systemer skal udformes.

Om der er tale om en medfødt evne for at være kreativ, eller om det er en færdighed, som kan læres, vides ikke. Mange systemudviklere er end ikke i stand til at diskutere, hvad der egentlig sker i deres hjerner, når de løser problemer. Det hænger sammen med, at der ikke er nogen tradition for at uddanne kommende systemudviklere i det at være reflekterende over egne evner og muligheder.

Indlagt 27. april 1997