2016. augusztus–szeptember: anyagtudomány, nanotechnológia, portré, agykutatás, tudomány, energiagazdálkodás, innováció, it, fenntarthatóság, zöldkörnyezet, ipari automatizálás, kiállítás/konferencia, jegyzet, vízgazdálkodás
2016. szeptember 1.

Szerző:
B. Szabó Edina

Egyedi szoftverek, speciális megoldások

A szoftverfejlesztés egyik kulcskérdése az egyedi, személyre szabott megoldások kínálata. Minden piaci szereplő – legyen vállalati vagy lakossági, egyéni vagy közösségi felhasználó – egyedi, számára valami új vagy speciális alkalmazást keres. Ezek közül aztán lesz, ami tiszavirág-életű, lesz, ami valami nagyobb részeként, lesz, ami a mindennapok felhasználói élményei között vonul be a szoftvertörténelembe.


Ez a fejlődési szakasz arányaiban ugyan nem hosszú, de már tudjuk, hogy önmagában is rendkívüli ívet ír le, ha pedig hozzárendeljük az egyes ágazatokban az elmúlt évtizedek alatt felmerült igényekre adott megoldásokat, könnyen elveszhetünk az áttekintése során.
Ezúttal az alapfogalom, az egyediség kibontását tűztük ki célul, ahol lehetséges, általánosabb példákkal illusztrálva. Adorján Gábor szakértővel, a Nextent Informatika Zrt. BI üzletágvezetőjével beszélgettünk. A BI (Business Intelligence) jelentése magyarul „üzleti intelligencia” – a kellemes hangzás érdekében. Eredetileg ugyanis az „intelligence” szó itt „hírszerzés” értelemben használatos, ami az adatbányászat területén ugyan nem pejoratív jelentésű, de érthető módon jobban hangzik az intelligens megoldás értékesítése, mint a hírszerzéssel szerzett információk árusítása. Első meghatározását egy bizonyos Howard Dresner nevéhez kötötték, aki 1989-ben úgy definiálta az üzleti intelligenciát, mint olyan módszerek, fogalmak összességét, melyek a döntéshozás folyamatát javítják az úgynevezett tényalapú rendszerek (MIS, DSS, OLAP, DM stb.) segítségével.

Van-e jelentősége a fogalom használatának? Valahol minden szoftver egyedi, legalábbis a fejlesztői annak szánják.

– Mindegyik egyedi, amelyik nem dobozos… alapvetően tehát egyedi az a szoftver, ami nem standard, hanem a megrendelő egyedi igényei alapján készült. Például a pénzintézeteknél több dobozos készterméket használnak, és ezek a pénzügyi jelentések készítését támogatják. A bank infrastruktúrájába ezeket be kell illeszteni, ilyenkor indul a testreszabás, vagyis az egyedi jellemzők beépítése. Az adott banknak nyilván van minderre bevett gyakorlata – egy partnerünk például az alapmódszertanát is velünk együtt alakította ki –, és erre vetítve, ehhez kapcsolódóan készül egy olyan szoftver, amely a gyakorlatban támogatja ennek megvalósítását és működtetését.

Az adat-információ-érték hármas szem előtt tartása fontos a munkánk során. Ám a legfontosabb a kinyert adat, mert ezekből kapunk releváns információt, ami a vállalatok életében azonnal értékké alakul. Mivel egy vállalat életében minden mindennel összefügg, érthető módon az egyik legfontosabb, egyedi megoldás a különböző folyamatok és eltérő rendszerek összekötése és integrációja. Amikor különböző rendszereket kell összekötni, bizonyos információkat az egyik rendszerből, más információkat egy másik rendszerből kell kinyerni, ezekből pedig létre kell hozni a kívánt döntéstámogatást, vagyis egy harmadik rendszerbe vagy egy speciális saját felületre kell új adatot szolgáltatni. Így már maga az integráció is lehet egyedi szoftverfejlesztés.

