2. PROCESSERNE - Teknologisk Institut

I dette kapitel vil vi kigge nærmere på processerne: dels selve projektledelsesprocessen, 

dels udviklingsprocessen som er den måde man udvikler software på, og endelig de 

læreprocesser som er involveret. Projektledelse er nemlig en multiperspektivisk disciplin. 

2.1 De mange perspektiver 

2. PROCESSERNE 

En historie som ofte bruges til at beskrive nødvendigheden af et multiperspektivisk syn, 

er historien om de blinde mænd og elefanten. Den stammer fra et digt af den amerikanske 

digter John Godfrey Saxe (1816-1887) som igen baserer sig på en gammel indisk fortælling. 

Digtet er langt, så her genfortælles det kun (find det evt. selv på nettet): 

De blinde mænd og elefanten 

Seks blinde mænd bliver præsenteret for en elefant. Den første ramler ind i siden på dyret og 

udbryder: – En elefant er som en mur. Den næste kommer til at føle på stødtanden og mener 

at en elefant er som et spyd. Den tredje føler på snabelen og udtaler kategorisk at en elefant 

er som en slange. Den fjerde får fat i et ben, så en elefant må være som et træ. Den femte 

rører ved øret og er overbevist om at der er tale om en vifte, mens den sjette som rører 

halen, synes at en elefant er som et reb. Herefter skændes de så om hvordan en elefant 

egentlig er. 

Projektledelse er ligesom en elefant: det afhænger af den vinkel man ser det fra, og et 

perspektiv (eng.: view) er netop en synsvinkel, dvs. måden at se tingene på ud fra et bestemt 

ståsted. Overordnet kan vi anlægge tre hovedperspektiver: 

– PRODUKTPERSPEKTIVET ser projektet som noget der skal frembringe et produkt med 

bestemte egenskaber. 

– INTERESSENTPERSPEKTIVET eller samarbejdsperspektivet ser projektet som et samspil 

mellem mennesker. 

– PROCESPERSPEKTIVET ser projektet som en løbende proces der bringer os fra en situation 

til en anden. 

2· PROCESSERNE | 29

Herunder kan anlægges forskellige specialperspektiver som typisk afhænger af hvad 

man mener er vigtigt i projektet: 

– STYRINGSPERSPEKTIVET ser projektet som en række aktiviteter der gennemføres i en 

nærmere planlagt rækkefølge. 

– FORRETNINGSPERSPEKTIVET ser projektet som et middel til at understøtte virksomhedens 

forretning. Her kan der f.eks. være fokus på effektivisering og profitmaksimering. 

– BRUGERPERSPEKTIVET ser projektet som noget der skal opfylde brugernes behov. Her 

drejer det sig om at involvere brugerne i projektet, brugbarhed og brugervenlighed 

osv. 

– LÆRINGSPERSPEKTIVET ser projektet som en række læreprocesser hvor vi gradvist bliver 

klogere mht. de forskellige dele. 

– KVALITETSPERSPEKTIVET ser projektet som en række delprodukter som hver for sig 

skal leve op til aftalte kvalitetskriterier. Her er der fokus på inspektioner og test. 

– INFORMATIONSPERSPEKTIVET ser projektet som en række informationer (data) som 

skal indsamles, gemmes og behandles. 

– ARKITEKTURPERSPEKTIVET ser projektet som en struktur opbygget af en række komponenter 

der arbejder sammen. 

osv. 

Nogle af disse perspektiver kan være sammenhængende, men de afspejler hver for sig 

en måde at opfatte projektet på, et ståsted at se det fra, et verdensbillede. Man ser det 

samme projekt, men fra vidt forskellige synsvinkler. Nogle af perspektiverne kan bruges 

til at drive projektet, dvs. til at styre hvad der skal ske hvornår. Der er således udviklingsmodeller 

som er use case-drevne, arkitekturdrevne eller risikodrevne. 

Ligesom med de blinde mænd er alle perspektiverne en del af helheden. Og det er 

en god ide at bruge flere perspektiver. Forskellighed gør stærk. Vi vender senere tilbage 

til disse specialsyn i afsnittet om Interessentanalyse. 

Disse perspektiver kan også have andre navne, f.eks. dimensioner, aspekter, facetter, 

parametre, fokusområder eller discipliner. 

2.2 Andre brancher 

Mennesker organiserer udviklingsprocessen på mange forskellige måder, afhængigt af 

hvad man skal lave. Alligevel er der visse fælles træk, og man kan lære meget af at se 

hvordan andre gør, så lad os starte med at se hvordan man griber udviklingsprocessen 

30 | 2 · PROCESSERNE

an uden for it-branchen i nogle af de brancher som man ofte sammenligner it-udvikling 

med. Se i øvrigt også det senere afsnit om Store ledere (side 68). 

Brobygning 

Ofte sammenlignes it-udvikling med brobygning. Ikke, at vi i it-branchen skal falde på 

halen for de dygtige brobyggere der kan levere til tiden, bare “sådan lige” og helt uden 

problemer. For det kan de som bekendt ikke. Fejl, dårlig kvalitet, fordyrelser og store 

forsinkelser finder også sted i brobygningsbranchen. Jf. Storebæltstunnelen der først 

blev oversvømmet og siden brandhærget (havde det så endda blot været samtidig!). Alligevel 

kan it-udviklere lære meget af brobyggere. 

Tacoma-broen 

I staten Washington i det nordvestlige USA havde man bygget 

en hængebro over Tacoma-snævringen, Tacoma Narrows 

Bridge. Det var en af de første hængebroer, så man havde ikke 

mange erfaringer med denne brotype. Den 7. november 

1940 gik det helt galt. Når vindhastigheden bliver for høj, kan 

hængebroer nemlig sættes i en voldsom kombination af vridninger og lodrette svingninger 

(såkaldt flutter). Dette kan forhindres ved at gøre brodækket tilstrækkeligt vridningsstabilt. 

Imidlertid havde designeren af Tacoma-broen – i øvrigt på trods af advarsler – valgt en mindre 

vridningsstabil løsning for derved at gøre broen billigere. Broen blev simpelthen vredet 

itu og faldt ned. Heldigvis kom ingen mennesker noget til (har du ikke set de spektakulære billeder, 

findes der videoklip på nettet). Brobyggerne lærte en masse af den historie, og i dag er 

det normalt at den slags anlæg testes i en vindtunnel, så man ved hvordan de opfører sig i 

blæsevejr. Tilsvarende burde det være helt normalt at alle større it-systemer gennemgik performancetest 

og test i et brugervenlighedslaboratorium før de blev sluppet løs. 

Et af de steder hvor it-udvikling adskiller sig mest fra brobygning, er at vi ofte har muligheden 

for at udvikle systemerne i mindre bidder. Som bekendt kan man ikke starte en bro 

med et frit spænd på 1.600 meter ved at sige: “Nu lægger vi lige en planke over, og så tager 

vi det lidt ad gangen”. Og når ankerblokkene er støbt i mange tusind tons beton, kan man 

heller ikke lige komme og bede om at få dem flyttet et par meter mod nord. Men ved udvikling 

af et it-system kan man som regel lave det i en iterativ proces hvor man i gentagne 


delleverancer føjer mere og mere funktionalitet til systemet. Denne teknik åbner desuden 

mulighed for at måle på kvaliteten af systemet undervejs. Desværre åbner fastpriskontrakter 

sjældent mulighed for en sådan iterativ proces, og det er egentlig synd – for alle parter. 

Men der er ikke noget i vejen for at en fastpriskontrakt kan stille krav om kvalitetsmålinger 

undervejs (se historien side 329 om Øresundsbroens pyloner). 

Ofte bruges ingeniørdisciplin generelt som metafor for it-udvikling. Tidligere talte 

man ligefrem om “software engineering”. Det vi kan lære af ingeniørernes tilgang, er 

den detaljerede planlægning før vi går i gang (i det omfang det er muligt) samt den 

præcise kvalitetsstyring undervejs. Og at vi skal kende vores teknikker før vi bruger 

dem i stor skala. Man skal kravle før man kan gå. 

Krigskunst 

Ordet “kunst” i denne forbindelse, hvor det handler om at slå mennesker ihjel, er ilde 

valgt. Alligevel er det den betegnelse man sommetider ser anvendt af dem som gør sig 

tanker om det at føre krig. Ofte drages også paralleller mellem krigskunst og it-udvikling. 

Sammenligningen er forståelig. Begge dele handler om at: 

– gennemføre en – ofte svær – opgave som ikke er prøvet før 

– mange menneskers koordinerede indsats er nødvendig 

– planlægning, koordinering og kommunikation er essentiel 

– handlekraft når virkeligheden viser sig at være anderledes end planerne, er lige så 

essentiel 

– ord som strategisk, taktisk og operationel er anvendelige til at anskue processen fra 

forskellige detaljeringsniveauer. 

Og så kan vi lære noget fordi tingene bliver tydeligere (mere accentuerede) når de kommer 

ud i ekstremerne. I [Munk-Madsen96] fremhæves således et af de vægtigste militærteoretiske 

bidrag i moderne tid, von Clausewitz’ bog “Vom Kriege”, der beskriver 

strategiens betydning ved ledelse af vanskelige og usikre opgaver. Det var her forståelsen 

af krigen som politikkens fortsættelse blev introduceret. Her slås det bl.a. fast at vi 

ikke kan planlægge i detaljer præcist hvordan slaget vil forløbe – der er for mange 

ukendte faktorer, og virkeligheden ser alligevel altid helt anderledes ud end vi tror. 

Det vi ikke bør lære af krigskunsten, som den er praktiseret op gennem historien, er 

den militæriske kadaverdisciplin og kæft-trit-og-retning-mentalitet hvor en ordre skal 

følges, uanset hvad. Det virker sjældent på it-udviklere som bare kan tage deres gode 

tøj og gå over til et andet firma. Og som man i den moderne militærverden har erkendt, 

virker det heller ikke på nutidens soldater. 


Flyvning 

Der er mange lighedspunkter mellem en flypilot og en projektleder: 

– begge har det overordnede ansvar for opgaven 

– ingen af dem kan løse opgaven tilfredsstillende uden andre 

– ingen af opgaverne kan løses uden dem 

– begge er underlagt højere myndigheder i udførelsen af opgaven 

– det er i dårligt vejr og med brand i den ene motor at de for alvor skal vise hvad de dur til. 

Det vi kan lære af piloterne, er den udelte opmærksomhed på at materiellet og forudsætningerne 

er på plads, gennemprøvede og i orden inden vi går i gang. Også brugen 

af tjeklister og fornuftige systemer som løbende forbedres når vi opdager fejl og 

uhensigtsmæssigheder. 

Det vi ikke bør lære, er de nøje fastlagte flyruter som moderne flyvning gør brug af. 

Hertil er it-udvikling for uforudsigelig. 

Filmproduktion 

Når der skal produceres en film, skal man først have en god historie: den fælles vision. 

Her bruges et story board (opfundet af Walt Disney til brug ved tegnefilmproduktion). 

Der laves detaljerede planer for optagelser af de enkelte scener. Ofte i total forvirring i 

forhold til den færdige film. Skal der bruges to scener i den samme kulisse, men to forskellige 

steder i filmen, er det smartest at optage begge scener når man har hele holdet 

samlet det rigtige sted. Og så klippe det sammen senere. Men det kræver en detaljeret 

