1. Introduksjon til systemutvikling

Størrelse: px
Begynne med side:

Download "1. Introduksjon til systemutvikling"

Transkript

1 Greta Hjertø 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 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

2 - 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

3 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 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: Å 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

4 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 Å 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 Å 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 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

5 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 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

6 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 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

7 - 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 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

8 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 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

9 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

10 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 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 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

11 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 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

12 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

13 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

14 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 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 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

15 - 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 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 %. side 15 av 33

16 - 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 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

17 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 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

18 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 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

19 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 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

20 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 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

1. Forstudiefasen. 1.1. Oversikt over forstudiefasen

1. Forstudiefasen. 1.1. Oversikt over forstudiefasen Greta Hjertø 24.2.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D 1. Resymé: I denne leksjonen skal vi ta for oss den første fasen i systemutviklingsprosjektet

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Innlevering 3. IBE 250 Ingrid Vermøy, 090859

Innlevering 3. IBE 250 Ingrid Vermøy, 090859 Innlevering 3 IBE 250 Ingrid Vermøy, 090859 Kai A. Olsen er professor i informatikk ved Høgskolen i Molde og ved Universitetet i Bergen, han er også professor ved universitetet i Pittsburgh. Per Sætre

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

Detaljer

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner Introduksjon til prosjektarbeid del 1 Prosjektet som arbeidsform Begrep, fundament og definisjoner For å lykkes i konkurransen Er innovasjon viktig Nye produkter, markedsføring, produksjonsmåter, opplæring,..

Detaljer

Psykososialt IT-miljø

Psykososialt IT-miljø Psykososialt IT-miljø En av mange: Definisjon Det psykososiale miljøet dreier seg om hvordan hvert individ har det sammen med andre. Mennesker er sosiale skapninger, vi er avhengig av kontakt med andre,

Detaljer

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

Detaljer

Test of English as a Foreign Language (TOEFL)

Test of English as a Foreign Language (TOEFL) Test of English as a Foreign Language (TOEFL) TOEFL er en standardisert test som måler hvor godt du kan bruke og forstå engelsk på universitets- og høyskolenivå. Hvor godt må du snake engelsk? TOEFL-testen

Detaljer

1. Innføring av system

1. Innføring av system Greta Hjertø 02.04.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 den siste av fasene

Detaljer

IT I PRAKSIS!!!!! IT i praksis 20XX

IT I PRAKSIS!!!!! IT i praksis 20XX IT I PRAKSIS 1 IT i praksis 20XX 2 IT I PRAKSIS FORORD 3 INNHOLD 4 IT I PRAKSIS Styringsmodell for utviklingsprosjekter (SBN) 5 Fra en idé til gevinstrealisering styringsmodell for utviklingsprosesser

Detaljer

Studentevaluering av undervisning. En håndbok for lærere og studenter ved Norges musikkhøgskole

Studentevaluering av undervisning. En håndbok for lærere og studenter ved Norges musikkhøgskole Studentevaluering av undervisning En håndbok for lærere og studenter ved Norges musikkhøgskole 1 Studentevaluering av undervisning Hva menes med studentevaluering av undervisning? Ofte forbindes begrepet

Detaljer

Anskaffelse av nytt Biblioteksystem

Anskaffelse av nytt Biblioteksystem Oppdatert: 2009-10-27 Til: Styremøte 2009-11-02 Saksdokument S-2009/57 Anskaffelse av nytt Biblioteksystem Det vises til vedlagte notat om anskaffelsen. Notatet ble brukt da KD ble orientert på etatsstyringsmøtet

Detaljer

Grunnleggende om Evaluering av It-systemer

Grunnleggende om Evaluering av It-systemer Grunnleggende om Evaluering av It-systemer Hva er å evaluere? Foreta en vurdering av systemet og avklare nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien

Detaljer

Gruppenavn. Prosjektnavn Visjonsdokument. Versjon <1.0>

Gruppenavn. Prosjektnavn Visjonsdokument. Versjon <1.0> Gruppenavn Prosjektnavn Visjonsdokument Versjon Revisjonshistorie Dato Versjon Beskrivelse Forfatter 2 Mal Visjonsdokument Informasjon om malen: - Bruk av malen

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14. Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.april 2015 Innhold 1. INNLEDNING... 3 2. GJENNOMFØRING... 4 3. SATSINGSOMRÅDER...

Detaljer

13 tips. for å lykkes med. Skype for Business. Her er våre 13 tips for å lykkes med innføring av Skype for Business.

