Systemutvikling i uforutsigbare omgivelser - FINF4001 - Forelesning 16. september Temaer: Oppsummering valg av SU-metoder Hard, myk og dialektiske perspektiver på perspektiver på SU-arbeidet Ulike perspektiver på kvalitet Organisatorisk kontekst for utvikling og bruk Hvorfor ulike metodologier Målet for et SU-prosjekt vil være svært forskjellig Konstruksjonsprosess, OU-prosess, ledelsesstyrt (politisk) prosess Egenskaper ved det ferdige system er forskjellig Eksempler: databaseløsning, beslutningssystem, nettsider, nett-basert tjeneste, osv Ulike rammebetingelsene rundt utvikling av systemet Tekniske, organisatoriske, økonomiske, juridiske,.. SU-prosjektet organiseres på ulike måter Top-down, Bottom-up, spesialist bruker styrt,.. Litteratur FINF- H -08, 16 september Arild Jansen. AFIN/UiO 1 Avison & Fitzgerald, Information Systems, Kap. 17, Dahlbom og Mathiassen kap 7 9 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 2 Ulike strategier i SU-arbeidet Hva er resultat: Et produkt eller en prosess? Overordnet strategi og metode: Analytisk (topp-styrt) vs Eksperimentell/Iterativ (prototyping) Ekspertdominert vs brukerdrevet Ensidig teknisk SU vs sosioteknisk SU Strategi for realisering Egenutvikling vs kjøp av standardsystem Leveranse/innføringsform: Revolusjonær (alt på en gang) vs evolusjonær/inkrementell (skrittvis ) Se på eksempler på etatsprosjekter Skatteetaten : Flere ulike mål: effektivitet, bedre kvalitet, gode brukertjenester Krav : Portabilitet, skalerbarhet, Interoperabilitet, Åpenhet Stor vekt på brukermedvirkning Bruker standard prosjektstyringsmetode - kvalitetsikring Lånekassen Mål: Effektivitet, brukervennlighet, sikker Krav: Nettbasert løsning, gjenbruk av kundedata, automatiserte kontroller Problemer med sikkerhetsløsning Kjørte pilot-løsning med utvalget brukergrupper FINF- H -08, 16 september Arild Jansen. AFIN/UiO 3 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 4 1
Samordna opptak Langsiktig, fasedrevet utviklingsprosjekt Fase 1 : Utvikling av (rent) informasjonssystem Fase 2 : Pilotprosjekter basert på ny modell (utvalgte utdanninger) Nødvendig med betydelige regelverksendringer Fase 3 : Felles nasjonalt samordnet opptak Store organisatoriske endringer Nye Regeleverksendringer Fase 4 : Nettbasert søknads- og svar registrering (søkerveven) Fase 5: Kompetansereformen Automatisert saksbehandling ved elektronisk vitemål Kvalitetsreformen Mange nye studier.. FINF- H -08, 16 september Arild Jansen. AFIN/UiO 5 Om Standard-avtaler for prosjektstyring Om PS 2000 http://dataforeningen.no/?module=articles;action=articlefold er.publicopenfolder;id=747/ Se forelesningen i IN 1050 : http://www.uio.no/studier/emner/matnat/ifi/inf105 0/v08/undervisningsplan.xml FINF- H -08, 16 september Arild Jansen. AFIN/UiO 6 D&M, kap. 4-6 Ulike tilnærminger i utviklingsarbeidet Tre ulike tilnærmingsmåter for systemutvikling: Konstruksjon = Hard systemtenkning Antar verden er stabil og problemområdet veldefinert En rasjonell, analytisk topp-down framgangs-måte, Evolusjon = Myk systemtenkning Realistisk, helhetlig virkelighetsforståelse, usikkerhet og at problemene er upresist. Anvender eksperimentell strategi for systemløsning Bruker-orientering, prosessorientering og læring Intervensjon = dialektisk systemtenkning Problemet er ikke (klart) definert Utviklingsarbeidet kan ikke skilles fra løpende aktiviteter i organisasjonen Myk system tenkning Bygger på at det finnes flere likeverdige perspektiver på verden Vi må hanskes med en verden som har stor variasjonsrikdom og er i kontinuerlig forandring Verden er slik vi oppfatter den - som et resultat av våre erfaringer, holdninger og visjoner Ulike antagelser, erfaringer innebærer ulike system perspektiver Vi kan alltid endre (forbedre) systemer gjennom ny erfaringer, kunnskap og kompetanse Vi trenger en metodologi hvor vi kan forstå ulike perspektiver: Fortolkninger Et mykt system er totaliteten av perspektiver med egenskaper som er i stadig endringer FINF- H -08, 16 september Arild Jansen. AFIN/UiO 7 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 8 2
Dialektisk system tenkning - 1 Verden er i endring som skyldes motsetninger Motsetninger gir muligheter til å forstå, forklare og kontrollere endringer Motsetninger skyldes interessekonflikter, både reelle og skinnkonflikter i den virkelige verden ( f eks. forhold ledelse-ansatt, sentralt - lokalt,, mellom ulike brukere, Konflikter kan f eks. knyttes til ulike tekniske eller organisatoriske løsninger (f eks standarder versus variasjon) Vi må akseptere konflikter som grunnlag for design Konfliktene er grunnleggende og vil føre til stadige endringer - lar seg ikke løse men må forstås og håndteres. Dialektisk system tilnærming - 2 Metodologiske implikasjoner Nødvendig med en rik virkelighetsbeskrivelse Fokus på forholdet mellom virkeligheten og de ulike parters oppfatning av denne. Analysere ulike interesser, roller,strukturer og prosesser Fokus på handlinger som basis for å håndtere konflikter (design is action) som vil kunne bidra til prosesser som resulterer i løsninger Løsninger vil ha kortere eller lengre levetid, kunne fungere en periode av kortere eller lengre varighet ( midlertidige løsninger) En dialektisk systemtilnærming er både hard og myk: men organisatoriske aktører overseer ofte grunnleggende konflikter Motsetninger må håndteres gjennom handlinger som endrer organisasjoner (mange motsetninger kan ikke løses) FINF- H -08, 16 september Arild Jansen. AFIN/UiO 9 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 10 Eksempel for diskusjon Oppgave: Utvikle en felles elektronisk pasientjournal (EPJ) som kan brukes for alle pasientgrupper Tre alternative antakelser i prosjektet 1. Vi antar at krav kan spesifiseres rimelig fullstendig i starten av prosjektet 2. Vi antar at det er en rekke behov vi ikke kan definere i den første analysefasen, men som kan avdekkes gjennom prototyping og andre former eksperimentering med mer 3. Vi antar at det er en del grunnleggende forskjeller mellom de ulike pasientgrupper og medisinske fagmiljøer, og det er [foreløpig] uklart i hvilken grad det er mulig å lage et felles EPJ, og det er i beste fall en lang prosess Hvilke ulike tilnærminger krever disse tre situasjoner? Utviklingsarbeidet som Evolusjon Tar utgangspunkt i : Realistisk og helhetlig problemforståelse Omgivelsene er dynamiske og uforutsigbare Flere mulige framgangsmåter Prototyping fram for fullstendige kravspesifikasjoner: Prøving og feiling - usikkerhet Bottom-up-tilnærming Brukerorientering - brukerdeltagelse Vekt på prosessorientering og læring Men også Mindre vekt på planlegging og utforming Mer vekt på prosjektledelse - samarbeid og koordinering Skrittvis utprøving og tilpasning av løsningen FINF- H -08, 16 september Arild Jansen. AFIN/UiO 11 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 12 3
Utgangspunkt Utviklingsarbeidet som Intervensjon Problemforståelsen springer ut fra situasjoner eller (uventede) hendelser Problemområdet som datasystemet skal løse (understøtte) er uavklart Forståelse av ulike holdninger, roller og preferanser er viktige faktorer i utviklingsarbeidet Verden er full av motsigelser Brukerne er irrasjonelle, data er inkonsistente og organisasjoner er uforutsigbare Forberedt på at forandringer skjer løpende Forberedt å at systemer ikke [alltid] fungerer [biler], skriver, kopimaskin, PC,.. 3 nivåer av organisatorisk praksis 1. Formelle rutiner og prosedyrer 2. Oppfatningene blant de ansatte av hvordan arbeidet bør gjøres, dvs tolkningen/forståelsen av rutiner og prosedyrer 3. Det faktiske adferden de har i arbeidet, den rotfestede praksis som utvikles over lang tid) For å endre organisatorisk praksis må alle 3 nivåene håndteres (ikke bare den formelle) FINF- H -08, 16 september Arild Jansen. AFIN/UiO 13 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 14 Strategi Utviklingsarbeidet som Intervensjon - Gjennombrudd ved sammenbrudd - ved at motsetningene blir synlige og kan håndteres Forståelse gjennom bruk av metaforer ( lignelser )- som skal stimulere kreativiteten Systemutvikling endrer ofte karakter av organisasjons-utviklingsprosesser fordi systemet ikke kan løse problemet (alene) Systemutvikler må delta i organisasjonsspill Vekt på systemkvalitet i bruk - og hva dette i praksis betyr Intervensjonstenkningen skal ikke erstatte supplere de øvrige tenkemåtene. Kvalitet Kvalitet og kvalitetssikring (1) Et systems evne til å tilfredsstille de krav og forventninger og ønsker (2) Grad av systemets overensstemmelse med med skriftlige spesifikasjoner (3) Forholdet mellom forventet og opplevd ytelse av et system Opplevd kvalitet: subjektiv vurdering av den enkelte bruker eller aktør som er involvert Kvalitetssikring (engelsk Quality Assurance, QA) Arbeidet med planlegging, utforming, vedlikehold og kontroll som tar sikte på øke eller sikre kvaliteten av et produkt eller en prosess. FINF- H -08, 16 september Arild Jansen. AFIN/UiO 15 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 16 4
Hva er kvalitet - 1 Datakvalitet = kvaliteten på dataene (informasjonen) korrekthet, nøyaktighet, relevant, a jour, fullstendig,.integritet,.. Systemkvalitet = kvalitetene på de systemene som behandler dataene: Effektivitet, funksjonalitet, brukervennlighet, driftsikkerhet, sikring, fleksibilitet, flyttbarhet, vedlikeholdbarhet, testbarhet,... Prosesskvalitet = kvaliteten på de prosesser (aktiviteter, handlinger ) som leder fram til et gitt resultat Holde tidsfristen og økonomiske rammer, følge fastsatte lover, regler og forskrifter, fastlagte prosedyrer og krav,.. Hvordan måle datakvalitet Datakvalitet gjelder krav til innholdet og måles gjerne ut fra blant annet disse kriterier Korrekthet, nøyaktighet, relevante, oppdatert, fullstendige, integritet (helhetlige), konfidensialitet (beskyttelse) Andre krav som også gjelder systemene rundt Tilgjengelighet, brukervennlige Oppfylle Personopplysningsloven, Forvaltningsloven,.. Brukere og tilbydere vil kunne ulike ha oppfatninger om kvalitetskravene FINF- H -08, 16 september Arild Jansen. AFIN/UiO 17 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 18 Hvordan måle systemkvalitet Vi kan angi noen ulike typer krav til systemkvalitet Krav ved bruk av programvaren Effektivitet, funksjonalitet, brukervennlig, enkelt å lære, Tekniske krav til programvaren Driftsikker, sikkert, fleksibilitet, flyttbar, enkelt å vedlikeholde, testbarhet, kapasitet, modularitet, konsistens Krav til omgivelsene Sikkerhet, integrasjon med annen programvare, stabilitet Problem: Brukere og systemutviklere har ofte ulike oppfatninger om kvalitet Objektive eller subjektive kvalitetskrav Objektive krav Funksjonskrav Ytelseskrav Tekniske krav... Subjektive Bruksmessige krav Estetiske krav Symbolske krav... Nødvendig å utvikle metoder for å evaluere alle typer kvaliteter, basert på krav & preferanser fra ulike brukermiljøer. FINF- H -08, 16 september Arild Jansen. AFIN/UiO 19 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 20 5
Prosesskvalitet: Kvalitet i utviklingsarbeidet Dette gjelder kvaliteten på de aktiviteter/handlinger som inngår i arbeidet med å produsere resultatet Overholde tidsfrister, Ressursforbruk : Ligge innenfor økonomiske rammer, Følge relevante lover, regler og forskrifter, Fastlagte prosedyrer og krav (f eks. ISO 9000) Sikre gode arbeidsmiljø,.. Problem: Her vil det kunne være interessekonflikter mellom ulike parter Måling eller evaluering av kvalitet Evaluering i henhold til kravspesifikasjoner Hva er det brukerne har bedt om? Evaluering basert på mål (metrikker), f eks. mål for effektivitet, stabilitet, vedlikehold,.. Formelle metodikker for å bevise korrekthet Slike mål tilstreber objektivitet,uavhengig av den som som evaluerer Evaluering søker å avdekke alle sider ved en artefakt som ansees å være viktig for brukeren Evaluering av kvalitet basert på brukeres opplevde egenskaper Utprøving gjennom f eks. eksperimentering og prototyping for å få fram hva er det brukerne virkelig ønsker /forventer Evaluering i henhold til systemets plass/rolle i organisasjonen Dette er basert på subjektiv kompetanse, erfaringer og intuisjon FINF- H -08, 16 september Arild Jansen. AFIN/UiO 21 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 22 Noen problem med kvalitet og kvalitetssikring Ulike parter har ulike oppfatninger om kvalitetskrav og dere prioritet Eks: funksjonalitet versus brukervennlighet Ulike kvalitetskrav er ofte ikke helt forenlige Eks: brukervennlighet versus sikkerhet Ikke alle brukerkrav lar seg enkelt måle Kvalitet koster resurser (og tar mer tid?) Vi mennesker opplever systemer forskjellig egenskaper som vises seg i praksis å være viktige, også estetiske og symbolske Omgivelsene påvirker oppfatninger om kvalitet Funksjonelle, estetiske og symbolsk egenskaper Teknologi som funksjon: hvordan de fungerer i praksis Oppfyller forventninger i bestemte bruksmessig sammenheng - i en gitt virkelighet Teknologi har også estetiske egenskaper - Utseende, arkitektonisk, visuelt inntrykk, Uavhengig av andre egenskaper : Må oppleves - erfares Teknologi som symbolsk uttrykksform Formidler kulturelle verdier i en organisasjon Kjøp av siste duppeditter for å framstå som moderne Teknologiens politiske innhold som bærer av verdier knyttet til f eks. demokrati makt, likestilling, likeverd Eks. hvem som brukes i reklame (fargerikt fellesskap) Datamaskinen og fargete i reklamen i USA Ny teknologi og eldre, kvinner i Norge FINF- H -08, 16 september Arild Jansen. AFIN/UiO 23 FINF- H -08, 16 september Arild Jansen. AFIN/UiO 24 6