planlægning (scripting). Holdet forsøges også sammensat så optimalt som muligt i en 

casting hvor man finder de bedste skuespillere til rollerne. 

Så her kan vi lære noget om detaljeret planlægning af de enkelte scener (i it-sammenhæng: 

planlægning af de enkelte iterationer), men sandelig også om nødvendigheden af 

improvisation undervejs. F.eks. når skuespillerne begynder at leve sig ind i rollen og 

kommer med ændringsforslag. 

Det vi ikke bør lære af filmproduktion, er at hele manuskriptet skal være detaljeret 

fastlagt inden vi går i gang. Det kan kun sjældent lade sig gøre ved it-udvikling. 

Planteavl 

Selv holder jeg meget af at betragte projektlederen som en gartner. Der er en række gode 

paralleller mellem gartneri og projektledelse: 

– Man høster som man sår. Dvs. udbyttet er afhængigt af de frø man starter med. 

– En god gødning er med til at få planterne til at udvikle sig. 


– Gartneren skal beskytte planterne mod angreb fra skadedyr. 

– Det betaler sig at forebygge angreb f.eks. ved sprøjtning. 

– Et godt (rod-)netværk er vigtigt for plantens vækst. 

– Mange planter elsker sol og varme. 

Af gartneren kan vi lære at tålmodighed og forudseenhed betaler sig. Gartneren kan ikke 

selv lave frugter, det kan kun planterne. 

2.3 Projektledelsesprocessen 

Selve projektledelsesprocessen er en generisk proces som det kan være hensigtsmæssigt 

at have gjort sig klart. Den vil vi se på i dette afsnit, og i det senere afsnit om Udviklingsprocessen 

vil vi se på hvordan den udmøntes til softwareudvikling. 

Vi skelner mellem ledelse og styring. Ledelse handler om at gøre de rigtige ting, 

mens styring handler om at gøre tingene rigtigt. Begge dele er vigtige at kunne for en 

projektleder. Men faktisk har vi tre niveauer: 

Fig. 2.1: De tre styringsniveauer 

For god ordens skyld skal du vide at denne trekant normalt bruges på hele virksomheden. 

Her bruger vi den dog “kun” på projektet. 

I “A guide to the project management body of knowledge” – den såkaldte 

PMBOK Guide fra Project Management Institute ([PMI2000]) – skelnes mellem fem 

projektledelsesprocesser: 


– OPSTART hvor projektet etableres 

– PLANLÆGNING hvor målet lægges fast, og kursen udstikkes 

– UDFØRELSE hvor arbejdet rent faktisk udføres 

– OPFØLGNING hvor det sikres at vi laver det vi aftalte 

– NEDLUKNING hvor projektet bringes til en kontrolleret afslutning. 

Denne opdeling kan også bruges på mindre faser i et større projekt. Og du vil kunne 

genfinde alle elementerne i de kommende kapitler. 

Der findes andre bud på en generisk projektledelsesproces, f.eks. den engelske 

PRINCE2 (bl.a. beskrevet i [Hughes99]). 

2.3.1 Kunsten at styre 

Når vi bruger ordet “styre”, har vi allerede en intuitiv fornemmelse af hvad der menes. 

Det er nærliggende at lave analogier til andre situationer hvor vi “styrer”, f.eks.: 

– når vi kører bil, styrer vi. Vi gør det for at komme det rigtige sted hen og for at komme 

uden om forhindringer 

– når man flyver, sidder der en pilot forrest i flyet og styrer det. 

Men styring er ikke bare at dreje på rattet. Styring involverer flere discipliner: 

Før turen: 

– Hvor skal vi hen? Der skal ske en fastlæggelse af målet. 

– Hvordan kommer vi det? Hvilken vej skal vi? Er der evt. risiko for uvejr eller andre 

forhindringer på en del af ruten, så vi skal lægge vejen udenom? Der skal ske en planlægning. 

– Hvor lang tid tager det? Der skal ske en tidsestimering. 

Undervejs: 

– Er der forhindringer forude? I bilen kan vi blot kigge ud ad forruden for at opdage 

eventuelle forhindringer. I fly kan vi bruge radar og automatiske landingssystemer, i 

ubåde kan vi bruge sonar osv. I projektet må vi også benytte os af indirekte metoder 

til at kigge fremad. Vi må “synliggøre” vejen foran os. Og det er betydeligt vanskeligere 

at synliggøre it-udvikling end mere fysiske fænomener (som f.eks. klippeskæret 

foran ubåden). Vi gør det i form af projektplaner, statusrapporter, reviews, kravspecifikationer, 

evalueringer osv. 


– Aktiv styring: drej på rattet når der skal skiftes kurs. I projektet foretages ændring af 

bemanding, ændring af opgaver, igangsættelse af nye aktiviteter osv. 

– Er vi hvor vi tror? Uforudsete ting kan bringe os ud af kurs (kastevinde, vildspor), og 

en gang imellem skal vi kontrollere at vi er der hvor vi tror vi er. Vi bruger her milepælene 

langs vejen eller andre kendingsmærker på landkortet. På havet, hvor der ingen 

kendingsmærker er, må vi navigere efter andre pejlemærker, f.eks. stjerner. Og i 

dag har de fleste installeret en GPS-navigator som bestemmer positionen ved hjælp 

af satellitter. I projektet må vi bruge de fastlagte tjekpunkter til at finde ud af hvor vi 

er. 

Efter turen: 

– Kan vi gøre det bedre næste gang? Her skilles de professionelle fra amatørerne. De 

sidste er glade for at være kommet frem, men de professionelle ved at de skal på den 

igen. Så de sætter sig ned sammen med kollegerne og diskuterer hvad der skete på 

turen, og om det var gået bedre hvis de havde handlet anderledes end de gjorde. Det 

gælder også i projektet hvor der skal foretages en projekt-evaluering når projektet er 

slut, for at finde ud af hvilke ting vi kan gøre bedre næste gang. 

2.3.2 Syvlagsmodellen 

Det kan være nyttigt at betragte selve styringsprocessen ud fra følgende “syvlags-model” 

som står for min egen regning (HIPEVOD-modellen): 

Fig. 2.2: Syvlagsmodellen 

36 | 2 · PROCESSERNE 

Lagnavn Aktiviteter 

Handlingslaget 

Informationslaget 

Planlaget 

Estimeringslaget 

Vilkårslaget 

Opgavelaget 

Domænelaget 

Styring 

Opfølgning, status 

Planlægning, tjekpunkter 

Bestemmelse af omfang 

Risikoanalyse, interessentanalyse 

Kravspecifikation 

Foranalyse

Hovedformålet med styringsaktiviteterne er at blive i stand til at foretage den egentlige 

styring (øverst i modellen) når det viser sig nødvendigt. Altså at ændre på prioritering, 

bemanding, planer osv. Det kan vi kalde handlingslaget. Her finder vi også aktiviteter 

som kontraktstyring, underleverandørstyring, kvalitetsstyring osv. 

Men for at kunne styre er det nødvendigt at have noget information at styre ud fra. 

Det får vi via det næste lag, informationslaget, som f.eks. forsyner os med rapporter 

indeholdende grafiske oversigter, tabeller og nøgletal for projektets status. Heraf kan vi 

f.eks. læse at en bestemt aktivitet er ved at blive forsinket i forhold til planen, og at en 

anden aktivitet der netop skal til at starte, godt kan vente uden derfor at forsinke projektet. 

Dette sætter os i stand til at træffe beslutningen (“foretage styringen”) om at ombemande 

således at hende der netop skulle til at starte på den ikke-kritiske aktivitet, i 

stedet hjælper med til at afslutte den kritiske. Men denne beslutning er vi kun i stand til 

at træffe fordi vi har vores rapporter, planer osv. 

For at vi kan frembringe informationerne i rapporterne, må vi tidligere have lavet 

en planlægning. Planerne er nemlig forudsætningen for at vi kan udtale os om hvorvidt 

en aktivitet er forsinket eller ej. Uden en plan ville vi ikke vide hvad aktiviteten var forsinket 

i forhold til. Bemærk i øvrigt at planerne næsten altid ændres undervejs fordi 

målet ofte flytter sig. 

Og en forudsætning for denne planlægning er nogle gode og realistiske estimater. 

Planerne bliver nemlig kun så realistiske som de estimater de baserer sig på. Estimeringen 

indgår ofte som en integreret del af planlægningen. 

En forudsætning for realistiske estimater og planer er kendskab til det vi skal lave 

samt de vilkår vi skal arbejde under. I vilkårslaget laver vi risikoanalyse og interessentanalyse 

for at få uddybet opgavebeskrivelsen (kravspecifikationen). 

I opgavelaget finder vi kravspecifikationen som handler om det det hele drejer sig 

om, genstanden for vores projekt, domænet med dets mennesker og/eller maskiner i 

den rigtige verden. 

Grunden til at så mange projekter er blevet forsinkede i tidens løb, er ofte at man 

har taget for let på ét eller flere af trinene i modellen. Hvis man f.eks. begynder med en 

utilstrækkelig kravspecifikation, vil dette forplante sig opad således at også tidsestimaterne 

bliver for små. Og dermed vil planerne ikke afspejle virkeligheden. Så når man 

styrer efter disse (for korte) planer, vil man selvfølgelig blive forsinket i forhold til dem. 

Når et projekt er forsinket, er det nemlig altid i forhold til en plan. Så i stedet for at 

tale om forsinkede projekter, burde man hellere tale om forkerte planer. Derfor er det 

vigtigt at de hele tiden holdes opdaterede. 

Ovenstående proces kan gennemføres ad flere gange, som vi skal se i det senere af- 


snit om iterative modeller. Den viste proces kan f.eks. benyttes til softwareudviklingsprojekter. 

Der findes andre projektledelsesprocesser til andre typer af projekter. 

Mestrer du alle de ovenstående lag, er der en god chance for at du vil undgå nogle 

af de værste katastrofer. For det er det bedste man kan opnå. Der kan ikke gives nogen 

kogebogsopskrift på hvordan man får succes hver gang. Men hvis du følger rådene og 

arbejdsmetoderne i denne bog, vil du aldrig komme helt galt af sted. 

2.3.3 Trekanten 

Traditionelt taler man om trekanten, bestående af tid, omkostninger og funktionalitet. 

Ideen er at man ikke kan nøjes med at ændre én af dimensionerne – de hænger uløseligt 

sammen. En klassisk projektledervits siger: “Jeg kan lave systemer billigt, hurtigt 

og med megen funktionalitet. Vælg selv to!” Fordi projektlederens opgave bl.a. er at have 

styr på at den givne funktionalitet leveres til den givne tid med de givne omkostninger, 

kaldes projektlederen af nogle ligefrem for trekantsbestyrer. 

Fig. 2.3: Styringstrekanten 

Bemærk at der med “tid” menes kalendertid – ikke persontid som er en del af omkostningerne. 

Funktionalitetsdimensionen omfatter også kvaliteten af systemet. Hvis kvaliteten er 

lige meget, kan vi lave hvad som helst på ingen tid (også kendt som “den nulte softwarelov”, 

se [Weinberg97]). 

Som regel vægtes de tre dimensioner i trekanten forskelligt. I nogle projekter kan 

det være altafgørende at nå en bestemt deadline, så her er tiden vigtigst. Andre gange 

er det omkostningerne. Endelig kan funktionaliteten være det helt afgørende. Derud- 


over skal man vide hvad det mindst vigtige er – her har vi nemlig vores reserve – det 

