DIPLOMADOLGOZAT SZOMMER KÁROLY KAPOSVÁR 2010.

Átírás

1 DIPLOMADOLGOZAT SZOMMER KÁROLY KAPOSVÁR 2010.

2 KAPOSVÁRI EGYETEM GAZDASÁGTUDOMÁNYI KAR INFORMATIKA TANSZÉK Relációs adatbáziskezelőben tárolt fizetési felszólítások adatainak feldolgozása Java nyelven Készítette: SZOMMER KÁROLY V. évfolyam Folyamatszabályozó mérnök szak Témavezető: DR. CSER LÁSZLÓ Egyetemi tanár Társkonzulens: Dr. KÖVÉR GYÖRGY Egyetemi docens Tanszékvezető: DR. CSUKÁS BÉLA Egyetemi docens 2010.

3 TARTALOMJEGYZÉK 1. Bevezetés A vállalatok és az informatikai beruházások Célkitűzés Irodalmi áttekintés SAP SQL A Java programozási nyelv, a NetBeans IDE fejlesztési környezet, és a Java Excel API csomag A Java programozási nyelv A NetBeans IDE fejlesztési környezet A Java Excel API csomag Programfejlesztés A programozó A szoftverfejlesztés nehézségei Követelményelemzés Jackson-féle programtervezési módszer Szoftver modularitás A szoftverprototípus elkészítése Felhasználói felületek Hibakeresés Adatbányászat és adattárházak A Kaposvári Cukorgyár fizetési felszólításának eddigi feldolgozási módja Az informatikai háttér és a fizetési felszólítás alapjai Az eddigi folyamat főbb technikai részletei Egy vizsgált eset folyamatainak leírása A vizsgált folyamat pénzügyi oldalról Az eddigi folyamat nehézségei, kritikus hibalehetőségei, annak lehetséges következményei A kifejlesztett szoftver Célkitűzés Követelmények Fogalomtár Használati esetek A kimenő adatokkal kapcsolatos követelmények Nem funkcionális követelmények Bemeneti adatok specifikációja A programfejlesztési nyelv, környezet, és módszer kiválasztása A moduláris felépítés bemutatása Az osztályok és főbb algoritmusok bemutatása A program által használt SQL adatbázis szerkezetének bemutatása A grafikus felhasználói felület kialakítása A szoftver tesztelése A tesztadatok meghatározása és tesztelés tesztadatokkal Tesztelés éles adatokkal A program hardver- és szoftverigénye, telepítése, használatának bemutatása A kimeneti adatok további felhasználása A szoftverfejlesztés során felmerülő főbb programozási problémák és megoldásaik

4 4.13. A fejlesztés során felmerült egyéb nehézségek A szoftver bevezetése Az új munkafolyamat és becsült költsége Pénzügyileg nem mérhető előnyök Javaslattétel a bevezetési folyamatra A bevezetéssel járó munkaidő- és költségváltozások Összefoglalás Következtetések és ajánlások Irodalomjegyzék Nyilatkozat

5 1. BEVEZETÉS 1.1 A vállalatok és az informatikai beruházások A nagyobb vállalatoknál egyre nagyobb hangsúly helyeződik az egyes munkafolyamatok számítógéppel történő támogatására. Makroökonómiai szempontból a vállalatok IT-beruházásai pénzügyileg egyértelműen pozitív eredményességűek [SZATMÁRI, 2008]. Kielemezve a munkafolyamatok számítógépes támogatásának lehetőségeit, azok költségét, megtérülési idejét, amennyiben gazdaságosan megvalósítható, célszerű az ilyen irányú fejlesztést mielőbb elkezdeni. Nem csak értékes munkaidőt takaríthatunk meg, vagy csoportosíthatunk át más munkafolyamatokra, de csökkenthetjük a munkahelyi stresszt, a hibák előfordulását és új lehetőségeket teremthetünk meg egy-egy ilyen beruházással. 1.2 Célkitűzés A Magyar Cukor Zrt. Kaposvári Cukorgyárában töltött szakmai gyakorlatom ideje alatt egy hasonló feladat megvalósítását tűztem ki célul, amivel a diplomadolgozatom is kapcsolatos: a fizetési felszólítások számítógéppel történő feldolgozásának támogatását. Kimondottan fizetési felszólítások feldolgozásának módjával kapcsolatos szakirodalmat nem találtam, így az általam feldolgozott szakirodalom a megvalósítás lehetséges eszközkészleteivel, a szoftverfejlesztés menetével, a felhasznált technológiákkal, módszerekkel foglalkozik. Elemzem mind idő, mind pénzügyileg az eddigi folyamatot, ahogy a fizetési felszólításokat jelenleg elkészítik, egészen az SAP rendszerbe 4

6 történő belépéstől a fizetési felszólítási levelek feldolgozásáig. Ismertetem a követelményeket, felépítem a szükséges fogalomtárat, bemutatom a használati eseteket, a be- és kimenő adatokat, a feldolgozott szakirodalom alapján kiválasztom a fejlesztési nyelvet és a fejlesztői környezetet, bemutatom milyen modulokból épül fel az általam elkészített program, milyen osztályokkal rendelkezik, majd részletezem az osztályokat. Leírom a felhasznált SQL adatbázis szerkezetét, oszlopainak tulajdonságát, majd beszámolok az elkészített grafikus felhasználói felületről. Bemutatom a tesztelést teszt és éles adatokon, valamint a tesztelés során felmerült hibákat, ezeknek okait és javítását. Részletezem a program hardver és szoftver követelményeit, telepítését, használatát. Leírom, hogy a kimeneti adatokon milyen további munkálatokat kell elvégezni, valamint a fejlesztés során felmerült főbb problémákat, melyeket meg kellett oldani. Bemutatom a szoftver elkészülte utáni munkafolyamatot, a becsült költségeket, a pénzügyileg nem mérhető előnyöket, valamint javaslatot teszek a bevezetésével kapcsolatban. Összehasonlítom a program használata nélküli folyamatot az új folyamattal idő és pénzügyi szempontból, valamint kitérek a további fejlesztési lehetőségekre is. 5

7 2. IRODALMI ÁTTEKINTÉS 2.1. SAP Az SAP a világ vezető integrált vállalatirányítási rendszere (Enterprise Resource Planning, ERP). Az ERP egy adott vállalat minden vállalati folyamatát lefedő programcsomag ben alakult az SAP AG, Németországban. Az eredeti neve Systemanalyse und Programmentwicklung volt, amely a következőt jelenti: Rendszerelemzés és programfejlesztés. Később ezt átértelmezték, így az új név Systeme, Anwendungen und Produkte in der Datenverarbeitung lett, melynek a jelentése: Rendszerek, alkalmazások és termékek az adatfeldolgozásban (angolul: Systems, Applications and Products in Data Processing). Az R/2-es rendszerrel érték el az első nagyobb sikert, ezt közel 3000 vállalat használta, majd a 90-es évektől, az R/3 rendszerrel a fejlődésük üteme tovább nőtt. Az R/3-as telepítések száma 1993-tól 2004-ig folyamatosan bővült, 2004-ben a et is elérte [HERNANDEZ, 2007]. Az R/3-as rendszeren belül is több verziót különböztethetünk meg, azonban talán az egyik legfontosabb állomás az R/3 3.1, ahol a rendszer már képes volt az internetes kapcsolat kezelésére is, valamint a másik az R/3 4.5, ami már előre elkészített üzleti folyamatok tömegét tartalmazta, így nagyrészt elegendő volt a vállalatok igényeinek kielégítésére. Minden rendszer a legjobb üzleti megoldásokat integrálja és bár a vállalatoknak a versenyelőny megtartására a saját SAP rendszerüket testre kell szabniuk, a túl nagy eltérés nem ajánlott, mivel igen magas költséget 6

8 jelent a rendszer testreszabása, ezért ajánlott a saját vállalati struktúrán módosítani amennyiben az lehetséges, hogy minél kisebb átalakítást kelljen véghezvinni az SAP rendszeren. Az SAP minden iparág számára specifikus rendszereket kínál. A specifikusság jól szemléltethető az amerikai Lockheed Martin cégnél alkalmazott SAP rendszerrel, azon belül is az RFID (Radio Frequency Identification, azaz rádiófrekvenciás meghatározás) kezeléssel [BJORENDAHL, 2004], valamint az SAP különböző, egyéb cégeknél végzett kutatásaival, és jövőképével [KUBACH, 2005]. Az SAP R/3 hardveres kialakítása kezdetben három rétegű volt, melyben az első réteg az adatbázis szerver, amely adatbázis elérési feladatokkal foglalkozik, SQL lekérdezési lehetőséget biztosít a második réteg, az alkalmazásszerver számára. A második réteghez az alkalmazással kapcsolatos feladatok tartoznak, például a nyomtatásra váró dokumentumkezelés, a belső adatbázis zárolások, a különböző jelentések háttérben való feldolgozása, vagy jelentések végrehajtása. A harmadik a prezentációs szerver réteg, ide tartoznak a felhasználói feladatok [HERNANDEZ, 2007]. A prezentációs réteg a felhasználók számítógépeiből áll, itt fut az SAP grafikus felhasználói felülete, melyen keresztül az SAP által kínált jelentések könnyen elérhetőek. Később, az internetes technológiákkal történő bővítés során ez plusz egy réteggel bővült, mégpedig az internet réteggel, ami az alkalmazási és prezentációs réteg közé került. A SAP R/3 szoftveres kialakítása folyamatosan fejlődik, mindig újabb technológiát kell a rendszerbe integrálni, így a fejlesztése, napra 7

9 készen tartása állandó kihívást jelent. Támogatja a legfőbb operációs rendszereket: UNIX, Windows, Linux, így ezek közül bármelyik platformot is választjuk, az SAP-t mindegyikkel használhatjuk. Az alap modulban találhatóak a pénzügyi alkalmazások, az emberierőforrásgazdálkodási alkalmazások, valamint a logisztikai alkalmazások. Az SAP-ban saját programokat lehet készíteni ABAP (Advanced Business Application Programming Language) nyelven, az ABAP fejlesztő felület segítségével SQL Az SQL (Structured Query Language) egy, a relációs adatbáziskezelők számára kifejlesztett strukturált lekérdező nyelv. Az alapjait 1970-ben az IBM cég készítette el. Az IBM, az Oracle, és más gyártók is érdekeltek voltak egy szabványos lekérdező nyelv létrehozásában, amivel a relációs adatbázisok programozhatók. A szabványt az ANSI (Amerikai Nemzeti Szabványügyi Intézet) 1986-ban, míg az ISO (Nemzetközi Szabványügyi Szervezet) egy évvel később, 1987-ben jegyezte be. Az SQL-t folyamatosan fejlesztik, egy jó példa erre a rekurzív lekérdezések használatának vizsgálata [LIBKIN, 2003], hogy a nyelv jelenlegi elemeivel meg lehet-e azt valósítani. Egy másik cikk foglalkozik az SQL parancsok hibáival: szintaktikailag helyes, ám valójában nem szándékosan úgy írt lekérdezések (például amik mindig üres táblával térnek vissza) hibáinak kezelésével, ennek szükségességével [BRASS, 2006]. A további fejlesztések egy újabb lehetséges ösvénye a lekérdezések 8

