Programvareendring In 140 Forelesning Sommerville kap 27.

Presentasjon om: "Programvareendring In 140 Forelesning Sommerville kap 27."— Utskrift av presentasjonen:

1 Programvareendring In 140 Forelesning Sommerville kap 27

2 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

3 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

4 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

5 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

6 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

7 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

8 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.

9 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

10 Fordeling av vedlikeholdsarbeidet

11 Spiralmodell for vedlikehold

12 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?

13 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

14 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

15 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

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

17 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

18 Vedlikeholdsprosessen

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

20 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

21 Implementering av endringer

22 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

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

24 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

25 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

26 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

27 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

28 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?

29 Strukturen i gamle systemer

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

31 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

32 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?)

33 Distribusjon av brukergrensesnitt (for gamle systemer uten lagdeling)

34 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

35 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.

36

37

38