Van arra igény, hogy egy induló cég eleve integrált, komplex, egyedi rendszerrel startoljon, vagy inkább a cégnövekedéssel, adathalmaz-növekedéssel merül fel a rendszerfinomítás, az igény az összetettebb rendszerekre?

– Mindkettőre van példa. Ha egy kisebb cég vállalatirányítási rendszer nélkül dolgozik, az azt jelenti, hogy valamilyen más formában tárolja a saját folyamataiból kinyert adatait. Ezek különböző dokumentumtípusok lehetnek, jellemzően Excel fájlok. Amikor ez már nem elegendő, akár mert az időfelhasználás jelentősen növekszik a kézi adatrögzítés miatt, akár mert egyre bonyolultabb a szükséges adatokat, vagyis az információértéket kinyerni, felmerül az igény egy szoftver által támogatott standard folyamat bevezetésére. Ez általában a kis- és középvállalkozói szektorban jellemző, de a nagyvállalatoknál is felmerülnek olyan speciális igények a különböző területeken belül, amelyekre speciális célszoftvert kell legyártani.

Okos blokk applikáció
Az egyik leghasznosabb lakossági felhasználásra fejlesztett alkalmazás a Smart receipts, magyarul talán Okos blokk lehet a megfelelő fordítás. Bár az alkalmazásnak jelenleg nincs magyar nyelvű menüje, az egyszerűsége – nem használ szakmai nyelvet, a nyilvántartás kifejezései vagy a fájlformátumok pedig általánosan ismertek – tökéletesen alkalmassá teszi a magyarországi használatra. Elérhető Android és iOS platformon egyaránt.
A letöltés után néhány egyszerű lépéssel máris indulhat a nyilvántartás, a riportok készítése. Az első lépések minden esetben a pontos adatfelvételi pontok: a név megadása után a dátumok megadása következik, tulajdonképpen itt jelöljük ki, hogy milyen időintervallumban kapott blokkjainkat, számláinkat visszük be a rendszerbe. A kezdő és záró dátum megadása után állítjuk be a pénznemet, bár az alkalmazás alapvetően automatikusan az érzékelt helyi valutát hozza fel. Az egyes riportok többféleképpen menedzselhetők, személyre szabhatók, érdemes kideríteni, melyik a számunkra legideálisabb nyilvántartási mód. A riportok természetesen szerkeszthetők, törölhetők, illetve e-mailben továbbküldhetők.
Hogy a legkisebb költségünkről se vesszen el blokk, a következő, nagyon egyszerű módon kell felvinni az adatokat. Az elkészített riport alapba vagy csak szöveggel, vagy képpel rögzítjük az adatokat. Például: 2016. augusztus 20. ünnepi vacsora, 6 fő, és így tovább. A képi felvitel, azaz egyszerű fényképezés után az alkalmazás aztán elkészíti annak szöveges megfelelőjét.
A speciális igények mellett mennyire fontos szem előtt tartani a leendő felhasználókat? A dobozos megoldásokkal általában arra törekednek, hogy a lehető legfelhasználóbarátabb legyen egy termék. Speciális esetekben nem lehet, hogy a felhasználó másod­lagossá válik?

– Természetesen nem, ez az egyik legfontosabb szempont, a cél a könnyen alkalmazható, átlátható, jól elsajátítható funkciókkal készített szoftver. Ha például nagyvállalati ügyfelekről beszélünk, általában adott az igény, maga az ügyfél specifikálja, hogy mire van szüksége, milyen megoldást szeretne, és kik fogják használni azt a bizonyos szoftvert. De az agilis szoftverfejlesztés, amit mi is alkalmazunk a munkánkban, segít abban, hogy a fejlesztő ne csak a végterméket mutassa be, hanem menet közben, a fejlesztés különböző fázisaiban egyeztesse azt az ügyféllel. Nem vonul el a többoldalas igénylistával fél évre, hanem minden fontos szakasz végén bemutatja, teszteli az elkészült terméket. Ilyenkor még nem a teljes szoftver áll rendelkezésre, de már ki lehet próbálni, a megjelenéstől a speciális igényekig a folyamatok modellezhetők, és persze visszajelezhetők a tapasztalatok.

