Systemudvikling via prototyper

Transkript

1 DIKU, Systemarbejde E85 Erik Frøkjær Systemudvikling via prototyper 1 Indledning med sammenfatning Systemudvikling via prototyper (på engelsk "prototyping") er en ret ny måde at gribe systemudviklingen an på, når det drejer sig om administrative opgaver. Det færdige edb-system udvikles via et antal prototyper (forenklede, kørende edb-modeller af det ønskede system), som efter afprøvning i det lokale arbejdsmiljø videreudvikles i et direkte samarbejde mellem de kommende brugere og edb-kyndige, indtil et tilfredsstillende resultat er opnået. Via eksperimenter med prototyper opnås empirisk viden om brugbarheden af ideerne til det påtænkte edb-system. Denne synsmåde ligger bag en anden betegnelse "eksperimentel systemudvikling", som kan bruges synonymt med betegnelsen "systemudvikling via prototyper". I takt med fremkomsten af stadigt mere effektive systemudviklingsværktøjer - ofte markedsført under betegnelsen 4. generationssprog - bliver denne form for systemudvikling mere og mere konkurrencedygtig i forhold til traditionelle systemudviklingsmetoder, der karakteriseres ved omfattende skriftlige specifikationer af det ønskede edb-system; specifikationer som gradvist detaljeres i systemudviklingsprocessens enkelte faser, indtil et kørende edb-program som en del af det ønskede edb-system er realiseret. Erfaringer tyder på, at benyttelse af de nye værktøjer og teknikker kan øge kvaliteten og produktiviteten i systemarbejdet. Ikke blot selve konstruktionen af programmer kan forenkles. Især i det indledende arbejde med problemanalyse og klarlægning af krav til det ønskede system kan opnås betydelige gevinster med hensyn til kvalitet, tid og økonomi. I forhold til traditionelle systemudviklingsmetoder giver systemudvikling via prototyper helt anderledes gode muligheder for, at brugere og edb-teknikere kan arbejde sammen om opbygning af nye edb-systemer. Afprøvningen af prototyperne giver et konkret grundlag for at vælge mellem alternative løsningsmuligheder, og grundlæggende beslutninger vedrørende systemets udformning kan lettere revideres i takt med indhøstede erfaringer. Systemudvikling via prototyper kræver øget indsigt i systemudviklingsprocessens indhold og styring, også hos brugerne, fordi fremgangsmåden forudsætter en mere direkte og aktiv deltagelse i systemudviklingen fra brugernes side. Ledelse, ansatte og edb-teknikere skal finde frem til nye samarbejdsformer, for at denne form for systemudvikling kan foregå effektivt og betryggende for alle parter Ḋer er endnu ret få erfaringer med anvendelse af prototypeudvikling i forbindelse med administrative edb-systemer, specielt når det drejer sig om større edb-opgaver med mange og komplicerede grænseflader til forskellige brugerkredse og andre administrative rutiner. I forbindelse med sådanne systemer må imødeses større problemer med at inddrage brugerne i den aktive form, som er en forudsætning for systemudvikling via prototyper. Vanskelighederne med at træffe beslutninger vokser ligeledes, ikke mindst når delvist modsatrettede hensyn skal forliges. Denne problemstilling bliver særlig markant, når systemerne omfatter flere selvstændige virksomheder. Parterne vil under prototypeudvikling opnå større klarhed om egne, lokale muligheder, hvorfor der vil være en tendens til at søge opdeling af større edb-systemer i mindre delsystemer. En sådan opdeling af meget omfattende edb-systemer i mindre delsystemer kan medvirke til at opnå en vis systemmæssig enkelhed. Omstillingsevne i det samlede system kan herved øges under forudsætning af, at den nødvendige samordning af delsystemerne kan fastholdes, f.eks. i en overordnet edb-rammeplan, der afstikker mål for og fastlægger snitflader mellem de enkelte delsystemer. Uden baggrund i et samlet overblik over virksomhedens status og behov vedrørende informationssystemer, f.eks. i form af en edb-rammeplan, vil der være risiko for, at systemudvikling via prototyper i forhold til traditionelle systemudviklingsmetoder kommer til at foregå på et mere indsnævret grundlag, hvorved gennemgribende og kvalitative forbedringer i virksomhedens informationsbehandling vanskeliggøres [1]. I det efterfølgende kapitel 2 omtales begrebet prototype i tilknytning til systemudvikling. Herefter gives i kapitel 3 en karakteristik af vigtige arbejdsfunktioner i systemudvikling via prototyper. I kapitel 4 indføres en skelnen mellem tre hovedformer for anvendelse af prototyper i et systemudviklingsforløb. I kapitel 5 omtales værktøjer og teknikker til prototypeudvikling. Det ville 1