10 automatikus kiegészítésének egyre pontosabb és gyorsabb lehetősége, valamint ennek megoldása [IOANNIDIS, 2006]. A nyelvben az utasításokat pontosvessző választja el egymástól. Megkülönböztetünk adatdefiníciós, valamint adatkezelési elemeket. Az adatdefiníciós elemekkel az objektumokon végzünk el utasításokat, azokat hozzuk létre, módosítjuk (például tábla létrehozása), az adatkezelő elemekkel magával az adattal foglalkozunk. Ha már az adatbázis-kezelőkről van szó, az adatbiztonságot is célszerű megemlíteni, ugyanis egy cégnek rendkívül fontos, hogy az adatbázisaiban tárolt titkaihoz senki más ne férjen hozzá. Minél elterjedtebb szoftvert használunk, annál valószínűbb, hogy támadások érik a rendszert, amelyre nem mindig lehet időben felkészülni január 25- én talán az akkori legnagyobb számítógépes fertőzését produkálta egy úgynevezett SQL Slammer nevű féreg, amely a Microsoft Windows 2000 egy hat hónapja létező biztonsági rését kihasználva mintegy számítógépet fertőzött meg, amelyeken Microsoft SQL szerver futott. A féreg az elindulását követő 10 percen belül a lehetséges számítógépek 90%-át megfertőzte [HINDE, 2003]. A fertőzést követően az internetes forgalom emiatt globálisan lecsökkent. Nem mindig a forgalom lassítása a cél: ha egy féreg képes beférkőzni ilyen módon a rendszerbe és nincs hasonló, feltűnő viselkedése, akár fontos adatokat is szolgáltathat a gazdája számára. 9

11 2.3. A Java programozási nyelv, a NetBeans IDE fejlesztési környezet, és a Java Excel API csomag A Java programozási nyelv A Java egy objektumorientált programozási nyelv, melyet 1990 óta a Sun Microsystems fejleszt [LINK2]. A neve eredetileg Oak volt, ám ben egy már létező nyelvvel való nyelvhasonlatosság miatt át kellett nevezni, így kapta a Java nevet. Az Internet és a World Wide Web akkori rohamos fejlődése miatt a Java hamarosan népszerű lett, és 1996 körül a Microsoftot annyira aggasztotta a Java sikere, hogy elkezdte fejleszteni a saját verzióját, ez lett a Visual J++ fejlesztői környezet. A Microsoft megpróbálta a Java-t a Windows-hoz kötni, úgy fejlesztette a saját verzióját, hogy ne legyen platformfüggetlen: Windows-specifikus megoldásokat rakott bele. Ezt a másik fajta Java-t, a szakmai tolvajnyelv polluted Java -nak, azaz szennyezett Java-nak keresztelte. Mivel a Microsoft ezt a nyelvet is Java-nak nevezte el, a Sun pert indított a Microsoft ellen, aminek az lett a vége, hogy a Windows XP-be már a Microsoft Java VM sem kerülhetett be. Így a Java-t sikerült megőrizni platformfüggetlenként, ami azt jelenti, hogy egy Windows alatt megírt Java kódot futtathatunk más platformokon is. A Java program platformfüggetlenségének a lényege: A programozó elkészíti a forráskódokat (.java kiterjesztésű szöveges állományok) A forráskódkat bytekóddá fordítja (a bytekód hordozható, platformfüggetlen, kompakt) 10

12 A bytekódokat a felhasználó a Virtuális Gépen (továbiakban JVM) lefuttatja, azaz a bytekód a Java Virtuális Gép gépi kódjának tekinthető A Java Virtuális Gép egy virtuális számítógép, amely egy fizikai hardver működését szimulálja. A Java programozási nyelvben minden objektum, azaz osztály. Minden változó egy osztályhoz kapcsolódik. Önállóan létező függvény sem található benne, minden függvény valamelyik osztály része. Erősen típusos nyelv, ami azt jelenti, hogy a sok más nyelvben megtalálható automatikus típuskonverzió nem működik, a változókat és az osztályokat igen szigorúan ellenőrzi, minden konverziót le kell programozni. Az objektum-orientáltság leglényegesebb tulajdonsága az öröklődés, ami lehetővé teszi, hogy könnyebben felhasználhassuk a már előre megírt programrészleteket. A Java csak az egyszeres öröklődést engedélyezi (ellentétben például a C++ nyelvvel), tehát minden osztálynak legfeljebb egy közvetlen szülője van. Támogatja a több szálon történő futtatást, az egyes szálak csoportba foglalhatóak és prioritás is rendelhető hozzájuk. Nagyon sok elemet vett át más, már ismert nyelvből, így könnyű megérteni a szintaxisát. A futás közben fellépő hibákat, kivételeket jól lehet kezelni, a hibakezelése fejlett. A memóriakezelése automatikus, egy úgynevezett Garbage Collector felelős érte: a program csak használatba vehet szabad memóriát, azonban nem szabadíthat fel, ezt egyedül a GC végezheti el. Ezzel elkerülhető a már felszabadított objektumokra való hivatkozás. 11

13 A NetBeans IDE fejlesztési környezet A NetBeans széleskörű felhasználói bázissal, egyre növekvő közösséggel és világszerte több mint 100 partnerrel (és ez a szám tovább növekszik!) rendelkező, nyílt forráskódú projekt. A Sun Microsystems júniusban hozta létre a NetBeans nyílt forráskódú projektet, és továbbra is a projekt főszponzora. Jelenleg két termék érhető el: a NetBeans IDE és a NetBeans Platform [LINK3]. A NetBeans IDE fejlesztői környezet Java nyelven íródott a NetBeans Platform felhasználásával, és a programozók számára lehetővé teszi a programírást, a fordítást, a tesztelést, a hibakeresést, a profilozást, valamint a telepítést. A NetBeans IDE a Java-n kívül több, más nyelvet is támogat (például: JavaScript, Python, Ruby, PHP, C/C++, Groovy). Ingyenes termék, és a használatára vonatkozóan jelenleg nincsenek érvényben korlátozások. Nyílt forráskódú és ingyenesen használható kereskedelmi vagy nem kereskedelmi célokra egyaránt. A forráskód a CDDL (Common Development and Distribution Licence, közös fejlesztési és terjesztési licenc) alapján használható fel újra. A NetBeans IDE minden funkcióját modulok biztosítják, amikből rendkívül sok áll rendelkezésre, a NetBeans IDE ezekkel igény szerint bővíthető. Minden modul egy-egy meghatározott funkciót lát el, például az adott programozási nyelv (Java, PHP, stb.) támogatása, vagy a szerkesztés. Új funkciókkal való kibővítéshez (például egy újabb programozási nyelv támogatása) elég csak hozzáadni a modulokat, amik között felhasználók által is készített, sokszor igen hasznos kiegészítő is található a szoftverhez, érdemes a saját témánkhoz tartozó modulokat végigböngészni. 12

14 Néhány példa a NetBeans IDE core komponenseiből [LINK1]: NetBeans Profiler: A NetBeans Profiler a Java alkalmazások felügyeletét biztosító eszköz, amely támogatást nyújt a memóriakezelésben, az alkalmazás sebességének optimálásában, és lehetővé teszi a Java SE, Java FX és Java EE alkalmazások létrehozását. A NetBeans Profiler futásidőben nyújt információkat az alkalmazásokról. Támogatja profile pontok elhelyezését a forráskódban, amely lehetővé teszi az alkalmazás futásának meghatározott pontjaiban történő nézetét. GUI (Graphical User Interface) tervező modul: Ez a modul lehetővé teszi a Swing felületek tervezését és a grafikus felhasználói felület elemeinek pozícionálását, különböző elrendezési stratégiával. Néhány példa az elrendezési stratégiára: CardLayout: Egyszerre csak egy komponens látható, a többi ez alatt van takarásban. FlowLayout: A komponensek sorokba szervezve jelennek meg, minden komponenst annak optimális nagyságára méretez. BorderLayout: Egyszerre legfeljebb öt komponenst tud kezelni, ezeknek az igazítása a konténer széléhez, valamint a fennmaradó szabad területre történik. GridLayout: A rendelkezésre álló területet egyenlő nagyságú sorokra és oszlopokra (ezáltal egyforma cellákra) osztja fel, minden komponens egy ilyen cellában kap helyet, így a méretük a GridLayout elrendezési stratégia szerint egyforma lesz. 13

15 GridBagLayout: Akárcsak a GridLayout, sorokra és oszlopokra osztja fel a területet, azonban itt különbözőek lehetnek a szélességek és a magasságok, valamint a komponensek egyszerre akár több cellát is elfoglalhatnak. AbsoluteLayout: A komponensek méreteit és koordinátáit mi magunk, koordinátákkal határozzuk meg. JavaScript szerkesztő modul: JavaScript programok és CSS leírásokat készíthetünk vele. Egy szövegszerkesztő tartozik hozzá (amely szintaktikai elemzőt és hibakeresőt is tartalmaz, valamint egy dokumentációkészítőt). NetBeans IDE alapcsomag: Egy többnyelvű szerkesztőt tartalmaz a támogatott programozási nyelvek számára. A gépeléssel párhuzamosan végzi a szintaktikai és szemantikai elemzést. Van beépített dokumentációja, valamint képes a megkezdett kódot kiegészíteni. A fejlesztőrendszerben megtalálható a MySQL és PostgreSQL adatbázis-kezelőhöz való meghajtóprogram, az integrált verziókövetési funkció pedig támogatja a fejlesztők együttműködését, ezáltal a NetBeans IDE az elosztott fejlesztésekre is alkalmas. Java SE: A Java Platform, Standard Edition alkalmazások (appletek, GUI alkalmazások, desktop alkalmazások) fejlesztésére biztosítja ez a csomag az eszközöket. Web és Java EE: A Java Platform, Enterprise Edition komponensek (webszolgáltatások, Java szervletek, weboldalak) létrehozását támogatja. 14

16 C/C++: Ez a csomag a C/C++ alkalmazások fejlesztését támogatja. PHP: A NetBeans PHP szerkesztő a PHP programok szerkesztését támogatja, ez a csomag automatikusan integrálódik a NetBeans HTML, JavaScript és CSS szerkesztőhöz. Java FX: Ez a NetBeans egy új kiterjesztése, úgynevezett rich internet alkalmazások fejlesztését teszi lehetővé, amik az alap, böngészőben megszokott lehetőségeinket kibővíti. Java ME: A Java Platform, Micro Edition a mobil eszközökre (mobiltelefon, PDA) való alkalmazásfejlesztésre felkészített csomag A Java Excel API csomag A Java Excel API (továbbiakban JExcelApi) egy nyílt forráskódú alkalmazásprogramozási interfész (Application Programming Interface) [Link4]. Lehetővé teszi a Java nyelven írt programok számára az Excel munkafüzetek dinamikus írását, olvasását és módosítását. Minden operációs rendszer, ami a Java Virtuális Gépet (JVM) futtatni tudja, ezt a csomagot is képes használni. Az Excel munkafüzetek készítéséhez, beolvasásához, módosításához nem szükséges sem a Microsoft Office, sem az OpenOffice programcsomag megléte a számítógépen. A JExcelApi leglényegesebb jellemzői: Excel 95, 97, 2000, XP, és 2003-as munkafüzeteket képes beolvasni Excel 97 és újabb munkafüzeteknél függvényeket tud írni és olvasni Excel 2000 formátumban menti el a munkafüzeteket támogatja a betűtípusok beállítását, a szám- és dátumformátumokat 15