Ha már bankot említettünk, tételezzük fel, hogy a bank az ügy­felei számára fejleszt felületet, elsősorban arra kell figyelni, hogy ők mit gondolnak. Az ügyfelek nem specifikálják, hogy nézzen ki, mondjuk, egy internetbank, de miután elkészült, lehet róla véleményük. Itt következhet egy úgynevezett AB tesztelés, a kattintások tesztje, amikor az egyidejűleg két verzióban élesített megoldás közül a több kattintást kapott, vagyis egyértelműen a sikeresebb verzió „nyer”. Ezt nem minden esetben, de azért sok helyen érdemes alkalmazni. Emellett pedig maga a szoftverműködés, annak használata is mérhető, hogy hova mikor lépnek az ügyfelek, mennyi a várakozási idő, melyik funkcióra mikor kattintanak többen – minden mérhető és minden feldolgozható.

Olyan is előfordul, amikor nincs specifikált megrendelői igény, hanem a fejlesztő dob piacra saját, egyedi megoldást egy, a világban felmerülő igényre adott válaszként – vagyis terméket fejleszt. Ilyen esetekben adott egy ötlet és az elgondolás, hogy összeállítunk egy ilyen és egy ilyen alkalmazást, azt majd várhatóan sokan fogják használni. Ekkor az ötlet minél korábbi fázisban elvégzett validációja, piaci értékelése a legfontosabb. Ezután a már említett, szakaszos vagy egyéb felhasználói tesztelés következik, mert nagyon fontos, hogy a lehető leghamarabb olyan tesztelhető termék kerüljön a piacra, amely ugyan a teljes elképzelésnek csak bizonyos funkcióit tartalmazza, mégis biztonsággal felmérhető például az alkalmazhatósága, felhasználóbarát kialakítása.

Ez a prototípus – vagy a mi kifejezésünkkel: pretotípus – segít jó esetben a továbbfejlesztésben, rosszabb esetben a termék bevonására vonatkozó döntés meghozatalában. Az utóbbi természetesen egy korrekt validálási folyamat mellett fel sem merülhet. Mindegy, hogy telekommunikációról vagy kereskedelemről, mezőgazdaságról vagy gyártásról van szó. A grafikus megjelenés már más téma, de maga a módszertan hasonló.

A mobileszközök és a viselhető okos termékek kapcsán többször fölmerül, hogy a nagy szoftverekből érdemes-e egy-egy modult magunkkal vinnünk, mondjuk az e-bankon kívül?

– A témával kapcsolatban nagyon sok mindenről beszélhetünk. Elmozdulhat minden ugyanúgy a viselhető eszközök felé, ahogy pár évvel ezelőtt elmozdult az okostelefonok felé. Ha az eddigieket vesszük példaként, emlékezhetünk arra, hogy banki szolgáltatást régebben csak személyesen, a bankfiókban vehettünk igénybe. Aztán jött az internetbank, és a számítógép előtt ülve intéztük az ügyeinket. Ma már a telefonunkról is tudunk utalni, egyenleget ellenőrizni, vagy egyéb szolgáltatásokat is igénybe tudunk venni.

Nagyon úgy tűnik tehát, hogy ismét el fogunk térni, most már az egyéb, viselhető eszközök irányába. Ilyen szempontból az eszköz csak egy user interface, egy felhasználói felület, ahol a szolgáltató kapcsolatot tud teremteni a felhasználóval. Nyilván e felületek biztonságát meg kell teremteni annak érdekében, hogy ne tudjon bárki hozzáférni az adott eszközön például egy bankszámlához.