13 tips. for å lykkes med. Skype for Business. Her er våre 13 tips for å lykkes med innføring av Skype for Business. 13 tips for å lykkes med Skype for Business Skype for Business er ikke bare en ny type telefonsentral eller et nytt videosystem. Det er en mulighet for å jobbe sammen på en ny måte. Men det kommer ikke

Detaljer

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette?

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette? Introduksjon til evaluering av It-systemer Hvordan vurdere og verdsette? Bør jeg gå på forelesning i dag? Kriterier for eller imot: Interessant/kjedelig tema God/dårlig foreleser Kan lese forelesningene

Detaljer

Studentevaluering av undervisning

Studentevaluering av undervisning Studentevaluering av undervisning En håndbok til bruk for lærere og studenter ved Norges musikkhøgskole Utvalg for utdanningskvalitet Norges musikkhøgskole 2004 Generelt om studentevaluering av undervisning

Detaljer

Regning i alle fag. Hva er å kunne regne? Prinsipper for god regneopplæring. 1.Sett klare mål, og form undervisningen deretter

Regning i alle fag. Hva er å kunne regne? Prinsipper for god regneopplæring. 1.Sett klare mål, og form undervisningen deretter Regning i alle fag Hva er å kunne regne? Å kunne regne er å bruke matematikk på en rekke livsområder. Å kunne regne innebærer å resonnere og bruke matematiske begreper, fremgangsmåter, fakta og verktøy

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Prosjektplan for forprosjekt. Felles avfallshåndtering i Kongsbergregionen

Prosjektplan for forprosjekt. Felles avfallshåndtering i Kongsbergregionen Prosjektplan for forprosjekt Felles avfallshåndtering i Kongsbergregionen Innhold Innledning...3 Bakgrunn...3 Mål og hovedaktiviteter...4 3.1 Overordnet målsetting...4 Delmål...4 Rammer...6 Fremdriftsplan...6

Detaljer

P R E S E N TA S J O N AV F O R B E D R I N G S P R O G R A M M E T «L I N K I T» F R O K O S T M Ø T E B A 2 0 1 5

P R E S E N TA S J O N AV F O R B E D R I N G S P R O G R A M M E T «L I N K I T» F R O K O S T M Ø T E B A 2 0 1 5 P R E S E N TA S J O N AV F O R B E D R I N G S P R O G R A M M E T «L I N K I T» F R O K O S T M Ø T E B A 2 0 1 5 VÅR BEDRIFT CA 340 ANSATTE 14 LOKASJONER I NORGE, SVERIGE OG DANMARK ARKITEKTUR, INTERIØR,

Detaljer

Effektiv møteledelse. Ole I. Iversen Assessit AS Mob: +47 992 36 296

Effektiv møteledelse. Ole I. Iversen Assessit AS Mob: +47 992 36 296 Effektiv møteledelse Ole I. Iversen Assessit AS Mob: +47 992 36 296 Definisjon En situasjon der flere mennesker er samlet for å løse en oppgave En situasjon hvor arbeidsmåten velges ut fra møtets mål hensikt

Detaljer

Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret

Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret Hvordan styre anskaffelsen Organisering-kvalitetssikring Hvordan unngå å gå i baret Advokat Kristine Vigander, KS Advokatene Innhold Makro Hvordan tilrettelegge for anskaffelsesarbeidet i organisasjonen

Detaljer

KOMMUNIKASJON TRENER 1

KOMMUNIKASJON TRENER 1 KOMMUNIKASJON TRENER 1 INNLEDNING Bra lederskap forutsetter klar, presis og meningsfylt kommunikasjon. Når du ønsker å øve innflytelse på spillere, enten det være seg ved å lære dem noe, løse problemer,

Detaljer

LEDER- OG PERSONALUTVIKLING

LEDER- OG PERSONALUTVIKLING LEDER- OG PERSONALUTVIKLING TEAMUTVIKLING, LEDELSE OG KOMMUNIKASJON BAKGRUNN, OPPLEGG OG GJENNOMFØRING INNLEDNING Lederrollen er en av de mest krevende og komplekse oppgaver i bedriften. Etter hvert som

Detaljer

Strategier 2010-2015. StrategieR 2010 2015 1

Strategier 2010-2015. StrategieR 2010 2015 1 Strategier 2010-2015 StrategieR 2010 2015 1 En spennende reise... Med Skatteetatens nye strategier har vi lagt ut på en spennende reise. Vi har store ambisjoner om at Skatteetaten i løpet av strategiperioden