17 beállítható a cellák háttere, a cellakeret és az árnyékolás létező munkafüzeteket módosíthatunk vele majdnem minden nyelven és karakterkódolással használható (azonban a függvények készítése csak angol, francia, spanyol és német nyelven lehetséges [LINK 4]) alkalmas grafikonok másolására képeket tud elhelyezni a munkafüzetben, azonban azt csak PNG (Portable Network Graphics) formátumban tudja kezelni, ami egy veszteségmentes tömörítésre alkalmas fájlformátum a munkafüzetek másolásakor a makrókat megőrzi, de nem alkalmas makrók létrehozására 2.4. Programfejlesztés Makroökönómiai szempontból a vállalatok IT-beruházásai pénzügyileg egyértelműen pozitív eredményességűek [SZATMÁRI, 2008]. Fontos, hogy a vállalatok jól döntsenek az IT-beruházásukkal kapcsolatban, ugyanis ennek kritériuma a hatékonyság növelés, az információ áramlás, az éppen időbeni (JIT) döntések megalapozása, valamint a versenyelőny biztosítása A programozó Manapság a programozó valójában már mást jelent, mint ahogy régebben értelmeztük [BLACKWELL, 2002]. A régi értelmezés szerint ma már programozónak nevezhetünk majdnem minden számítógép-használót, 16

18 ugyanis elég sok olyan elemmel találkozunk (szkriptek, makrók, stb.) a hétköznapi, nem programozóknak készült szoftverekben, amelyek már egy kisebb szintű programozói tudást igényelnek. Majdnem minden nagyobb program tartalmaz már egy saját nyelvet, amelyen keresztül azt egyéb funkciókkal bővíthetjük. Ezt a szót ezek után akár használhatnánk akármilyen eszköz vagy szoftverhasználói tevékenységre, és Blackwell szerint célszerű lenne újraértelmezni A szoftverfejlesztés nehézségei A szoftverfejlesztés nehézségeivel [BROOKS, 1987] minden bonyolultabb program elkészítésénél találkozunk. Ezeknek a nehézségek a lényege nem változott az elmúlt huszonnégy év során, csupán az elhárításukra alkalmas módszerek, szoftver megoldások gyarapodtak. Rajtunk áll, hogy eldöntsük: ezek közül melyeket célszerű használnunk, a feladatunk mit követel meg. A főbb nehézségek, melyekkel a szoftvertervezés során meg kell küzdenünk a következőek: Komplexitás: a szoftverekben két hasonló rész ritkán fordul elő, leginkább csak utasítás szinten találunk ilyent, és a komplexitás mértéke a szoftver méretével együtt nem lineárisan nő. A szoftver kevésbé lesz átlátható, a szoftvertervezés közben a programozók közti kommunikációs gondok is megjelenhetnek. Minél bonyolultabb egy rendszer, annál nehezebb az új funkciókkal való bővítés, és annál nagyobb a lehetősége a biztonsági rések megjelenésének. 17

19 Szoftver alkalmazkodása: A folyamatosan változó szoftverkörnyezetnek, a felhasználói igényeknek legtöbbször igen nehéz megfelelni, ezekhez alkalmazkodni. Változtathatóság: A már sikeres szoftver életében eljön az az idő, amikor változtatni kell rajta, az alap funkciókat ki kell bővíteni a felhasználók visszajelzései alapján. Idővel fel kell készíteni, az újonnan megjelenő eszközök (perifériák, nyomtatók) támogatására. Külön gondot jelent a változó jogi szabályozásoknak való megfelelés is. Láthatatlanság: A szoftver nem egy kézzel fogható dolog, nincs tökéletesen átlátható módszer, ami a felépítését könnyen, jól bemutatja, akár egy térkép. A szoftvertervező céljai közé kell tartoznia a szerkezet egyszerűsítésének is, hogy a program jobban átláthatóbb legyen. Brooks a következő megoldásokat javasolja a problémák orvoslására: Magas szintű programozó nyelveket kell használni, ezáltal a programkód átláthatóbbá válik, így csökken a hibalehetőség is. A szoftverfejlesztés során foglalkozni kell a számítógép válaszidejével. Egységes programozási környezetek szükségesek, hogy a különböző alkalmazások használatának nehézségét megoldjuk. Ami a problémák nehézségeinek leküzdését segítették: 18

20 A magas szintű nyelvek gyors fejlődése, egyike volt ezeknek kezdetben az Ada. Ez egy strukturált programozási nyelv sok objektum-orientált lehetőséggel, modularizációval. Az 1980-as évek egyik legbiztonságosabb programozói nyelve volt. Objektum-orientált programozás: Egy nagyon jó lehetőség a fent említett problémák megoldására. Lehetővé teszi a program struktúrájának jobb tervezését anélkül, hogy a parancsok tömegét kellene átvizsgálni, azonban a komplexitás problémáját nem oldja meg. A szakértői rendszerek vagy más néven tudásalapú rendszerek sok problémát képesek könnyebben megoldhatóvá tenni a bennük található feladat-specifikus tudással, megoldási módszerekkel. A legnagyobb előnye ezeknek a rendszereknek az, hogy a kevésbé tapasztalt programozók azt a beépített tudást használhatják, amit a legjobb programozók létrehoztak. A grafikus programozás fontos az átláthatóság, a sikeresség eléréséhez. Bár a szoftvert nehéz vizualizálni, egy jól átlátható folyamatábra sokat tud segíteni egy-egy kisebb probléma megoldásában és ha azt nem a füzetben több oldalon, hanem a képernyőn egyszerre láthatjuk, könnyebbé válik a munkánk. Azonban olykor előfordul az az eset is, amikor a helyes megoldás néha egészen más irányban található: Néha a helyes megoldás nem a programkészítés, hanem a piacon az adott probléma megoldására megírt program felkutatása és 19

21 megvásárlása. Már 1987-ben is olykor ez volt a célszerű irány, azonban manapság még több szoftver közül lehet válogatni. Sokszor már azért is megéri vásárolni, mert többe kerülne egy új szoftver elkészíttetése, mint a dobozos verzió megvétele. Fontos, hogy tisztában legyünk ezen programcsomagok képességeinek a határával, ugyanis legtöbbször nem vállalat-specifikusak, hanem általános megoldást tartalmaznak és ezeken sokszor a változtatás csak akkor lehetséges, ha egy olyan szoftverről van szó, aminek van saját programozói nyelve [BLACKWELL, 2002], amivel mi magunk is adhatunk hozzá új modulokat, változtathatunk a futásán, testre szabhatjuk saját magunk számára. Olykor még ez is kisebb költséget jelenthet, hogy a program megvásárlása után fejlesztőkkel testre szabatjuk, mint a semmiből megírni egy programot. Az egyik legnehezebb része a szoftverfejlesztésnek a követelményelemzési fázis [BROOKS, 1987]. Ritkán fordul elő, hogy a megrendelő már a fejlesztés legelején pontosan meg tudja határozni a követelményeit a programmal kapcsolatosan, épp ezért fontos a folyamatos konzultáció és a szoftverprototípus elkészítése Követelményelemzés A követelményelemzés során először a megfelelő konzulenst/konzulenseket kell kiválasztani [GOUSE, 1989], majd a funkcionális és nem funkcionális követelményeket kell megismernünk [SOMMERVILLE, 2002]. A funkcionális követelményekhez tartozik a szoftver logikai viselkedése, a kimeneti és bemeneti elemek meghatározása. A nem 20

22 funkcionális követelményekhez tartoznak a program látható-hallható viselkedésére tett megszorítások (például: ne legyen túl sötét, a színek jól láthatóan elkülönüljenek, színtévesztők is könnyen tudják használni, legyen egyszerű a felhasználói felület, jól elkülöníthető jelző hangok szerepeljenek benne), a felhasznált módszertan, a fejlesztési környezet, a futtatási környezet, a megbízhatóság, a tárfoglalás, a hordozhatóság. Sokszor probléma a természetes nyelven leírt követelmények egyértelműségének hiánya, amikor is a követelmények leírása terjengőssé, nehezen olvashatóvá válik. Probléma még a követelmények keveredése, ahol az információk nehezen különíthetőek el tisztán, valamint a követelmények ötvöződése, mely során több követelmény egyetlen követelményként fogalmazódik meg. A követelményelemzést több kategóriába rendezhetjük [DORFMAN, 1999], a négy kategória: az objektum-orientált, a vezérlésorientált, az adat-orientált, és a folyamat-orientált követelményelemzés Jackson-féle programtervezési módszer Ezt a módszert szokás adatszerkezet alapú tervezésnek, vagy Jackson-féle strukturált programozásnak (Jackson Structured Programming) is nevezni. A módszert megalkotója után nevezték el [BELL, 2003]. Alapelve, hogy egy programnak az általa feldolgozott fájl vagy fájlok belső szerkezetével a legteljesebb összhangban kell lennie. Ezt a módszert használva a feladat meghatározása egyértelműen meghatározza a tervet is. A szakirodalom a megoldandó probléma szerkezete, és az ehhez készített program logikai szerkezete közti hasonlóságot rokonságként említi. A rokonság egy igen fontos és előnyös következménye az, hogy amennyiben a bemenő adatok szerkezetében egy kisebb változás 21

23 következik be, akkor elegendő csak egy hasonló mértékű, kisebb változtatást végezni a program szerkezetén, így biztosak lehetünk abban is, hogy amennyiben az karbantartásra szorul, a változtatások mértékével egyenesen arányos lesz a változtatáshoz szükséges munka mennyisége is. A módszer a napjainkban használtak közül talán a legrendszerezettebb [BELL, 2003]. Nagyon jól megfontolt, könnyen átlátható alapelvre épít (strukturált programozás), könnyen tanítható, egy adott feladatleírás során valószínű, hogy két programozó nagyon hasonló eredményre jutna. Könnyen használható, segítségével olyan terveket lehet készíteni, amiket bármelyik programozási nyelven megvalósíthatunk. A módszer általánosan alkalmazható, akár folyamatszabályozó akár tudományos feladatokat szeretnénk vele megoldani. A módszert leginkább fájlok soros feldolgozására használják (például képek, hangfájlok, weblapok, táblázatkezelő és szövegszerkesztők formátumok) Szoftver modularitás Egy bonyolultabb szoftver általában különböző részegységek rendszere, ezeket a részegységeket moduloknak hívjuk. Arra kell törekednünk, hogy a különböző modulok a legteljesebb mértékben függetlenek legyenek egymástól [BELL, 2003]. A modularitás által a programunk átláthatóbbá válik és külön-külön foglalkozhatunk az egyes modulok elkészítésével. Egy modulokból felépített rendszer egészét egyszerre rendkívül időigényes és összetett tesztelni. Egy felmerülő hiba esetén, egy jól megtervezett modulrendszerben könnyű megtalálni, hogy melyik működik helytelenül és ezek függetlensége miatt a javítás sem okoz 22

