Rendszerelemzés. Konstantinusz Kft.

Átírás

1 Rendszerelemzés Konstantinusz Kft. 2009

2 Tartalomjegyzék 1. Bevezetés Témafelvetés Gyakorlatban alkalmazandó módszerek Hogyan kezdjünk hozzá? Adatok elemzése Folyamatok elemzése Alkalmazottak képességei Változások Bevezetés, oktatás Tipikus buktatók Félreértési problémák Teherbírási problémák Kölcsönös kizárás Hivatkozások Fenntartás Összefoglalás...11

3 1. Bevezetés Az esettanulmány témája a rendszerelemzés, a rendszerelemzést rendszerfejlesztés szempontjából, fogom megközelíteni. A rendszerelemzés meglátásom szerint, az informatikai rendszer fejlesztés első és egyik legfontosabb lépése. Ha hibásan mérjük fel, hogy mit vár tőlünk az ügyfél akkor esélyünk sincsen arra, hogy olyan rendszert készítsünk, ami megfelel az elvárásainak. Ez esetben a szerződéstől függően vagy kötbért kell fizetnünk, vagy ingyen átalakítani, vagyis nagy valószínűséggel veszteséges lesz a projekt. Az esettanulmányban ismertetni fogom, hogy milyen módszereket javaslok rendszer elemzésre, amelyek a gyakorlatban is jól alkalmazhatóak. Valamint azt is ismertetni fogom, hogy miért is fontos egy-egy módszer. Nem szándékozom kitérni elméleti dolgokra, saját tapasztalataimat fogom az esettanulmány során ismertetni. Az esettanulmány főként egyedi rendszerek fejlesztésénél használható elemzéssel foglalkozik, nem az általános rendszer fejlesztéssel, bár a módszerek többsége használható, dobozos szoftverek fejlesztésénél is. Megjegyezném, hogy a rendszer elemzés során nagy valószínűséggel olyan problémákkal is fogunk találkozni, amiket nem feltétlenül informatikailag kell megoldani.

4 2. Témafelvetés Miért is fontos megismerni a rendszerelemzést? Meglátásom szerint azért, mert egy fejlesztés során a legnagyobb hibákat ebben a szakaszban lehet elkövetni. Ha rosszul mérjük fel, hogy hogy működik a rendszer akkor lehetetlen, hogy olyan informatikai rendszert adjunk át, ami megfelel az ügyfélnek. Az informatikai cégek többsége anélkül kezd hozzá egy rendszer kifejlesztésének, hogy alaposan tanulmányozná azt, hogy milyen rendszert kell elkészíteni. Fontos, hogy csak akkor kezdjünk hozzá egy rendszer fejlesztéséhez, ha már megfelelően ismerjük minden részét, hogy is kell működnie. Egy rendszer megismerése időigényes és nem egyszerű feladat, viszont mindenképpen meg fog térülni az, hogyha nem sajnáljuk rá az időt. A legtöbb fejlesztő a rendszer elemzés során arra kíváncsi, hogy az ügyfél mit szeretne, sajnos azonban ez általában nem ilyen egyszerű feladat. Az esetek döntő többségében az ügyfél sem tudja, vagy nem jól tudja, hogy mire is van szüksége. Ennek tipikus esete amikor valójában csak annyit tud, hogy szüksége van egy informatikai rendszerre, hogy kövesse a folyamatait. Kisebb cégeknél az sem ritka, hogy a folyamatokat nem ismeri elég részletesen. Fontosnak tartom megemlíteni, hogy általában az ügyfél számára más az, ami egyértelmű vagy magától értetődő mint egy programozó számára. Ezért is kell mindent tisztázni, minél több dolgot felvenni a rendszer specifikációjába.