2 have været naturligt at afslutte dette notat med en opsummering af konsekvenser ved anvendelse af prototypeudvikling. Jeg har imidlertid ikke fundet det muligt på nuværende tidspunkt. Erfaringerne er endnu ret begrænsede, og prototypeudvikling dækker over så forskellige fremgangsmåder, at sammenstillinger af de i litteraturen omtalte erfaringer er yderst vanskelig og indebærer stor risiko for misfortolkninger. 2 Om begrebet prototype i systemudvikling Den grundlæggende vanskelighed ved at definere begrebet prototype i forbindelse med systemudvikling er, at begrebet ikke fuldt ud kan bruges i sin oprindelige betydning. "Prototype" betyder egentlig "en første version af en ny type, hvis produktion er under forberedelse". Det giver mening inden for de grene af industriel produktion, hvor det er hensigten at masseproducere varer af samme type. F.eks. bruges begrebet ofte i forbindelse med bilproduktion og flyproduktion. Udvikling af prototyper refererer på disse områder til en veldefineret fase i produktionsprocessen. Prototypen er en model, der indeholder alle de væsentlige egenskaber for det endelige produkt. Den realiseres inden typen sættes i masseproduktion og bruges til afprøvning af, om typens faktiske egenskaber kan leve op til de opstillede mål. Prototypen anvendes tillige til indretning af fremstillingsprocessen for den kommende masseproduktion. Systemudvikling adskiller sig fra en sådan fremstillingsvirksomhed på flere måder. I systemudvikling er der ofte tale om udvikling af enkeltprodukter i form af såkaldte skræddersyede systemer. I så fald er der ikke tale om massefremstilling af produkter med mindre udviklingsopgaven drejer sig om standardprogrammel som f.eks. tekstbehandlingsprogrammel, programmel til elektronisk regneark eller basisprogrammel. Endvidere er de ønskede egenskaber for edb-produkter normalt ikke særlig veldefinerede på forhånd. Det gør det vanskeligt at definere ordet "type" i forbindelse med systemudvikling på en relevant måde. Samtidig er det uklart, hvad der skal forstås ved "første", d.v.s. hvorledes prototypen skal forholde sig til det endelige produkt. Begreberne kompliceres yderligere af det faktum, at betegnelsen "udvikling af prototyper" kan anvendes meningsfuldt både i tilknytning til produktet som helhed og i tilknytning til dele af produktet. F.eks. kan udvikles prototyper af en bil og bilens motor. Endelig er brugen af betegnelsen "prototypeudvikling" i forbindelse med systemarbejde et udtryk for, at vi primært er interesseret i processen fremfor i prototypen som produkt. Vi søger at finde frem til arbejdsprocesser, som giver mulighed for, at relevante dele af det ønskede programmel på et tidligt tidspunkt kan demonstreres i praksis som kørende model på en datamaskine. Herved kan prototypen afprøves i forbindelse med andre processer i systemudviklingen med det sigte at øge kvaliteten af det edb-baserede system, der er under udvikling og indførelse. Mange systemudviklere motiveres til at anvende prototypeudvikling ud fra egne markante erfaringer fra praksis: - Først nu - efter at systemet er udviklet og sat i drift - ved vi, hvordan vi skulle have opbygget det. Bare vi kunne få lov at smide de gamle programmer bort og nyudvikle ud fra den indsigt, vi har i dag. Det ville kun koste lidt i forhold til de oprindelige udviklingsomkostninger. Problemet er mest at få tid, da mange vedligeholdelsesopgaver presser sig på. - Når jeg udvikler programmel til eget brug, udvikler jeg ofte den ene version efter den anden. Fra arbejdet med værktøjet får jeg gode ideer til faciliteter, som det skal indeholde for at være egnet til de aktuelle arbejdsopgaver. Prototypen skal først og fremmest betragtes som et middel til at lære. Den giver mulighed for at indhøste visse praktiske erfaringer med det ønskede system, således at der under indtryk heraf gradvist kan opbygges bedre og mere præcise ideer om det færdige system. Det overordnede sigte med systemudvikling via prototyper er at bidrage til kvaliteten af det færdige produkt. I dette notat betragter vi systemudvikling via prototyper som en række teknikker, der vil kunne indpasses i flere forskellige systemudviklingsmetoder. Prototypeudvikling tjener til at indføre et element af kommunikation og feed-back i systemudviklingsforløbet. Den fremadrettede, lineære udviklingsproces, som præger de faseorienterede systemudviklingsmetoder, brydes af mere eller mindre omfattende cykliske forløb. 2

