A szoftverkarbantartás a szoftvertermék módosítását jelenti a kiszállítás után a hibák javítása, a teljesítmény vagy más tulajdonságok javítása érdekében.
A karbantartás gyakori értelmezése az, hogy kizárólag a hibák javítását jelenti. Azonban egy tanulmány szerint a karbantartási erőfeszítések több mint 80%-a nem javító jellegű tevékenységekre fordítódik. Ezt az érzést az erősíti, hogy a felhasználók olykor olyan hibajelentéseket küldenek be, amelyek valójában funkciófejlesztéseket jelentenek a rendszerhez. A legfrissebb tanulmányok szerint a hibajavítás aránya közelebb van a 21%-hoz.
Történet A szoftverkarbantartás és rendszerek fejlődése először Meir M. Lehman vizsgálta 1969-ben. Kutatásai során, húsz év alatt, Lehman törvényeket (Lehman 1997) fogalmazott meg. Kutatásának fő eredményei szerint a karbantartás valójában evolúciós fejlesztés, és a karbantartási döntések segítséget nyújtanak a rendszerek (és szoftverek) időbeli változásainak megértésében. Lehman kimutatta, hogy a rendszerek folyamatosan fejlődnek. Ahogy fejlődnek, egyre bonyolultabbá válnak, hacsak nem történik például kódrefaktorálás a bonyolultság csökkentése érdekében.
Az 1970-es évek végén Lientz és Swanson híres és széles körben idézett felmérést végzett, amely rámutatott a karbantartásra fordított életciklusköltségek nagyon magas arányára. A felmérés azt mutatta, hogy a karbantartási erőfeszítések mintegy 75%-a az első két típusra irányult, és a hibajavítás körülbelül 21%-ot tett ki. Több későbbi tanulmány hasonló problémaméretet sugall. A kutatások szerint a végfelhasználók hozzájárulása kulcsfontosságú az új követelmények adatainak gyűjtése és elemzése során. Ez az oka a legtöbb problémának a szoftver fejlődése és karbantartása során. A szoftverkarbantartás fontos, mert jelentős részét teszi ki az átfogó életciklus-költségeknek és a képtelenség a szoftvert gyorsan és megbízhatóan változtatni azt jelenti, hogy üzleti lehetőségek veszhetnek el.Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MALehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
A szoftver karbantartásának jelentősége A szoftverkarbantartás főbb problémái a vezetési és műszaki területeken jelentkeznek. A vezetési problémák közé tartozik az ügyfél prioritásainak összehangolása, a személyzet kérdései, a felelősségek kiosztása és a költségbecslés. A műszaki problémák közé tartozik: korlátozott megértés, hatáselemzés, tesztelés és karbantarthatóság mérése.
A szoftverkarbantartás egy széles tevékenységet foglal magában, amely tartalmazza a hibajavítást, a képességek bővítését, az elavult képességek eltávolítását és az optimalizálást. Mivel a változás elkerülhetetlen, mechanizmusokat kell kifejleszteni az értékelésre, a kontrollra és a módosítások végrehajtására.
A szoftver kiszállítása után végzett bármilyen munka karbantartásnak számít. A karbantartás megőrzi a szoftver értékét az idő során. Az érték növelhető az ügyfélkör kibővítésével, új és további követelmények teljesítésével, a felhasználás egyszerűsítésével, hatékonyabbá tételével és újabb technológiák alkalmazásával. A karbantartás akár évtizedekig is eltarthat, míg az elsődleges fejlesztés általában kevesebb, mint 3 év.
Szoftverkarbantartás tervezése A szoftver elengedhetetlen része a karbantartás, amely pontos karbantartási tervet igényel a szoftverfejlesztés során. Ez a terv meghatározza, hogyan kérhetik a felhasználók a módosításokat vagy jelenthetik a problémákat. A költségvetés tartalmaznia kell az erőforrásokra és költségekre vonatkozó becsléseket, és minden új rendszerfunkció fejlesztéséhez és minőségi céljaihoz új döntésre kell lépni. A szoftverkarbantartás, amely a fejlesztési folyamatot követően akár 5+ évig (vagy akár évtizedekig) is eltarthat, hatékony tervet igényel, amely foglalkozik a szoftverkarbantartás terjedelmével, az átadás/telepítés utáni folyamat igazításával, a karbantartást nyújtó személyek kijelölésével és az életciklus-költségek becslésével.
Szoftverkarbantartási folyamatok Ez a rész a hat szoftverkarbantartási folyamatot írja le:
Megvalósítás - A szoftver előkészítése és átmeneti tevékenységek, például a karbantartási terv elkészítése; a fejlesztés során azonosított problémák kezelésére történő felkészülés; és a termék konfigurációkezelésének követése. Probléma- és módosításelemzés - A kérelmek és problémák megerősítésre (reprodukcióra), elemzésre és vizsgálatra kerülnek. Megoldásokat javasolnak és dokumentálnak. Engedélyt kapnak a módosítások alkalmazására. Módosítás végrehajtása - A szoftverkód, adat és/vagy konfiguráció frissítése, fordítása és újra telepítése. Módosítás elfogadása – Az a személy, aki a kérelmet benyújtotta, működteti/teszteli a szoftvert annak megerősítésére, hogy a probléma megoldódott. Az áttelepítés (például a platform migrációja ) rendkívüli eset, és nem része a mindennapi karbantartási feladatoknak. Ha a szoftvert egy másik platformra kell áthelyezni anélkül, hogy a funkcionalitásban változtatás történne, akkor ezt a folyamatot alkalmazzák, és valószínűleg egy karbantartási projektcsapatot bíznak meg a feladattal. Elavult/kicserélt szoftverösszetevők kivonása. Ez általában nem mindennapos.
Számos olyan folyamat, tevékenység és gyakorlat létezik, amelyek egyedülállóak a karbantartók számára, például:
Átmenet: egy ellenőrzött és összehangolt tevékenységsorozat, amely során egy rendszert fokozatosan átadnak a fejlesztőtől a karbantartónak. Ideális esetben magában foglalja a Tudástranszfer (KT) folyamatát, amely a tipikus átadáskor történik Szolgáltatási szint megállapodások (SLA-k) és a karbantartók által tárgyalásra kerülő szakosodott (domainspecifikus) karbantartási szerződések. Módosítási kérelem és problémajelentés Help Desk: egy problémamegoldási folyamat, amelyet a karbantartók használnak a kérelmek prioritizálására, dokumentálására és továbbítására.
Szoftverkarbantartási kategóriák E.B. Swanson eredetileg három karbantartási kategóriát azonosított: hibajavító, alkalmazkodó és fejlesztő. Az IEEE 1219 szabványt 2010 júniusában felváltotta a P14764.Status of 1219-1998 by IEEE Standards Azóta ezeket frissítették, és az ISO/IEC 14764 standard bemutatja:
Hibajavító karbantartás: :A szoftvertermék reaktív módosítása a kiszállítást követően a felfedezett problémák kijavítására. A hibajavító karbantartás automatizálható az automatikus hibajavítással. Alkalmazkodó karbantartás: A szoftvertermék módosítása a kiszállítást követően annak érdekében, hogy a szoftvertermék használható maradjon egy megváltozott vagy változó környezetben. Fejlesztő karbantartás: A szoftvertermék módosítása a kiszállítást követően annak érdekében, hogy javítsa a teljesítményt vagy karbantarthatóságot. Megelőző karbantartás: A szoftvertermék módosítása a kiszállítást követően annak érdekében, hogy észlelje és kijavítsa a lappangó hibákat a szoftvertermékben, mielőtt azok hatékony hibákká válnának.
A pre-delivery/pre-release karbantartás fogalma azt jelenti, hogy az alkalmazás előtt, a kiadás előtt végzett tevékenységek, amelyekkel csökkenthető a szoftver teljes tulajdonlási költsége. Ilyen tevékenységek például a kódolási szabványok betartása, amelyek magukban foglalják a szoftver karbantarthatósági céljait. Az alkalmazás összekapcsolódásának és összetartozásának kezelése. A szoftvertámogathatósági célok elérése (például SAE JA1004, JA1005 és JA1006). Néhány tudományos intézmény kutatást végez azáltal, hogy megpróbálja mennyiségi módon meghatározni a folyamatos szoftverkarbantartással járó költségeket a tervezési dokumentumok és a rendszer/szoftver megértést elősegítő képzések és erőforrások hiányából adódóan (a költségeket kb. 1,5-2,0-szeresére szorozzák, ha nincs rendelkezésre álló tervezési adat).
Karbantartási tényezők A kulcsfontosságú korrekciós tényezők hatása a karbantartásra (a maximális pozitív hatás szerint rendezve) Karbantartási tényezők Plusz tartomány Karbantartási szakemberek 35% Magas személyzeti tapasztalat 34% Táblázatvezérelt változók és adatok 33% Az alapkód alacsony összetettsége 32% Y2K és speciális keresők 30% Kódátalakítási eszközök 29% Szerszámok újratervezése 27% Magas szintű programozási nyelvek 25% Fordított mérnöki eszközök 23% Komplexitáselemző eszközök 20% Hibakövető eszközök 20% Y2K „tömeges frissítés” specialisták 20% Automatizált változásvezérlő eszközök 18% Fizetetlen túlóra 18% Minőségi mérések 16% Formális alapkód ellenőrzések 15% Regressziós tesztkönyvtárak 15% Kiváló válaszidő 12% Éves képzés > 10 nap 12% Magas szintű vezetői tapasztalat 12% A HELP desk automatizálása 12% Nincsenek hibákra hajlamos modulok 10% Online hibabejelentés 10% Termelékenység mérések 8% Kiváló könnyű használat 7% Felhasználói elégedettség mérése 5% Magas csapatmorál 5% Összesen 503% Nemcsak a hibás modulok jelentenek problémát, hanem rombolhatják a teljesítményt is. Például a nagyon bonyolult, szöszmötölős kód nagyon nehéz biztonságosan karbantartani. Egy nagyon gyakori helyzet, amely gyakran rontja a teljesítményt, az alkalmazható karbantartási eszközök hiánya, például hibajelentő szoftver, változásmenedzsment szoftver és tesztkönyvtár szoftver. Az alábbiakban ismertetem néhány tényezőt és azok hatáskörét a szoftverkarbantartásra.
A kulcsfontosságú korrekciós tényezők hatása a karbantartásra (a maximális negatív hatás szerint rendezve) Karbantartási tényezők Mínusz tartomány Hibaveszélyes modulok -50% Beágyazott változók és adatok -45% A személyzet tapasztalatlansága -40% Magas kód komplexitás -30% Nincs Y2K speciális keresőmotorok -28% Kézi változtatásvezérlési módszerek -27% Alacsony szintű programozási nyelvek -25% Nincsenek hibakövető eszközök -24% Nincsenek Y2K „tömeges frissítés” specialisták -22% Rossz könnyű használat -18% Nincs minőségi mérés -18% Nincsenek karbantartási szakemberek -18% Gyenge válaszidő -16% Nincs kódellenőrzés -15% Nincsenek regressziós tesztkönyvtárak -15% Nincs help desk automatizálás -15% Nincs online hibajelentés -12% Menedzsment tapasztalatlanság -15% Nincsenek kódátalakítási eszközök -10% Nincs éves képzés -10% Nincsenek újratervezési eszközök -10% Nincsenek visszafejtő eszközök -10% Nincsenek komplexitáselemző eszközök -10% Nincs termelékenységmérés -7% Gyenge csapatmorál -6% Nincsenek felhasználói elégedettségi mérések -4% Nincs fizetetlen túlóra 0% Összeg -500%
Eltartási tartozás Egy 2019-es tanulmányban, amelyet John Estdale írt a 27. Nemzetközi Szoftverminőség-kezelési Konferenciára, bemutatta a "karbantartási adósság" kifejezést. Ez a karbantartási igényeket jelenti, amelyeket egy implementáció külső IT tényezőkre, például elavult könyvtárakra, platformokra és eszközökre való függősége generál. Az alkalmazás továbbra is fut, és az IT-osztály megfeledkezik erről a potenciális felelősségről, és inkább a sürgős követelményekre és problémákra összpontosít máshol. Az ilyen adósság idővel felhalmozódik, észrevétlenül fogyasztva a szoftvereszköz értékét. Végül olyan esemény következik be, amely megkerülhetetlenné teszi a rendszer változtatását.
Ebben az esetben a tulajdonos felfedezheti, hogy a rendszert már nem lehet módosítani - szó szerint karbantartásra képtelen. Kevesebb drámaian fogalmazva, túl hosszú ideig tartana, vagy túl sokba kerülne a karbantartás, hogy megoldja a vállalkozási problémát, és alternatív megoldást kell találni. A szoftver értéke hirtelen nullára esik vissza.