UKE 14 Versjonshåndtering og testing Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski
UKENE FREMOVER OBS! Ikke forelesning 17. mai ikke gruppetime 19. og 23. mai Felles gruppetime for alle fredag 26. mai gjennomgang av prøveeksamen + tips og triks
Hva skal vi i dag? Versjonshåndtering og testing (kapittel 8 og 25) Ukesoppgaver 5: testing (del 1) og konfigurasjonsstyring (del 2)
TESTING Kompetansemål - Testing av programvare - Hva og hvorfor? - Testfaser - Ulike nivåer - Testtyper - Spesifikasjonsbasert testing/strukturbasert testing - Testdrevet utvikling
BAKGRUNN FOR TESTING Hva er testing? Hvorfor er testing viktig? De syv testprinsippene
TESTING: hva og hvorfor? - Testing utforsker et system/systemkomponenter for å avdekke feil eller mangler - Nødvendig for kvalitetssikring av et system - Sørge for at systemet som bygges holder høy standard Etablere gode kunderelasjoner - Påser at systemet innfrir funksjonelle og ikke-funksjonelle krav - Forsikre seg om at man har laget det man skal lage, og på en god måte - Økonomisk gevinst - Avdekking av feil under utvikling er ofte rimeligere enn når systemet er tatt i bruk - Et svært viktig tema i systemutvikling
TESTING: de syv testprinsippene 1. Testing viser feil - Testing kan bare vise at feil/defekter eksisterer - Testing kan ikke bevise at et program er feilfritt 2. Fullstendig testing er umulig - Det er umulig å teste alt - Kan ikke teste alle mulige kombinasjoner mellom input og betingelser 3. Tidlig testing - Testing bør starte så tidlig som mulig i utviklingsprosessen - Testinnsatsen bør fokuseres på tydelig definerte mål
TESTING: de syv testprinsippene 4. Konsentrasjon av feil - Et samlet mindretall av komponenter/moduler inneholder de fleste feilene - Feil er ikke jevnt fordelt i kildekoden - Noen komponenter er mer komplekse å utvikle enn andre - Enkelte utviklere kan være mindre kompetente og dermed produsere flere feil 5. Plantevernmiddelparadokset - Hvis de samme testene kjøres hver gang, vil de til slutt ikke finne flere feil - Tester bør oppdateres og tilpasses jevnlig - Nye tester bør inkluderes ved behov - Øker sannsynligheten for å oppdage ytterligere feil i systemet
TESTING: de syv testprinsippene 6. Testing er kontekstavhengig - Testinnsatsen avhenger av konteksten - Ulike systemer bør testes på ulike måter Testfokus varierer fra system til system. Eksempelvis kan ikke sikkerhetskritiske system testes på samme måte som trivielle spill 7. Fravær av feil -fellen - Et feilfritt system er ikke nødvendigvis et brukbart system - Validering versus verifisering Bygger vi det riktige produktet? Bygger vi produktet riktig?
KONFIGURASJONSSTYRING Kompetansemål - Konfigurasjonsstyring - Hva og hvorfor? - I en smidig sammenheng - Endringshåndtering - Versjonhåndtering - Systembygging - Release -håndtering
BAKGRUNN FOR KONFIGURASJONSSTYRING Hva? Hvorfor? Ulike aktiviteter
KONFIGURASJONSSTYRING: hva? - Output fra en systemutviklingsprosess kan deles inn i tre kategorier
KONFIGURASJONSSTYRING: hva? - Konfigurasjon: samling av alle komponenter som inngår i et system - Hver komponent representeres med en versjon - Konfigurasjonsstyring: Software Configuration Management (SCM) - Aktiviteter, prosesser og verktøy: - Håndtere endringer i programvaresystemer gjennom hele utviklingsprosessen - Spore endringer som gjøres - Systematisk kontroll over utviklingsprosessen og det som utvikles
KONFIGURASJONSSTYRING: hvorfor? - Programvaresystemer er i konstant endring - Systemer og kode kan bli veldig komplekse - Lett å miste oversikten over endringer/versjoner av komponenter - Varierer fra versjon til versjon - Ønsker å ha kontroll over endringer - Hva ble endret? Hvem har endret hva? - Bringer kontroll over systemutviklingsprosessen! - Forenkler teamarbeid/koordinering - Unngå endringsrelaterte problemer - Vil feks. spille en sentral rolle for å sikre kvalitet
KONFIGURASJONSSTYRING: aktiviteter
KONFIGURASJONSSTYRING: aktiviteter - Endringshåndtering (Change Management) - Oversikt over endringer fra kunde/utviklere >> Change Request Form - Kostnadsestimering og virkning (fordeler, ulemper) av foreslåtte endringer - Slutninger om hvorvidt foreslåtte endringer skal implementeres - Versjonhåndtering (Version Management) - Oversikt over ulike versjoner av system og systemkomponenter - Sørge for at endringer fra ulike utviklere ikke kolliderer med hverandre >> Git
KONFIGURASJONSSTYRING: aktiviteter - Systembygging (System Building) - Setter sammen systemkomponentene - programvare, data, biblioteker - Kompilering og integrering - Skaper et fullstendig (kjørbart) system - Release-håndtering (Release Management) - Forberede/ferdigstille programvare for ekstern utgivelse (release) - Oversikt over ulike versjoner av systemet som har blitt gitt til kunden
KONFIGURASJONSSTYRING: forholdet til smidig utvikling - Systemer/komponenter endres flere ganger daglig - Hyppig bygging og testing av programvare - Selvstyrte team med mye frihet - Kunden er i stor grad involvert i endringshåndtering - Pågående kommunikasjon om hva som har blitt gjort/skal gjøres - Håndtering av endringer er tilnærmet umulig uten konfigurasjonsstyring
UKESOPPGAVER
SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.
SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil. Svar:
SPØRSMÅL 1a Spørsmål: Testing viser feil som oppdages under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil. Svar: Kun fordi det ikke oppdages, betyr det ikke at feil ikke finnes. - Å bevise et negativ: Kan man bevise at julenissen ikke eksisterer? - Hvordan vite det man ikke vet? - Tester kan være skrevet av utviklere - Tunnelsyn: Fokuserer bare på det man forventer av feil - Utfordrende å sette seg fullt inn i brukerens perspektiv - Tester kan være skrevet feil/inneholde mangler
SPØRSMÅL 1b Spørsmål: Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden.
SPØRSMÅL 1b Spørsmål: Forklar hvorfor det ikke er nødvendig for et program å være fullstendig feilfritt før det overleveres til kunden. Svar: - Enkelte feil kan aksepteres/ignoreres - De fleste programmer er ikke så kritiske at de ikke kan inneholde feil - Feil i systemet betyr ikke nødvendigvis at systemet er ubrukelig - Det kan være feil i områder brukeren aldri oppdager - Økonomisk motivasjon - Som regel lite lønnsomt å avdekke/rette opp alle feilene før release
SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode.
SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: FORDELER - Ressursbesparende: redusert tid og reduserte kostnader - Unødvendig at eksterne team skal finne feil utviklere selv kan finne - Desto mindre kode, desto lettere er testingen - utviklere kan derfor delta i testinnsatsen tidlig i utviklingsprosessen ULEMPER - Testing og utvikling er to forskjellige grener - Testere og utviklere har derfor helt ulike utgangspunkt - Hvordan kan jeg lage det? vs. hvordan kan jeg ødelegge det?
SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: Flere ulemper: - Vanskelig å skille mellom hvordan det virker og hvordan det skal virke - Utviklere kan se seg blinde på egen kode - Utviklere har ofte en formening om hvor feilene ligger, og fokuserer ensidig på disse - Kan være vanskelig å løsrive seg fra utviklermentaliteten - Utviklere er ikke nødvendigvis kompetente testere
SPØRSMÅL 2 Spørsmål: Diskuter fordeler og ulemper med at utviklere selv tester sin egen kode. Svar: Løsningen på utviklerens rolle: bruk eksterne testere/team til å gjennomføre testingen - Interne eller eksterne testere? - Testing er en vurdering av kvalitet - Interne testere kan oppleve det som vanskelig å poengtere medarbeideres feil - Eksterne testere/testteam - Eksterne testere kan ofte se (andre) feil/mangler som utviklere ikke oppdager - Kommer inn med andre antakelser og forutsetninger enn utviklerne - Eksterne testere nyter ofte mer troverdighet hos organisasjonen/ledelsen - Kan uttrykke feil på en ærlig og kritisk måte
SPØRSMÅL 3 Spørsmål: Hva er regresjonstesting? Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting.
SPØRSMÅL 3 Spørsmål del 1: Hva er regresjonstesting? Svar: Regresjonstesting er testing relatert til endringer - Når? Etter at kildekoden/systemet har blitt endret - Mål Avdekke eventuelle feil som har blitt introdusert i kildekoden etter endring Konsekvensanalyse gjennomføres i forkant - Kartlegger deler av kildekoden som har stor sannsynlighet for å bli påvirket
SPØRSMÅL 3 Spørsmål del 1: Hva er regresjonstesting? Svar: Teknikker for regresjonstesting - Test alt (full regresjonstest) - Test utvalg - Prioriter tester - Kombinasjon av disse Regresjonstester og konfirmasjonstester er ikke det samme! - Konfirmasjonstester skal bekrefte at eventuelle feil er blitt rettet opp
SPØRSMÅL 3 Spørsmål del 2: Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting. Svar: Automatiserte tester og rammeverk er: - Bruk av programvare/verktøy for å gjennomføre testing - Tester kildekode om og om igjen, uten at dette må gjøres manuelt Hvorfor? - Testinnsatsen kan være tidkrevende, kostbar, og ikke minst repetitiv - Umulig å dekke testbehovet manuelt (spesielt for større systemer) - Programvare og rammeverk forenkler testinnsatsen - Kan overlate testingen til automatiserte prosesser
SPØRSMÅL 3 Spørsmål del 2: Forklar hvorfor bruk av automatiserte tester og rammeverk forenkler regresjonstesting. Fordeler: - Tester utføres på nøyaktig samme måte som tidligere - Umiddelbar sammenligning av forventet og faktisk utfall av testene - Økt testomfang - Ressursbesparende Tid/Innsats/Penger - Kan mate verktøyet med data - Mange ulike kombinasjoner av input og betingelser - Kan la programvaren, og ikke menneskene, gjøre jobben - Slipper å teste 100, eller 1000 kombinasjoner for hånd! - Kan lage samlinger av ulike (regresjons)tester - Kan kjøre flere (regresjons)tester etter hverandre
SPØRSMÅL 4a Spørsmål: Hva forstår du med begrepet stresstesting?
SPØRSMÅL 4a Spørsmål: Hva forstår du med begrepet stresstesting? Svar: Stresstesting Stresse systemet under test - Kartlegge systemets stabilitetsegenskaper - Avdekke antall transaksjoner/operasjoner et system er i stand til å takle - Fremprovosere systemkollaps Hensikt: - Eksponere breaking points - Avdekke kapasitet i henhold til systemkrav og spesifikasjon - Avdekke hvordan systemet håndterer kollaps
SPØRSMÅL 4b Spørsmål: Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter.
SPØRSMÅL 4b Spørsmål: Foreslå hvordan du vil stressteste et minibanksystem der det er mulig å sjekke saldo på konto og ta ut kontanter. Svar: Fremgangsmåte: - La minibanksystemet utføre mange transaksjoner samtidig - Sjekk deretter om alle transaksjoner ble behandlet korrekt - Redegjør for hvorvidt systemet taklet stresset/hvordan? - Utvid stresstesten til systemet krasjer/tilfredsstiller spesifikasjonen
SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest?
SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Man har først og fremst ulike testnivåer: - Testing av programvare er en omfattende prosess Bør stykkes opp - Man kan (bør) ikke teste alt på en gang - Testing bør starte så tidlig som mulig - Hvordan? - Det er begrenset hvor mye man kan teste tidlig i utviklingsfasen - Testing deles ofte opp i ulike testnivåer: enhetstesting, integrasjonstesting, systemtesting og akseptansetesting - Hvert nivå er tydelig definert med tanke på formål og aktiviteter
SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Enhetstesting tester individuelle enheter/komponenter (kildekode) - Eksempel: Enheter i programmering som klasser eller metoder - Enheten testes isolert fra resten av systemet - Gjennomføres ofte tidlig i utviklingen/testingen Formål: - Forsikre seg om at enheten gjør akkurat som den skal - Uavhengig av samspill med øvrige komponenter
SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Karakteristikker for god enhetstesting: - Isolasjon - Testene til en klasse X avhenger ikke av å ha implementert andre klasser - Testene i en klasse X skal ikke feile på grunn av feil i øvrige klasser - Uavhengighet - Hver enhetstest skal være selvforsynt - Skal virke uavhengig av andre enhetstester som kjøres - Enkelhet - En enhetstest = ett scenario
SPØRSMÅL 5 Spørsmål: Hva er forskjellen på enhetstest og integrasjonstest? Svar: Integrasjonstesting - Sammensetning av flere enkeltstående enheter til komponenter - Tester disse komponentene sammen - Avdekker hvordan komponentene interagerer med hverandre
SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing?
SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing? Svar: Blackbox-testing = spesifikasjonsbasert testing - Tester funksjonaliteten til en komponent i henhold til spesifikasjonen - Hva skal komponenten gjøre? Gjør den det? - Ikke fokus på underliggende intern struktur/logikk
SPØRSMÅL 6a Spørsmål: Hva er forskjellen på blackbox- og whitebox-testing? Svar: Whitebox-testing = strukturbasert testing - Tester den interne strukturen til et system - Hvordan realiseres funksjonaliteten? Hvilken logikk ligger i grunn? - Inspisere kildekoden - Brukes ofte for å måle dekningsgrad av testene Hvor mye har vi testet?
SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Fordeler Blackbox-testing: - Krever ikke teknisk kompetanse - Enkelte tester kan gjennomføres av ulike brukergrupper - Planlegging av testinnsatsen kan starte tidlig - Vi vet hva systemet skal gjøre - Kan bruke uavhengige testere (ikke involvert i utviklingen) - Resultater kan tolkes uten kjennskap til systemets interne strukturer - Finner krav som ikke er implementert riktig/mangler
SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Ulemper Blackbox-testing: - Usikkerhet rundt hvor mye/hvilke deler av systemet som er testet - Vet ikke hva som forårsaker problemet - Hvor i kildekoden ligger feilen? Hva trigget feilen? - Vanskelig å utforme tester uten en tydelig kravspesifikasjon - Tester kan vise seg å være redundante (overflødige) - Utviklere har allerede kjørt tilsvarende tester
SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Fordeler Whitebox-testing: - Kan utføres tidlig i systemutviklingsprosessen - Trenger ikke vente på at grensesnittet skal lages - Ser nærmere på underliggende logikk/struktur i koden - Optimalisering av kode/fjerne unødvendige kodelinjer - Grundigere analyse av hva som forårsaker eventuelle problemer - Kartlegger data/input som mest effektivt tester programmet - Utviklere må begrunne kode/beslutninger rundt implementasjon
SPØRSMÅL 6b Spørsmål: Forklar fordeler og ulemper med hver av teknikkene. Svar: Ulemper Whitebox-testing: - Krever teknisk kompetanse - Programmerings- og testeferdigheter - Bør være ekspert og allerede ha kjennskap til koden - Krever tid og tilgang til kildekoden - Utfordrende å gjennomføre hvis implementasjonen endres hyppig - Finner ikke krav eller mangler som ikke er implementert
SPØRSMÅL 7 Spørsmål: Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting.
SPØRSMÅL 7 Spørsmål: Foreslå testcases for use caset ta ut penger. Ta for deg enhetstesting og integrasjonstesting. Svar: Enhetstester Blir PIN-koden validert korrekt? Blir kortet godkjent korrekt? Blir kortet returnert korrekt? Integrasjonstester Henter man saldo fra rett konto? Trekkes korrekt beløp fra rett konto? Blir saldo oppdatert korrekt etter uttak?
SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing?
SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing? Svar: Forskjell på hvilke system-aspekter man tester - Funksjonell testing - HVA systemet gjør - Tester hvorvidt de funksjonelle kravene fra systemspesifikasjonen innfris - Ikke-funksjonell testing - HVORDAN systemet virker - Tester ikke-funksjonelle krav Kvalitetsattributter (brukervennlighet, effektivitet) - Samlet testinnsats øker produktkvaliteten
SPØRSMÅL 8 Spørsmål: Hvorfor er det viktig å utføre både funksjonell og ikke-funksjonell testing? Validering Bygger vi det riktige produktet? Programvaren gjør det brukerne virkelig ønsker seg Fokus på hele systemet Verifisering Bygger vi produktet riktig? Stemmer det med kravspesifikasjonen? Fokus på komponenter / delsystemer
SPØRSMÅL 9 Spørsmål: Hvorfor er det viktig å utføre vedlikeholdstesting?
SPØRSMÅL 9 Spørsmål: Hvorfor er det viktig å utføre vedlikeholdstesting? Svar: Vedlikeholdstesting = testing etter at systemet er tatt i bruk - Vanlig med endringer i et system - Korrigeringer/utvidelser/øvrige forandringer - Plattformer endres eller fjernes - Avdekker om vedlikehold har introdusert nye feil/mangler - Først: Kjør tester for endringene som ble utført - Deretter: Kjør regresjonstest for systemet
SPØRSMÅL 1 (fra konfigurasjonsstyring) Spørsmål: Foreslå 3-5 mulige problemer som kan oppstå hvis et softwareselskap ikke bruker effektive styringsverktøy og prosesser (policies).
SPØRSMÅL 1 (fra konfigurasjonsstyring) Spørsmål: Foreslå 3-5 mulige problemer som kan oppstå hvis et softwareselskap ikke bruker effektive styringsverktøy og prosesser (policies). Svar: - Begrenset oversikt over - Systemets tilstand - Utviklingsprosessen - Mangel på oversikt over endringer - Kildekode/krav - Svekket dokumentasjon - Tilnærmet umulig å gjenskape eldre (tidligere) versjoner av systemet
SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching.
SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Codeline = sekvens av versjoner av en programvarekomponent (kildekode) - Senere versjoner i sekvensen er utledet av tidligere versjoner
SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Baseline = beskrivelse av en samling av komponenter som utgjør et system - Spesifiserer codeline-versjonene som er inkludert i systemet - Definerer øvrige komponenter (og versjoner) inkludert i systemet - Biblioteker, konfigurasjonsfiler, øvrig dokumentasjon - Kan gjenskape komplette og spesifikke versjoner av et system - Viktig funksjonalitet - Nødvendig dersom kunden rapporterer om feil
SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Versjon = et tilfelle av en konfigurasjon - Skiller seg fra andre tilfeller av samme konfigurasjon - Har en unik identifikator - Konfigurasjonsnavn + versjonsnummer Release = versjon av et system overført til kunden, klar for bruk
SPØRSMÅL 2 Spørsmål: Forklar følgende begrep innen konfigurasjonsstyring og versjonhåndtering: Codeline, Baseline, Versjon, Release og Branching. Svar: Branching = forgrening av codelines - Opprettelse av nye codelines fra eksisterende codelines - Kan ha flere uavhengige sekvenser av versjoner - Vanlig scenario: utviklere jobber med ulike versjoner av kildekoden - Til slutt blir det nødvendig å flette sammen (merge) codeline-grenene - Lager ny komponentversjon som inneholder alle endringer
SPØRSMÅL 3 Spørsmål: Hva er et repository? Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering.
SPØRSMÅL 3 Spørsmål del 1: Hva er et repository? Svar: Lagringsplass for kildekode/programvarekomponenter - Verktøy for versjonhåndtering - Oversikt over endringer som utføres - Kan være - Sentraliserte - Distribuerte
SPØRSMÅL 3 Spørsmål del 2: Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Svar: Sentraliserte systemer - Det finnes én kopi av systemet Master repository, ligger på en server - Utviklere sjekker ut komponenter fra master repository, over på eget arbeidsområde - Etter at endringer er utført sjekkes komponentene inn igjen gjennom commit - Commit Registrere endringen i det sentrale systemet - Andre utviklere kan nå se denne endringen - Ikke nødvendig å lagre mange kopier av filer på privat arbeidsområde
SPØRSMÅL 3 Spørsmål del 2: Forklar forskjellen på sentraliserte og distribuerte systemer for versjonhåndtering. Svar: Distribuerte systemer - Master repository ligger på en server - Utviklere laster ned (pull) en klone til privat arbeidsområde - Har nå tilgang til hele historien på egen maskin Data + metadata - Endringer blir oppdatert privat gjennom commit - Endringer oppdateres globalt ved push til master repository - Git er et eksempel på dette
SPØRSMÅL 4 Spørsmål: Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter?
SPØRSMÅL 4 Spørsmål: Hvilke problemer kan oppstå når to utviklere samtidig gjør endringer i tre programvarekomponenter? Svar: En utvikler endrer en funksjon som en annen utvikler er avhengig av Oppstå feil Endringer som ikke er kompatible
SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke.
SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Svar: Sentral aktivitet inngår i endringshåndtering - Ønskede endringer presenteres gjennom et Change Request Form - Avgjør om foreslåtte endringer er gyldige/gjennomførbare - Husk: Ikke alle endringer er nødvendige å gjennomføre! - Analyseres i lys av kostnader og gevinst - Prioriterer de viktigste og mest kostnadseffektive endringene
SPØRSMÅL 5 Spørsmål: Diskuter faktorer som innvirker på om en endring skal implementeres eller ikke. Svar: Faktorer i en endringsanalyse: - Konsekvenser - Hva skjer dersom foreslåtte endringer ikke følges opp/utføres? - Fordeler/gevinst av foreslåtte endringer - Brukere - Hvem, og hvor mange, berøres av de foreslåtte endringene? - Kostnader knyttet til implementasjon av endringene
Neste uke Teamarbeid og smidige prinsipper, kapittel 22 og 23.1-23.3