3 udførelse af eksperimenter konstruktion af edb-model evaluering Figur 1: Prototypeudvikling indfører cykliske forløb som en ønsket del af systemudviklingsforløbet. I kapitel 4 behandles, hvorledes forskellige tilgange til systemudvikling via prototyper medfører forskellige grader for nedbrydning af den lineære følge af udviklingstrin, idet en følge af cykliske forløb indpasses på forskellige trin i systemudviklingsforløbet. Behandlingen af emnet i dette notat sigter på et anvendelsesområde, hvor edb-systemerne er tænkt at understøtte mennesker direkte i deres arbejdsprocesser - som enkeltpersoner og indgående i grupper. Der er primært tænkt på systemer til støtte ved løsning af administrative opgaver eller planlægningsopgaver. Sådanne edb-systemer kan karakteriseres ved tre forhold: En interaktiv brugergrænseflade, viden om databehandlingsprocesser på algoritmisk form og en stor database. I mangel på et bedre navn skal vi her benytte betegnelsen "interaktivt informationssystem" for disse systemer. Kvaliteten af et interaktivt informationssystem er i det væsentlige bestemt af dets egnethed som redskab for mennesker som brugere. Undersøgelse og vurdering heraf kræver inddragelse af både psykologiske og sociale faktorer, f.eks. menneskelig kognition (opbygning af viden og forståelse), kommunikation og samarbejde. Disse faktorer kan kun med stor vanskelighed undersøges på grundlag af skriftlige systemspecifikationer [2]. Eksperimenter med prototyper i forbindelse med interaktive informationssystemer vil normalt tage sigte på at forbedre og konkretisere kommunikationen mellem systemudvikler og bruger, hvad angår spørgsmål om fastlæggelse af systemfunktioner og datagrundlag samt opbygning af grænseflader mellem mennesker og maskine. Prototypen kan eventuelt også benyttes til at demonstrere den tekniske egnethed af en ide til opbygning af systemet, f.eks med henblik på at opnå effektivitet i en særlig kritisk del af edbsystemet. Herved kan prototypen støtte projektgruppen i arbejdet med specifikation og design inden implementering af et stort og teknisk kompliceret informationssystem. Sammenfattende kan systemudvikling via prototyper, også kaldet eksperimentel systemudvikling, defineres ved følgende: Systemudvikling via prototyper tager sigte på at fastlægge særlig betydningsfulde eller uforudsigelige egenskaber ved et ønsket edb-system på et delvist empirisk grundlag, for derved at opnå øget sikkerhed i beslutninger om systemets udformning. Hovedvægten lægges på eksperimenter med systemets ydre egenskaber, hvor samspil mellem organisation, menneske og maskine indeholder mange elementer, som ikke kan behandles fyldestgørende på et rent teoretisk grundlag. Eksperimenterne foregår som mere eller mindre realistiske forsøg med kørende edb-modeller, normalt under direkte inddragelse af systemets kommende brugere. Systemudvikling via prototyper betegner således ikke en enkelt, sammenhængende metode til systemudvikling, men en samling teknikker, som kan udnyttes i forbindelse med forskellige systemudviklingsmetoder. 3 Karakteristik af systemudvikling via prototyper Systemudvikling via prototyper kan ses som bestående af fire trin: udvælgelse af funktioner, konstruktion, evaluering og fortsat brug. Beskrivelser i dette kapitel bygger primært på Bansler & 3

4 Bødker (1983), Floyd (1983) og Mogensen (1985), se [3]. Udvælgelse af funktioner refererer til udvælgelse af de funktioner, som prototypen skal indeholde. Udvælgelsen skal altid tage sigte på relevante arbejdsopgaver, som kan udnyttes til demonstration og afprøvning. I forbindelse med prototypen udvikles de udvalgte funktioner ikke i fuldt omfang, d.v.s. ikke i det omfang som det ønskes i det færdige edb-system. Forskellen mellem omfanget af funktioner i prototypen og det endelige system kan gå på to dimensioner: - vertikal prototypeudvikling, dvs at funktionerne i prototypen er implementeret i den tilsigtede, endelige udformning, men kun udvalgte funktioner er medtaget; - horisontal prototypeudvikling, dvs at funktionerne i prototypen ikke er implementeret i de detaljer som ønskes i det endelige system. De kan dog bruges til demonstration, selv om dele er udeladt eller blot indgår simuleret på edb-form eller f.eks. ved anvendelse af papirmodeller, lysbilleder eller video. Ofte vil disse to former for prototyper være kombineret i forskellige dele af den samlede prototype. Konstruktion betegner den indsats som er nødvendig for, at prototypen kan gøres tilgængelig. Normalt skal indsatsen være meget mindre end det, der kræves for at konstruere det endelige system. Det kan opnås ved passende udvælgelse af funktioner i prototypen og ved brug af egnede teknikker og værktøjer til konstruktion af prototypen. Ved konstruktion af en prototype skal der lægges primær vægt på den ønskede evaluering, ikke på efterfølgende brug af prototypen i ordinær drift. Det medfører, at visse kvalitetskrav, som skal være opfyldt af det færdige system, f.eks. pålidelighed, datasikkerhed og effektivitet, kan udelades i forbindelse med prototypen, med mindre det netop er sådanne faciliteter, der ønskes afprøvet. F.eks. vil effektivitet i prototypen være af central betydning i eksperimenter med svartider som den kritiske faktor for opnåelse af en god arbejdsrytme. Evaluering er det afgørende trin i forbindelse med prototypeudvikling, da det er her der opnås feedback til den fortsatte udviklingsproces. Derfor er det vigtigt, at projektorganisationen afsætter de nødvendige ressourcer til en systematisk evaluering, der inddrager alle relevante grupper af kommende brugere. Evaluering er først meningsfuld efter en rimelig indlæring og bør udstrækkes over et passende tidsrum. Den bør baseres på et dokument, som gør eksplicit efter hvilke kriterier evalueringen skal gennemføres, og hvilke arbejdsfunktioner afprøvningen skal omfatte. Det er væsentligt, at det ikke alene er selve edb-delen, prototypen, men også de tilgrænsende arbejdsfunktioner, som inddrages i afprøvningen. Endvidere må tages hensyn til de aspekter af arbejdet, som ikke kan formaliseres, så som afbrydelser, håndtering af "nødsituationer", samtale med andre ansatte og meget andet. Fortsat brug af prototypen kan ske på flere måder afhængig af de erfaringer, som er opnået ved evalueringen. F.eks. kan prototypen anvendes som redskab ved undervisning i det kommende system og kan eventuelt bibeholdes til senere kursusbrug. Eller den kan indgå som en komponent i det endelige system - fuldstændigt, delvist eller efter modifikation. Det behandles nærmere i kapitel 4 og 5. Her skal alene fremhæves, at brugeres og systemudvikleres motivation ofte viser sig at være meget større, når prototypen videreudvikles med henblik på senere brug. Da prototypen primært anvendes som et middel til at lære, skal der drages omsorg for, at systemudviklingsprocessen tilrettelægges som en læreproces. Det kræver opmærksomhed på flere aspekter, hvoraf kan fremhæves: Tidlig tilgængelighed. En prototype skal være tilgængelig meget tidligt i systemudviklingsprocessen i en form, som kan demonstreres for brugerne. Demonstrationen skal være meningsfuld i sammenhæng med brugerens arbejdsprocesser. Det betyder, at demonstrationen skal baseres på virkelige og ikke-trivielle problemer for at gøre afprøvningen relevant. Det skal være let at ændre prototypen ved revision af de indeholdte funktioner eller ved tilføjelse af nye. Herved bliver det muligt at modificere prototypen under evalueringen i direkte og hurtig dialog med brugerne. 4