5 3. Gyakorlatban alkalmazandó módszerek A következőkben néhány tapasztalatot fogok ismertetni, hogy hogyan is kezdjünk hozzá, mit kell elvégeznünk és, hogy miért. Egyáltalán nem mindegy az sem, hogy az elemzés során milyen benyomást keltünk az ügyfélben. A gyakorlatban előfordul, hogy a specifikáció a szerződés része, vagyis a rendszert meg kell ismernünk még szerződés kötés előtt, ha nem teszünk jobb benyomást akkor az ügyfél elállhat attól, hogy velünk készíttessen rendszert. Ekkor az elemzés során eltöltött nem kevés időt ingyen dolgoztuk. Tekintettel arra, hogy nem egyszerű árajánlatot adni, ismeretlen rendszer fejlesztésre ezért vagy vállaljuk a kockázatot, hogy az ügyfél nem minket választ. Alternatív megoldásként lehet külön szerződést kötni a készítendő rendszer megismerésére. Ennek a szerződésnek a végterméke a specifikáció, ez az ügyfélnek azért jó, mert ha nem is minket választ, akkor ezt egy másik fejlesztő csapat fel tudja használni. Nekünk meg ilyen esetben nem vész kárba munkánk. Többször hallottam programozótól, hogy leülök egy energia itallal holnapra megvan. Ezután két hónap múlva sem tudott csak néhány felületet felmutatni, amelyen viszont a gombok fele nem működött, a másik fele pedig rendszeresen valamilyen szemantikai vagy szintaktikai hibához vezetett Hogyan kezdjünk hozzá? Erre a kérdésre nincs egyértelmű válasz. Első lépésként akkor járunk jól, ha végig járjuk a céget, mintha egy termék vagy ügyfél lennénk és figyeljük meg, hogy hol mi történik. Ez arra lesz jó, hogy megismerjük az adott céget, milyen beosztások léteznek, hol kell majd az elkészülő rendszert használni és hol nem. Hova kell majd hozzáférési pontokat telepíteni, vagy hol kell mobil megoldásokat alkalmazni.

6 3.2. Adatok elemzése Ehhez célszerű elkérni az összes formanyomtatványt, és dokumentumot ami keletkezik, majd ezeket dolgozzuk fel. A feldolgozás után tudni fogjuk, hogy milyen elemek vannak a cégen belül és azoknak milyen tulajdonságai vannak. A végig járás folyamán (3.1.) előfordulhat, hogy találkozunk olyan adatokkal is amelyeket nem dokumentálnak, ezeket is jegyezzük fel, és egyeztessünk az ügyféllel, hogy ezeket miért nem rögzítik Folyamatok elemzése A ben leírtakat ha elvégezzük akkor már egy jó képünk lehet arról, hogy milyen folyamatok vannak a rendszerben ezeket is ki kell gyűjteni, részletesen megnézni, hogy ezek hol kapcsolódnak a rendszer elemeihez. Ha összegyűjtöttük a folyamatokat akkor látni fogjuk, hogy lesznek párhuzamos vagy fölösleges folyamatok. Valamint találni fogunk dokumentálatlan folyamatokat is. Ezeket nem minden esetben informatikai rendszerrel kell megoldani. Különös tekintettel kell lennünk az olyan folyamatokra, amire az ügyfél esetleg azt mondja, hogy az nem fontos, mert olyan nem fordul elő gyakran egy rendszer csak akkor rendszer, ha minden folyamatot még a ritkákat is kezeli. Az ügyfél akkor fogja úgy érezni, hogy nem azt kapta a pénzéért amit szeretett volna, hogy egy ilyen ritka esetet nem tud rögzíteni a rendszerben. Ami a rendszeren kívül van az a kimutatásokban nem létezik, jutalékos fizetés esetén nem jár érte jutalék stb.

