Programvareendring In 140 Forelesning Sommerville kap 27

Mål Forstå tre strategier for endring av programvare –Vedlikehold –Arkitekturtransformasjon –Reengineering Forstå prinsippene for programvarevedlikehold og hvorfor programvare er dyrt å vedlikeholde Forstå hvordan gamle systemer kan gjøres om til distribuerte C/S-systemer

Hvorfor endringer? Forandring er nødvendig –Nye behov –Organisasjonsendring –Feilretting –Ytelsesforbedring Organisasjonen er avhengig av systemet Systemet representerer store verdier som vil gå tapt uten vedlikehold

Strategier for programvareendring Vedlikehold –Endringer, men programmets grunnleggende struktur ligger fast Arkitekturtransformasjon –Endringer som medfører betydelige forandringer i arkitekturen. –Fra sentralisert datasentrert til C/S Reengineering –Lage systemet på nytt så det blir lettere å forstå og vedlikehold

Hva velger man? Strategiene kan kombineres Andre muligheter: –Ny utvikling –COTS –Outsourcing Endringer skaper forskjellige versjoner –Det er en kunst å holde orden på versjonene – konfigurasjonsstyring

Dynamikken i systemevolusjon (Lehman og Belady 1985) Lehmans "lover" –Kontinuerlig forandring - Et program som brukes i virkelighetens verden må endres eller bli mer og mer ubrukelig –Økende kompleksitet – Ettersom programmet endres, blir strukturen mer og mer komplisert. Det kreves ekstraressurser for å holde strukturen enkel nok. –Store programmers utvikling – Utviklingen er en selvstyrt prosess. Størrelse, tid mellom releaser og antall feil er noenlunde konstant –Organisatorisk stabilitet – gjennom systemets levetid er utviklingstakten noenlunde konstant og uavhengig av systemutviklingsressursene –Bevart gjenkjennelighet – gjennom systemets levetid er endringen for hver utgave noenlunde konstant

Lehmanns lover Selvstyrt prosess er den mest omstridte –Store systemers dynamikk fastsettes tidlig i utviklingsprosessen –Treghet hindrer større forandring forandring - > feil feil ->feilrettingsrelease –Sammenheng med organisasjonens beslutningsprosess Organisatorisk stabilitet –Prosjektet kommer i mettet tilstand. (Uansett hvor mye ressurser som settes inn klarer man ikke å akselerere arbeidet) Tilsynelatende brudd på Lehmanns lov –ms-word fra 256k til gigantsystem

Vedlikehold av programvare Endringer –Liten: Retting av kodefeil –Større: Endring av design –Betydelig: Endring av spesifikasjon eller innføring av ny funksjonalitet –Vanligvis ikke større arkitekturendringer under vedlikehold –Endre komponenter og legge til nye hvis det er nødvendig.

Vedlikeholdstyper Reparasjonsendringer –Kodefeil lette å rette. De er lokale –Endring av design er mer kompliserte fordi de involverer flere komponenter –Endring pga. feil i kravspesifikasjon er kostbare. Kan kreve ny design av systemet Endringer som tilpasser systemet til nytt miljø –Svarer til endringer i maskinvare operativsystem annen støtteprogramvare Vedlikehold som øker eller endrer funksjonaliteten –Når kravene til programvaren endrer seg

Fordeling av vedlikeholdsarbeidet

Spiralmodell for vedlikehold

Vedlikeholdskostnader Vanligvis 2 – 4 ganger utviklingskostnad Både tekniske og organisatoriske faktorer spiller inn Øker etter hvert som programvaren blir vedlikeholdt. Vedlikeholdet ødelegger strukturen. Da blir videre vedlikehold vanskeligere Eldre programvare kan ha høye supportkostnader Hvordan vil bruk av hyllevare spille inn?

Vedlikeholdskostnader Det kan lønne seg å investere i utviklingsarbeid som gjør systemet lettere å vedlikeholde –Hovedkostnad å forstå systemet og analysere virkninger –Kan lettes med god systemering: Presis spesifikasjon OO-utvikling Konfigurasjonsstyring

Hvorfor er det dyrere å legge til funksjonalitet etterpå Utviklingsteamet med sin forståelse eksisterer ikke lenger Kontraktansvar: Utviklingsorganisasjonen er ikke vedlikeholdsorganisasjonen Personalkompetanse –Vedlikehold har lav status –Vedlikehold utføres av uerfarent personale –Gamle programmeringsspråk Programalder og struktur –Strukturødeleggelse, dårlig systemering, ikke strukturerte, optimert for effektivitet, dokumentasjonsbrist, manglende konfigurasjonsstyring

Hva kan gjøres: Vekk med skillet mellom utvikling og vedlikehold Evolusjonære systemer –Nyutvikling –Forbedring av eksisterende med RE eller AT Struktur i eksisterende systemer kan bedres med RE eller AT Preventivt vedlikehold

Vedlikeholdsprosessen Varierer med programvaretype, utviklingsprosess, involverte. Formell med strukturert dokumentasjon eller ad-hoc Samme abstrakte struktur –Forandringsanalyse –Releaseplanlegging –Implementering –Release

Vedlikeholdsprosessen Prosessen settes i gang av et antall forandringsønsker eller system krasj Vurdering av kostnader og virkninger som forandringene fører til Valg av forandringer som skal gjennomføres danner releaseplan –feilretting –tilpasning –ny funksjonalitet Implementering Validering

Vedlikeholdsprosessen

Endringene bør gjennomføres fullstendig Endring av spesifikasjon Endring av design Endring av kode Testing av systemet Ikke alltid mulig –Brannslukking

Brannslukking – løse problemer det haster med Behovet oppstår ved: –Feil som hindrer bruk av systemet –Uventede konsekvenser av endringer i omgivelsene –Uventede endringer i organisasjon eller lovverk Løses ved nødreparasjon av koden Stor fare for inkonsistens mellom krav, design og kode Systemet aldres fortere ved nødreparasjoner Kan løses ved å gjøre skikkelig reparasjon – sendere – når vi får tid

Implementering av endringer

Vedlikeholdsplanlegging Forutsi hvilke endringer som blir nødvendige Forutsi hvilke deler av systemet blir mest vedlikeholdskrevende Forutsi kostnader –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

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 implementeringstid for endringer –Antall ikke gjennomførte endringer Økninger i disse tallene tyder på lavere vedlikeholdbarhet

Arkitekturevolusjon 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

Distribusjon av brukergrensesnittet Gamle systemer: –Skjemabaserte grensesnitt – all prosessering og skjemagenerering 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 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 appletts Jo mer funksjonalitet som kreves i nettleseren, dess nyere versjon kreves det.