5 Alternative løsninger. Flere alternative løsninger bør demonstreres på et tidligt tidspunkt for at give brugere og systemudviklere mulighed for at få konkret indsigt i forskellige løsningsmuligheder. Præsentation af alternativer giver ofte brugere et bedre grundlag for selv at foreslå nye alternativer. Det gælder om at få sådanne ønsker frem så tidligt som muligt, så det undgås at lægge sig fast på en bestemt løsningsvariant på et tilfældigt eller indsnævret grundlag, som senere kan vise sig uholdbart - økonomisk, teknisk eller organisatorisk. Lære og indøve. Efter evaluering og modifikation af en prototype kan en brugbar prototype eventuelt anvendes som undervisningsmiddel for brugere af det kommende system. Forpligtelse. Hvis en prototype er demonstreret og de kommende brugere er inddraget i evalueringen af prototypen, vil der normalt mellem de involverede parter være en klar, gensidig forpligtelse, hvad angår forbindelsen mellem prototypen og det færdige system. Hvis der indføres væsentlige forandringer i nogle funktioner ved implementeringen af det færdige system uden eksplicit godkendelse fra brugerne, må man indstille sig på alvorlige problemer med hensyn til brugernes accept. 4 Forskellige former for systemudvikling via prototyper Der kan skelnes mellem følgende tre hovedformer for anvendelse af prototyper i systemudviklingen, jf. Bansler & Bødker (1983), se [3]: - Prototyper til undersøgelse af krav til det påtænkte edb-baserede system gennem eksperimenter med forskellige edb-modeller, idet eksperimenterne gennemføres i kunstige omgivelser og på basis af fiktive data. - Prototyper til eksperimenter i virkelige omgivelser på basis af virkelige data med henblik på en nogenlunde dækkende afprøvning af det kommende edb-systems funktionalitet og samspillet mellem mennesker, organisation og maskinsystem. - Prototyper til versionsudvikling, hvor prototypen udgør en fuldt funktionsduelig version af det edb-system, som er under udvikling. Ved versionsudvikling foretages en konkret afprøvning i virkelige omgivelser inden udviklingsopgaven anses for fuldført. Udviklings- og driftfasen smelter sammen. Efter gradvis accept og idriftsættelse af systemet kan erkendte, nye udviklingsbehov tages op og give anledning til indførelse af en ny version af edb-systemet. 4.1 Prototyper til undersøgelse af krav Prototyper kan anvendes til empiriske undersøgelser af krav og ønsker til det påtænkte edb-system, på et tidspunkt hvor systemet alene er mere eller mindre entydige visioner i brugernes og systemudviklernes hoveder. Alternative muligheder belyses gennem eksperimenter med forskellige, forenklede edb-modeller af det ønskede edb-system. I forbindelse med denne form for prototypeudvikling taler man også om eksperimenter med "skelet-modeller", modelskitser eller systemskitser, hvorved forstås kørende edb-modeller, der dog kun omfatter enkelte, udvalgte egenskaber ved det påtænkte edb-system. Oftest vil eksperimenterne tage sigte på afklaring af systemets ydre egenskaber, f.eks. brugergrænseflader i form af skærmdialoger, udformning af rapporter fra systemet m.v.. Normalt vil edb-modellerne arbejde på testdata fremfor virkelige data. 5

6 Visioner om nyt system Edb-modeller Edb-system i drift tid Figur 2: Prototyper til empiriske undersøgelser af krav Prototyper af denne art er ikke egnet til afprøvning og vurdering af hele samspillet mellem edbsystemet og de tilhørende manuelle arbejdsgange, under ét kaldet det edb-baserede system, jf. figur 2, hvor den afsluttende lodrette streg, skal symbolisere et tidspunkt for beslutning om projektets videreførelse. Der kan også være tale om opbygning af prototyper, hvis sigte er eksperimenter med systemets indre egenskaber, f.eks. alternative datastrukturer eller modulstrukturer, afprøvning af særlig kritiske forhold vedrørende svartider m.v.. I sådanne tilfælde er prototypen i hovedsagen et redskab for systemudviklerne, og brugerne inddrages kun i begrænset omfang. Anvendelse af prototyper i denne form kan indpasses i en faseorienteret tilgang til systemudviklingen og tjener til at forbedre kvaliteten af de tidlige faser i udviklingsprocessen, d.v.s. arbejdet med kravspecifikation og analyse af det kommende systems funktioner. Der kan være god grund til at sætte ressourcer ind på at forbedre kvaliteten i arbejdet med denne indledende del af systemudviklingsprocessen. Ressourcer krav og analyse design programkodning og test 60 procent indførelse tid Figur 3: Det største ressourceforburg i et systemudviklingsprojekt foregår typisk under arbejdet med programkodning og test i forhold til en given designspecifikation. Selv om en stor del af ressourceforbruget ved udvikling af administrative edb-systemer går til programkodning og test (se figur 3) tyder flere empiriske undersøgelser på, at de væsentligste fejlkilder og forandringsbehov under edb-systemernes vedligeholdelse kan føres tilbage til mangler eller utilstrækkeligheder i det indledende arbejde med kravspecifikation. Figur 4 henfører fejl og utilstrækkeligheder, som senere udbedres under systemernes vedligeholdelse, til "kilder" i betydningen, hvor i systemudviklingsforløbet rettelsen skulle indarbejdes. 6

