Kezdőlap
Szolgáltatások
Hírek
Őszbúcsúztató Bécsben
Elvileg el lehet jutni egy tökéletes kódig
December 20, 2007
Különbözik a multinacionális és a magyarországi szoftverfejlesztők munkamódszere – jelentette
ki lapunknak Privitzky Gábor, a Qualysoft Informatikai Zrt. szoftverfejlesztési ágazatának
igazgatója. Véleménye szerint bár elméletileg lehetne hibátlan szoftvereket írni, ám ez olyan
költséges lenne, hogy nincs is rá igény.
- Ön fejlesztett szoftvert multinacionális cégnél és korábban is és most is magyar tulajdonú társaságnál is. Milyen különbségeket tapasztalt?
- Egy biztos, más a magyar valóságban dolgozni. Több évet eltöltöttem multinacionális cégnél, s láttam, hogy a társaságnak van fejlesztési iránya, tudja, hogy milyen termékeket akar a piacra vinni, és ezeket közli is a piaccal. Ennek megfelelően a saját termékeihez saját környezeteket is gyárt, mind hardver, mind szoftverműködtetési környezeteket, és a fejlesztések ebben történnek. És persze nagyon messze van programozóktól a vevő. A multiknak a saját rendszereik tekintetében, nagyon nagy a termékismeretük, nagyon pontosan megfogalmazottak a követelmények. Az egyedi alkalmazásokat fejlesztő magyar cégek esetében közvetlenül megjelenik a vevő, a munka során ott “ szuszog” a programozó fülébe, azonnal reagálva a megszülető alkalmazás egyes moduljaira. Ez egész más projektvezetési és fejlesztési módszertant kíván.
- A Qualysoft érzésem szerint egy kicsit kilóg mind a két csoportból, hiszen bár magyar a cég, de Németországban alapították, és onnan terjeszkedett haza. Melyik kultúrához áll közelebb a társaság?
- Egyértelműen a felhasználó-központú fejlesztéshez áll közelebb, mint a multik által működtetett hatalmas szervezeti berendezkedéshez. Itt teljesen egyértelműen látjuk azokat a felhasználókat, akik majd az alkalmazásunkat élőben fogják használni, és ahhoz próbáljuk igazítani mind módszertanilag, mind technológiailag a lépéseinket, azért hogy a megrendelő elégedett legyen. Mindig az adott felhasználónak megfelelő technológiai környezetet próbálunk kialakítani, ami elég nagy dinamikát is jelent a csoporton belül. Ez azt jelenti, ha a vevőnek az a kérése, hogy márpedig ehhez vagy ahhoz a technológiai környezethez kell az elkészülő alkalmazásnak illeszkedni, akkor azt nekünk meg kell tanulni. Vagyis meg kell értenünk, hogy mik a megrendelő igényei, és nekünk kell ehhez alkalmazkodnunk. Ez nem a klasszikus “dobozos” szoftverfejlesztés, hogy mi megmondjuk, hogy mit tudunk, és azzal oldjuk meg a végfelhasználó problémáját, hanem mi alkalmazkodunk a végfelhasználókhoz.
- Nem tehetem meg, hogy ne kérdezzem meg a véleményét a programhibákról. Gyakorlatilag a programozás kezdete óta sulykolják a szoftvergyártók, hogy hibamentes szoftver nem létezik. Ön szerint igaz ez?
- A hibákat több részre kell bontani. A projektek kezdetén, a vevő igényei alapján felállítunk egy követelményspecifikációt, ami az egyik alapköve az elkészülő alkalmazásnak. A hibák egy része úgy jön létre, hogy már a követelményspecifikáció létrehozása során kialakulhat némi disszonancia. Ez egész egyszerűen abból fakad, hogy a felhasználó se biztos, hogy mindig érti, hogy mit szeretne, mi is félreérthetünk ezt-azt, s végül a félreértésekből eredő hibát szépen átvisszük az alkalmazásba. A hibák másik része egész egyszerűen abból fakad, hogy nagyon nagy kódtömegek állnak elő ezeknél az alkalmazásoknál. Valójában úgy kell elképzelni az alkalmazásainkat, hogy nagyon sok kódrészletet felhasználunk a háttérrendszerekből, nagyon sok kész kódot bevonunk. Ezeknek a kódoknak az egymáshoz hangoltsága nem biztos, hogy mindig a legsikeresebb.
- Ennek ellenére léteznek elégedett vevők?
Igen. A jó minőség biztosításának alappillére a tesztelés, az elkészült vagy készülőben lévő rendszer folyamatos ellenőrzése. A komoly rendszerek nagyon sok elágazási pontból állnak. Amikor tesztelünk, megpróbáljuk felosztani az alkalmazásunkat olyan részegységekre, amelyeket önmagukban lehet tesztelni, ezeket utána összerakjuk és együtt is leteszteljük. Ugyanakkor az élő környezetben történő használat során előfordulhatnak olyan bejárási utak az alkalmazásban, amelyeket nem tudtunk tesztelni, mert az alkalmazásban bejárható utak számossága akkora, hogy minden lehetséges bejárást végigtesztelni képtelenség. A minőség mindig azon múlik, hogy mekkora energiát, pénzt fektetünk abba, hogy az alkalmazás helyességét leteszteljék. El lehet jutni addig a pontig, ahol azt mondhatom, hogy megtalálhatok ugyan még több hibát, de még egyszer ekkora erőfeszítést, pénzt kell befektetni az alkalmazás tesztelésébe. Elvileg el lehetne jutni a tökéletes kódig is, gyakorlatban azonban kivitelezhetetlennek tartom, már csak azért is, mert amikor a hibajavítások történnek, új hibát vihetek be a kódba. Az a véleményem erről, hogy el lehet - és el is kell érni -, egy olyan optimumot, aminél azt lehet mondani, elkészült egy jó minőségű alkalmazás, amit a felhasználó megelégedéssel fog és tud használni.
- Ideális esetben milyen arányokat képviselnek a fejlesztés folyamatában a különböző folyamatok?
- Maga a fejlesztés, a kódolás a teljes projekt költségének nem lehet több, mint az 50 százaléka. A tesztelésre, a Qualysoftban meglévő szabályok szerint, legalább feleannyi időt fordítunk, mint az alkalmazás kifejlesztésére. A fennmaradó idő és költség az üzleti elemzésre, és az egyéb projektmenedzsment feladatokra megy el.
- Milyen irányba halad a programozás?
- Ha csak a programnyelvekről beszélünk, azt látom, hogy azok a nyelvi környezetek fognak előtérbe kerülni, ahol speciális problémakörökre speciális nyelveket lehet definiálni. Ma már léteznek olyan nyelvi környezetek, ahol lehetőség van arra, hogy úgynevezett domainspecifikus nyelveket definiáljunk. Mondjuk, ha egy számlakezelő-rendszert szeretnék írni, akkor van egy alapnyelvem, az alapnyelvre pedig rá tudom fejleszteni azt a domainspecifikus nyelvet, amivel a számlákat könnyen tudom mozgatni és az adott problémát meg tudom oldani. Ezután a programozók nagy része már ezen a domainspecifikus nyelven fog dolgozni, ebben az újonnan megalkotott nyelvi környezetben fogja magvalósítani a leírt követelményspecifikációt.
Napi informatika - 2007.12.20.
+36 88 429 453
