1. No category

11. Fasemodeller og projektstyring
De !T-systemer, der udvikles til brug i en organisation, skal passe til organisationen. Det vil sige, at systemet skal være af en sådan beskaffenhed,
at de personer,
der skal bruge systemet, føler at det er opbygget på en rationel og effektiv måde. I
dette kapitel vises forskellige fasemodeller, organisationsformer
der kan anvendes ved udvikling og ændring afIT-systemer
og testmetoder,
i virksomheder.
11.4 Fasemodeller
Man har traditionelt
forsøgt at styre systemudviklingen
ved at opdele den i en
række forholdsvis afgrænsede trin. De modeller, der opdeler systemudviklingen
~
i trin kaldes fasemodeller.
Ved at anvende en fasemodel sikrer man, at alle delele-
menter ved udviklingen bliver gennemført - og at de gennemføres i den rigtige
rækkefølge.
Vandfaldsmodeller
De traditionelle modeller i forbindelse med udvikling af nye IT-systemer i 80erne
og 90erne benævnes ofte vandfaldsmodeller.
De er faseopdelte og baseret på den
antagelse, at der er mere bekostelige fejlbeslutninger
processen. Hvis man først er begyndt at programmere
end andre i konstruktionsen applikation,
er det en
ganske bekostelig fejltagelse at opdage, at man er ved at udvikle en løsning på det
forkerte problem. Derfor er vandfaldsmodeller
bygget op omkring en gradvis af-
klaring fra de sværeste problemer til de mere enkle og konkrete problemer.
Hvis slutresultatet i en fase ikke kan leve op til de kriterier, man har opstillet, så
giver vandfaldsmodeller
"lov til" at vende tilbage til tidligere faser. Disse tilbage-
spring er vigtige for at modellen giver mening. Man kan ikke lave en test, der kan
vise, at produktet ikke er godt nok, uden at levne mulighed for at rette op på det.
Formålet med fasemodeller er:
L At fungere som disposition for systemudviklingen
2. At fungere som styringsværktøj
1. Disposition
Ved at gennemføre systemarbejdet
ved hjælp af en fasemodel sikrer man sig, at
man ikke overser noget i forløbet. Samtidig bliver de forskellige opgaver gennemført i en rækkefølge, der erfaringsmæssigt
har vist sig at være hensigtsmæssig.
2. Styringsværktøj
Det er nødvendigt at have en kraftig styring på systemarbejdet.
Fasemodellen kan
være en hjælp til denne styring. Hver fase afsluttes med en beskrivelse af de resultater, man har opnået. Herefter er der mulighed for at tage stilling til om projektet skal videreføres - eller om man skal overveje at omformulere
eller helt op-
give projektet.
214
11. FASE MODELLER OG PROJEKTSTYRING
Forskellige fasemodeller
Der findes en lang række af traditionelle fasemodeller. Grundlæggende
er mange
af disse modeller dog ens. Der er måske lidt forskel i antallet af faser og navngivningen af faserne, men indholdet i modellerne er stort set den samme. Vi vil efterfølgende beskrive følgende modelformer nærmere:
FAKIR
Sociotekniske fasemodeller
Fasemodeller med prototyping
Extreme Programming
De to første må betegnes som vandfaldsmodeller.
FASEMODEL: Model til systemudvikling
der skal gennemløbes
bestående af en række faser,
i rækkefølge.
VANDFALDSMODEL: Traditionel
fasemodel
af nye IT-systemer. Tillader tilbagevenden
11.5 Fasemodellen
i forbindelse
med udvikling
til tidligere faser.
FAKIR
Fasemodellen FAKIR er en traditionel vandfaldsmodeL Den indeholder fem faser:
Forundersøgelse
Analyse
Konstruktion
Igangsætning
Revision
FAKIR-modellen.
11. FASE MODELLER OG PROJEKTSTYRING
215
Som det ses, er det forbogstaverne i de fem faser, der har givet modellen sit navn.
Hver af de fem faser har sit eget formål og indhold.
år en fase er gennemført,
vurderes resultatet, og der vendes evt. tilbage og foretages revisioner.
Forundersøgelse
Formål: At omsætte et problem eller en ide til en konkret beskrivelse af de behov,
man ønsker at få dækket samt at planlægge det resterende projektforløb med hensyn til tidsforbrug, økonomi og organisatoriske ressourcer. Det vil bl.a. sige at udpege det personale, der skal deltage i projektforløbet.
Indhold: Forundersøgelsen
tager sit udgangspunkt
i en ide eller et problem. Ideen
eller problemet skal beskrives, så der er mulighed for at foretage en afgrænsning
af problemområdet.
Man skal foretage en overordnet undersøgelse af virksomhe-
dens eksisterende systemer, både med hensyn til IT-mæssige og organisatoriske
ressourcer.
Analyse
Formål: At få udarbejdet
konstruktionen
en kravspecifikation, der kan danne udgangspunkt
for
eller anskaffelsen af det nye system.
Indhold: Der foretages en beskrivelse og en analyse af det miljø, hvori systemet
skal fungere. Ofte kan det være en fordel detaljeret at beskrive det bestående system, for derved at kunne identificere styrker og svagheder ved dette system. Der
foretages en beskrivelse af det tekniske, sociale og organisatoriske miljø, hvori systemet skal fungere. Beskrivelsen munder ud i en beskrivelse af de krav, det nye
system skal opfylde (kravspecifikation).
Kravspecifikationen
skrivelse af de økonomiske og tidsmæssige begrænsninger,
omfatter også en besystemet er underlagt.
Analysefasen har følgende hovedindhold:
Analyse af eksisterende system
Fastlæggelse af systemmål
Beskrivelse af systembegrænsninger
Udarbejdelse af kravspecifikation
Konstruktion
Formål: At udarbejde - eller anskaffe - systemet i henhold til kravspecifikationen.
Indhold: Der skal udarbejdes en detaljeret beskrivelse af de enkelte dele af det nye
system. Man skal beskrive både de processer, der indgår i systemet og de data, sy-
216
11. FASEMODELLER
OG PROJEKTSTYRING
stemet består af. Beskrivelsen vil typisk foregå ved hjælp af en række standardiserede beskrivelsesværktøjer.
ser og organisatonsstruktur
Også de organisatoriske
forhold, som jobbeskrivel-
skal fastlægges i denne fase. Beskrivelsen omfatter et
designgrundlag, der danner basis for opbygningen af systemet.
Igangsætning
Formål: At få det nye system indpasset i organisationen.
Indhold: Systemet skal testes, lokaler skal indrettes og personale skal uddannes.
Det foretages en test, både af de enkelte delsystemer og af systemet som helhed.
Eventuelle fejl rettes. Data fra et eventuelt gammelt system konverteres til det nye
systernt, og organisationen
tilpasses det nye system.
Revision
Formål: At foretage en opfølgning på det nye system.
Indhold: Man skal have foretaget en analyse af det gennemførte forløb samt af det
endelige resultat. Det drejer sig ikke kun om den rent tekniske side af systemet,
men også de sociale og organisatoriske
ændringer, indføringen
af systemet har
medført. En sådan undersøgelse kan eventuelt foretages som en interview- eller
spørgeskemaundersøgelse.
Denne fase kan eventuelt resultere i enkelte justerin-
ger af systemet. Den kan også medføre, at man er nødsaget til at gå tilbage i faseforløbet for at foretage mere drastiske ændringer i systemet.
FAKIR: Traditionel fasemodel bestående af fem faser:
Forundersøgelse,
Analyse, Konstruktion,
11.6 Socio-tekniske
Igangsætning
og Revision.
modeller
Fasemodeller som f.eks. FAKIR er ofte blevet kritiseret for primært at tage hensyn til den rent tekniske side af sagen. Mange mener, at man derved let kommer
til at overse forhold som miljø, medarbejdernes
veau samt selve organisationsstrukturen.
holdninger
og uddannelsesni-
For at imødegå disse kritikpunkter
har
man udviklet modeller, der i højere grad betoner relationerne mellem systemudviklingen og organisationsudviklingen.
I disse modeller fremhæves vigtigheden
af, at man, samtidig med udviklingen af den tekniske side af et nyt system, også
ser på den sociale side (medarbejderne)
og den organisatoriske
side (strukturen)
- jævnfør Leavitt's model. Ingen af delsystemerne må ses som det primære. Sådanne modeller kaldes ofte socio-tekniske modeller, da de indeholder både sociale
og tekniske aspekter.
11. FASEMODELLER
OG PROJEKTSTYRING
217
Socio-tekniske
fasemodeller kan beskrives som to parallelle forløb. Dels et tek-
nisk forløb, dels et organisatorisk/socialt
forløb:
Forundersøgelse
<,
-:
Analyse af
teknisk system
Organisatorisk
analyse
~
~
Konstruktion
Jobudformning
~
~
Igangsætning
Brugeruddannelse
<,
I
/
Revision
I
FAKIR som en socio-teknisk fasemodel.
Som det ses, er det tekniske forløb i modellen identisk med det, vi kender fra FAKIR-modellen.
Den sociale del indeholder bl.a. organisatoriske
analyser og ud-
formning af job.
Begge forløb i modellen skal prioriteres lige højt. Det er vigtigt, at tiltag og ideer,
der opstår i et af forløbene samtidig kommunikeres
over i det andet forløb, såle-
des at tilpasningen kan foregå begge steder samtidig.
SOCIO-TEKNISK MODEL: Fasemodel bestående af to faseforleb:
teknisk- og et socialt-organisatorisk
Et
forløb.
11.7 Brugerdeltagelse
Udvikling af individuelle, komplicerede systemer er en både tids- og økonomisk
krævende opgave. Ofte er det en opgave, der involverer mange personer. Der er
her både tale om de eksperter, der har erfaring med systemudvikling
og de bru-
gere, der senere skal anvende systemet. Man kan ikke udvikle gode systemer med
mindre man involverer begge disse grupper af personer. Eksperterne er i besid-
218
11. FASEMODELLER
OG PROJEKTSTYRING
delse af en viden, der kan anvendes til at få systemet til- rent teknisk - at fungere. Brugerne ved hvilke behov og krav, der skal stilles til systemet for at få det til
at fungere i dagligdagen.
Modstand mod forandringer
Ændringer
i medarbejdernes
(brugernes)
dem, der berøres af ændringerne.
dagligdag møder ofte modstand
hos
Denne modstand kan skyldes flere ting:
Man skal pludselig ændre vaner.
Frygt for at ens arbejdsopgaver bliver overflødige.
Frygt for ikke at kunne magte de nye opgaver.
Den mulige modstand
mod et nyt system kan i sidste ende være afgørende for
om systemet, bliver en succes eller en fiasko. Hvis denne modstand bliver for stor,
kan et ellers - teknisk set -velfungerende
system vise sig at være totalt ubrugeligt
i dagligdagen.
En meget væsentlig metode til at undgå denne modstand mod forandringer
sørge for, at medarbejderne,
sker. Information
distribueres
er at
gennem hele forløbet, er vidende om, hvad det er der
om det nye system skal gennem hele systemudviklingsforløbet
ud til de berørte medarbejdere.
medindflydelse
på de beslutninger,
medarbejderne
kan foregå på flere måder:
Afholdelse af informationsmøder,
Løbende konsultation
Medarbejdernes
Desuden skal medarbejderne
der tages. Distributionen
af information
have
til
hvor nye ideer og tanker fremlægges.
af medarbejderne.
deltagelse i faseforløbet. se afsnit 11.8.
Trinvist arbejdsforløb.
Forhandlinger
med berørte medarbejdere.
De opgaver, som henholdsvis medarbejderen
og eksperten skal udføre i et fasefor-
løb som FAKIR, fremgår af følgende skema:
11. FASEMODELLER
OG PROJEKTSTYRING
219
ARBEJDSOPGAVER
Fase
Forundersøgeise
Medarbejder
•
•
•
•
Analyse
•
•
Ekspert/designer
Foreslå ændringer
Skitsere
informationsbehov
Beskrive eksisterende rutiner
Beskrive
eksisterende system
Udvælge alternativer
Indsamle data
•
•
Igangsætning
•
Revision
•
•
Foreslå alternativer
Beskrive konsekvenser
mht. tid og økonomi
•
Beskrive og evaluere
eksisterende system
Udarbejde
kravspecifikation
•
•
• Gennemse
Konstruktion
•
•
specifikationer
Designe manuelle
procedurer
•
•
•
•
Udarbejde testdata
og evaluere
testresu Itater
Gennemgå
uddannelsesplan
•
•
•
•
Overvåge systemet
Foreslå forbedringer
det
Udarbejde tekniske
specifikationer
Udarbejde
designgrundlag
Udvikle nyt system
Teste softwa re
Hjælpe med uddannelse
af brugere
Koordinere
overgangsplan
Foretage rettelser af fejl
Overvåge systemet
Foreslå forbedringer
11.8 Projektorganisation
Det er vigtigt, at brugeren/medarbejderen
viklingsforløbet.
- på en formel måde - inddrages i ud-
En måde at gøre dette på er ved at oprette en projektorganisation.
En projektorganisation,
er en organisation,
gennemføre et systemudviklingsprojekt.
der oprettes med det ene formål, at
Projektorganisationen
ganisation. Det vil sige, at organisationen
er en ad hoc or-
nedlægges igen, når projektet er fær-
digt. Man kan sige, at en projektorganisation
er en midlertidig
organisation
varetagelse af et opstået problem. Når problemet er løst, har organisationen
til
ikke
længere nogen berettigelse - og kan derfor opløses.
Den eksisterende organisation, der varetager det daglige arbejde kaldes basisorganisationen. Det er i basisorganisationen,
man har konstateret et problem eller fået
en ide. For at få løst problemet oprettes en projektorganisation
220
11. FASEMODELLER
bl.a. med brugere
OG PROJEKTSTYRING
fra basisorganisationen.
I denne organisation kan brugerne arbejde med proble-
met eller ideen i en periode. Det kan evt. være på deltidsbasis, således at de samtidig kan varetage deres normale opgaver i basisorganisationen.
på deltidsbasis. Projektorganisationen
Om ikke andet så
nedsættes i forundersøgelsesfasen
og be-
står af en styregruppe og en projektgruppe.
Styregruppe:
Styregruppens
opgaver er at:
Formulere problemstillingen.
Definere mål.
Tildele økonomiske og tidsmæssige ressourcer til projektet.
Styregruppen har ret til at afbryde, udvide eller beskære projektets omfang. Det
er derfor nødvendigt, at de personer, der er placeret i styregruppen,
er personer
med kompetence. Det vil sige, at personerne skal have en organisatorisk placering i
basisorganisationen,
der sætter dem i stand til at kunne træffe beslutninger, der be-
rører projektet. Styregruppen suppleres evt. med ekstern ekspertise/konsulenter.
Projektgruppe:
Projektgruppens
opgaver er at:
Gennemføre projektarbejdet.
Udarbejde forslag.
Foretage projekt planlægning.
Projektgruppen
er projektorganisationens
arbejdsgruppe.
ceres derfor brugere, der i basisorganisationen
I projektgruppen
pla-
har en viden om det problemom-
råde, projektet berører. Da man ikke altid kan sikre sig, at der i en organisation
findes tilstrækkelig viden om systemudvikling,
vil man i projektgruppen
kunne
placere eksterne konsulenter. I forbindelse med udvikling af et IT-system kunne
dette være systemplanlæggere/designere.
I projektgruppen
vil der være placeret en projektleder, der varetager ledelsen af
arbejdet i gruppen. Projektlederen
deltager både i projektgruppen
pen. På den måde virker projektlederen
Sammenhængen
og i styregrup-
som bindeleddet mellem de to grupper.
mellem basisorganisationen
og projektorganisationen
kan illu-
streres ved hjælp af følgende figur:
11. FASEMODELLER
OG PROJEKTSTYRING
221
BASISORGANISATION
PROJEKTORGANISATION
EVENTUELLE
EKSTERNE
KONSULENTER
Projektorganisationen henter sine medlemmer fra basisorganisationen og evt. eksternt.
Styregruppen
har det overordnede ansvar for projektforløbet.
Dette gælder både
hvad angår økonomiske og tidsmæssige rammer.
Styreredskab
Fasemodellen giver styregruppen
et redskab til håndtering
slutningen af hver fase skal projektgruppen
af problemer. Ved af-
aflevere en rapport til styregruppen
med en beskrivelse af det arbejde, der indtil dette tidspunkt
er udført. Hermed
har styregruppen - efter en hvilken som helst fase - mulighed for at tage stilling
til projektets videre forløb. I yderste konsekvens kan styregruppen
eventuelt helt
stoppe det videre projektforløb. Styregruppen har også mulighed for at udvide eller begrænse de ressourcer, der tildeles projektet. Sammenhængen
modellen og projektorganisationen
r
II L
STYREGRUPPE
II
F A
mellem fase-
kan illustreres ved hjælp af følgende figur:
I
PROJEKTGRUPPE
Projektorganisationen arbejder efter en fasemodel.
222
11. FASEMODELLER
OG PROJEKTSTYRING
PROJEKTORGANISATION: En midlertidig
organisation
til løsning af et
opstået problem. Består af en styre- og en projektgruppe.
11.9 Nyere udviklingsmodeller
FAKIR-modellen
er kun en af mange metoder til at organisere systemarbejdet
på. Modellen har mange fordele. Bl.a. er den systematisk og nem at overskue. På
trods af dette er der forskellige kritikpunkter,
der kan indvendes mod modellen:
Den kan være en stiv og ufleksibel metode, der ikke giver mulighed for hurtigt
at indarbejde spontant opståede ideer.
Brugeren deltager muligvis ikke fuldstændigt
i konstruktionsfasen.
tager brugeren ofte kun ved fastlæggelse af de grundlæggende
Reelt del-
informations-
behov.
Det kan tage meget lang tid at udvikle systemet. Der kan - i løbet af udviklingsperioden - være sket store forandringer
både i organisationen
og i den
teknologi, der er til rådighed.
I dag er der ikke længere et skarpt skel mellem brugere og IT-eksperter. Computerne er placeret hos brugeren. Og brugeren er dermed ofte selv blevet ekspert.
De traditionelle
eksperterne
fasemodeller blev udviklet på et tidspunkt,
hvor skellet mellem
og brugerne var væsentligt større. Et af formålene med modellerne
var blandt andet at lette kommunikationen
mellem brugeren og eksperten. Når
brugeren selv nærmer sig et ekspertniveau
bliver disse metoder ofte alt for lang-
sommelige. Brugeren har ikke tålmodighed
neret behov, udarbejdet specifikationer
til at vente på, at eksperten får defi-
og programmeret
systemet. Ofte vil bru-
geren selv kunne udvikle systemet langt hurtigere.
En stor del af omkostningerne
ved traditionel
systemudvikling
har vist sig at
stamme fra den tid, der går med at opstille krav til systemer. Hvis brugeren selv
kom tættere på den egentlige systemudvikling,
kunne en del af disse omkostnin-
ger måske spares. Brugeren kender jo bedst de behov, der skal dækkes af det nye
system.
Derfor har man set en udvikling hen imod nogle metoder, der i højere grad inddrager brugeren i selve designprocessen
f.eks. prototyping og eXtreme Program-
ming (XP). De to metoder beskrives i de følgende afsnit.
11. FASEMODELLER
OG PROJEKTSTYRING
223
11.10 Prototyping
og FAKIR
Mange systemer opfattes af brugeren som "dårlige" systemer, fordi misforståelser mellem eksperten og brugeren ikke blev konstateret i tide. I sin yderste konsekvens kan dette betyde, at systemerne slet ikke bliver anvendt i virksomheden.
Og dermed vil et - måske ellers velfungerende - system blive opfattet som en fejlinvestering. De nævnte misforståelser kan skyldes flere ting:
Forskelle i sprogbrug mellem brugeren og eksperten.
Den tid, der går fra behovene klarlægges, til systemet er færdigt.
Uklarhed hos brugeren om hvad der egentligt kan forventes.
Disse forhold kan medføre, at det system, der præsenteres for brugeren, er et helt
andet, end det system brugeren forventede.
Prototyping
Protyping er en samling af teknikker og metoder til at reducere misforståelser og
klargøre de behov, der udtrykkes af brugeren. Ved hjælp af disse teknikker sikrer man, at de to parter i udviklingsforløbet
Grundlaget
for prototyping
"følges ad" gennem hele forløbet.
er, at eksperten løbende viser brugeren, hvad syste-
met kan, og hvordan det ser ud. Brugeren kan så -løbende
pertens forslag og komme med ændringsforslag.
- tage stilling til eks-
Der udarbejdes således løbende
nogle prototyper, som brugeren kan tage stilling til. Proceduren kan illustreres i
følgende figur:
Forundersøgelse
,l.
Analyse af
brugerens basale
behov
l
Konstruktion
(Udarbejdelse af
første prototype)
r-----.
••
Analyse
(Brug prototype til
at identificere
brugerens behov)
I
-+
Konstruktion
(Revider og udvid
prototype)
l
Igangsætning
~
Revision
Det typiske forløb ved prototyping.
224
11. FASEMODELLER
OG PROJEKTSTYRING
Det er i konstruktionsfasen,
at forskellen til de traditionelle metoder er tydeligst.
Der udarbejdes her en prototype af systemet. Brugerens rettelser og kommentarer indbygges herefter i en revideret udgave af prototypen. Denne proces fortsætter indtil brugeren accepterer prototypen
(markeret med fede pile i modellen).
Herefter kan det endelige system færdiggøres og igangsættes.
Prototyping
kan foregå på flere måder. Grundlæggende
findes der tre kategorier
af prototyper:
Ikke-virkende prototype:
Ved denne metode opbygges en prototype af systemet, der rent faktisk ikke
virker. Man opbygger skærmbilleder,
rapporter
og andre systemelementer,
der kan bruges til at kommunikere
___
----'~
Mod"
med
brugeren. Men systemet virker ikke
- det er kun en overflade.
og systemkonstruktøren
brugerflade,
Når brugeren
er nået til en
der kan accepteres af begge
parter, skrottes prototypen,
og det
rigtige system opbygges.
Evolutionær prototype:
Her opbygges det færdige system del for
del. Den første prototype
Fungerende
system
------'
er en simpel
udgave af det færdige system. Herefter
raffineres systemet i de efterfølgende
~
faser, således at systemet til sidst
fremstår som et færdigt system.
Pilotprototype, :
Denne metode er velegnet i situationer,
Fungerende
system
hvor der skal installeres ens programmer
på flere arbejdspladser
organisation.
i den samme
Man konstruererførst
Fungerende
færdigt system og installerer
system
en arbejdsplads.
et
dette på
Herefter undersøges
dette system for eventuelle fejl og
mangler. Når disse er udbedret,
Fungerende
system
indføres det forbedrede
arbejdspladser
system på flere
for til slut at være indført
i hele organisationen.
11. FASEMODELLER
OG PROJEKTSTYRING
225
PROTOTYPING: Systemudvikling
ved opbygning
af en model af det
færdige system. Denne model kan så senere ændres og tilpasses efter
brugerens ønsker.
11.11 eXtreme Programming (X P)
I "vandfaldsmodellerne"
har en af de helt generelle tendenser altid været at flytte
flere og flere aktiviteter op foran selve programmeringsarbejdet.
gjort grundigt med en omfattende kravspecifikation,
digt design af arkitekturen;
så er kodningsarbejdet
XP er en nyere arbejdsform/model,
en god analyse og et grun-
blot en "formalitet".
der kritiserer de traditionelle
vendelse, specielt ved programudvikling.
vikling af programmer
Er forarbejdet
modellers an-
XP er opstået i en erkendelse af, at ud-
adskiller sig fra de fleste andre udviklingsprojekter.
Det er almindeligt erkendt, at de specifikationer, der udfærdige s først i et længerevarende projektforløb med programudvikling,
met bedst muligt, da programmets
ofte viser sig ikke at løse proble-
forudsætninger
har ændret sig i den mellem-
liggende tid.
XP er en metode, der tager det for givet, at specifikationer
ændrer sig hen over
tiden. Antagelsen er, at "vi bliver alle klogere undervejs i et projektforløb",
udviklerne/specialisterne
som en fremgangsmåde,
og kunden/brugerne.
både
Metoden kan også karakteriseres
der giver et bud på, hvordan man kan udvikle program-
mer i en omskiftelig verden.
Metoden involverer samtidig alle parter i et projekt til programudvikling,
leverandørsiden
både
og brugeren. Alle skal arbejde sammen og bidrage med nye ideer
i udviklingsprocessen.
XP opfatter et projekt til programudvikling
som et dynamisk system med fire
indbyrdes afhængige variable:
Pris
Kvalitet
Tid
Indhold
226
11. FASEMODELLER
OG PROJEKTSTYRING
Det vigtige i tankegangen i XP er erkendelsen af sammenhængen
mellem varia-
blene. At de fire variable er afhængige betyder, at når de tre af dem holdes fast, vil
systemet give den fjerde.
Så hvis man siger:
"Vi vil udarbejde dette økonomiprogram
med disse funktioner/dette
indhold
i højeste kvalitet til en pris på kr. 100.000",
så svarer systemet med den tid, det tager. Den er i øvrigt ofte en del højere, end
det man forventer.
EXTREME PROGRAMMING (XP): Metode til programudvikling,
tager det for givet, at forudsætninger
løbet af den tid udviklingsarbejdet
og specifikationer
der
ændrer sig i
foregår.
11.12 Valg af udviklingsmodel
Alle fasemodeller har deres fordele og ulemper. Det er ledelsens opgave at vælge
den rette fasemodel til de rette systemer. Der er flere parametre, der kan være afgørende for valget.
Antal brugere
Nogle systemer skal anvendes på mange arbejdspladser
i en organisation. Andre
systemer anvendes kun på en eller ganske få arbejdspladser. Jo bredere anvendelse
et system har, jo vigtigere er det, at man har standardiseret
den måde, systemet
fungerer og fremtræder på. Dette vil gøre fejlretning og justering af systemet lettere, end hvis der findes mange forskellige løsninger på det samme problem.
Funktionalitet
Nogle systemer har en forholdsvis. afgrænset funktionalitet.
Systemet modtager
ingen eller kun få data fra andre systemer i organisationen. Andre systemer spiller
kraftigt sammen med virksomhedens
øvrige delsystemer. Der modtages og sendes
data til disse systemer. I jo højere grad et system skal arbejde sammen med andre
af organisationens
systemer, jo mere må man strukturere
systemudviklingen.
Opgavens kompleksitet
Nogle systemer fremtræder som små, velafgrænsede, løsninger på problemer, der
er opstået i organisationen.
11. FASEMODELLER
Andre systemer fremtræder som store komplekse sy-
OG PROJEKTSTYRING
227
stemer, der er i stand til at håndtere en stor mængde af de arbejdsopgaver, organisationen står overfor.
J o mere kompleks et system er, jo mere uoverskuelig bliver udviklingen. Det medfører, at man bør strukturere
udviklingen for at kunne holde styr på alle de dele,
der indgår.
Hvis vi sammenholder
disse tre parametre med de kendte traditionelle
faserno-
deller, kan dette summeres i følgende tabel:
Antal brugere
Mange
Opgave
Få
Applikationspakke/
Kompleks
Simpel
Applikationspakke/
FAKIR
Prototype
Prototype
Brugerudvikling
Tabellen skal ikke opfattes som absolut. Der kan være forhold i en organisation,
der gør, at man vil vælge en anden end den, der fremtræder af tabellen f.eks. eXtreme Programming.
En organisation kan også være i besiddelse af så stor IT-vi-
den, at selv ret komplekse systemer kan udvikles af brugeren selv, dvs. ved brugerudvikling.
11.13 Testmetoder
Ved udvikling og ændring afIT-systemer
er det vigtigt at foretage grundige tests,
før systemerne frigives. Der kan gives talrige eksempler på såvel offentlige som
private II-systemer, der har været fatalt fejlbehæftede ved ibrugtagningen.
Testen
kan opdeles i 2 dele: Systemtest og test afbrugervenligheden.
Systemtest
Her tester man, om systemet rent teknisk virker, som det skal. Hvis det er et helt
nyt system, kan det evt. forsøgsvist bruges samtidig med et gammelt system, der
udfører de samme opgaver (parallelkørsel).
Det er vigtigt, at alle muligheder af-
prøves og kontrolleres. Testen bør indeholde følgende elementer:
22.8
11. FASEMODELLER
OG PROJEKTSTYRING
Afprøvning af samtlige funktioner.
Test af systemet sammen med andre systemer.
Afprøvning og kontrol af ind- og uddata.
Test af fejlmeddelelser.
Test af kontroller f.eks. med helt urealistiske inddata.
Test af sikkerhedsprocedurer,
herunder faciliteter til sikkerhedskopiering.
Test afbrugervenlighed
Det er ikke nok at have et teknisk velfungerende system. Brugerne skal også kunne finde ud af, at bruge det effektivt. Det bør være brugervenligt.
anvendt målestok for brugervenlighed
I en almindelig
indgår følgende elementer:
IT-systemet skal være:
Let at lære for målgruppen/brugerne
(kort indlæringstid) .
Let at huske.
Stabilt og pålideligt.
Effektivt at bruge.
Tilfredsstillende
Brugervenlighed
at bruge.
er i sagens natur et svært begreb at måle, da det indeholder man-
ge kvalitative og subjektive elementer. Brugervenligheden
forsøges ofte vurderet
ved hjælp af tests, hvor brugeren iagttages og præstationsmåles
under kontrolle-
rede forhold.
Spørgeskemaer og interviews kan anvendes f.eks. ved vurderingen
ne mener, systemet er tilfredsstillende
af, om bruger-
at bruge.
Se i øvrigt kapitel 10, der bl.a. omhandler brugervenlighed
SYSTEMTEST: Her tester man om systemet
skal.
og design.
rent teknisk virker, som det
TEST FOR BRUGERVENLIGHED: Test af om systemet er let at lære, let
at huske, stabilt og pålideligt,
11. FASE MODELLER
effektivt
OG PROJEKTSTYRING
og tilfredsstillende
at bruge.
229