A szoftverhiba

Az esetek egy részében az ERP cserék kiváltó oka egyértelműen a vevő – szállító viszony megromlása, de majd minden más esetben közvetett okként ez is jelen van. A viszony megromlása pedig mindig kapcsolatban van a szoftverhibákkal, azok kijavításával vagy hibával kapcsolatos félreértésekkel. Ezért fontos a szoftverhibákkal is foglalkoznunk.
Ezzel a fejezettel arra szeretnénk rámutatni, hogy a szoftverhibákkal márpedig együtt kell élnünk.

Most rögtön szögezzük le. A szoftverhibák többsége a hanyag-szemét programozási munkából fakad, amikor 3-4 hónapos tanfolyamokon rosszul képzett programozókra bízunk fontos fejlesztési feladatokat. 
Azt is ki kell mondani, hogy a felhasználónak nem feladata tesztelés, sőt, semmilyen tesztelés nem bízható a felhasználóra, így a felhasználót semmilyen felelősség nem terheli, bármilyen szintű szoftverhiba kerül felszínre.

Szoftverhibák miatt emberek haltak meg, dollármilliárdos káresetek történtek, tízezrével hívták vissza az autókat stb. így biztosak lehetünk abban, hogy nem egyszerű a kérdés. Nem beszélve arról, hogy már most elárasztják az élet minden területét szoftverek, holott még csak most indult meg ez a fejlődés. A termelésirányításban már régebb óta hirdetjük, hogy mindent, amit egy gép el tud végezni, azt a géppel kell elvégeztetni. Ez bizton azt eredményezi, hogy a termelés minden területén ugrásszerűen növekszik majd a szoftverhibák száma is. Egyetlen lehetőségünk van, megtanulni együtt élni a hibákkal.

De mi is az a fránya szoftverhiba?
Hibásnak mondjuk a szoftvert, ha a megadott inputra nem az elvárt eredményt adja, vagy a tervezettől eltérően viselkedik. A hibák döntő többsége a programozók által írt forrásprogramban található, de egy részük a program struktúrájában van, ami már tervezési hiba és okozhatja a hibát a környezet rendellenes működése is.
Rögtön felvetődik néhány kérdés. Hibás-e a szoftverünk, ha rosszul van telepítve az operációs rendszer vagy az adatbáziskezelő? Hiba-e, ha hibás inputra kapunk nem várt választ? A válasz egyszerű. Igen, hibás. A szoftvernek észre kell vennie, hogy a környezet hibás és a hiba kijavításához elegendő információtartalmú üzenetet kell küldenie.

A felhasználó számára minden hiba, ami az üzleti funkciót károsan befolyásolja.

Azonban hiba-e, ha a szoftver nem a termelésben dolgozók elvárása szerint működik? Hiba-e, ha a fenti definícióban maga a „tervezett viselkedés” hibás?
Ezek viszont nem szoftverhibák.

Tehát szükség van tehát egy ökölszabályra.
A szoftver akkor hibás, ha nem úgy működik, mint az átvételhez kapott dokumentáció vagy megszegi a működésére vonatkozó jogszabályokat továbbá  az alapvető (matematikai és logikai) szabályokat. Ha ezen a ponton nem tud a szállító és a felhasználó megegyezni, akkor minden további vita nélkül szakemberhez kell fordulni.

Mit is jelent ez?
Amikor átadunk egy igényjegyzéket, akkor a vevő azt igazolja aláírásával, hogy valóban ezt adta meg elvárásként (és csak ezt), de ez nem kötelező érvényű a szállítóra nézve. A szállító adhat jobb megoldást is és gyengébbet is, amit a vevő elfogadhat. Ezt követően a szállító ad egy részletes specifikációt, amit szintén mindketten aláírnak. Ha ebben a dokumentációban van olyan rész, ahol a szoftver működése eltér a leírtaktól, akkor hibás a szoftver.
Ha átvettünk egy olyan dokumentációt, amely nem szabályozott fontos részleteket, akkor jönnek a törvényi előírások. Így, ha rosszul számol ÁFÁ-t és ebből kár keletkezett, akkor nincs min vitatkozni, bíróságot neki.

