Greta Hjertø 7.2.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Resymé: I denne leksjonen skal vi ta for oss systemutviklingsprosjektet og se nærmere på hva som er spesielt med det sammenlignet med andre prosjekter. Tema er: systemutviklingens utfordringer, en diskusjon om vha som styrer kundens behov, forankring av prosjektet i organisasjonen, prinsipper for gjennomføring av prosjektet og tilslutt ser vi næremere på ulike prosjektmodeller for systemutviklingsprosjektet. 1.1. Innledning I dette faget skal vi følge arbeidet i et systemutviklingsprosjekt gjennom disse fasene, se figuren: Problemstilling Design Forstudium Analyse Innføring og progr. Men først skal vi starte med å se nærmere på de utfordringene vi vil møte i et slikt prosjekt og hvilke rammebetingelser vi kommer til å jobbe under. Vi skal forsøke å forstå hva et systemutviklingsprosjekt egentlig er for noe og hva som skiller det fra andre typer prosjekter. I denne leksjonen skal vi behandle følgende tema: 1. Hva er systemutviklingsprosjektets utfordringer? - å omsette kundens behov til et system som bruker har nytte av gjennom hele prosjektets levetid. 2. Hva styrer kundens behov? - systemets levetid - kundens forskjellige roller bruker eller oppdragsgiver - systemets forskjellige roller støtte eller effektivisere arbeidsoppgavene. - lover og regler. 3. Hva betyr forankring av prosjektet? 4. Hvilke grunnleggende prinsipper har vi for gjennomføring av et slikt prosjekt? - prinsipper for organisering fordeling av arbeidet mellom ekspertene og brukerne
- prinsipper for styring om å kontrollere usikkerhet - prinsipper for kvalitetssikring om å forebygge og finne feil. 5. Hva er en prosjektmodell? - forskjellige prosjektmodeller - bruk av modellene - generelle prosjektfaser i modellene 1.2. Hva er systemutvikling og hvilke utfordringer har vi? Systemutvikling å omsette brukers behov til et system som bruker har nytte av gjennom hele systemets levetid Systemutvikling er et mangfoldig begrep. Skal vi si generelt hva det er, kan vi definere det som: Arbeidet med å fremstille det vil si spesifisere og utvikle et IT-system som skal møte et kundebehov. Begrepet systemutvikling brukes delvis synonymt med programvareutvikling, men oftest brukes det i betydningen: programvareutvikling og litt til. Det er som oftest slik at et ITsystem er mer enn programvare. Det er programvare pluss det grensenittet som gjør at programvaren fungerer. Med grensesnitt tenker vi vanligvis på utstyr og arbeidsrutiner og opplegg for brukerstøtte. Derfor blir systemutvikling oppgaven å utvikle programvaren, og i tillegg: programvarens grensesnitt mot omgivelsene. Men som sagt, systemutvikling er et mangfoldig begrep, brukt om svært ulike oppgaver. Det betyr at utfordringene kan variere voldsomt, fra det enkleste til det mest kompliserte. Grunnen er at det finnes så mange typer programvare (som tross alt er kjernen i IT-systemet). Det finnes mange måter å klassifisere de ulike typene programvare på. Denne inndelingen kan være grei: - Systemprogramvare brukt til å kontrollere fysisk utstyr - Programvarepakke kommersielt tilgjengelige standardprogrammer kjøpes over disk - Personlig programvare utviklet til personlig bruk. - Programvare og arbeidsrutiner, utstyr og opplegg for brukerstøtte som skal støtte arbeidsoppgavene i en bedrift vi kaller gjerne denne typen programvare et informasjonssystem. I dette faget skal vi konsentrere oss om den siste kategorien programvare et informasjonssystem for en bedrift. Det betyr at systemutvikling for oss er karakterisert ved: 1. Systemet utvikles i et systemutviklingsprosjekt. Dette er vanligvis en stor oppgave som krever innsats fra flere personer over lengre tid. 2. Systemet skal utvikles til å tilfredsstille behov som blir bestemt av en kunde. Kvaliteten av det nye systemet vil bli vurdert etter hvor godt det oppfyller disse behovene. Den viktigste oppgaven til systemet vil være å gi best mulig støtte til arbeidsoppgavene i kundens organisasjon. 3. Kunden betaler for gjennomføring av utviklingen. side 2 av 33
4. Systemutvikling gjennomføres av systemutviklere, men i tett samarbeid med kunden. Vi kommer tilbake til fordeling av oppgaver mellom systemutviklerne og kunden senere. Selv om vi først og fremst er opptatte av informasjonssystemet, så er mange av de prinsippene vi diskuterer like gyldige for de andre kategoriene programvare. Vi har imidlertid noen vesentlige forskjeller: for systemprogramvare er for eksempel kravene klart definert av det fysiske utstyret som skal kontrolleres, for programvarepakker har vi ikke en spesifikk kunde men en mulig kundegruppe å forholde oss til, for personlig programvare er det vi selv som har behovet og systemet er ofte lite og enkelt, osv. Slike forskjeller betyr mye når vi for eksempel skal definere og beskrive brukerkravene, men de betyr lite når vi først er i gang med programmeringen. 1.3. Hva er det som er så vanskelig med systemutvikling? Med det utgangspunktet vi har sagt over, kan vi si at dette er prosjektets hovedoppgaver: Å avdekke, forstå og beskrive kundens subjektive og objektive behov og krav til systemet Å omsette kravene til et system som oppfyller behovene Å sørge for best mulig samspill mellom systemet, arbeidsrutiner og brukere i hele systemets levetid I disse hovedoppgavene ligger det store utfordringer: 1.3.1. Å avdekke, forstå og beskrive kundens behov og krav til systemet I denne delen av arbeidet skal vi bestemme hvilke egenskaper systemet skal ha. For å kunne gjøre det, må vi ha en god dialog med den kunden som vi lager systemet for, slik at vi klarer å få frem hvilke behov denne kunden har, og hvilke krav han stiller til det nye systemet. Dette er ikke nødvendigvis enkelt. Kunden vet ikke alltid hva han vil ha. Han vet ikke hvilke spørsmål som skal besvares, og han klarer heller ikke å forestille seg hvordan et fremtidig system må være. Kanskje han sier at vi som er IT-eksperter sikkert vet best. Dette er et håpløst utgangspunkt. Selv om vi er ITeksperter, kan vi umulig vite hva akkurat denne kunden har behov for, hvis han ikke forteller oss det. Vi må derfor få til en dialog med kunden. I neste omgang nøyer han seg kanskje med å si at han vil ha et nytt system som fungerer akkurat som det gamle manuelle gjør. Da er vi noe bedre stillet, fordi vi kan studere virkemåten til det gamle systemet, men heller ikke dette er et utsagn vi bør akseptere uten videre. Mange systemer har blitt laget med dette utgangspunktet, og ofte med dårlig resultat Et IT-system kan gjøre det mulig å arbeide på en helt annen og mer effektiv måte. Et nytt system som bare kopierer den gamle måten å jobbe på, snyter kanskje kunden for muligheten til å gjøre ting annerledes og bedre, og ofte billigere. Budskapet er at dialogen med kunden er helt avgjørende for et godt resultat, og at vi som er eksperter på systemutvikling må hjelpe kunden til å se hvilke muligheter han har.. Skal vi lykkes, må vi også klare å oversette subjektive, uklare og av og til ubevisste behov til objektive krav. Og kravene må deretter beskrives presist og detaljert på en slik måte at de kan verifiseres. Dette krever kompetanse og ferdigheter som kommer i tillegg til vår ITkompetanse. Vi må forstå kundens virksomhet og lære å kjenne kundens organisasjon. Vi må side 3 av 33
kunne lytte, vi må formidle, vi må være selgere og vi må ha andre så kalte myke, menneskeorienterte ferdigheter. I tillegg må vi være både analytiske og kreative på en gang. Tilslutt er det slik at systemutvikling er underlagt lover og regler. Dette kan være myndighetskrav, som vern av personopplysninger og arbeidsmiljøloven, eller det kan være skrevne og uskrevne regler i bedriften, som krav til fremgangsmåte, krav til representasjon i prosjektet og krav til konsekvensanalyser. Disse reglene må vi ta hensyn til. 1.3.2. Å omsette kravene til et system som tilfredsstiller kundens behov og krav I denne fasen skal systemutviklerne, ved hjelp av godt ingeniørarbeid, bygge et system som oppfyller spesifikasjonene. På en måte er dette den letteste delen av jobben, nå gjelder det bare å følge arbeidstegningene, og sørge for å gjøre færrest mulig feil. På den annen side er systemutvikling hardt arbeid. Med store krav til dyktighet i fagdisiplinene. Det er et arbeid som i den mest hektiske utviklingsperioden fordeles på mange, som hver for seg skal lage biter som passer sammen i en helhet. Arbeidet blir også mer komplisert av at vi må ta hensyn til de andre systemene som bedriften har og til infrastrukturen i bedriften. Det begrenser hvilke løsninger vi kan velge, og det betyr at vi må følge de standardene som bedriften har. Videre er teknologien kompleks når det gjelder systemutvikling, og enda verre, den utvikler seg hele tiden. I de fleste prosjekter kan vi oppleve å måtte ta i bruk ny og uprøvd teknologi. Mange synes dette er spennende, men det er likevel en stor utfordring å beherske uprøvd teknologi godt nok til, for det første, å kunne forutse hvor stor og kompleks oppgaven er, og for det andre å kunne benytte teknologien godt nok til å lage gode løsninger. 1.3.3. Å tilrettelegge for et best mulig samspill mellom bruker og system i hele systemets levetid Vi som utvikler datasystemer, må huske at selv det mest fantastiske IT-systemet ikke har kvalitet med mindre det fungerer for brukerne i brukernes arbeidssituasjon. For å oppleve kvalitet, må brukerne få den støtte og opplæring de trenger i tillegg til at vi gir dem et system med de riktige egenskapene, bygd med det gode ingeniørarbeidet. Og organisasjonen rundt systemet må vi heller ikke glemme. Hvis brukerne trenger hjelp til å bruke systemet, må de få det, og hvis systemet har feil og mangler, må disse rettes. Denne delen av arbeidet er krevende, ikke minst fordi alt som ikke har direkte med systemet å gjøre, ofte blir neglisjert eller avglemt helt til problemene plutselig står der. Prosjektet konsentrerer seg om å utvikle et best mulig system og glemmer at det også må skje noe i brukerorganisasjonen, for eksempel endringer i arbeidsrutiner, endringer i ansvarsforhold, opplæring av brukere, anskaffelse av utstyr og så videre. Den kan også bli krevende fordi systemet ble laget uten at kravene til driftssikkerhet, vedlikeholdbarhet og utvidbarhet blir viet nok oppmerksomhet. Dette er egenskaper ved programvaren som ikke nødvendigvis vises så godt den dagen vi leverer systemet men som vil bety svært mye for kunden etter at systemet er tatt i bruk. 1.4. Lykkes vi med systemutviklingsprosjektene? Til alles frustrasjon er det ikke uvanlig at systemet, når det settes i drift, ikke oppfyller brukernes behov side 4 av 33
Vi er i dagens samfunn omgitt av programvare. Vi kan ikke gå inn i en bank, en forretning, et legekontor uten å møte datasystemer. Vi får lønn fra dem, vi bruker dem hjemme ved PC-en, vi kommer i kontakt med dem når vi setter oss inn i bilen eller mobiltelefonen. Store deler av vår infrastruktur ville bryte sammen uten programvare. Det er lett å forstå at kvaliteten på denne programvaren betyr enormt mye for samfunnet. Men har programvaren kvalitet? Lykkes vi når vi utvikler IT-systemer? Svaret er dessverre ikke et umiddelbart ja. Det er nok slik at vi har fått et nytt IT-system, for mange betyr det samme som: nå blir det problemer. Og sørgelig ofte har de rett. Statistikken er faktisk så dårlig at noen eksperter på systemutvikling hevder at det tradisjonelle systemutviklingsprosjektet (slik vi til en viss grad beskriver det i dette faget), faktisk ikke kan lykkes. Begrunnelsen deres er det tradisjonelle systemutviklingsprosjektet er dømt til å mislykkes fordi de skyter på bevegelige mål. Som et resultat, blir enten prosjektet aldri helt ferdig, eller det leverer et resultat som ingen har bruk for lenger. Begrunnelsen er at et tradisjonelt systemutviklingsprosjekt som nevnt er både krevende og langvarig. Først går en vesentlig del av arbeidet i prosjektet ut på å avdekke brukerkrav og spesifisere den løsningen som skal lages. Dette tar lang tid og krever mye ressurser. Når alle krav er spesifisert og grundig dokumentert, overlates spesifikasjonene til en stor gruppe programmerere som setter i gang og lager systemet. Dette tar enda lenger tid og enda mer ressurser. Det er ikke uvanlig at hele dette løpet tar et flere år og koster mange millioner. Til alles frustrasjon er det da slett ikke uvanlig at systemet, når det endelig settes i drift, ikke gir brukerne det de har behov for. Grunnen kan selvfølgelig være at vi har vært lite flinke til å avdekke og beskrive brukerbehov. Men den vesentlige årsaken, hevdes det, er rett og slett at det har gått for lang tid. De spesifikasjonene vi laget for to år siden, var helt greie de, men i mellomtiden har verden forandret seg. Teknologien har utviklet seg, måten forretningen drives på har endret seg, folkene som bestilte systemet har fått nye jobber. Bare det faktum at vi setter i gang et prosjekt er nok til å påvirke omgivelsene slik at de sannhetene som gjaldt da spesifikasjonene ble laget ikke er gyldige lenger når systemet endelig er ferdig. Dette er jo deprimerende tanker! Kanskje vi skulle finne oss en annen jobb? Poenget er at vi systemutviklere må vite om denne problemstillingen og ha den i tankene når vi planlegger prosjektene. Når vi senere i leksjonen ser nærmere på noen standard fremgangsmåter for systemutvikling, (prosjektmodeller) vil vi se at noen av dem legger vekt på å håndtere akkurat denne problemstillingen. Det gjør de ved å legge opp til å levere systemet bit for bit. På den måten kan kursen justeres underveis, etter hvert som omgivelsene endrer seg. Mer om dette senere. 1.5. Hva styrer kundens behov? I forrige kapittel sa vi at en av hovedoppgavene i systemutvikling er å avdekke og beskrive kundens behov og krav. Vi sa videre at dette er en krevende oppgave. I tillegg er det en meget viktig oppgave det er jo her vi legger hele grunnlaget for systemet. Vi skal derfor i dette kapitlet ser litt nærmere på noen utfordringer i denne fasen av arbeidet. Vi har valgt disse: side 5 av 33
Systemet skal oppfylle behov og krav i hele systemets levetid Kunden kan ha flere roller og disse kan ha behov som er i konflikt med hverandre Rollen til den nye programvaren kan være uklar, skal den best mulig støtte dagens arbeidsrutiner eller er det forventninger til effektivisering av organisasjonen Systemutvikling er underlagt lover og regler 1.5.1. Systemet skal oppfylle behov i hele systemets levetid Når vi sier at systemet skal oppfylle brukerens behov, er det viktig å være oppmerksom på at vi snakker om systemet i hele systemets levetid. Systemutvikleren vil naturlig være mest opptatt av å komme i mål med systemutviklingsprosjektet og kunne levere og demonstrere et system som fungerer slik det skal, til avtalt tid. Den dagen systemet er installert føler systemutvikleren at jobben er gjort. For brukeren er imidlertid den dagen starten på et samliv med systemet som kan vare i 5 10 år, kanskje ennå lengre. Nedenfor er vist et typisk livsløp for et system i en bedrift: Videreutviklingsprosjekter Utviklings prosjekt Bruk og Forvaltning Utviklings prosjekt 1 år 2 år 3 år 4 år 5 år Tidslinje Figuren viser et (2-årig) utviklingsprosjekt for et system, fulgt av en 3 til 5 kanskje 10 års periode med daglig bruk og løpende forvaltning. Parallelt med forvaltning har vi tegnet inn flere ½-årige prosjekter for periodisk videreutvikling av systemet, hvorpå det startes et (2- årig)prosjekt for å erstatte det gamle systemet med et nytt. Når brukeren vurderer om systemet oppfyller behovet, vil han legge vekt på hvordan systemet oppleves i bruk, dag etter dag, hver dag. I tillegg til systemets ytre egenskaper som skjermbilder, enkelhet i bruk osv. kommer plutselig andre forhold inn. Dette er viktige spørsmål for brukerne: - Hvor stabilt er systemet i drift, hvordan påvirkes det av infrastruktur og andre systemer? - Hvor ofte oppstår feil i systemet? - Hvor lett er det å få systemet opp å stå etter systembrudd? - Hvor lett er det å rekonstruere data? - Hvor lang tid tar det å rette feil? - Hvilket forvaltningsapparat er etablert? - Hvilke avtaler har bedriften med leverandører av programvarekomponentene? - Er leverandørene til å stole på? side 6 av 33
- Hvor lett er det å utvide systemet med ny funksjonalitet? - Hvor lett er det å endre virkemåten til systemet? - Hvor lett er det å flytte det til nye plattformer? - Osv. Vi skal som sagt følge arbeidet i et systemutviklingsprosjekt gjennom forskjellige prosjektfaser. Kanskje vil mange synes at arbeidet av og til er unødig komplisert og byråkratisk, for eksempel med strenge krav til at vi skal lage detaljert dokumentasjon før vi får lov til å starte den egentlige jobben å programmere. En del av begrunnelsen for dette finner vi i lista over. Det er ikke nok å få opp noe raskt som ser bra ut. Vi må være sikre på at dette noe tar hensyn til den fremtidige bruken, og til vedlikehold og videreutvikling. 1.5.2. Kundens forskjellige roller - bruker og oppdragsgiver Det er ofte motsetning mellom brukers interesser og oppdragsgivers interesser Det kan være vanskelig å få riktig brukerrepresentant med i prosjektet Ofte opplever vi at kunden slett ikke er én person med ett behov. Tvert om kan han være representert ved flere personer i flere roller, og disse personene og rollene kan ha behov som er i konflikt med hverandre. I systemutviklingsprosjekter må vi skille mellom: - bruker - brukerrepresentanter - oppdragsgiver. Disse rollene er alle representanter for kunden, men vær oppmerksom på at de kan ha forskjellige interesser. Brukeren skal bruke det nye systemet i sine daglige arbeidsoppgaver. Brukeren vil gjennom erfaring kjenne dagens situasjon, hvordan arbeidsrutinene fungerer, hvilke problemer man har med dagens system, hvilke muligheter man har som ikke er utnyttet osv. Brukeren vil bli direkte berørt av arbeidet i prosjektet, og må leve med det nye systemet (og eventuelle endringer i arbeidsrutinene) etter at prosjektet er gjennomført. Ofte kompliseres dette ved at vi har flere brukere som kan ha forskjellige behov og forskjellige syn på hva som er en god løsning. Dette løses ved å utpeke en brukerrepresentant som har ansvar for å skifte vær og vind mellom forskjellige syn og finne en løsning som kan aksepteres av alle. Systemutvikleren vil da ha direkte kontakt med brukerrepresentanten(e). Oppdragsgiveren betaler for prosjektet. Oppdragsgiveren representerer ledelsen i bedriften. Oppdragsgiveren vil være opptatt av økonomien i prosjektet, og av å få et best mulig system for minst mulig penger. Oppdragsgiveren vil også være opptatt av de mulighetene det nye systemet kan gi til å rasjonalisere arbeidsmåten i bedriften eller spare penger på andre måter. Ofte er det motsetning mellom brukerens interesser og oppdragsgiverens interesser. For eksempel kan oppdragsgiverens ønske om å effektivisere og rasjonalisere bety en ny side 7 av 33
arbeidssituasjon for brukeren som brukeren ikke ønsker. Systemutvikleren får da den ikke helt enkle oppgaven å ivareta begges interesser. Dessverre er det også vanlig at den (eller de) som velges til brukerrepresentant(er) ikke er særlig representative. Mange prosjekter opplever problemer med å få tilgang til de rette personene i brukerorganisasjonen. Grunnen er at systemutvikling for brukerne kommer i tillegg til daglige arbeidsoppgaver. Da er det fristende å velge en brukerrepresentant som det er lett å unnvære i det daglige. Dette er ikke nødvendigvis den personen som best ivaretar brukernes interesser. Dette må systemutvikler være klar over og stille krav til oppdragsgiveren. 1.5.3. Programvarens rolle støtte eller effektivisere De fleste bedrifter har en rekke programvaresystemer, etablert i bedriften gjennom flere år. Det kan være typisk administrative systemer til støtte for arbeidsoppgaver som - bestilling av varer - fakturabehandling - materialforvaltning - lønnsutbetaling - behandling av reiseregninger Det kan være typiske fagspesialist systemer til støtte for oppgaver som - tolking av brønndata fra Nordsjøen - produksjonsstyring for raffineriene - produktdesign Eller det kan være typiske ledelsesinformasjonssystemer (LIS) til støtte for lederoppgaver som - oppfølging av resultatet - utforming av strategien Til en hver tid vil også bedriften ha arbeid i gang med å erstatte disse systemene, eller med å utvikle nye systemer på andre områder. Men hvorfor all denne systemutviklingen? Vanlige årsaker er: 1. Systemene kan være for dårlige. IT teknologien endrer seg meget raskt. Mange av systemene vil derfor være basert på gammel teknologi og oppleves som tungvinte å bruke sammenlignet med de moderne systemene, eller de blir etter hvert krevende å vedlikeholde. 2. Det kan ha skjedd endringer i arbeidsoppgavene som systemene skal støtte. Organisasjoner endrer seg også raskt. Det som var en god måte å jobbe på i går, kan være gammeldags i dag. Dermed er kanskje ikke IT-systemene hensiktsmessige lenger. Noen vil kanskje sementere gammeldagse måter å gjøre jobben på, andre har funksjoner som ikke kan brukes fordi arbeidsoppgavene har endret seg. 3. Ny teknologi kan gi nye muligheter. Det kommer også stadig nye typer systemer på markedet som støtter nye arbeidsmåter. Et eksempel er systemer som integrerer alle administrative funksjoner rundt en felles database og dermed gir mulighet til å fjerne gamle skillelinjer mellom avdelingene i bedriften. Et annet eksempel er systemer som side 8 av 33
støtter resultatoppfølging og beslutningsprosesser i bedriften ved å integrere og sammenstille data på tvers av avdelingene. Avhengig av utgangspunktet for prosjektet, kan oppdragsgiveren ha forskjellige forventninger til programvaren. I enkelte tilfeller er målet å erstatte et system som fungerer for dårlig, i andre kan det være å utnytte IT-teknologien til å gjøre store endringer i bedriften. Når vi skal bestemme kundens behov, har vi derfor et svært viktig spørsmål som vi må få svar på hvilken rolle skal programvaren ha i bedriften? Skal den støtte dagens arbeidsoppgaver eller skal den bidra til å effektivisere bedriften? Det er svært viktig at vi tidlig i prosjektet diskuterer dette med oppdragsgiveren. Programvare som best mulig støtter oppgavene til firmaets avdelinger? Programvare som best mulig effektiviserer firmaet, f.eks. ved å fjerne oppgaver og avdelinger? For å illustrere forskjellen på disse utgangspunktene, skal vi ta et enkelt eksempel. Gitt at avdelingen for reiseregnskap i en bedrift trenger et nytt datasystem. Da har vi følgende valg: - Vi kan utvikle programvare som best mulig støtter dagens rutiner for registrering og manuell kontroll av reiseregninger. Konsekvensen er at organisasjonen og arbeidsrutinene er som før, men de ansatte får bedre støtte og kan jobbe både raskere og riktigere. - Vi kan utvikle programvare som effektiviserer rutinene. Da gjør vi samtidig om på både organisasjon og arbeidsrutiner. En vanlig måte å effektivisere på, er å gjøre all reisebestilling og all behandling av reiseregninger elektronisk og styrt av de ansatte. I tillegg fjernes sluttkontrollen av regningene og erstattes av stikkprøver. Konsekvensen av dette er at reiseregnskap mister svært mange av sine sentrale oppgaver. Begge utgangspunkt kan gi et riktig system, avhengig av situasjonen. Hvis vi tenker på kundens ulike roller som vi har snakket om før, er det kanskje slik at et system som støtter dagens praksis er riktigst sett fra brukernes side, mens oppdragsgiver kanskje vil være mest tilfreds med et system som gjør det mulig med radikale endringer og effektivisering. I eksemplet over ble mange ansatte i reiseregnskap overflødige da kontrollen av reiseregningene for mange tusen ansatte falt vekk. Bedriften oppnådde store besparelser, men de ansatte mistet oppgavene sine. Det har i de senere år blitt stadig større oppmerksomhet på at vi ikke kan få virkelig radikale forbedringer og effektivisering i en bedrift ved å gi en avdeling et nytt og bedre datasystem, og dermed få den til å gjøre sine oppgaver litt raskere. De virkelige radikale forbedringene får vi først hvis vi er villige til å analysere og forbedre arbeidsprosessene i bedriftene. Og da gjerne på tvers av de tradisjonelle avdelingene. Gjennom en slik analyse viser det seg nesten alltid at vi er i stand til å fjerne arbeidsoppgaver eller avdelinger, eller å få avdelinger til å samarbeide på en annen måte. Vi er også på jakt etter å fjerne unødige kontroller av andres arbeid eller annet overflødig arbeid. Som et resultat av en slik gjennomgang kan det vise seg at bedriften trenger et nytt datasystem som støtter helt andre arbeidsmåter enn de gamle. Hvilken strategi skal da bedriften velge? Som systemutviklere kan vi argumentere at dette må oppdragsgivere avgjøre, strategien må være klar når vi får oppdraget når vi får prosjektet gjør vi det vi blir bedt om. Det er riktig. Vi gjør imidlertid ikke jobben vår om vi ikke opptrer som oppdragsgivers rådgiver. Av og til er det slik at vi som systemutviklere vet bedre hvilke side 9 av 33
muligheter som finnes, eller vi kan i løpet av prosjektet bli oppmerksomme på mulige angrepsmåter som kan gi oppdragsgiveren større muligheter enn oppdragsgiverens opprinnelige utgangspunkt. 1.5.4. Forankring av prosjektet Som nevnt over, er det avgjørende viktig for å lykkes at vi klarer å avdekke de riktige brukerkravene. I denne forbindelse må vi være oppmerksomme på forankringen av prosjektet. Vi må ikke starte arbeidet med det nye system før vi har forsikret oss om at prosjektet er forankret på riktig måte i organisasjonen. Med riktig forankring mener vi for det første at prosjektet må ha en sponsor som har myndighet til å innføre prosjektresultatene i organisasjonen. Deretter er det viktig at de som skal bruker resultatet av prosjektet virkelig har et behov og er enige i at det startes et prosjekt for å oppfylle behovet. Og de må være representert i prosjektet på en tilfredsstillende måte. Så må alle enheter som skal betale for prosjektet har godkjent prosjektets mål, rammer og planer og de må være tilfredsstillende representert i prosjektets styrende organer (styringskomité). De enhetene som skal avgi ressurser til prosjektet må ha godkjent prosjektets ressursplaner. Og tilslutt må alle som på en eller annen måte vil bli berørt av prosjektet være informert om at prosjektet er startet. Hvis alt dette er på plass kan vi si at prosjektet er forankret! Vi kan også si det så sterkt som at om noe av dette ikke er på plass, så har vi store muligheter til å mislykkes! Forankring av prosjektet er oppdragsgivers ansvar men prosjektleder har et klart ansvar for å si fra om dette til oppdragsgiver og vurdere om forankringen er tilfredsstillende. Vi fraråder en prosjektleder å påta seg et prosjekt hvis forankringen ikke er på plass. Mange bedrifter har utarbeidet en egen IT-strategi. Hensikten er å finne og prioritere de ITinvesteringene som vil gi bedriften størst nytteverdi i forhold til kostnader. Det er en stor fordel hvis et prosjekt er forankret i en IT-strategi. Det viser at behovet er reelt, og at bedriften prioriterer å få dekket det. Hvis bedriften derimot har en IT-strategi, men vil starte et nytt prosjekt uten at vi kan finne noe om det i strategien, bør vi være ekstra på vakt og ekstra påpasselig med å sjekke at forankringen er i orden. 1.5.5. Systemutvikling og lover og regler Over har vi snakket om forskjellige sider ved det å definere brukers behov og krav. Som en begrensning eller utdyping av dette, kommer det vi kan kalle systemutviklingens lover og regler. De viktigste å være oppmerksom på er: - Arbeidsmiljøloven, spesielt paragraf 12 om tilrettelegging av arbeid - Personregisterloven, som begrenser hvilke personopplysninger det er lov å registrere. Generelt må Datatilsynet søkes om konsesjon for å etablere et elektronisk personregister. - Rammeavtale mellom NHO og LO om teknologisk utvikling og datamaskinbaserte systemer. Avtalen forutsetter at det utarbeides konsekvensanalyser basert på helhetsbetraktninger for nye datasystemer, der forhold som endringer i arbeidsrutiner, organisasjon, informasjonsrutiner og mellommenneskelig kontakt er med. - Bedriftsinterne regler og standarder, som krav til arbeidsmetodikk, verktøystandarder etc. side 10 av 33
1.6. Gjennomføring av systemutvikling hvordan gjør vi det? Vi har nå diskutert noen av de utfordringene et systemutviklingsprosjekt står overfor. Vi starter nå med å diskutere hva vi bør gjøre for å møte utfordringene best mulig. Vi snakker i den forbindelse om beste praksis for systemutvikling. Beste praksis - et sett av velprøvde prinsipper, aktiviteter, fremgangsmåter og teknikker som erfaringsmessig er en sikker vei til målet - programvare som oppfyller kundens behov Beste praksis for systemutvikling er tema for dette og det neste kapitlet i denne leksjonen, og for alle de følgende leksjonene. I dette kapitlet starter vi med noen overordnede beste praksiser. Vi skal se på: - prinsipper for organisering - prinsipper for styring - prinsipper for sikring av kvalitet I neste kapittel skal vi snakke om systemutviklingsmodeller. I disse modellene vil vi finne overordnede prinsipper for gjennomføring av prosjektene, dvs. faser, aktiviteter og resultater. I de leksjonene som kommer senere, vil vi gå nærmere inn på hvordan prinsippene omsettes til praktisk arbeid. 1.6.1. Prinsipper for organisering av systemutvikling I leksjon 2 har vi diskutert de generelle prinsippene for organisering av prosjekter og sett nærmere på roller og oppgaver i en klassisk prosjektorganisasjon. I dette kapitlet skal vi se nærmere på hvordan vi vil fordele ansvar og oppgaver når vi driver systemutvikling. For vår type systemer informasjonssystemer for en bedrift gjennomføres normalt utviklingen som et samarbeid mellom en brukerorganisasjon og systemutviklere. Mye av suksessen til systemutviklingsprosjektet er avhengig av at dette samarbeidet fungerer godt. Det har derfor etter hvert utviklet seg en beste praksis for organisering av samarbeidet hvem som gjør hva og hvordan samarbeidet bør foregå. I praksis vil dette variere fra prosjekt til prosjekt, men disse generelle retningslinjer er et godt utgangspunkt når vi planlegger prosjektet. Alle de rollene vi diskuterte i leksjonen om prosjektarbeid må fylles, men her ser vi altså nærmere på hvem det er som bør fylle dem. Hvem deltar i arbeidet? Vi har følgende roller: Bruker: Skal bruke systemet i sine daglige oppgaver Oppdragsgiver: Betaler for utvikling av systemet Systemutvikler: Er ekspert på systemutvikling side 11 av 33
Bruker og oppdragsgiver Både brukeren og oppdragsgiveren representerer brukerorganisasjonen, men med hver sine roller. Brukeren er som nevnt den som skal bruke det nye systemet i sine daglige arbeidsoppgaver. Oppsummert kan vi si at siden brukeren er den som eier problemet og vil bli eier av løsningen, er det rimelig at brukeren har sterk påvirkning på virkemåten og egenskapene til løsningen. Oppdragsgiveren er som nevnt den som betaler for prosjektet. Oppsummert kan vi si at siden oppdragsgiveren finansierer arbeidet, er det rimelig at oppdragsgiveren går inn i styringen av prosjektet og godkjenner budsjett og planer og prosjektets valg av løsning. Systemutvikleren Systemutvikleren er enkelt sagt ekspert i systemutvikling. (Vi bruker her begrepet systemutvikler veldig generelt og skiller for eksempel ikke mellom analytiker og programmerer). Det er systemutvikleren som har den IT-faglige kompetansen i prosjektet. Systemutvikleren vet hva som er mulig å få til, hva som er teknisk sett gode og robuste løsninger, hva løsninger vil koste og hvilke verktøy som bør benyttes. Systemutvikleren har i tillegg ofte kompetanse i prosjektledelse og erfaring fra andre systemutviklingsprosjekter. Oppsummert kan vi si at siden systemutvikleren har denne kompetansen, bør den utnyttes til fulle. Ut i fra dette hvordan velger vi å fordele oppgavene? Systemets ytre egenskaper. Systemets ytre egenskaper, av og til kalt funksjonalitet, vil si den måten systemet virker på, den delen av systemet som brukeren ser og opplever. Dette er slike ting som skjermbilder og måten bruker kommuniserer med systemet på. Det er hva systemet kan gjøre eller med andre ord, hvilke funksjoner det har, det er de data systemet kan behandle, det er responstid, det er antall samtidige brukere og så videre. Systemets ytre egenskaper er brukerens ansvar. Det er brukeren som må formulere behov og krav, og vurdere og gjøre valg om egenskapene til systemet. Systemutvikleren må imidlertid bidra aktivt til at brukeren kan gjøre gode valg. Systemutvikleren gjør dette gjennom - å gjennomføre en god prosess for å avdekke hvilke krav bruker har til det nye systemet - å veilede bruker i hva som er mulig og hva som er anerkjent god utforming av systemer - å spesifisere kravene på en slik måte at bruker forstår hva han beslutter - å vise konsekvensene av valg i forhold til kostnader, både utviklingskostnader og driftskostnader og kostnader til utstyr, arbeidsrutiner, infrastrukturen etc. - å utrede mulige alternativer Systemets indre egenskaper Med systemets indre egenskaper mener vi de datatekniske løsningene vi har valgt for å kunne realisere de ytre egenskapene. Dette er slike ting som programkode, inndeling i programmoduler, måten data er organisert på, måten data er lagret på, valg av verktøy, valg av utstyr osv. side 12 av 33
Systemets indre egenskaper er systemutviklerens ansvar. Det er systemutvikleren som må finne frem til den sammensetningen av indre egenskaper som gir brukeren et system med de ytre egenskapene som brukeren vil ha. I tillegg må systemutvikleren sørge for godt systemteknisk håndverk, slik at systemet blir driftsstabilt, modulært, enkelt å vedlikeholde, fleksibelt for utvidelser, i samsvar med bedriftens verktøystandard osv. Dette gjør systemutvikleren uten innblanding fra brukeren. Strategi, mål og rammer for løsningen. Strategi, mål og rammer for løsningen vil si overordnede føringer for hva slags system som skal utvikles. Dette er forhold som: hvor stor del av organisasjonen og arbeidsprosessene blir berørt, hvor mye skal automatiseres, hva kan systemet koste, hvilken infrastruktur skal systemet passe inn i osv. Å velge strategi, beslutte mål og gi rammer for valg av løsning, er oppdragsgiverens ansvar. Oppdragsgiveren har i tillegg ansvar for å vurdere prosjektets lønnsomhet. Systemutvikleren må imidlertid hjelpe oppdragsgiveren til å gjøre gode beslutninger. Det gjør han gjennom å vise oppdragsgiveren hvilke muligheter han har, og vise han konsekvensene av valgene. Når det gjelder prosjektets lønnsomhet, må systemutvikleren synliggjøre kostnadene ved systemutviklingen mens oppdragsgiveren må vurdere nytten og beslutte om prosjektet er verdt kostnadene. Forberede organisasjonen til å ta systemet i bruk Forberedelse til å ta systemet i bruk betyr å sørge for at organisasjonen og arbeidsrutinene og systemet passer sammen den dagen systemet er ferdig, nytt utstyr er på plass, hjelpeapparat er på plass og brukerne har fått nødvendig opplæring. Det er oppdragsgiverens ansvar at organisasjonen er tilstrekkelig forberedt til å ta systemet i bruk den dagen systemet er ferdig. Systemutvikleren har ansvar for å informere oppdragsgiveren i god tid om hvilke forberedelser som er nødvendige. Systemutvikleren bør bistå oppdragsgiveren med - brukerdokumentasjonen - opplæringen av brukerne - etablering av brukerstøtten Prosjektledelse Det er brukerorganisasjonen som eier prosjektet og derfor bør prosjektet i prinsippet ledes av en derfra. I praksis velges ofte systemutvikleren som prosjektleder. Begrunnelsen for dette, er bedre prosjektlederkompetanse og erfaring, og bedre anledning til å gå inn i prosjektet på full tid. Hvis systemutvikleren påtar seg oppgaven som prosjektleder, er det viktig at han gjør dette på vegne av brukerne og har nok fokus på det som kommer i tillegg til den rene programvareutviklingen. Vi tenker her på organisasjonen, på arbeidsrutinene, på opplæring osv. Som vi har nevnt, kan det være motsetning mellom brukerens interesser og oppdragsgiverens interesser. For eksempel kan oppdragsgiverens ønske om å effektivisere og rasjonalisere bety en ny arbeidssituasjon for brukeren som brukeren ikke ønsker. Prosjektlederen får da den ikke helt enkle oppgaven å ivareta begges interesser. Her kan arbeidsgiverorganisasjonene og avtaleverket være til hjelp. side 13 av 33
1.6.2. Oppsummert - Systemutviklerens rolle Målet er å utvikle programvare som oppfyller kundens behov. Det betyr ikke at vi som systemutviklere gjør en god jobb hvis vi forholder oss passive og aksepterer uten spørsmål det kunden sier at han vil ha. Som systemutviklere har vi en ekspertise som er viktig for kunden når vi skal finne frem til brukerbehovene. Gjennom vår kompetanse, vår tidligere erfaring og det arbeidet vi gjør i prosjektet, kan vi se muligheter og løsninger som kunden ikke nødvendigvis klarer å se uten vår hjelp. Vi må da opptre som rådgivere for kunden. Men vi må ikke blande sammen det å gi råd med det å bestemme - kunden skal ta beslutningen. 1.6.3. Noen ord til slutt Alt som er skrevet over er generelt gode råd og retningslinjer for å organisere et systemutviklingsprosjekt. Men vi kan selvfølgelig, og med god grunn, velge å gjøre det helt annerledes. Uansett hvordan vi velger å fordele oppgaver og roller er det imidlertid et prinsipp som er overordnet alle andre og som vi må sørge for er oppfylt: alt ansvar, alle oppgaver og roller skal være definert og klart beskrevet, og alle prosjektmedlemmer skal vite hvilken rolle de har og hva som forventes av dem De fleste prosjekter organiseres med en styringskomité og en kvalitetsfunksjon. Vær spesielt oppmerksom på at vi også må fortelle disse hvilken rolle de har og hva som forventes av dem i prosjektet. Det er lett å tro at det ikke er nødvendig, siden medlemmene i disse to funksjonene er ledere og/eller medarbeidere med lang erfaring. I praksis viser det seg at det kan være disse som trenger det mest. 1.7. Prinsipper for styring av systemutvikling Med begrepet styring mener vi - ledelse - planlegging - oppfølging Dette er et svært omfattende tema som vi allerede har vært inne på i leksjonen: Prinsipper for prosjektarbeid. Det vi har sagt der, gjelder også for et systemutviklingsprosjekt. Oppsummert gjelder dermed disse prinsippene også for våre prosjekter: - Prosjektets styringsstruktur må være klart definert i prosjektorganisasjonen (se prinsipper for organisering) - Det må utvikles realistiske planer. Planene viser - resultater som skal produseres - aktiviteter som skal gjennomføres for å produsere resultatene - nødvendige ressurser for å gjennomføre aktivitetene side 14 av 33
- kriterier for å kunne vurdere om resultatene er tilfredsstillende - Prosjektstatus må følges opp regelmessig - Planene må kontinuerlig revideres basert på resultatet av oppfølgingen Dette er svært enkle og overordnede prinsipper, og et absolutt minimum av hva som må sies om styring. I et konkret prosjekt må dette bli til detaljerte planer, til en organisasjon med personer som har ansvar for oppgaver, til definerte kriterier for å vurdere resultater og til prosedyrer som forteller oss hvordan vi skal følge opp og revidere planene. Når vi planlegger et systemutviklingsprosjekt tar vi utgangspunkt i en systemutviklingsmodell (se neste kapittel). En slik modell inneholder standarder og retningslinjer også for styring. Den vil dermed hjelpe oss til å gjøre de prinsippene som vi har beskrevet over, om til virkelig styring av et virkelig prosjekt. Tilsutt tar vi med enda ett viktig prinsipp for styring: kontroll av usikkerhet i systemutvikling. 1.7.1. Usikkerhet i et systemutviklingsprosjekt Det er stor usikkerhet i estimatene tidlig i et systemutviklingsprosjekt. Når de første estimatene utarbeides, kan usikkerheten være så mye som 100%. Selv om det utføres en grundig analyse av prosjektet av prosjektledere med lang erfaring, har vi lite å holde oss til så tidlig i prosjektet. Senere i arbeidet når brukerkravene er beskrevet og prosjektet har oversikt over hva slags system som skal utvikles, bør usikkerheten være redusert til omkring 20% for et prosjekt med lav risiko, mens det for et prosjekt med høy risiko fremdeles kan være snakk om usikkerhet i størrelsesorden 50%. Det er viktig at både oppdragsgiver og prosjektleder aksepterer usikkerheten og er enige om prosedyrer for å kontrollere den. Prinsipp for å kontrollere usikkerhet Et generelt prinsipp for å kontrollere usikkerheten er vist i figuren nedenfor. Utgangspunktet er å dele arbeidet inn i faser. Mer om faseinndeling senere. Mellom hver fase stopper vi opp og gjør en vurdering av prosjektet. Avtalen mellom oppdragsgiveren og prosjektlederen kan da være: - Oppdragsgiveren finansierer en fase om gangen. Oppdragsgiveren kan se på finansiering av en fase som finansiering av å få vite mer. Når vi vet mer, reduseres usikkerheten i prosjektet. - Oppdragsgiveren kan stoppe prosjektet etter hver fase og oppdragsgiverens risiko er dermed i prinsippet begrenset til en fase om gangen. - Prosjektlederen planlegger alltid arbeidet for neste fase slik at usikkerheten i fasen kan holdes innenfor 10-15 %. side 15 av 33
- Usikkerheten i estimatene for resten av prosjektet starter høyt, men reduseres etter hver ny fase fordi vi vet mer se figuren. - I beslutningspunktet etter en fase, legger prosjektlederen frem prosjektresultater og reviderte planer. Dette er oppdragsgiverens grunnlag for nye beslutninger. Grunnlaget for å beslutte om et prosjekt skal stoppes eller gå videre, er hele tiden en samlet vurdering av oppnådde resultater og prosjektkostnader. 1.7.2. Prinsipper for kvalitetssikring Vi har noen enkle prinsipper for kvalitetssikring som er allment aksepterte. Du vil finne dem igjen som grunnlag for alle systemutviklingsmodeller (se neste kapittel): Estimerte totalkostnader Maksimum Spesifikasjon ferdig Punkt for kost/nytte Akumulerte kostnader Minimum Kostnader for å bli sikker Forstudium Analyse Arkitektur Innføring Programmering Prosjektfaser Legg vekt på å forhindre feil Legg vekt på å oppdage feil så tidlig som mulig Legg vekt på å finne årsaken til at feil oppstår og sørg for å fjerne årsaken La noen utenfra vurdere prosjektet (kvalitetsgjennomganger) Bruk erfaringer fra prosjektene til å forbedre utviklingsprosessen Noen kommentarer: I et prosjekt har vi lett for bare å se kostnadene ved kvalitetssikring, det vil si ved å forhindre feil og oppdage feil så tidlig som mulig. I teorien er det lett å argumentere overbevisende for side 16 av 33
at kvalitetssikring lønner seg. I praksis, i vårt eget, konkrete prosjektet, kan det være fristende å satse på at vi klarer oss uten. Av og til kan vi faktisk oppleve at det er oppdragsgiveren som mest ivrer for å sløyfe kostbar dokumentasjon, kvalitetsgjennomganger etc. Da er det vår oppgave å vite hvorfor vi arbeider som vi gjør og selge dette til oppdragsgiveren. Men det er selvfølgelig lov å bruke fornuft. Omfanget på de tiltakene vi iverksetter for å forhindre feil, må alltid stå i et rimelig forhold til alvorligheten av det vi prøver å forhindre, og hva det koster å rette opp om feil oppstår. Så kalte kvalitetsgjennomganger er ikke alltid populære i prosjektene. Ingen liker vel egentlig at noen kommer inn utenfra og kritiserer og finner feil i arbeidet vårt. Vi må imidlertid forsøke å se på kvalitetsgjennomgangene som noe positivt. Her kommer det folk med erfaring og kompetanse og er villig til å bruke av sin tid på at mitt arbeid skal bli bedre! Det forutsetter selvfølgelig at de som gjennomfører kvalitetsgjennomgangene oppfører seg skikkelig. Det å ta vare på prosjektenes erfaringer og bruke dem til å forbedre måten vi jobber på, er en veldig god og praktisk anvendbar idé. Det er mye billiger å bruke noe lurt som et prosjekt har utviklet og prøvd, enn å sette ned en egen metodegruppe for å utrede og forslå og lage en metode eller en standard. Det går mye fortere før det kommer andre prosjekter til nytte også. Tips til arbeidslivet: hvis den bedriften du havner i ikke har noen systematikk for å samle opp lure ting fra prosjektene, så bør du jobbe for å få innført dette. 1.8. Prosjektmodeller for systemutvikling Systemutvikling er et forholdsvis nytt fagfelt, men etter hvert som man har fått erfaring med faget, har det utviklet seg en beste praksis for å gjennomføre hovedoppgavene. Med utgangspunkt i beste praksis er det definert standardprosesser for systemutvikling. Slike standardprosesser kaller vi systemutviklingsmodeller eller prosjektmodeller. En systemutviklingsmodell er et overordnet rammeverk som gir: prinsipper, struktur, faser og aktiviteter og krav og retningslinjer for gjennomføring av hovedoppgavene. Vi kaller dem systemutviklingsmodeller fordi de er en modell av et prosjekt, et eksempel på hvordan det kan gjøres. Det finnes mange forskjellige modeller. Det skyldes i hovedsak at det finnes ulike oppfatninger av hva som faktisk er den beste fremgangsmåten. Vi skal senere i leksjonen se noen eksempler på modeller. Vi har tidligere sagt at vi har to kategorier aktiviteter i et systemutviklingsprosjekt: de faglige og de prosjektadministrative. Alle systemutviklingsmodeller dekker de faglige aktivitetene, men ikke alle har med de prosjektadministrative. En bedrift som driver systemutvikling vil ha en eller flere modeller som de ansatte skal følge. Disse modellene gir rammeverket for andre hjelpemidler for systemutviklere slik som verktøy, standarder, metoder etc. Vær oppmerksom på I dette kapitlet bruker vi ordet modell om en modell for gjennomføring av et prosjekt en prosjektmodell. Når prosjektet er et systemutviklingsprosjekt bruker vi ordet systemutviklingsmodell. Det er kortformen av: en prosjektmodell for systemutvikling. Disse tre begrepene: modell, prosjektmodell og systemutviklingsmodell vil bli brukt litt om hverandre i kapitlet. side 17 av 33
Senere i faget kommer vi til å bruke ordet modell i andre betydninger. Spesielt vil vi snakke mye om å lage forskjellig modeller av det systemet som skal utvikles. 1.8.1. Hvorfor forskjellige prosjektmodeller for systemutvikling? Som sagt, det finnes mange forskjellige modeller. Forskjellene skyldes: 1. Type system som skal utvikles (eksempel: flerbrukersystem som egenutvikles, enkelt enbrukersystem basert på regneark, videreutvikling av eksisterende system eller programpakke som tilpasses). 2. Hvilke arbeidsoppgaver som vurderes som de viktigste (eksempel: analyse av virksomheten med tanke på forbedringer, organisasjons- og personalutvikling, avbildning av dagens praksis i nytt system, markedsundersøkelse for å finne det beste systemet eller ren teknologiutvikling). 3. Ulike strategier for leveranse av det nye systemet (revolusjon eller evolusjon). 4. Fremgangsmåte for å avdekke brukerkrav: (analytisk eller eksperimentell). 5. Arbeidsfordeling mellom ulike interessegrupper, spesielt mellom bruker og IT-eksperter. 6. Hjelpemidler som metoder, teknikker og verktøy (eksempel: CASE-verktøy, 4- generasjonsverktøy, intensive arbeidsmøter, prototyping, kreative teknikker eller beskrivelsesteknikker). 7. Ønsket grad av styring, for eksempel avhengig av generell risikovurdering, oppfølging av eksterne kontrakter, kompetanse hos prosjektdeltagerne, organisasjonskultur. 8. Gradvis utvikling av beste praksis i systemutvikling, det vil si at vi får stadig bedre modeller etter hvert som kunnskapen om systemutvikling øker hos ekspertene. Vi skal kort omtale to ulike leveransestrategier og to ulike arbeidsmetodikker for å finne brukerkravene. Revolusjon eller evolusjon Vi har tidligere flere ganger vært inne på at et systemutviklingsprosjekt er langvarig og omfattende. Det klassiske systemutviklingsprosjektet tar gjerne minst et par år og koster fort 10 millioner. Noen ganger langt mer. Det er vanskelig å lykkes med et slikt prosjekt rett og slett fordi det går for lang tid fra ønsker og behov presenteres til resultatet foreligger. Det har derfor etter hvert utviklet seg modeller som legger opp til å levere systemet til brukerne gradvis, en bit av systemet om gangen: evolusjon i motsetning til tidligere modellers leveransestrategi revolusjon hvor hele systemet ble gjort ferdig og levert alt på en gang. Når vi følger denne strategien, skal ikke brukerne vente for lenge på første bit av systemet, ofte settes en øvre grense på 4 6 mnd. Vi velger også gjerne ut den delen som selger best i organisasjonen og har størst sjanse for å bli en suksess. Dette gir prosjektet positiv støtte. Videre er det en forutsetning at brukernes erfaringer med de leverte bitene skal være grunnlag for videre arbeid, slik at en hele tiden kan justere behov og forventninger og resultat, og sørge for at det blir samsvar mellom det som leveres og det brukerne har behov for. side 18 av 33
Analytisk eller eksperimentell Før selve utviklingen av systemet tar til, må vi finne ut hvilke krav brukerne har og hva slags system som skal utvikles. Det er en lang tradisjon for at vi gjør dette gjennom en systematisk, intellektuell prosess en analyse, med mål å beskrive brukerorganisasjonens behov og krav og de egenskapene det nye systemet må ha for å oppfylle disse. Erfaring viser at denne fremgangsmåten ikke alltid er vellykket. Det er ikke alltid den fører til et system som blir slik brukerne har tenkt seg, eller egentlig hadde bruk for. Det er mange grunner til det, her er noen stikkord: - Brukeren vet ikke alltid hva han vil ha eller hva som er mulig - Brukeren og systemutvikleren snakker forskjellig språk og misforstår hverandre - Brukeren blir overkjørt av systemutviklerens ekspertise - Det beslutningsgrunnlaget som systemutvikleren legger frem for brukeren etter analysen, er for det første for abstrakt til å se konsekvensene av, og for det andre alt for omfattende til å sette seg inn i. Det har derfor etter hvert blitt mer og mer vanlig å bygge en så kalt prototyp som grunnlag for å diskutere krav til systemet. Det vil si et programsystem som demonstrerer et systems ytre egenskaper, for eksempel skjermbilder. En prototyp gjør det mulig å eksperimentere, slik at en lett kan vise alternative muligheter og fort endre på ting. Brukeren og systemutvikleren kan da sitte sammen om noe konkret og det er mye lettere å forutse hvordan systemet blir. 1.8.2. Bruk av systemutviklingsmodeller Før vi ser eksempler på forskjellige modeller, skal vi i dette kapitlet si litt generelt om hvordan de brukes: - modeller er rammeverk for andre hjelpemidler for systemutvikling - modeller er utgangspunkt for å planlegge prosjektet - en bedrift som driver systemutvikling har en eller flere modeller Modeller som rammeverk for andre hjelpemidler En prosjektmodell hører som nevnt sammen med andre hjelpemidler for systemutvikling. Vi kan definere: Begrep Modell Metode Teknikk Verktøy Standarder Betydning i en prosjektmodell Overordnet rammeverk Fremgangsmåte for å løse et problem, kan bli brukt i flere modeller, på flere steder i modellen En måte å jobbe på, kan støtte flere metoder Støtte til metoder eller teknikker Skal følges i arbeidet, for eksempel programmeringsstandarder eller navnestandarder Vi får dermed et hierarki av hjelpemidler, hvor modellen gir oss rammeverket for å benytte de andre. Dette gjør mulig for oss å velge standarder, verktøy, teknikker og metoder som passer side 19 av 33
til prosjektet uten å endre modellen. Dette er en viktig side ved modellen at den tillater oss å skifte ut gamle hjelpemidler med nye og bedre uten å endre selve strukturen i arbeidet. En prosjektmodell med tilhørende hjelpemidler kalles av og til en metodikk. Men begrepsbruken på dette området er temmelig forvirrende og ordene modell, metode og metodikk blir ofte brukt om hverandre. Planlegging ved hjelp av prosjektmodeller Ved planlegging av et nytt prosjekt bør vi ta utgangspunkt i en prosjektmodell, og se på den som en sterk anbefaling. Deretter utarbeider vi prosjektets konkrete planer basert på modellen. Se figuren nedenfor. I praksis vil vi alltid gjøre visse tilpasninger i forhold til modellen. Ingen prosjekter er like og modellen er generell. Modeller er likevel meget nyttige verktøy ved planleggingen og det er et sunt prinsipp å følge modellen med mindre vi har gode argumenter for å gjøre det annerledes. Prosjektmodell Prosjektplaner Planlegging av prosjektet Anbefaling om beste praksis Planlegging ved hjelp av prosjektmodeller Konkrete planer for dette prosjektet: resultater aktiviteter ressurser verktøy standarder 1.8.3. En bedrift som driver systemutvikling har en eller flere modeller Det finnes som nevnt mange forskjellige modeller. De fleste bedrifter som gjennomfører systemutviklingsprosjekter, har etablert en eller flere modeller som standard i bedriften. Det er vanlig at disse modellene integrerer både faglige aktiviteter og prosjektstyringsaktiviteter i en modell, at modellen dekker hele prosjektforløpet og at den har knyttet til seg andre hjelpemidler som beskrevet i forrige kapittel. De modellene du vil finne i litteraturen konsentrer seg gjerne om de rene systemutviklingsaktivitetene og dekker ikke nødvendigvis hele prosjektløpet. Slike modeller vil inngå som elementer i den typiske bedriftsmodellen, som kanskje også kombinerer forskjellige modeller slik at hele prosjektløpet dekkes. Hvis du har fått forståelsen av prinsipper og innhold i en modell vil overgangen være lett til å kunne bruke en du møter i arbeidslivet på en fornuftig måte. Sertifisering av modeller Mange bedrifter har sertifisert sine modeller (med tilhørende hjelpemidler) i forhold til en standard, for eksempel ISO-standard for systemutvikling. Eller de har fått sine modeller vurdert i forhold til et modenhetsnivå, for eksempel CMM (Capability Maturity Model). side 20 av 33