Údržba softwaru - Software maintenance

Údržba softwaru v softwarovém inženýrství je úprava softwarového produktu po dodání za účelem odstranění chyb, zlepšení výkonu nebo jiných atributů.

Běžným vnímáním údržby je, že zahrnuje pouze odstraňování vad . Jedna studie však uvedla, že více než 80% úsilí na údržbu je použito na neopravovací akce. Toto vnímání je udržováno uživateli, kteří odesílají zprávy o problémech, které ve skutečnosti představují vylepšení funkcí systému. Novější studie uvádějí, že podíl opravujících chyby se blíží 21%.

Dějiny

Softwarovou údržbu a evoluci systémů poprvé řešil Meir M. Lehman v roce 1969. Během dvaceti let jeho výzkum vedl k formulaci Lehmanových zákonů (Lehman 1997). Klíčová zjištění jeho výzkumu dospěla k závěru, že údržba je skutečně evoluční vývoj a že rozhodování o údržbě napomáhá pochopení toho, co se stane se systémy (a softwarem) v průběhu času. Lehman prokázal, že systémy se v průběhu času stále vyvíjejí. Jak se vyvíjejí, stávají se složitějšími, pokud není provedena nějaká akce, jako je refaktorování kódu za účelem snížení složitosti. Na konci 70. let 20. století slavná a široce citovaná průzkumová studie Lientze a Swansona odhalila velmi vysoký zlomek nákladů životního cyklu, které byly vynakládány na údržbu.

Průzkum ukázal, že přibližně 75% úsilí údržby bylo na prvních dvou typech a opravy chyb spotřebovaly asi 21%. Mnoho dalších studií naznačuje podobnou velikost problému. Studie ukazují, že během shromažďování a analýzy nových požadavků je klíčový přínos koncových uživatelů. Toto je hlavní příčina jakéhokoli problému během vývoje a údržby softwaru. Údržba softwaru je důležitá, protože spotřebovává velkou část celkových nákladů životního cyklu a také neschopnost rychle a spolehlivě měnit software znamená, že přicházejí o obchodní příležitosti.

Význam údržby softwaru

Klíčové problémy s údržbou softwaru jsou manažerské i technické. Klíčové problémy řízení jsou: sladění s prioritami zákazníků, personální obsazení, které organizace provádí údržbu, odhad nákladů. Klíčovými technickými problémy jsou: omezené porozumění, analýza dopadů , testování, měření udržovatelnosti.

Údržba softwaru je velmi široká činnost, která zahrnuje opravu chyb, vylepšení funkcí, odstranění zastaralých funkcí a optimalizaci. Protože je změna nevyhnutelná, je třeba vyvinout mechanismy pro vyhodnocování, řízení a provádění úprav.

Jakákoli práce provedená na změně softwaru poté, co je v provozu, je tedy považována za údržbu. Účelem je zachovat hodnotu softwaru v průběhu času. Hodnotu lze zvýšit rozšířením zákaznické základny, splněním dalších požadavků, snazším používáním, efektivnějším využitím nových technologií. Údržba může trvat 20 let, zatímco vývoj může být 1–2 roky.

Plánování údržby softwaru

Nedílnou součástí softwaru je údržba, která vyžaduje, aby byl během vývoje softwaru sestaven přesný plán údržby. Mělo by určit, jak budou uživatelé požadovat úpravy nebo hlásit problémy. Rozpočet by měl zahrnovat odhady zdrojů a nákladů a mělo by být řešeno nové rozhodnutí pro vývoj každé nové funkce systému a jeho cílů kvality. Údržba softwaru, která může trvat 5 a více let (nebo dokonce desetiletí) po procesu vývoje, vyžaduje účinný plán, který by se mohl zabývat rozsahem údržby softwaru, přizpůsobením procesu po dodání/nasazení a určením toho, kdo bude zajistit údržbu a odhad nákladů životního cyklu.

Procesy údržby softwaru