24 hibát egy másik modulban. Egy független programrészt más alkalmazásban is újra tudunk hasznosítani, így nem kell újra megírni. Fontos a modulok méretének kiválasztása is a programszerkezet átláthatósága szempontjából [BELL, 2003]. Ha sok kicsiből építjük fel, a program futása általában lassabb, mint a kevesebb, nagyobból felépítettben, azonban sokkal átláthatóbb. A modulokat tervezhetjük úgy, hogy felülről lefelé építkezünk, akár egy létező rendszer megismerésénél [MÜLLER, 1993], és tervezhetjük a részekből kiindulva is, mindig az összetartozó részeket összefoglalva A szoftverprototípus elkészítése Működő prototípusok elkészítése általában segít a felhasználói igényeket jobban, pontosabban kielégíteni a szoftverfejlesztés során [GORDON, 1997], használatával könnyebben kezelhetőbbek lesznek a programok. A prototípus készítés során a fejlesztőknek nagyobb szakértelemre, a megoldandó probléma jobb átlátására van szükségük, de valamivel kisebb erőfeszítéssel készülnek el a szoftverek Felhasználói felületek A grafikus felhasználói felületek (Graphical User Interface) célja a kezelhetőség megkönnyítése, lehetőség szerint olyan szempontokat is figyelembe véve, mint például a színtévesztés [RIDGEN, 1999]. Fontos vizsgálni, hogy az elrendezés, a színek milyen hatással vannak a szoftver használójára, például a piros szín válaszadásra ösztönöz, a zöld szín pedig biztonságérzetet nyújt [LANDBERG, 2000]. Fontos továbbá az is, hogy a felület használata egyszerű, könnyen tanulható legyen [SOMMERVILLE, 2002]. 23

25 Hibakeresés A fekete dobozos tesztelés (vagy más néven funkcionális tesztelés) során csak a bemenetek és a kimenetek tanulmányozásával vizsgáljuk a szoftver működését, tehát ebben az esetben csak a funkcionalitással foglalkozunk, a belső logikai szerkezettel közvetlenül nem foglalkozunk. A fekete dobozos tesztelés feltételezi a program működésének igen nagy mértékű ismeretét, ugyanis csak így készíthető el a megfelelő bemeneti adat és csak így vehetjük pontosan észre, ha a kimeneti adatban hiba jelentkezik [HOWDEN, 1980]. Ez a módszer jól használható függvény vagy objektum alapú rendszerekre [SOMMERVILLE, 2002]. Amennyiben nem a várt kimenetet kapjuk, akkor a teszt sikeresen feltárt egy hibát. Egy másik tesztelési módszer a struktúrateszt, amit fehér dobozos tesztelésnek is neveznek, ugyanis a teszteket ebben az esetben a szoftver struktúrájának ismeretében készítjük. Ehhez a tesztelési módszerhez a program igen pontos ismerete nem olyan fontos, mint a fekete dobozos tesztelésnél [HOWDEN, 1980]. Ezt a hibakeresést általában kisebb részekre alkalmazzák a programon belül (mint például alprogramok, objektumok műveletei) [SOMMERVILLE, 2002]. A tesztadatok elkészítéséhez a kód elemzése szükséges, hogy biztosítva legyen az összes komponens vagy részegység legalább egyszeri lefutása. A különálló programkomponensek, modulok tesztelése után következik az integrációs tesztelés, ahol a komponensek együttműködéséből adódó problémákat tárhatjuk fel. Az integrációs tesztelés során mindig inkrementális megközelítést kell alkalmazni [SOMMERVILLE, 2002], ugyanis ekkor könnyebb a hibák lokalizálása. 24

26 Kezdetben csak egy minimális rendszerkonfigurációt kell tesztelni, majd ehhez kell komponenseket adni. A nagyobb szoftverek tesztelését általában már nem csak egy személy végzi és többféleképp is el lehet járni a tesztelés során. Valaki a tesztelők közti minél több konzultációt tartja előnyösnek, valaki pedig a sok kisebb, különálló tesztelő csoportok létrehozását. Fontos a hatékony módszer kiválasztása is, ugyanis a tesztelésen igen sok időt és pénzt meg lehet spórolni, ha azt a megfelelő módon, megfelelő eszközökkel végezzük [PORTER, 1995]. Fontos továbbá az is, hogy a fekete és fehér dobozos tesztelést ne egymás ellen versengő, hanem egymást kiegészítő módszereknek tekintsük, mert sokszor ezek kombinált használata teszi a legeredményesebbé a hibakeresést Adatbányászat és adattárházak Manapság a rendelkezésre álló adatmennyiség óriási és mértéke exponenciálisan nő. Ilyen mennyiségű adatot hagyományos eszközökkel már nem lehet jól áttekinteni, így szükségessé válik a rejtett kincset tartalmazó adatok adatbányászati módszerrel történő vizsgálata. Az adatbányászat olyan rejtett összefüggéseket, információkat, szabályszerűségeket, mintázatokat szolgáltat az adatbázisokból, amely a gyakorlatban is jól használható, azonban ezek csak annyit érnek, amennyit hasznosítanak belőle [FAJSZI, 2010]. Az adatbányászatnak lehetnek nem anyagi jellegű hasznai is, ilyenek például a javuló vállalati arculat, az elégedettebb ügyfelek. 25

27 Az adattárházak az egy témához tartozó adatokat összekapcsoltan, azokat történiségükben tárolják. A betöltött adatokat nem változtatják, nincs felülírás, törlés. Az adatok integráltan találhatóak benne, egységes formátumban. A rekordok időbélyegesek, tárolják az érvényességi idő kezdetét és végét, tehát tetszőleges időre visszalépve az akkori állapotot vissza lehet állítani. Az adatok redundánsan vannak tárolva, ugyanazt az adatot több tábla irányából ki lehet szedni, de itt a módosítás hiánya miatt a redundancia nem probléma. A fő adatforrásai a tranzakciós rendszerek (On-Line Transaction Processing, OLTP) [FAJSZI, 2010]. Az OLTP nem alkalmas elemzések elvégzésére, jelentéskészítésre, mert arra van optimalizálva, hogy előre meghatározott, strukturált, rövid és izolált elemi tranzakciókat gyorsan hozzon létre és módosítson. Csak az aktuális adatot tárolja, a többit vagy törli vagy archiválja, így nem lassítja az az OLTP rendszer működését. Az adattárházat egészen kis mérettől kifizetődő építeni (kisebb adattárház kisebb költségbe is kerül). Elkészítését az iparág határozza meg leginkább, azonban egy fős cégnél már előnyökkel járhat. Manapság a nagyobb cégek egy része azért is használja (még akkor is ha nem használják ki teljes mértékben az adattárház által nyújtott előnyöket), hogy a presztízsüket növeljék ezzel. 26

28 3. A KAPOSVÁRI CUKORGYÁR FIZETÉSI FELSZÓLÍTÁSÁNAK EDDIGI FELDOLGOZÁSI MÓDJA 3.1 Az informatikai háttér és a fizetési felszólítás alapjai 1995-ben az AGRANA bevezette az SAP rendszert, ezzel párhuzamosan került bevezetésre a Magyar Cukor Zrt. is, de ezek akkor nem kapcsolódtak egymáshoz. A Magyar Cukor Zrt.-é egy IBM szerverparkon futott, volt egy teszt és egy éles rendszerük. Az adatokat tükrözték, de nem folyamatosan, hanem időnként, szakaszosan. Budapest, Petőháza és Kaposvár tartozott ehhez az SAP rendszerhez és Petőházán volt egy 6 fős informatikai csoport, ami ennek a karbantartását végezte. Akkor még a levelezés is az SAP-n keresztül történt ben a Magyar Cukor Zrt. átállt arra a verzióra, amit akkor az AGRANA is használt: az R/3-ra. A két szerver az RV3 és az EV3. Az EV3 egy tesztrendszer, erre tükrözik időnként az adatokat, ezen tesztelik a különféle beállításokat, majd amennyiben ezen beválik, az új rendszerre átrakják azt. Az RV3 az éles rendszer, mindig friss adatokkal. Március 1- től a régi rendszerbe nem került azóta adat és azért ezt a dátumot választották, mert ahhoz, hogy könnyebben átálljanak egy másik SAP rendszerre, az új gazdasági évet az új SAP-ban kell kezdeni, a régit pedig addig kell megtartani, amíg a főkönyvi számlákat lezárják és az adatokat szalagra archiválják, amiket később megfelelő körülmények között fognak tárolni. Az átállás egyik célja az volt, hogy az AGRANA minden leányvállalatánál azonos legyen az SAP, ezáltal a megrendeléseket könnyebb kezelni, nem kell egyik rendszerből átvezetni a másikba az 27

29 információkat, a másik célja pedig a pénzügyi megtakarítás volt, ugyanis ha központilag irányítható az egész, akkor kevesebb SAP-s szakember szükséges az üzemeltetéshez. Az átállás a következőképp történt: Felkészítették az osztrák adatbázist az adatok befogadására (új tulajdonságok, metaadatok felvitele, stb.). Az adatokat bizonyos szűrőkkel szinkronizálták. A levelezést kivették az SAP alól amit azóta külön levelezőszerver lát el. Tárhelyet alakítottak ki az osztrák oldalon: a kaposvári oldalon semmi nem tárolódik, csak kliensek vannak, közvetlenül dolgoznak az osztrák rendszerbe, de ezért a tárhelyért a gyár fizet. Titkosított peer-to-peer vonalat alakítottak ki SAP adatküldés céljára. Kettő vonalas kapcsolatot használnak, melyek fizikailag is elkülönülnek (egyik az SAP, a másik a sima előfizetéses Internet). Munkahelyi migrációt vezettek be, hogy Ausztriából bármikor elérhető legyen bármelyik számítógép karbantartás céljából. A budapesti adminisztratív központot júniusban megszüntették. Az SAP-ból hetente egyszer ki kell listázni az adott időpontban már lejárt követeléseket, ez alapján belső mérlegelés kérdése, hogy melyik cégnek küld a Kaposvári Cukorgyár fizetési felszólító levelet. A fizetési felszólító levelek szintjei szolgálnak arra, hogy a kintlévőségeket az adott ügyfélnél minősíthessék, és ez alapján megfelelően járjanak el az adott ügyben. A fizetési feldolgozások pontos, gyors feldolgozása igen fontos. A gyorsaság a kevesebb ráfordított idő miatt, a pontosság pedig mind 28

30 pénzügyileg, mind pedig a félreértések (ezáltal a presztízs romlása) miatt. Egy konkrét esetet megvizsgáltam folyamat és pénzügyi szempontból is Az eddigi folyamat főbb technikai részletei Az adatok tárolására használt relációs adatbázist az Oracle szolgáltatja. A táblák az SAP alatt vannak definiálva, ezek száma: Az Oracle licenc arról szól, hogy az SAP egy felhasználóként csatlakozik az adatbázishoz, sem az SAP felhasználóknak, sem az informatikusoknak nincs és nem is lehet közvetlen hozzáférése az adatbázishoz. Az SAP rendszerhez biztonsági okokból csak intraneten keresztül lehet csatlakozni, kívülről nem hozzáférhető Egy vizsgált eset folyamatainak leírása Folyamat szempontból a fizetési felszólítások feldolgozása jelenleg a következő lépésekből áll: 1. Belépés az SAP-ba 2. SAP felszólítások program indítása 3. Szelekciós paraméterek megadása 4. SAP jelentéskészítő program futtatása 5. Rich Text formátumba való mentés 6. Megnyitás majd újramentés Microsoft Word formátumban 7. Konvertálás táblázat szöveggé 8. Oldalbeállítás: tájolás és betűméret átállítása 29