Sajnos ez sem ennyire egyszerű. A kérdés ugyanis az, hogy kinek a költsége egy átadást követően történt törvénymódosítás átvezetése a rendszeren. A jó megoldás az, hogy a szerződésben lerögzítjük az ilyen kérdéseknek a megoldását. PL. úgy, hogy a szállító kötelessége a mindenkori hatályos törvényeknek való megfeleltetés. (Amit a szállító vagy elfogad vagy nem. Azt viszont mindenképpen ki kell kötni, hogy a szállító köteles figyelmeztetni, ha olyan törvényi módosítás történt, ami érinti a rendszerét. Ebből ne engedjünk.)

Jönnek azok a problémák, hogy 2+2=5. Az ilyenek megszegik a matematika és logika alapvető szabályait. Tehát szoftverhiba. Igen ám, de pl. a 2+2=4.00000000012 már csak akkor hiba, ha a dokumentáció szabályozta a kerekítést és annak ez nem felel meg.
Az össze többi esetben a szoftver nem hibás, hanem olyan amilyen.

Lépjünk tovább….
A szoftverhibának van jogi vetülete, szakmai vetülete és erkölcsi vetülete.
A szoftver jogi vetülete akkor kerül elő, ha bizonyítani tudjuk, hogy program eltér a dokumentációtól.

Igen ám, de a jogrendünk ismeri a szóbeli szerződés jogintézményét, így módunk van megegyezni a fejlesztővel bármilyen szamárságban, amire szóbeli szerződést is köthetünk. Na, ezt az utat most rögtön felejtsük el. Személyes véleményem (a szerző), hogy a Kutyaütő Bt. által a sufniban tákolt bármely programszörnyeteg műalkotás a jogrendszerünkhöz képest, ezért megjósolhatatlan, hogy mi egy ilyen per kimenetele.

A szakmai vetületet akkor jön elő, amikor valami fontos dolgot nem tartalmazott a dokumentáció és a fejlesztés rosszul oldotta meg az utólag felmerült feladatot. Sajnos egyértelműen az a hibás, aki átvette a fejlesztés által benyújtott dokumentációt. Ezzel a kérdéssel azért érdemes foglalkozni, mert általában ez vezet a felhasználó / fejlesztő viszony megromlásához. Vannak egyszerűbb esetek, amikor a fejlesztés valójában jó megoldást ad a feladatra, de az nem jól alkalmazható a megbízóra. És van az, amikor a fejlesztő azt mondja a rossz megoldásra, hogy az egy feature (szolgáltatás). Ezt az esetet szemlélteti az alábbi – számomra (szerző) ismeretlen mester – alkotása.

Ilyen esetben bármennyire bosszantó is, a vevőnek meg kell rendelnie a módosítást.

A „Bug” kifejezést 1878-ban Thomas Edison használta először egy mechanika meghibásodására. Tehát messze az informatikai szóhasználat előtt lett a mérnöki szakzsargon része. Az informatikába Grace Hopper – a Mark II egy meghibásodásának a javításakor – hozta be, amikor felfedezett egy relébe szorult lepkét. A bugot természetesen annak rendje és módja szerint naplózta: beragasztotta a hibanaplóba a lepkét. Érdekes, hogy Hopper nem tudott a mérnöki szóhasználatról.

A szakmai becsület lenne hivatott megoldani a bonyolult (vitatható vagy közös-felelősségű) kérdéseket. A partnerünket mi választottuk, ha nem vagyunk megelégedve velük hát magunkra vessünk.

Ahhoz, hogy lássuk mennyire bonyolult a szoftverhiba kérdése, meg tudjuk ítélni mi az, ami elvárható és mi az, amit a fejlesztővel együttműködve kell megoldani, látnunk kellene a szoftverhibák osztályozását.