7 andre programkodning og test 7% 10% design 27% kravanalyse 56% Figur 4: Fordeling af "fejl" på kilder. Figur 5 viser omkostningerne ved at udbedre manglerne. Denne fordeling af udgifterne til vedligeholdelse skal sammenholdes med det forhold, at vedligeholdelsesomkostningerne som helhed er meget betydelige og beslaglægger en stor del af de uddannede edb-teknikere. Det kan nævnes, at Riksdataförbundet i Sverige anslår, at 45% af Sveriges edb-teknikere i 1981 var beskæftiget med vedligeholdelse af edb-systemer [4]. programkodning og test 1% andre 4% design 13% kravanalyse 82% Figur 5: Omkostninger ved forskellige "fejlkategorier" Store problemer ligger således i arbejdet med at fastlægge edb-systemernes ydre egenskaber og systemernes indpasning i de manuelle arbejdsgange. Disse sider bliver af større og større vigtighed i takt med udbredelsen af terminaler og datamatbaserede arbejdspladser. Mange af problemerne kan henføres til mangler i det grundlæggende arbejde med kravspecifikation. Fastfrysningen af det kommende systems egenskaber sker i praksis under arbejdet med kravspecifikation og foregår ofte på et spinkelt grundlag. Hverken brugere eller edb-planlæggere har på tidspunktet konkrete erfaringer med det nye system, fordi systemet kun eksisterer "på papiret" og brudstykkevis i forskellige menneskers hoveder. Brugerne har yderst vanskeligt ved at erkende deres behov på et rent teoretisk grundlag uden at have konkrete erfaringer med det nye system. Og edb-planlæggerne kan ikke hjælpe, fordi de ikke har tilstrækkelig indsigt i brugernes arbejde - og ligeledes har vanskeligt ved at overskue det specificerede system i alle dets facetter. 4.2 Prototyper til eksperimenter 7

8 Prototyper kan anvendes til at foretage afprøvninger af påtænkte systemegenskaber i virkelige arbejdssituationer. I dette tilfælde lægges vægt på at undersøge egnetheden af en foreslået løsning, inden der investeres i den endelige og ofte meget omfattende implementering af det færdige system. For en sådan afprøvning kræves en ret fuldstændig edb-model med så tilpas mange lighedspunkter med det ønskede edb-system, at modellen kan afprøves i virkelige omgivelser i samarbejde med brugerne og på basis af virkelige data. Her bliver således tale om ganske realistiske afprøvninger af det edb-baserede system Visioner om nyt system Edb-modeller Edb-systemer i drift tid Figur 6: Prototyper til eksperimenter med forskellige edb-modeller Eksperimenter med prototyper i denne form sigter primært på at undersøge og videreudvikle grænsefladerne mellem brugernes arbejde og det kommende edb-system. Selvom prototyperne skal være tilstrækkeligt udviklet til at kunne afprøves i praksis, udelades oftest en række faciliteter, som vil indgå i et færdigt system, f.eks. sikkerhedskontroller og faciliteter, som ikke bruges i det daglige. Ofte er prototyperne ineffektive i den forstand, at de beslaglægger mere edb-kapacitet end et fuldt udviklet system med sigte på ordinær drift. De ydre egenskaber for prototypen er i denne sammenhæng vigtigere end effektivitet og indre opbygning. 4.3 Prototyper til versionsudvikling Prototyper kan anvendes som foreløbige versioner af det færdige system. Ved tilrettelæggelsen af systemudviklingsforløbet planlægges at udvikle og afprøve at antal versioner af det påtænkte system. Når en version findes tilfredsstillende ud fra relevante vurderingskriterier, overgår denne version til at være det færdige system. Her lægges vægt på en gradvis tilpasning af prototypen til de delvist uforudsigelige krav til systemet - krav, som af den ene eller anden årsag ikke kan fastlægges pålideligt på et tidligt trin af udviklingsforløbet og uden konkret afprøvning i det virkelige produktionsmiljø. Forløbet er grafisk illustreret i figur 7. Visioner om nyt system Edb-modeller Edb-systemer i drift tid Figur 7: Prototyper til udvikling af versioner af edb-systemet 8