7 3.4. Alkalmazottak képességei Nem mindegy, hogy milyen képességgel rendelkeznek az alkalmazottak, különösen akiknek a rendszert kellene használni, törekedjünk arra, hogy a felületek nagyon hasonlítsanak azokra a dokumentumokra amiket eddig kellet kitölteniük. Tipikus probléma, hogy az alkalmazott azt mondja én nem értek hozzá, még akkor is ha a felület pont úgy néz ki mint a dokumentum amit eddig töltött ki. Ez inkább humán politikai probléma, ezt a vezetőségnek kell megoldani Változások Ne feledkezzünk meg arról, hogy a kisebb cégnél nagyon könnyen változhatnak a folyamatok, ezért gondolkozzunk előre, illetve kérdezzük meg a vezetőt, hogy milyen változásokra lehet számítani. Tipikus példa erre az, hogy jelenleg egy pénztárunk van ami egy adott raktárból dolgozik, de később több külön pénztár is lehet, amiből némelyiknek van külön raktára némelyeknek pedig nincs. Ez esetben nagyon kellemetlen ha nem gondolkoztunk előre és a rendszerünknek fogalma sincs arról, hogy pénztár. Szélsőséges esetben előfordulhat, hogy újraírhatjuk a rendszerünk főbb működési folyamatait Bevezetés, oktatás Nem teljesen a rendszerelemzés része, de az mivel az rendszerelemzés célja a részletes megismerés, ezért tartom célszerűnek itt tárgyalni. Gondolkozzunk előre, fontos, hogy gondoljuk át, kiket kell majd oktatni és mire. Fölösleges valakit olyan részekre oktatni amely részét a rendszernek nem vagy csak alig fogja kezelni. Tervezzük meg előre, hogy hogyan akarjuk, hogy mindenki az általa leggyakrabban használt funkciókat érje el és ne lásson olyan gombokat, amiket nem kell használnia. Gyűjtsük össze kérdezés segítségével, hogy ki miket csinál a leggyakrabban. pl.: pénztáros valószínűleg számlát állít ki, a raktáros különböző raktár műveleteket.

8 4. Tipikus buktatók Ebben a fejezetben ismertetni fogom, hogy melyek azok a rendszerelemzési hibák, amiket egy rendszer fejlesztése során el lehet követni, és megpróbálok néhány ötlettel is szolgálni ezek megoldására, kivédésére. Itt lesznek részek, amelyek inkább tervezéshez tartoznak, de kapcsolódnak az elemzéshez is Félreértési problémák A problémák többsége ide sorolható. Ide azokat a problémákat sorolom, amik abból adódnak, hogy nem értjük meg pontosan az ügyfél problémáját. Itt példaként azt lehet említeni, hogy az ügyfél megkeres minket azzal, hogy kell neki egy webshop. Ha ezt elkészítjük, olyan webshopot kap amit szeretne akkor is előfordul, hogy hat hónap múlva megkeres minket, és kiderül, hogy neki nem ez kellet, hanem az, hogy legyen X ezer vagy X millió forint eladása. Ehhez azonban nem csak webshopra van szükség, hanem arra, hogy egy olyan webshopot kapjon, amivel valaki napi 4-8 órát foglakozik. Mint látjuk, ez nem informatikai probléma. Ezt a problémát kétféleképpen lehet megoldani, vagy a rendszerelemzéssorán ezt kiderítjük, és azt adjuk az ügyfélnek, vagy pontosan leírjuk a szerződésben, hogy mit készítünk el, ez esetben nem azt kapja amit szeretne, de pontosan azt ami a szerződésben van.

