Programvareendring del 2 In 140 Forelesning Nr 22 Sommerville kap 27, 2. Del

Vedlikeholdsplanlegging Hva slags endringer blir nødvendige Hvilke deler av systemet blir mest vedlikeholdskrevende Hva kommer vedlikeholdet til å koste –Hvis systemet er lett å vedlikeholde er det lettere å godta et ønske om systemendring –Systemendringer gjør systemet vanskeligere å vedlikeholde –Vedlikeholdskostnaden avhenger av antallet endringer og kostnaden for hver av dem som igjen avhenger av hvor lett det er å vedlikeholde

Vedlikeholdsplanlegging

Forutsi forandringer Avhenger av forholdet mellom system og omgivelser –Brukergrensesnitt: antall og kompleksitet –Antall ustabile (volatile) systemkrav –Antall forretningsprosesser systemet er knyttet til

Forutsi vedlikeholdbarhet Antall komponenter Sammenhenger Indre kompleksitet i komponentene Kompleksitet –Funksjonsstørrelse –Modulstørrelse –Avgreininger Jo større kompleksitet, jo større vedlikeholdsomkostninger Lønnsomt å forenkle under utvikling Lønnsomt å erstatte svært kompliserte komponenter med enklere komponenter

Forutsi vedlikeholdbarhet Kan også bruke erfaringstall –Antall feilkorrigeringsforespørsler –Gjennomsnittlig tidsforbruk i konsekvensanalyse –Gjennomsnittlig impelementeringstid for endringer –Antall ikke gjennomførte endringer Økninger i disse tallene tyder på lavere vedlikeholdbarhet

Forutse vedlikeholdsomkostnader Forandringsbehov Forandringskostnad Intuisjon Erfaring

Arkitekturevolusjon Vedlikehold er ofte lokalisert Fra 1980 alminnelig med arkitekturevolusjon av økonomiske årsaker Distribuerte systemer er mer kosteffektivt enn stormaskin –Maskinvarekostnader C/S er mye rimeligere enn stormaskin –Krav til brukergrensesnitt Tegnbasert -> GUI –Distribuert tilgang til systemer Avdelinger Hjemmekontor

Arkitekturevolusjon Overgangen gir –Billigere systemer som er mer moderne- enklere å bruke og mer tilgjengelig –Muligheter for innføring av objektorientering i deler av systemet ->Lettere vedlikehold Ikke bare fordeler –Overgangen er vanskelig og kostbar Nødvendig å vurdere om endringen bør gjennomføres

Vurdering av overgang til C/S Er systemet viktig og varig? Hvor gammelt er systemet? Struktur i eksisterende system? Er det tatt en overordnet beslutning om å forlate stormaskin?

Strukturen i gamle systemer

En løsning for distribusjon av gamle (ustrukturerte) systemer

Lagdelt distribusjonsmodell Greit hjelpemiddel når man planlegger overgang til C/S Lagene –Presentasjon –Datavalidering –Interaksjonsstyring –Applikasjonstjenester –Databaselag Kostnaden avhenger blant annet av hvor mange lag som skal distribueres Gradvis overgang kan være mulig

Lagdelt distribusjonsmodell

Overgang til distribuerte systemer: valgmuligheter Multi-tier systemer er også mulig

Distribusjon av brukergrensesnittet Gamle systemer: –Skjemabaserte grensesnitt – all prosessering og bildegenerering på stormaskin –Skjermterminaler kan erstattes med terminalemuleringsprogrammer på PC Alternativer: –Hvis atskilt presentasjons (og datavaliderings-) lag, kan dette laget bygges på nytt. Resten av systemet styres via samme grensesnitt som før –Hvis lagdeling mangler: Bygge nytt brukergrensesnitt som limes til det gamle brukergrensesnittet via middleware. Ser ut som skjermterminaler fra det eksisterende systemet Ser ut som GUI for brukerne –Skjermbeskrivelser (i XML?)

Distribusjon av brukergrensesnitt (for gamle systemer uten lagdeling)

Strategier for distribusjon av brukergrensesnitt Bruke PC-ens vindushåndteringssystem og lage kommunikasjonsrutiner mot server –Alle muligheter – Full frihet – Bedre ytelse –Plattformavhengig – Vedlikeholdsproblem – Vanskeligere å oppnå konsistens Bygge brukergrensesnittet i HTML og bruke en WWW-leser –Uavhengig av plattform – Rimelig opplæring – Lettere å oppnå konsistens – Leser XML direkte – Har felles trekk med stormaskintankegang – Dårligere ytelse – Fattigere grensesnitt – Rimeligere vedlikehold av arbeidsstasjoner

Bruke PC-ens vindusmiljø Bruke Java eller VB til –Skjermbilder –Datavalidering –(Interaksjonsstyring) –(Applikasjonstjenester) –Kommunikasjonsrutiner Tilgang til alle muligheter i vindusmiljøet

Bruke www-teknologi Skrive brukergrensesnittet i HTML Datavalidering –med Java-script lokalt –med CGI-script eller servlet på server Interaksjonsstyring og applikasjonstjenester på server Ikke nødvendig å skrive kommunikasjonsrutiner. Dette brukergrensesnittet kan gjøres rikere med appletter Jo mer funksjonalitet som kreves i nettleseren, dess nyere versjon kreves det. www-teknologien har innebygd treghet

Grunnleggende problem: Skjemabasert –Systemstyrt rekkefølge –Ett skjema av gangen –Validering felt for felt –Krever gyldige data for å gå videre GUI-basert –Brukerstyrt rekkefølge. Fordel? –Kan bruke mange samtidige vindu –Validering felt for felt kan gi økt nettverkstrafikk (tregt system) Hva er viktig? –Hastighet, Umiddelbar tilbakemelding, Oversikt. Skjemabaserte tankegangen passer i mange arbeidsoperasjoner.

Hovedpunkter Endringsstrategier er vedlikehold, arkitekturevolusjon eller re-engineering Det ser ut til å være visse faste sammenhenger for endring av programvaresystemer (Lehmanns "lover") Tre vedlikeholdstyper –reparasjon –tilpasning til nytt miljø –økning eller endring av funksjonalitet Vedlikeholdskostnad er vanligvis høyere enn utviklingskostnaden

Hovedpunkter Antall gamle systemer er økende – en større andel av programvarebudsjettet blir brukt på vedlikehold Høye vedlikeholdskostnader kommer av –Personalkostnader – Liten tendens til å lage vedlikeholdbar kode – Kompetansemangel – Forverret systemstruktur Arkitekturevolusjon innebærer overgang fra sentralisert – datasentrert til distribuert arkitektur En vanlig strategi er å kapsle inn det gamle systemet og lage et distribuert brukergrensesnitt som anvender den gamle funksjonaliteten vha. middleware