31 9. Rossz helyre került oldalfejlécek és üres sorok törlése, soronként végignézve a listát 10. Lista tartalmi áttekintése és a megfelelő megjegyzések beírása 11. Mentés és en továbbítás az érintett 10 kollégának 12. Lefűzéshez nyomtatás 13. SAP program újbóli futtatása 14. A szelekciós paraméterek állítása azokra a vevőkre, akiknek a felszólítót kell küldeni 15. Lista nyomtatása 16. Levelek aláírása, lebélyegzése 17. Levelek fénymásolása 18. Levelek borítékolása 19. Fénymásolatok lefűzése 20. A listával dolgozó kollégák további munkája (10 fő) A folyamaton, amennyiben a relációs adatbázishoz nem kapcsolódhatunk közvetlenül, SAP-n kívüli programozási megoldással az 5., 6., 7., 8., 9., 10., 12., 20. pontokon lehet javítani A vizsgált folyamat pénzügyi oldalról Fontos a folyamat vizsgálata pénzügyi oldalról is. Ebben az esetben külön kell vizsgálni mind a technikai (például nyomtató, fénymásoló üzemórák), mind az emberi órabér költségét. Jelen esetben egy emberi 30

32 munkaóra díja 1400 Forint. Az 1. táblázatban a vizsgált folyamatra fordított emberi munkaidőt láthatjuk percben, órában, valamint forintban kifejezve. Folyamat sorszáma Munkaidő percben Munkaidő órában Időarányos bér (Ft) 1 1,00 0, ,17 0, ,50 0, ,00 0, ,00 0, ,00 0, ,17 0, ,00 0, ,00 0, ,00 0, ,00 0, ,00 0, ,17 0, ,00 0, ,00 0, ,00 0, ,00 0, ,00 0, ,00 0, ,00 3, Összesen: 319,01 5, táblázat: A vizsgált folyamatra fordított emberi munkaidő és annak értéke A 2. táblázat a felmerült nyomtatási és fénymásolási költségeket tartalmazza. A lista terjedelme SAP-ból nyomtatva 40 fekvő tájolású oldal, ugyanez Microsoft Word formátumban a formázási beállítások nélkül 82, a formázás és a fölösleges sorok törlése után pedig 76 oldal. A folyamat teljes költsége (munkaórával és anyagköltséggel együtt) 9534 Ft-lett. 31

33 Tevékenység neve Értéke forintban kifejezve Levelek kinyomtatása 125 Levelek fénymásolása oldal nyomtatása x 76 oldal nyomtatása 1360 Összesen: táblázat: A vizsgált folyamat nyomtatási és fénymásolási költségei 3.5. Az eddigi folyamat nehézségei, kritikus hibalehetőségei, annak lehetséges következményei A lista átmentését követően sok beállításra van szükség ahhoz, hogy a szöveg ismét áttekinthető legyen. Betűtípust nem lehet változtatni a dokumentum teljes szétcsúszása, olvashatatlanná válása nélkül. Az átmentett listában a vevőnkénti csoportok utolsó sorát a Word mindig áttolja a következő sorba, ezáltal ez a fontos adat bekerül a szöveg sűrűjébe, így nehezen lehet megtalálni. Ebben a formátumban a beltartalmat sokkal nehezebb számítógépen áttekinteni, mint a kinyomtatott listával dolgozni. A Word formátumban a tabulátorral való elválasztás miatt figyelni kell a megjegyzések hosszára: tetszőleges hosszúságú megjegyzés írása nem lehetséges, mivel egy hosszú szöveg átlógva a következő sorba átalakítja a dokumentum egy részének a szerkezetét és ezáltal nehezíti a már amúgy is nehéz átláthatóságot. A hosszabb, részletező, magyarázó szövegek használata a többi kolléga munkáját is megkönnyítené, azonban ez így nem lehetséges, többet közt ezért is alakultak ki az egy-két szavas hozzáfűzések. Ha rossz helyre kerül egy megjegyzés, akkor akár egy olyan vevő felé is kiküldésre kerülhet egy felszólító levél, ahova bizonyos okok miatt normális esetben nem kellene, így nagyon kényes helyzetben akár a másik cégnél az illető pénzügyes 32

34 kolléga munkahelye is veszélybe kerülhet (volt már rá példa, de sikerült elkerülni az elbocsátást), azonban általánosságban a kereskedelmi kapcsolatokra lehet hatással egy ilyen eset. Egy SAP-ban tárolt fizetési felszólítási lista exportálásának lehetőségeit láthatjuk az 1. ábrán, a cégek neve, címe, számlaszámuk titoktartási okokból kisatírozva. 1. ábra: Fizetési felszólítási lista exportálása SAP-ból 33

35 4. A KIFEJLESZTETT SZOFTVER A szoftverfejlesztés során először a célkitűzést, a szoftver elkészítésének célját kell megfogalmazni, majd ezt követi a követelményelemzés, ahol fel kell sorolni a szoftverben használandó, szakterülethez tartozó fogalmakat, a szoftver használati eseteit, valamint itt kap helyet a nem-funkcionális követelmények megfogalmazása is. Ez után a bemeneti adatok pontos specifikációjával kell megismerkednünk, hogy az ahhoz legmegfelelőbb programozási nyelvet és programfejlesztési módszert ki tudjuk választani. Ez után következik a megvalósítás, az osztályok kiválasztása, a logikai szerkezet kialakítása, valamint a grafikus interfész megtervezése, elkészítése. A következő lépés a tesztelési fázis, majd a teszt során előjött hibák javítása. A szoftver elkészülte után annak telepítését, az ahhoz szükséges feltételeket és a használatát is pontosan meg kell határozni Célkitűzés A szoftverfejlesztés célja egy grafikus felhasználói felülettel rendelkező SAP post-processing modul elkészítése, amely az SAP-ból exportált fizetési felszólításokat képes feldolgozni, azokat egy későbbi felhasználásra egy adatbázisba tudja menteni, képes Excel formátumba exportálni az adatbázisban tárolt adatokat, valamint HTML kódot is tud belőlük generálni. 34

36 4.2. Követelmények A követelményelemzés során meg kell ismerni a fogalmakat, azokat a szereplőket, akik a szoftvert használni fogják, a használati eseteket és a funkcionális, valamint a nem funkcionális követelményeket. A szereplők jelen esetben egy kategóriába sorolhatóak, a felhasználók közé Fogalomtár Fontos a szoftverfejlesztés folyamatában felmerülő fogalmak tisztázása, a fogalmi szótár felállítása. A következő sorokban mind a felszólítólistával kapcsolatos, mind pedig a szoftver használatával kapcsolatos, nehezen érthető fogalmakat fejtem ki. 1. A felszólítólistával kapcsolatos fogalmak: vevőkód: az adott ügyfél SAP-ban tárolt azonosítója felszólítókód: a felszólítási eljárás neve az SAP rendszerben referencia: annak az SAP-n belüli cellának a száma, ahova plusz információt lehet írni bizonylat kód: a könyvelés típusa, például az SB a banki tranzakció, az RV a Magyar Cukor Zrt. által kiállított számla könyvelési tranzakciójának a kódját jelenti könyvelési periódus: a gazdasági évben a tételhez tartozó könyvelési hónap száma. könyvelési dátum: az adott számla lekönyvelésének időpontja 35

37 esedékesség dátuma: A kifizetés határideje. Vannak olyan számlák, amit később, (például a lekönyveléstől számítva 4 hónap elteltével) kell fizetni, mint a könyvelési dátum, ez csupán megállapodás kérdése a két ügyfél részéről. Az esedékesség dátuma azokban az esetekben szokott megegyezni a könyvelési dátummal, amikor előre fizetés volt a megállapodás, vagy ilyenek például a készpénzes fizetések, illetve ide tartoznak technikai szempontból a folyamatos teljesítésű szolgáltatások is. késedelmi napok: az adott tétel esedékességi napjától eltelt idő (napokban meghatározva) összeg: az adott tétel tartozásának mértéke pénznem: az adott tétel tartozásának pénzneme felszólítási szint: mutatja, hogy az adott ügyféllel szemben a tétellel kapcsolatosan hányszor lett kiküldve fizetési felszólítás. A Kaposvári Cukorgyár négy felszólítási szintet különböztet meg. tételek összege HUF: forint pénznemben jelentkező tételek összege tételek összege EUR: euró pénznemben jelentkező tételek összege esedékes tételek összege: az összes esedékes tétel értéke a következő logika szerint: amennyiben forint tartozása is van a cégnek, akkor forintként van feltüntetve a deviza is (SAP 36

38 számolja aktuális árfolyam mellett), amennyiben csak deviza alapú tartozása van, úgy az összeg is devizában van kifejezve. számlaegyenleg: a vevő felé kiszámlázott esedékes és nem esedékes tételek összes értéke kód: az adott tételhez hozzáfűzött gyors megjegyzés kódja megjegyzés: az adott tételhez tartozó hosszabb megjegyzést tartalmazó oszlop teljes tartozás: az adott ügyfélhez tartozó összes tartozás pénznemekre bontva 2. A szoftver használatával kapcsolatos fogalmak: SQL állapot: a szoftver adatbázis-kezelő rendszerhez való kapcsolódásának állapota. XLS: Excel fájl formátum kiterjesztése HTML: Hyper Text Markup Language, azaz hiperszöveges jelölőnyelv. Egy internetes szabvány, amelyet weboldalak készítéséhez fejlesztettek ki Használati esetek A használati esetek megismerése fontos, segítségükkel a felhasználó és a rendszer közti kommunikációt tudjuk leírni. A 2. ábrán látható az általam fejlesztett szoftver használati eset diagramja. Jelen az esetben csak egy szereplő van, a felhasználó, ugyanis a program minden funkciójának elérésére jelenleg minden használójának megvan a jogosultsága. 37

39 2. ábra: Használati esetek A következő ábrákon a főbb tevékenységek mögötti altevékenységeket részletezem, hierarchikus bontásban. A 3. ábrán az adatbázis kapcsolódás kezelésének részletezése található. A felhasználó kapcsolódhat az adatbázishoz és lekapcsolódhat róla. 3. ábra: Adatbázis kapcsolódás kezelése Az adatbázishoz való kapcsolódás egy fontos tevékenység, ugyanis a program ezzel fog dolgozni a következő munkák során. A 4. ábra az adatfelvitelt mutatja. Ebben a lépésben a felhasználó kiválasztja a feldolgozandó fájlt, ám annak a feldolgozása ekkor még nem kezdődik meg automatikusan. 38

40 4. ábra: Új adat felvitele A táblák törlése már egy kicsit komplikáltabb módon történik, ugyanis lehetőséget kell adnunk a törlés megerősítésére is. A felhasználó ki kell hogy válassza a táblát, amelyet törölni kíván, majd a törlés elkezdésekor ezt meg kell hogy erősítse, vagy érvénytelenítenie kell a folyamatot. 5. ábra: Létező tábla törlése A következő feladat, melyet a felhasználó elvégezhet, az exportálás. A Microsoft Excel formátumba történő exportálást a 6. ábra, a HTML-be történő exportálást a 7. ábra mutatja. Mindkét esetben először azt a táblát kell kiválasztania, amelyiket exportálni szeretné, majd ez után kell kiválasztania a kimeneti fájlt. 39