som vi eventuelt kan fire på. Så hvis tiden f.eks. er vigtigere end funktionaliteten, kan 

vi udskyde nogle af funktionerne for dermed at blive færdige til tiden. 

Der kan dog ligge en fare i den mekanistiske betragtning omkring resurseforbrug 

(omkostninger) som trekanten lægger op til. Hvis man f.eks. bliver presset på tiden, forsøger 

man måske at vælge “the chinese army approach”: man sætter mange udviklere 

på projektet i håb om dermed at gøre det hurtigere. Ud fra en ide om at hvis 2 mand 

kan grave en grøft på 10 dage, så kan 20 mand grave den på 1 dag. Det holder imidlertid 

ikke altid for it-projekter, bl.a. på grund af læreprocesserne som vi skal se på i et senere 

afsnit. Sammenligningen skal snarere være at to kaniner løber ikke dobbelt så hurtigt 

som én kanin. Eller: hvis 1 kvinde kan føde 1 barn på 9 måneder, hvor mange 

kvinder skal der så til for at føde 1 barn på 1 måned? 

Det er en central problemstilling i it-projekter at forholdet mellem trekantens sider 

(tid, funktionalitet og omkostninger) låses fast på et tidspunkt hvor grundlaget slet ikke 

er til stede. Adskillige projekter er kommet galt af sted fordi man har lavet en fastpriskontrakt 

hvor både pris og afleveringsdato lå helt fast, men reelt kendte man ikke funktionaliteten. 

Det går galt. Hver gang. Vi skal senere vende tilbage til denne problemstilling 

og se på andre metoder til at løse den. 

2.4 Udviklingsprocessen 

I dette afsnit vil vi se på den proces som gennemgås når man udvikler software. En udviklingsmodel 

er en beskrivelse af udviklingsprocessens forløb, dvs. “Hvem gør hvad 

hvornår?” Vi opererer også med begrebet livscyklusmodeller som er tiden fra produktideen 

fødes, og til sidste version er faset ud (hvor udviklingsmodellen kun omfatter tiden 

indtil afleveringen til kunden). 

En hel livscyklus kan typisk se således ud: 

– Forundersøgelse 

– Udvikling 

– Udrulning 

– Vedligeholdelse 

– Udfasning 

Der kan indgå mange elementer i en udviklingsmodel. Mest typisk er at modellen beskriver: 


– PROCES, hvilke aktiviteter gennemføres i hvilken rækkefølge. 

– ROLLER, hvem laver hvad? 

– METODER til f.eks. analyse, krav, design, test. 

– VÆRKTØJER, f.eks. CASE, programmering, test. 

– TEKNISKE AKTIVITETER. 

– KVALITETSSTYRINGSAKTIVITETER, f.eks. hvornår laves test og inspektioner. 

– KONFIGURATIONS-, VERSIONS- og DOKUMENTSTYRING. 

– MELLEMPRODUKTER (eng.: artifacts), hvilke skal laves hvornår, og hvad skal de indeholde. 

– DOKUMENTER (som også er mellemprodukter), herunder specifikationer og planer. 

Formålet med overhovedet at have en udviklingsmodel er først og fremmest at have en 

fælles referenceramme for udviklingsprocessen – “Sådan gør vi her”. Det giver dels en 

billigere uddannelse når der kommer nye projektdeltagere, dels sparer det mange diskussioner 

i kampens hede. Ikke, at vi skal undertrykke diskussionerne – vi tager dem 

bare på andre tidspunkter end midt under projektet. Og når vi alle sammen i hele virksomheden 

gør tingene på samme måde, har vi bedre mulighed for procesrelateret erfaringsudveksling. 

Endelig giver det alt andet lige en lettere planlægning samt en mulighed 

for at måle på processen og dermed en større sandsynlighed for succes. 

Overordnet set findes der to typer udviklingsmodeller: fasemodeller og iterative modeller. 

2.4.1 Fasemodeller 

En klassisk kopifitti om projektfaser lyder: 

De seks projektfaser: 

– Vild entusiasme 

– Desillusionering 

– Total forvirring 

– Jagt på de skyldige 

– Afstraffelse af de uskyldige 

– Forfremmelse af dem der ikke deltog 

Mere seriøst inddeler vi i fasemodellerne udviklingen i et antal faser, typisk: 

– Analyse 

– Kravspecifikation 


– Design 

– Kodning 

– Test 

– Udrulning 

Disse modeller kaldes ofte for vandfaldsmodeller fordi man “falder” fra den ene fase til 

den næste. Dette er dog en sandhed med modifikationer, for de fleste fasemodeller 

rummer mulighed for “tilbageløb”. Hvis man således i kodningsfasen opdager et nyt 

krav, kan man gå tilbage til kravfasen og tage det med. 

Struktureret ProgramUdvikling (SPU) er et eksempel på en fasemodel (med tilbageløb) 

– se [Biering-Sørensen88]. 

Alt flyder 

At udvikle systemer ud fra en specifikation er ligesom at gå på vandet: det hjælper hvis 

det er frosset! I øvrigt er det som regel en illusion at man kan fastfryse kravene. I de fleste 

situationer vil der være en person med tilpas mange stjerner (om ikke andet, den 

administrerende direktør) som kan overrule beslutningen og beordre et nyt krav medtaget 

– og så er vi lige vidt. Ved du i øvrigt hvad ligheden er mellem fastfrosne krav og 

den afskyelige snemand? Jo, begge er myter, og begge smelter når det bliver tilstrækkeligt 

varmt. Nogle siger ligefrem at kravspecifikationen er at opfatte som en kontrakt der 

skal genforhandles dagligt med alle interessenter. Det vender vi tilbage til i det senere 

afsnit om Kravstyring. Mekanismen har været kendt længe: den græske filosof Heraklit, 

som levede omkring 500 f.Kr., sagde at “alt flyder” hvormed han mente at intet er 

uforanderligt, alting ændres hele tiden. Det gælder også systemkrav. 

2.4.2 Iterative modeller 

De iterative modeller går frem med små skridt. Først udvikler vi en lille bid af systemet. 

Så leverer vi det til brugerne og ser hvordan det virker. Og så udvider vi det med 

lidt mere. Derfor kan du også høre ordene inkrementel, gradvis eller trinvis udvikling 

brugt om iterativ udvikling. Tidligere kaldte man de iterative modeller for RAD (Rapid 

Application Development). 

I nogle udviklingsmodeller starter man (som i en vandfaldsmodel) med at gennemanalysere 

og designe hele systemet hvorefter man udvikler det i mindre bidder. 

Man kan også starte med at udvikle en lille del af systemet og så lade systemdelen 

vokse sig gradvis større og større gennem en række iterationer. Det kaldes evolutionær udvikling. 

Her kan vi opfatte hver iteration som et gennemløb af faserne i en fasemodel: 


– først finder vi ud af hvad vi skal lave (analyse og krav) 

– så finder vi ud af hvordan vi skal lave det (design) 

– så laver vi det (kodning) 

– og så tester vi det. 

Denne måde at arbejde på er ikke nogen ny ide. Allerede i 1950’erne udarbejdede den 

amerikanske kvalitetsekspert Dr. W. Edwards Deming sin såkaldte Deming-cycle: Planlægge-Udføre-Vurdere-Ændre 

(eng.: PDSA-cycle, Plan-Do-Study-Act. Nogle siger dog 

“Check” i stedet for “Study”: PDCA.). Den illustrerer at man i en stadig vekslen mellem 

disse fire aktiviteter vedvarende forbedrer sine processer. Den blev i starten en stor succes 

i japansk kvalitetsledelse hvor begrebet kaizen (løbende forbedringer, alting kan altid 

gøres lidt bedre) i dag er kendt verden over. Den er grundlaget for mange moderne 

forbedringsprocesser og altså også for iterative it-udviklingsprocesser. 

Fig. 2.4: Deming-cyklen 

De forskellige iterative modeller har hver deres bud på hvordan denne proces foregår. 

Af fremherskende modeller kan nævnes: 

– Rational Unified Process (RUP), se side 44. 

– Microsoft Solution Framework (MSF), se side 45. 

– eXtreme Programming (XP), se side 46. 

– Objektorienteret Analyse og Design (OOA&D, også kaldet Aalborgmetoden. Se 

[Mathiassen01]). 

– Dynamic System Development Model (DSDM, se [Stapleton97]). 

– Structured Systems Analysis and Design Method (SSADM, se [Weaver02]). 

– Scrum (se [Beedle01]). 


Mange virksomheder har i tidens løb udviklet deres egne modeller (eventuelt med afsæt 

i en af de etablerede). 

Der er forskellige bud på hvad en iteration omfatter. I nogle iterative modeller fastholder 

man f.eks. tiden: den næste iteration skal være færdig om (f.eks.) 6 måneder. 

Med andre ord: vi når det vi når. Og når tiden er gået så er vi færdige. Det kaldes time 

boxing. Man kan også fastholde omkostningerne (resurserne). Det kaldes money 

boxing. Og endelig kan man fastholde funktionaliteten (function boxing) i en use case-drevet 

proces: den næste iteration implementerer disse to use cases. 

Ofte lader man den første iteration omfatte det helt basale system, dvs. f.eks. platformen, 

database-serveren, web-serveren osv. Man starter med andre ord med at “få 

hul igennem”. I RAD lægger man vægt på at få den første release søsat så hurtigt som 

muligt (deraf navnet). Derfor var det også i forbindelse med RAD man første gang 

introducerede begrebet time box. 

En af grundene til at det som regel forholdsvis hurtigt lykkes at få lavet et brugbart 

system, er Paretos 80/20-regel som siger at den funktionalitet som af brugerne vil blive 

brugt i 80% af tiden, laves på 20% af udviklingstiden. 

De iterative processer virker så godt fordi de har indbygget feedback. Vi får mulighed 

for at tage højde for det vi lærer undervejs i processen. Med vandfaldsmodellerne 

skal vi vide det hele på forhånd – hvad man meget sjældent gør. Og vi må vente til allersidst 

med at drage nytte af det vi lærer undervejs. Vi skal senere se på disse læreprocesser 

og på hvor nyttigt det er at kunne få feedback undervejs. 

Adrætte metoder 

Mange udviklingsmodeller indeholder detaljerede retningslinjer for præcis hvilke 

skridt man skal udføre. Sådanne præskriptive modeller har nærmest karakter af kogebøger. 

Som modvægt mod disse overvægtige metoder har der i 1990’erne (samtidig 

med den fedtfrie slankebølge!) været en tendens hen mod modeller med mindre 

“gør-dit-og-gør-dat” (f.eks. XP, DSDM og Scrum). De kaldtes tidligere letvægtsmetoder 

(eng.: lean), men i dag kaldes de adrætte metoder (eng.: agile). Det har givet anledning 

til det “adrætte manifest” (se www.agilealliance.org samt [Cockburn01]): 

– Individer og samspil frem for processer og værktøjer. 

– Kørende software frem for fuldstændig dokumentation. 

– Samarbejde med kunden frem for kontraktforhandling. 

– Reaktion på forandring frem for at følge en plan. 

Det kan ses som en modreaktion mod de meget store og tunge metoder (lidt i stil med 


dogmereglerne for filmproduktion: tilbage til rødderne). Ideen er at projektet skal fokusere 

på de værdiskabende aktiviteter og så i øvrigt være tunet til at kunne reagere hurtigt 