Van olyan nézet, hogy a szoftverhibák a gondolkodásunk melléktermékei, így ahhoz, hogy ne kövessünk el ilyen hibákat ismernünk kéne a gondolkodásunkat is. Ez viszont nem fog menni.
Miután a szoftverhiba azért keletkezik, mert a programozó hibásan értelmezi az általa leírt programsorokat, ezért a problémát a klasszikus filozófiai megközelítéssel is tanulmányozni kezdték. A filozófiában a hermeneutika foglalkozik az értelmezés és megértés tudományával. A tudományág a nevét Hermészről (nevének jelentése megvilágít) az isteni bölcsesség birtokosáról kapta.
A napi gyakorlatban a szoftverhibákat teszteléssel lehet megtalálni. Minden fejlesztőrendszer tartalmaz vagy javasol strukturált tesztelési módszereket és biztosít hozzá eszközöket is. Itt is van egy kis érdekesség. Ha van egy gépműhelyünk, amelyben előállítottuk azokat a mérőeszközöket és sablonokat, amivel dolgozunk és ellenőrzünk, biztosak lehetünk abban, hogy a termékünk minősége még azt a szintet sem fogja elérni, amivel a mérőeszközünk rendelkezik.
Miért lenne ez más a szoftverek esetében?
Tehát ha a tesztelő eszközöket (pl. automatikus teszteléshez vagy a regressziós teszteléshez) szoftverrel fejlesztettük és azok a munkatársak tesztelnek, akik a termelésirányítási rendszer is fejlesztik, elvileg sem keletkezhet hibátlan program. Ezért a cél nem a hibátlanság, hanem az üzletmenet korlátozás nélküli fenntartása.
A hibák számának csökkentésére vannak érdekes javaslatok. A Toyota a Lead rendszerben működő gyártósorára azt az elvet alkalmazza, hogy ha valahol selejtet találnak, akkor leáll a szalag a selejt javításáig és a selejt okának megtalálásáig. A javaslat úgy szól, hogy alkalmazni kell a „Stop the Line” módszert a szoftverfejlesztésre is. Az ötlet nem ördögtől való. Abból indul ki, hogy egyrészt a hibát azonnal javítani kell másrészt, ha a szoftverhiba túljutott a beépített és külső tesztelési eljárásokon, akkor az eljárásokban van a hiba. A fejlesztést a hiba okának meghatározásáig azért kell leállítani, mert nem lehet tudni, hogy hány helyen van még benne ugyanez a hiba, vagy ennek a hibaosztálynak másik eleme. Márpedig minél mélyebben van egy hiba, annál költségesebb a javítás, ezért a legolcsóbb az azonnali javítás.
Tehát ha nem állítják le a fejlesztést akkor tudatosan vállalják ennek az összes következményét. Ez is járható út.
A szoftverfejlesztőknek kidolgozott tesztelési módszerek állnak rendelkezésre (unit teszt, integrációs teszt, regressziós teszt stb.), támaszkodhatnak továbbá teszt eszközparkra (TestSigma, Szelén, stb.) és vannak kifejezetten erre szakosodott nagyon jó közösségi oldalak is, de ez a fejlesztők belső ügye a felhasználónak nincs beleszólása, csak a végeredménybe.
Meg kell értenünk hibák keletkezését is, hogy el tudjuk azokat fogadni, ill. tudjuk kezelni.  A hibákat osztályozni szokás, mert a hibaosztályok más-más szinten keletkeznek és másként is kell kezelni őket.
A hibák jelentős részét egyértelműen a programozók követik el.

• • Szintaktikai hibáról beszélünk amikor a programozó egyszerűen elnéz valamit. Ez nem kerül ki a felhasználóhoz csak az interpreteres programok esetén.
  • Szemantikai vagy logikai hibáról akkor beszélünk amikor egy programozó az algoritmusban hibázik, pl. rosszul ír meg egy optimalizálást. Nem sorolnám azonban ide pl. azt, ha a gyártásütemezés nem az elvárásnak megfelelően működik. Egy programozónak nem feladata a gyártás részletes ismerete. Ezt általában a vevő veszi észre, mert a tesztelési módszerek nem mutatják ki és futási hibát sem okoz.
  • És van futási hiba. Ez az az eset, amikor munka közben jön valamilyen üzleti tevékenységtől független, értelmezhetetlen üzenet, a program kilép esetleg az egész rendszer lefagy (semmire nem reagál), de van egy olyan esete is, amikor az adatok megsemmisülnek. A szakzsargon ezt Hindenbug hibának nevezi, a léghajó katasztrófára utalva.
  • A biztonsági hiba a hozzáférési rendszerben lévő olyan anomália, amely lehetővé teszi illetéktelenek hozzáférését a rendszerhez és az adatokhoz. Nem is hibának, hanem sérülékenységnek nevezzük és az sem biztos, hogy a szoftverfejlesztő hibája. Önálló programok állnak rendelkezésre, amelyek az ilyen hibák egy részét képes feltárni.
  • Vannak továbbá specifikációs hibák, amelyek a felhasználói követelményjegyzék és az ajánlatkérés hibái. Ezek lehetnek felhasználói hibák, azonban, ha a beszállító (díjazás mellett) egy saját felmérést is készít, akkor ez már a fejlesztés hibája lesz. Ugyanis ekkor már dokumentálási kötelezettsége van, így nem hivatkozhat arra, hogy nem szerepel a dokumentációban.