9 4.2. Teherbírási problémák Ezek általában ritkábban fordulnak elő. Fontos azonban megemlíteni őket, mert ha nem megfelelően mérjük fel, akkor később nagyon rosszul jöhetünk ki a fejlesztésből e miatt. Tipikus példa, egy rendszert elkészítünk, és leteszteljük a működését, jutalék számítást, vagy törzsvásárlói kedvezmények adását, a teszt adatokon. Amikor pedig élesben elkezdik használni akkor nem tud lefutni, mivel a valóságban 2 millió vásárló lesz, míg a teszt adatbázisban csak 10 darab volt. Ezt úgy védhetjük ki, hogy a teszt adatok számát, legalább nagyságrendileg közelítjük a tényleges adatok számához Kölcsönös kizárás Ezek a problémák is ritkán fordulnak elő, de megéri számításba venni őket. Itt olyan dolgokra kell gondolni, hogy valaki dolgozik valamivel és közben valaki megváltoztatja azt. Erre példa, hogy termékeket rakunk össze elszállításra, és figyeljük, hogy három millió forint összegben kell árut összerakni. Miközben pakoljuk össze a szállítmányt, egy másik felhasználó megváltoztatja a termék árát. Ez esetben nem mindegy, hogy azon az áron számolunk tovább, amin elkezdtük, vagy az új áron, vagy nem engedjük megváltoztatni az árat, ha valaki dolgozik vele. Ezeket előre tisztázni kell, mert utólag csak nagy erőfeszítések árán lehet megoldani.

10 4.4. Hivatkozások Ez ismét egy gyakori hiba, az elemzés során döntsük el, hogy mit engedünk törölni. A semmibe mutató hivatkozások súlyos hibákhoz vezethetnek. Erre tipikus példa, vásárlásnál megvesznek egy adott termékeket, és utána a terméket törlik ekkor mi történik? A vásárlásból kikerül az a tétel? Akkor mi lesz a vásárlás összegével az marad ugyanannyi? Ezt a kérdést is fontos eldönteni, tapasztalatom szerint törlést nem kell csak nagyon kis mennyiségben engedni. Inkább úgynevezett logikai törlést kell csak megengedni az ügyfélnek. És csak olyan tudjon törölni, aki mélységeiben ismeri a rendszert Fenntartás Ha rendszert készítünk biztos, hogy kérni fognak fenntartást, vagy felhívnak minket, hogy nem működik. Ezek többsége vak lárma lesz, de gondoljunk rá előre mérjük fel, hogy valószínűleg mennyi hívásra számíthatunk. Valamennyire próbáljunk meg olyan fizetési konstrukciót ajánlani, amiben meghatározzuk a későbbi fenntartás mikéntjét. Vannak cégek, akik ezt úgy határozzák meg, hogy évente három óra technikai segítségnyújtás jár. Más cégek azt a módszert követik, hogy minden hívás X forint, függetlenül attól, hogy miért telefonál az ügyfél. Az ügyfél akkor lesz elégedett a szerződéssel, ha olyan kikötéseket teszünk, hogy a hibajavítást ingyen végezzük. Ez alól valószínűleg nem nagyon tudunk kibújni, de nem is kell, ha alaposan megterveztük a rendszert, akkor a hibák száma minimálisra csökkenthető. Megjegyzem találkoztam már olyan informatikai céggel, ahol pénzért végezték a hiba javítást, ez szerintem etikátlan, csak tőlünk függ, hogy ki tudunk-e ilyen konstrukciót harcolni.

11 5. Összefoglalás Összességében elmondható, hogy minél alaposabban mérjük fel az elkészítendő rendszert annál jobb lesz az általunk készített szoftver. Az elemzésre épül a tervezés, vagyis ha az elemzést elhanyagoljuk, akkor a tervezés is hibás lesz, valamint a végeredmény sem lesz jó. Az elemzés időigényes folyamat, összegyűjteni dokumentumokat megkérdezni az alkalmazottakat, hogy mik a leggyakoribb feladatok. Ilyenkor az is célszerű lehet, hogy odaköltözünk az adott céghez, és alaposan felmérünk minden munkafolyamatot, akár úgy is, hogy minden feladatkörbe beülünk és kitapasztaljuk. Fontosnak tartom megemlíteni, hogy gondolkozzunk előre, senki sem szeret ingyen munkát végezni, ha rossz elemzésből következően az ügyfél nem azt kapja, amit szeretett volna akkor szerződéstől függően, előfordulhat, hogy önköltségen kell kijavítanunk. Így fordul elő szoftverfejlesztő cégeknél, hogy egy két hétre vállalt munkát 3-4 hónapig csinálnak.