når tingene ændrer sig. 

2.4.3 Rational Unified Process 

Rational Unified Process (forkortet RUP) er en konkretisering af Unified Process (se 

[Jacobson99]). RUP har opnået stor udbredelse fordi den er både operationel og værktøjsunderstøttet, 

men andre virksomheder har også lavet deres bud på hvorledes Unified 

Process kan instantieres. 

RUP er en use case-drevet, arkitekturcentreret, iterativ udviklingsmodel. Den rummer 

følgende hovedfaser: 

– BEGYNDELSE (eng.: inception) hvor ideen fødes, de vigtigste use cases beskrives og 

der laves overordnet arkitektur og plan. 

– UDDYBNING (eng.: elaboration) hvor de fleste use cases beskrives, arkitekturen udarbejdes 

og resten af projektet estimeres og planlægges. 

– KONSTRUKTION (eng.: construction) hvor implementeringen foregår. 

– OVERGANG (eng.: transition) hvor der laves betatest, rettes fejl, trænes brugere og rulles 

ud i organisationen. Dette er med andre ord produktmodningsfasen. 

At modellen er iterativ, betyder at man i de enkelte hovedfaser gennemløber et antal 

iterationer. Hver iteration består af kravfastlæggelse, analyse, design, kodning og test. 

De fleste iterationer foregår af gode grunde i konstruktionsfasen. 

Gennem hele udviklingsforløbet udføres ni aktiviteter (eng.: work flows). Dels seks 

kerneaktiviteter: 

– FORRETNINGSMODELLERING som sørger for koblingen mellem de forretningsprocesser 

som it-systemet indgår i, og selve it-systemet. Er det det rigtige vi udvikler? 

– KRAV som beskæftiger sig med en grundig forståelse og beskrivelse af kravene til systemet. 

Der laves vision, identificeres aktører og beskrives use cases. Hvad skal vi 

lave? 

– ANALYSE og DESIGN beskæftiger sig med hvordan vi rent faktisk vil implementere systemet. 

Det er her vi tænker på delsystemer, arkitektur og grænseflader. 

– IMPLEMENTERING hvor vi udvikler koden og tester at enkeltkomponenter virker. 

– TEST hvor vi tester at komponenter og delsystemer virker sammen, at hele systemet 

virker og at alle krav er implementeret korrekt. 

– UDRULNING hvor vi i en række delleverancer indfører systemet i brugerorganisationen 

og hjælper brugerne med at tage det i anvendelse. 


Dels tre støtteaktiviteter: 

– PROJEKTLEDELSE som handler om faktisk at få gennemført de nævnte aktiviteter på 

en afbalanceret måde. 

– KONFIGURATIONS- og ÆNDRINGSSTYRING som holder styr på alle de mange krav, 

mellemprodukter og releases undervejs. 

– UDVIKLINGSMILJØ som sørger for at dels udviklingsprocessen, dels de værktøjer som 

projektgruppen har behov for, er til stede og tunet til opgaven. 

Men det er vigtigt at understrege at disse ni aktiviteter forløber gennem hele projektet. 

Der bliver dog ikke lagt lige meget arbejde i dem i alle faserne. F.eks. lægges der flere 

kræfter i arbejdsgangen implementering i konstruktionsfasen. 

Du kan læse mere om RUP i f.eks. [Kruchten00]. 

2.4.4 Microsoft Solution Framework 

MSF er en ramme for systemudvikling, det er ikke en egentlig metode. Den er udviklet 

af Microsoft gennem mange år og indeholder essensen af hvad Microsoft mener er best 

practice. MSF består af en række modeller: 

– PROCESMODELLEN som beskriver hvordan udviklingsprocessen forløber. 

– ROLLEMODELLEN som beskriver de forskellige roller i projektgruppen. Den vender vi 

tilbage til i det senere afsnit om Organisation (side 164 ). 

– APPLIKATIONSMODELLEN som beskriver applikationens arkitektur. 

– RISIKOMODELLEN som beskriver hvordan projektet skal forholde sig til risici gennem 

hele forløbet. 

Procesmodellen beskriver at projektet overordnet inddeles i fire faser: 

– VISIONSFASEN (eng.: Envisioning phase) hvor vi danner overblikket over projektets 

omgivelser og mål: Hvad går det ud på? 

– Planlægningsfasen (eng.: Planning phase) hvor vi laver kravspecifikation og overordnet 

projektplan. 

– UDVIKLINGSFASEN (eng.: Developing phase) hvor produktet udvikles og testes. Udviklingen 

sker iterativt, evt. i parallelle forløb. 

– MODNINGSFASEN (eng.: Stabilizing phase eller Deployment phase) hvor produktet testes 

i den virkelige verden og gradvist tages i brug. 

Bemærk at MSF, ligesom RUP, er en hybrid mellem en vandfaldsmodel og en iterativ 

model. Man har taget det bedste fra begge verdener. 


MSF er i øvrigt en del af et endnu større koncept, nemlig ESF, Enterprise Services 

Framework. Det omfatter: 

– Microsoft Readiness Framework (MRF) som er en foranalyse der skal afdække de 

forskellige løsningsmuligheder og deres egnethed i relation til de forretningsmæssige 

mål. 

– Microsoft Solution Framework (MSF). 

– Microsoft Operations Framework (MOF) som omfatter drift og vedligehold. 

Se i øvrigt mere om MSF på www.microsoft.com. 

2.4.5 eXtrem Programmering 

eXtrem Programmering (eng.: eXtreme Programming, XP) er et eksempel på en adræt 

metode. Her gives en kort oversigt over metoden. 

Det centrale styringsredskab er de såkaldte user stories som er meget små funktionalitetsbeskrivelser. 

XP består af 12 selvstændige teknikker som tilsammen udgør XP: 

– PLANLÆGNINGSSPILLET (eng.: The Planning Game). Kunden og projektgruppen fastlægger 

i fællesskab hvad den næste aflevering skal indeholde. Det er et tæt samspil 

mellem kundens forretningsmæssige prioritering og udviklernes estimater. 

– SMÅ DELLEVERANCER er nødvendige for hele tiden at have et kørende system. 

– METAFOREN er et “billede” på systemet som alle kan referere til. Hvad handler systemet 

om, fortalt på to linjer. Den fælles vision. 

– SIMPELT DESIGN betyder at vi under hele opbygningen holder designet på det 

simplest mulige. Vi tager altså ikke hensyn til at vi i næste uge skal lave en tilføjelse 

som kræver et mere kompliceret design. Så laver vi det mere kompliceret til den tid. 

Men ikke nu. Dette er KISS-reglen: “Keep It Small and Simple” som vi senere vender 

tilbage til i andre sammenhænge. 

– TEST FØR KODNING. Hvis test er godt, så må vi teste hele tiden. Og her laver vi så testen 

før vi laver den kode der skal testes. Testen fejler (fordi koden den skal teste ikke 

er skrevet endnu), men når vi får skrevet koden, så virker testen. Alle disse tests automatiseres 

så vi hurtigt kan verificere at hele systemet virker indtil nu. 

– OMBRYDNING (eng.: Refactoring) betyder at vi hele tiden bliver klogere mht. hvordan 

designet af systemet skal være – og så tilpasser vi det løbende. Hvilket vi også er nødt 

til fordi designet skal holdes på det simplest mulige hele tiden. Vi er altså ikke bange 

for at lave noget om. Og det behøver vi heller ikke at være – for med den automatiske 

test har vi vished for at det virker, også efter ombrydningen. 


– PARPROGRAMMERING (eng.: Pair Programming) er nok den mest kendte af XP-teknikkerne. 

Det betyder helt bogstaveligt at to programmører sidder samtidig ved den 

samme skærm og hjælpes ad med at kode. Oftest skiftes de til at sidde med tastaturet, 

og så koder og skriver den ene, mens den anden løbende tjekker at det er korrekt. 

Hvis review er godt, så lad os reviewe koden hele tiden. 

– FÆLLES EJERSKAB betyder at der ikke findes “dine moduler” og “mine moduler”. Det 

er “vores moduler” alle sammen, og hvis jeg har brug for at rette et sted i koden, så 

gør jeg det. Den automatiske test sikrer at der ikke sker ulykker. Egofri programmering 

er i øvrigt et gammelt begreb som er omtalt allerede i 1971 (se [Weinberg98]). 

– FORTLØBENDE INTEGRATION betyder at vi integrerer hele systemet hele tiden. Så er vi 

sikre på at det vi har lavet, hele tiden virker. 

– 37-TIMERS UGE. De fleste udviklere elsker denne regel. Baggrunden er den at når udviklere 

har været kreative en hel arbejdsdag, er de trætte. Og hvis de koder videre, laver 

de fejl. Det er billigere og bedre bare at lade dem gå hjem og hvile ud til næste dag. 

– KUNDEN TIL STEDE betyder helt bogstaveligt at kunden skal være umiddelbart tilgængelig 

for udviklerne. Når vi ikke har en egentlig nedskreven detaljeret kravspecifikation, 

må vi kunne få afklaret alle tvivlsspørgsmål her og nu. 

– KODESTANDARDER er helt nødvendige når vi har fælles ejerskab til koden. Ellers bliver 

det noget rod. 

Bemærk at alle disse teknikker skal være i anvendelse før man taler om eXtrem Programmering. 

Hvis én eller flere mangler, virker metoden ikke optimalt. 

I det senere afsnit om Organisation (side 167) ser vi på de roller som findes i eXtrem 

Programmering. Du kan i øvrigt læse mere om XP i [Beck00] og [Beck01]. 

I øvrigt findes der en konkretisering af Unified Process som til forveksling ligner 

eXtrem Programmering. Den kaldes dX (læs det på hovedet). Den kan bruges hvis man 

skal bruge Unified Process, men gerne vil bruge XP. 

2.4.6 Foranalyse 

Inden der er taget endelig stilling til om projektet overhovedet skal startes, laves sommetider 

et foranalyseprojekt. Det kaldes også et forprojekt, et feasibility study eller et 

“præjekt”. Det svarer lidt til at vi starter med at lave jordbundsanalyser inden vi påbegynder 

et byggeprojekt. 

Som resultat udarbejdes en foranalyserapport (en business case) som fastlægger om 

projektet rent forretningsmæssigt kan bære. Den skal danne beslutningsgrundlag for 

hvorvidt projektet overhovedet skal sættes i gang. 


Rapporten indeholder f.eks.: 

– Formålet med projektet. Hvorfor laver vi egentlig det her? Hvilket problem vil vi 

løse? 

– Overordnet beskrivelse af hvad det er vi vil lave. 

– Beskrivelse af teknologien (hvis relevant). 

– Risikoanalyse. 

– Beskrivelse af projektets finansiering. 

– Anslået tid og pris. 

– Cost/benefit-analyse, kan det betale sig? 

Dette dokument kan senere udbygges til at blive projektgrundlaget. 

En del af arbejdet med foranalysen går ud på at få opbygget en forståelse for den 

opgave der skal løses. I diskussionen med brugerne om et eventuelt nyt system kan 

f.eks. anvendes mock-ups, dvs. skærmbilleder på papir. Eller man kan lave egentlige 

prototyper for at demonstrere og afprøve systemets grænseflader. 

Men at analysere for længe er også farligt (eng.: analysis paralysis). I en misforstået 

angst for ikke at gøre det godt og grundigt nok bliver vi ved med at analysere langt efter 