9 Vi ser, at denne form for anvendelse af prototyper mest vidtgående fastholder en eksperimentel tilgang til systemudviklingen. Formen vil derfor være særlig egnet, hvor man virkelig står over for en kompleks udviklingsopgave. Først efter konkret afprøvning og evaluering af en version af det påtænkte edb-system i et virkeligt produktionsmiljø og accept heraf blandt de kompetente beslutningstagere anses udviklingsprocessen for at være foreløbigt afsluttet 5 Grundlæggende antagelser bag prototypebaseret systemudvikling Ved en prototypebaseret systemudvikling til udvikling af interaktive informationssystemer er der særlig opmærksomhed på betydningen af, at - de organisatoriske omgivelser for det interaktive informationssystem vil ændres under udviklingsprocessen, således at vigtige, nye krav til det færdige system erkendes og formuleres under forløbet. - det interaktive informationssystem i sig selv indebærer kvalitative nye arbejdsprocesser, hvorved indførelse af det færdige system vil omforme arbejdsbetingelserne og medføre, at nye og delvis uforudsigelige krav opstår. For at klare sådanne vanskeligheder er det ikke tilstrækkeligt at benytte en strategi for anvendelse af prototyper, som primært er indrettet på at håndtere kommunikationsproblemer i systemudviklingsprocessen, men ellers anerkender de forudsætninger, som specifikationsmetoder til systemudvikling baseres på. Antagelser som i mere eller mindre ren form ligger til grund for specifikationsmetoder kan opsummeres i følgende punkter: - Visionen om det ønskede system er entydig og kan beskrives præcist i en specifikation, således at der ikke opstår misforståelser. - Alle betydende konsekvenser af at indføre edb-systemet i organisationen kan forudsiges. - Organisationen ændrer sig ikke under konstruktionen. I stedet er det nødvendigt med et perspektiv, hvor systemudviklingsprocessen opfattes som en problemløsnings- og læreproces, der kun i begrænset omfang er styrbar og forudsigelig. Udviklingen af edb-systemet tilrettelægges som et cyklisk forløb, hvor prototyper eller versioner af det ønskede edb-system afprøves og modificeres, indtil et tilfredsstillende resultat er opnået. En sådan synsmåde på systemudviklingen er baseret på følgende antagelser: - Visionen om det ønskede edb-system er flertydig og upræcis og kan ikke beskrives fuldstændigt i en specifikation. Specifikationer misforstås ofte. - Det er umuligt at forudsige alle betydende konsekvenser af edb-systemets indførelse i organisationen. - Organisationen udvikler sig hele tiden. - Konstruktionsprocessen er en problemløsnings- og læreproces (en erkendelsesproces). Prototypebaseret systemudvikling nedbryder altid den liniære følge af udviklingstrin, som vi kender dem fra forskellige specifikations- og faseorienterede systemudviklingsmodeller. I stedet overgår udviklingstrinene til en følge af cykliske udviklingsforløb. Afhængig af i hvilken grad denne nedbrydning foregår, kan skelnes mellem følgende former for prototypeudvikling: Skridtvis systemopbygning. Den grundliggende ide bag denne form er, at komplekse problemer angribes bedst via en gradvis opbygning af evnen til at løse problemerne i deres fulde omfang. F.eks. tages i en aktuel databehandlingsproces udgangspunkt i de kendte begreber og løsningsteknikker. I en skridtvis proces erstattes efterhånden flere og flere komponenter i databehandlingsprocessen med datamatstøttede komponenter, indtil man ikke ønsker at gå 9

10 videre i automatiseringen. I en langsigtet udviklingsstrategi udformes de tekniske sider af databehandlingsprocessen ved en gradvis udvidelse af problemløsnings- og læreprocessen. De datamatstøttede delløsninger skal omhyggeligt indpasses i de manuelle og automatiserede arbejdsopgaver, som den samlede databehandlingsprocessen består af. Kun herved kan en gradvis udvidelse af løsningen realiseres. En sådan gradvis opbyggende systemudvikling er på sin vis i nogenlunde overensstemmelse med en faseorienteret systemudviklingsmodel i den forstand, at fremgangsmåden primært påvirker implementeringsfasen og vedligeholdelsesfasen. F.eks. er vedligeholdelsen og videreudviklingen af de store offentlige edb-systemer, bl.a. skattesystemerne samt løn- og regnskabssystemerne, rimelig godt karakteriseret som en skridtvis systemopbygning. I traditionelle systemudviklingsforløb sker den skridtvise opbygning imidlertid snarere på trods af metodeforlæg og planlægningen. Det opleves af brugere og systemudviklere som stærkt generende forsinkelser, budgetoverskridelser eller reducerede forventninger til systemets funktionalitet. Ofte erkendes de grundlæggende vanskeligheder i et systemudviklingsprojekt alt for sent i de traditionelle systemudviklingsforløb. Ved en prototypeorienteret tilgang fremskyndes læreprocesser ved flere og hurtigere iterationer, og der opnås en mere realistisk fornemmelse af tidskrav for udvikling af et færdigt system. Som udviklingsstrategi kræver fremgangsmåden en vedvarende opmærksomhed på helhedsdesign og samordning af de mangeartede og delvist konflikterende udviklingsønsker. For at bevare flest mulige frihedsgrader og dermed størst omstillingsevne ved indretningen af de administrative procedurer, er det af stor betydning at fastholde enkle og veldefinerede grænseflader mellem delsystemerne samtidig med, at der opretholdes et overordnet overblik over systemernes informationsindhold. Evolutionær systemudvikling. (Af evolution, hvilket betyder udvikling som en rolig og jævn omformning mod højere trin.) Her opfattes systemudviklingsprocessen som helhed som en sekvens af cykliske forløb: design/redesign, implementering/reimplementering, vurdering/revurdering. Ved denne fremgangsmåde overføres alle faser til en følge af cykliske udviklingsforløb. I stedet for at indkredse og fastlægge alle relevante krav på forhånd opbygges systemet med det sigte at kunne tilpasses senere fremkomne ændringsbehov. Denne tilgang søger at tilpasse systemudviklingsprocessen til de realiteter, som følger af, at vi grundlæggende lever i en uforudsigelig og foranderlig verden. For at fungere må både systemudviklere og brugere være villige til at forholde sig åbent overfor forandringer og indstille sig på en stor og vanskeligt afgrænselig kommunikationsindsats. I særlig grad må systemudviklere acceptere nødvendigheden af hyppige revisioner af deres egne programmer, hvilket kræver en disciplineret arbejdsstil. Brugere må være villige til at acceptere gentagne ændringer i systemerne, som påvirker deres arbejde og kræver ny indlæring og uddannelse. Spørgsmålet om antallet af cykliske forløb kan kun behandles meningsfuldt ud fra en konkret situation. F.eks. kan der være tale om par forløb med prototyper til undersøgelse af kravene til systemet under analysearbejdet, én eller flere prototyper til eksperimenter under designarbejdet afsluttende med en "gradvis opbyggende systemudvikling" under systemets implementering. Ved evolutionær systemudvikling er der ingen vedligeholdelsesfase som sådan. Den erstattes af forsatte systemudviklingscykler baseret på eksisterende versioner i drift og indpasning af nye krav med henblik på udvikling af nye versioner. 6 Værktøjer og teknikker til prototypeudvikling Som det er fremgået ovenfor afhænger systemudvikling via prototyper ikke fuldstændig af nye værktøjer og teknikker, men kan foregå ved behændig anvendelse af kendte værktøjer og inden for rammerne af forskellige systemudviklingsmetoder. Måske er de mest relevante teknikker i forbindelse med prototypeudvikling: - datamodellering og design af database - modulær design, - dialog-design, og - simulation. 10

