Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Gamle systemer In 140 Sommerville kap 26. Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring.

Liknende presentasjoner


Presentasjon om: "Gamle systemer In 140 Sommerville kap 26. Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring."— Utskrift av presentasjonen:

1 Gamle systemer In 140 Sommerville kap 26

2 Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring. Styring av endringer. Versjonsproblematikk 5/5: 1) Brukermedvirkning 2) Åpen kildekode som systemutviklingsmetode 6/5:Oppsummering med eksamenstips

3 Mål Forstå hva som menes med gamle systemer og hvorfor disse systemene er sentrale i mange organisasjoner Bli kjent med hvordan slike systemer kan være bygd opp Kjenne til funksjonsorientert design. Forstå hvordan man beslutter om slike systemer skal: kasseres, vedlikeholdes, gjenoppbygges eller erstattes

4 Introduksjon Systemer koster mye og bør derfor ha lang levetid Levetid ofte over 10 år, kanskje over 20 år Gamle systemer er ofte forretningskritiske Systemene har utviklet og endret seg Mange endringer over mange år Ingen forstår helt hvordan systemet virker Kassere og erstatte gamle systemer er risikabelt.

5 Risiko ved endring av gamle systemer –Spesifikasjonene er mangelfull eller gått tapt. –System og forretningsvirksomhet er sammenvevd. –Forretningsregler er innebygd i systemet og ikke dokumentert på annen måte. –Nyutvikling er risikabelt i seg selv. –Hva skjer med integrasjon mot andre systemer?

6 Kostbart å vedlikeholde gamle systemer Mange har vært involvert – dårlig konsistens Laget i programmeringsspråk som få behersker i dag. Dårlig eller ingen systemdokumentasjon utenom kildekoden Vedlikeholdet har ødelagt strukturen i systemet Optimerte systemer er mindre forståelige Data i filer med ulik struktur – dobbeltlagring

7 Dilemma Fortsatt bruk av gammelt system – stadig økte kostnader Dyrt og risikabelt å erstatte gammelt system Kan noe gjøres for å utvide levetiden for gamle systemer og redusere kostnaden ved å drive dem videre?

8 Struktur i gamle systemer Ikke bare programvare Sosio-teknisk system –Brukere –Programvare –Maskinvare –Data –Forretningsprosesser –Leverandører –Ledelsen –Strategier –Lover & regler

9 Strukturen i et gammelt system

10 Lagdelt modell

11 Endring av lagdelt modell Kan man endre et lag uten å påvirke de andre? Ja, MEN: –Endringer gir nye muligheter som høyere lag vil utnytte... –Endringer kan involvere tyngre programvare... –Endring av hardware fører ofte til endring av operativsystem

12 Strukturen i gamle applikasjoner

13 Database-sentrert system

14 Transaksjonsbehandling

15 Design av gamle systemer Ikke samarbeidende objekter – samling av subrutiner (funksjoner) Subrutiner kan kalle (bruke) andre subrutiner Avhengig av språk kan data være: –Tilgjengelige for hele systemet –Private for hver subrutine Designstrategien er –Å dele inn programfunksjonaliteten i subrutiner –Felles data (systemtilstand) som deles av subrutinene Teori for designstrategi (70'-start 80') –Top down-design –Structured design

16 Funksjonsorientert design Algoritmekomleksitet overvinnes ved å dele inn i subrutiner Felles statiske data er et stort problem Funksjonsorientert utforming fungerer bra når –Deling av data er uttrykt (vist som funksjonsparametre) –Systemet håndterer uavhengige enkle inndata Databehandlingssystemer er ofte postorienterte –De passer godt til funksjonsorientert utforming

17 Input-process-output model

18 Lønningssystem DFD

19 Vurdering av gamle systemer Hvilken løsning er mest kosteffektiv? –Kassere 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

20 System quality and business value

21 Hva gjør vi med de gamle systemene? Fire muligheter –Lav kvalitet, lav forretningsverdi –Lav kvalitet, høy forretningsverdi –Høy kvalitet, lav forretningsverdi –Høy kvalitet, høy forretningsverdi Objektiv kvalitetsvurdering Ikke objektive forhold –Organisasjonsendringer –Organisasjonsstandarder –Budsjetthensyn

22 Vurdering av forretningsverdi Ingen enkle metoder Hent synspunkter fra flere interessenter –Sluttbrukere –Kunder –Avdelingsledere –IT-ledere –Toppledere

23 Lagdelt modell

24 Vurdering av systemkvalitet Hele det sosio-tekniske systemet må vurderes: –Brukere –Programvare –Maskinvare –Data –Forretningsprosesser –Leverandører

25 Vurdering av forretningsprosessen Prosesskvalitet Spørsmål som kan stilles: –Finnes det en modell for prosessen? –Er samme prosess brukt for samme funksjon i hele organisasjonen? –Hvordan har man tilpasset prosessen til arbeidet? –Er det sammenheng med andre prosesser, er sammenhengen klar for de involverte? –Støttes prosessen effektivt av applikasjonsprogrammet Leverer det nødvendig informasjon? Må samme informasjon registreres flere steder? Normalt forskjell på teori og praksis

26 Vurdering av støttemiljø Endringer i støttemiljøet fører til endringer i applikasjonsprogrammet Dette bør inngå i vurderingen: –Leverandørstabilitet –Oppetid –Alder –Ytelse –Behov for støtte –Vedlikeholds- og driftskostnader –Interoperabilitet

27 Vurdering av applikasjonsprogramvare Avviker fra vurdering av systemer under bygging –Foreldede standarder og teknikker –Struktur ødelagt av forandringer –Mangelfull dokumentasjon Forhold som inngår i vurdering –Forståelighet –Dokumentasjon –Data –Ytelse –Programmeringsspråk –Konfigurasjonsstyring –Testdata –Personalets kunnskap og kompetanse

28 Vurdering av applikasjonsprogramvare Kvantitative måltall –Antall forandringsønsker –Antall brukergrensesnitt –Datavolum Arbeid å skaffe denne informasjonen Sammenholdes med alder og systemstørrelse

29 Gamle systemer: Hovedpunkter I Systemet er ikke bare applikasjon, men sosio-tekninske system Består gjerne av mange programmer som deler data i filer eller foreldede DBMS De fleste er bygd på funksjonsorientert utvikling – De er satt sammen av funksjoner som kommuniserer gjennom parametere og globale delte dataområder

30 Gamle systemer: Hovedpunkter II To hovedtyper: –Batch- systemer –Transaksjonssystemer Felles struktur: input, behandle, output Forretningsverdi og kvalitet må vurderes før man velger kassering, omforming, videre vedlikehold, erstatning Systemkvaliteten avhenger av –Forretningsprosess –Støttesystemer –Selve applikasjonen


Laste ned ppt "Gamle systemer In 140 Sommerville kap 26. Forelesninger fremover 8/4:Gamle systemer 22/4: Systemevolusjon og vedlikehold 28/4: Konfigurasjonsstyring."

Liknende presentasjoner


Annonser fra Google