41 6. ábra: XLS exportálás 7. ábra: HTML exportálás A kimenő adatokkal kapcsolatos követelmények Konkrét követelmény csak a kimeneti Excel fájl formázásával kapcsolatosan merült fel a Kaposvári Cukorgyár részéről. Szükség van kettő munkalapra, ahol az első munkalap a tételek részletes bemutatásával foglalkozik, a második pedig a cégek összesített tartozását mutatja. Az első munkalapon az RV, SB, SA tételeket különböző színekkel kell kiemelni, mégpedig a következő szerint: RV halványkék (aqua), SB világoszöld (bright green), SA sárga (yellow), a többi sor fehér színű kell, hogy legyen. Minden tételhez kell hogy tartozzon egy kód mező, ami alapján egy FKERES() függvény egy listából az adott megjegyzést kiválasztja a tétel számára. A második munkalap -amelyik nyomtatva lesz- első sorában szerepelnie kell a felszólító lista adatbázisban tárolt nevének, a következő 40

42 sorban az oszlopneveknek: Ügyfélnév, Teljes tartozás, Pénznem, Vevőkód. Az azt követő sorokban az oszlopokhoz tartozó megfelelő értékek kell, hogy legyenek Nem funkcionális követelmények A szoftver legyen könnyen kezelhető, grafikus felhasználói felülete legyen egyszerű, átlátható. A grafikus felületen használt színek ne legyenek se rikítóak, se túl sötétek a jól láthatóság érdekében. A feldolgozandó fájlt ne módosítsa, abban kárt ne tegyen. A futtatási környezet a Windows operációs rendszer. A betanítási idő legyen rövid. A kimeneti adatok legyenek könnyen átláthatóak Bemeneti adatok specifikációja Mivel közvetlenül az Oracle adatbázishoz -amely az SAP rendszer mögött található- nem kapcsolódhat a szoftver, így kell választani egy olyan bemeneti információs csatornát, amely minden szükséges adatot tartalmaz. Jelen esetben ez az információhordozó az SAP által Táblázatkezelés formátumba exportált felszólítási lista. Fontos megjegyezni, hogy az SAP ebben az esetben is csak egy tabulátorral elválasztott szövegfájlt hoz létre, amelyet xls kiterjesztéssel ment el, így a kapott fájlt, hogy valóban Microsoft Excel formátumú legyen, megnyitás után el kell menteni Excel munkafüzetként, de más változtatást 41

43 a feldolgozáshoz tilos a fájlon végezni. A fájl nevének és kiterjesztésének a következőnek kell lennie: <fájlnév><szóköz><dátum>.xls, ahol a dátum ÉÉÉÉHHNN formátumban van megadva, például: Felszólító lista xls A programfejlesztési nyelv, környezet, és módszer kiválasztása Programfejlesztési nyelvként a Java-t választottam [LINK 2], ugyanis egy platformfüggetlen programozási nyelven megírt szoftvert egy másik platformon történő felhasználáshoz nem kell újrafordítani, valamint nincs szükség licencre ahhoz, hogy ezen a nyelven programokat fejlesszünk, terjesszünk, ami költségcsökkentő tényező. A másik ok, amiért a Java nyelv mellett döntöttem az, hogy az egyetemi tanulmányaim során ezzel a nyelvvel ismerkedtem meg a legrészletesebben. A Java nyelv mellé a NetBeans IDE fejlesztési környezetet választottam [LINK 1], ami szintén szabadon felhasználható mind kereskedelmi, mind nem kereskedelmi célokra -és ez szintén a szoftverfejlesztés költségeit csökkenti-, valamint a hozzá letölthető kiegészítők rendkívül gazdag világa a programkészítést átláthatóbbá, könnyebbé teszi. A szoftver elkészítéséhez felhasználtam továbbá a szintén szabadon felhasználható JExcelApi-t [LINK 4], ami az Excel formátumú munkafüzetek celláit képes írni és olvasni. A program fejlesztéséhez a Jackson-féle módszert használtam. Bár már viszonylag régi, még ma is talán a legrendszerezettebbnek tekinthető [BELL, 2003]. Azért ezt választottam, mert a probléma megoldásához egy 42

44 adott adatszerkezettel rendelkező fájl feldolgozására van szükség, és amennyiben ennek a módszernek az elveit alkalmazom, akkor a későbbiekben a változtatásokat a program szerkezetében is könnyebb lesz véghezvinni a rokonság miatt, valamint a változtatások mértékével egyenesen arányos lesz a változtatáshoz szükséges munka mennyisége A moduláris felépítés bemutatása A programot modulokból építettem fel, az egyes modulokat különkülön készítettem el, majd azokat a fejlesztés végén illesztettem össze. Az általam elkészített szerkezeti felbontást a 8. ábra mutatja. Jól látható, hogy a felhasználó csak a grafikus felülettel van közvetlen kapcsolatban, a többi modult a grafikus felhasználói felület indítja, miután a megfelelő információkat megkapta a felhasználótól. Mindegyik modul csatlakozhat az SQL adatbázishoz külön-külön, de miután végzett a feladatával, a kapcsolatot bontja. Ezt a későbbiekben fel lehetne arra használni, hogy egyszerre több feladatot is elvégezhessen párhuzamosan a szoftver. 43

45 8. ábra: A moduláris felbontás 4.6. Az osztályok és főbb algoritmusok bemutatása A következőkben ismertetni fogom az osztályokat, azok fontosabb részeit, utasításait, valamint bemutatom a két legbonyolultabb algoritmust. Az Excelt olvasó osztály Feladata egy Excel formátumban lévő fizetési felszólítás beolvasása és adatbázisba mentése. A program legkomplexebb algoritmusa tartozik ehhez az osztályhoz, aminek a vázlata a 9. ábrán látható. Az ábrán a START felirattól a STOP feliratig kell haladni a feldolgozás során. Az egyes héjak az egyes feldolgozási szakaszokat jelölik. A külső és a belső héjban történő haladáskor a fájlban is a feldolgozás szerint előre haladunk, a középső héjban egy külön folyamat kezdődik, ami a további 44

46 feldolgozáshoz szükséges adatokat összegyűjti. Az egész feldolgozási folyamat addig tart, amíg a fájl végét el nem érjük, ez után kilép. 9. ábra: A bemeneti fájl feldolgozó algoritmusának vázlata Class ExcelReader attribútumok: String JDBC_DRIVER: az SQL csatlakozó meghajtó elérési útja String DATABASE_URL: az SQL adatbázis címe String PASSWORD: az SQL csatlakozáshoz tartozó jelszó 45

47 String USERNAME: az SQL csatlakozáshoz tartozó felhasználónév Connection connection: a csatlakozás állapota Statement statement: az SQL lekérdezés metódusok: public void main(string inputexcelfajl): paraméteres konstruktor public void read(file inputworkbook): munkafüzet olvasása public void CONNECTION(String muvelet): SQL csatlakozás vagy lecsatlakozás public void TABLATKESZIT(String PARANCS): SQL táblát készít public void TABLABAIR(String PARANCS): SQL táblába ír Az Excelt író osztály Feladata egy kiválasztott, már előzőleg feldolgozott fizetési felszólítás Excel fájlba írása az SQL adatbázisból, megfelelő formázással. Kettő munkalapot hoz létre: az első munkalapon a részletes adatok találhatóak, minden tétel külön, egy ezekhez kapcsolódó FKERES oszlop, valamint a megjegyzések listája, a második munkalapon pedig a cégenkénti bontás szerepel, devizánként külön sorban. Az első munkalap egy részlete a 10. ábrán, míg a második munkalap a 11. ábrán látható. 46

48 10. ábra: Az első munkalap részlete 11. ábra: A második munkalapon található adatok Class ExcelWriter attribútumok: String JDBC_DRIVER: az SQL csatlakozó meghajtó elérési útja 47

49 String DATABASE_URL: az SQL adatbázis címe String PASSWORD: az SQL csatlakozáshoz tartozó jelszó String USERNAME: az SQL csatlakozáshoz tartozó felhasználónév Connection connection: a csatlakozás állapota Statement statement: az SQL lekérdezés String kivalasztottabla: az aktuálisan kiválasztott tábla neve Numberformat nf: a pénznem formátuma WritableCellFormat: a cellák formátuma (háttérszín, keret, betűtípus) metódusok: public void main(string outputexelfajl, String kivalasztottabla): paraméteres konstruktor public void write(file outputworkbook, String kivalasztottabla): az excel fájl kiírása public void CONNECTION(String muvelet): SQL csatlakozás vagy lecsatlakozás A grafikus felhasználói felület és a HTML exportálás osztálya A két feladatot a HTML exportálás egyszerűsége miatt egy osztályba helyeztem. A grafikus felület a felhasználóval tartja a kapcsolatot a működés során, itt indíthatjuk el az egyes modulokat. A HTML exportálás egy előzőleg feldolgozott fizetési felszólítás egyszerű HTML táblázatba írása az SQL adatbázisból. A HTML dokumentum készítésének algoritmusa a 12. ábrán látható. 48

50 12. ábra: A HTML kód generálásának folyamatábrája Class Foablak attribútumok: String JDBC_DRIVER: az SQL csatlakozó meghajtó elérési útja String DATABASE_URL: az SQL adatbázis címe String PASSWORD: az SQL csatlakozáshoz tartozó jelszó String USERNAME: az SQL csatlakozáshoz tartozó felhasználónév Connection connection: a csatlakozás állapota 49

51 Statement statement: az SQL lekérdezés String inputexcelfajl: a bemenő Excel fájl elérési útja és neve String outputexcelfajl: a kimenő Excel fájl elérési útja és neve NumberFormat formatter: a pénznem formátuma metódusok: public void ExcelReader(String inputexcelfajl): az Excel olvasó meghívása public void ExcelWriter(String outputexcelfajl, String kivalasztottabla): az Excel író meghívása public void IRASINICIALIZACIO(): a HTML kód írásának előkészítése public void IRASIR(String INPUT): elem írása a HTML kódba public void IRASUJSOR(): új sor készítése a HTML kódba public void IRASURESSOR(): egy üres sor beszúrása a HTML kódba public void IRASVEGE(): a HTML kód lezárása public void CONNECTION(String muvelet): SQL csatlakozás vagy lecsatlakozás public void TABLATKERDEZ(): a kiválasztólistába gyűjti az adatbázisban található táblák neveit. public void TABLATTOROL(): egy táblát kitöröl az SQL adatbázisból 50

52 public void LEKERDEZES(): a kiválasztott táblában található információkat HTML fájlba írja public void OSZLOPNEVGENERALAS(String TABLANEV): a kiválasztott SQL tábla oszlopneveit kérdezi le 4.7. A program által használt SQL adatbázis szerkezetének bemutatása A háttérben lévő SQL adatbázis a teszteléshez egy MySQL szerveren található. Mivel az SQL-ben tárolt adatokat egyelőre csak Excel-be és HTML-be kell exportálni, így az adatforgalom rendkívül kicsi. A felszólító lista egyes tételeit csak sok adat együttes vizsgálatával lehet megkülönböztetni, így bevezettem egy id mezőt a rekordok azonosítására. Az adatbázis oszlopainak formátumát a 3. táblázat mutatja be. Sok oszlopba kerül karakter a feldolgozandó fájlból, így csak text formátumban lehet azokat eltárolni. Az adatbázis szerkezet továbbfejlesztésének iránya a további fejlesztési igényektől függ. 51