Tato část popisuje šest procesů údržby softwaru jako:

  1. Proces implementace obsahuje činnosti přípravy a přechodu softwaru, jako je koncepce a tvorba plánu údržby; příprava na řešení problémů identifikovaných během vývoje; a návaznost na správu konfigurace produktu.
  2. Proces analýzy problémů a modifikací, který se provede, jakmile se aplikace stane odpovědností skupiny údržby. Programátor údržby musí analyzovat každý požadavek, potvrdit jej (reprodukováním situace) a zkontrolovat jeho platnost, prozkoumat jej a navrhnout řešení, dokumentovat požadavek a návrh řešení a nakonec získat všechna požadovaná oprávnění k provedení změn.
  3. Proces zvažující implementaci samotné úpravy.
  4. Proces přijetí modifikace potvrzením modifikované práce s jednotlivcem, který žádost odeslal, aby se zajistilo, že změna poskytne řešení.
  5. Proces migrace ( například migrace platformy ) je výjimečný a není součástí každodenních úloh údržby. Pokud musí být software přenesen na jinou platformu bez jakékoli změny funkčnosti, bude tento proces použit a k tomuto úkolu bude pravděpodobně přiřazen tým projektu údržby.
  6. Nakonec poslední proces údržby, což je událost, která se nevyskytuje denně, je vyřazení softwaru.

Existuje celá řada procesů, činností a postupů, které jsou pro správce jedinečné, například:

  • Přechod: kontrolovaný a koordinovaný sled činností, během nichž se systém postupně přenáší z vývojáře na správce
  • Dohody o úrovni služeb (SLA) a specializované smlouvy o údržbě (specifické pro doménu) sjednané správci
  • Modifikační žádost a hlášení o problému Help Desk: proces řešení problémů používaný správci k upřednostňování, dokumentování a směrování požadavků, které dostávají

Kategorie údržby softwaru

Společnost EB Swanson původně identifikovala tři kategorie údržby: opravné, adaptivní a dokonalé. Standard IEEE 1219 byl nahrazen v červnu 2010 P14764 . Ty byly od té doby aktualizovány a ISO/IEC 14764 uvádí:

  • Opravná údržba : Reaktivní modifikace softwarového produktu provedená po dodání za účelem odstranění zjištěných problémů. Opravnou údržbu lze automatizovat pomocí automatického opravování chyb .
  • Adaptivní údržba: Úpravy softwarového produktu prováděné po dodání, aby byl softwarový produkt použitelný ve změněném nebo měnícím se prostředí.
  • Perfektní údržba: Úprava softwarového produktu po dodání za účelem zlepšení výkonu nebo udržovatelnosti .
  • Preventivní údržba : Úprava softwarového produktu po dodání za účelem detekce a opravy skrytých chyb v softwarovém produktu, než se stanou účinnými poruchami.

Existuje také pojem údržba před vydáním/před vydáním, což je vše, co je dobré udělat pro snížení celkových nákladů na vlastnictví softwaru. Věci, jako je dodržování standardů kódování, které zahrnují cíle údržby softwaru. Správa propojení a soudržnosti softwaru. Dosažení cílů podpory softwaru (například SAE JA1004, JA1005 a JA1006). Některé akademické instituce provádějí výzkum s cílem kvantifikovat náklady na průběžnou údržbu softwaru kvůli nedostatku zdrojů, jako jsou návrhové dokumenty a školení a zdroje pro porozumění systému/softwaru (vynásobte náklady přibližně 1,5–2,0, pokud nejsou k dispozici žádná konstrukční data) .

Faktory údržby

Dopad klíčových faktorů úpravy na údržbu (seřazeno podle maximálního pozitivního dopadu)

Faktory údržby Plus rozsah
Specialisté na údržbu 35%
Vysoká zkušenost personálu 34%
Proměnné a data řízená tabulkou 33%
Nízká složitost základního kódu 32%
Y2K a speciální vyhledávače 30%
Nástroje pro restrukturalizaci kódu 29%
Nástroje pro přepracování 27%
Programovací jazyky na vysoké úrovni 25%
Reverzní inženýrské nástroje 23%
Nástroje pro analýzu složitosti 20%
Nástroje pro sledování vad 20%
Specialisté na „hromadnou aktualizaci“ Y2K 20%
Automatizované nástroje pro řízení změn 18%
Neplacené přesčasy 18%
Měření kvality 16%
Formální základní kontrola kódu 15%
Knihovny regresních testů 15%
Vynikající doba odezvy 12%
Roční školení> 10 dní 12%
Vysoká zkušenost s řízením 12%
HELP automatizace stolu 12%
Žádné moduly náchylné k chybám 10%
On-line hlášení závad 10%
Měření produktivity 8%
Vynikající snadné použití 7%
Měření spokojenosti uživatelů 5%
Vysoká týmová morálka 5%
Součet 503%

