Evaluering av It-systemer i et forvaltningsperspektiv. Drift, vedlikehold og videreutvikling av IT-systemet

Transkript

1 Evaluering av It-systemer i et forvaltningsperspektiv Drift, vedlikehold og videreutvikling av IT-systemet

2 Bakgrunnen IT-systemer har ofte lenger levetid enn forventet er ofte forretningskritiske utvikler seg i hele brukstiden med mange endringer over mange år Ingen er lenger helt kjent med hvordan systemet fungerer Å fase ut et gammelt system kan derfor være risikofylt Derfor er det viktig at systemet er lett å forvalte

3 Hvorfor endringer etter levering? Forandring er nødvendig fordi: Nye behov oppstår Organisasjonen gjennomgår forandringer Det er behov for å rette feil som oppdages Det er nødvendig å forbedre ytelsen Organisasjonen er avhengig av systemet Systemet representerer store verdier som vil gå tapt uten vedlikehold

4 Risiko ved utfasing og fjerning Spesifikasjon er mangelfull eller gått tapt System og forretningsvirksomhet er en helhet Forretningsregler er innebygd i systemet og ikke dokumentert på annen måte Systemet kan være integrert mot andre systemer

5 Utfordringen ved forvaltning av systemer over lang tid Mange har deltatt lite konsistens Ofte laget i gamle programmeringsspråk som få behersker i dag. (Cobol år 2000) Ofte lite systemdokumentasjon utenom kildekoden Vedlikeholdet har ødelagt strukturen i systemet Data er lagret i filer med ulik struktur ofte dobbeltlagring

6 Dilemmaene Lang og fortsatt bruk av systemer gir økte vedlikeholdskostnader Dyrt og risikabelt å erstatte et gammelt system med et nytt Kan det gjøres noe gjøres for å utvide levetiden til systemet og redusere kostnaden ved å drifte det videre? Når er nok nok?

7 Struktur i et gammelt system Ofte mer enn bare programvare deler av virksomheten er deler av systemet Programvare Maskinvare Data Forretningsprosesser Forretningsregler Leverandørtilpasset Ledelsestilpasset Strategitilpasset Lover og regler er implementert i systemet

8 Vanlig utvikling av tidligere applikasjoner Startet med ett program Utvidet med flere programmer som kan dele data med de tidligere Programmene er ikke konsistente DBMS kan være foreldet eller ikke lenger kompatibel Fra hierarkisk DB til relasjonsdb, nettverksdb

9 Vedlikehold Alle endringer av systemet etter det er installert i et driftsmiljø Endringer mens programmets grunnleggende struktur ligger fast Vedlikehold er nødvendig fordi virkeligheten og omgivelsene endrer seg hele tiden Brukerne spesifiserer ikke alt de ønsker. Når systemet er ferdig kan spesifikasjonen ha behov for endringer Et system uten vedlikehold eldes raskt

10 Vedlikehold av programvare Endringer Liten: Retting av kodefeil Større: Retting av utformingsfeil Størst: Retting av spesifikasjonsfeil eller innføring av ny funksjonalitet Vanligvis ikke større arkitekturendringer under vedlikehold Endre komponenter og legge til nye hvis det er nødvendig.

11 Flere typer vedlikehold Feilretting Kodefeil enkle å rette. De er lokale Utformingsfeil mer kompliserte fordi de involverer flere komponenter Kravspesifikasjonsfeil er kostbare. Kan kreve ny utforming av systemet Tilpasninger til nytt miljø Når det skjer endringer i maskinvare operativsystem annen støtteprogramvare Vedlikehold som øker eller endrer funksjonaliteten Når kravene til programvaren endrer seg

12 Vurdering av et gammelt system Hvilken løsning er mest kostnadseffektive? Fjerne systemet Fortsette vedlikehold Forandre systemet for lettere vedlikehold Erstatte systemet med et nytt system Beslutningen avhenger av Det eksisterende systemets verdi og kvalitet. Svaret kan være forskjellig for ulike deler av systemet

13 Vurdering av forvaltningsmiljø Endringer i forvaltningsmiljøet kan føre til endringer i applikasjonsprogrammet Dette bør inngå i vurderingen: Leverandørstabilitet Oppetid Alder Ytelse Behov for støtte Vedlikeholds- og driftskostnader

14 Vedlikeholdsprosessen Prosessen settes i gang når det kommer viktige ønsker om forandringer Vurdering av kostnader og virkninger som forandringene fører til Hvilke forandringer som skal gjennomføres bestemmer gjennomføringen feilretting tilpasning ny funksjonalitet Implementering Validering

15 Brannslukking løse utfordringer straks Brannslukking utføre når det oppstår: Feil som hindrer bruk av systemet Uventede endringer i omgivelsene Uventede endringer i organisasjon eller lovverk Vanligvis kjapp nødretting av koden Stor fare for at det ikke lenger blir konsistens mellom krav, utforming og kode Systemet eldes fort ved vanlig brannslukking Kan forbedres ved å gjennomføre en vanlig retting senere når (om) vi får tid

16 Evaluering av vedlikehold Hva slags endringer kan bli nødvendige Hvilke deler av systemet kan bli mest krevende å vedlikeholde Hva vil vedlikeholdet koste? Et system som er lett å vedlikeholde er også lettere å tilføre ny funksjonalitet Ny funksjonalitet gjør systemet vanskeligere å vedlikeholde Kostnaden til vedlikehold avhenger av antallet endringer som igjen avhenger av hvor lett det er å vedlikeholde

17 Evaluere vedlikeholdbarhet Avhenger av: Antall komponenter Sammenhengen mellom komponentene Kompleksiteten i komponentene Kompleksitet Funksjonsstørrelse Modulstørrelse Forgreninger Økt kompleksitet gir økte kostnader til vedlikehold Kompliserte moduler bør forenkles i utviklingsfasen Store moduler bør erstattes med flere små og gjenbrukbare moduler i utviklingsfasen

18 Å forutsi vedlikeholdbarhet Bygger ofte på kompetanse og erfaring Antall forespørsler om å korrigere feil Tidsforbruk for å analysere konsekvensen av feilkorrigeringen Gjennomsnittlig tidsforbruk for å implementere endringen Antall ikke gjennomførte endringer Økninger i disse tallene tyder på lavere vedlikeholdbarhet