Szoftverkarbantartás
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.[1][2]
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.[3] 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.[4]
Történet
[szerkesztés]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.[5][6][7]
A szoftver karbantartásának jelentősége
[szerkesztés]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
[szerkesztés]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
[szerkesztés]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
[szerkesztés]E.B. Swanson eredetileg három karbantartási kategóriát azonosított: hibajavító, alkalmazkodó és fejlesztő.[8] Az IEEE 1219 szabványt 2010 júniusában felváltotta a P14764.[9] 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
[szerkesztés]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
[szerkesztés]Egy 2019-es tanulmányban,[11] 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.
Az Estdale a "karbantartási tartozást"[12] a következőképp definiálja: ez az eltérés az alkalmazás jelenlegi implementációs állapota és az ideális állapot között, amely csak olyan külső komponensek funkcionalitását használja, amelyek teljes körűen karbantartottak és támogatottak. Ez az adósság gyakran rejtett vagy felismeretlen marad. Az alkalmazás átfogó karbantarthatósága attól függ, hogy folyamatosan hozzáférhetőek-e a különböző típusú komponensek más szállítóktól, ideértve:
- Fejlesztőeszközök: forrásszerkesztés, konfigurációkezelés, fordítás és építés
- Tesztelési eszközök: tesztkiválasztás, végrehajtás/ellenőrzés/jelentés
- A fentiek végrehajtására szolgáló platformok: hardver, operációs rendszer és más szolgáltatások
- Termelési környezet és az esetleges készenléti/katasztrófavédelmi létesítmények, ideértve a forráskód nyelvének futási környezetét, valamint a munkafolyamat ütemezést, fájlátvitelt, replikált tárolást, biztonsági mentést és archiválást, egyszeri bejelentkezést stb.
- Külön megvásárolt csomagok, pl. adatbázis-kezelő rendszer, grafikai, kommunikációs, köztes réteg stb.
- Megvásárolt forráskód, objektumkód könyvtárak és más felhívható szolgáltatások
- Bármilyen követelmény, amely a termelési környezetet megosztó más alkalmazásokból származik, vagy amely az adott alkalmazással való együttműködést érinti
és természetesen
- A releváns szaktudás elérhetősége, legyen az vállalaton belül vagy a piac kínálatában.
Egy komponens teljes eltűnése miatt az alkalmazás újjáépíthetetlenné vagy azonnal karbantarthatatlanná válhat.
Hivatkozások
[szerkesztés]- ↑ ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance. Iso.org, 2011. december 17. (Hozzáférés: 2013. december 2.)
- ↑ Soleimani Neysiani (2020. október 1.). „Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems” (angol nyelven). Information and Software Technology 126, 106344. o. DOI:10.1016/j.infsof.2020.106344.
- ↑ Pigoski, Thomas M. (2002. január 15.). „Software Maintenance”. Encyclopedia of Software Engineering, Hoboken, NJ, USA, Kiadó: John Wiley & Sons, Inc..
- ↑ Eick, S.G., A.F. (2001. december 7.). „Does code decay? Assessing the evidence from change management data”. IEEE Transactions on Software Engineering 27 (1), 1–12. o. DOI:10.1109/32.895984. ISSN 0098-5589.
- ↑ Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
- ↑ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076
- ↑ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
- ↑ (1978. június 1.) „E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497”. Communications of the ACM 21 (6), 466–471. o, Kiadó: Portal.acm.org. DOI:10.1145/359511.359522. (Hozzáférés: 2013. december 2.)
- ↑ Status of 1219-1998 by IEEE Standards
- ↑ The Economics Of Software Maintenance In The Twenty First Century. [2015. március 19-i dátummal az eredetiből archiválva]. (Hozzáférés: 2013. december 2.)
- ↑ Proc of Software Quality Management XXVII: International Experiences and Initiatives in IT Quality Management. Southampton: Solent University (2019). ISBN 978-1-9996549-2-4
- ↑ Estdale, John. Delaying Maintenance Can Prove Fatal. in [11], 95–106. o.
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Software maintenance című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
További irodalom
[szerkesztés]- ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. DOI: 10.1109/IEEESTD.2006.235774 (2006). ISBN 0-7381-4960-8
- Pigoski, Thomas M.. Practical Software Maintenance. New York: John Wiley & Sons (1996). ISBN 978-0-471-17001-3
- Pigoski, Thomas M.. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area
- April, Alain. Software Maintenance Management. New York: Wiley-IEEE (2008). ISBN 978-0-470-14707-8
- Gopalaswamy Ramesh. Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill (2006). ISBN 978-0-07-048345-3
- Grubb, Penny. Software Maintenance. New Jersey: World Scientific Publishing (2003). ISBN 978-981-238-425-6
- Lehman, M.M.. Program evolution : processes of software change. London: Academic Press Inc (1985). ISBN 0-12-442441-4
- Page-Jones, Meilir. The Practical Guide to Structured Systems Design. New York: Yourdon Press (1980). ISBN 0-917072-17-0