Programvareendring In 140 Forelesning Nr 21 Sommerville kap 27.

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

1 Programvareendring In 140 Forelesning Nr 21 Sommerville kap 27

2 Mål Forstå tre strategier for programvareforandring –Vedlikehold –Arkitekturtransformasjon –Re-engineering 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 mens programmets grunnleggende struktur ligger fast Arkitekturtransformasjon –Endringer som medfører betydelige forandringer i arkitekturen. –Fra sentralisert datasentrert til C/S Re-engineering –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 utgaver 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 -> feilrettingsutgave –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: Retting av utformingsfeil –Betydelig: 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.

9 Vedlikeholdstyper Reparasjonsendringer –Kodefeil lette å rette. De er lokale –Utformingsfeil mer kompliserte fordi de involverer flere komponenter –Kravspesifikasjonsfeil er kostbare. Kan kreve ny utforming 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 Vedlikeholdstyper Glidende overgang Uklare begreper –Korrigerende vedlikehold –Tilpassende vedlikehold –Forbedrende vedlikehold

11 Fordeling av vedlikeholdsarbeidet

12 Spiralmodell for vedlikehold

13 Vedlikeholdskostnader Vanligvis 2 – 4 ganger utviklingskostnad Både tekniske og ikke tekniske 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 COTS spille inn?

14 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

15 Utviklings/vedlikeholdskostnad

16 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

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

18 Vedlikeholdsprosessen Varierer med programvaretype, utviklingsprosess, involverte. Formell med strukturert dokumentasjon eller uformell Samme abstrakte struktur –Forandringsanalyse –Utgaveplanlegging –Implementering –Utgave

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

20 Vedlikeholdsprosessen

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

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

23 Implementering av endringer

24 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

25 Vedlikeholdsplanlegging

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

27 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

28 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

29 Forutse vedlikeholdsomkostnader Forandringsbehov Forandringskostnad Intuisjon Erfaring

30 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

31 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

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

33 Strukturen i gamle systemer

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

35 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

36 Lagdelt distribusjonsmodell

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

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

39 Distribusjon av brukergrensesnitt (for gamle systemer uten lagdeling)

40 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

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

42 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

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

44 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

45 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

46

47

48