at vi skulle være gået videre til næste fase. Det gælder både foranalysen og en 

eventuel senere analysefase. 

Flere udviklingsmodeller omfatter en foranalyse (f.eks. DSDM og Microsoft Readiness 

Framework). Du kan læse mere om foranalyse i f.eks. [Bødker00]. 

2.4.7 Kravspecifikationen 

Inden vi går i gang med selve udviklingen, skal vi have styr på hvad det er vi vil lave. 

Denne aktivitet kaldes kravspecifikation, og det er en videnskab i sig selv. Da det samtidig 

er en af de væsentligste forudsætninger for projektets succes, er der al mulig grund 

til at tage kravspecifikationen alvorligt. 

Tidligere lavede man næsten altid kravspecifikationen (eng.: SRS, Software Requirement 

Specification) som en opremsning af produktkrav, dvs. præcise beskrivelser af 

funktionerne i systemet. I dag har man flere strenge at spille på, og også i forståelsen af 

kravene til systemet anvender vi en multiperspektivisk tilgang: 

– FORRETNINGSANALYSEN udarbejder en forretningsmodel som giver overblik over 

domænet og indplacerer it-systemet i den rigtige sammenhæng. 

– DOMÆNEBESKRIVELSEN er en beskrivelse af de kommende brugeres arbejde – det arbejde 

som det nye system skal understøtte. Dette kan også omfatte en arbejdsgangsanalyse. 


– FUNKTIONELLE KRAV beskriver de enkeltkrav der kan opstilles til systemets funktionalitet. 

Ofte beskrives disse i form af Use Cases (brugsmønstre). 

– BRUGERGRÆNSEFLADEKRAVENE beskriver kravene til systemet set fra brugerens side. 

– INFORMATIONSMODELLEN giver overblik over hvilke informationer systemet skal 

holde styr på. 

– YDELSESKRAVENE (eng.: performance) skal også beskrives. Det kan være krav til 

transaktionsmængder (eng.: throughput), antal samtidige brugere, spidsbelastning 

(eng.: peak), databasestørrelse osv. 

– SIKKERHEDSKRAVENE beskriver hvilke krav der stilles til datasikkerhed, adgangskontrol, 

recovery osv. 

– ORDLISTEN indeholder en alfabetisk liste over alle domænets ord, termer og begreber, 

med tilhørende definition og beskrivelse. Selve arbejdsprocessen med at udarbejde 

ordlisten vil som regel altid ske i samarbejde med en domæneekspert. Det kan i øvrigt 

også være en læreproces for domæneeksperten at lave ordlisten. Begreber man 

har gået og brugt i det daglige, er ikke altid helt så enkle når de skal forklares, formuleres 

og nedskrives. 

I erkendelse af at det kan være særdeles vanskeligt at give fastpristilbud på et stort system 

uden at kende kravene, ses det ofte at udviklingen af selve kravspecifikationen laves 

som et forprojekt (eventuelt til fast pris). Når kravspecifikationen så foreligger, kan 

der gives tilbud på udviklingen af det egentlige system. 

Omvendt skal vi også være klar over at det sjældent er en god ide at forsøge at detailspecificere 

ned til den mindste detalje. Hvis vi ikke kender området, er det bedre at 

holde kravene overordnet så vi kan drage fordel af læreprocessen undervejs. 

Proportionalitetsreglen 

Ved udarbejdelse af kravspecifikationer gælder proportionalitetsreglen: Små systemer – 

lille kravspecifikationsindsats. Store systemer – stor indsats. Proportionalitetsreglen siger 

generelt at der skal være sammenhæng mellem tingene, og der skal være måde 

med galskaben. Vi skal hverken skyde gråspurve med kanoner eller skyde elefanter 

med ærtebøsser. I forbindelse med kravspecifikationen betyder det altså at vi ikke skal 

køre det helt store apparat i stilling for at lave en lillebitte opgave. Men at det på den 

anden side er i orden at bruge mange kræfter på at finde ud af hvad systemet går ud på 

hvis det er meget stort. 


Videre studier 

Du kan læse mere i [Lauesen00] som er en introduktion til området, eller i [Lauesen02] 

som er den autoritative bog om kravspecifikation. Også [Wiegers99] og [Robertson99] 

rummer god indsigt i området. Use Case-teknikken er beskrevet i [Schneider98]. [Biering-Sørensen88] 

rummer også et kapitel om kravspecifikation. Bruger du RUP, kan 

[Leffingwell99] anbefales. Endelig rummer [IEEE830] et udmærket forslag til en indholdsfortegnelse 

for kravspecifikationer. 

2.4.8 Valg af udviklingsmodel 

Et af de klassiske problemer i it-projekter er at man glemmer at være bevidst om sin 

udviklingsmodel. Man behøver ikke nødvendigvis vælge en af de etablerede (selv om 

det er det letteste fordi de er så velbeskrevne). Man kan sagtens lave sin egen tilpassede 

(eng.: tailoring). Bare man har en. 

Når projektet (eller virksomheden) står over for at skulle vælge en udviklingsmodel, 

er der flere hensyn at tage: 

– Hvor godt forstår vi (og kunden) anvendelsesområdet? 

– Vil kravene ændre sig undervejs? 

– Hvor godt kender vi udviklingsmiljøet? 

– Hvor godt kender vi den organisation som skal modtage systemet? 

– Hvor meget styr har vi på designet af denne type applikationer? 

– Kræves der fast pris, tid og funktionalitet? 

– Hvor mange personer skal deltage i udviklingen? 

Er der tale om udvikling til fast pris og tid inden for et velkendt domæne, kan det være 

mest praktisk med en vandfaldsmodel. Er der derimod tale om ukendt land, vil en 

iterativ model med indbygget udnyttelse af læreprocesserne være at foretrække. Det 

kan godt være at det kræver nogen pædagogisk overtalelse af projektsponsoren, men 

tro mig: det er det værd. 

Skift af model 

Det tager ofte lang tid at få en udviklingsmodel ind under huden. Så man skal ikke skifte 

udviklingsmodel for tit – man når simpelthen ikke at lære dens styrker og svagheder tilstrækkeligt 

godt at kende, og man går glip af læreprocessen med at anvende modellen. 

Men behersker man flere modeller, og er der tale om et stort system inden for et 

ukendt område, kan man også vælge en adræt model i starten, for siden at gå over til 

f.eks. RUP. 


Regler eller ej? 

Når mange mennesker skal arbejde sammen, er et vist mål af regler nødvendigt. Hvis 

alle blot gør hvad der passer dem, ender det hele i anarki. Vi har behov for nogle færdselsregler 

som sikrer at vi ikke modarbejder hinanden. Nogle regler er lette at få udviklerne 

til at forstå – og følge. F.eks. at vi skal benytte et fælles versionsstyringsværktøj så 

vi undgår problemer med at flere udviklere vil rette i de samme filer samtidig, og så vi 

altid kan genskabe tidligere releases. Andre regler kan det være sværere at håndhæve. 

F.eks. regler omkring kodestandarder (“Jeg har altid lavet 4 indrykninger efter en if!”). 

Se også det senere afsnit om Standarder (side 173) i kapitlet om Projektetablering. 

Jo flere personer der er involveret i projektet, jo større er behovet for fælles regler. 

2-4 udviklere kan sagtens koordinere ved at snakke sammen hele tiden. Når vi bliver 

ret mange flere, går der alt for lang tid med diskussion hvis vi ikke følger de samme 

retningslinjer. 

Imidlertid er vi her oppe imod store kræfter. For det 

første menneskets iboende dovenskab. De fleste vil helst 

springe over hvor gærdet er lavest (eng.: Path of least 

resistance). Dette kaldes dovenskabsreglen eller reglen 

om den mindste modstand. Det ses f.eks. når der trædes 

stier den direkte vej hen over en græsplæne – selv om 

der er anlagt “officielle” flisegange. 

For det andet er vi oppe imod menneskets særdeles kreative evner når det handler 

om at omgå love og regler. Jeg vil illustrere dette med en berømt fangeflugt: 

Hvor der er en vilje 

I 1949 brød fangen Carl August Lorentzen ud fra sin celle i Horsens Statsfængsel. Han havde 

fjernet bagklædningen i det lille skab i cellen og kunne derved bryde gennem muren til et lille 

trapperum. Ad den vej tilbragte han nætterne i det meste af et år med at grave en 20 meter 

lang tunnel ud under fængselsmuren. Den bortgravede jord gemte han på loftet. Efter flugten 

fandt man i det lille skab i cellen en seddel hvor han havde skrevet de senere så berømte ord: 

“Hvor der er en vilje, er der også en vej!” 

For god ordens skyld: det er ikke Lorentzen der har fundet på dette ordsprog – det er 

ældgammelt og findes i flere kulturer. 


Så hvis du tror at du kan styre folk gennem regler som de ikke er enige i, så husk på 

“hvor der er en vilje”-syndromet. I den virkelige verden finder den ofte anvendelse 

omkring omgåelse af skattelovene. I naturen finder den anvendelse når mælkebøtterne 

bryder frem gennem asfalten (derfor kaldes det også undertiden mælkebøttesyndromet). 

Og ofte ledsages den af bemærkninger som “Så må vi jo finde på noget andet”, 

“Det skal de i hvert fald ikke bestemme” og lignende. 

Men bevidstløst regelrytteri er også galt. Det er tilladt at bruge indersiden af hovedet 

og træffe velovervejede beslutninger – også selv om reglerne siger noget andet (eng.: 

Engage your brain). 

2.4.9 Softwarehåndbogen 

Udviklingsmodellen beskrives typisk i en softwarehåndbog (også kaldet en projekthåndbog). 

Den skal helst være tilgængelig online på virksomhedens intranet. Softwarehåndbøger 

på papir er for vanskelige at holde opdateret, og så forældes de lynhurtigt. 

Men selv en nok så god softwarehåndbog er intet værd hvis udviklerne ikke kender 

dens indhold. Så den skal under alle omstændigheder suppleres med undervisning i 

dens brug når der kommer nye udviklere. Og de gamle kan formentlig også trænge til 

at få den frisket op en gang imellem. 

2.5 Læreprocesserne 

Forestil dig at du hver den 1. i måneden bliver bedt om at være projektleder på udviklingen 

af et givet system. Og det er nøjagtigt det samme system du skal udvikle måned 

efter måned. Det er naturligvis en tænkt situation, men mit gæt er at du vil blive i stand 

til at udvikle systemet på stadig kortere tid – indtil en vis grænse. Denne grænse kan vi 

kalde idealtiden, dvs. den tid det tager at udvikle systemet hvis alting bare flasker sig, 

og hvis vi ved det hele. Tiden som du de første gange bruger ud over idealtiden, kan vi 

kalde overtiden. Altså den tid du bruger “for meget”. Lad os kigge på hvad overtiden 

egentlig bruges til. Den bruges nemlig til en række læreprocesser. Vi skal blive klogere 

mht. PIP: 

– Produktet, dvs. f.eks. anvendelsesområdet og den konkrete applikations design. 

– Interessenterne, dvs. f.eks. kundens forhold og samarbejdet i projektgruppen. 

– Processen, dvs. f.eks. udviklingsmiljøet. 


Produktet 

Læreprocesserne omkring anvendelsesområdet (domænet) handler om at vi skal tilegne 

os viden om den verden systemet skal virke indenfor. Er det f.eks. et system til patientadministration, 