Van másféle osztályozás is, ami jól tükrözi a hiba bonyolultságát.

• • Schrödinbug. Schrödinger non intuitív elveken gondolkozó fizikus. Ide azok a hibák tartoznak, amelyeket sem a fejlesztő, sem a felhasználó nem vesz észre és csak akkor okoz észlelhető a hibát amikor kijavítják 😊 Ez a hiba általában a fejlesztőkörnyezetben vagy hibakereső programban van és általában a programszöveg elemzésekor derül ki.
  • Heisenbug. A Heisenbergről (szintén egy elvarázsolt fizikus) elnevezett hiba csak akkor nem lép fel, ha fut hibakereső, így nem lehet egyszerűen hibát keresni.
  • Higgs bug. Peter Higgs fizikus után, a bozon részecskéről „Higgs-bugson”-nak is nevezett hiba. Ez egy olyan hiba, amit csak a körülményekből pl. a rejtélyes naplóbejegyzésekből lehet megjósolni. Szörnyű nehezen lehet észrevenni és javítani.
  • Bohr bug (szintén fizikus). A Bohr hiba minden programozó álma, ez az, amely úgy viselkedik ahogy mutatja magát, nem küld aknára, nem rúg hasba és minden következetes metódussal megtalálható.
  • Mandelbug (Benoit Mandelbrot matematikusról elnevezve). Ez egy olyan hiba, ami annyira összetett, hogy már kaotikusnak tűnik. Addig nem lehet kijavítani, amíg nem sikerül stabilan reprodukálni. A baj az, hogy nem lehetünk biztosak abban, hogy reprodukálható. Ide tartoznak pl. a lefagyások.
  • És ide sorolnám még a banális hibát is (banális nem fizikus). A banális hiba abban különbözik a Bohr hibától, hogy ennek oka a hanyagság vagy a munka összecsapása.

A hibákat üzleti szempontból is osztályozni kell. Ez a felhasználó dolga. A felhasználó joga annak megítélése, hogy egy hiba mennyire súlyos, a fejlesztő azonban adhat hozzá tanácsot, aki általában abból indulni ki, hogy a hiba mennyire hátráltatja az üzleti tevékenységet. A fejlesztő azonban sokszor rosszul látja a kérdést. Például jelentéktelennek ítélt egy feleslegesen lenyomandó ENTER-t. Igen ám, de a felhasználó ezt 100 000-szer nyomja le. Hasonló a helyzet pl. az ékezetekkel és a helyesírási hibákkal. Ha a felhasználó súlyosnak ítéli, akkor az is, mert ilyenkor a felhasználó kétségbe vonja, hogy valaki, aki nem volt képes megtanulni az anyanyelvének a szabályait képes lehet-e megtanulni a szoftverfejlesztés szabályait.

Tehát nyugodtan induljunk ki abból, hogy vannak és lesznek szoftverhibák. Nem mindegy azonban, hogy milyen okok miatt keletkezett, mennyi van belőlük és mennyire befolyásolja a működésünket.
Mindenesetre rögzítsünk néhány alapelvet.

• A szoftvert a vevő fizeti, a vevő határozza meg az elvárásokat.
• A vevő az igényeit üzleti szinten határozza meg.
• A vevő sohasem tesztel, nem feladata a hibakeresés.
• A garanciális időn belül a hibák kijavítása ingyenes.
• A vevő határozza meg, hogy egy hiba mennyire súlyos.
• A vevő határozza meg, hogy egy hiba kijavítása mennyire sürgős.