11 Datamodellering og design af databasen danner grundlaget for, hvilke funktioner, der senere kan indbygges i informationssystemet, og hvor let det er senere at indføre ændringer heri. I datamodellen fastlægges, hvilke begreber, genstande og hændelser, der skal afbildes i informationssystemet. Normalt er det nyttigt at afbilde egenskaberne på en måde, som ligger tæt på det, der kendes fra den del af virkeligheden, som man ønsker at beskæftige sig med. Datamodellen bliver herved mere stabil over for ændringer, som typisk kan indbygges i form af nye funktioner på basis af eksisterende egenskaber, udvidelser i tabeller m.v.. Ændringer bygger ofte naturligt på velkendte begreber, genstande og hændelser. I tilknytning til prototypeudvikling kan der her være særlig grund til at fremhæve, at vi får mulighed for at eksperimentere med forskellige datamodeller. Hos systemudviklerne (edb-teknikere og brugere) opbygges gradvist en klar forståelse for hensigtsmæssige valg af grundbegreber i datamodellen, begrebernes definition, egenskaber og sammenhænge. Under arbejdet hermed er et godt databasestyresystem af stor betydning, bl.a. for hurtigt at kunne foretage modifikationer i prototypens database. Modulær design er - som i al systemudvikling - af stor betydning i strategier for prototypeudvikling, specielt når der sigtes på, at prototypen skal indgå i det færdige edb-system. Disse strategier omfatter simulation af grænseflader mellem menneske og maskine, programmering af skeletmodeller og gradvis voksende systemudvikling. I alle disse tilfælde er modularitet en stor hjælp til at muliggøre en gradvis udskiftning af de enkelte elementer i prototypen med fuldt udviklede komponenter, der kan indgå i det færdige system. Grænseflader kan normalt ikke forventes at forblive uændrede under en sådan udskiftning, bl.a. fordi ændrede krav kan medføre behov for grundlæggende omformning også af hele systemets struktur. Eksplicit kommunikation mellem moduler via navngivne snitflader gør omformninger i systemstrukturen mere pålidelig. Dialog-design tjener til at gøre brugergrænseflader mere fleksible og gennemskuelige for systemets brugere. Evaluering af brugergrænseflader kræver mulighed for at navngive, diskutere og ændre dialogernes opbygning på forskelligt detailniveau. Det kræver opmærksomhed på helhedsstrukturen i dialogernes opbygning, på valget af systemkommandoer, lay-out af skærmbilleder, behandling af fejlsituationer m.v. samt på brugernes muligheder for smidig tilrettelæggelse af arbejdet med systemet. Det må tilstræbes at adskille aspekter vedrørende dialogudformningen fra aspekter tilknyttet den applikationsspecifikke databehandling. Herved gøres det enklere at ændre på ét område og undgå overflødige og vanskeligt gennemskuelige følgevirkninger på det andet område. En sådan uafhængighed mellem applikationsdelen og dialogdelen - i det omfang den er mulig - kan kraftigt øge fleksibiliteten ved design af interaktive informationssystemer. Simulation er et begreb som anvendes i mange sammenhænge og med forskellige betydninger. Ethvert program er normalt en simulation af en aktivitet, som foregår i den virkelige verden. Det bør tilstræbes at modellere aktiviteter på nogenlunde genkendelig vis fremfor at opnå en ønsket funktion ved kunstgreb af forskellig art. Herved opnås, at begrebsdannelser i edb-modellen står i en gennemskuelig forbindelse med begrebsdannelser i den virkelige verden. Det har stor betydning ved modifikationer af prototypen og i den senere vedligeholdelse, idet begrebsdannelserne i den virkelige verden har længere levetid end de funktioner, som ønskes udført. Ved at basere sit system på velkendte begrebsdannelser fra den virkelige verden opnås, at grundelementer til implementering af nye eller ændrede funktioner ofte vil findes i systemet. Som teknik i forbindelse med prototypeudvikling kan simulation tjene til at inddrage sådanne forhold ved det ønskede edb-system, som på den ene side ikke er udvalgt til direkte indbygning i selve prototypen, men som på den anden side heller ikke kan udelades helt ved en realistisk afprøvning. Et eksempel på simulering af denne art kan være opbygning af en lille og simpel datastruktur placeret i datamaskinens interne lager til produktion af et mindre antal testtilfælde i én eller anden applikation, frem for opbygning af en realistisk filstruktur, som i det ønskede system må være baseret på grundige analyser af lagerkapacitet og søgningsmønster. Som et andet eksempel kan nævnes simulation af svartid ved hjælp af simple løkker. Der kan også være tale om simulation af særlige hændelser eller specielle applikationer ved manuelle midler - papirmodeller, lysbilleder og andet - for herved at undersøge prototypen inden for bredere rammer af funktioner og hændelser, som det (endnu) ikke har været ønskeligt at indbygge i selve prototypen. Brugt som teknik er simulation klart afhængig af at foregå inden for rammerne af et modulært design. Kun herved opnås, at simulationen kan udføres lokalt uden at påvirke systemets struktur som helhed. 11