skal vi vide noget om hvordan et hospital fungerer. Er det et system 

til styring af et kraftværk, skal vi vide noget om hvordan et kraftværk fungerer. Derfor 

kan det sommetider være en god ide at tilbringe nogle dage i det miljø hvor systemet 

skal bruges ([Bødker00]). 

Vi skal opbygge den konkrete applikations design. Vi skal lave en arkitektur som 

egner sig til denne applikation. Vi skal finde ud af hvilke komponenter systemet skal 

bestå af. Og hvordan de snakker sammen. Vi skal måske opbygge (eller genbruge) hele 

application frameworks, dvs. standardarkitekturer for denne type systemer. 

Interessenterne 

Projekter er bl.a. kendetegnet ved at det er forskellige personer der deltager fra gang til 

gang. Kunden er sjældent den samme. Brugerne er forskellige. Og projektgruppen 

sammensættes ofte på ny hver gang. Derfor skal vi lære os hvordan projektets interessenter 

denne gang er skruet sammen. Hvilke behov de har. Hvordan de kan takles bedst 

muligt. Hvordan vi sikrer at så mange af deres interesser som muligt opfyldes. Vel vidende 

at de kan være modstridende. 

Processen 

Læreprocesserne omkring udviklingsmiljøet handler om at vi skal sætte os ind i udviklingsværktøj, 

compiler, standardkomponenter, biblioteker, udviklingsplatform, konfigurationsstyringsværktøjer 

osv. 

Læreprocesser tager tid 

Det er ofte læreprocesserne som er skyld i at it-udvikling underestimeres. Vi glemmer 

simpelthen at tage højde for alle de ting som vi ikke ved, og som vi skal sætte os ind i 

(lære) hen ad vejen. I andre brancher kaldes fænomenet “begyndervanskeligheder” eller 

“børnesygdomme” – begreber som dækker over at vi udmærket godt ved at ting 

kan gå galt når vi starter på noget nyt. Vi snakker om at “al begyndelse er svær”. 

I øvrigt siger man lidt i spøg at det først er det tredje system (af samme slags) man 

udvikler som rammer rigtigt, både hvad angår funktionalitet og resurseforbrug. På det 

tidspunkt har man nemlig gennemført så mange af læreprocesserne at overtiden og 

“skæverterne” er kommet ned på et acceptabelt niveau. Det minder lidt om følgende 

historie om at tegne en hane: 


At tegne en hane 

Det fortælles om Kejseren af Kina at han bestilte en tuschtegning af en hane hos en dygtig 

tegner. Tegneren sagde at den kunne være klar om fire år. Fire år senere var den dog endnu 

ikke klar, men tegneren lovede at om fire år mere ville den være færdig. Fire år senere gentog 

historien sig. Da Kejseren efter nu tolv års forløb troppede op med hele sit følge hos tegneren, 

sagde denne at nu var den klar. Han tog et nyt stykke papir, og med sin pensel tegnede 

han i én eneste hurtig bevægelse en helt ufatteligt livagtig hane. Da Kejseren spurgte hvorfor 

han skulle bruge tolv år, tog tegneren ham med ind i rummet ved siden af hvor der lå stabler 

af tegninger fra gulv til loft – af haner! 

Frit efter [Bastian88] 

Nu behøver du ikke tage denne historie som udtryk for at du bare kan forsinke projektet 

til det tredobbelte fordi det så bliver sublimt. 

De iterative processer har deres styrke ved at læreprocesserne indbygges i selve udviklingsforløbet. 

Ved hver iteration bliver vi lidt klogere mht. de tre læreprocesser. Ved 

de første iterationer gætter vi sædvanligvis meget galt. Men fordi vi bliver klogere og 

klogere hen gennem udviklingsforløbet, rammer vi mere og mere præcist. Nøgleordet 

er feedback. Fordi vi bliver i stand til at udnytte vores forøgede viden i løbet af selve 

projektet, kan vi løbende tilpasse såvel produkt som proces. 

Den amerikanskfødte (og norsk bosatte) it-guru Tom Gilb har sagt det meget rammende: 

“Hvis du ikke ved hvad du har med at gøre, så lad være med at gøre det i stor 

skala.” Eller som det mere poetisk er udtrykt af Piet Hein i dette Gruk: 

Du skal bruge en del af dit snilde 

til at trylle din opgave lille. 

Når du først har lagt seletøj på den - 

lad den gro sig så stor, du kan få den! 

Eller med et gammelt ordsprog: Man skal kravle før man kan gå. Start i det små indtil 

du har styr på hvad du har med at gøre, dvs. indtil du har været igennem læreprocesserne. 

Så kan du altid sætte turbo på bagefter. 

2.5.1 Nyt eller gennemprøvet? 

“Vi skal tjene penge og have det sjovt. Men vi skal ikke tjene så mange penge at vi ikke 


har det sjovt. Og vi skal ikke have det så sjovt at vi ikke tjener penge”. Sådan lyder en 

klassiker fra ledelseslitteraturen. Og den kan overføres til it-udvikling. Nogle gange har 

vi det så sjovt at vi får udviklet for lidt og forkert. Vi har så meget fokus på hele tiden at 

anvende den ultimative og nyeste teknologi at vi glemmer det vigtigste: at vi skal lave 

gode systemer til kunderne. Her bør vi satse mere på det gode håndværk, frem for at 

forfølge de nyeste (og sjoveste) værktøjer og ideer for enhver pris. Det er nemlig ikke 

altid brugerne opdager at deres system er lavet med en meget fancy, ny indmad – og 

som regel er de også ligeglade. 

Man kunne stille spørgsmålet: For hvis skyld er det så vi uophørligt jagter det nyeste? 

Er det i virkeligheden for udviklernes egen skyld? For at de kan have det sjovt? Og 

vise at de er med på noderne? Og at det er sjovt at arbejde her hos os, så vi kan tiltrække 

og fastholde de dygtigste udviklere? Dette kaldes også Mount Everest-syndromet: vi 

bruger den nyeste teknologi bare for at bevise at vi kan. Og nogle kalder ny teknologi 

for “udviklernes opium”: de skal have noget nyt at lege med en gang imellem. Selvfølgelig 

skal vi hele tiden holde nyhederne under observation, men måske ville vi en gang 

imellem stå os bedre ved lige at vente lidt og få andre til at indhøste erfaringer med nye 

værktøjer, mens vi koncentrerer os om at få løst opgaven til kundens tilfredshed. 

Og så er der lige det med læreprocessen: når vi endelig er blevet gode til en bestemt 

teknologi eller et bestemt værktøj, kan vi jo lige så godt have glæde af det – i stedet for 

straks at ile videre til det næste og dermed starte forfra på læreprocessen. 

Men man skal heller ikke vente alt for længe med at tage nye teknologier i brug. 

Det kaldes Thomas Lawson-syndromet hvis man krampagtigt forsøger at holde fast i en 

kendt teknologi længe efter at man burde være skiftet til en ny: 

Thomas Lawson 

I slutningen af 1800-tallet, da dampskibene begyndte at fortrænge sejlskibene, forsøgte nogen 

at bygge større og større sejlskibe ud fra ideen om at det var en kendt teknologi, og de var 

prisbillige at sejle med. F.eks. byggede man både fem- og seks-mastede skonnerter. Og i 1902 

byggede man verdens eneste syv-mastede skonnert, Thomas Lawson. For at håndtere sejlene 

havde den installeret en lille dampmaskine! Skibet var i øvrigt ikke særligt manøvredygtigt, og 

det sank i 1907. 

Eller med den amerikanske psykolog Abraham Maslows ord: “hvis du er god til at bru- 


ge en hammer, så ligner alle problemer søm”. Nogle har en tendens til udelukkende at 

løse problemer med de teknologier de nu en gang behersker (“Det vi har brug for her, 

er en større hammer”, [Senge99]). Det er også galt. Vi skal beherske så tilpas mange teknologier 

at vi er i stand til at vælge den bedst egnede til opgaven. Det er kompliceret, 

det her. Sammenlign i øvrigt med det multiperspektiviske syn – nogle har en tendens 

til at anskue verden ud fra et enkelt perspektiv. Så kender du kun til at bruge en hammer, 

bruger du “hammerperspektivet”. 

2.5.2 Sølvkugler 

I den mørke middelalders Transsylvanien – dengang ulvene tudede, bjørnene brølede 

og vampyrerne føg om ørerne på folk – mente folkeovertroen at man endegyldigt kunne 

dræbe en varulv ved at skyde den med en sølvkugle. Disse sølvkugler (eng.: silver 

bullet) er siden blevet synonyme med en enkeltstående, hurtig løsning på et slemt problem 

(se [Brooks87]). Inden for it-verdenen har vi i tidens løb hørt om mange sådanne 

“frelserteknologier”, f.eks.: 

– CASE-værktøjer 

– Objektorientering (OO) 

– Genbrug og komponenter 

– Design Patterns 

– Use Case-teknikken 

– Java 

– XML 

– eXtrem Programmering 

Hver for sig udmærkede teknologier. Men fælles for dem er at ved deres fremkomst 

blev de udråbt som revolutionerende og med et potentiale til at løse (næsten) alle problemer. 

Hvilket selvfølgelig er noget sludder. Så lad være med at tro at alle dine problemer 

med it-udvikling kan løses af én enkelt teknologi. Der er specielt grund til at tænke 

sig om ved anskaffelse af værktøjer. Det er før set at værktøjer er blevet oversolgt så 

nogle har fået det indtryk at de kunne løse flere problemer end tilfældet faktisk var. 

Hvis man konsekvent halser efter de nyeste teknologier, kaldes det i spøg for Management 

by Buzzwords. 

Som tidligere nævnt findes der heller ikke simple løsninger inden for projektledelse. 

Hvis nogen prøver at bilde dig det ind, så lad være med at tro på dem. Det er og bliver 

kompliceret, det her. 


2.5.3 Videndeling 

Videndeling er vigtigt at beskæftige sig med som projektleder, og det vil vi kigge lidt 

på i dette afsnit. 

Kan viden overhovedet deles? 

I filmen The Matrix oplevede vi hvordan ny viden blev downloadet direkte ind i hjernen. 

Der går nok lige et par år før udviklerne kan dele deres viden på denne meget 

it-agtige måde. Spørgsmålet er om man i det hele taget kan dele sin viden med andre. 

Viden er snarere noget som hver enkelt selv skal tilegne sig, og derfor er det også vigtigt 

at man giver udviklerne muligheden for at tilegne sig hinandens viden. Det skal 

altså være politisk acceptabelt i virksomheden at man tilegner sig hinandens viden. 

F.eks. gennem mesterlære (som i XP), gennem interne foredrag, gennem sparring og 

spørgen til råds, gennem review af hinandens kode osv. 

Genbrug er besværligt 

Dybe tallerkener er uhyre nyttige – ellers blev de vel heller ikke opfundet så tit. Der kan 

ligefrem gå sport i det. For mange it-udviklere er det i hvert fald en yndet beskæftigelse 

at genopfinde allerede kendte løsninger, og det er egentlig en skam, for det er både dyrt 

og forsinkende. 

I ganske mange år har ordet genbrug været et magisk ord (en sølvkugle) blandt ledere 

i it-branchen. Man så for sig hvordan udviklerne kunne spare enorme mængder af 

tid ved “blot” at genbruge tidligere udviklet kode i nye sammenhænge. Men efterhånden 

