DIPLOMADOLGOZAT
SZOMMER KÁROLY
KAPOSVÁR 2010.
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.
TARTALOMJEGYZÉK 1. Bevezetés...................................................................................................4 1.1 A vállalatok és az informatikai beruházások......................................................................................4 1.2 Célkitűzés...........................................................................................................................................4
2. Irodalmi áttekintés.....................................................................................6 2.1. SAP....................................................................................................................................................6 2.2. SQL...................................................................................................................................................8 2.3. A Java programozási nyelv, a NetBeans IDE fejlesztési környezet, és a Java Excel API csomag.10 2.3.1. A Java programozási nyelv.....................................................................................................10 2.3.2. A NetBeans IDE fejlesztési környezet................................................................................... 12 2.3.3. A Java Excel API csomag.....................................................................................................15 2.4. Programfejlesztés............................................................................................................................16 2.4.1. A programozó.........................................................................................................................16 2.4.2. A szoftverfejlesztés nehézségei..............................................................................................17 2.4.3. Követelményelemzés..............................................................................................................20 2.4.4. Jackson-féle programtervezési módszer.................................................................................21 2.4.5. Szoftver modularitás...............................................................................................................22 2.4.6. A szoftverprototípus elkészítése.............................................................................................23 2.4.7. Felhasználói felületek.............................................................................................................23 2.4.8. Hibakeresés.............................................................................................................................24 2.5. Adatbányászat és adattárházak........................................................................................................25
3. A Kaposvári Cukorgyár fizetési felszólításának eddigi feldolgozási módja...........................................................................................................27 3.1 Az informatikai háttér és a fizetési felszólítás alapjai......................................................................27 3.2. Az eddigi folyamat főbb technikai részletei....................................................................................29 3.3. Egy vizsgált eset folyamatainak leírása...........................................................................................29 3.4. A vizsgált folyamat pénzügyi oldalról............................................................................................30 3.5. Az eddigi folyamat nehézségei, kritikus hibalehetőségei, annak lehetséges következményei .......32
4. A kifejlesztett szoftver.............................................................................34 4.1. Célkitűzés........................................................................................................................................34 4.2. Követelmények................................................................................................................................35 4.2.1. Fogalomtár..............................................................................................................................35 4.2.2. Használati esetek.................................................................................................................... 37 4.2.3. A kimenő adatokkal kapcsolatos követelmények ...................................................................40 4.2.4. Nem funkcionális követelmények..........................................................................................41 4.3. Bemeneti adatok specifikációja.......................................................................................................41 4.4. A programfejlesztési nyelv, környezet, és módszer kiválasztása....................................................42 4.5. A moduláris felépítés bemutatása...................................................................................................43 4.6. Az osztályok és főbb algoritmusok bemutatása..............................................................................44 4.7. A program által használt SQL adatbázis szerkezetének bemutatása...............................................51 4.8. A grafikus felhasználói felület kialakítása......................................................................................52 4.9. A szoftver tesztelése........................................................................................................................53 4.9.1. A tesztadatok meghatározása és tesztelés tesztadatokkal.......................................................54 4.9.2. Tesztelés éles adatokkal..........................................................................................................55 4.10. A program hardver- és szoftverigénye, telepítése, használatának bemutatása..............................56 4.11. A kimeneti adatok további felhasználása......................................................................................60 4.12. A szoftverfejlesztés során felmerülő főbb programozási problémák és megoldásaik..................60
2
4.13. A fejlesztés során felmerült egyéb nehézségek.............................................................................61
5. A szoftver bevezetése..............................................................................63 5.1. Az új munkafolyamat és becsült költsége.......................................................................................63 5.2. Pénzügyileg nem mérhető előnyök.................................................................................................65 5.3. Javaslattétel a bevezetési folyamatra...............................................................................................66 5.4. A bevezetéssel járó munkaidő- és költségváltozások......................................................................67
6. Összefoglalás...........................................................................................72 7. Következtetések és ajánlások.................................................................. 73 8. Irodalomjegyzék......................................................................................74 9. Nyilatkozat.............................................................................................. 77
3
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
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
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. 1972-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 60000-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
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
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. 2.2. 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
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. 2003. 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 200000 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
2.3. A Java programozási nyelv, a NetBeans IDE fejlesztési környezet, és a Java Excel API csomag 2.3.1. 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 1995ben 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
• 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
2.3.2. 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 2000. 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
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
◦ 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
• 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. 2.3.3. 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
• 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. 2.4.1. 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
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. 2.4.2. 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
• 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
• 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
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. 2.4.3. 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
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. 2.4.4. 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
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). 2.4.5. 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
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. 2.4.6. 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. 2.4.7. 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
2.4.8. 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ó
következik
az
programkomponensek, integrációs
tesztelés,
modulok ahol
tesztelése a
után
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
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. 2.5. 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
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 50-100 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
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. 2009-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 1tő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
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
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. 3.2. 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: 314796. 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ő. 3.3. 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
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 e-mailen 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. 3.4. 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
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,02
23
2
0,17
0,00
4
3
0,50
0,01
12
4
2,00
0,03
47
5
1,00
0,02
23
6
1,00
0,02
23
7
0,17
0,00
4
8
1,00
0,02
23
9
10,00
0,17
233
10
40,00
0,67
933
11
5,00
0,08
117
12
5,00
0,08
117
13
0,17
0,00
4
14
5,00
0,08
117
15
5,00
0,08
117
16
10,00
0,17
233
17
5,00
0,08
117
18
30,00
0,50
700
19
2,00
0,03
47
20
200,00
3,33
4667
319,01
5,32
7561
Összesen:
1. 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
Tevékenység neve
Értéke forintban kifejezve
Levelek kinyomtatása
125
Levelek fénymásolása
216
76 oldal nyomtatása
272
5 x 76 oldal nyomtatása
1360
Összesen:
1973
2. 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
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
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. 4.1. 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
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é. 4.2.1. 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
• 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
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. 4.2.2. 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
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
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
6. ábra: XLS exportálás
7. ábra: HTML exportálás
4.2.3. 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
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. 4.2.4. 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. 4.3. 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 97-2003” munkafüzetként, de más változtatást 41
a feldolgozáshoz tilos a fájlon végezni. A fájl nevének és kiterjesztésének a következőnek kell lennie: „
<szóköz>.xls”, ahol a dátum ÉÉÉÉHHNN formátumban van megadva, például: „Felszólító lista 20100402.xls”. 4.4. 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 97-2003 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
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. 4.5. 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
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 97-2003 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
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
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
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
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
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
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
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
megkülönböztetni,
csak
így
sok
adat
bevezettem
együttes
egy
„id”
vizsgálatával mezőt
a
lehet
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
Név id vevokod ugyfelnev iranyitoszam helyseg cim felszkod szamlaszam ev referencia bank b konyvelesiperiodus konyvelesdatum esedekessegdatuma kesedelminapok osszeg penznem felszolitasiszint tetelekosszegeft tetelekosszegeeuro esedekestetelosszeg szamlaegyenleg
Formátum int(11) int(11) text text text text text text int(11) text text text int(11) text text int(11) double text int(11) double double double double
Leírás Kulcs Vevőkód Vevőnév Irányítószám Helység Cím Felszólító lista kódja Számlaszám Év Referencia Referencia szöveg Bizonylattípus Könyvelési periódus Könyvelés dátuma Esedékesség dátuma Késedelmi napok Késedelmi összeg Pénznem Felszólítási szint Tételek összege Ft Tételek összege EUR Esedékes tételek összege 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
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. 4.9. 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
program esetében könnyen lehet egy-egy modulhoz kötni. A fekete dobozos tesztelést a struktúrateszt követte. 4.9.1. 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
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. 4.9.2. 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
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. 4.10. 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 http://www.java.com/ 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
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//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
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
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
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. 4.11. 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.
4.12. 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
• 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. 4.13. 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
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
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
9. Lista tartalmi áttekintése és a megfelelő megjegyzések beírása 10. Mentés és e-mailen 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
216
4 oldal nyomtatása
16
5 x 4 oldal nyomtatása
64
Összesen:
421
4. táblázat: Az új folyamat nyomtatási és fénymásolási költségei
64
Folyamat sorszáma
Munkaidő percben
Időarányos bér (Ft)
1
1,00
23
2
0,17
4
3
0,50
12
4
2,00
47
5
1,00
23
6
1,00
23
7
1,00
23
8
1,00
23
9
10,00
233
10
5,00
117
11
1,00
23
12
0,17
4
13
5,00
117
14
5,00
117
15
10,00
233
16
5,00
117
17
30,00
700
18
2,00
47
19
50,00
1167
Összesen:
125,84
3053
5. 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
• 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. 5.3. 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
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. 5.4. 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 193.17 perc csak egy feldolgozás esetén. 67
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
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
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: 234416 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
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 315120 Forint.
22. ábra: Egy év alatt az összes felmerülő költség becsült alakulása
71
6. ÖSSZEFOGLALÁS A Kaposvári Cukorgyárban töltött gyakorlatom alatt megvizsgálva a fizetési felszólítások feldolgozási folyamatát, annak javítását tűztem ki célul. Felkutattam majd feldolgoztam az ehhez kapcsolódó szakirodalmat, elvégeztem a követelmények elemzését. A szoftvert prototípusról prototípusra haladva elkészítettem, az egyes készenléti fázisokban bemutattam, majd az újabb követelményeket rögzítettem, és azoknak megfelelően bővítettem tovább a programot. A megfelelő tesztadatok elkészítése problémás volt, ez volt az egyetlen része a fejlesztésnek, ami szigorúan meghatározott léptékkel haladhatott csak előre. A szoftver elkészülte után elemeztem az új folyamatot, kiszámoltam annak becsült költségeit, majd javaslatot tettem a bevezetésével kapcsolatban, és legvégül megmutattam a bevezetéssel járó becsült költségcsökkenést. A szoftver a bevezetés után alkalmazásra kerül a Kaposvári Cukorgyárban. Ezúton szeretnék köszönetet mondani Dr. Cser László és Dr. Kövér György
Tanár
diplomadolgozat
Uraknak elkészítése
a
konzulensi során
feladatok
nyújtott
ellátásáért,
munkájukért,
a
szakmai
útmutatásukért és tanácsaikért, továbbá szeretném megköszönni BabócsaiFekete Ilonának a Kaposvári Cukorgyár pénzügyi munkatársának a követelményelemzésben és a feldolgozási folyamatok vizsgálatában végzett segítségét, és szeretném megköszönni húgomnak, Szommer Brigittának a program felhasznált színeinek összeállításához kapott támogatását.
72
7. KÖVETKEZTETÉSEK ÉS AJÁNLÁSOK Jól látható, hogy egy viszonylag kis folyamaton is igen nagy megtakarítás lehetséges, amennyiben azt megfelelően elemezve gondosan megtervezett informatikai eszközökkel támogatjuk. Azok a cégek, akik egy adott folyamatukon informatikai eszközökkel szeretnének javítani, időben el kell hogy kezdjék a szükséges információk összegyűjtését. Ez a szoftver fejlesztését megkönnyíti, a bevezetési időt lerövidíti, ezáltal a várt megtakarítás előbb jelentkezik. Célszerű a továbbiakban: • A szoftver egy másik változatát elkészíteni, ahol azoknak a személyeknek, akik nem vihetnek fel újabb adatot az adatbázisba csak olvasási jogot adunk, így csak az adott fizetési felszólítási listát exportálhatják, akár más formázással is. • További lehetőség az exportált Excel fájlban lévő adatok színnel történő kiemelésének konfigurálhatóvá tétele, ami egy mentőöv lehetne azoknak a dolgozóknak, akik színtévesztők. • A vezetők munkájának megkönnyítése érdekében vagy a HTML exportálási lehetőséget kell továbbfejleszteni, megfelelő jogosultságú felhasználóknak intraneten hozzáférhetővé tenni, vagy egy hálózati meghajtón tárolni a keletkezett Excel munkafüzeteket. • A későbbiekben a munkafolyamattal összegyűjtött egyéb meglévő adatok felhasználásával egy adattárház építése célszerű lenne, annak adatbányászati eszközökkel való vizsgálata a magas kockázattal rendelkező leendő vevők kiszűrését, valamint a cég marketing tevékenységét segíthetné. 73
8. IRODALOMJEGYZÉK [ÁDÁM, 2009]: Ádám, Gém, (2009) SAP, mint a modern vállalatirányítás eszköze. Diplomadolgozat, Debreceni Egyetem [BELL, 2003]: Bell, Douglas, Morrey, Ian, Pugh, John, (2003) Programtervezés [BJORENDAHL, 2004]: Bjorendahl, Magnus, Roddy, Mark, Quinn, Brian, (2004) RFID & UID Compliancy: SAP and Lockheed Martin working together [BLACKWELL, 2002]: Blackwell, Alan F., (2002) What is Programming? [BRASS, 2006]: Brass, Stefan, Goldberg, Christian, (2006) Semantic errors in SQL queries: A quite complete list [BROOKS, 1987]: Brooks, Frederick P., (1987) No Silver Bullet: Essence and Accidents of Software Engineering [DORFMAN, 1999]: Dorfman, Merlin, (1999) Requirements Engineering [FAJSZI, 2010]: Fajszi, Bulcsú, Cser, László, Fehér, Tamás, (2010) Üzleti haszon az adatok mélyén – Az adatbányászat mindennapjai
74
[GAUSE, 1989]: Gause, Donald C., Weinberg, Gerald M., (1989) Exploring Requirements – Quality Before Design [GORDON, 1997]: Gordon, V. Scott, Bieman, James M., (1997) Rapid Prototyping: Lessons Learned [HERNANDEZ, 2007]: Hernandez, José A., Keogh, Jim, Martinez, Franklin F., (2007) SAP R/3 kézikönyv [HINDE, 2003]: Hinde, Stephen, (2003) Computer Security: Mapping the future [HOWDEN, 1980]: Howden, William E., (1980) Functional Program Testing [IOANNIDIS, 2006]: Ioannidis, Yannis E., Viglas, Stratis D., (2006) Conversational querying [KUBACH, 2005]: Kubach, U., (2005) Smart Items & Future Manufacturing [LANDBERG, 2000]: Landberg, Viktoria, (2000) Developing User Interfaces in Virtual Reality [LIBKIN, 2003]: Libkin, Leonid, (2003) Expressive power of SQL
75
[MÜLLER, 1993]: Müller, Hausi A., Orgun, Mehmet A., Tilley, Scott R., Uhl, James S., (1993) A Reverse Engineering Approach To Subsystem Structure Identification [PORTER, 1995]: Porter, Adam A., Siy, Harvey, Votta, Lawrence G., (1995) A Review of Software Inspections [Ridgen, 1999]: Ridgen, Christine, (1999) ‘The Eye of the Beholder’ Designing for Colour-Blind Users [SMITH, 1986]: Smith, Sidney L., Moiser, Jane N., (1986) Guidelines for designing user interface software [SOMMERVILLE, 2002]: Sommerville, Ian, (2002) Szoftverrendszerek fejlesztése [SZATMÁRI, 2008]: Szatmári, Ferenc, Kovácsné Antal, Anita (2008) Business value creation in IT [ZOLTÁN, 2001]: Zoltán, László, (2001) Programozás Technológiája [ANDY KHAN (2009)] http://jexcelapi.sourceforge.net/ [ORACLE CORPORATION (2010a) = LINK1] Oracle Corporation 2010, www.netbeans.org
76
[ORACLE CORPORATION (2010b) =LINK2] www.java.com [ORACLE CORPORATION (2010c) = LINK3] http://netbeans.org/index_hu.html
77
9. NYILATKOZAT Alulírott Szommer Károly, folyamatszabályozó mérnök szakos hallgató nyilatkozom, hogy a diplomadolgozat saját munkám, a felhasznált irodalmat korrekt módon kezeltem és az erre vonatkozó jogszabályokat betartottam. Kaposvár, évszám. hónap nap. …………………………….. hallgató aláírása
NYILATKOZAT
Alulírott Dr. Cser László, egyetemi tanár nyilatkozom, hogy a diplomadolgozat a Kaposvári Egyetem Gazdaságtudományi Kar vonatkozó szabályzata előírásainak tartalmi és formai szempontból egyaránt megfelel. A dolgozat végleges változatát áttanulmányoztam, annak benyújtásához hozzájárulok. Kaposvár, év. hó nap. …………………………….. témavezető aláírása 78
