<==Nazaj

Vzdrževanje programske opreme

• do nedavnega najbolj zanemarjano
• stroški vzdrževanja vse višji
• stare opreme je vedno več
• opremo je potrebno sproti spreminjati in prilagajati
• stroški so visoki zaradi slabe dokumentiranosti stare opreme in vse večje kompleksnosti nove
• pri vzdrževanju nastajajo tudi indirektni stroški
• glavne aktivnosti vzdrževanja:
  1. Popravki za odpravljanje napak
  2. Prilagajanje
  3. Razširitev zmogljivosti
  4. Preventivno vzdrževanje
• največ zahtev po vzdrževanju nastane zaradi sprememb v zunanjem okolju
• programerji raje pišejo nove programe kot vzdržujejo obstoječe
• z dobrim načrtovanjem se lahko vzdrževanju deloma izognemo
• tiste module, ki jih bomo velikokrat spreminjali izoliramo tako, da bo spreminjanje čim lažje
• tudi tukaj veljata Zakon stalnih sprememb in Zakon naraščajoče kompleksnosti
• vzdrževanje kode, ki je nismo sami napisali je težavno

Organizacija vzdrževanja programske opreme

• tri načela organzacije skupin:
  1. W-type: delitev po tipu dela (analiza, programiranje, ...)
  2. A-type: delitev glede na vrsto aplikacije
  3. L-type: delitev glede na življenski cikel (razvoj, vzdrževanje)
• prednosti ločenega razvoja in vzdrževanja:
  • jasne zadolžitve
  • zaradi nujnih vzdrževalnih del je težko načrtovati novo opremo
  • jasna ločitev obeh aktivnosti
  • specializacija prinese višjo kvaliteto
  • bolj osredotočeno delo → večja produktivnost
• slabosti ločenega vzdrževanja in razvoja
  • slabša motivacija zaradi različnega statusa
  • slabše poznavanje sistema
  • slabša koordinacija med razvojem in vzdrževanjem
  • večji začetni stroški vzdrževanja
  • možno podvajanje komunikacij z uporabnikom

Postopek vzdrževanja

1. Ustrezna organizacija: da ne pride do neavtoriziranih in nasprotujočih si sprememb
2. Dokumentiranje zahtevkov
3. Preverjanje zahtevkov: odobrimo le tiste, ki so potrebni, smiselni in ekonomsko upravičeni
4. Ukrepanje: glede na dano situacijo sprožimo ustrezen postopek (kritična napaka, napaka ki lahko počaka, ...)
5. Organizacija: podobno kot razvoj (analiza, načrtovanje, kodiranje, testiranje)
   • Obstaja model COCOMO za oceno dela za vzdrževanje: E_maint = 2.4ACT(KLOC)^1.05, (KLOC = št. tisočev vrstic kode, C₁ = število ukazov, ki smo jih spremenili ali dodali v enem letu)
6. Dokumentacija sprememb: spremeniti moramo tudi dokumentacijo

Stranski učinki vzdrževanja

• paziti moramo, da ne povzročimo stranskih učinkov
• najbolj nevarni so:
  1. spreminjanje ali brisanje imena spremenljivk
  2. spreminjanje ali brisanje podprogramov
  3. spreminjanje mejnih vrednosti
  4. spremembe za pohitritev procesiranja