53 Név Formátum Leírás id int(11) Kulcs vevokod int(11) Vevőkód ugyfelnev text Vevőnév iranyitoszam text Irányítószám helyseg text Helység cim text Cím felszkod text Felszólító lista kódja szamlaszam text Számlaszám ev int(11) Év referencia text Referencia bank text Referencia szöveg b text Bizonylattípus konyvelesiperiodus int(11) Könyvelési periódus konyvelesdatum text Könyvelés dátuma esedekessegdatuma text Esedékesség dátuma kesedelminapok int(11) Késedelmi napok osszeg double Késedelmi összeg penznem text Pénznem felszolitasiszint int(11) Felszólítási szint tetelekosszegeft double Tételek összege Ft tetelekosszegeeuro double Tételek összege EUR esedekestetelosszeg double Esedékes tételek összege szamlaegyenleg double Számlaegyenleg 3. táblázat: az SQL tábla elemei 4.8. A grafikus felhasználói felület kialakítása A grafikus felület a program használatában kulcsszerepet tölt be. Ezen keresztül választjuk ki a ki- és bemeneti fájlokat, indítjuk az egyes modulokat, valamint töröljük az adatbázisból a táblákat. A kialakításkor elsősorban a felsorolt követelményeket vettem figyelembe. Az előugró ablakok helyett az egészben jól átlátható, folyamatábrás módszert választottam az elkészítéséhez. A felület első látásra bonyolultnak tűnhet, ám ha jobban megvizsgáljuk, használata mégis egyszerű: a különböző feladatok megoldásához szükséges lépéseket más-más színű nyíllal jelöltem. A fekete nyílon haladva egy korábban felvitt fizetési felszólítást exportálunk, a kék nyílt követve csak adatbázisba mentés történik, a piros 52

54 nyíl egy adatbázisban tárolt adat kitörlését mutatja, míg a sötétzöld végigvezet egy teljes folyamaton, ahol a fizetési felszólítást feldolgozzuk, majd ki is íratjuk megfelelő formázással, Excel vagy HTML formátumba. A folyamatábrás felület a 13. ábrán látható. 13. ábra: A grafikus felhasználói felület A felület megfelelően szolid, az egyes elemek jól láthatóan elkülönülnek egymástól. A folyamatot mutató nyilaktól a betanítási idő lerövidülését várom A szoftver tesztelése A teszteléshez mind a fekete, mind a fehér dobozos tesztelési módszert felhasználtam. Ezek megfelelően alkalmazott kombinációja igen hatásos [Porter, 1995]. A moduláris felépítés miatt a fekete dobozos teszteléssel kezdtem, ugyanis az előforduló hibákat egy ilyen szerkezetű 53

55 program esetében könnyen lehet egy-egy modulhoz kötni. A fekete dobozos tesztelést a struktúrateszt követte A tesztadatok meghatározása és tesztelés tesztadatokkal A tesztadatok megfelelő módon történő felkészítése igen fontos. Mivel hasonló szoftver eddig még nem készült a Kaposvári Cukorgyárban, így az első és a legfontosabb dolog a tesztadatok elkészítésénél a nyers adatok elemzése volt. Az SAP minden 7 naptári napon belül csak egyszer enged egy felszólító listát exportálni, így a tesztadatokhoz szükséges információgyűjtés már a legelső fejlesztési fázisban elkezdődött. Az eddigi feldolgozási folyamatban is a legnagyobb problémát a nagy oldalszámon kívül a Word formátumába konvertált listában található SAP-s fejlécek különböző helyeken való megjelenése okozta, így a tesztadatokban én is a lehető legkülönbözőbb helyekre illesztettem be, többet is. Az éles adatokban előfordult, hogy olykor az irányítószám, vagy a helységnév, vagy a cím, vagy akár a három együtt is hiányzott. Ez az adott tételeknél a valóságban nem jelent problémát, ugyanis azoknál az eseteknél más módon különböztetik meg az ügyfeleket, de a feldolgozás szempontjából fontos, hogy ezeket is megfelelően lekezeljük. Mivel bizonyos sorokat különböző színekkel kell kiemelni és az adott sor egyik eleme tartalmazza azt az adatot, ami alapján a színt kiválasztjuk, így ezt is fontos tesztelni. Kiemelten fontos továbbá a Forint és az Euró alapú tranzakciók és összesítések kezelésének tesztelése. A szoftvert több tesztadattal is lefuttattam, az egyes funkciókat szisztematikusan teszteltem le. A különböző hibák lokalizációjának 54

56 megkönnyítése miatt a tesztelést inkrementálisan végeztem, ahol egyre több, és egyre magasabb szintű feladatot próbáltam ki egy tesztadaton belül egyszerre. A tesztelés sikeres volt, hibát nem találtam a futások során Tesztelés éles adatokkal A következő mérföldkő a szoftver éles adatokkal való tesztelése volt. Amint már korábban említettem, a szoftver feldolgozásbeli javításai az újabb nyers adatok vizsgálata után sűrűn megtörtént, azonban a legújabb éles adatot először kielemezve nem találtam újabb változtatásra adó okot. Lefuttattam a szoftvert az éles adattal, és látszólag megfelelően működött, minden sort feldolgozott, sehol nem lépett ki hibával. A futtatást követte az elemek soronkénti ellenőrzése, ahol olyan hiba derült ki kettő sornál, ahol a szoftver futása nem állt meg, csak nem a megfelelő adatokat szolgáltatta. A hiba kijavítása a Jackson-módszer alapelveinek megfelelően történő felépítés miatt nem igényelt sok időt. Ez után lefuttatva az összes eddig kapott és készített bemenő adattal a program megfelelően működött. Egy hét múlva egy újabb éles adattal lehetett tesztelni a szoftvert, ahol ismét előjöttek olyan hibák, amelyekkel még a hosszas vizsgálat során sem találkozhattunk: az SAP exportált fájljában plusz megjegyzések jelentek meg, amelyek a felszólítási lista feldolgozása számára nem szükségesek, valamint bekerült néhány olyan cég is a listába, amelyeknek csak Euró pénznemben volt tartozása, így az SAP ebben az esetben az összesítést is Euróban készítette el Forint helyett. További probléma volt még a fájl feldolgozása szempontjából az az új eset is, hogy amennyiben Forint és Euró pénznem is szerepel egy cégnél, az összesítésben az a 55

57 pénznem kerül előre, amelyik előbb jelentkezett. Ezen hibák javítása szintén csak kis időt vett igénybe, majd a következő éles adattal való tesztelés során hibás működést már nem tapasztaltam A program hardver- és szoftverigénye, telepítése, használatának bemutatása A napjainkban kapható számítógépek mindegyike képes a programot megfelelő sebességgel futtatni. Egyedüli követelményként a 800x600-as felbontást szükséges megemlítenem, ugyanis kaphatóak olyan mini számítógépek, melyek ez alatti felbontású kijelzővel rendelkeznek, így azokon a szoftvert nem lehet megfelelően használni. Az alkalmazás fut a következő operációs rendszereken: Windows Linux Solaris A használathoz szükséges a Java futtatórendszere (Java Runtime Environment, JRE). A futtatórendszer más nevei: Java VM, Java WEB Start. Ha még nincs a gépen a JRE szükséges verziója, akkor a legegyszerűbb a oldalról letölteni a legújabbat, majd feltelepíteni [LINK 2]. Szükséges továbbá egy SQL szerver a feldolgozott adatok tárolására. A szoftver külön telepítést nem igényel, csupán a jar kiterjesztésű fájlt, valamint a mellette található lib könyvtárat a benne lévő fájlokkal együtt át kell másolni abba a könyvtárba, ahol futtatni szeretnénk a későbbiekben. 56

58 Az indításhoz duplán kell kattintani a Feldolgozó program.jar fájlon. Ha még nincs társítva a jar kiterjesztéshez a Java futtatóprogram, akkor társítani kell a JRE bin könyvtárában levő javaw.exe programhoz, például: Feldolgozó program.jar fájlon: Jobb egérgomb/társítás/egyéb/ C:/Program Files/Java/<aktuális java verzió, pl. jre1.6.0_04 >/bin/javaw.exe 14. ábra: A grafikus felhasználói felület részei A 14. ábra a grafikus felület részeit mutatja. A számokkal jelzett részek a következők: 1. Adatbázis kapcsolódás létrehozása a szerverrel. Ez a gomb aktivizálja a felület többi elemét is. 2. A feldolgozni kívánt, XLS formátumú fizetési felszólítás kiválasztása. 57