har man indset at udviklernes iboende trang til tallerkenopfinding har stukket en 

effektiv kæp i hjulet for de altomfattende genbrugsbiblioteker. Dygtige udviklere udvikler 

hver for sig deres egne genbrugsbiblioteker hvorfra de klippe-klistrer kodestumper 

og moduler. Men udviklerne imellem er det meget sværere. Dels skal man over 

psykologiske barrierer (NIH: Not Invented Here - det er ikke mig der har fundet på 

det). Dels skal man over økonomiske barrierer (det koster en del tid at gøre kode genbrugelig). 

Og endelig skal man over tekniske barrierer (det er ikke helt let at organisere 

et genbrugsbibliotek så tingene faktisk er lette at genfinde). Derfor har kun ganske få 

virksomheder succes med genbrug ud over få standardmoduler. 

NIH-syndromets modsætning er at man sætter en ære i at genbruge så meget som 

muligt: “Steal with pride, share with delight”. 

Mønstre er viden 

Midt i 1990’erne blev mønstrene (design patterns) heldigvis opfundet. Det er en metode 


til at beskrive gode løsninger på bestemte problemer: – Når du står med dette problem, 

så er løsningen sådan-og-sådan. Og man satte oven i købet navn på. Nu kunne man 

høre udviklere snakke om et singleton-pattern, et observer-pattern osv. Hver udvikler 

behøvede nu ikke længere genopfinde de samme løsninger på de problemer som man 

tidligere havde opfundet udmærkede løsninger på. Det var et godt skridt i den rigtige 

retning. At det så er for få udviklere der sætter sig ind i de tilgængelige mønstre – ja, 

det er en helt anden sag. Hvis du vil gøre noget ved dette problem, kan du f.eks. lave 

en studiekreds hvor I hver gang diskuterer et bestemt emne som en af udviklerne så 

skal komme med oplæg til. Det er en god måde at holde hinandens viden ved lige på. I 

øvrigt taler man også om anti patterns som er mønstre for at gøre noget på den forkerte 

måde. Disse er f.eks. beskrevet i [Brown98] og [Brown00]. 

Lægerne bruger teknikken 

Inden for andre erhverv er det velkendt at man deler sin viden til gavn for hinanden – 

og kunderne. F.eks. ser læger hinanden over skuldrene når de opererer. Noget der har 

sparet mange menneskeliv. Det er et eksempel på brug af den gamle mesterlære. Man 

betragter “Mesteren i arbejde” og lærer derved hvordan man selv skal gøre. Det er en 

effektiv teknik når man ikke er i stand til at sætte ord på sin viden. Sådan ordløs viden 

kaldes i øvrigt tavs viden eller implicit viden (i modsætning til den viden man kan skrive 

ned – den kaldes eksplicit viden). 

It-udviklere i mesterlære 

Den mest omtalte af de teknikker der tilsammen udgør eXtrem Programmering, er 

par-programmering: kode udvikles af to udviklere samtidig ved den samme skærm. 

Og det er i realiteten en fantastisk måde at lære af hinanden på. God programmeringsskik 

er nemlig en vanskelig evne at sætte ord på. De fleste dygtige udviklere kan kende 

god programmering når de ser den. Men at beskrive det.... Derfor foregår der ekstremt 

meget videndeling når udviklerne benytter XP. Det forudsætter dog at det faktisk er 

god programmeringsskik der videreføres – og ikke unoder. Derfor er en vis rokering en 

god ide, så man lærer fra forskellige og ikke udelukkende fra den samme. Se i øvrigt 

[McConnell93] omkring god programmeringsskik. 

Procesviden kan også deles 

Vidensteoretikerne har en model som fortæller hvordan viden skabes i en stadig vekslen 

mellem tavs og eksplicit viden. Man nedskriver, man læser og sammensætter fra 

flere kilder, man ser hinanden gøre tingene, man begynder selv at gøre dem: 


– SOCIALISERING (eng.: Socialization). Tavs-tavs. Her videregives den tavse viden fra 

én person til en anden, uden at sætte ord på. Det er typisk for bl.a. mesterlæren hvor 

lærlingen ser hvordan mester gør. Jf. parprogrammering i XP. 

– EKSTERNALISERING (eng.: Externalization). Tavs-eksplicit. Her sætter vi ord og begreber 

på den tavse viden, dvs. vi gør den eksplicit. Det sker f.eks. når man laver en softwarehåndbog 

hvor man nedskriver de arbejdsgange vi hidtil blot har udført uden at 

tænke nærmere over det. 

– KOMBINERING (eng.: Combination). Eksplicit-eksplicit. Her opstår nye måder at gøre 

tingene på ved at sammenstille andre. Det sker f.eks. når man i to projekter har gjort 

tingene på hver sin måde og så mødes og finder på noget helt tredje som tager det 

bedste fra de to andre. Det er f.eks. det vi gør under projektevalueringen. 

– INTERNALISERING (eng.: Internalization). Eksplicit-tavs. Her bruger udviklerne den 

beskrevne, eksplicitte viden i praksis, og derved får de den ind under huden så den 

til sidst bliver en del af deres tavse viden – sådan gør vi altså her i huset. 

Modellen stammer fra [Nonaka95] og kaldes SECI-modellen (efter forbogstaverne i de 

engelske betegnelser). Læring er den proces at viden bliver til erkendelse som bliver til 

kunnen. 

Hvis udviklingsafdelingen begynder at få fokus på selve udviklingsprocessen, vil 

det at deltage i udviklingsprojekterne øge udviklernes viden om hvordan man laver 

god udvikling. Men det forudsætter altså lige en lille detalje: der skal være fokus på 

processen. Den skal diskuteres, den skal nedskrives, den skal bruges, den skal ændres. 

Det er i øvrigt sådan man skaber de gode vaner som en projektkultur består af. En måde 

at dele procesviden på er gennem projektevalueringer. Når projektet er slut, evaluerer 

projektgruppen hvordan det gik (se kapitlet om Projektevaluering på side 361). Og 

de positive og negative erfaringer formidles så til de udviklere som ikke selv var med i 

projektet. Det er nu heller ikke uden problemer. Bedst er det hvis man kan sætte navn 

på de “mønstre” man oplevede i projektet. Så kan udviklerne nemlig huske dem når de 

næste gang står i en lignende situation. 

It som formidler af viden 

Mange har forsøgt at understøtte videndelingsprocessen med it-systemer (SECI-modellens 

eksternalisering). Det kaldes også Knowledge Management. Men ifølge sagens natur 

må den viden der gemmes i et it-system være eksplicit. Tavs viden kan selvsagt ikke 

repræsenteres i et it-system. Den eksplicitte viden kan derimod godt – og bliver det. 

F.eks. viden om hvem der ved hvad. Dette benyttes i større organisationer hvor man ad 


denne vej kan finde frem til kolleger som besidder viden inden for et bestemt felt. Men 

lige så snart man forsøger at overføre den konkrete viden med et it-system som mellemled, 

opstår problemerne. Det er hundesvært at lave en ordentlig beskrivelse og endnu 

sværere at få den formidlet ind i hovedet på modtagerne så de faktisk bruger den. 

Brug hinanden 

It-udviklerne skal udnytte hinandens viden i langt højere grad end tilfældet er mange 

steder. Og i udviklingsafdelingerne skal man begynde at udbygge de processer der 

understøtter videndeling. Måske ligefrem stille krav om at man forsøger at bruge hinanden. 

Der er store resurser gemt her. Både økonomisk og kvalitetsmæssigt. For slet ikke at 

tale om den menneskelige dimension: det er sjovt at tilegne sig ny viden. Og kan man 

oven i købet få den fra en god kollega, så er det med til at udbygge sammenholdet blandt 

udviklerne. Det optimale er at udviklerne i fællesskab kan skabe ny viden. F.eks. review 

af hinandens produkter, evaluering af projekterne og diskussion af gode løsninger. 

To-timers-reglen 

I en dansk elektronikvirksomhed har man indført en totimersregel som betyder at hvis 

en udvikler har forsøgt at løse et problem, men ikke har løst det inden for to timer, har 

vedkommende pligt til at få hjælp af en kollega. Flere par øjne ser ofte bedre end et par, 

og man mener her at det simpelthen er spild af virksomhedens tid hvis en medarbejder 

sidder alene og kæmper med et problem uden at komme videre. Især hvis en kollega 

kunne have givet en hjælpende hånd. 

Her hjælper det i øvrigt meget hvis man har et godt og velplejet netværk. Folk er 

mere villige til at hjælpe hvis de på forhånd kender den som kommer og spørger efter 

hjælp. 

Læs mere om videndeling på arbejdspladsen i [Bjerrum03]. 

2.6 Modenhed 

Modenhed handler ikke kun om at være voksen og følsom. Det er i denne forbindelse 

en betegnelse der beskriver en virksomheds evne til at udvikle it-systemer – en evne 

der i øvrigt også omfatter de mere bløde kompetencer. I det følgende vil vi beskrive 

nogle af de modeller der ofte bruges i denne sammenhæng. Men bemærk at det er virksomhedens 

modenhedsniveau der beskrives – ikke det udviklede system. 


2.6.1 CMMI-modellen 

CMMI-modellen (Capability Maturity Model Integration) er udviklet af Software Engineering 

Institute (SEI) ved Carnegie Mellon Universitetet i Pittsburgh, USA. Den blev 

først beskrevet i [Humphrey89] (og hed oprindeligt blot CMM), men der er senere 

kommet opdateringer som kan hentes gratis fra www.sei.cmu.edu. 

Der findes flere CMMI-modeller, men her vil vi se på modellen som beskriver 

softwareudvikling, CMMI-SW. Den omfatter en række procesområder man skal beherske. 

Procesområderne kan inddeles i 5 modenhedsniveauer, 1-5, hvor 1 er det mest 

Niveau Fokus Procesområder 

1. Begynder Helte 

2. Styret Projektstyring Kravstyring 

Projektplanlæging 

Projektstyring 

Underleverandørstyring 

Måling og analyse 

Kvalitetssikring af produkt og proces 

Konfigurationsstyring 

3. Dokumenteret Udviklingsprocessen Udvikling af krav 

Teknisk løsning 

Produktintegration 

Verifikation 

Validering 

Organisatorisk procesfokus 

Organisatorisk procesdefinition 

Organisatorisk uddannelse 

Integreret projektledelse 

Risikostyring 

Beslutningsanalyse 

4. Kvantitativt styret Kvalitet i proces og 

produkt 

5. Optimerende Vedvarende 

procesforbedring 

Organisatorisk procesydeevne 

Kvantitativ projektledelse 

Organisatorisk fornyelse og udbredelse 

Årsagsanalyse og forbedring 


umodne (begynderniveauet), og 5 er det optimale. Dette kaldes den trinvise repræsentation. 

Men det er vigtigt at understrege at (i modsætning til den tidligere CMM-model) 

findes også en kontinuert repræsentation hvor man kigger på hvor meget de 

enkelte procesområder beherskes – uden skelen til trin. 

Selv om I ikke skal CMMI-certificeres, kan det være nyttigt at se på de discipliner 

som modellen fremhæver er vigtige. Det er nemlig de steder hvor du som projektleder 

får størst udbytte af at sætte ind i forhold til jeres projekt. 

Niveau 1 – Begynderniveauet (eng.: Initial) 

Dette kaldes også det kaotiske niveau, her er typisk ikke styr på ret meget. Når det alligevel 