Moduly náchylné k chybám jsou nejen problematické, ale také mnoho dalších faktorů může snížit výkon. Například velmi složitý kód špaget je docela obtížné bezpečně udržovat. Velmi častou situací, která často snižuje výkon, je nedostatek vhodných nástrojů pro údržbu, jako je software pro sledování defektů, software pro správu změn a software testovací knihovny. Níže popište některé z faktorů a rozsah dopadu na údržbu softwaru.

Dopad klíčových faktorů úpravy na údržbu (seřazeno podle maximálního negativního dopadu)

Faktory údržby Mínus rozsah
Moduly náchylné k chybám -50%
Vložené proměnné a data -45%
Zkušenost personálu -40%
Vysoká složitost kódu -30%
Žádné Y2K speciálních vyhledávačů -28%
Ruční metody řízení změn -27%
Nízkoúrovňové programovací jazyky -25%
Žádné nástroje pro sledování závad -24%
Žádní specialisté na „hromadnou aktualizaci“ Y2K -22%
Špatné snadné použití -18%
Žádné kvalitní měření -18%
Žádní specialisté na údržbu -18%
Špatná doba odezvy -16%
Žádné kontroly kódu -15%
Žádné knihovny regresních testů -15%
Žádná automatická podpora -15%
Žádné online hlášení závad -12%
Nezkušenost vedení -15%
Žádné nástroje na restrukturalizaci kódu -10%
Žádné roční školení -10%
Žádné nástroje pro opětovné inženýrství -10%
Žádné nástroje reverzního inženýrství -10%
Žádné nástroje pro analýzu složitosti -10%
Žádné měření produktivity -7%
Chudá týmová morálka -6%
Žádné měření spokojenosti uživatelů -4%
Žádné neplacené přesčasy 0%
Součet -500%

Udržovací dluh

V příspěvku na 27. mezinárodní konferenci o řízení kvality softwaru v roce 2019 John Estdale představil termín „dluh na údržbu“ pro potřeby údržby generované závislostí implementace na externích IT faktorech, jako jsou knihovny, platformy a nástroje, které zastaraly. Aplikace nadále běží a IT oddělení zapomíná na tuto teoretickou odpovědnost a zaměřuje se na naléhavější požadavky a problémy jinde. Takový dluh se časem hromadí a tiše požírá hodnotu softwarového aktiva. Nakonec se stane něco, kvůli čemu jsou změny systému nevyhnutelné.

Majitel pak může zjistit, že systém již nelze upravovat - je doslova neudržitelný. Méně dramaticky může údržba řešení obchodního problému trvat příliš dlouho nebo příliš mnoho a je třeba najít alternativní řešení. Software náhle narazil na hodnotu 0 GBP.

Estdale definuje „Údržbový dluh“ jako: mezeru mezi aktuálním stavem implementace aplikace a ideálem, přičemž využívá pouze funkčnost externích komponent, která je plně udržována a podporována. Tento dluh je často skrytý nebo není uznán. Celková udržovatelnost aplikace závisí na pokračující získatelnosti komponent všeho druhu od jiných dodavatelů, včetně:

  • Vývojové nástroje: úpravy zdrojů, správa konfigurace, kompilace a sestavení
  • Testovací nástroje: výběr testů, provádění/ověřování/hlášení
  • Platformy k provedení výše uvedeného: hardware, operační systém a další služby
  • Produkční prostředí a všechna pohotovostní zařízení/zařízení pro obnovu po havárii, včetně prostředí Run-Time Support Environment jazyka zdrojového kódu a širší ekosystém plánování úloh, přenosu souborů, replikovaného úložiště, zálohování a archivace, jednotného přihlašování atd. Atd.
  • Samostatně získané balíčky, např. DBMS, grafika, komunikace, middleware
  • Zakoupeno ve zdrojových kódech, knihovnách objektových kódů a dalších fakturovatelných službách
  • Jakékoli požadavky vyplývající z jiných aplikací sdílejících produkční prostředí nebo ze spolupráce s dotyčnou aplikací

a samozřejmě

  • Dostupnost příslušných dovedností, interně nebo na trhu.

Úplné zmizení součásti by mohlo způsobit, že aplikaci bude možné přestavět nebo bezprostředně neudržitelnou.

Viz také

Reference

Další čtení

externí odkazy