Detaljer

HSH Lederhusets medieguide

HSH Lederhusets medieguide HSH Lederhusets medieguide Det å kunne håndtere media er blitt en viktig rolle for en bedriftsleder både det å utnytte mediene til din for å skape positiv blest rundt din virksomhet, og å unngå å ramle

Detaljer

Tom Røise 27.Jan 2011

Tom Røise 27.Jan 2011 Forelesning IMT2243 27. Januar 2011 Tema : Risikostyring i systemutviklingsprosjekter Prosjektstyring i systemutviklingsprosjekter Presentasjon av prosjektoppgave 2011 Prosjektplandokumentet (Innlevering

Detaljer

Psykososialt IT-miljø

Psykososialt IT-miljø Psykososialt IT-miljø En av mange: Definisjon Det psykososiale miljøet dreier seg om hvordan mennesker har det sammen med andre. Vi er sosiale skapninger, avhengig av kontakt med andre. Kontakten må være

Detaljer

Sjekkliste for leder. Samtalens innhold (momentliste)

Sjekkliste for leder. Samtalens innhold (momentliste) OPPLEGG FOR MEDARBEIDERSAMTALE Mål, status og utvikling 1. Innledning og formålet med samtalen 2. Rammer for medarbeidersamtalen innhold og forberedelse 3. Hvordan gjennomføre den gode samtalen? 4. Oppsummeringsskjema

Detaljer

Medarbeiderundersøkelse

Medarbeiderundersøkelse Medarbeiderundersøkelse Innledning Undersøkelsen skal gi den enkelte medarbeider mulighet til å gi tilbakemelding på hvordan han eller hun opplever sin arbeidssituasjon. Resultatene fra undersøkelsen vil

Detaljer

Bedre effekt av IKT jobb systematisk!

Bedre effekt av IKT jobb systematisk! NSF ehelsekonferanse Bedre effekt av IKT jobb systematisk! ehelse et nødvendig virkemiddel for samhandling 13. 14. mai 2009 Deloitte AS Tønsberg 13.mai 2009 Bedre effekt av IKT er mulig! Effekter fra IKT

Detaljer

Strategisk salg - med fokus på kundestrategier, nøkkelkundeutvikling og optimalisering av salgsprosesser

Strategisk salg - med fokus på kundestrategier, nøkkelkundeutvikling og optimalisering av salgsprosesser Strategisk salg - med fokus på kundestrategier, nøkkelkundeutvikling og optimalisering av salgsprosesser Tar vi ut potensialet i vår salgsorganisasjon? Dette programmet skaper en rød tråd fra selskapets

Detaljer

Egenevalueringsskjema

Egenevalueringsskjema Egenevalueringsskjema for foretakets IT-virksomhet forenklet versjon basert på 12 COBIT prosesser Dato: 10.07.2012 Versjon 2.6 Finanstilsynet Tlf. 22 93 98 00 post@finanstilsynet.no www.finanstilsynet.no

Detaljer

Psykologisk kontrakt - felles kontrakt (allianse) - metakommunikasjon

Psykologisk kontrakt - felles kontrakt (allianse) - metakommunikasjon Tre kvalitetstemaer og en undersøkelse Psykologisk kontrakt felles kontrakt/arbeidsallianse og metakommunikasjon som redskap Empati Mestringsfokus 9 konkrete anbefalinger basert på gruppevurderinger av

Detaljer

Sammenhengen mellom og

Sammenhengen mellom og Sammenhengen mellom og Kvalitet HMS v/ Geir A. Molland Haugaland Kraft EBL 4. mars 2008 Forenklet historikk, et utgangspunkt HMS: Fra lavstatus til kritisk suksessfaktor Kvalitet: Fra selvfølgelighet /

Detaljer

Prosjektrettet systemarbeid Tema: prinsipper for prosjektarbeid

Prosjektrettet systemarbeid Tema: prinsipper for prosjektarbeid Prosjektrettet systemarbeid Tema: prinsipper for prosjektarbeid Høsten 2008 Lærere: Tore Mallaug, Kjell Toft Hansen Tema for dagen er Litt teori om prosjektarbeid Hva er et prosjekt? Hvor skal vi om prosjektmål

Detaljer

Salg! Salg av større prosjekter med lang tidshorisont og prosjektbasert leveranse - Leveranseprosjektet

Salg! Salg av større prosjekter med lang tidshorisont og prosjektbasert leveranse - Leveranseprosjektet SALG! I begynnelsen Salg! Salg av større prosjekter med lang tidshorisont og prosjektbasert leveranse - Leveranseprosjektet Perspektiv Store prosjekter har en lang tidsperiode før anbudsinnbydelse Antatt

Detaljer

Endringsledelse i Drammen Taxi BA 2011. Glenn A. Hole

Endringsledelse i Drammen Taxi BA 2011. Glenn A. Hole Endringsledelse i Drammen Taxi BA 2011 Glenn A. Hole Trender i arbeidslivet Organisasjonsutvikling Organisasjonsutvikling er: basert på en planlagt innsats, styrt fra toppen av organisasjonen, som omfatter

Detaljer

Felles gevinstmetodikk i. Kongsbergregionen

Felles gevinstmetodikk i. Kongsbergregionen Felles gevinstmetodikk i SuksIT Kongsbergregionen Alle IKT-prosjekter i Kongsbergregionen skal benytte felles gevinstmetodikk m/ følgende maler: 1. Mal for prosjektvurdering (vurdere om prosjektet skal

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Veileder for omstilling ved Handelshøyskolen BI Vedtatt av rektor 17.12.2010. Gjelder fra 1.1.2011. Revidert juli 2015

Veileder for omstilling ved Handelshøyskolen BI Vedtatt av rektor 17.12.2010. Gjelder fra 1.1.2011. Revidert juli 2015 Veileder for omstilling ved Handelshøyskolen BI Vedtatt av rektor 17.12.2010. Gjelder fra 1.1.2011. Revidert juli 2015 Som markedsutsatt virksomhet er BIs evne til innovasjon og tilpasning til markedet

Detaljer

Profesjonalisering av prosjektledelse

Profesjonalisering av prosjektledelse Profesjonalisering av prosjektledelse Ingar Brauti, RC Fornebu Consulting AS Software2013, IT-ledelse i fremtiden Onsdag 13. februar 2013 ingar.brauti@fornebuconsulting.com I fremtiden vil IT funksjonen

Detaljer

Mennesker fornyer Slik endrer digitaliseringen Norge klarer stat og kommune å følge med? Vidar Lødrup, direktør kunnskapsledelse, 11.2.

Mennesker fornyer Slik endrer digitaliseringen Norge klarer stat og kommune å følge med? Vidar Lødrup, direktør kunnskapsledelse, 11.2. Mennesker fornyer Slik endrer digitaliseringen Norge klarer stat og kommune å følge med? Vidar Lødrup, direktør kunnskapsledelse, 11.2.14 Abelia landsforeningen for kunnskaps- og teknologibedrifter i NHO

Detaljer

Hjelp til oppfinnere. 01 Beskyttelse av dine ideer 02 Patenthistorie 03 Før du søker et patent 04 Er det oppfinnsomt?

Hjelp til oppfinnere. 01 Beskyttelse av dine ideer 02 Patenthistorie 03 Før du søker et patent 04 Er det oppfinnsomt? Hjelp til oppfinnere 01 Beskyttelse av dine ideer 02 Patenthistorie 03 Før du søker et patent 04 Er det oppfinnsomt? 05 Å få et patent 01 Beskyttelse av dine ideer Hvis du har en idé til et nytt produkt

Detaljer

S Ø K E R V E I L E D I N G O G S Ø K N A D S M A L

S Ø K E R V E I L E D I N G O G S Ø K N A D S M A L S Ø K E R V E I L E D I N G O G S Ø K N A D S M A L Dette dokumentet er ment som informasjon om søknadsprosessen og om hva en prosjektsøknad til Skogbrukets verdiskapingsfond bør inneholde. SØKERBERETTIGEDE

Detaljer

Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011

Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011 Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011 6.2.11 Gjennomgå avtaleverket for å få på plass databehandleravtaler med driftsleverandørene 6.2.7 Pasientreiser

Detaljer

Ingen kan alt Alle kan noe Sammen kan vi det hele

Ingen kan alt Alle kan noe Sammen kan vi det hele Prosjekter er et viktig verktøy hvis man vil forandre og utvikle sitt lokalsamfunn. Et prosjekt er et tiltak som kan gjennomføres med et klart definert formål innenfor et avgrenset tidsrom og som forandrer

Detaljer

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem)

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Versjon 10. juni 2013 1 Bakgrunn Samarbeidstiltaket FS er et samarbeid mellom norske universiteter og høgskoler med ansvar for å videreutvikle

Detaljer

Markedsstrategi. Referanse til kapittel 4

Markedsstrategi. Referanse til kapittel 4 Markedsstrategi Referanse til kapittel 4 Hensikten med dette verktøyet er å gi støtte i virksomhetens markedsstrategiske arbeid, slik at planlagte markedsstrategier blir så gode som mulig, og dermed skaper

Detaljer

17. Kommunikasjon og samarbeid Grunnleggende prosjektledelse

17. Kommunikasjon og samarbeid Grunnleggende prosjektledelse 17. Kommunikasjon og samarbeid Grunnleggende prosjektledelse Innledning Coming together is a beginning. Keeping together is progress. Working together is success. Henry Ford Et vellykket prosjekt møter

Detaljer

Fra data til innsikt. Om prosjektet

Fra data til innsikt. Om prosjektet Fra data til innsikt DEFINERE FOKUS Om prosjektet De store produksjonsselskapene innen olje og gass må hele tiden strebe etter å effektivisere drift og øke sikkerheten på sine installasjoner. For å støtte

Detaljer

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer.

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer. KURSBESKRIVELSE Del 1: Grunnleggende kurs, 3 dager Del 2: Prosjektoppstart med fokus på IT-prosjekter, 2 dager Del 3: Utviklingsfaser innenfor IT integrasjonsprosjekter, 2 dager Del 4: Prosjektavslutning

Detaljer

Om utviklingssamtalen

Om utviklingssamtalen Om utviklingssamtalen NMH vektlegger i sin personalpolitiske plattform at systematisk oppfølging av den enkelte medarbeider gjennom blant annet regelmessige utviklingssamtaler er viktig. Formålet med utviklingssamtalen

Detaljer

HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT?

HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT? HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT? Felles forståelse for prosjekt som metode - en kritisk faktor for prosjektets suksess! Spesialrådgiver Bjørg Røstbø, Prosjektledersamling 20.08.08 Kompetanseutvikling

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

Referat fra Temakveld om lobbyvirksomhet 27.1.2011 Innleder: Håvard B. øvregård, leiar for Noregs Mållag

Referat fra Temakveld om lobbyvirksomhet 27.1.2011 Innleder: Håvard B. øvregård, leiar for Noregs Mållag Referat fra Temakveld om lobbyvirksomhet 27.1.2011 Innleder: Håvard B. øvregård, leiar for Noregs Mållag Definisjon lobbyvirksomhet Personers forsøk på å påvirke politikere/makthavere/beslutningstakere

Detaljer

Gode medarbeidersamtaler

Gode medarbeidersamtaler Gode medarbeidersamtaler Forberedelses- og samtaleskjema Forberedelsesskjemaet benyttes i forberedelsen til samtalen. Det skal bidra til å skape et felles utgangspunkt til at begge parter kan bidra like

Detaljer

RETNINGSLINJER FOR KONFLIKTLØSNING VED VEST-AGDER-MUSEET

RETNINGSLINJER FOR KONFLIKTLØSNING VED VEST-AGDER-MUSEET 09.05.11 RETNINGSLINJER FOR KONFLIKTLØSNING VED VEST-AGDER-MUSEET Retningslinjene er forankret i Arbeidsmiljøloven. Retningslinjene godkjennes av AMU. Retningslinjene evalueres etter at de har vært i bruk

Detaljer

Personalpolitiske retningslinjer

Personalpolitiske retningslinjer Personalpolitiske retningslinjer Vedtatt av fylkestinget juni 2004 Personalpolitiske retningslinjer. Nord-Trøndelag fylkeskommunes verdigrunnlag: Nord-Trøndelag fylkeskommune er styrt av en folkevalgt

Detaljer

Utviklingsprosjekt. Prosjektveiledning

Utviklingsprosjekt. Prosjektveiledning Utviklingsprosjekt Prosjektveiledning Juni 2011 Målsetting Utviklingsprosjektet skal bidra til utvikling både av deltakeren og hennes/hans organisasjon gjennom planlegging av et konkret endringsprosjekt

Detaljer

Prosjektplan nøkkelskinne for nøkkelhåndtering

Prosjektplan nøkkelskinne for nøkkelhåndtering Prosjektplan nøkkelskinne for nøkkelhåndtering Av Gaute Lau og Øyvind Lillenes 1 Mål og rammer 1.1 Bakgrunn Electric Time Car har gitt en oppgave som går ut på å lage og designe innmaten til en intelligent

Detaljer

Forskningsmetoder i informatikk

Forskningsmetoder i informatikk Forskningsmetoder i informatikk Forskning; Masteroppgave + Essay Forskning er fokus for Essay og Masteroppgave Forskning er ulike måter å vite / finne ut av noe på Forskning er å vise HVORDAN du vet/ har

Detaljer

Dagens IMT 1321 IT-LEDELSE. Faglærer : Tom Røise. IMT1321 IT-Ledelse 1. Faglærers bakgrunn

Dagens IMT 1321 IT-LEDELSE. Faglærer : Tom Røise. IMT1321 IT-Ledelse 1. Faglærers bakgrunn IMT 1321 IT-LEDELSE Kategori : Obligatorisk emne i studiene bachelor i Programvareutvikling bachelor i Økonomi og Ledelse Studiepoeng : 10 Info om emnet: http://www.hig.no/content/view/full/10186/language/nor-no

Detaljer

Yrkesforedrag. Yrkesforedrag

Yrkesforedrag. Yrkesforedrag Yrkesforedrag Ole Lied Yrkesforedrag Ferdig utdannet Software ingeniør i 1973 Etter militæret, Startet i Aftenposten i 1974. Jobbet med IT og IT prosjekter i forskjellige Schibsted selskaper siden. Vært

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Veiledning om tilsynets praksis vedrørende virksomhetenes målstyring (veiledning om målstyring)

Veiledning om tilsynets praksis vedrørende virksomhetenes målstyring (veiledning om målstyring) Veiledning om tilsynets praksis vedrørende virksomhetenes målstyring (veiledning om målstyring) Utgivelsesdato: 07.06.2010 1 Bakgrunn...2 2 Hensikt...2 3 Omfang...2 4 Sentrale krav...2 5 Generelt om målstyring...4

Detaljer

Prosjektmandat Prosjektmandatet forteller om:

Prosjektmandat Prosjektmandatet forteller om: Tiende gang. Et utvalg fra fagets hjemmesider NB! Case osv. er ikke tatt med Hvilke metoder og tilnærmingsmåter passer for krevende prosjekter og endringsoppgaver? Prosjekt og prosjektarbeid Et prosjekt

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

Digitaliseringsstrategi 2014-2029

Digitaliseringsstrategi 2014-2029 Digitaliseringsstrategi 2014-2029 Stavanger kommune Stavanger kommune skal gi innbyggerne og næringsliv et reelt digitalt førstevalg. Den digitale dialogen skal legge vekt på åpenhet og tilgjengelighet.

Detaljer

Outsourcing av forretningsprosesser muligheter og fallgruver

Outsourcing av forretningsprosesser muligheter og fallgruver Outsourcing av forretningsprosesser muligheter og fallgruver Norsk Arbeidslivsforum 2. mars 2006 Kurt Harald Aase Dir. Forretningsutvikling Bluegarden AS Erfaringsbakgrunn Direktør Forretningsutvikling

Detaljer

Gründercamp. Videregående opplæring. ue.no FRAMTID - SAMSPILL - SKAPERGLEDE

Gründercamp. Videregående opplæring. ue.no FRAMTID - SAMSPILL - SKAPERGLEDE Gründercamp Videregående opplæring SAMARBEID SKOLE NÆRINGSLIV Hva er Gründercamp? Idéverksted Fokus på kreativitet og nyskaping Konsentrert tidsrom og fokusert tema Fleksibelt program Oppdraget er reelt

Detaljer

IT som pådriver for prestasjonsforbedring. Åge Helgeland, IT-sjef i Petoro

IT som pådriver for prestasjonsforbedring. Åge Helgeland, IT-sjef i Petoro Åge Helgeland, IT-sjef i Petoro Kort om Petoro Den norske stat eier store andeler i olje- og gasslisensene på norsk sokkel gjennom Statens Direkte Økonomiske Engasjement (SDØE). Disse eierandelene forvaltes

Detaljer

Profesjonelt kunnskapsarbeid i en byråkratisk kontekst. Prof. Thomas Hoff Psykologisk institutt Universitetet i Oslo

Profesjonelt kunnskapsarbeid i en byråkratisk kontekst. Prof. Thomas Hoff Psykologisk institutt Universitetet i Oslo Profesjonelt kunnskapsarbeid i en byråkratisk kontekst Prof. Thomas Hoff Psykologisk institutt Universitetet i Oslo NOCM 22. september 2013 FOA seminar Prof.Dr. Thomas Hoff 3 22. september 2013 FOA seminar

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel

Detaljer

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort NCEI Teknologifrokost 25. Mars 2015 Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort Del 1: Are Hellandsvik Forsker ved SINTEF IKT Kommunikasjonssystemer Del 2: Terje Frøysa Forsker

Detaljer

Mann 21, Stian ukodet

Mann 21, Stian ukodet Mann 21, Stian ukodet Målatferd: Følge opp NAV-tiltak 1. Saksbehandleren: Hvordan gikk det, kom du deg på konsert? 2. Saksbehandleren: Du snakket om det sist gang at du... Stian: Jeg kom meg dit. 3. Saksbehandleren:

Detaljer

KommITs lederkurs i gevinstrealisering

KommITs lederkurs i gevinstrealisering KommITs lederkurs i gevinstrealisering Økonomiforum i Skien 4. juni 2015 Grete Kvernland-Berg, PA Consulting Group Liza Nienova, PA Consulting Group Plan for dagen 13:30 Introduksjon 13:50 14:20 14:30

Detaljer

KONFLIKTER OG KONFLIKTLØSING

KONFLIKTER OG KONFLIKTLØSING KONFLIKTER OG KONFLIKTLØSING Konflikt er en forutsetning for forandring Et foredrag basert på boken av Bo Ahrenfelt og Roland Berner LØS KONFLIKTENE DEFINISJONER Konflikt En situasjon der en eller flere

Detaljer

Finansportalen Historiske bankdata

Finansportalen Historiske bankdata Bilag 6: Administrative bestemmelser For Finansportalen Historiske bankdata Åpen anbudskonkurranse Bilag 6 Administrative bestemmelser Innholdsfortegnelse 1 AVTALEN PUNKT 1.9: PARTENES REPRESENTANTER...

Detaljer

Signalanlegg for nye Lervig sykehjem. Behovsavklaringer og dialog med markedet. erfaringer så langt.

Signalanlegg for nye Lervig sykehjem. Behovsavklaringer og dialog med markedet. erfaringer så langt. Smarte anskaffelser av varslingssystemer i helse og omsorg Signalanlegg for nye Lervig sykehjem. Behovsavklaringer og dialog med markedet. erfaringer så langt. Elvur Thorsteinsdottir Fagsjef anskaffelser

Detaljer

IBM3 Hva annet kan Watson?

IBM3 Hva annet kan Watson? IBM3 Hva annet kan Watson? Gruppe 3 Jimmy, Åsbjørn, Audun, Martin Kontaktperson: Martin Vangen 92 80 27 7 Innledning Kan IBM s watson bidra til å gi bankene bedre oversikt og muligheten til å bedre kunne

Detaljer

Eric Haugen, forretningsrådgiver 31.03.2014 EFFEKTIVISERING AV INNKJØPSPROSESSER

Eric Haugen, forretningsrådgiver 31.03.2014 EFFEKTIVISERING AV INNKJØPSPROSESSER Eric Haugen, forretningsrådgiver 31.03.2014 EFFEKTIVISERING AV INNKJØPSPROSESSER TEMA OG STRUKTUR Definisjoner Virksomhetenes utfordringer Spesifisering av prosjektramme EVRYs metodikk for innkjøpsprosjekter

Detaljer

Hva tilbyr HiAk? Bedriftspedagogikk og Kreativ Kommunikasjon. Innlegg på ASVLs fagkonferanse, oktober 2010, Eva Schwencke, HiAk

Hva tilbyr HiAk? Bedriftspedagogikk og Kreativ Kommunikasjon. Innlegg på ASVLs fagkonferanse, oktober 2010, Eva Schwencke, HiAk Hva tilbyr HiAk? Bedriftspedagogikk og Kreativ Kommunikasjon Innlegg på ASVLs fagkonferanse, oktober 2010,, HiAk Studium i Bedriftspedagogikk, 60 stp Ca 70 fra ASVL-bedrifter gjennomført 60 stp - Derav

Detaljer

Sentrale krav til IKT-anskaffelser. Gardermoen, 16. januar 2014 Kristian Bergem, Difi

Sentrale krav til IKT-anskaffelser. Gardermoen, 16. januar 2014 Kristian Bergem, Difi Sentrale krav til IKT-anskaffelser Gardermoen, 16. januar 2014 Kristian Bergem, Difi Poenget Det finnes en liste over anbefalte og obligatoriske IT-standarder i offentlig sektor. Alle kravspesifikasjoner

Detaljer

IDRI3001 Bacheloroppgave i Drift av datasystemer

IDRI3001 Bacheloroppgave i Drift av datasystemer IDRI3001 Bacheloroppgave i Drift av datasystemer Kjell Toft Hansen, 15.04.2015 Bachelor Informatikk Drift av datasystemer Sammendrag Her er noen studiespesifikke retningslinjer for veiledning og vurdering

Detaljer

Retningslinjer for vold, trusler og trakassering

Retningslinjer for vold, trusler og trakassering Retningslinjer for vold, trusler og ID Nfk.HMS.2.6.6 Versjon 1.00 Gyldig fra 01.02.2013 Forfatter Organisasjon- og personalseksjonen Verifisert Bjørnar Nystrand Godkjent Stig Olsen Side 1 av5 Vedtatt i

Detaljer

Utforskeren. Stille gode spørsmål

Utforskeren. Stille gode spørsmål Utforskeren Stille gode spørsmål Utforskeren 8-10 En «mal» for timene? Kognisjon og metakognisjon I praksis handler kognisjon om kunnskap (hvor mange meter er det i en kilometer), ordforståelse (hva er,

Detaljer

Om prosjektlederrollen og gruppeledelse Kull 9, 2010. Spesialrådgiver HR Helse Sør-Øst Irene Sørås

Om prosjektlederrollen og gruppeledelse Kull 9, 2010. Spesialrådgiver HR Helse Sør-Øst Irene Sørås Prosjektledelse Om prosjektlederrollen og gruppeledelse Kull 9, 2010 Spesialrådgiver HR Helse Sør-Øst Irene Sørås Tema i opplæringen Hva er et prosjekt? Noen sentrale begreper i prosjektarbeid Prosjektgruppen

Detaljer

Fra ord til handling Når resultatene teller!

Fra ord til handling Når resultatene teller! Fra ord til handling Når resultatene teller! Av Sigurd Lae, Considium Consulting Group AS Utvikling av gode ledelsesprosesser i et foretak har alltid til hensikt å sikre en resultatoppnåelse som er i samsvar

Detaljer

Lederhåndbok for spørreundersøkelser

Lederhåndbok for spørreundersøkelser Lederhåndbok for spørreundersøkelser Hva kreves av kommunen? Gjennomføring av spørreundersøkelser vil i seg selv skape forventninger, både i forhold til resultater og oppfølging. Det vil bli iverksatt

Detaljer

Kursholder. Roar Eriksen Cand. Psychol. Lade ledelse og organisasjonsutvikling ladeledelse@gmail.com Tlf 99 22 44 13

Kursholder. Roar Eriksen Cand. Psychol. Lade ledelse og organisasjonsutvikling ladeledelse@gmail.com Tlf 99 22 44 13 Kursholder Roar Eriksen Cand. Psychol Lade ledelse og organisasjonsutvikling ladeledelse@gmail.com Tlf 99 22 44 13 Oversikt - Introduksjon, mål for dagen - En kognitiv forståelsesmodell - Meg selv i samtalen

Detaljer

Skjulte egenskaper (hidden characteristics)

Skjulte egenskaper (hidden characteristics) Skjulte egenskaper (hidden characteristics) Ny klasse av situasjoner, kap. 7 i Hendrikse (Se bort fra avsnitt 7.5; ikke kjernepensum) Forskjellig fra skjult handling (hidden action) (kap. 6) Men her: Skjulte

Detaljer

Erfaringer fra offentlige anskaffelser

Erfaringer fra offentlige anskaffelser Erfaringer fra offentlige r Oddrun Lyslo Kristiansen og Bjørn Børresen 15.03.2012 20.03.2012 www.a-2.as Om A-2 Oddrun Lyslo Kristiansen, seniorkonsulent, A-2 Bjørn Børresen, seniorkonsulent, A-2 Forretningsområder

Detaljer

Byggekostnadsprogrammet. Hvordan unngå prosjekteringsfeil RESULTATER

Byggekostnadsprogrammet. Hvordan unngå prosjekteringsfeil RESULTATER Byggekostnadsprogrammet Hvordan unngå prosjekteringsfeil RESULTATER Kvalitetssjef Endre Grimsmo COWI AS 1 Målsetting Prosjektets mål er å kartlegge årsaker til prosjekteringsfeil i forskjellige typer prosjekter,

Detaljer