59 3. A kiválasztott XLS formátumú fájl feldolgozása, beírása az adatbázisba. 4. A 14-es számmal jelzett legördülő listában kiválasztott tábla törlése. Ez a gomb aktivizálja az 5-ös gombot és a 6-ost, valamint inaktivizálja a 14-es legördülő listát. 5. A törlés visszavonása. A gomb lenyomására a 4-es gomb, valamint a 14-es számú elem aktívvá válik, az 5-ös és a 6-os pedig inaktívvá. 6. A törlés megerősítése. A gomb lenyomására a 4-es gomb, valamint a 14-es számú elem aktívvá válik, az 5-ös és a 6-os pedig inaktívvá. 7. A listából kiválasztott, adatbázisban található tábla lementése XLS formátumba. 8. A listából kiválasztott, adatbázisban található tábla lementése HTML formátumba. 9. Adatbázis kapcsolódás megszakítása a szerverrel, majd kilépés a programból. 10. A program menüje, ahol a bezárást végezhetjük el. 11. Az adatbázis kapcsolat állapota. 12. A hibainformációk megjelenítője. 13. A legördülő listában kiválasztott táblát mutatja (4-es gomb lenyomására a 14-es számmal jelzett legördülő lista inaktívvá válik, így nem lehet a törlési folyamat közben más táblára váltani, de a táblanév láthatósága is csökken, ezért van szükség egy mindig tökéletesen látható megjelenítőre. 14. Az adatbázisban található táblák kiválasztása. 58

60 15. Az adatbázisban található táblák száma. 16. Az aktuálisan kiválasztott fájl elérési útja, kimeneti és bemeneti fájl kiválasztása esetén is. A használati módok: 1. Egy teljes munkafolyamat: Fájl feldolgozás, majd exportálás. Ebben az esetben a sötétzöld nyíl mentén kell haladni. A programmal végzendő feladat: (1) kapcsolódás az adatbázishoz, (2) feldolgozandó fájl megnyitása, (3) a feldolgozás és adatbázisba mentés elindítása, (14) a megfelelő dátummal rendelkező tábla kijelölése, (7) Excel vagy (8) HTML fájlba történő exportálás, (9) adatbázis kapcsolat lezárása és kilépés a programból. 2. Már felvitt tábla törlése az adatbázisból: Ebben az esetben a piros nyilat kell követni. A programmal végzendő feladat: (1) kapcsolódás az adatbázishoz, (14) a törlendő tábla kiválasztása, (4) a törlés elindítása, (6) a törlés megerősítése (a 6-os helyett az 5-ös választva a törlési folyamat megáll, az aktuálisan kiválasztott tábla nem törlődik az adatbázisból), (9) adatbázis kapcsolat lezárása és kilépés a programból. 3. A feldolgozandó fájlt csak elmentjük az adatbázisba, kimeneti adatot nem kérünk. Ez a feladat a sötétkék nyíl mentén haladva hajtható végre: (1) kapcsolódás az adatbázishoz, (2) feldolgozandó fájl megnyitása, (3) a feldolgozás és adatbázisba mentés elindítása, (9) adatbázis kapcsolat lezárása és kilépés a programból. 4. Egy már korábban, adatbázisba mentett adat exportálása. Ez a munkafolyamat a fekete nyíl mentén történik: (1) kapcsolódás az 59

61 adatbázishoz, (14) a megfelelő dátummal rendelkező tábla kijelölése, (7) Excel vagy (8) HTML fájlba történő exportálás, (9) adatbázis kapcsolat lezárása és kilépés a programból A kimeneti adatok további felhasználása A kimeneti Excel fájlban további műveletek elvégzése szükséges a feldolgozás után. A Java Excel API csomag csak angol, francia, spanyol és német nyelven engedélyezi a függvények írását [LINK 4], azonban a megnyitáskor a függvényt a magyar nyelvű Office alkalmazások rosszul értelmezik, így csak szövegként történő írással lehetett a megfelelő függvényt beírni. Ezt a függvényt a cellában meg kell nyitni, majd változtatás nélkül visszamenteni, így megfelelően fog működni. További megjegyzéseket írhatunk be a megjegyzések oszlopba, amiket használni fog az FKERES() függvény A szoftverfejlesztés során felmerülő főbb programozási problémák és megoldásaik A fejlesztés során számos olyan problémát is meg kellett oldani, ami a felhasznált szoftverek működési szabályainak különbözőségéből eredt. Az ékezetes fájlok kezeléséhez egy közös karakterkódolást, az UTF-8 -at kellett használni. A Windowsra telepített NetBeans IDE fejlesztési környezetben ez a karakterkódolás alapértelmezett, de az SQL szervert külön be kellett konfigurálni emiatt. A Java SQL vezérlő miatt a táblanevek nem tartalmazhatják a pontot, mint karaktert, valamint nem állhatnak csupa számból. 60

62 A Windowsban az ezres elválasztás egy különleges karakterrel van megoldva, a karakter kódja: \u00a0. A Java Excel API beolvasása után a számmá konvertálásban gondot okozott ez a speciális karakter, így minden konvertálás előtt az összes adatból ezt el kellett távolítani. A Java Excel API a double típusú számokat tudományos formátumban írja be az Excelbe, így erre is kellett egy megoldást találni A fejlesztés során felmerült egyéb nehézségek Amint azt már korábban említettem, az SAP minden 7 naptári napon belül csak egyszer engedélyezi a felszólítólista exportálását, így a tesztadatokat is csak hetenként tudtam pontosítani. Előzetes adatok azért nem álltak a rendelkezésemre, mert korábban nem Táblázatkezelő típusba lettek a felszólítólisták exportálva, hanem Rich Text formátumba, így azokat az adatokat nem tudtam felhasználni a szoftver fejlesztése során. A követelményelemzési fázisban nem fogalmazódott pontosan meg az elvárt megoldás, ezen az egyes prototípusok bemutatásával tudtam pontosítani, alkalomról alkalomra. Előfordult olyan eset, amikor a program jelentős részét át kellett írni emiatt, hogy teljesen megfeleljen az igényeknek. Ahogy a megoldás kész lett, újabb ötletek és igények jelentek meg, amiket szintén implementálni kellett. Mint színtévesztőnek, további gondot jelentett a szoftverfejlesztés során a kívánt színek használata, valamint a megfelelő színekkel történő kiemelés is. Az egyetlen lehetséges módja a megfelelő szín használatának a 61

63 színkód vizsgálata, és annak feljegyzése volt. Mind a felhasználói felület, mint a kimeneti dokumentumban található színek kiválasztása külső segítséget, és plusz konzultációt vett igénybe. 62

64 5. A SZOFTVER BEVEZETÉSE 5.1. Az új munkafolyamat és becsült költsége A program használatával az információ haladásának vázlata a 15. ábrán látható. 15. ábra: Az információ útjának vázlata Az új feldolgozási folyamat a következő lépésekből áll: 1. Belépés az SAP-ba 2. SAP felszólítások program indítása 3. Szelekciós paraméterek megadása 4. SAP jelentéskészítő program futása 5. Táblázatkezelő formátumban való mentés (SAP ezt a szöveges exportálást kínálja fel) 6. Megnyitás majd újramentés Microsoft Excel formátumban. 7. Feldolgozó program futtatása, bemeneti adatok feldolgozása 8. Feldolgozott adatok Microsoft Excel formátumba történő exportálása 63

65 9. Lista tartalmi áttekintése és a megfelelő megjegyzések beírása 10. Mentés és en továbbítás az érintett 10 kollégának 11. Lefűzéshez nyomtatás 12. SAP program újbóli futtatása 13. A szelekciós paraméterek állítása azokra a vevőkre, akiknek a felszólítót kell küldeni 14. Lista nyomtatása 15. Levelek aláírása, lebélyegzése 16. Levelek fénymásolása 17. Levelek borítékolása 18. Fénymásolatok lefűzése 19. A listával dolgozó kollégák további munkája (10fő) Az új folyamat anyagköltségeit a 4. táblázat, az egyes lépések becsült idejét és munkaóra költségeit az 5. táblázat tartalmazza. Tevékenység neve Értéke forintban kifejezve Levelek kinyomtatása 125 Levelek fénymásolása oldal nyomtatása 16 5 x 4 oldal nyomtatása 64 Összesen: táblázat: Az új folyamat nyomtatási és fénymásolási költségei 64

66 Folyamat sorszáma Munkaidő percben Időarányos bér (Ft) 1 1, , , , , , , , , , , , , , , , , , , Összesen: 125, táblázat: Az új folyamatra fordított emberi munkaidő és annak értéke 5.2. Pénzügyileg nem mérhető előnyök A kimeneti dokumentum rövidebb, átláthatóbb, mint az elődje, a sok oldal monoton átvizsgálása megszűnt, a beltartalom áttekintése a színekkel történő kiemeléssel még könnyebbé vált. A feldolgozás során a jobb átláthatóság és az új szerkezeti kialakítás miatt csökken annak a lehetősége, hogy rossz helyre kerül egy megjegyzés, ami kisebb munkahelyi stresszt eredményez, ugyanis abban az esetben előfordulhat az is, hogy a Kaposvári Cukorgyár olyan vevő felé küld ki egy felszólítólevelet, akinek valamilyen ok miatt nem kell. 65

67 Lehetőség van hosszabb, részletező megjegyzések használatára, amely a többi dolgozó munkáját is megkönnyíti, aki a felszólítólistával dolgozik. A folyamatábra használata miatt rövidebb a betanítási idő, a grafikus felhasználói felület használata egyszerű. Egy stabil szerveren található adatbázisban tárolt adatok egy teljes lokális rendszerösszeomlás után is megmaradnak, az adatvesztés lehetősége ezáltal csökken, valamint az egyik felhasználó által felvitt információhoz hamar hozzáférhet a többi is Javaslattétel a bevezetési folyamatra A folyamat elején egy (akár lokális) SQL szervert kell megfelelően konfigurálva elindítani, a szoftvert a kapcsolódásra beállítani. Tekintettel a tesztelés közben az először hetente, majd később ritkábban megjelenő újabb hibákra, a szoftver bevezetési ideje alatt továbbra is az előző feldolgozási módszert kell élesben alkalmazni, majd azt összevetni a szoftver által készített kimeneti fájllal. A bevezetési időszak meghatározására a feldolgozandó nyers adatok hetente történő megjelenése döntő befolyással van. Heti tesztelés esetén az utolsó adathiba megjelenésétől és kijavításától, vagy a programon végzett utolsó változtatástól számítva legalább tíz különböző adatfeldolgozásra (azaz legalább kettő és fél hónapnyi időszakra) van szükség párhuzamos munkára. Amennyiben újabb hiba nem tapasztalható, a használati oktatás is megkezdődhet, párhuzamosan a központi adatbázis szerver 66

68 konfigurálásával. Ez történhet e-learninggel, vagy egy bemutató előadás keretében, ahol a felhasználók személyes konzultációs lehetőség mellett kipróbálhatják a szoftver működését. Egy magas informatikai tudással rendelkező személy számára az e-learning gyorsabb és egyszerűbb megoldás lenne, azonban a szoftvert a jelen esetben olyan dolgozók fogják használni, akik nem rendelkeznek ilyen szintű tudással. A felhasználók a programmal kapcsolatos kezdeti félelmeit nagy mértékben csökkentheti a fejlesztővel történő konzultáció. Célszerű a felhasználók oktatását egyszerre elvégezni, ugyanis azok a dolgozók, akik a programot könnyebben fogadják, kisebb-nagyobb mértékben a többi, szkeptikus felhasználót is meg tudják győzni a szoftver használatának előnyeiről, szükségességéről, még az előadás és a kipróbálás alatt. Ez azért fontos, mert így szívesebben sajátítják el azok a felhasználók is azt a tudást, amivel kezelni tudják majd a későbbiekben az alkalmazást A bevezetéssel járó munkaidő- és költségváltozások Jelentős munkaidőt és munkaóraköltséget takaríthatunk meg az adott folyamattal kapcsolatban. Ez a költségcsökkenés, amennyiben nem munkaidő-elszámolással dolgozik az alkalmazott, pénzben nem jelenik meg közvetlenül, a felszabadult munkaidőt más munkafolyamatra lehet átcsoportosítani, vagy új feladatok elvégzésére ad lehetőséget. Az egy alkalommal felmerülő munkaidő-változást a 16. ábra mutatja. Már egy folyamat vizsgálata esetén is a percben kifejezett értékek sok információt elárulnak a megtakarítással kapcsolatban. Leolvasható, hogy a becsült időmegtakarítás perc csak egy feldolgozás esetén. 67

69 16. ábra: Munkaidő becsült csökkenése egy alkalom esetén Ha az egy alkalommal felmerült munkaidőre vonatkozó költséget vizsgáljuk, amit a 17. ábra mutat, láthatjuk, hogy a megtakarítás 4508 Forint. Ez egy ilyen egyszerű folyamat esetén is nagynak tekinthető. 17. ábra: A munkaidőre vonatkozó költségek becsült csökkenése egy alkalom esetén A becsült anyagköltség-változást a 18. ábra szemlélteti. Már az arányon is jól látszik, hogy a megtakarítás igen nagy: 1552 Forint. 68

70 18. ábra: Egy alkalom esetén a becsült anyagköltség-csökkenés Azonban nem elég csak egy alkalomra vizsgálni a munkaórák, a munkaóraköltségek és az anyagköltségek alakulását. Órában kifejezve az egy év alatt várható munkaidő-csökkenés a 19. ábrán látható. Egy év alatt ez az összeg jelentős: 167,42 órányi munkaidőt lehet más feladatokra átcsoportosítani. 19. ábra: Egy év alatti becsült munkaóra-csökkenés 69

71 20. ábra: Egy év alatt bekövetkező becsült munkaóra költség csökkenés 21. ábra: Egy év alatti becsült anyagköltség-csökkenés A 20. ábra a feladatra igénybe vett munkaórák költségének becsült csökkenését mutatja, ami egy év alatt igen nagy összeget: Forintot. Az anyagköltség-csökkenés, ami a 21. ábrán látható is igen nagy, különösen ha azt is figyelembe vesszük, hogy ez mindenképp jelentkezik, ellentétben a munkaidő-csökkenéssel, ami fix bérezés esetén csak 70

72 munkaidő-átcsoportosítással jelenik meg. Utoljára szeretném bemutatni az összes költség becsült alakulását a 22. ábrán. A teljes megtakarítás a folyamaton egy év alatt a becslések alapján Forint. 22. ábra: Egy év alatt az összes felmerülő költség becsült alakulása 71