12 Værktøjer til prototypeudvikling kræver principielt ikke andet end behændig udnyttelse af velkendte hjælpemidler, som over en årrække er udviklet med henblik på at effektivisere systemudviklingsprocessen. Siden systemudvikling via prototyper er blevet populært, er sådanne værktøjer mere eller mindre berettiget blevet markedsført under betegnelsen prototypeværktøjer, 4.generationssprog eller andre "lovende" etiketter. Værktøjerne omfatter typisk et eller flere højniveausprog, et databasestyresystem, et forespørgselssprog, en skærmbilledgenerator og en rapportgenerator. De enkelte værktøjer i "redskabskassen" er således velkendte. Det kvalitativt nye kommer frem i det omfang, at værktøjerne kompletterer hinanden og udnyttes godt i sammenhæng. Man kunne kalde det et spørgsmål om integration bl.a. i den forstand, at kommandosproget for de forskellige værktøjer er ensartet opbygget, at data og definitioner af data ikke skal gentages i forbindelse med forskellige applikationer og lignende. Integration af værktøjerne fremmer således overskueligheden i systemarbejdet, samtidig med at dobbeltarbejde og risiko for inkonsistens i datagrundlaget reduceres. En interessant mulighed for datamatstøtte i forbindelse med prototypeudvikling synes at kunne være programmeringsomgivelser, hvor problemløsnings- og læreprocesser via eksperimenter understøttes med henblik på gradvis opbygning af egnede edb-løsninger. Sådanne systemer er endnu blot visioner i forsknings- og udviklingsafdelinger rundt om i verden - visioner, som står i markant modsætning til mange, eksisterende programmeringsomgivelser, som påtvinger en eller anden bestemt tilgang til systemudviklingsprocessen, f.eks. baseret på en top-down, deduktiv designmetodik. Som et mere realistisk alternativ på kort sigt kan benyttes et værktøjssæt til prototypeudvikling sammensat med sigte på mere begrænsede anvendelsesområder, f.eks. interaktive informationssystemer til administrative og planlægningsmæssige opgaver. Et sådant værktøjssæt skal bestå af en editor, et tekstbehandlingssystem, højniveausprog, et databasestyresystem, simuleringsfaciliteter, et system til håndtering af vinduer, skærmbilleder og grafik samt matematiske og statistiske standardprogrammer. For at kunne genanvende programmel udviklet af andre skal der findes et programbibliotek, ligesom der skal være værktøjer til integration af eksisterende programmel med programmel fremkommet via prototypeudviklingen. Alle værktøjerne skal være integrerede, for at arbejdet kan gøres effektivt. Værktøjerne, som anvendes i forbindelse med opbygning af menneskemaskine dialoger, skal være interaktive, kraftige og lette af benytte, således at ændringer i dialogformen hurtigt kan modificeres under afprøvning og evaluering af prototypen. Referencer 1. Dette aspekt er nærmere behandlet i Erik Frøkjær, Styrings- og samarbejdsformer i prototypebaseret systemudvikling, november Er tidligt fremhævet af Peter Naur, se f.eks. Naur, Peter, Concise Survey of Computer Methods, Studentlitteratur, Lund, 1974, chapter 18.4, p Fremstillingen bygger i høj grad på følgende tre kilder: Bansler, Jørgen og Keld Bødker, Experimentelle teknikker i systemarbejdet, DIKU-rapport nr. 83/7 (Speciale), Datalogisk Institut, Københavns Universitet, Floyd, Christiane, A Systematic Look at Prototyping, pp. 1-18, in: Budde, R., Kuhlenkamp, and L. Mathiassen (eds.), Approaches to Prototyping, Springer-Verlag, N.Y., Bogen indeholder arbejdsdokumenter fra en tidlig konference om prototypebaseret systemudvikling, afholdt i Namur, oktober Mogensen, Klaus Viby, Afprøvning af systemudvikling med prototyper, DIKU-rapport (Speciale), Datalogisk Institut, Københavns Universitet, Statskontoret, Systemutveckling - verksamhet i förändring, Stockholm, Speeding Up Application Development, Edp Analyzer, Vol. 23, No. 4, April