Mielőtt tovább lépünk foglalkozni kell a szoftver minőségével is. Ez azért érdekes mert a szoftverhiba, illetve a szoftverhibák jellege csak egy komponense a szoftver minőségének. A minőségnek azonban nézetei vannak, melynél meg kell különböztetnünk kereskedői, gyártói, vevői és szakmai minőségnézetet. Ha egy szoftvert (melyet a szóbeszéd szerint) több mint 20 000 példányban tudnak eladni és működtetni, akkor a kereskedő joggal értékeli egy kiváló szoftvernek. Miután évekig hozzá sem kell nyúlni és viszik, mint a cukrot, a gyártó is roppant elégedett vele. Minden gyártó ilyenről álmodik.
Nézzük most a felhasználói minőséget. Nos, ha egy könyvelő simán kiad a kezéből egy hibás főkönyvi kivonatot, akkor ez a szoftver neki is tökéletesen megfelel. Sőt, fizetni kell egy méregdrága könyvvizsgálót, aki mindig, mindent rendben talál. Ezt is. És ha rendszer nevére rákeresünk az interneten, akkor az első oldalon megjelenik egy hírhedt adótanácsadó cég, amelynek PHD-s munkatársa alkalmasnak találta egy tanulmányban ismertetni ezt a kiváló terméket. Aztán itt van a NAV. Ez a szoftver megsérti a számviteli törvényt. Ha milliárdos cégek használnak ilyen minőségű belépőszintű szoftvereket, akkor talán beleeshetne már a NAV érdeklődési körébe is. De nem. Tehát a vevői minőség sem magától értetődő, ugyanis a vevőnek is van minősége.
Akkor meg mi a baj?
Az, hogy van informatikai szakma és van szakmai minősítés is. Ebből a szempontból pedig ez egy borzalmas szoftver.
Ennek ellenére nem érdemes egy ilyen szoftverre figyelmet fordítani. Annál a cégnél, amelynél csak 25 000 Ft-ot lehet egy könyvelési szoftverre fordítani, a többi mellett a szoftverminőség említésre sem méltó probléma.

Ha érteni akarjuk a jelenséget, akkor felhasználó szinten is fontos látni a hibák okát.
A hibák tömeges megjelenésének az egyik oka magában a szoftverfejlesztés folyamatában van. Anno így nézet ki egy fejlesztés:

Azaz a marketing, majd az értékesítés csak a kész, gyártható termék meglétekor kezdődött.

Ez ma ilyen:

A marketing gyakorlatilag már akkor elkezdődik, mikor a szoftver alig több egy csalafinta ötletnél és a piaci megjelenéskor is épphogy működőképes. Ezt követik a frissítések, az „SP-k”, és ezek során alakul ki az igazán működőképes rendszer. A megoldásnak kétségtelenül hatalmas előnye, hogy a fejlesztés jó részét maga a vevő finanszírozza meg, másrészt rengetegen vesznek részt a tesztelésben és a végső verzió kialakításában.
Sajnos a módszer elterjedése nagyon nagy károkat okozott. A legtermészetesebb dologgá vált, hogy egy szoftver itt-ott elszáll, hogy értelmetlen és érthetetlen üzeneteket küld, hogy állandóan változik, és mire igazán beáll a működése, a felhasználó megérti a gondolatmenetét és megszokja használatát, megjelenik a következő „félkész” verzió.

Ne higgyük, hogy ez csak a szoftveripar sajátossága. Az autószalonok „ülőpróbája” úgy keletkezett, hogy a luxus kategóriás gyártó Genfben kiállított autójába nem fért bele a motor, ezért egy hengert flexszel levágtak.
Volt olyan közismert sportautó szerűség, amelynek „SP1” nélküli kiadása a hidak lefutó ágában szó szerint elszállt.

Ez tehát egy stratégia. Ez ellen úgy kell védekezni, hogy az ember nem veszi meg a frissen kiadott szoftvereket.

A kérdés az, hogyan lehet csökkenteni a számukat és hogyan lehet együtt élni a hibákkal.
A legfontosabb annak megértése, hogy a szoftverek különböző minőségűek. Vannak gyengébbek és vannak jobbak. Van továbbá a dobozos szoftver. A dobozos szoftvert a forgalmazó nem fogja sem javítani, sem testre-szabni. Ez olyan amilyen, ezért olcsó. Azonban itt sem csak az elszenvedés az egyetlen lehetőségünk, mert a törvényeknek ezeknek is meg kell felelni.
A jó minőségű, nagy szolgáltatási portfólióval rendelkező, így drága szoftverek sem hibamentesek. A magasabb ár nem hibamentességet ígér, hanem jobb használhatóságot és gazdagabb funkcionalitást. Itt azt már elvárjuk, hogy az alapverzió ne produkáljon nem tervezett kilépést és ne legyen hiba a funkcionalitásában.

A szoftver árát a fejlesztőeszközök ára, a fejlesztők felkészültsége és folyamatos képzése, valamint a tesztelés elve, eszközrendszere és főleg a mennyisége határozza meg. Ha kevesebb hibát akarunk a rendszerben, akkor drágább szoftvert és több tesztelést kell megrendelnünk, de az átvétel előtt megbízhatunk külső tesztelőket is.
Felmerül azonban az a kérdés, hogy meddig kell teszteltetésre költeni és mikor jobb megoldás, ha a hibákkal való együttélésre költünk.