en gang imellem lykkes at aflevere kørende systemer til kunderne, skyldes det 

dygtige udviklere, såkaldte helte. 

Niveau 2 – Det styrede niveau (eng.: Managed) 

Vi kan gentage vores succeser – vel at mærke så længe vi laver de samme ting. Kaster vi 

os over nye områder, går det ofte galt. Og bliver vi pressede, forfalder vi gerne til 

brandslukning – som vi plejer. 

På niveau 2 fokuseres på projektets fundamentale processer, og følgende procesområder 

beherskes: 

– KRAVSTYRING. Formålet med kravstyring er hele tiden at have overblik over kravene 

til projektet. Der skal derfor etableres en effektiv proces til at styre ændringer til kravene 

undervejs i projektforløbet. 

– PROJEKTPLANLÆGNING. Der skal udarbejdes og vedligeholdes fornuftige estimater 

og planer for projektet. 

– PROJEKTOPFØLGNING. Fremdriften i projektet skal synliggøres så man bliver i stand 

til at opdage hvis planerne skrider og handle derefter. Vi skal altså kunne se hvor 

projektet er henne. 

– UNDERLEVERANDØRSTYRING. Eventuelle underleverandører til projektet skal udvælges 

omhyggeligt, og vi skal kunne styre dem effektivt. 

– MÅLING og ANALYSE. Vi skal have etableret et sæt målinger som kan forsyne os med 

de nødvendige informationer for at kunne styre projektet ordentligt. 

– KVALITETSSIKRING. Der skal være passende synlighed, både mht. kvaliteten af selve 

udviklingsprocessen og mht. kvaliteten af det udviklede produkt. Det betyder bl.a. 

fokus på test af den udviklede software og fokus på reviews/inspektioner undervejs 

i udviklingsforløbet. 

– KONFIGURATIONSSTYRING. Sammenhængen og integriteten mellem de ofte mange 


forskellige indgående komponenter i produktet skal sikres. Dette gøres typisk med 

automatiserede værktøjer (f.eks. SourceSafe, PVCS eller CVS). 

Niveau 3 – Det dokumenterede niveau (eng.: Defined) 

Her er der styr på alle udviklingsprocesserne. Vi flytter fokus op fra at kigge på projektet 

til nu at kigge på hele organisationen og dermed skabe et fælles udgangspunkt for 

alle projekter. 

På niveau 3 beherskes følgende procesområder: 

– UDVIKLING AF KRAV. Vi skal være i stand til at tage udgangspunkt i kundens behov 

for derved at opstille de krav til produktet (og eventuelle komponenter) som opfylder 

kundens behov. Kun på denne måde kan vi lave en brugbar kravspecifikation. 

– TEKNISK LØSNING. Det er her vi har fokus på at omsætte produktkravene til et kørende 

system. Vi skal kunne vælge den bedste tekniske løsning (herunder teknologi, arkitektur 

og design). 

– PRODUKTINTEGRATION. Dette procesområde drejer sig om at have styr på det at 

sammensætte det kørende produkt ud fra de indgående komponenter. 

– VERIFIKATION. Vi skal sikre os at produktet opfylder de opstillede krav. Vi skal med 

andre ord sikre os at det vi har lavet er lavet rigtigt. 

– VALIDERING. Vi skal sikre os at produktet opfylder behovet. Vi skal med andre ord 

sikre os at det er det rigtige vi har lavet. 

– ORGANISATORISK PROCESFOKUS. Der skal udarbejdes en plan for forbedring af udviklingsaktiviteterne, 

og aktiviteterne skal koordineres på tværs af hele organisationen. 

– ORGANISATORISK PROCESDEFINITION. Det er under dette procesområde der tænkes 

på softwarehåndbog, definition og beskrivelse af softwareudviklingsprocessen samt 

dokumenterede retningslinjer. 

– ORGANISATORISK UDDANNELSE. Vi skal sikre at alle personer der deltager i projektet 

har modtaget en passende uddannelse i de metoder, standarder, værktøjer og andet 

der benyttes. 

– INTEGRERET PROJEKTLEDELSE. I dette procesområde fokuseres på at få styringen af de 

enkelte projekter tilpasset organisationens vedtagne måde at køre projekter på. 

– RISIKOSTYRING. Vi skal kunne identificere potentielle risici før de opstår så vi eventuelt 

kan iværksætte modforanstaltninger. 

– BESLUTNINGSANALYSE. Vi skal kunne træffe vigtige projektbeslutninger på et kvalificeret 

grundlag og på en kvalificeret måde. 


Niveau 4 – Det kvantitativt styrede niveau (eng.: Quantitatively Managed) 

Her er der fokus på måling og dataindsamling som kan synliggøre processerne. 


– ORGANISATORISK PROCESYDEEVNE. Dette procesområde fokuserer på at måle hvor effektive 

vi er. Her måler vi f.eks. både på udviklingshastighed og på fejlhyppighed. 

– KVANTITATIV PROJEKTLEDELSE. Her drejer det sig om at bruge målingerne aktivt i projektledelsen. 

Vi opsætter mål, og vi laver statistiske analyser. På denne måde bliver vi 

også i stand til at kunne forudsige værdier om projektet, f.eks. omkring antal fejl. 

Niveau 5 – Det optimerende niveau (eng.: Optimizing) 

Her forsøger vi hele tiden at gøre tingene endnu bedre ved en konstant fin-tuning af 

vores processer. 


– ORGANISATORISK FORNYELSE OG UDBREDELSE. Formålet er her at udvælge og udbrede 

de forbedringer til vores processer som vi fra målingerne ved har en virkning. 

– ÅRSAGSANALYSE OG FORBEDRING. Formålet med aktiviteterne i dette område er systematisk 

at finde årsagerne til fejl for herigennem at forhindre at de gentager sig. 

Er dit firma ISO9001-certificeret, er der ingen garanti for at I har styr på softwareudviklingen 

set i CMMI-perspektiv. Typisk vil en ISO9001-certificeret virksomhed opfylde de 

fleste af procesområderne på CMMI niveau 2 og mange af dem på niveau 3. Så en sådan 

virksomhed vil formentlig befinde sig et sted mellem niveau 2 og 3 på CMMI-skalaen. 

Men det er ikke sikkert. 

Som et kuriosum kan nævnes at ifølge Software Engineering Institute ligger 40% af 

softwarevirksomhederne på niveau 4 eller 5 i Indien. Du kan på SEIs hjemmeside finde 

den aktuelle fordeling af virksomheder på de fem niveauer. 

Der findes som nævnt endnu flere modenhedsmodeller som alle også kan findes på 

www.sei.cmu.edu. F.eks. findes en modenhedsmodel for anskaffelse, så hvis du kommer 

fra indkøbssiden, kan du kigge på Software Acquisition Capability Maturity Model, 

SA-CMMI. Her vil det også være relevant at kigge på EUs model for anskaffelsesprojekter, 

ISPL: Information System Procurement Library (tidligere kendt som Euromethod 

– se [Hughes99]). 

Der findes i øvrigt en europæisk pendant til CMMI. Den kaldes Bootstrap (se [Kuvaja94]). 

En selvevaluering i miniformat kan hentes gratis på www.esi.es/Bootcheck. 

Der findes også en ISO-standard for modenhedsvurdering. Den gik tidligere under 

navnet SPICE efter projektgruppen der udviklede den (Software Process Improvement 


and Capability dEtermination), men kaldes nu ISO/IEC 15504. Læs mere om den i 

[Emam97] eller på nettet. 

2.6.2 Andre standarder 

Der findes en række standarder for softwareudviklingsprocessen som kan være nyttige 

at kende til: 

– NATO stiller krav ved leverancer til forsvaret. Der findes bl.a. AQAP-standarderne: 

Allied Quality Assurance Publications. Se f.eks. AQAP-150: “NATO Quality Assurance 

Requirements for Software Development”. 

– FDA, som er det amerikanske Food and Drug Administration, stiller krav til softwareudviklingen 

i bl.a. medicinske produkter. 

– ISO (International Organization for Standardization) har ISO 9001 som opstiller retningslinjer 

for hvordan et kvalitetsstyringssystem skal være opbygget. 

For alle disse standarder gælder det at det ofte er både et særdeles krævende arbejde at 

sætte sig ind i dem og et endnu større arbejde at efterleve dem. Men som regel har man 

ikke noget valg hvis man vil ind på disse områder. 

Endelig findes en “Software Engineering Body of Knowledge” (SWEBOK) (se 

www.swebok.org). Det er dog ikke en egentlig standard, men en samling af alment accepteret 

viden omkring det at lave software. 

2.6.3 Procesforbedring 

Der skal være en sammenhæng mellem kompleksiteten af de opgaver virksomheden 

påtager sig, og modenheden af den udviklingsproces der benyttes. Vil man således 

kunne påtage sig større opgaver – eller har man allerede gjort det – er der grund til at 

forbedre sin udviklingsproces. 

En speciel disciplin inden for projektledelse beskæftiger sig med forbedring af udviklingsprocessen 

(eng.: Software Proces Improvement, SPI). Fokus er her på de tiltag 

som skal bringe virksomheden op ad CMMI-stigen. Man kan sagtens lave procesforbedring 

inden for et udviklingsprojekt (specielt hvis det har karakter af pilotprojekter), 

men det normale er dog at aktiviteten foregår i hele virksomhedens udviklingsafdeling, 

altså på tværs af de enkelte projekter. 

Du kan læse mere om procesforbedring i [Mathiassen02]. 


2.7 Hovedpunkter 

Kapitlet fremhæver følgende hovedpunkter: 

– Vi skal være opmærksomme på flere vigtige processer i projektet: projektledelsesprocessen, 

udviklingsmodellerne og læreprocesserne. 

– Projektledelsesprocessens elementer er opstart, planlægning, udførelse, opfølgning 

og nedlukning. Denne proces sikrer at vi gennem hele projektet har styr på tingene, 

dvs. elementerne i PIP-modellen: Produkt, Interessenter og Proces. Herunder at vi 

kan forudsige hvor lang tid projektet tager, og hvor langt vi er kommet. 

– “Trekanten” beskriver en uløselig sammenhæng mellem tid, omkostninger og funktionalitet. 

Vi kan ikke nøjes med at ændre blot én af faktorerne. 

– Udviklingsmodellerne beskriver vores angrebsvinkel i forhold til at udvikle software. 

De klassiske vandfaldsmodeller antager at vi har et godt kendskab til domænet og derfor 

kan inddele udviklingen i velafgrænsede faser. De iterative modeller går trinvist 

frem i udviklingen og kan derfor drage nytte af den læring der sker undervejs. 

– Udviklingsmodeller med feedback virker. Brug altid en iterativ model hvis du skal i 

gang med noget helt nyt – og hvis der er mulighed for det. 

– Læreprocesserne beskriver den læring projektdeltagerne udsættes for undervejs. 

Den er en vigtig del af projektarbejdet, men glemmes ofte under estimeringen. Det 

skal vi bl.a. være opmærksomme på ved valg af teknologi. Hvis vi vælger en ny og 

uprøvet teknologi som vi ikke har erfaring med, skal vi være forberedt på at der kan 

gå tid med at lære selve teknologien. 

– Modenhed er en virksomheds evne til at udvikle software. Den kan f.eks. beskrives 

ved hjælp af CMMI-modellen.

2. PROCESSERNE - Teknologisk Institut

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?