Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig når et system er operativt Alt arbeid som utføres på et system etter at det har blitt operativt, regnes som vedlikehold Software vedlikehold kan ikke betraktes på samme måte som hardware vedlikehold Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Alt arbeid som utføres på et system etter at det har blitt operativt, regnes som vedlikehold. Software vedlikehold kan ikke betraktes på samme måte som hardware vedlikehold. Av den enkle grunn at HW vedlikehold stort sett består av å reparere eller skifte ut deler, mens dette ikke er tilfelle med SW vedlikehold. (Husk at funksjonen tostring() må skiftes ut etter å ha blitt brukt 10.000 ganger ;-)) SW er i mye større grad bygget for å kunne forandres.
Slide 3 The changing system and the nature of maintenance Ulike systemer S-system P-system E-system Alle systemer, unntagen de som er veldig små, kommer til å forandre seg gjennom sitt livsløp. Helt generelt kan vi beskrive et system etter hvordan det er relatert til miljøet som omgir systemet. Jo mer avhengig et system er av den virkelige verden (real world) for sine krav, jo sikrere er det at systemet vil forandre seg.
Slide 4 The changing system and the nature of maintenance S-system Problemet er helt definert Det er en eller flere løsninger til problemet. Utvikler er ikke bekymret for riktigheten av løsningen, men med riktigheten av implementasjonen av løsningen. Real Wold Problem Requirements specification System Information Comparison Subject to change Noen systemer er formelt definert av spesifikasjoner. Problemet i disse systemene er helt definert og det er en eller flere løsninger på problemet. Løsningen er vel kjent, slik at utvikler ikke er opptatt med riktigheten av løsningen, men med riktigheten av implementasjonen av løsningen, og løsningens presisjon. Figuren viser problemet løst av et S-system som er relatert til den virkelige verden, og at den virkelige verden kan forandres. Hvis den virkelige verden forandres, er resultatet er helt nytt problem som må spesifiseres. Regneeksempel
Slide 5 The changing system and the nature of maintenance P-system Beskriver et problem på en abstrakt måte Systemets kravspesifikasjon blir skrevet ut fra vårt abstrakte synspunkt Mer basert på praktisk abstraksjon enn på en komplett og definert spesifikasjon Mer dynamisk enn et S-system Real Wold Problem Abstraction Requirements specification System Information Comparison Subject to change Det er ikke alltid lett eller mulig å beskrive et virkelig-verden problem fullstendig. I mange tilfeller eksisterer den teoretiske løsningen til et problem, men implementeringen av løsningen er upraktisk eller umulig. Sjakkeksempel Et P-system baserer seg mer på praktisk abstraksjon av problemet enn på en komplett definert spesifikasjon. Figuren forteller at P-systemet er mer dynamisk enn S-systemet. Løsningen produserer informasjon som blir sammenlignet med problemet. Hvis det da viser seg at informasjonen er dårlig egnet på noen som helst måte kan problemabstraksjonen bli forandret og kravene modifisert for å prøve å lage løsningen mer realistisk.
Slide 6 The changing system and the nature of maintenance E-system Systemet er integrert i den virkelige verden Forandrer seg når verden gjør det Problemet ikke fullt spesifisert Løsningen er basert på en modell av de abstrakte prosessene som er involvert Real World Problem Abstraction Requirements specification System Information Comparison Subject to change Et E-system er integrert (embedded) i den virkelige verden og forandrer seg når verden gjør det. Problemet kan ikke spesifiseres fullt ut. (Eksempel: forutse en nasjons helseutvikling) Løsningen er basert på en modell av de abstrakte prosessene som er involvert. Figuren illustrerer forandringsmulighetene til et E-system og systemets avhengighet av dens virkelige verden. Suksessen til et E-system er helt avhengig av kundens evaluering av systemets oppførsel (performance). Fordi problemet et E-system tar for seg ikke fullt ut kan spesifiseres må systemet bli vurdert kun etter sin oppførsel under virkelige kjøreforhold (actual operating conditions)
Slide 7 The changing system and the nature of maintenance SW vedlikehold Trenger all SW vedlikehold? Behov for vedlikehold kan sees i lys av systemets kategori Vedlikeholdsfase = videreutviklingsfase Vedlikeholdsfasen til et system kan være lengre enn utviklingsfasen av systemet Hele tiden vurdere om det lønner seg å videreutvikle et system, eller erstatte det med et nytt Lehmans Law of Software Evolution Trenger all SW vedlikehold? JA, knapt noe system unngår å bli forandret Behov for vedlikehold kan sees i lys av systemets kategori S-system: Lite utsatt for forandringer P-system: Høyst sannsynlig utsatt for forandringer E-system: Garantert forandringer Vedlikeholdsfase = videreutviklingsfase Vedlikeholdsfasen til et system kan være lengre enn utviklingsfasen av systemet. Har økt med årene, nå brukes opp til 80 % av arbeidsinnsatsen i vedlikeholdsfasen. Hele tiden vurdere om det lønner seg å videreutvikle et system, eller erstatte det med et nytt Lehmans Law of Software Evolution For de spesielt interesserte, står i læreboka kap. 11.1
Slide 8 Når vi utvikler et system er vår hovedfokus på å produsere kode som implementerer kravene og som fungerer korrekt. På hvert steg i utviklingen, refererer utviklingsteamet konstant til arbeid som er produsert tidligere i utviklingen. De sjekker for eksempel at designkomponentene er knyttet opp til kravspesifikasjonen og de har tester som sjekker at funksjoner virker i henhold til krav og design. Når vi snakker om vedlikehold er det litt annerledes. Vedlikeholdsteamet ser tilbake på utviklingsprodukter, samtidig som de er også opptatt av å etablere et samarbeid med brukerne og systemansvarlig for å finne ut hvor fornøyde de er med systemet. Vedlikeholdsteamet ser også framover for å prøve å finne feil før de oppstår, for å tenke over funksjonelle forandringer som kreves hvis bedriften forandres eller for å se på systemforandringer som kan være nødvendige hvis HW, SW eller interfacet forandres.
Slide 9 Aktivitetene rundt vedlikehold er nokså like aktivitetene til utvikling. De skal analysere krav, evaluerer systemet og programdesign. Skrive og se igjennom kode, teste forandringer og oppdatere dokumentasjonen. Vi kan fastslå at de som utfører vedlikeholdet, analytikere, programmere og designere, har samme roller. Men fordi endringer ofte krever en intim kunnskap til kodestrukturen og innhold, vil programmerere spille en større rolle i vedlikehold enn de gjorde i utviklingen.
Slide 10 Fokuserer på fire store aspekter ved systemets utvikling - Opprettholde kontrollen over systemets dag-til-dag funksjoner - Opprettholde kontrollen over systemets modifikasjoner - Perfeksjonere eksisterende akseptable funksjoner - Forhindre at systemets ytelse går under akseptabelt nivå
slide 11 Corrective Maintenance (korrigerende vedlikehold) For å kontrollere dag-til-dag funksjoner, vil vedlikeholdstemaet reagere på problemer som har oppstått på grunn av feil. Når feil inntreffer vil vedlikeholdsteamet få beskjed; de finner grunnen til feilen og gjør korreksjonene og forandrer kravene, designet, koden, test pakkene og dokumentasjonen. Ofte så blir problemet bare løst midlertidig slik at systemet kan fortsatt kjøre. Adaptive Maintenance (tilretteleggende vedlikehold) Det er slik at noen ganger kan en forandring i en del av systemet kreve at andre deler av systemet også forandres. Adaptive maintenance kan også benyttes ved forandringer i hardware og i miljøet. Hvis for eksempel et system opprinnelig var designet for et tørt, stabilt miljø, og skal flyttes over til en ubåt, må systemet blant annet tilpasse seg magnetisme og fuktighet.
Perfective Maintenance (utviklende vedlikehold) Involverer forandringer for å forbedre visse aspekter ved systemet, selv når forandringene ikke har kommet på grunn av feil. Når vi vedlikeholder et system, undersøker vi dokumentasjon, design og kode for å sjekke om noe kan gjøres bedre og mer tydeligere. Forandringer i dokumentasjon for å klare opp i poster, testpakker forandres for å forbedre test dekningen og kode og design modifiseres for å bedre lesbarheten er alle eksempler på perfective maintenace.
Slide 12 Preventive Maintenance (forebyggende vedlikehold) Denne metoden for vedlikehold oppstår når programmerer eller kodeanalytikere finner en feil eller en potensiell feil som ennå ikke har blitt til en feil i systemet. Retter feilen får den oppstår. Who Performs Maintenance (hvem utfører vedlikehold) Som regel er det ikke utviklingsteamet som også vedlikeholder systemet. Det er vanlig at en bedrift ansetter egne vedlikeholdsteam som skal sørge for at systemet fungerer korrekt. Det er positive og negative sider ved å la utviklingsteamet også vedlikeholde systemt: Positivt: De som har laget systemet kjenner systemet godt. De kjenner koden, designet, og filosofien bak systemet. Hvis de som utviklet systemet vet at de også skal vedlikeholde systemet, vil de bygge/designe systemet slik at vedlikehold vil være lettere. Negativt De forstår selv hva de mener slik at de ikke holder dokumentasjon oppdatert. Vanskelig å være objektiv når du selv har laget systemet.
Team Responsibility (ansvaret til vedlikeholdsteamet) Å vedlikehold et system krever at alle medlemmer i vedlikeholdsteamet er aktive. Det er vanlig at brukere, systemansvarlige kunder kontakter vedlikeholdsteamet med kommentarer og spørsmål. Deretter må analytikerne og programmererne finne ut hvilke deler av koden som berørt, hva som må gjøres med designet og hvor mye resurser (tid og innsats) som er nødvendig for å gjennomføre endringene.
Slide 13 Use of Maintenance Time (bruken av tiden ved vedlikehold) Perfective 50 % Adaptive 25% Corrective 21 % Preventive 4 %
Slide 14 Spørsmål