Programvareendring del 1 In 140 Forelesning Nr 21 Sommerville kap 27, 1. Del.

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

1 Programvareendring del 1 In 140 Forelesning Nr 21 Sommerville kap 27, 1. Del

2 Mål Forstå tre strategier for programvareforandring –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 mens 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 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 srukturen 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: 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 –Releaseplanlegging –Implementering –Release

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 releaseplan –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 – sendere – når vi får tid

23 Implementering av endringer