A bankok esetében a core banki rendszerek, vagyis a lényeges, kulcsfontosságú alapszoftverek a háttérben működnek, a fejlesztés pedig ezekkel és, mondjuk, egy viselhető eszközzel teremt kapcsolatot. Ezek természetesen mindig jól behatárolt kapcsolódási pontok. Ha például az otthoni vagy egy nyilvános internetkapcsolat segítségével lekérdezem az egyenlegemet a telefonomon, megnyomok egy gombot, beállítok egy időszakot – például az egyenleg számlatörténetét egy adott időszakra –, azzal a bank rendszerének küldök egy kérést. Az adatbegyűjtést követően visszakapom a kért információt a használt interfészen keresztül. Ennyi történik. Az, hogy az interfész okosóra vagy mobiltelefon, esetleg okosszemüveg, szerintem már majdnem mindegy. Mindig kell egy kis idő ezek hétköznapi rendszeres igénybevételére, megszokására, ahogyan az okostelefonok esetében is ez történt, de ez az idő egyre rövidebb és rövidebb lesz, miközben az eszközök mérete csökken, kapacitásuk pedig növekszik.

Közösségi nyomtatás útközben
A PickaPrinter közösségi nyomtató megosztó szolgáltatás lényege, hogy ha sürgősen szükségünk van egy nyomtatóra, azt egyszerűen és gyorsan megtaláljuk, mégpedig a távolság vagy útvonal tekintetében a számunkra legmegfelelőbb helyen. A közösségi jelleg egyrészt abból adódik, hogy nem csupán nyomtatószalonokban, hanem nyilvános (közösségi) helyeken is elérhető, vagyis kávézókban vagy szállodákban, másrészt abból, hogy ezeket a helyeket, illetve az ott nyújtott szolgáltatást a felhasználók, vagyis a közösség, értékelni tudja. Mindemellett maguk a felhasználók is megoszthatják saját nyomtatóikat.
A PickaPrinter fejlesztőcsapata nemcsak egyedi alkalmazást készített, de azt is zászlajára tűzte, hogy a rendszerben végzett nyomtatások során elhasznált papír pótlására különböző (egyelőre hazai) nemzeti parkokat támogat (faültetés, fagondozás). Ezzel több fa ültetése valósul meg, mint amennyit felhasználnak a nyomtatásoknál, ráadásul a megosztott nyomtatók használata azt is eredményezheti, hogy nem szükséges az eddigi mértékben az otthoni, saját gépet használnunk, ezáltal pedig csökkenhet a környezeti terhelés (például nincsenek beszáradt tintapatronok).
A szolgáltatás webes felületen és mobil platformokon egyaránt elérhető.
Nem jelent ez újabb kihívásokat a biztonság területén?

– Ez a kérdés egyre inkább előtérbe kerül. Amikor szoftverfejlesztésről beszélünk, már a folyamat legelején mérlegelni kell a biztonsági lehetőségeket. Ágazattól függetlenül a legfontosabb üzleti érték az adat, az információ. Ma már a fejlesztői csapatokban egyre inkább megkérdőjelezhetetlen egy biztonsági szakember jelenléte. Fontos, hogy ne akkor kezdjünk el a biztonsági kérdésekkel foglalkozni, amikor már felfedeztük a réseket, vagy amikor már baj van és feltörték a szoftvert, ellopták az adatokat. Eleve figyelni kell arra, hogy ne kerüljenek be olyan megoldások, amelyek beépítése biztonsági rést vagy egyéb kockázatot hagynak maguk után. Ezek már komplexebb módszertani kérdések, bizonyos dolgokat eleve nem használunk egy fejlesztés során, másokat pedig meghatározott formában használunk – ez így nem hangzik túl egyértelműen, de a lényeg, a legfontosabb ebben a szoftverfejlesztői kérdésben az, hogy az adatbiztonságra a munka megkezdésekor már nagy hangsúlyt kell fektetni.•

 
Innotéka