Közlekedési rendszertervezés

Közlekedési rendszertervezés

Figyelmeztetés: Ez az anyag a közlekedési rendszertervezés c. tárgy előadási óráinak nagyvonalú vázlata. Kizárólag az órai jegyzetelés megkönnyítését szolgálja. Az anyag tanulmányozása nem helyettesíti az előadásokon való részvételt, illetve az előadáson bemutatott irodalmak tanulmányozását. Az itt leírtak tökéletes ismerete nem elegendő a zárthelyik, vagy a vizsga eredményes abszolválásához!


2

Tartalomjegyzék 1 Bevezetés, alapfogalmak ................................................................................. 5 1.1 1.2 1.3 1.4

2

A közlekedési rendszer és a közlekedési rendszertervezés .......................................5 Ismeretelméleti alapfogalmak: .................................................................................7 Rendszerelméleti alapfogalmak: ..............................................................................8 A rendszertervezés fogalma................................................................................... 10

A rendszertervezésről általában ................................................................. 12 2.1 A rendszertervezés története .................................................................................. 12 2.1.1 A rendszertervezés korszakai ......................................................................... 12 2.1.2 A rendszertervezés kezdetei........................................................................... 14 2.1.3 A számítógépes információrendszerek fejlesztése .......................................... 15 2.1.4 A változás okai .............................................................................................. 15 2.1.5 A rendszerfejlesztés életciklusa .....................................................................15 2.2 A rendszerszervező helye és szerepe .....................................................................16 2.3 Az információ rendszer szervezése ........................................................................ 18

3

Az információrendszer fejlesztés életciklusa ............................................. 22 3.1 A rendszertervezés klasszikus folyamatábrája ....................................................... 23 3.2 A rendszertervezést befolyásoló tényezők ............................................................. 25 3.3 A helyzetfelmérés módszertana ............................................................................. 25 3.3.1 Dokumentumgyűjtés...................................................................................... 26 3.3.2 Interjú............................................................................................................ 26 3.3.3 Kérdőív ......................................................................................................... 27 3.3.4 Mérés, megfigyelés ....................................................................................... 29 3.3.5 A módszerek egymásra épülése, kapcsolata ................................................... 30 3.4 Helyzetrögzítés módszertana ................................................................................. 30 3.4.1 Statikus struktúra rögzítése: ........................................................................... 30 3.4.2 Dinamikus struktúra rögzítése ....................................................................... 32 3.4.3 Informatikai fejlettség rögzítése .....................................................................32 3.4.4 Statisztikai és gazdasági jellegű adatok rögzítése ........................................... 33 3.5 Helyzetelemzés .....................................................................................................33 3.6 A rendszerkoncepció ............................................................................................. 36 3.6.1 Az irányító rendszer hatáskörének tisztázása ................................................. 36 3.6.2 A komplex információrendszer koncepciójának kidolgozása ......................... 36 3.6.3 Géprendszer koncepciójának a kidolgozása ................................................... 37 3.6.4 Programszükséglet körvonalazása..................................................................37 3.6.5 Szakemberszükséglet körvonalazása .............................................................. 37 3.6.6 Költségszámítás............................................................................................. 37 3.6.7 Időterv készítés.............................................................................................. 41 3.6.8 Dokumentáció ............................................................................................... 42 3.6.9 Munka folytatásával kapcsolatos döntés dokumentálása ................................ 42 3.7 Rendszerterv ......................................................................................................... 44 3.8 Alrendszerek tervezése .......................................................................................... 45 3.9 Kivitelezés, bevezetés ........................................................................................... 45 3.9.1 Manuális eljárások kidolgozása .....................................................................45 3.9.2 Programozás, tesztelés ................................................................................... 46 3.9.3 Felhasználók kiképzése ................................................................................. 46 3.9.4 Rendszer üzembe helyezés ............................................................................ 47 3.9.5 Átállás megtervezése ..................................................................................... 47 3.9.6 Rendszer átadása ........................................................................................... 47

Közlekedési rendszertervezés 3.9.7 3.9.8

4

Értékelés: ...................................................................................................... 47 Karbantartás, továbbfejlesztés ....................................................................... 48

Ábrázolási technikák a rendszertervezésben .............................................. 49 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

5

3

Diagrammok: ........................................................................................................ 49 Táblázatok ............................................................................................................ 49 Mátrixok ............................................................................................................... 50 Szervezeti ábrák .................................................................................................... 52 Információkapcsolati diagrammok ........................................................................ 53 Információáramlási folyamatábrák ........................................................................ 55 Funkcionális kördiagram ....................................................................................... 57 Területi elrendezési ábrák...................................................................................... 57

Szervezet elemzés ...................................................................................... 59 5.1 A szervezetekről általában ..................................................................................... 59 5.2 Szervezet – szervezeti felépítés ............................................................................. 61 5.2.1 Környezet ...................................................................................................... 63 5.2.2 A vállalt adottságainak befolyásoló szerepe ................................................... 65 5.2.3 A szervezet alapfeladatai (tevékenységi kőr) ................................................. 67 5.2.4 Stratégia ........................................................................................................ 68 5.3 Szervezeti struktúrák és formák ............................................................................. 69 5.3.1 Munkamegosztás ........................................................................................... 69 5.3.2 Hatáskörmegosztás (egy- és többvonalas szervezetek) ...................................70 5.3.3 A koordinációs eszközök ............................................................................... 70 5.3.4 Konfiguráció mint másodlagos jellemző ........................................................ 74 5.3.5 Leggyakoribb szervezeti alapformák ............................................................. 75 5.4 Humán erőforrás-gazdálkodás (management) ........................................................ 80

6

A rendszertervezés komplex módszertanai ................................................ 81 6.1 Bevezetés a komplex módszertanokba:..................................................................81 6.2 A rendszerfejlesztés komplex módszertanainak általános bemutatása .................... 81 6.3 Az IBM vállalati információrendszer tervezési módszere (BSP) ............................ 82 6.3.1 A BSP alapelvei ............................................................................................ 82 6.3.2 A BSP módszer lépései.................................................................................. 84 6.3.3 A BSP és a dokumentáció .............................................................................. 86 6.3.4 A BSP módszertan értékelése ........................................................................ 86 6.4 ARDOSZ '79 - a rendszerfejlesztés legismertebb hazai módszertana ..................... 87 6.4.1 Az ARDOSZ általános bemutatása ................................................................ 87 6.4.2 Az ARDOSZ tervezési módszerei is technikái ............................................... 87 6.4.3 Az ARDOSZ dokumentálási rendszere .......................................................... 88 6.4.4 Az ARDOSZ értékelése ................................................................................. 89 6.5 SDM-HOSKYNS rendszerfejlesztési módszertan.................................................. 89 6.5.1 Az SDM módszertan alapelvei ...................................................................... 90 6.5.2 A rendszerfejlesztés folyamata a módszertan alkalmazásával......................... 92 6.5.3 Az S D M (HOSKYNS) módszertan munkafázisai ........................................ 94 6.5.4 Az SDM módszertan dokumentációs rendje ................................................ 103 6.5.5 A módszertan értékelése .............................................................................. 104 6.6 Az SDM - PANDATA fejlesztési módszertan ..................................................... 105 6.6.1 Az SDM - PANDATA fejlesztési módszertan áltlános felépítése ................. 105 6.6.2 A módszertan lépései ................................................................................... 106 6.6.3 A módszertan értékelése .............................................................................. 111 6.7 Egyéb strukturált módszertanok .......................................................................... 111 6.7.1 SADT- Structured Analysis and Design Technique ..................................... 111


4

6.7.2 DARTS – Design Method for Real-Time Systems (Adatfolyamorientált tervezési módszetan valós idejű feldolgozásokhoz) ..................................................... 112 6.7.3 DOMINO: Integrált fejlesztési módszertan .................................................. 112 6.7.4 EuroMethod ................................................................................................ 112 6.8 Az SSADM rendszerfejlesztési módszertan ......................................................... 113 6.8.1 A módszertan célja, rendszerszemlélete ....................................................... 114 6.8.2 Az SSADM módszertan alapelvei, jellemzői ............................................... 116

7

Minőségbiztosítás a szoftverfejlesztésben:............................................... 142


5

1 Bevezetés, alapfogalmak 1.1 A közlekedési rendszer és a közlekedési rendszertervezés A közlekedési rendszertervezés cím a teljes közlekedési rendszerre utal. A közlekedés azonban igen komplex. Beleértjük a: közlekedés szervezetét közlekedést mint gazdasági ágat magát a helyváltoztatási folyamatot. A tárgykör pontosítása szükséges, ami azonban csak akkor lehetséges, ha áttekintjük a leglényegesebb rendszerekkel kapcsolatos fogalmakat. A mindenkori rendszerkövetelmények teljesítéséhez meg kell tervezni a rendszer: vázszerkezetét (statikus struktúráját horizontálisan és vertikálisan) működését (dinamikus struktúráját) teljesítményét, kapacitását irányítását információ ellátását mind belsőleg, mind külső kapcsolatait tekintve A közlekedési rendszert témánk szempontjából az alábbi négy fő területre oszthatjuk:

Közlekedési rendszertervezés STATIKUS STRUKTÚRA pálya, úthálózat járművek energiarendszer környezet szállítmány

6 DINAMIKUS STRUKTÚRA

fő tevékenységgel kapcsolatos (szállítás) mellék, kieg. tevékenységgel kapcsolatos működés.

Irányítási információs Irányítási info. rendszeri koponensek: kezeléssel kapcs. működés: információk rendszere adatbázis rendszer szoftver rendszer hardver rendszer

A-E rendszeri összetevők

Irányítási információs rendszeri összetevők

felvétel átvitel tárolás feldolgozás felhasználás Erre a négy struktúrára terjed ki a „közlekedési rendszertervezés” és e cím használatát ezek a szempontok teszik lehetővé akkor is, ha alapvetően az irányítási információs rendszer tervezésével foglalkozunk. Az A-E rendszeri összetevőkkel kapcsolatos ismereteket más szaktárgyak témakörébe tartoznak. Ez a tantárgy keretében csak az irányítási információs rendszer tervezésével foglalkozik. Kérdés, hogy így miért jogos a „közlekedési rendszertervezés” megnevezés: a) A rendszertervezés szóhasználat először az információs rendszerek tervezésével kapcsolatban terjedt el. Ekkor a „közlekedés” szó csak szűkebb tervezési területet jelöl. b) Az irányító rendszer nem tervezhető meg az irányított rendszer nélkül. c) Az irányító információs rendszer visszahat magára az irányított rendszerre. d) Az irányításkor használatos információk az irányított rendszert leképező absztrakciók tükörképei. e) Az információs rendszer fejlesztésének fő célkitűzése az egész közlekedési rendszer fejlesztése. Nyilvánvaló tehát, hogy indokolt a „közlekedési rendszertervezés” szóhasználat, jóllehet e tantárgyban – a korábban elsajátított szaktárgyak ismeretanyagát felhasználva –,

csak

közlekedési információs rendszerek módszertanával foglalkozunk. Ez ugyanis a közlekedési


7

informatikai, telematikai rendszerekre vonatkozik amivel más közlekedési szaktárgyak nem, vagy csak érintőlegesen foglalkoznak.

1.2 Ismeretelméleti alapfogalmak: Adat, információ és tudás Adat: rögzített jelsorozat. Információ: egy adott rendszer számára, annak működését befolyásoló, új ismereteket hordozó jelkonfiguráció tartalmi jelentését értjük. Az információ tehát nem egyenlő az azt hordozó jelsorozattal. Tudás: A valós világnak, az abban létező dolgoknak, tényeknek, eseményeknek, jelenségeknek, az azok között fennálló kapcsolatoknak, okozati összefüggéseknek az emberi tudatban történő visszatükröződése. Az információ ugyanis csak statikus állapotot képes tükrözni, nem alkalmas bonyolultabb kapcsolatok kifejezésére, összefüggések, elemek közötti viszony meghatározására. Azok a valós világ jelenségeiről, folyamatairól megismerés, tapasztalás és tanulás útján szerzett ismeretek azonban, amelyek alkalmasak következtetések levonására elvonatkoztatásra, újabb ismeretek, felfedezések tételére egy magasabb szintű rendszert alkotnak, amelyet tudásnak nevezünk 1. Új ismeret: Ahhoz, hogy információról beszélhessünk, nagyon fontos az, hogy új ismeretet közvetítsen. Nem általában, hanem a fogadó fél korábbi ismereteihez képest. Új: adott esemény bekövetkezésével kapcsolatos bizonytalanságot megváltoztat. Nincs kikötve, hogy ez csak határozatlanságot csökkenthet, növelheti is ezt a határozatlanságot. 2. Határozatlanság változtatása A határozatlanság sem általában létezik, hanem rendszerspecifikus tulajdonság. Ugyanaz a jelkonfiguráció más-mást jelenthet a különböző rendszerekben. 3. Döntő a felhasználás A határozatlanság változását csak az adott rendszer működésével kapcsolatban tudjuk értelmezni, ami azt jelent, hogy csak akkor változik a határozatlanság, ha az rendszer


8

működését befolyásolja, ha az információt valamilyen formában felhasználják. A felhasználás leggyakoribb esete a döntés. 4. Entrópia tulajdonság Valamennyi szervezetben létezik entrópia. A rendszerbe bevitt információ csökkenti a rendszer entrópiáját, a szervezetlenség mértékét. Azt is mondhatjuk, hogy az információ megszünteti a szervezetlenséget, az entrópia pedig a megmaradó szervezetlenség. Az információs rendszer különféle típusú elemekből épül fel és fontos, hogy az u. n. ember-

Adatbázis

Interfész

Feldolgozások

Interfész

gép rendszerek csoportjába tartozik. A fenti egyszerű ábrán azt a felfogást látjuk: melynek értelmében a rendszer egyik oldalán a felhasználó áll, a másik oldalán azok az adatok, amelyek a felhasználó számára viszonylag hosszú ideig fontosak. Az ábrán nincsenek feltüntetve az eszközök, amelyek hardver és szoftver részekből állhatnak.

1.3 Rendszerelméleti alapfogalmak: Arisztotelész „Az egész több mint a részek összege” Rendszer: Meghatározott struktúra szerint egymással összefüggő és kölcsönhatásban lévő elemek egymással és a struktúrákkal összhangban lévő elemek együttese. (RM26) Elemek és az elemek közötti kapcsolatok halmaza. (WGy) Célja: (pl. áruk szállítása) Tartalma: a teljes való világ rendszeren belüli része. Rendszer környezete: a rendszert körülvevő, annak működését befolyásoló, illetve a rendszer által erre ható rész. Rendszer statikus szerkezete: az elemek és azok kapcsolatai Rendszer dinamikus struktúrája: a cél megvalósítására felvett szerkezete.


9

Struktúra: a rendszert alkotó elemek az elemek között értelmezett valamennyi lehetséges kapcsolattal együtt. Egyszerű rendszerek: további alrendszerekre nem bontható Komplex rendszerek: belső felépítésük összetett: alrendszerekre, ill. részrendszerekre bontható Részrendszer: A vizsgált rendszeren belül relatíve önállóan viselkedő elemek részhalmaza, amelynek környezete a rendszer többi része. Alrendszer: Valamely rendszernek, vagy részrendszernek egy jól lehatárolható tartománya, amely értelmezhető belső struktúrával rendelkezik, azonban a rendszer többi alrendszerével való relációban értelmezhető. Nyílt rendszerek: környezetükkel kölcsönhatásban állnak. Zárt rendszerek: nincs kapcsolatuk a külvilággal (Ilyen rendszerek csak elméletileg léteznek) Technikai rendszerek: Csak technikai összetevőket tartalmaznak. Szervezeti rendszerek: Technikai és humán összetevőket tartalmaznak. A szervezeti rendszerek adott, vagy változó környezeti feltételek mellett, jól definiált cél megvalósítására törekszenek.

A

cél

megvalósítása

érdekében

adott

bemenetekből

meghatározott

transzformációt biztosító algoritmus segítségével a cél elérése érdekében szükséges kimeneteket állítanak elő és ilyen működésükhöz speciális statikus és dinamikus struktúrát alkalmaznak. Mindkét struktúrát képesek a megváltozott környezeti feltételekhez igazítani. Konkrét rendszerek: (fizikai, pl.: gyártósor) Társadalmi rendszerek: Determinisztikus rendszerek: Egy adott bemenetre, illetve bemeneti kombinációra konkrét válaszokat adnak. (pl.: számítógép) Sztochasztikus rendszerek: Egy megadott bemenetre, illetve bemeneti kombinációkra valamilyen valószínűségi függvény által leírt válaszokat adnak. (pl.: minőségellenőrző, tőzsde) Információs

rendszer:

Az

objektív

valóságra

vonatkozó

megfigyelések,

adatok

megszerzésével, átalakításával, csoportosításával, feldolgozásával és megjelenítésével kapcsolatos tevékenységeket foglalja magában.


10

Az információ felhasználása közvetlenül vagy közvetve döntéshez kapcsolódik. Ha a döntéseket tárgyuk vagy típusuk szerint összefüggésbe rendezzük az irányításhoz jutunk. Ezért használjuk a tananyagban az irányítási információs rendszer kifejezést. Az általunk vizsgált információs rendszereket az alábbi tulajdonságok jellemzik: 1. Célratörők: a rendszer működésében van egy olyan kitüntetett állapot aminek az elérésére törekszik. A célratörő rendszer képes saját működésének korrigálására. 2. Nyíltak: környezetükkel anyag, energia és információkapcsolatban állnak. 3. Határozatlanok: a rendszer működése során az értelmezett rendszerállapotok bekövetkezése csak valószínűsíthető. 4. Tervezettek: egy adott feladat létrehozására hozták létre 5. Szervezett rendszerek: saját működésüket tekintve bizonyos fokú autonómiával rendelkeznek. 6. Bonyolultak: az elemek és elemkapcsolatok száma meglehetősen nagy, egyidejű áttekintésük szinte lehetetlen. 7. Hierarchikusak: önálló rész és alrendszerekre bontható 8. Totális rendszerek: a részrendszerek között kölcsönkapcsolatok vannak. 9. Önszervező, adaptív rendszerek: környezetükhöz bizonyos határokon belül alkalmazkodni tudnak a részrendszerek dinamikus kapcsolatai által. 10. Irányítást tartalmaznak. (GA13)

1.4 A rendszertervezés fogalma Rendszertervezés: Rendszereink szervezésének, tervezésének feladata, olyan állapot létrehozása, amelyben az erőforrások felhasználása révén a rendszerrel elérendő cél az adott körülmények között a leghatékonyabban megvalósítható. (A hatékonyság alatt az eredmény és a ráfordítás viszonyát nézzük.) (WGy) Vagyis az informatikai rendszernek olyannak kell lennie a közlekedés egész rendszerét tekintve, hogy a szállítási, közlekedési feladatok leghatékonyabb megoldását segítse elő az adott feltételek mellett. A rendszertervezésen fogalmát többféle értelemben is használják mind a mai napig: gépi-technikai, programozási, komplex információ rendszer tervezésére.


11

A fentiek közül a közlekedési rendszertervezés során a komplex információ rendszer tervezésére vonatkozó jelentést fogjuk használni. A rendszertervezés során a rendszertervezés, és rendszerszervezés szavakat szinonimaként használjuk. Amennyiben a két kifejezést mégis meg kívánjuk különböztetni egymástól, akkor a rendszertervezés elsősorban új informatikai rendszerek létrehozásakor használható, a rendszerszervezés pedig meglévő információs rendszer átalakításakor.


12

2 A rendszertervezésről általában 2.1 A rendszertervezés története 2.1.1 A rendszertervezés korszakai A rendszerszervezés mindig a technikai (hardver és szoftver) eszközök fejlődésére épült, de jelentős mértékben befolyásolta és befolyásolja ezt a fejlődést az igények letapogatása és megfogalmazása. A nagyon korai időszakban a rendszerszervezői munka célja az volt, hogy minél pontosabban meghatározza a programozó számára az előállítandó outputokat, melyek döntően papíroutputok voltak, és tablóknak nevezték azokat. A rendszerszervezés úgy jellemezhető, mint outputorientált rendszertervezés. A munka mindig úgy indult, hogy minél pontosabban sikerüljön meghatározni a felhasználó által igényelt outputokat (tablókat), ezt követően az outputok előállításához szükséges algoritmusokat, valamint az algoritmusok adatigényét. Ezen a ponton kétfelé vált a szervezési munka; el kellett dönteni, hogy az algoritmusok adatigényét milyen arányban elégítjük ki huzamosabban tárolt - törzs jellegű - adatokból, illetve esetenként kifejezetten az adott feldolgozáshoz bevitt adatokból. Fontos jellemzője ennek a korszaknak, hogy a feldolgozásnak van központi szerepe. Minden további rendszerösszetevőt eköré kellett csoportosítani. A feldolgozások miatt kellett az általuk szolgáltatandó outputokból kiindulni, majd a szintén általuk igényelt adatokkal foglalkozni. Az adatok még csak mint a feldolgozás eszközei jelentek meg. Az algoritmikus program kódja a program végrehajtásakor passzív adatrészből, és az ezen dolgozó (aktív) algoritmus részből áll. Az adatok között kiemelt szerepük van az input és az output adatoknak. A rendszerszervezési módszerek fejlődésének első korszaka alapelveit tekintve folyamatközpontos volt, technikailag pedig az output-orientáltság jellemezte. A rendszerszervezési módszerek fejlődésének első korszaka alapelveit tekintve folyamatközpontos volt, technikailag pedig az output-orientáltság jellemezte, algoritmikus program azaz passzív adat és aktív algoritmus jellemző rendszertechnikai szempontból rá. Rendszerszervezési szinten tapasztalt gondok: rengeteg adatot átfedő módon tartalmaztak (redundancia), nem egységesen határozták meg az adatok neveit. A hardver fejlődése, nevezetesen a háttértárak létrejötte és címezhetősége után már csak egy lépés volt az állományszervezés, mint külön rendszerszervezési tématerület. Elvileg már át lehetett volna térni az adatbázis-kezelésre, de ehhez meg kellett alkotni az adatbázis- kezelő rendszereket (mint szoftvertermékeket) és ki kellett dolgozni az ilyen környezetben hatékony rendszerszervezési technikákat (például az adatmodellezést). A programozói törekvések a munka hatékonyságának növelésére, valamint a hardver fejlesztése találkoztak, és megszületett az adatbázis-kezelés elve. Az adatbázis-kezelő rendszerek megjelenése fokozatosan és gyökeresen átalakította a rendszerszervezéssel kapcsolatos szemléletet. Nagyon lényeges súlyponteltolódás következett be, az addigi outputorientáltság helyett mindinkább az adatorientáltság szemlélete tört előre. Újabb és újabb outputokat kitalálhat bármely pillanatban egy-egy felhasználó, ami azonban viszonylag állandó módon, hosszabb távon jellemzi egy szervezet működését, az a saját adatbázisa. Ha sikerül megfelelően - azaz valósághűen - feltárni és meghatározni, akkor hosszú távra megvethetjük az adott szervezet teljes - vagyis integrált - információs rendszerének alapjait.


13

Az, hogy ezt milyen módon lehet elérni, milyen rendszerszervezési technikákat kell alkalmazni, hogyan lehet a legmegfelelőbb adatszerkezeteket meghatározni, ez volt a rendszerszervezés második nagy korszakának alapkérdése. Ez a korszak a 70-es évtizedre tehető. Ekkoriban dolgozták ki az adatmodellezés elméletét és gyakorlatát. A korszak legjelentősebb adatkezelési szakemberei: Bachman (az adatbázis-kezelés első számú úttörője), Codd (a relációs adatbázisok elméletének kidolgozója), Halassy (a fogalmi szintű adatmodellezés egységes szemléletének megalkotója). A hardverfejlesztések eredményeképpen rendelkezésre álló egyre nagyobb központi és háttértárak egyre nagyobb programok írását és futtatását tették lehetővé. Világossá vált, hogy a nagy programokat sokkal könnyebben és megbízhatóbban lehet elkészíteni, ha modulokra bontjuk őket, és a modulokat összekapcsolva egy szerkezetet - struktúrát - alakítunk ki. Az is kiderült, hogy a strukturálásra szabályokat lehet kidolgozni , így alakult ki a strukturált programozás elmélete és gyakorlata. E terület legjelentősebb szakemberei Jackson, Warnier és Dijkstra. A rendszerszervezési módszerek fejlődésének második korszakának jellemzői: 1. A strukturált programozás megjelenése 2. Az adat-báziskezelés elve, relációs adatbázisok elmélete, az adatmodellezés egységes szemléletének megalkotása, 3. Az adatorientáltság szemlélete. Az adatbázis-kezelő rendszerek a nagy és osztott adatbázisok kezeléséhez hatékony mechanizmusokat, kényelmes szolgáltatást nyújtanak. Program helyett itt adatbázisalkalmazásokról beszélünk. Az adatbázisok a program adatrészének, míg az adatbáziskezelőrendszer az algoritmusrész kiterjesztéseként funkcionál. Az adatrész továbbra is passzív. Az algoritmusrész helyét az adatbázis-kezelő rendszer, valamint a megengedett adatbázis-kezelő nyelven megírt alkalmazói programok foglalják el. Azonban nem csupán ezek; egy adatbázisalkalmazás “kinyit” a végfelhasználó felé. Olyan szolgáltatásokat kínál, amelyekkel a felhasználó feladatokat fogalmazhat meg és adhat a rendszernek megoldásra. Mind a fejlesztő, mind a felhasználó nem valamely algoritmus megadásával, hanem leíró stílusban deklarálhatja a rendszer számára azt, hogy MIT, azaz milyen feltételeket kielégítő adatokat kíván outputként megkapni. Az algoritmikus programozás mellett megjelent tehát a deklaratív feladat-leírási stílus is, amely jó néhány programozási nyelvre (pl. LISP, Prolog, Logo) is jellemző, és amely természetes módon valósul meg az ún. tudásalapú rendszereknél. Ezek már komoly beruházásoknak voltak tekinthetők, és ennek megfelelő komolysággal kellett foglalkozni a velük kapcsolatos döntésekkel, a vezetésükkel. Kialakult tehát az általános projektvezetés egy sajátos területe, a számítógépes rendszerfejlesztési projektek irányítása. Tovább finomodott a fejlesztés munkaszakaszainak, az azokon belüli tevékenységeknek a felbontása (életciklus), a közöttük levő logikai kapcsolatok struktúrájának a meghatározása, a tevékenységek időigényének becslése. A nagy rendszerek kialakítása hangsúlyozottabbá tette a dokumentáció fontosságát. Határozott törekvések történtek szabványos dokumentációs rendszerek kialakítására. Ezzel összefüggésben egyre sürgetőbben jelentkezett az igény a rendszerfejlesztés számítógépes támogatására. Nagyon nehéz volt ugyanis az egyre terjedelmesebb dokumentáció manuális kezelése. Technikailag már látszott, hogy az adatbázis-kezelő rendszerek minden további nélkül alkalmazhatóak egy sajátos adatbázis, az ún. fejlesztési adatbázis kezelésére. Akkoriban az ilyen tartalmú adatbázisokat adatszótáraknak neveztük. Az adatszótár tehát egyfajta számítógépesített dokumentációs rendszernek tekinthető. Ezt követően elérkezett az idő, annak felismerésére, hogy nincs elsőbbségük sem a folyamatoknak, sem az outputoknak, sem az adatoknak a rendszerszervezési munka sorrendiségét tekintve. Minden rendszerelemmel foglalkozni kell önmagában is,


14

valamint egymással való kapcsolatukkal is. Egyrészt megkülönböztetünk elemzési és tervezési, másrészt fizikai és logikai szinteket. Az elemzés során az felülről lefelé haladó szemléletet, a tervezés során az alulról felfelé haladót alkalmazzuk. A másik fontos felismerés az volt, hogy minden szinten belül egyaránt foglalkoznunk kell mindegyik alapvető elemcsoporttal: az adatokkal a folyamatokkal (feldolgozásokkal) és az ember- gép rendszer határfelületével (input/output), amelyet szokás felhasználói interfésznek is nevezni. Ezek kombinációjából adódik az a szemlélet, hogy egy meglevő, fizikailag létező információs rendszer elemzésével indul a rendszerszervezési munka, ebből bontja ki a meglevő rendszer logikáját. Ezt a módszert pilot projekteknek vagy demótervezésnek nevezik. A rendszerszervezési módszerek fejlődésének harmadik korszakának jellemzői: 1. Adatbázisalkalmazás- ill. általában alkalmazásfejlesztés, 2. Felhasználóbarát környezet (a képernyő kialakítása, az adatbevitel és a megjelenítés módja, hibakezelés, menüvezérlés), 3. Deklaratív vagy leíró nyelv használata, 4. A projektvezetés módszereinek kidolgozása, 5. A dokumentáció fontosságának felismerése, 6. Pilot projekt módszerének kidolgozása,

2.1.2 A rendszertervezés kezdetei (WGy órai jegyzet, 1998.03.19) Howard Levin (1965) Dél Amerikai Pacific Vasutak információs rendszerének tervezése Lépések: információs folyamat elemzése információs rendszer meghatározása és a berendezések kiválasztása rendszer felszerelése és üzembe helyezése Siemens (1967)  tervkészítési fázis  helyzetfelvétel  feltételek megtervezése  fejlesztési alternatívák kidolgozása  megvalósítási időterv készítése  felszerelés, előkészítés fázisa  feldolgozási folyamat ábra készítés  program készítés  számító központ tervezése  átviteli fázis  adatbázis, adatbiztonság megtervezése Honeywel (1968) BISID (Business Information System Analysing and Design)  rendszer elemzés  helyzet felmérés  folyamat elemzés  rendszer tervezés  információs rendszer modellje  működő rendszer megtervezése  bevezetés megtervezése


15

Kanter (1972)  helyzetelemzés  meglévő helyzet elemzése  rendszer tanulmány készítés  rendszertervezés  információ rendszer tervezése  hardver tervezés  rendszer felszerelés  programozás  üzembe helyezés  üzemeltetés

2.1.3 A számítógépes információrendszerek fejlesztése Ez a típusú rendszerfejlesztés ma már hosszú múltra tekint vissza. A kezdeti időszakokhoz képest jelentős változásokat tapasztalhatunk a rendszerszervező munkában: Rendszertervezés

Régen

Ma

Cél

Egyfajta adat feldolgozás

Sokféle adat feldolgozás, több szervezet részére

Dokumentálás

Vázlatos

Kiterjedt, felhasználó barát

Személyzet

Szervező, programozó, karbantartó ugyanaz

Minden tevékenységnek külön szakembere van

Munkafolyamat

Egyszerű, ügyviteli foly.

Komplex, önálló rendszerek

Szervezet

Egy

Sokféle

2.1.4 A változás okai 

Gyorsabb számítógépek – felhasználói igénynövekedés



Nem kellően megalapozott előkészítés – toldozás foldozás, nehéz karbantarthatóság.



Számítógép misztifizáslása = a számítógép önmagában képes a problémák megoldására.



Sok költséges projekt látványos bukása  rendszertervezési eljárások használata, és kidolgozása

2.1.5 A rendszerfejlesztés életciklusa A rendszertervezési életciklus sokféle módon bontható fel. A legáltalánosabb felbontás a következő:


16

1. Vezetői elhatározás 2. Előzetes helyzetfelmérés 3. Részletes helyzetfelmérés 4. Információ rendszer logikai tervezése 5. Információ rendszer fizika tervezése 6. Információ rendszer kialakítása 7. Bevezetés 8. Karbantartás A következő ábrán azt láthatjuk, hogy az eljárás egyes fázisaiban hogyan változik a kockázat, ill. hogyan nőnek a ráfordítási költségek, illetve milyen munkavolumen szükséges a rendszerfejlesztők valamint a felhasználók részéről. 

a kockázat akkor a legnagyobb amikor a költség és munkaráfordítás még kicsi



a költség és munkaráfordítás akkor emelkedik, amikor a rendszertervezésben elegendő

költség

kockázat

pontossággal előirányozható a teljes fejlesztés, az összes körülményt figyelembe véve.

idő

2.2 A rendszerszervező helye és szerepe A rendszertervezés többnyire olyan bonyolult feladat, amellyel egy szakember nem képes megbirkózni. Általában egy rendszertervezéshez szükség van o rendszertervezőre o hardver szakértőre és o programozóra nekik kell együttműködniük a o helyi szakemberekkel és más o konzulensekkel.

Közlekedési rendszertervezés A fejlesztési mukafázis Helyzetfelvétel és elemzés Rendszerterv készítés Alrendszer tervezés Kivitelezés, üzembe helyezés Üzemeltetés

17 Rendszertervező 5

Hardver szakértő 1

Programozó

5

3

2

3

1

2

2

5

4

1

3

3

0

Az egyes szakemberek részesedési aránya a rendszertervezés fő munkafázisaiban A rendszertervezőnek képesnek kell lennie arra, hogy a teljes folyamatokat átlássa, képes legyen azok jobb megszervezésére, jó hardver és szoftver ismeretekkel kell rendelkeznie, és megfelelő gazdasági ismereteknek is a birtokában kell lennie. Ezen kívül tudnia kell csapatban dolgozni, munkatársainak többségét neki kell összeválogatnia. Általában az alábbi kérdésekre kell tudnia válaszolni: 

mit kell csinálni és miért?



hol kell csinálni és miért?



mikor kell csinálni és miért?



kinek kell csinálni és miért?



hogyan kell csinálni és miért?

Ahhoz, hogy valamilyen munkavégzést irányítani lehessen a következő tényezőket kell ismerni:  mi az előállítandó eredmény  milyen részekre bontható fel a munka  milyen típusú munkaerőt igényel a feladat.

18

Tervezési munkák

Kivitelezés bevezetés

Rendszerelemzés

Felhasználók munkája

Célkitűzés

Rendszertervezők munkája


Előkészítő munkák idő

A munkaráfordítás változása az idő függvényében

2.3 Az információ rendszer szervezése Egy-egy adott szervezetben az információrendszer fejlesztése a legkülönbözőbb okokból kezdődhet, azonban minden esetben a vezetésnek kell kezdeményezni, vagy a kezdeményezést a vezetésnek kell megerősíteni. Miért lényeges rendszerszervezési szempontból a kezdeményezés alapos vizsgálata? A tapasztalatok szerint az információrendszer fejlesztésének igénye mindig valamilyen konkrét elképzelés (projekt) köntösében jelentkezik. A nagy kérdés az, hogy a vezetés által érzékelt vagy elismert - tünetek, rendellenességek (anomáliák) kiküszöbölésére az eredeti elképzelés a legmegfelelőbb-e vagy valahol máshol kell a probléma gyökerét keresni. E kérdésben a gyakorlat néhány olyan általános jelenségre irányította rá a figyelmet, amely támpontot adhat az eligazodáshoz. Működési problémák Leggyakrabban tapasztalt kifogás: az éppen üzemelő információrendszer nem jól működik. (Lényegtelen, hogy a nem jól működő információrendszer hagyományos, manuális feldolgozásra vagy számítógépes feldolgozásra épül.) A rossz működésnek rengeteg tünete lehet, így többek között: állandósuló tűzoltó-munka; a valós folyamatok áttekinthetetlensége; állandó késedelem az adatszolgáltatásban (információtartalom rohamos csökkenése); párhuzamos feldolgozások kialakulása (koordinálatlanul és egymástól elszigetelten) és még sok más egyéb. A jó rendszerszervező tudja, hogy az említett jelenségek tünetek, a tünetek alapján először jó diagnózist kell készíteni. A terápián csak ezt követően lehet gondolkodni. Szervezeti változások Változtatni kell az információrendszeren akkor is, ha változik az információrendszerhez tartozó szervezeti felépítés. Ez bekövetkezhet pl. azért, mert egy vállalat expanzívan növekszik, újabb és újabb szervezeti egységekkel bővül. De megfigyelhető az ellenkező


19

irányú változás is, behemót vállalatokat fognak "fogyókúrára", ez is indokolhat változtatást az információrendszerben. Információrendszer szervezése szempontjából a szervezeti felépités nem lehet elsődleges szempont, de alapvető szervezeti típusok az információrendszer szervezése során eltérő megközelítést igényelnek. Az alapvető szervezettípusok a következők: centralizált szervezet; decentralizált szervezet; osztott szervezet. A szervezetek természetes fejlődése alapján egy-egy szervezet az idők során egyik szervezeti formából másikba szerveződhet, s ez önmagában is ösztönözheti az információrendszer módosítását, fejlesztését. Változnak a feladatok Igen gyakori ok a környezet változásának hatására kezdeményezett fejlesztés. Megváltoznak a valós rendszer feladatai és/vagy működési körülményei. Gondoljunk csak a napi valutaárfolyamok bevezetésével járó gyorsabb információszolgáltatás igényére, vagy az adószabályozás változtatásának hírére meginduló gyors számításokra. A környezeti változások az információrendszertől vagy meglévő szolgáltatások gyorsabb elvégzését vagy a szolgáltatások körének bővítését követelik meg. Sokszor mindkettőt egyszerre igénylik. Technikai-technológiai fejlődés A technikai-technológiai fejlődés (netalán fejlesztés) is lehet az információrendszer szervezését kiváltó ok. A számítógépek árának rohamos csökkenése, a személyi számítógépek gyors és széleskörű elterjedése a számítástechnika alkalmazását egy kiváltságos kör helyett széles tömegek számára tette elérhetővé. Emellett és ezen felül a mai számítógépek olcsóságuk mellet nagyságrendekkel "tudnak többet" elődeiknél. Tervszerű fejlesztés A fejlesztési kezdeményezések közül természetesen nem zárhatjuk ki azt az esetet sem, amikor tudatos, tervszerű fejlesztésről van szó. Arra gondolunk, amikor először elkészítik a komplex integrált információrendszer fejlesztésének távlati koncepcióját, tervét, s azt fokozatosan, részletekben valósítják meg. Ilyenkor az egyes fejlesztési lépcsők megvalósítási igénye mögött már nem szükséges az indítóokokat kutatni. Sajnálattal kell mondani, de az ilyen hosszú távra történő tervezés, végrehajtás ritka, mint a fehér holló. Az okok között egyaránt megtalálhatjuk a megvalósítás igen hosszú elhúzódását, a kívánatos szakmai felkészültség, belső szervezettség hiányát. (Optimista becslés szerint is, egy viszonylag egyszerűbb rendszer megvalósítása minimálisan háromszor annyi ideig tart mint amennyi feltétlenül szükséges lenne.) A számítógépes információrendszer kialakítása, fejlesztése mögött meghúzódhatnak virtuális okok is. Azért mondjuk, hogy virtuális, vagyis látszólagos okok, mert az igazi indítékok valójában egészen másfajta beavatkozást indokolnának, nem az információrendszer fejlesztését. A teljes körű felsorolás, elemzés igénye nélkül hadd hívjuk fel a figyelmet a leggyakoribbakra. Versenyhelyzet ösztönöz fejlesztésre Nagy csábítást jelent a fejlesztésre, ha a versenytárs már belevágott. Persze ez önmagában még nem baj. Baj csak akkor van, ha a versenytárs tudja mit akar, biztosítja a feltételeket hozzá, a mi szervezetünk pedig csak azt látja, hogy a konkurencia mit csinál (vagyis azt nem, hogy miért). Szervezés a vezetési hibák kijavítása helyett Az előbbi esetnél is sokkal rosszabb az, amikor az információrendszer fejlesztésére azért kerül sor, mert egy szervezet működésében komoly - legtöbbször vezetési eredetű - nehézségek


20

keletkeznek. A valódi cél persze a problémák igazi okairól való figyelem elterelése. Vezetőket az a hamis hit éltet, hogy amíg az információrendszer szervezése folyik, időt nyernek az igazi bajok orvoslásához. Ha a rendszerszervező ilyen esettel találja szemben magát, csak egy tanács adható: meneküljön ahogy tud. Ennek a hibás vezetői magatartásnak a "b" változata szerint ugyanis "az egész balhét" a szervező nyakába igyekeznek varrni. Mint láttuk, az információrendszer fejlesztésére a legkülönfélébb valódi és nemegyszer hamis indítékok alapján kerülhet sor. A rendszerszervező számára rendkívül fontos, hogy tudatában legyen, mi miért történik. Fontos ismerni az indítóokokat, mert az eltérő megközelítést, más és más technikák alkalmazását, stb. kívánja meg. Van azonban még valami, ami miatt ennek a kérdésnek nagy a jelentősége. A rendszervező és a felhasználó közötti kapcsolatról van szó. Felhasználók közreműködése A számítógépes információrendszer fejlesztésére, a rendszerszervező foglalkozására jellemző a nagyfokú kooperáció. A szakma sajátosságaiból fakad, hogy az információrendszer "haszonélvezője" nem a rendszerszervező, a rendszerszervező viszont igazából nem ért, nem érthet, s nem is kell érteni azokhoz a tartalmi kérdésekhez, melyek megoldását az információrendszer támogatja. A rendszerszervező feladata, hogy a szervezet működése szempontjából kimunkált fontos, tartalmi összefüggéseket az információrendszerben értelmesen, a valós rendszerhez jól kapcsolódva érvényesítse. Ezért nagyon fontos a tényleges vagy leendő felhasználókkal való jó kapcsolata, az együttműködés megteremtése. Ez a megállapítás közhely lenne, ha a gyakorlatban ez az együttműködés olyan simán menne. De nem megy. Miért? Általános tapasztalat az ismeretlentől való félelem, idegenkedés. Megváltozhatnak a korábbi megszokott munkakapcsolatok, szervezeti kapcsolatok, informális hatalmi viszonyok. Az emberek pedig rendszerint nagyon nehezen tűrik a bizonytalanságot. Gondot okozhat az is, ha az egyéni és csoportérdekek összeütköznek egymással. Ennek a jelenségnek gondos elemzése alapján a konfliktusok feloldása is előre tervezhető. Hangsúlyozni szeretnénk, az érdekkonfliktus önmagában nem baj. Baj az, ha feloldása elhúzódik vagy rosszabb esetben elmarad. Károsan befolyásolhatja az információrendszer fejlesztését, ha a vezetés aktívan nem vállalja fel a változásokkal együttjáró problémákat. Az aktív támogatás hiánya kétfelől is jelentkezik: egyrészt közvetlenül, kisebb problémák megoldása is már nagy erőket kíván, másrészt a szervezet valamennyi dolgozója csak azt látja, a vezetésnek nem fontos, neki miért legyen fontos? A rendszerszervező és a felhasználó közötti kapcsolatot a nulladik órában is megmérgezheti a felhasználó korábbi rossz tapasztalatai. Ezek a rossz tapasztalatok származhatnak egy korábbi szervezésből, de jöhetnek a felhasználó korábbi munkahelyeiről. Sokszor tűnik úgy, hogy fantomokkal kell viaskodni, olyan ki nem mondott kifogásokat kell megcáfolni, amelyeket valójában másoknak címeznek (vagy kellett volna címezniük). A felhasználói közreműködést motiváló tényezők felsorolásával nem azt akartuk bizonyítani, milyen nehéz sora van a rendszerszervezőnek. Inkább az a szándékunk, hogy ezekre a problémákra ráirányítsuk a figyelmet. Ha számolunk ezekkel, bízvást remélhetjük, a megfelelő ellenszert időben és közösen meg is találjuk. A rendszerszervező és a felhasználó közötti kapcsolatot meghatározza az is, hogy mennyire világosak az információrendszer fejlesztéséhez kapcsolódó célkitűzések, hogyan lehet (majd) értékelni az elkészült rendszert (lehet-e egyáltalán?).


21

Költség-haszon elemzés Egy számítógépes rendszertervezési eljárásnál fontos, hogy ne veszteséges beruházást készítsünk. Általában a költségek két részletre bonthatóak: egyszeri kiadások, és a folyamatos üzemeltetéssel együtt járó kiadások. A haszon felmérése általában jóval bonyolultabb. Lehet mérhető és nem mérhető haszon. A mérhető haszon a következőképpen állapítható meg:  tényleges költségcsökkenés (jobb készletgazdálkodás, alacsonyabb raktárszint stb.)  bizonyos költségek megtakarítása (jobb ütemezéssel a gyártó kapacitás jobb kihasználása) A legnehezebb a nem mérhető haszon értékelése. Ez lehet fegyelmezettebb munka, nyugodtabb munkavégzés, kisebb fluktuáció, megbízhatóbb adatok szolgáltatása, kevesebb panasz, több idő a fejlesztésre stb.


22

3 Az információrendszer fejlesztés életciklusa Az eddigieket kiegészítve és összefoglalva elmondható, hogy a rendszereket általában négy dolog befolyásolja:  tartalom: a technikai elemek között ott az ember, aki a rendszert működteti  struktúra: az elemek egymás közötti és a környezethez viszonyított szerepe  kommunikáció: elemek közötti információ áramlás (megfelelő információ megfelelő helyen és időben legyen)  döntéshozatali folyamat: egyes elemek állandóan rendelkeznek választási lehetőséggel és ez visszahat a kommunikációra.


23

3.1 A rendszertervezés klasszikus folyamatábrája pályázati kiírás, javaslattétel, stb

rendszerjavaslatok kidolgozása

döntés

nagyvonalú helyzetfelmérés (és elemzés) információs modell, hardver, szoftver becsült ktg. alternatívák kialakítása, időbeniség tervezése

rendszerkoncepció

döntés

részletes helyzetfelmérés (és elemzés)

rendszerterv

a kapcsolatok inf. tartalma is megismerésre kerül

pontosított értékek alrendszerek tervezése, kapcsolatuk egymással prioritásuk

döntés

feltételrendszer kialakítása

1. alrendszer logikai, fizikai terve

gépek, eszközök, stb döntés


1. alrendszer üzembe helyezése

n. alrendszer üzembe helyezése

rendszerkarbantartás

24

átállás megtervezése, adatfeltöltés bizt. kezelők oktatása dokumentációk elkészítése

rendszerátadás-átvétel

inf-s rendszer folyamatos karbantartása módosítások, változatok rendszerbe illesztése

A rendszertervezés lépéseit mutatja be a következő ábra is, amely a rendszertervezésre fordított munka volumenének változását ábrázolja a rendszertervezésre fordított idő függvényében:


25 az információs rendszer felfutásának ideje alrendszerek alrendszerek üzembe helyezése felszerelése

egész rendszer tervezése Elemzés

1.alrendszer tervezése

1.alrendszer

elemzés

terv készítés

2. alrendszer

koncepció készítés

elemzés

Elemzés 2. alrendszer tervezése

1. alrendszer 2. alrendszer

teljes rendszer üzembe helyezése, üzemeltetése Gépi rendszer tervezése rendszer terv

munkaráfordítás volumenének változása

Gépi rendszer felszerelése

idő

3.2 A rendszertervezést befolyásoló tényezők 1. Rendszer nagysága, bonyolultsága (pl. egy kis vállalt könyvelése  vasúti rendszer) 2. A rendszerszervezési feladat jellege 3. Szakemberek mennyisége, típusa (hardverorientált, szoftverorientált szakemberek) 4. Tervezési módszerek 5. Jelenlegi információs rendszer 6. Rendelkezésre álló idő 7. Rendelkezésre álló pénz.

3.3 A helyzetfelmérés módszertana A helyzetfelmérés oka:  bonyolult szerteágazó információs rendszerek  a rendszer állandó változásokon megy keresztül  a működő rendszer felmérése egyszerűbb mint kinyomozni, hogy hogyan alakult ki így a rendszer


26

 általában a meglévő dokumentumok nem tartalmazzák pontosan a jelenlegi helyzetet. A helyzetfelmérést mindig csak a cél függvényében érdemes elvégezni, csak olyan szintig ameddig az elemzés megkívánja. Bár ez egy érdekes feladatrész, és látványos eredményt lehet vele produkálni, de takarékoskodni kell az idővel a hf. során.

3.3.1 Dokumentumgyűjtés A vállalatoknál lennie kell szervezeti és működési leírásnak (vállalat célja, küldetése, szervezeti diagramm) munkaköri leírások bizonylati albumok bizonylatok. Bár a helyzetrögzítéssel a későbbiekben foglalkozunk, érdemes itt megjegyezni, hogy a begyűjtött lapokról érdemes nyilvántartást vezetni (mire használják, ki tölti ki, ki kapja, milyen gyakran stb.)

3.3.2 Interjú Felső és középvezetői szinten Időigényes, nehezen feldolgozható, de a rendszertervezés kezdetén nélkülözhetetlen, csak így tudjuk meg a rendszertervezés motivációit a felmerülő elsődleges és másodlagos információkat. Előnye: az interjúalany ismeri a vállalatot, a munkatársakat, és tartalmas válaszokat tud adni (ehhez persze az kell, hogy megfelelően válasszuk ki az interjúalanyt) Hátránya: a megkérdezett érzelmei, személyes kapcsolatai befolyásolhatják a válaszokat. Interjú előkészítése: felkészülés az alanyból felkészülés a témából a teljes szakmai terület ismerete (átfogó kép) időpont és helyszín tisztázása (lehetőleg nyugodt, beszélgetésre alkalmas hely) bemutatkozó látogatás vázlat készítése Menete: rövid bevezető beszélgetés probléma tisztázása ragaszkodni kell a témához a válaszokat kritika nélkül kell fogadni


27

nem szabad kapkodni kerülni kell az eldöntendő kérdéseket az alanynak is lehetőset kell adni a kérdésekre időnként, és a végén mindenképpen össze kell foglalni a hallottakat mindent jól értettünk-e van-e valami hozzátenni való az eddig elhangzottakhoz Általános észrevételek:  az interjú időtartama kb. 1 óra. Ennyi elegendő a bonyolultabb összefüggések felderítésére is, és ennyi idő alatt nem fáradnak még el a résztvevők.  Hallottak rögzítése:

interjú után (röviddel utána, mert különben elfelejthetünk néhány fontos részletet); interjú közben: csak vázlatosan! nem javasolt a magnós, videós adatrögzítés

3.3.3 Kérdőív Középvezetői és végrehajtói szinten Nagy mennyiségű választ kapunk rövid idő alatt, könnyen feldolgozható Előnye: Könnyű feldolgozhatóság, nagy mennyiségű alkalmazhatóság. Hátránya: Csak a feltett kérdésekre érkeznek válaszok, új ötletek, gondolatok nem jelennek meg. Típusai:  Nyílt: Kérdés felelet. Nehezen feldolgozható, de személyre szabott válaszok születnek.  Zárt: Kérdés, majd választás a megadott feleletek közül. Könnyen feldolgozható, de uniformizált válaszok születnek.  Vegyes: a kettő kombinált alkalmazása. A kérdőív szerkesztés folyamata: 1. Milyen információkra van szükségünk? 2. A kérdőívek milyen típusát, illetve az adatgyűjtés mely módszerét használjuk? 3. Írjuk le az egyes kérdések szövegének konkrét megfogalmazását! 4. Döntsük el, hogy milyen típusú skálákat, táblázatokat, vagy egyéb különleges eszközöket használunk a kérdőívek szerkesztése során!


28

5. Határozzuk meg a kérdések legmegfelelőbb sorrendjét. Legyen a kérdőívünk gördülékeny, és irányuljon valamire. 6. Határozzuk meg a kérdőív szerkezetét, elrendezését, és küllemét. 7. Végezzünk

próbakérdezést,

majd

ezek

alapján

hajtsuk

végre

a

szükséges

változtatásokat! 8. Készítsünk kitöltési útmutatót. A kérdőív szerkesztés néhány alapszabálya: o

Egyféle jelentésű szavak használata.

o

Kerüljük a szakzsargont!

o

Homonímiák kiküszöbölése. (azonos hangzású szavak), pl.: „Hullám hátára hull ám a hullám”

o

Tulajdonságot jelző melléknevek megfelelő használata (gyakorlatilag mindenki, majdnem mindenki; döntő többség, legtöbben)

o

Zárt kérdőíveknél legyen összhang a kérdések és az előre megadott válaszok között. (pl.: az Ön mennyi keres? kérdésre nem jó válasz, hogy ’jól élek’, ’elfogadható szinten élek’; hanem a ’50-60e Ft’, ’60-70e Ft’.

o

A nagyságot és arányt leíró szavak legyenek koherensek.

o

Ha kategóriákat használunk, akkor ezek legyenek azonosak (5-10, 10-20, 20-25: ez nem elfogadható)

o

A jövedelmet érintő kérdésekre adott válaszok országonként eltérhetnek. (Mo-n általában nem válaszolnak az ilyen kérdésekre)

o

Legyen „nem tudom” válasz a kérdéseknél!

o

Az esetek egy részében elégedjünk meg a kb. válaszokkal.

o

Ne legyen torzító kérdésfeltevés!

o

Ne legyen kétszeres tagadás vagy egyéb szótrükk.

o

Osztályzási kategóriák (5-ös, 10-es skála)

o

Sorba rendezésnél ne legyen túl sok tétel.

Adatgyűjtés módszerei:  Önkitöltő kérdőív  Csoportos önkitöltő kérdőív  Személyes kitöltésű kérdőív  (megszólításos interjú  telefonos interjú  telefon – posta – telefon )


29

Mintavételi módszerek:  önkényes - legolcsóbb  panelek: kiválasztott csoport folyamatos vizsgálata  kvóta szerinti minták (különböző csoportok szerinti minták)  valószínűségi mintavétel – legjobb (Marketingkutatások: Feltáró kutatás – nem tudjuk mit is keresünk Leíró kutatás – csak azt akarjuk megtudni mi történik, de azt nem, hogy miért Magyarázó kutatás – a miértekre ad választ Előrejelző kutatás

)

Szekunder kutatások: Már meglévő kutatások eredményeit használjuk fel újra. 

Belső szekunder kutatások (vállalaton belül)



Külső

szekunder

kutatások:

más

cégektől

vásároljuk

meg

az

adatokat.

Léteznek készen beszerezhető kutatások. (Olcsóbb mint egy általunk megszervezett – Rendszeres időközönként végzik – Hivatásos, hozzáértő személyek végzik – Nem kell részt vennünk benne) Előny: Időt takarítunk meg Munkát takarítunk meg Pénzt takarítunk meg Jobb lehet mint amit mi valaha is készíteni tudnánk De legalább alapul vehetjük a saját felmérésünkhöz. Hátrány: Más gyűjtötte az adatokat más célból Nem aktuálisak az adatok Nem a mi célcsoportunkat kérdezték. Nem olyan pontos, mint amit mi készítünk

3.3.4 Mérés, megfigyelés Általában megfigyeléssel is fontos tapasztalatokhoz jutunk. Viszont figyelembe kell venni, hogy a megfigyelt másként dolgozik.


30

A mérések általában az alapfolyamathoz kötődnek, csak akkor szükséges ezt megtenni, ha az információs folyamat felméréséhez szükség van rá.

3.3.5 A módszerek egymásra épülése, kapcsolata 1. Vezetői szinten interjú (feladat lehatárolása) 2. Bemutatkozó célú értekezlet, megbeszélés (az interjúk, kikérdezések ütemezése, időbeli tervezés, szervezők bemutatása) 3. Dokumentumgyűjtés 4. Szervezeti szabályzatok tanulmányozása 5. Helyzetfelvétel megtervezése (háló diagramm, Gannt diagram) 6. Szakmai interjúk 7. Lehatárolt területeken kérdőív 8. Néhány területen részletes interjú-megfigyelés 9. Alapfolyamat mérése 10. Mindezek rögzítése és elemzése

3.4 Helyzetrögzítés módszertana A helyzetrögzítés ábrázolástechnikai lehetőségeit a következő fejezetben tekintjük át. A helyzetrögzítés ajánlott módszertana:

3.4.1 Statikus struktúra rögzítése: horizontális struktúra leírása térbeli ábrák, helyszínrajzok


Gép divízió szerelde

Félkészáru, készáruraktár

Hőkezelő

Öntvényraktár

Szerszámraktár

vertikális struktúra hierarchikus egymásra épülés (szervezeti ábrák) Közgyűlés

Könyvvizsgáló

Felügyelő bizottság

Igazgatóság Műszaki Igazgató

Gazdasági Igazgató

Titkárság

Gép Divízió

Vasöntöde Kft.

Kereskedelmi osztály

Számviteliés pénzügyi osztály

Fék Divízió

Minőségbiztosítási vezető

Személyügyi és informatikai osztály

Anyagellátási osztály

Alkatrészgyártó Divízió

Minőségellenőrzési osztály

Rendészet

Üzemfenntartási Osztály

funkcionális struktúra szervezet funkciói (funkcionális kördiagram)

Keráru raktár Festő

Forgácsoló üzem

Csomagoló

Fék divízió szerelde

Fék MEO

31


32

ejle szt és ám Pó gé ta p lk gy at ár ré tás sz gy ár tá s

Mű sza ki f

er sz

Sz

di ví zi ó

yártó

Rend észe t

Nyilvántartások

El sz ám olá s

s zté les fej i k

trész Alka ás gyárt

div.

Munka és tűzvédelem Por

tasz olgá lat

Re nd sz er ka r

lás llá ta ins w. .s rtás Hw nta rba , ka ítás ítése Jav telep ések ndez Bere ások Ipari szolgáltat

Sz ám Bé lá zá rsz s ám fej tés ,T Mé rleg B. kés zíté s Statis ztika

II. Fő tevékenység

rtás

Fékja vítás

Fék d iv

ép

ás álkod Gazd

a ik at rm fo In rtás fennta

IV. Gazdálkodás

g trész Alka

Üzem

d. z gaz eszkö Tárgyi ás lkod á d az zletg Kés y üg nz Pé el vit ám Sz

G

Irányít ás Raktározás

a sz Mű

ízió

és őrz en

St rat ég ia

Vasúti fék gyá

Ell

rrás n erőfo Humá

I. Igazgatás

bq an tar

tás

III. Kiegészítő tevékenység

3.4.2 Dinamikus struktúra rögzítése Alapfolyamat megismerése:  helyszíni berendezések elrendezési vázlata  alapfolyamat lebonyolódásának rögzítése  műveletek időbeliségének megismerése (időtartam, gyakoriság) irányítási folyamat meghatározása  irányítási feladatok meghatározása (tevékenységi jegyzék)  irányítási folyamatban résztvevők kapcsolatai (kapcsolati mátrix)  irányítási kapcsolatainak rögzítése (ált, és részletes kapcsolati diagrammok)  irányítási feladatok időbeli folyamata (bizonylatáramlási, információs folyamatábrák)

3.4.3 Informatikai fejlettség rögzítése milyen hardver eszközök állnak rendelkezésre szoftverek bizonylatszerkezetek alkalmazott kódrendszerek


33

3.4.4 Statisztikai és gazdasági jellegű adatok rögzítése

3.5 Helyzetelemzés Nem választható el a helyzetfelvételtől. Egyrészt már a helyzetfelvétel és a rögzítés sem végezhető el bizonyos elemző munka nélkül. Gondoljunk az interjúk, kérdőívek megtervezésére, ill. a helyzet rögzítésére alkalmas ábrák, táblázatok, vázlatok elkészítésekor végzendő elemző munkára. Másrészt a helyzetfelvétel, amint már láttuk, nem egyetlenegy munkafázis, lehet nagyvonalú és részletes helyzetfelvétel is. Tárgyköre: A helyzetelemzés tárgyköre az új fejlesztet rendszer megtervezési feladatainak megoldásához igazodik. Célja a fennálló, vagy fejlesztésre váró rendszer jellemzőinek olyan választékban és mélységben történő feltárása, megismerése, összevetése és összefoglalása, amely elegendő a fejlesztési munka objektív alapokon való elvégzéséhez. alapfolyamatokra alapfolyamatok információs rendszere o információellátási szükségletek o bizonylati rendszer o információkezelés logikája Mind az alapfolyamat, mind pedig az irányítási folyamat tekintetében először külön-külön kell elvégezni a helyzetelemzést. A komplex rendszerfejlesztés azonban azt is megkívánja, hogy az alapfolyamatot és irányítási folyamatát összekapcsoltan is elemezzük. helyzetfelmérés részletezettsége A rendszertervezési eljárás több fokozatú és egyre részletesebb feladatok megoldása felé halad. A kockázat-költség ábrán látható volt, hogy a nagy kockázatú területeken nem szabad a részletekben elveszni, hanem a megoldások körvonalait kell meghatározni, éppen a kockázat csökkentése érdekében. Ez nemcsak a tervezés, de az elemzési fázisban is azt vonja magával, hogy több fokozatban kell a feladatot elvégezni, a pontos megoldást megtalálni. Ezért a következő részletezettséggel kell az elemzést elvégezni: o előzetes (koncepció előtt) o részletes (készítés előtt) o részletes (alrendszertervre vonatkozóan) Az előzetes helyzetelemzés az alapfolyamatok irányításához szükséges adatok körét vizsgálja. Ennek érdekében mind a szervezeti összetevőket, mind a folymatokat, mindpedig az


34

információigényeket a teljes meglévő rendszerre elemzi a hiányosságok, megbízhatóság, pontosság, időbeliség stb. szempontjából. Egyik lényeges eredménye a felhasznált adatcsoportok jegyzéke. Az elemzés fő irányai: Az alapfolyamatok körében: Rendszer körvonalainak meghatározása Az

egyes

munkahelyeket

végzett

műveletek

kiterjedésbe,

mennyiségben,

sorrendiségben és időbeliségben megfelelők-e Vannak-e felesleges munkafolyamati elemek Általában az üzemszervezés során alkalmazott eljárásokat kell alkalmazni Az irányítási informatikai rendszer körében: Az irányítási rendszer körvonalazása A felesleges információkezelési párhuzamosságok kiküszöbölése A szükséges, jelenleg még nem használt információk meghatározása Hibás, pontatlan nem illeszkedő információk körének meghatározása stb. A részletes helyzetelemzésnek a rendszerterv elkészítése előtt minden olyan összefüggést fel kell tárni, amely megfelelő rendszertervet eredményezhet. Amíg az első elemzési fázisban az egész rendszerre vonatkozó átfogó összefüggések és jellemzők megismerése volt a fő cél, addig itt már az egész rendszer belső összefüggései állnak a vizsgálatok középpontjában. A rendszerterv még a teljes rendszerre vonatkozik, azonban alapvető jellemzője, hogy alrendszereket határol el egymástól. Ezeknek relatív kapcsolatát

rögzíti, beleértve a

szükséges gépi rendszer megtervezését is. Ezért ebben a helyzetelemzési szakaszban, a teljes rendszer lehatároltságát figyelembe véve, az összefüggő egész rendszer logikailag egybetartozó részeire, alrendszereire irányítjuk az elemző munkát, majd minden egyes résznek, alrendszernek a tanulmányozása, elemzése után áttérünk a kölcsönkapcsolataik elemzésére. A gépi rendszer kialakításához is elegendő információhoz jutottunk ebben az elemzési fázisban. Az egyes alrendszerek részletes megtervezése elé ékelődő helyzetelemzési munka a lehető legrészletesebb. Ekkor az egyes alrendszerek megtervezésének a sorrendjében feltárjuk azokat a belső logikai felépítési és működési törvényszerűségeket, a részletes adatforrásokat illetve adatigényeket. Az előbbi a leendő számítógépes információfeldolgozás algoritmusainak kialakításához az utóbbi pedig az előállítandó outputok és inputok megtervezéséhez szolgáltatnak objektív kiindulási alapot.


35

Helyzetelemzési módszerek helyzetfelvétel és rögzítés során helyzetrögzítést követően Az adatfelvétel és rögzítés is gondos előkészítést és a szerzett ismeretek áttekintését rendszerezését jelenti. Ezek nem nélkülözhetik az elemzéseket. A vizsgálódások másik csoportja a helyzetrögzítést követően végezhető el. Ekkor ugyanis már rendezett formában rendelkezésünkre állnak adatok. A helyzetelemzés eredménye : minden esetben a feltárt hiányosságok megállapítása. Minél részletesebb a helyzetelemzés, annál részletesebb helyzetelemzésre nyílik lehetőség. A helyzetelemzés eredménye minden esetben a hiányosságok megszüntetésére tehető javaslatok összefoglalása, a korszerű technika, technológia és

információtechnika

alkalmazásának az irányába haladva. Dokumentálás, jóváhagyatás A különféle rendszerelemzési fokozatokban az előzőekből kivehetően igen sok jegyzet, ábra, táblázat, vázlat, kimutatás és összesítés készülhet el. Ezeket csak akkor tudjuk jól használni ha rendezett formában tároljuk őket. A rendszerezés első tagoltsága a megismert három elemzési fokozat szerint való elkülönítés lehet. Ezeken belül további tagolás

valósítható meg azáltal,

hogy a szervezetre,

az

alapfolyamatokra, illetve az irányítással összefüggésben az informatikai területekre vonatkozó dokumentumokat elkülönítjük. Célszerű a dátumok hozzárendelése is a dokumentumokhoz. Ugyanakkor fontos, hogy a több azonos tartalmú dokumentum közül mindig a legfrissebbet kell tekinteni. A dokumentálás általános elve, hogy a részletesebb tartalmú anyagokat szét kell választani az átfogó, összegző tartalmú iratoktól. Ugyanis a fejlesztési munkálatok során nem mindenkinek kell a részletes dokumentumokat áttekinteni. Utólag pedig igen nehéz megkeresni vagy szétválasztani a részletes dokumentumkötegbe elhelyezett átfogó tartalmú lapokat. A vizsgált szervezet vezetői ellenőrzési és jóváhagyási tevékenységeik során csak az áttekintő iratokra hagyatkoznak általában. Ténykedésük megkönnyítésére összefoglaló feljegyzéseket érdemes készíteni. Az ellenőrzési és jóváhagyási tevékenységet is dokumentálni kell. Az ehhez szükséges szerződéseket, megállapításokat, záradékokat külön célszerű dokumentálni.


36

3.6 A rendszerkoncepció A rendszerkoncepció = nagyvonalú rendszerterv Ehhez elegendő lehet nagyvonalú helyzetfelvétel is.

3.6.1 Az irányító rendszer hatáskörének tisztázása lehatárolás rögzítése környezet felvázolása (ez következik a lehatárolásból)

3.6.2 A komplex információrendszer koncepciójának kidolgozása Output információ rendszer kidolgozása Az igénylők körének meghatározása (szervezeti ábrából, folyamat ábrából, térbeli elrendezési ábrákból). Ezeket állandónak vesszük. Az igénylők szervezetbeli elhelyezkedésének vizsgálata (mind horizontálisan, mind vertikálisan). Erre a gépi igény előrevetítése miatt van szükség Az információ rendszer szükséges időközei (éves, féléves…, napi, órás, perces… „alarm”) szükséges megjelenítési formák. Adatok mennyiségi becslése. Tárolt információrendszer körvonalazása tárolt információk dinamikusan bevitt adatok tárolt algoritmusok adatszerkezetek adatbiztonság – decentralizálás Input információ rendszer körvonalazása input információk beszerezhetősége input információk bekerülése (feltöltés módja) Kódok: kódolandó fogalmak használt jelek kódolás szabályai kódok alkalmazási köre Feldolgozási folyamatok, algoritmusok körvonalazása elegendő a feldolgozás logikáját leírni, nem kell részletezni (fekete doboz) Információ rendszer egészének a körvonalazása.


37

3.6.3 Géprendszer koncepciójának a kidolgozása  Output szempontok szerint (információ választék, megjelenítés helyei, becsült mennyiségek)  Tárolási szempontok szerint  Feldolgozás terén  Input szempontból  perifériák, hálózatok kérdése  térbeli elhelyezkedés tervezése  gépi teljesítmény igények becslése  kapcsolódó létesítmények tervezése (épület, berendezés, klímatizálás, speciális eszközök)

3.6.4 Programszükséglet körvonalazása operációs rendszerek hálózati programok felhasználói programok egyedi programok

3.6.5 Szakemberszükséglet körvonalazása (tervezés alatt, üzembe helyezéskor, átállás után)

3.6.6 Költségszámítás Egyszer felmerülő építés gépek programok személyi állomány felszerelési tárgyak átállás



gazdaságosság

Folyamatos: Amortizáció Gépi összetevők cseréje Munkabér A számítógépes információrendszer valójában erőforrást teremtő beruházás. Egyfelől beruházás a szónak az eredeti értelmében, mely szerint gépet, gépeket (konfigurációt) kell


38

vásárolni. De beruházás a szónak szélesebb értelmében is, mert egy egyszeri ráfordítás rövidebb-hosszabb megtérülésére számítunk. Mint minden beruházás esetében, itt is költségeket (ráfordításokat) valamint hozamokat (hasznot) kell számszerűsíteni, szembeállítani, és a megfelelő következtetéseket kell levonni. Nézzük meg ezt a problémát részletesebben! Az információrendszerrel összefüggésben felmerülő költségeket két csoportba sorolhatók: egyszeri fejlesztési kiadások és a folyamatos üzemeltetéssel együttjáró ismétlődő kiadások. A költségek megoszlanak munkabérre, szolgáltatások költségeire és egyéb költségekre az alábbi táblázat szerint:

Munkabér

Szolgáltatás Egyéb

Fejlesztés

Üzemeltetés

Programozás Programtervezés Rendszertervezés Projektvezetés Gépidőbérlet Adatgyűjtés Hardver-, szoftvervásárlás Munkahelyek kialakítása Oktatási anyagok

Adatelőkészítés Adatbevitel Operátorok Gépidőköltség Adattárolás Adathordozók Kellékek

A költségek számbavétele esetén a hozamokat is fel kell mérni. Hozzátehetjük ehhez, hogy a költségeket csak olyan pontosan érdemes számszerűsíteni, amilyen pontossággal a hozamok számszerűsíthetők. Hozamokról legalább kétféle értelemben beszélhetünk: mérhető haszon és nem mérhető haszon. A mérhető haszon kétféle értelemben állapítható meg: bizonyos költségek megtakarítása és tényleges költségcsökkenés. Ha a haszon számszerűen nem mérhető, még nem jelenti azt, hogy nincs. Ezek becslése a fejlesztők és a felhasználók meggyőződésére, szakmai tapasztalatára, analógiákra támaszkodik. Nem mérhető haszon lehet például a fegyelmezettebb munka, a nyugodtabb munkakörülmények, a munkahely presztízsének növekedése, jobb minőségű, szélesebb körű szolgáltatások nyújtása. Megemlíthető, hogy számos olyan döntés-előkészítési módszer, eljárás van, amely arra szolgál, hogy az eredetileg nem mérhető hozamot mérhetővé tegye. A költségek és hozamok gondos számbavétele és összevetése az alapja a költség-haszon elemzésnek. A gazdaságos üzem valamilyen költségfüggvény értékének minimalizálását jelenti. A probléma általában az, hogy a költségfüggvény nem univerzális, hanem függ a számítógépes rendszer felhasználási körülményeitől. A számítógépet működtető rendszerek esetében két – egymásnak ellentmondó – költségfüggvényt használnak. Az egyik az erőforrások minél teljesebb kihasználtságára törekszik, a másik a rendszer válaszkészségét igyekszik optimalizálni. Az általános stratégia mellett meg lehet fogalmazni konkrétabb célokat is: az átlagos átfutási idő minimalizálása; a lassú válaszok számának minimalizálása; a hardverkihasználtság maximalizálása; maximális kihasználtság adott válaszidő-korlát esetén;


39

A hetvenes évek közepétől kezdve, a hardver árának csökkenésével együtt a gazdaságosság megítélése is változott. Az a tendencia, hogy a maximális kihasználtság egyre inkább háttérbe szorul a válaszkészséggel szemben. A vizsgálatok eredménye alapján kell dönteni a fejlesztés megvalósításáról, a megvalósítás kritériumairól, és mindarról, amiről korábban szót ejtettünk. AZ INFORMÁCIÓ HASZNOSÍTÁSÁNAK TÁRSADALMI SZINTŰ GAZDASÁGOSSÁGA Az információ hasznosításának potenciális és tényleges előnyeit különféle szervezetek, szakemberek kutatják és igazolják. A példák szemléletesen bizonyítják azt az értéket, amely az információk alkalmazása révén mint "haszon", illetve "nyereség" jelenik meg a társadalom és a gazdaság különböző szintjein. A használatból származó eredményekre vonatkozóan fontos megemlíteni azt a tényt, hogy felhasználás után az információ tartalma nem semmisül meg, nem veszti el az értékét; így használatuk más környezetben új értéket hozhat. A GAZDASÁGOSSÁG ÁLTALÁNOS KÖVETELMÉNYEI ÉS JELLEMZŐ SAJÁTOSSÁGAI AZ INFORMÁCIÓSFELHASZNÁLÁS TEKINTETÉBEN A számítógépes információrendszerek beruházásoknak, létesítményeknek tekinthetők, és a gazdaságosság( követelményeit ennek megfelelően kell érvényesíteni. (Ez a megállapítás nemcsak vállalati és egyéb olyan információrendszerekre vonatkozik, amelyeknél a gazdasági cél nyilvánvaló, hanem elsődlegesen nem gazdasági jellegű rendszerekre is.) A gazdaságosság érvényesítése, figyelembe vétele jelenleg nem kielégítő. Nem megfelelő az összefüggések felismerése, a felelősségtudat, a módszer, a mérés, a költségek felosztása. Amit jelenleg ténylegesen számba vesznek, az információtechnikai eszközök (számítógépek), az adatfeldolgozó programok beszerzési, fenntartási és üzemeltetési költségei. A gazdaságosság fogalmába azonban ma már beleértendő a rendszerben felhasznált adatok, információk bekerülési költsége is. AZ INFORMÁCIÓ HASZNÁLATÁBÓL SZÁRMAZÓ BEVÉTEL (AZ INFORMÁCIÓ ÉRTÉKE) Az információ igénybevételének követelményét és előnyét az az érték bizonyítja, amely a használat eredményeként és hatásaként jelentkezik. Több más érv mellett ez a fő indoka annak, hogy megítélés tekintetében különböző felfogásokkal találkozhatunk. A vonatkozó vizsgálatok és kutatások más és más módszert alkalmaznak, eltérő szempontok alapján tanulmányozzák a területet, és vegyes következtetésekre jutnak. Az érték minőségének és nagyságának bármiféle megállapítását nagyban befolyásolja az is, hogy az egyének, a szervezetek vagy az egész társadalom perspektívájából folytatnak-e vizsgálatokat. Ugyancsak különböző eredményekre vezethet az, ha az értékeléseket filozófiai, érzelmi vagy gyakorlati szempontból végzik. Az érték különböző értelmezései közül most az információk használati értékéről szeretnék rövid áttekintést adni. Ebben a gyakorlati értelemben a használatból származó hatások és előnyök néhány összefüggésben vizsgálhatók és tapasztalhatók: várható haszon vagy feltételezett használati érték (Az egyén szubjektív véleménye és döntése akkor, amikor arról határoz, hogy keresni vagy használni akarja az információkat.) közvetett vagy beruházó jellegű haszon (Ilyen, amikor egy személy vagy szervezet nem azért választ egy bizonyos forrást, hogy azonnal használja, hanem valamiképpen elraktározza azt, mivel a jövőben potenciális felhasználhatóságot lát benne.) szubjektív használati érték (Az egyén véleménye a felhasznált információk értékéről. Ide sorolható a bizonytalanság csökkenésének mértéke is.) objektív használati érték (Annak a közvetlen hatásának az értéke, amelyet az információ használata idéz elő bizonyos feladatokra és azok eredményeire.) Indirekt megközelítések


40

Igen sok vizsgálat az információ hasznosságát közvetve, általános megállapításokkal igazolja. Az információs termékekkel és szolgáltatásokkal többnyire nem elkülönítve foglalkoznak, hanem az információ tartalmi értékével keverten. Ezen az úton az információk hasznát közvetlenül "nem kimutatható"-ként jellemzik, de ugyanakkor "üzleti értékét" spekulatív úton magasabbra minősítik, mint több más hagyományos és mérhető tényező esetében. Az információk értékére vonatkozó indirekt következtetések lényeges (de sokszor figyelmen kívül hagyott) követelménye, hogy különbséget tegyenek a tényleges és várható haszon, az azonnal érvényesülő vagy a későbbi időkre elraktározott ismeretek hatása között. Ez az oka annak, hogy ezek a módszerek általában csak bizonyos részeredményekkel járhatnak. Elmaradt haszon A nemzetközi gyakorlatban ismert az úgynevezett "elmaradt haszon" fogalma, az a remélt haszon, amelytől az ügyletet kötő egyik fél az ügylet meghiúsulása miatt elesik. Ilyen például a hiány következtében előforduló többletkiadások és más váratlan kiadások számbavétele a termelés területén. Ennek a módszernek alapja az a kiindulási tétel, hogy a gyártási folyamatok (a szükséges és megfelelő információk hiányában) kikerülhetnek az ellenőrzés, irányítás és szabályozó beavatkozások alól. Ebből pedig többletkiadások és veszteségek származnak. Például kimutatták, hogy múlt hozzáférhető eredményeinek nem ismerete sok felesleges ismétléshez és kiadáshoz vezet. Így előfordulhat az, hogy a negatív hasznot megakadályozó információk több megtakarítást jelenthetnek, mint a szervezet összes saját működési költsége. Értéknövelés Az információ-használatnak, mint tevékenységnek az értéke a használatra vagy a használat fokozására tett közreműködés és hozzájárulás arányával mérhető. Napjainkra nyilvánvalóvá vált, hogy a termelésben felhasznált hagyományos erőforrások (a tőke és a nyersanyag) mellett az információ is jelentős tényezővé vált. Sőt az információ bizonyos határok között kiválthatja a tőkét (olcsóbban lehet termelni) illetve a nyersanyagot (takarékosabban lehet termelni). Az információ-felhasználás ezen aspektusból történő vizsgálata esetén pontosan számba vehető az a haszon, ami a tőke- és anyagmegtakarítás révén nyereségként könyvelhető el. Társadalmi haszon Az információ használatából származó előnyök társadalmi szinten való értelmezése és számbavétele tekintetében igen ellentétes véleményekkel lehet találkozni. A legtöbb társadalmi szolgáltatás értékének, illetve hasznának mérése pontos gazdasági terminusokkal általában lehetetlen. A társadalmi mértekben értelmezett hasznosság fogalmi körében a szociológia az élet minőségét, az egyénnek - a társadalom - elégedettségét, az életszínvonal befolyásolja. AZ INFORMÁCIÓK HASZNÁLATÁNAK KÖLTSÉGEI (AZ INFORMÁCIÓ ÁRA) Az információnak ára van, előállítása, terjesztése és használata költséggel jár. A kérdés csupán az, hogy ki és mennyit fizet érte. Az információ árujellegére vonatkozóan különböző felfogásokkal találkozhatunk világszerte. Az egyik vélemény szerint rendelkezik minden árutulajdonsággal: hasznosság; mások számára is hasznosság; eladási céllal kerül a piacra; stb. Más megállapítás szerint legfeljebb különleges áru: ez mutatkozik meg abban, hogy árát nem a termeléséhez felhasznált munka- és egyéb ráfordítások határozzák meg, hanem a felhasználásától elvárt és különböző módokon jelentkező gazdasági haszon. A különböző felfogások közti különbségek alapja, hogy sokan és sokszor nem tesznek különbséget az érték és az ár között. (Persze ez bizonyos esetekben ez nem is lehetséges, illetve nehezen keresztülvihető.) A fogyasztói félreértések visszavezethetők arra a gyakorlatra is, amelyek alapján az úgynevezett "könyvtárorientált", illetve könyvtári és kapcsolódó jellegű költségeket hagyományosan rezsi költségként kezelték az egyes vállalatoknál. Ugyanakkor a központi


41

szolgáltatásokat pedig ( hazánkban is ( hosszú időn keresztül az állam finanszírozta, s így azok jó része ingyen vagy áron alul volt igénybe vehető. Árujelleg Az információk, mint termelési tényezők nem sorolhatók teljesen az úgynevezett "kemény áruk", a "kézzelfogható javak", a tárgyi termelési tényezők kategóriájába. Az árujelleget meghatározhatjuk a következőkkel: az áruk cserére szánt termékek és szolgáltatások, az emberi szükségletek kielégítésére szolgáló hasznos javak, amelyeket nem közvetlenül saját szükségletre, hanem eladás céljából termelnek és adásvétel útján jutnak el a fogyasztókhoz. A javak nem válhatnak áruvá, ha azok másvalakik számára valamilyen szempontból nem hasznosak, nem alkalmasak szükségletek kielégítésére. Az információk vonatkozásában az előzőek egyéb jellemzőkkel is kiegészíthetők: Az információk legtöbbször beruházási javak, annak ellenére, hogy vannak fogyasztási vonásaik is. A döntéseknél és egyéb feladatoknál rendszerint más adatokkal és tapasztalatokkal együtt válik erőforrássá. Egyes közösségek túlságosan hagyományos magatartást tanúsítanak az újszerű információ átviteli mechanizmusokkal szemben. Kevés a bizalom a hozzáférhető és a közreadott újdonságok megbízhatóságában. Ennek következtében a felhasználók egy része nem vállalja a költségek meghatározott részének fedezését. A priori ismeretlen a keresett információk értéke és haszna. Jelentős gátakat jelent az információk megfelelő integrálása a létező tudásbázishoz. A hasznot és a költségeket nem teljesen a fogyasztó és a készítő kapja és viseli. Értéknövelés A cserére termelt áruk olyan jószágok, termékek vagy szolgáltatások, amelyek a piacon adásvétel formájában kerülnek forgalmazásra. Az információknak a kereslet-kínálat alapján kialakuló piaci ára a különböző szolgáltatásoknál jelentkezik. A feldolgozás, feltárás, terjesztés útján elért "hozzáadott érték" jó alap az árazáshoz, amit még több szubjektív tulajdonság is befolyásol. Ár meghatározása A pénzügyi döntési rendszerek, modellek fejlődésének keretében az információs termékekre és szolgáltatásokrakülönböző árazási módszerek alakultak ki: minimális ár - átlagköltségre alapozva; piac elviseli ár - a felhasználók vásárlási vásárlási hajlandóságának becslésére alapozva; fix százalék ár - vagy a költségek vagy az árak viszonyaira alapozva; jövedelem/felhasználók ár - a szükséges jövedelemre alapozva (a felhasználók számát figyelembebe véve tapasztalati ár - a múltbeli hasonló árakra alapozva (kiegészítve azt a változás tényezőivel); minimális érték/ár - a minimális érték és az ár jogos és méltányos arányára alapozva.

3.6.7 Időterv készítés pl. Gannt diagram


42 1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Alvállalkozóknak kiküldendő követelmények megbeszélése, ez alapján az IBSZ rész elkészítése Alvállalkozóknak a követelmény-rendszer és a minta kiküldése Értékelési szempontok kidolgozása Alvállalkozói ajánlatok visszaérkezése Ajánlatok értékelése Tárgyalás az alvállalkozókkal Pályázati anyag előkészítése Pályázati anyag összeállítása

3.6.8 Dokumentáció  bevezetés: célok rögzítése  feltétel rendszer körvonalazása  hardver, szoftver koncepció  költség – haszon elemzés  alternatívák kidolgozása  ütemezés

3.6.9 Munka folytatásával kapcsolatos döntés dokumentálása  előkészítés  vita  döntés, jegyzőkönyv Legkedvezőbb változat kiválasztására szolgáló multikritériumos módszerek súlyozó tényezők nélkül:  Pókháló diagramm


43

97 % 100 80 60

76%

40 20 0

83%

42 %

86 %  Juran-Harris módszer: Céltábla

 Harris-Marting módszer: Táblázat

61 % 69%

78%


É1

44

É2

É3

É4

…

Ém

+2 +1 -1 -2 súlyozó tényezőkkel:  KIPA módszer: preferencia és diszkvalifikancia mutatókon alapszik Kindler – Papp módszer Preferencia és diszkvalifikancia mutatók Preferencia: egyik változat a másik változathoz képest hány százalékban előnyösebb (max. 100%) Diszkvalifikancia: mekkora a legnagyobb megtűrt hátrány. Az egyes változatokat páronként hasonlíthatjuk össze

 Kesserling eljárás. Paraméterek: Pi= 1..4 Súlyozó tényezők: vi= 2..10 n

pi * vi X

i 1 n

pmax * vi

0,8<x<1 0,6<x<0,8 0,5<x<0,6 0<x<0,5

nagyon jó jó kielégítő nem kielégítő

i 1

 ELECTRE I: Ez egy egyetértési és egyet nem értési index-el dolgozik. Az egyet nem értési küszöb (vétó) minden kritériumnál jelen van. A rangsorolás és a vétó küszöbök adják a megoldást.  ELECTRE II: Ez rangsorolja az intézkedéseket, a legsikeresebbtől a legkevésbé sikeresig.  PROMETHEE: csak megegyezési indexszel dolgozik és bevezeti a progresszív rangsorolást  COMBINEX módszer

3.7 Rendszerterv kiterjedtebb helyzetfelmérésen alapszik nagyrészt azonos a rendszerkoncepcióval, de több részletre terjed ki. Általában az alrendszerekre való bontással kezdődik. Ez lehet: térbeli elhatárolás


45

vertikális szerkezet információ kapcsolati diagrammok vagy korreláció számítás, Cluster analízis előtünnek az alrendszerek közötti kölcsönkapcsolatok. Az információ rendszer rendszerterve a meglévő rendszerkoncepció pontosítása. (konszignációs mátrix) felesleges párhuzamok kiszűrése

3.8 Alrendszerek tervezése Logikai tervezés Fizikai tervezés Bevezetés Értékelés A rendszerkoncepció, az egész rendszer tervezése, és az egyes alrendszerek tervének elkészítése közti kapcsolatot mutatja be a következő a rendszertervezés külső és belső kapcsolatait feltáró ábra:

1. alrendszer rendszerterve



3.9 Kivitelezés, bevezetés 3.9.1 Manuális eljárások kidolgozása  bizonylatok készítése  felhasználók feladatainak leírása

Az egész rendszer rendszerterve

A rendszer alrendszerekre bontása

Rendszerkoncepció

Rendszerterv készítés 1. alrendszer részletes tervezése

2. alrendszer részletes tervezése

3. alrendszer részletes tervezése


46

 bizonylatok felvitelének módja  gépi működés szabályozása

3.9.2 Programozás, tesztelés ld. még. RM. 591 Egy elkészített program akkor válik jól használhatóvá, ha a gyakorlatban használatos értékekkel és hibás értékekkel is kipróbálták, tesztelték, is minden esetben a kívánatos eredményt produkálta. A programok működését nem csak egyenként, hanem egészében is meg kell vizsgálni a komplett rendszer szintjén. A tesztelés a programrendszer működési helyességének és hatékonyságának vizsgálati szempontjait, feladatait és a munkavégzés módját meghatározó tevékenységek összességének szisztematikus végrehajtása. Alulról felfelé: Lényege: a legkisebb programszegmenstől kezdve tesztelünk, a jókat összekapcsoljuk és így haladunk tovább. Iránya: Programrészek  programok  modulok  alrendszerek stb. Felülről lefelé: A felülről lefelé való tesztelés a hierarchikus struktúrák, a strukturált rendszertervezés elterjedésével párhuzamosan alakult ki. Lényege: a legkritikusabb modul tesztelését kezdjük meg először, és fokozatosan térünk ki a kevésbé fontos részekre. (Pl. először az alapfeladat hibátlan elvégzését ellenőrzik, s csak azután a menük tökéletességét, színeket [olvashatóság], stb.) Ez a tesztelési mód gyorsabb mint az előző Verifikáció és validitás: Verifikáció: a program helyes működését vizsgálja, vagyis a programutasítások megfelelően végrehajthatók-e Validitás: A fejlesztés alapvető céljainak, a felhasználói igényeknek való megfelelést vizsgálja. A tesztelési szintek a következők: Modul teszt Integrációs teszt Validitás vizsgálat Rendszerteszt A teszteléshez külön tesztelési terv készíthető. Ez meghatározza a tesztelés célját, leírja a tesztelési fázisokat azok ütemezését, a tesztelést támogató szoftvert a tesztelési környezetet. Tartalmazza a integráció szintjeit a tesztelési környezet leírását és a tesztadatokat. Végül pedig leírja a teszteredményeket. Jelentősebb méretű rendszereknél a tesztelési adatokat is előre meg kell határozni.

3.9.3 Felhasználók kiképzése Az új rendszer bevezetésének kockázatát nagymértékben csökkenti a felhasználók felkészítése, betanítása és a rendszer tesztelése. A felkészítésben egyik fő segítő eszköz a rendszerleírás, aminek valóságos értékét most ellenőrizhetjük. Az oktatás:  a rendszer átfogó ismertetését

Közlekedési rendszertervezés    

47

a szolgáltatások összefoglalását a használat ismertetését gyakorlást foglalhat magában Célszerű oktatási (tan)tervet készíteni

A betanítást nem biztos, hogy a fejlesztő csapat képes a legjobban elvégezni. Lehet:  csoportos képzés  szimulált működésű szoftver  konzultációk.

3.9.4 Rendszer üzembe helyezés  Feltételek megteremtésének befejezése (épületek, klíma, kábelezések)  Hardver telepítése (számítógép egységeinek elhelyezése, összeillesztése)



Szoftverek installálása (operációs rendszerek, hálózati szoftverek, fejlesztő eszközök, egyéb felhasználói szoftverek)

3.9.5 Átállás megtervezése o

Kísérleti futtatás (nem minden adattal)

o

Egy időpontban

o

Párhuzamos működés

o

Szakaszos átállás

3.9.6 Rendszer átadása Az elkészült rendszert a megbízónak át kell adni. Az átadáshoz mindennemű működéshez szükséges erőforrásnak rendelkezésre kell állnia. (hw, sw, adatok). Ezt a felhasználónak be kell mutatni, úgy, hogy meggyőződhessen a specifikációnak megfelelő működésről. Ehhez célszerű forgatókönyvet készíteni, az átadás tényét pedig jegyzőkönyvben rögzíteni.

3.9.7 Értékelés:  általános  dokumentáció  működési hatékonyság


48

 outputok értékelése  költségek értékelése  elért eredmények értékelése

3.9.8 Karbantartás, továbbfejlesztés

Az ábra a az utóbbi évek rendszer-karbantartási költségeinek %-os megoszlását mutatja. A karbantartási fázisban háromféle változás által kiváltott műveletet végezhetünk:  Javítás, korrekció A leggondosabb elemző-tervező munka és tesztelési eljárások ellenére is előfordulhat, hogy a rendszer működésében előre nem látható hibák lépnek fel, olyan feltétel-kombinációk következnek be, amelyeket senki sem látott előre, és amelyeket természetesen javítani kell.  Adaptálás A működés során a számítógépes rendszerben az idő múlásával olyan változások, fejlesztések következnek be (korszerűbb szoftverek alkalmazása, új, nagyobb perifériák vásárlása stb.), amelyek a rendszer módosítását, az új feltételekhez adaptálását igénylik.  Rendszerkorrekció A felhasználó igazán akkor látja az új rendszer által nyújtott szolgáltatások előnyét, amikor az már valóban működik, és ekkor „jön meg az étvágya” is újabb és újabb igények kielégítésére. De nemcsak az új elvárások, hanem a környezet változása, a feltételek módosulása is a rendszer karbantartását követeli meg.


49

4 Ábrázolási technikák a rendszertervezésben Ábrázolástechnikai lehetőségek: diagrammok táblázatok mátrixok szervezeti ábrák információkapcsolati diagrammok információs folyamatábrák funkcionális diagrammok elrendezési ábrák

4.1 Diagrammok: egymáshoz rendelt dolgok kapcsolatát ábrázolja koordinátarnedszeren alapuló diagram: pont, vonal, oszlop idődiagram: lehet statikus (egy-egy időpont adata), lehet dinamikus: idő függvényében folyamatos teljesítménydiagram: elvégzendő műveletek kapcsolatát is ábrázolja hálódiagram: kritikus út keresése, költségminimalizálás A diagrammok elmaradhatatlan részei: a címrész lépték jelmagyarázat

4.2 Táblázatok Értéktáblázat: kódok megadására használják: melyik jelölés mit jelent. Kód

Jelentés

01

Áru

02

Szolgáltatás

83

Kártyás fizetés

Hozzárendelő táblázat: pl. költségek bemutatására szolgál Bér

Anyag

Ért.csökk.

Összes

Termelési oszt.

100

500

20

620

Szállítási oszt.

100

50

50

200


50

Döntési táblázat, tevékenységek csoportosítására használható táblázat Tevékenységi jegyzék pl.: Részfolyamat Vállalatvezetés, Műszaki tervezés fejlesztés Elszámolás termelés könyvelése Ag. Raktár gazdálkodás gazdálkodás Üzemeltetés Üzembe helyezés Munkaerő Munkaerő gazdálkodás nyilvántartás

Tevékenység Beruházás KöltségSzervezés tervezés anyag Főkönyv Számlázás, Bér, és teljesítmény könyvelés készítés pénzügy elsz. Beszerzés Értékesítés Szerszám gazdálkodás Forgalom Operatív száll. Szervízelés Járműgazdálkodás tervezés irányítás Oktatás Bérgazdálkodás

Következő fokozat: Üzemeltetés Üzembe helyezés

Vizsgáztatás

Tevékenység Jmű átalakítás Nyilvántartás

Forgalom tervezés Fuvar szerződések

Jművezetők beosztása

Operatív száll. irányítás

Helyzetfigyelés Koordinálás

Napi tervkészítés

Szervizelési Futáskm terv készítés nyilvántartás Járműgazdálkodás Járművásárlás Lízingelés Szervízelés

Járművek koordinálása

Alkatrészek beszerzése Járműértékesítés

harmadik fokozat: Operatív száll. irányítás Napi tervkészítés Helyzetfigyelés Koordinálás Mentés, pótlás megszervezése stb.

4.3 Mátrixok Kapcsolati mátrix

Tevékenység

Eredet vizsgálat Belső szállítások ellátása Mentés, pótlás megszervezése

Közlekedési rendszertervezés A A

C

-

B C

B

x

D

51 D

x -

x

x

-

x

x

-

Bizonylat-adat mátrix 1. adat

2. adat

3. adat

4. adat

1. bizonylat

X

X

2. bizonylat

X

X

3. bizonylat

X

X

X

Input-output mátrix Az egyes bizonylatokon szereplő input adatokból melyik bizonylat output adata származik. Ebből látható, hogy egy outputhoz milyen input adatok szükségesek, illetve egy input adatokból milyen outputok készülnek.

(információs, vagy konszignációs mátrix ma már ritkábban használt háromszög alakú mátrix, melyiken három dimenziót síkban tudunk ábrázolni)


52

Keletkezési oldal

Felhasználási oldal Fájlok elnevezései

I/1 I1 I2

O/1 I/2

Módosítás

Mód. utáni felh.

O1 O2

O/2

In

On

Input bizonylatok

Output bizonylatok

I/O Közvetlen felhasználás

4.4 Szervezeti ábrák hierarchikus:


középpontos

koncentrikus szervezeti ábra:

a körcikkek szervezeti nagyságot is tartalmaznak.

4.5 Információkapcsolati diagrammok általános: műveletek, funkciók között

53


54 Vállalt vezetés

Készletgazd.

Értékesítés

Pü-i elszámolás

Technológia tervezés

Gyártás

részletes: szervezeti elemek közötti kapcsolatok is szerepelnek rajta. Bizonylatok megnevezését is tartalmazza. pl.:


55

4.6 Információáramlási folyamatábrák bizonylatáramlási folyamatábra, vagy információ áramlási folyamatábra attól függően, hogy mit akarunk ábrázolni a bizonylatok útját, vagy az információ útját: 1.

Műszakkezdés

2.

Kútkezelő azonosítása

5.

Elektronikus kútóra állás kinyomtatása

Záhonyi tankolási rendszer Opcionális, jelenleg nem kívánják használni

6.

n

Egyezik a kútfej számlálója a kinyomtatottal?

7.

Jegyzőkönyv

Raktárvezetőség

Kútóra állás módosításának engedélyezése

i

Szükség van-e az elektronikus kútóra állás módosítására

3.

Kútóra állás műszakkezdéskor

n

i 4.

Elektronikus számláló módosítása

4.

Kutak nyitóállásának beírása a NURIT-ba, vagy módosítás

n

VIU jármű tankolása? 8. i Működik-e azi automatikus járműazonosítás?

9.

n

i

10.

11.

13.

Tankoló személy azonosítása

Tankolás

13. Tankolási bizonylat nyomtatás

15.

16.

Tankolási bizonylat * 14.

24.

i 25.

26.

Fajsúlyozás

Tartályszintmérés negyedóránként

20.

Tankolás

21.

Kézi kútkönyv vezetése

Kézi engedélyezés

Tankolás

Tankolási bizonylat nyomtatás

Kézi kútkönyv vezetése

Tankolási bizonylat *

Tankolási bizonylat menetlevélhez csatolása

Napi első tankolás?

19.

17. Tankolási bizonylat nyomtatás

18. 12.

Kézi engedélyezés

H1 23.

n

Tankolási bizonylat * H1 Tankolási bizonylat AK jegyhez csatolása

Közlekedési rendszertervezés Időkoordinált

56

bizonylatáramlási,

vagy

időkoordinált

információáramlási

folyamatábrák.

Host

1.

Záhony Port tankolási rendszerének bizonylatáramlási ábrája

Átszámítás szabványliterre

Eltérés okainak vizsgálata

Raktárvezetőség 2.

Fajsúlyadatok beírása

Elektronikus kútóra állás megváltoztatásának engedélyezése

PIN kód

NURIT

3.

Elektronikus kútóra állások Elektronkikus óraállások módosítása

Üzemanyag kút

4.

Járművezet ő

5.

Mechanikus és elektronikus kútóra állások össehasonlítása

Jegyzőkönyv a kútóra állások eltéréséről

Gépkönyv vezetése

Kútóra állás módosítása

Fajsúlyozási jegyzõkönyv

Statisztikák készítése

1.

Kézi engedélyzős, és egyéb adatok felvitele

2.

Tankolási bizonylat

Döntés a paraméterek megváltoztatásáról

PIN kód

Kútkönyv bizonylat

3.

Paraméterek megváltoztatása

Kézi engedélyezés esetén csatolás a kútkönyvhöz

4. Kézi engedélyezés esetén nyilvántartás vezetése

5.

Csatolás a menetlevélhez

Csatolás a kézi kútkönyvhöz

Gépkönyv vezetése


57

Fék d iv

di ví zi ó

rtás nta rba , ka ítése telep ések

ítás

lás llá ta ins w. .s Hw

Jav

ások Ipari szolgáltat

Nyilvántartások

El sz ám olá s

Por

tűzvédele m

tasz

Re nd sz er ka r

ndez Bere

Sz ám Bé lá zá rsz s ám fej tés ,T Mé rleg B. kés zíté s Statis ztika

Munka és

a ik at

rtás fennta

Térképek, helyszínrajzok.

div.

rm fo In

4.8 Területi elrendezési ábrák

yártó

Rend észe t

álk Gazd

Üzem

zd. öz ga i eszk Tárgy dás o dálk gaz zlet Kés y üg nz Pé el vit ám z S

s zté les

trész Alka ás gyárt

ép g trész Alka odás

Raktározás

IV. Gazdálkodás

G

Irányít ás

fej

i ak sz Mű

ízió

és őrz en

St rat ég ia

II. Fő tevékenység

Fékja vítás Mű sza ki f Sz e jles er zté sz s ám Pó gé ta pg lk at y á ré rtá sz s gy ár tá s

Ell

rrás n erőfo Humá

I. Igazgatás

Vasúti fék gyá rtás

4.7 Funkcionális kördiagram

olgá lat

bq an tar

tás

III. Kiegészítő tevékenység


Gép divízió szerelde

Félkészáru, készáruraktár

Hőkezelő Szerszámraktár

Öntvényraktár

Keráru raktár Festő

Forgácsoló üzem

Csomagoló

Fék divízió szerelde

Fék MEO

58


59

5 Szervezet elemzés 5.1 A szervezetekről általában Gazdálkodási, működési cél

Erőforrások

Eredmények

Munkaerő Szabályok

Piac

Konkurencia

Épületek, gépek

Alapanyag, alkatrész

Gazdálkodó szervezet

Termékek, szolgáltatások

Szervezeti, működési struktúra

Árbevétel

Profit Pénz

Erőforrások pótlása

Integrált információs rendszer

Az adat, információ különleges erőforrás

A gazdálkodó szervezetek működése (Raffai, 30. old.)


60

Lehatárolás A lehatárolt rész szerkezetének feltárása A rendszerek felbontása 

A felbontás feleljen meg a rendszer természetének



A felbontás és a szintézis logikája között legyen összhang.

Minden felbontás, elhatárolás önkényes. 1. Feladat-módszer-eszköz: A végrehajtandó feladatokat A végrehajtás módját A végrehajtáshoz szükséges eszközöket, elemeket struktúrát vizsgáljuk A rendszerek analízisében és szintézisében a feladatok primátusa a jellemző, ehhez igazodva vizsgáljuk a többi dimenziót. 2. Küldetés Alaptevékenységen belüli ill. kívüli Műszaki-gazdasági ill. társadalmi-szociális Fejlesztési ill. üzemszerűen működő Rendszereket különböztethetünk meg. Információrendszer szempontjából legtöbbször az alaptevékenységen belüli, műszaki-gazdasági és üzemszerűen működő rendszerekkel foglalkozunk. 3. Működésterületek szerint A rendszer analízisében járható az az út is, hogy a felépítés logikáját követve a rendszer szerkezete mentén határolunk el kisebb részrendszereket. Ekkor a működésterületi elv szerint járunk el. magasabb fokú alacsonyabb fokú részrendszerek 4. Funkcionális elhatárolás: termelésirányítási anyaggazdálkodási műszaki előkészítési állóeszköz-gazdálkodási funkciók


61

5. Időhorizont szerint: hosszú távú középtávú rövidtávú feladatok A rendszerek felbontásában követhetjük bármelyik már említett kritériumot, követhetjük ezek bármilyen kombinációját, s a felosztás elvégezhető itt nem említett más kritériumok szerint is. A kritériumok megválasztását az adott körülmények figyelembe vételével állapíthatjuk meg. A felbontás alapvető értelmét az adja, hogy a szintézis szempontjából kezelhető méretű feladathoz jussunk.

5.2 Szervezet – szervezeti felépítés A szervezetek kialakítását, működését és megváltoztatását befolyásoló tényezők. A szervezetek nyílt rendszerek, szoros kapcsolatban vannak környezetükkel. Hatékonyságuk azon múlik, hogy milyen a struktúrájuk, milyen vezetési elveket és módszereket alkalmaznak. Ezek azonban nagymértékben függenek a környezeti feltételektől és a hosszú távon viszonylag stabilnak tekinthető vállalati adottságoktól. Ez nem jelenti azt, hogy minden befolyásoló tényezőt egyforma súllyal kell kezelni. A szervezetek kialakulását, működését és átalakítását a szervezet adottságai, és a környezeti feltételek határozzák meg, de ez nem jelent determinizmust. A szervezet megfelelő működése az ezekre adott jó válaszoktól függ. legmegfelelőbb struktúra kialakítása. a hatékonyságot rontó befolyásoló tényezők lehetőség szerinti megváltoztatása.


62

5 Környezet: Piac Tudományos-technikai környezet Szervezetközi kapcsolatok Kulturális környezet

4 A szervezet tagjainak jellemzői:

3 A szervezet tevékenysé gi köre:

(vezetők + beosztottak)

Diverzifikáltság (kiterjedtség) Vertikalitás (egymásra épülés) Komplexitás Tartósság Újdonságtartalom

Szakmai felkészültség Vezetési ismeretek Autoritás Általános vezetési elvek alkalmazása (menedzsment filozófiák)

Méret Alapfolyamati technológia Információ technológia Eredet Telepítettség Erőforrások

1 Stratégia

Konfliktustűrő-feloldó képesség

2 A vállalat adottságai:

Meglévő struktúra

Döntési kritériumok megfogalmazása

Kommunikációs hajlam Együttműködési hajlam Motivációs érdekstruktúra

és

Új szervezési struktúra, működés és magatartásformák

Ábra: A szervezetek kialakítását, működését és megváltoztatását befolyásoló tényezők.

szervezeti


63

5.2.1 Környezet

5.2.1.1 Piaci környezet A vállalatok vevőként és eladóként kapcsolatban vannak a piaccal. Megkülönböztethetünk: beszerzési és értékesítési piacot. A piac jellemzői közül a szervezetek kialakítása szempontjából az alábbiakat emelhetjük ki: változékonyság komplexitás korlátozó hatás. A piac változékonysága a partnerek változásának gyakoriságából és azok szabálytalan jellegéből adódik. Dinamikus a piac akkor, ha a vállalat piaci kapcsolatai gyorsan változnak, a vevők rendszeresen új termékek iránti igényekkel lépnek fel, és módosulnak a már forgalmazott termékekkel és szolgáltatásokkal szembeni követelmények (pl. a termékek korszerűségét, árát, minőségi paramétereit illetően). Staikus piaci környezetben az a vállalat működik, amely tar tósan ugyanazon termékeket és szolgáltatásokat vásárolja és értékesíti, a piaci partnerei hosszabb időtartam alatt sem változnak, a beszerzési és értékesítési feltételek és igények tartósan változatlanok. A komplexitást aszerint határozhatjuk meg, hogy mekkora a szervezetre vonatkozó döntések meghozatalánál figyelembe veendő külső tényezők száma, mennyire különbözőek ezek a tényezők és hogyan oszlanak meg a különböző környezeti szegmensek között. A komplexitás alapján - értelemszerűen - megkülönböztethetünk egyszerű és összetett piaci környezetet. A környezet változékonysága és komplexitása együt esen a bizonytalanság különböző fokozatait jelentik a szervezet számára. Statikus és egyszerű - azaz viszonylag biztos - környezetben a szervezet működésével szembeni követelmények jól áttekinthetők, viszonylag stabil tervek készíthetők, a struktúrák jól szabályozhatók. Ilyen feltételek mellett az úgynevezett mechanikus szervezet eredményesen alkalmazható. E szervezettípust az alábbiak jellemzik a feladatok fokozott specializációja és pontos leírása; a szabályok és eljárások szigorú formalizáltsága; a merev hierarchia, amely meghatározza a tagok közötti interakciókat és irányítja a kommunikációt; a döntéshozatal erőteljesen centralizált; a vezetők szorosan irányítják és ellenőrzik alárendeltjeik magatartását. Az előzőekkel ellentétben a dinamikus és összetett - azaz rendkívül bizonytalan környezetben a bizonytalanság kezelésére alkalmas organikus jellegű szervezet kialakítására van szükség. Előtérbe kerül a beosztottak részvételére építő, ún. participatív vezetési stílus, a döntéshozatal decentralizálása, a szervezeti egységek tevékenységé nek koordinációját biztosító mechanizmusok alkalmazása. A piaci környezet további fontos jellemzője a piac korlátozó hatása, amely adódhat a partnerek monopolhelyzetéből, a kereslet és kínálat egyensúlyának hiányából, esetleg állami korlátozó intézkedések (pl. kontingensek) érvényesüléséből. A hiánygazdaságban a beszerzési piacon a vállalatoknak gyakran kell szembe nézniük a szállító monopolhelyzetéből és/vagy a kínálat hiányából adódó hosszú és bizonytalan szállítási határidőkkel. A piaci korlátoktól erőteljesen függő helyzetben lévő vállalatok esetén a vezetés centralizációja figyelhető meg.


64

5.2.1.2 Tudományos-technikai környezet A tudományos-technikai környezet szervezetalakító hatása az 1960-as évektől kezdve, tehát a tudományos-technikai forradalom felgyorsulásával és az eredmények gyakorlati alkalmazásának kiszélesedésével került egyre inkább a figyelem előterébe. A gazdálkodó szervezetek számára nélkülözhetetlenné vált a fejlődés eredményeivel való lépéstartás, a termékek és szolgáltatások, valamint azok előállítási folyamatának megújítása a legújabb tudományos ismeretek felhasználásával. A tudományos-technikai környezet jellemzői közül a következőket emelhetjük ki: új tudományos eredmények megjelenésének gyakorisága; a tudományos eredmények gyakorlati alkalmazásának üteme (az alkalmazásba vételig terjedő időszak hossza); a tudományos-technikai fejlődés irányának kiszámíthatósága; a technika komplexitása. Minél gyorsabb a fejlődés üteme, az eredmények gyakorlati alkalmazása, s minél kiszámíthatatlanabb annak iránya, annál bizonytalanabb környezetben működik a vállalat. A bizonytalan tudományos-technikai környezet hasonló hatással van a szervezetre, mint a piaci bizonytalanság, emiatt gyakran együtt is tárgyalják e két környezeti szegmens hatását. A tudományos-technikai környezet különösen a vállalat kutatás-fejlesztési tevékenységére és szervezetére hat közvetlen módon. Amennyiben a piaci és a tudományos-technikai környezetet eltérő változékonyság és komplexitás jellemzi, akkor a vállalaton belül az egyes funkcionális területeken (K+F, termelés, értékesítés) eltérő struktúra alkalmazása indokolt annak érdekében, hogy mindegyik funkcionális terület alkalmazkodni tudjon a vele közvetlen kapcsolatban álló környezeti szegmens következményeihez. Az ily módon differenciálódott szervezetben fokozott igény jelentkezik a hatékony koordinációs mechanizmusok alkalmazására.

5.2.1.3 A szervezetközi kapcsolatrendszer Bármely társadalmi rendszerben működő szervezet közvetlen kapcsolatban áll a környezetében lévő politikai, kormányzati, érdekvédelmi stb. szervezetekkel. E szervezetkőzi kapcsolatrendszer (háló) kezelése fontos mind az erőforrások megszerzése, mind pedig a vállalat törekvéseinek a környezet által történő elfogadtatása szempontjából. Ugyancsak a szervezetközi kapcsolatrendszerhez tartozónak tekintjük a bankokkal a szállítókkal, valamint kooperációs partnerekkel fennálló viszonyt. A szervezetközi kapcsolatok rendkívül fontosak egy adott vállalat számára, hiszen az erőforrásokhoz való hozzájutás, az inputok beszerzése és az outputok piacra juttatása, más szervezetekkel történő együttműködés során realizálódik. Azt lehet mondani, hogy napjaink egyik fő tendenciájáról van szó: egyesülések, lobbizásra alkalmas szervezetek, politikusok és gazdaságirányítók mögött álló szponzorok és tanácsadók segítik a vállalatokat a kritikus erőforrások (pl. állami megbízások) megszerzésében.

5.2.1.4 Kultúrális környezet A kultúra a közösségek együttélésének terméke. Az együttélés során alakulnak ki azok a magatartásformák, viselkedési szabályok, amelyek sokszor a tudati szférától függetlenül vezérlik az emberek gondolatait és cselekedeteit. A kulturális jellemzők vizsgálhatók egy konkrét szervezet szintjén, illetve egy országra, szűkebb vagy tágabb földrajzi régióra, ágazatra vonatkozóan. E pontban bennünket a szervezet környezetének kulturális sajátosságai és azoknak a szervezetre gyakorolt hatásai érdekelnek.


65

A kultúra szerepének fontosságára jó például szolgálnak a japán vállalatvezetési módszerek amerikai és nyugat-európai alkalmazásának tapasztalatai. A Japánban-látványos sikereket eredményező módszerek bevezetésétől hasonló mértékű eredményjavulást vártak a nyugati féltekén is. A siker azonban sokszor elmaradt, az alkalmazási kísérletek csak részleges eredményt hoztak. Ennek magyarázatát abban találták, hogy e módszerek mélyen a japán kultúrában gyökereznek, s annak jellemzői lényegesen eltérnek a nyugati társadalmak kultúrájától. Példaként említhetjük, hogy a német vállalatoknál sokkal centralizáltabb a döntéshozatal, mint a hasonló méretű és profilú angol társaiknál. Ennek ugyancsak kulturális gyökerei vannak. Hasonlóképpen az angolszász és a német kultúra eltéréseinek hatása figyelhető meg az amerikai anyavállalatok németországi részlegei esetében. A második világháborút követően számos vállalatnál átvették az Amerikában alkalmazott vezetési és szervezeti megoldásokat. Néhány év elteltével a német részlegek struktúráját megváltoztatták, s a német szervezeti tradíciókhoz igazították, így a felső szintű vezetés hatalmi pozíciója megerősödött, a döntéshozatal centralizáltabbá vált. Ez a megoldás jobban megfelelt a német kultúra jellemzőinek, s eredményesebb működést vont maga után . Azt is látnunk kell, hogy a nemzeti kulturális sajátosságok vizsgálatával nem alakult ki a kultúra fogalmának és összetevőinek általánosan elfogadott értelmezése. Ugyanazon fogalmaknak eltérő tartalmat adnak a különböző szerzők. Ez részben arra is visszavezethető, hogy a használt fogalmakat nehéz pontosan és tartalmilag egyértelműen lefordítani egyik nyelvről a másikra, hiszen a nyelv, az egyes fogalmaknak tulajdonított tartalom maga is a kultúra terméke.

5.2.2 A vállalt adottságainak befolyásoló szerepe Az ábrán is látható vállalati adottságok közül az alábbiakra kell tekintettel lenni: a szervezet mérete az alapfolyamati és információ technológia a szervezet eredete a telepítési helyzete.

5.2.2.1 A méret A nagy szervezetekben a közvetlen személyes kapcsolattartás nem alkalmas arra, hogy megfelelő eligazítást adjon a szervezet tagjai számára a feladatok célszerű végrehajtási módját illetően. Szükség van orientációs eszközökre a szervezet tagjai tevékenységének összehasonlítása céljából. Ezt a szerepet az írásbeli szabályzatok tölthetik be. A méret szervezetalakító hatásának tárgyalásához mindenekelőtt a méret fogalmát kell tisztázni, milyen ismérvek alapján definiáljuk a szervezetek nagyságát. Ez leggyakrabban a létszám. Ennek megállapítása nem okoz jelentős nehézséget. (Egyéb tulajdonságok is képezhetik a méret alapját, pl.: árbevétel.) A méret és a szervezeti struktúra kapcsolatának vizsgálata szerint a nagyság összefügg a szervezeten belüli munkamegosztás (specializáció) mértékével és a tevékenységek írásbeli szabályozottságával. Minél nagyobb egy szervezet, annál nagyobb mértékű specializációt alkalmaznak, s egy-egy szervezeti egység, illetve dolgozó a vállalat fel adatainak egyre kisebb részével foglalkozik. Kisvállalatoknál például a fejlesztési tevékenység gyakran csak egy-két ember feladata, míg egy nagyvállalatnál esetenként több száz főt foglalkoztató főosztályok, intézetek végzik a fejlesztési munkát. A fejlesztési szervezeten belül ekkor munkamegosztást alakíthatnak ki, egy-egy fejlesztőmérnök általában csak meghatározott, specifikus


66

feladatokkal foglalkozik. A specializáció lehetővé teszi, hogy a vállalatnál az egyes munkafeladatokat magas szintű, speciális szakismeretek és kellő rutin alapján végezzék. Az elmélyült specializáció azonban azzal a következménnyel jár, hogy a szervezet egy-egy tagja a rendszer összfeladatainak csak a töredéke felett rendelkezik áttekintéssel. A nagy szervezetekben ezért fokozottan jelentkezik az összehangolás, az integráció követelménye. A részfeladatok és funkciók összehangolásában fontos szerepet játszik az írásbeli szabályozás. Számos gyakorlati tapasztalat mutatja, hogy minél nagyobb méretű a vállalat, annál több és részletesebb szabályzat alkalmazására van szükség. Amíg a kisebb szervezeteknél a szervezeti és működési szabályzat mellett néhány szabályzat (például a pénzforgalomra vagy a számviteli rendre vonatkozó) elégséges a megfelelő működéshez - ha egyáltalán ez határozza meg a működést -, addig a nagyobb szervezeteknél a szabályzatok teljes rendszerét figyelhetjük meg, amely részletesen előírja az egyes feladatok végrehajtásának módját, a különböző funkcionális területek kapcsolatát.

5.2.2.2 Alapfolyamati és információtechnológia Az alapfolyamati és információtechnológiával eddig is részletesen foglalkoztunk, sőt az utóbbi fejlesztése a tantárgy témája, ezért most erről részletesebben nem szólunk.

5.2.2.3 Eredet A szervezet struktúráját, működését és megváltoztatását befolyásoló tényezőnek tekinthető a vállalat eredete, múltja. A vállalat eredetének, múltjának jellemzői: a vállalat létrejöttének körülményei (pl. több korábbi szervezet összevonása); a szervezet keletkezésének személyhez kötöttsége vagy személytelensége; a szervezet kora; a történelmi jelentőségű változások, a szervezet történeti fejlődésével összefüggő lényegesebb események (a termékek és szolgáltatások választékmódosulása, a technoIógia változása, a tulajdonforma változása). A vállalat eredetén, múltján tehát a vállalat létrejöttének körülményeit, jellemzőit, az azóta eltelt időt és ezen időszak alatt bekövetkezett lényeges eseményeket, a termékek és szolgáltatások választékában, a technológiában és a tulajdonformában beállott változásokat értjük. E tényezők jelentős mértékben befolyásolják a különböző szervezeti és vezetési megoldások bevezethetőségét, de hatásuk különösen a szervezeti kultúrában a munkatársak vállalathoz való ragaszkodásában, kötődésében játszik nagy szerepet. Egy-egy krízishelyzetben gyakran éppen ezek a kötődések adnak lehetőséget a túlélésre.

5.2.2.4 A telepítési helyzet A szervezetekre vonatkozó döntések meghozatalakor indokolt figyelembe venni a telepítési helyzet sajátosságait. A telepítési helyzetet az alábbi ismérvekkel jellemezhetjük: a telephelyek száma, a telephelyek földrajzi elhelyezkedése, a telephelyek földrajzi távolsága, a nemzeti és régióbeli különbségek,


67

a város és falu, ill. főváros és vidék közötti különbségek, a szállítási hálózathoz való hozzáférés, infrastrukturális ellátottság. A több, s földrajzilag távol lévő telephelyekkel rendelkező termelővállalatok esetében a vertikális termelési szervezet, s az ebből adódó kiterjedt belső kooperáció alkalmazása a szállítási költségek növekedését vonja maga után. A különböző helyen végzett termelési folyamatok összehangolása még fejlett szállításszervezési rendszerek alkalmazása esetén is problémákat okoz. Rendkívül fontossá válnak a logisztikai problémákkal kapcsolatos szervezeti, vezetési kérdések. A földrajzi széttagoltság a vállalatok vezetésében a decentralizált döntéshozatal alkalmazását is kiválthatja. Minél szétszórtabban találhatók egy szervezet működési helyei, annál nehezebb központilag figyelemmel kísérni az események alakulását. Ha részletkérdésekben hozandó döntésekért is a központhoz kell fordulni, akkor a kommunikáció költségei a telephelyek számának növekedésével lényegesen megemelkednek, az időbeli késedelmek pedig elviselhetetlenek lesznek. További szempont, hogy a távolabbi helyeken működő középvezetők a döntések szempontjából jobb helyzetben vannak, hiszen ismerik a helyi körülményeket, így bármilyen kérdés felmerülése esetén azokat megfelelően értékelni tudják. Amennyiben földrajzi széttagoltság egyúttal eltérő állami szabályozással (adózás, környezetvédelmi rendelkezések) is párosul, akkor ez további érveket szolgáltat a decentralizáció irányában. Ezt nem csak multinacionális vállalatok esetében, hanem például az Egyesült Államok több tagállamában működő szervezeteknél is megfigyelhetjük.

5.2.3 A szervezet alapfeladatai (tevékenységi kőr) A szervezet alapfeladatait együttesen tevékenységi körnek nevezzük. A tevékenységi körön tehát azt értjük, hogy a szervezet milyen termékek előállításával és/vagy szolgáltatások nyújtásával foglalkozik; továbbá milyen a végzett feladatok belső struktúrája, kiterjedtsége, egymásra épülése stb. A tevékenységi kört szokták profilnak is nevezni. E két kategóriát mi szinonímaként kezeljük. A tevékenységi kört nagyon gyakran a vállalat adottságai közt szerepeltetik, mi azonban ezektől külön tárgyaljuk. Ennek elsősorban az az oka, hogy olyan jellegű tényezőről van szó, amelyet az esetek többségében nem tekinthetünk még rövidebb távon sem teljesen változatlannak, hiszen egy adott profilon belül is lehetőség nyilik - a vállalat stratégiájának megfelelően - minőségi módosításokra. A tevékenységi kört - az alaptevékenység tartalmán túl - az alábbi ismérvekkel jellemezhetjük: a diverzifikáltság (kiterjedtség), a vertikalitás (egymásra épülés), a termékek vagy szolgáltatások komplexitása, a tevékenységi kör tartóssága, a feladatok újdonságtartalma. A szervezet által végzett tevékenységek köre nagymértékben befolyásolja az ellá tandó funkciókat, az azokat realizáló folyamatokat és a szükséges szervezeti megoldásokat. A profil szerint változik az alaptevékenység tartalma (termelés, kereskedelem, gyógyítás stb.) és annak célszerű szervezési módja. Természetes tehát, hogy a különböző profilú szervezeteknél eltérő szervezeti felépítést találunk. A diverzifikáltság a szervezet tevékenységi körének a termelési és/vagy szolgáltatási ágak, illetve a piacok szerinti kiterjedtségét fejezi ki. Alacsony fokú diverzifikáltság (szűk


68

termék- és szolgáltatási skála, kevés számú piac) esetén a szervezet funkcionális tagolása még rendszerint megfelelő keretet biztosít a tevékenységek koordinálására. Erősen diverzifikált vállalatoknál a funkcionális szervezet nem bizonyul megfelelőnek, emiatt rendszerint a divizionális formára térnek át. A tevékenységek vertikalitása vállalaton belül és a vállalatközi kapcsolatokban egyaránt figyelmet érdemel. Iparvállalatnál a termelés vertikalitása a folyamat olyan tagozódását jelenti, amelyben a fázisok szorosan egymásra épülnek, s készterméket csak az utolsó vertikum bocsát ki. A belső kooperációban valamely termelőegység a megelőző vertikumtól kap továbbfeldolgozásra terméket, és az utána következőnek szállítja saját termékét (pl. fonoda, szövöde, kikészítő). Vertikális tagozódás esetén a fázisok összehangolása jelentős feladatot ad a termelésprogramozás és termelésirányítás számára. A vertikális termelési szervezetű vállalatoknál a gyakorlatban azt tapasztalhatjuk, hogy a termelőegységek gyakrabban tartoznak a hierarchia alsóbb szintjeinek irányítása alá, mint a horizontális vállalatoknál. Az egyes fázisok eredményhez való hozzájárulásának megállapítása fejlett belső elszámolási rendszert is igényel. A vertikalitás a vállalatközi kapcsolatokban is megfigyelhető. Nemzetközi tendencia, hogy a készterméket előállító vállalatok fejlesztési megbízásokat adnak alvállalkozóknak, illetve alkatrészeket és részegységeket gyártó beszállítókkal alakítanak ki tartós kooperációs kapcsolatokat (pl. autóipar). Ezáltal a vállalatközi integrációk különböző formái fejlődtek ki (koordinált bedolgozói rendszer, szerződéses kapcsolatok, koordinált jövedelmi kapcsolatok). A termékek vagy szolgáltatások komplexitása befolyásolja a fejlesztési, előkészítési, termelési és szolgáltatási folyamatok szakmai tartalmát, fokozott követelményeket támaszt a személyzet kiválasztásával és képzésével szemben. Hosszabb élettartamú, összetett termékek értékesítése esetén garanciális javítás, pótalkatrész-ellátás és a szervízhálózat kiépítése válik szükségessé. A tevékenységi kör tartóssága kihat a szervezetalakítás lehetséges formáira. A tartósan végzendő feladatok stabil szervezet kialakítását teszik lehetővé, ezáltal a szervezeti egységek - funkcionális vagy tárgyi munkamegosztás alapján - specializálódhatnak valamely feladatkör ellátására. Az újonnan jelentkező, s ideiglenesen végzendő feladatok vagy a tartós működést ellátó egységekhez csoportosíthatóak, vagy pedig ellátásukra külön, ideiglenes rendeltetésű szervezeti egységet hozhatunk létre. Az előbbi megoldás előnye, hogy nem kell változtatni a kialakult szervezeten, s elkerülhetőek az ebből eredő átmeneti zavarok, veszteségforrások. Fennáll viszont annak veszélye, hogy az új, ideiglenes feladatok ellátására kevés figyelmet fordítanak, s azok háttérbe szorulnak a stabil feladatokkal szemben. Éppen e hátrányok elkerülése érdekében alkalmazzák az új típusú feladatokra a teameket és a projekt szervezeteket. A projekt szervezeti egység kizárólag az új feladatok ellátásával foglalkozik, így biztosítható a feladatra való ráhangolódás és a sikeres megvalósításban való érdekeltség. Meg kell oldani viszont a projekt integrálását a kialakult vállalati szervezetbe. A feladatok újdonságtartalma befolyásolja az írásbeli szabályozás célszerű mértékét is. Minél újabb egy feladat, annál kevesebb ismeret áll rendelkezésre a végrehajtás módjára, az alkalmazandó eljárásokra vonatkozóan, s ennek következtében viszonylag alacsony fokú írásbeli szabályozásra van lehetőség. A feladatok írásban rögzítése ugyanakkor akadályozná a cél elérését szolgáló új megoldások keresését is.

5.2.4 Stratégia E fejezet előző pontjaiban áttekintettük a környezet, a vállalati belső adottságok és a tevékenységi kör hatását a szervezetek struktúrájára. Fontos kérdés azonban annak a hatásmechanizmusnak a tisztázása, hogy a befolyásoló tényezők miképpen vezetnek el valamely struktúra létrejöttéhez. Mindenekelőtt látnunk kell, hogy a tárgyalt befolyásoló


69

tényezők nem mechanikusan és nem determinisztikusan eredményezik a szervezeti struktúra kialakulását vagy megváltozását. A szervezeteknek választási lehetőségük van abban, hogy milyen módon alkalmazkodjanak a külső és belső feltételekhez vagy azok változásához. Tehát a befolyásoló tényezők és a szervezeti struktúra közé beiktatódik egy értékelési és célkitűzési tevékenység, amit stratégiának nevezünk. A stratégiát úgy értelmezzük, mint a szervezet jövőbeni céljaira és azok megvalósítási módjaira vonatkozó elképzelések összességét (lásd: Chikán, 1989). A stratégiaalkotás lényeges eleme a külső és belső feltételek vizsgálata. A szervezetalakítás szempontjából döntő fontosságú, hogy a vállalat (illetve annak vezetése) miként érzékeli és értékeli ezen feltételeket. Előfordulhat például, hogy megváltozik a környezet, de a szervezet vezetése ezt nem vagy csak késve érzékeli. A környezeti változásokra adandó strukturális válasz nyilvánvalóan függ attól is, hogy mikor és miként (pl. mennyire tartósnak, alapvető fontosságúnak) érzékeli a vezetés a változásokat, s milyen célokat fogalmaz meg azok alapján.

5.3 Szervezeti struktúrák és formák Alapvető strukturális jellemzők (szinonimaként: szervezeti formák) 

munkamegosztás



hatáskörmegosztás



koordinációs eszközök



konfiguráció

5.3.1 Munkamegosztás egy nagyobb feladatkomplexum részekre bontása 

funkcionális



tárgyi



regionális

Munkamegosztáson egy nagyobb feladatkomplexum részfeladatokra bontását és e részfeladatok egyes szervezeti egységekhez való telepítését értjük. A munkamegosztás egyben a szervezetek tagolásának alapja is. A munkamegosztás során különböző elvek szerint alakítják ki a szervezet egységeit, amelyeken belül a további munkamegosztás révén újabb szervezeti részlegeket különítenek el, egészen az utolsó munkahelyig. Ennek megfelelően beszélhetünk elődleges, másodlagos stb. munkamegosztásról. Funkcionális: homogén szakmai tevékenységek elkülönítése. Pl.: K+F, beszerzés, termelés, értékesítés, pénzügy. Tárgyi: 

termékek, termékcsoportok


70



anyagok



vevők szerint rendeljük az ellátandó feladatokat az egyes szervezeti egységekhez.

Regionális: földrajzi területek alapján. Egydimenziós szervezetek: kizárólag a három említett elv egyike alapján történik az elsődleges munkamegosztás. Két- és több dimenziós szervezetek: ahol az említett munkamegosztási elveket az elsődleges munkamegosztás szintjén párhuzamosan alkalmazzák ilyenek pl. a mátrixszervezetek.

5.3.2 Hatáskörmegosztás (egy- és többvonalas szervezetek) Egyvonalas szervezetek: + Alá fölérendeltség, kompetencia egyértelmű + Kapcsolatok áttekinthetőek és egyszerűek + A hierarchia megvéd mások visszaéléseitől. Felettes egységeket jelentősen igénybe vesz a koordináció Nagy mélységi tagozódásnál hosszú, körülményes információs utak. Személyes függőség jöhet létre a vezetők és a beosztottak között. Többvonalas szervezetek: + A funkciók elosztásával nagyfokú specializáció + Az információs utak közvetlenek + Újszerű megoldások kerülhetnek felszínre A kompetencia és a felelősség elhatárolása problematikus Szakmai alapon létrejövő konfliktusok személyessé válhatnak.

5.3.3 A koordinációs eszközök A koordináció szótári meghatározása szerint egymás mellé rendelést, összehangolást, „megfelelő viszonyba hozást" jelent. A szervezeti egységek differenciálódása a változó környezeti és belső feltételeknek megfelelő munkamegosztásból és hatáskörök megosztásából adódó természetes következmény, ezért nem a különbségek megszüntetésére, hanem sokkal inkább a részeknek a szervezeti célok érdekében történő összefogására kell törekedni. Mivel a koordinációs szükséglet annál erősebben jelentkezik, minél jellemzőbb a szervezeti egységek különbözősége, ezért korunk tendenciái: a diverzifikáció, a multinacionalitás, a környezeti hatások heterogenitása mind a koordináció fontosságát helyezik előtérbe. Nem túlzás tehát azt állítani, hogy a koordináció stratégiai jelentőségűvé vált napjainkra, s a szervezeti formák kitüntetett fontosságú strukturális jellemzője.


71

A koordinációs eszközök feltárásával kísérletező szervezetkutatók általában két nagy témakörben gondolkodtak (Child, 1984). Egy részük a vezetők túlterheltsége miatt a koordinációs igényeket a meglévő szervezetre támaszkodva próbálták kielégíteni, míg mások a weberi hagyományokból kiindulva az úgynevezett „absztrakt orientációs eszközöket" helyezték a középpontba. Az eszközök első csoportjába az alá- és fölérendeltségi viszonyok (az úgynevezett hierarchia) mint alapvető vertikális koordinációs eszköz mellett olyan horizontális megoldások tartoznak, mint: • a különböző (ideiglenes vagy állandó) összekötő pontok, egységek, keresztfunkciójú teamek; illetve a szervezeti egységek közötti közvetlen kapcsolatok; valamint • azok a megoldások, amelyek a hagyományos szervezeti tagolás mellett egy másfajta szempontot (logikát) is érvényesítenek a szervezetek működtetésében (termékvagy piacmenedzseri rendszerek, mátrixszervezetek). Ezek az eszközök tehát az adott szervezeti struktúra keretei között olyan pótlólagos, koordinációt segítő megoldásokat jelentenek, amelyek az adott struktúra lényeges átalakítása nélkül biztosítják a megnövekedett koordinációs igény kielégítését. Az „absztrakt orientációs eszközök" csoportjába tartoznak azok az - általában formalizált útmutatók, amelyek egységes irányt szabnak az egyes szervezeti részterületek tevékenységének. Így például: • a különféle szabályok, szabályzatok, procedúrák; • a tervek, programok, menetrendek (ügyrendek). A különböző koordinációs eszközöket (mint strukturális jellemzőket) az eddigiek alapján a következőképpen csoportosíthajuk: 

Strukturális



Technokratikus



Személyorientált.

Strukturális típusú koordinációs eszközök: olyan a szervezet alapstruktúrájába beépülő, az elsődleges munkamegosztást és a hatáskörök megosztását nem, vagy csak átmenetileg módosító megoldások mint: a projektek, a teamek, az ad hoc és állandó bizottságok, a törzskarok, valamint a termékmenedzseri rendszer. A projektekben különböző motivációjú, eltérő ismeretekkel és képességekkel rendelkező, a szervezet különböző szakmai területein és hierarchikus szintjein elhelyezkedő embereket hoznak össze olyan feladatok, tervek megvalósítása érdekében, amelyekre érvényesek a következők: időbeli korlátozottság (határidők), viszonylagos újszerűség, nagy kockázat (a végeredmény bizonytalansága), egyszeri jelleg, komplexitás. A szervezetekben adott célok projekt formájában történő megvalósítása mellett a következő érvek szólhatnak:


72

A problémaorientáltság, az áttekinthető, illetve az előre látható időtáv, az adott költségkeret, és esetenként a hozzá kapcsolható megtérülési követelmény biztosítja az anyagi és emberi erőforrások ésszerű kihasználását. A projektek vegyes szakmai összetétele támogatja a részérdekek összehangolását. A vállalat struktúrájának átalakítása nélkül is lehetőség nyilik a változó feltételeknek megfelelő alkalmazkodásra (növekszik a vállalat problémaérzékenysége és rugalmassága). A projektcsoport hierarchikusan strukturált vagy team formában működő szervezeti egység, amelynek vezetése egyértelmü kompetenciával és felelősséggel rendelkezik. A projektek tagjai - annak fontosságától függően - az eredeti szervezeti egységükből ideiglenesen kikerülve függelmileg és szakmailag is a projektvezető alá tartoznak. A team a szervezet különböző területein tevékenykedő, eltérő pozíciókkal rendelkező személyekből álló feladatorientált és autonóm egység, amelyet valamilyen probléma megoldására, illetve ideiglenes vagy állandó feladat elvégzésére hoznak létre. A különbség a projektekhez képest elsősorban abban ragadható meg, hogy az elvégzendő feladat vagy a megoldandó probléma nem szükségszerűen újszerű és egyedi, valamint az időbeli korlátozottság sem feltétlenül jellemző rá. Kissé leegyszerűsítve: a projekteket gyakran team formában működtetik (ezt projekt-teamnek is nevezik), ugyanakkor egy team létrehozása nem feltétlenül jelenti projekt indítását is. A teameknek a döntés-előkészítési és döntési fázisban van nagy szerepük, különösen a többcélú, többtényezős döntéshozatalban (a realizálási fázisban kevésbé célszerű teameket működtetni, itt inkább az operatív végrehajtás felügyeletét látják el). A teamek áItalában belső hierarchia, esetenként formális vezető nélküli, a különböző hierarchikus szintről kiválogatott embereket egymás mellé rendelő, hasonló jogosítványokkal rendelkező munkatársakat feltételező csoportok. A vállalat funkcionális egységei és különböző vezetési szintjei közötti intenzív kommunikációt, a döntések szakmai megalapozottságát, a dolgozói részvételt, az operatív és a stratégiai megfontolások egyidejű képviseletét állandó is ideiglenes (ad hoc) bizottságok felállításával biztosítják. Ezek a bizottságok általában a vállalat felső vezetése mellett működnek. Kevésbé speciális tevékenységet végeznek, inkább a vállalaton belüli kommunikációt segítik elő, a különböző szakmai területek döntéseinek koordinációját látják el. A bizottságok tehát esetenként a vezetőség tehermentesítését szolgálják, más esetben pedig a funkcionális akadályok leépítését segítik elő, amit a bizottságok heterogén összetételével érnek el (így biztosítható például az összhang a K+F és a marketing között). A bizottság tagjai eredeti státuszukat megtartva, sem szakmailag, sem függelmileg nem „kerülnek ki" az eredeti szervezeti keretek közül. A bizottságok információs, tanácsadó, döntéshozó, végrehajtó (megvalósító) tartalommal hozhatók létre. A törzskarok többnyire stratégiai döntések előkészítői fejlesztési, marketing, szervezetalakítási és innovációs kérdésekben. A törzskarok közvetlenül a vállalatvezetőnek alárendelten, utasítási jog nélküli csoportként több szempontból is fontos koordináló szerepet töltenek be: Áttekintik az alsóbb szinteken folyó, de a törzskar szakmai körébe tartozó munkákat. Állandó kapcsolatban állnak a felső vezetéssel, így sajátos közvetítői a hierarchián lefelé a stratégiai elképzeléseknek, felfelé a lehetőségeknek. Szélesebb látókörüknél fogva a törzskarok által megfogalmazott javaslatokban érvényre jut a többszempontúság.


73

A törzskarok lehetséges szervezeti elhelyezését nem elemezzük részletesen, jóllehet a szervezeti formák fejlődésében a törzskarok kialakulása igen nagy jelentőségű volt. A történelmi hűség kedvéért annyit azonban el kell mondanunk, hogy semmiképpen sem új keletű dologról van szó. Fayol szerint - akit a törzskari szervezeti koncepció atyjának tekinthetünk - minden termelést segítő, illetve ezt kiegészítő jellegű tevékenység törzskari jellegű. Általában az amerikai és az angol vezetési és szervezési felfogás is a fayoli gondolkodást követi a „line" (vonal) és a „staff" (törzskar) ilyen értelmű megkülönböztetésével. Eszerint a vonalbeli (line) szervezeti egységek közvetlenül a fő tevékenységi területhez kapcsolódnak (ilyen például iparvállalatok esetében a termelés és az értékesítés; kereskedelmi vállalatoknál a beszerzés, a készletezés és az értékesítés), a többi szervezet pedig a törzskart (staff ot) alkotja. E felfogás szerint egy iparvállalatnál a fejlesztés tehát ugyanolyan törzskari szervezet, mint egy jogi osztály vagy egy tanácsadó. A német nyelvterületen és Magyarországon is a törzskari szervezet (Stab) funkcióját sokkal szűkebben értelmezik. Elsősorban a vezetési tevékenységet közvetlenül segítő szervezeti egységeket (vagy személyeket) nevezik törzskarnak. Ezek olyan szervezetek, amelyeknek nincs semmilyen döntési, illetve utasítási jogkörük, s a döntéselőkészítés-döntés-végrehajtásellenőrzés egyes fázisaiban csak közvetetten (a vezetők befolyásolásán keresztül) érvényesíthetik akaratukat. Könyvünkben a törzskar ilyen (szűkebb) értelmezését követjük mi is, és a törzskarok szerepét a többi szervezeti formához kapcsolva tárgyaljuk. Az említett strukturális koordinációs eszközökről összességében elmondható, hogy a bizottságok, valamint a törzskarok létrehozása az adott szervezet hatásköri és felelősségi rendszerét formálisan nem változtatja meg. A projektek és a teamek viszont - tartalmuktól és céljuktól függően - egy adott időszak alatt általában nem hagyják érintetlenül a szervezet hatásköri rendszerét. A termékmenedzseri rendszer a fejlesztési, a termelési, az értékesítési stb. alrendszerek közötti (horizontális) koordinációt biztosítja oly módon, hogy az egyes termékekhez vagy termékcsoportokhoz felelős vezetőt rendel, aki a termékét vagy termékcsoportját érintő minden információ megszerzésére, az egyes funkciók közötti közvetítésére jogosult. E megoldás a szervezeten belül mátrixszerű működést eredményez. Az eddig említett strukturális koordináicós megoldások főbb jellemzőit az alábbi táblázat foglalja össze.

Projekt

Team

Törzskar

Bizottság

Különböző Eltérő pozíciókkal érkező Stratégiai Vállalat felső vezetése motivációjú, eltérő személyek, autonóm döntések mellett működik. ismeretekkel egység előkészítése. rendelkező, Vezetőség különböző mellett dolgozó szakterületen szervezet dolgozók Probléma orientáltság Probléma megoldás Tanácsadói Nem speciális Ideiglenes vagy állandó feladatok tevékenység feladat Újszerű feladatok

Nem szükségszerűen új – vagy egyedi probléma

Alkalmankénti feladatok.

Közlekedési rendszertervezés Időben korlátozott

Időben korlátozott, vagy Folyamatos állandó tevékenysége

74 Állandó vagy ad hoc bizottságok

Technokratikus: Szabályzatok, lejárások; tervek, programok; költségkeretek, pénzügyi tervek Személyorientált: A vezető határozza meg a szervezet működését.

5.3.4 Konfiguráció mint másodlagos jellemző A munkamegosztást, a hatásköri rendszert, az alkalmazott koordinációs eszközöket elsődleges strukturális jellemzőnek tekintjük, ezzel szemben a konfiguráció másodlagos vagy származtatott strukturális jellemző. Az első három ugyanis gyakorlatilag kialakítja a szervezet struktúrájának vázát, azaz a konfigurációt. (Sajátos módon sokak számára - ez alól nem kivételek hazai vállalataink sem - csak a konfiguráció megváltoztatása jelenti az „igazi" szervezetalakítást, miközben egy-egy szervezeti egység eltűnése, vagy újak felbukkanása a szervezeti ábrán nem feltétlenül jelenti a szervezet fennálló munkamegosztási, hatásköri stb. rendszerének lényegi átrendezését.) A konfiguráció mint származtatott, de mindenképpen önálló jelentéstartalommal bíró strukturális jellemző a következő kategóriákkal írható le: mélységi tagozódás szélességi tagoltság szervezeti egységek mérete.


75

5.3.5 Leggyakoribb szervezeti alapformák Funkcionális szervezet: elsődleges munkamegosztás: funkciók szerint hatáskörök: döntési jogkörök centralizációja Koordináció: Technokratikus. Vertikális koordinációs megoldások: kommunikációs csatornák alá-fölérendelt szervezeti egységek között. erőteljes szabályozottságra való törekvés

Vállalatvezetés

Fejlesztés

Termelés irányítás

Törzskar

Kereskedelem

Tervezés, pénzügy

Alaptevékenység/végrehajtás E szervezeti formát az egyik legrégebbi strukturális megoldásnak tekinthetjük Feltételei: Stabil piaci tudományos-technikai környezet. Előny:

Specializáció-kis egységköltség folyamatok standardizálhatósága alacsony koordinációs kltsg

Hátrány:

Alrendszerek egymással nem kommunikálnak. Felesleges mennyiségi, minőségi tartalékok Nehézkes alkalmazkodóképesség Stratégiai szemlélet elhanyagolása


76

Divizionális szervezet: A divizionális szervezeti forma az alábbi feltételek mellett alkalmazható: növekvő vállalati méret erőteljes termelési és termékdiverzifikáció a vállalat nemzetközivé válása. Divizionális szervezetekben az elsődleges munkamegosztás tárgyi vagy regionális elvű, azaz általában termékek, vagy vevők ; vagy földrajzi értelemben vett piaci régiók szerint tagolják a szervezetet. A vállalton belül így kialakított relatíve autonóm felelősségi és elszámolási egységeket nevezik divíziónak. Munkamegosztás: tárgyi (termékek, vevők) vagy regionális. Hatáskörmegosztás: decentralizál a divíziók és központ relációjában, centralizáltak a divíziókon belül Koordináció: divíziók között nincs, egyébként technokratikus. A divizió központ az összvállalati szintű célok érvényesítése és a feladatok ellátása érdekében az irányítási, koordinációs és ellenőrzési tevékenységet központi szinten látja el. A központ feladata elsősorban a források elosztása, a különböző vállalati tevékenységek pontos elhatárolása (a divíziók egymástól független működési feltételeinek megteremtése), divíziók létrehozása és megszüntetése; valamint a divíziók működésének megítéléshez hatékonysági kritériumok kidolgozása, és hatékonyságértékelés. A központ tervezési feladataihoz szorosan kapcsolódnak a vállalat pénzügyi irányításához és a controllinghoz. A tervezési rendszer megfelelő kialakítása igen komplikált, mivel egyszerre kell teljesülnie az összvállalati céloknak, de biztosítani kell a divíziók viszonylagos önállóságát is. A divíziók relatíve nagy önállóságot élveznek. A divízióvezetők nem csak operatív és adminisztratív döntéseket hozhatnak, hanem a hozzájuk tartozó termékek, régiók vonatkozásában stratégia döntéseket is. Megfelelő működésükhöz saját irányító apparátusuk van, amelyet esetében a funkció szerinti munkamegosztás elvét követik. Divíziók típusai: A divízió típusa Cost-center Profit center Investment center

Hatáskör A divízió működési költségei A divízió árbevétele, működési költségei és eredménye A divízió árbevétele, valamennyi költsége, ráfordításai, eredménye, valamint a működésbe vont eszközök megtérülése


77

A divízionális szervezet lehetséges felépítése:

Vállalatvezetés

Központi HEM

Központi igazgatás, ellenőrzés

A termékcsoport divízió

Központi K+F

Stratégia tervezés

B termékcsoport divízió

C termékcsoport divízió

Divízió vezető

Gyártmány fejlesztés

…

Termelés

Értékesítés

Feltételei: Dinamikus környezet, széles termékskála Előny:

Stratégiai és operatív feladatok szétválaszthatók Erőteljes piaci orientáció Teljesítményre ösztönző rendszer

Hátrány: Divízió egoizmus Párhuzamos funkciók léte

Mátrixszervezetek:

Központi marketing

…


78

A mátrixszervezeteknél az elsődleges munkamegosztás szintjén két munkamegosztási levet egyszerre alkalmaznak. Így elmondhatjuk, hogy a mátrixszervezetek a többdimenziós szervezeti formák családjába tartoznak. Munkamegosztás: Különböző elvű Hatáskörmegosztás: Két dimenzió vezetői együtt döntenek a metszéspontban található problémáról. Alacsony fokú formalizáltság. Koordináció: Személyorientált A mátrixszervezetek eltérő megjelenési formái léteznek, amelyek gyakorlatilag az alkalmazott munkamegosztási elvek kombinációi alapján jönnek létre. A leggyakrabban előforduló párosítások: •

funkció – tárgy

•

funkció – régió

•

funkció – funkció

•

tárgy - régió

Vállalatvezetés

Fejlesztés

Termelésirányítás

A termékcsoport

B termékcsoport

C termékcsoport

Feltételek: Dinamikus, heterogén környezet Előny:

Adaptív, innovatív Szervezeti tagok nagyobb telj.

Hátrány:

Problematikus kompetencialehatárolás Vezetők rivalizálása

Kereskedelem

…

Pénzügy


79

Túlhajtott csoportmunka Krízishelyzetben összeomolhat

Vállalatvezeté s Fejleszté s


Kereskedele m

…

Pénzüg y

A régió

B régió

C régió

Tenzorszervezetek: A mátrixstrukúrához hasonlóak, de legalább háromdimenziósak, azaz egyidejűleg alkalmazzák a munkamegosztás kialakításánál a funkcionális, a tárgyi, és a regionális elvet.

Vállalatvezeté s Fejleszté s A termék csoport B termék csoport C termék csoport


Kereskedele m

… I. régió II. régió

III. régió


80

Duális szervezetek: Az eddigiekben megismert szervezetek egyik munkamegosztási elvet kiemelt módon alkalmazták vagy párhuzamosan alkalmaztak több munkamegosztási elvet. A duális szervezet esetén az elsődleges (primer) struktúrára ráépül egy másodlagos (szekunder) struktúra. Kvázi párhuzamos struktúrák alakulnak ki. Ilyen pl.: stratégiai üzleti egységgel működő szervezetek és a team szervezetek. Konszernek és holdingok: •

Konszern: jogilag önálló szervezetek együttes tevékenysége valamely iparágban. A tőkekoncentráció egyik megjelenési formája.

•

Holding: olyan irányító vállalat, amely kizárólag a vagyonkezelés eszközeivel befolyásolja az irányított társaságokat.

5.4 Humán erőforrás-gazdálkodás (management) A szervezeteknél alkalmazott munkavállalóknak a munkavégzéshez szükséges képességük, szakismeretük és a munkamegosztásban betöltött helyük szerint strukturált összességét az emberi erőforrások, a munkaerő képezik. A humán erőforrás-gazdálkodási alrendszer feladata a szervezetben foglalkoztatott emberekkel, munkatársakkal való mindennemű feladatok elvégzése. Legfontosabb feladatai: megfelelő összetételű személyi igények: munkaerő szükséglet új emberi erőforrások megszerzésére irányuló teendők számbavétele bérezés és az ösztönzés rendszerének kialakítása, a hatékony ellenőrzés és a végzett munka értékelési módszereinek megválasztása dolgozók képzési, továbbképzési tervének elkészítése karrierépítés, a munkavállalók megfelelő előmenetelének biztosítása.


81

6 A rendszertervezés komplex módszertanai 6.1 Bevezetés a komplex módszertanokba: Miért van szükség módszertanokra tehető fel a kérdés. Íme néhány válasz 1. Hosszú, és a tervezettet legtöbbször meghaladó fejlesztési idő (mert nem normázható tevékenységet kell elvégezni, de a projekt megkezdése előtt általában nem világos az elérendő cél.) 2. Magas fejlesztési költségek, amelyekkel szemben kevés a kimutatható eredmény. 3. Az elkészült rendszerek általában nehezen módosíthatók, rugalmatlanok. (hiányos fejlesztési dokumentáció, hibás tervezés is okozhatja) 4. A felhasználói követelmények gyakran kielégítetlenül maradnak. 5. Még mindig gyakori a többszörös adattárolás (redundancia). 6. Új eszközön sokszor régi rendszer valósul meg. (régi rendszerben szokásos megoldásokat mechanikusan átviszik az új eszközökre) Jelentős átdolgozással használt; 1300

Változtatás nélkül használt; 119 Leszállított, de sikeresen sohasem használt szoftver; 3200

Változtatások után használt; 198

Kifezetett, de le nem szállított; 1950

6.2 A rendszerfejlesztés bemutatása

komplex

módszertanainak

általános

A módszertan azokat az általános elveket foglalja össze, amelyek a fejlesztési folyamaton belül a szervezők, - illetve a fejlesztő team tagjainak -, szemlélet- és viselkedésmódját, valamint a munka során alkalmazott módszereiket határozzák meg. Egy-egy fejlesztési módszertan azon túl, hogy összegyűjti azokat a fejlesztési-tervezési eszközöket, technikákat és módszereket, amelyeket saját céljainak megfelelőnek ítél, olyan elveket is lefektet(het), amelyek az egész munka menetére, a résztvevők tevékenységére hatnak. A módszertan tehát a fejlesztés során követendő :


82

elveknek, fejlesztési eszközöknek, módszereknek és technikáknak, valamint dokumentálási elveknek az összessége, amelyeket legalább az adott projekt során törvénynek tekintünk. "Komplex"-nek azért nevezzük ezeket, mert nem csak egy-egy munkafázis ra, hanem a teljes fejlesztési folyamatra, vagy legalább annak jelentősebb szakaszaira nézve adnak útmutatást. Az előzőekben már megemlítettünk néhány korai rendszer-fejlesztési módszertant. A továbbiakban a ma használatos un. struktúrált fejlesztési módszertanok közül tárgyalunk néhányat, amelyek itthon talán a legismertebbek illetve a leginkább használtak.

6.3 Az IBM vállalati információrendszer tervezési módszere (BSP)

A komplex módszertanok bemutatását szinte törvényszerűen kezdjük az IBM módszertanával, hiszen a cég a hazai informatikai kultúra egyik - és talán a legjelentősebb meghatározója, és szerepe e téren napjainkban is igen jelentős (Itt elsősorban nem az IBM PC-kre, sokkal inkább a 360/370-es sorozat, illetve az ezekre épülő és a hazai számítástechnikát közel két évtizedig meghatározó ESZR család gépeire, továbbá napjaink RISC 6000 és AS 400-as gépcsaládjaira, vagy a több hazai nagyvállalatnál használt mainframe gépekre, ezek szoftvereire és természetesen a hozzájuk kapcsolódó IBM terminológia használatára gondolunk.) Nyilván sokak előtt ismert, hogy az IBM nem csak számítógépeket gyárt. Legalább ilyen jelentőségű a szoftver készítési tevékenysége, amelynek egy jelentős részét természetesen a rendszer- és segédprogramok alkotják, de ugyanakkor igen nagymennyiségben "vállalati szoftverek" is készülnek az IBM szoftverházban. (Későbbi tanulmányaik során részleteiben is meg fogják ismerni a pl. a COPICS termelésirányítási rendszert.) A BSP - Business System Planning - módszert az IBM a 60-as évek végén, 70-es évek elején saját információrendszer fejlesztési tevékenysége során fejlesztette ki. Később piaci termékként is megjelent és a cég ajánlotta minden - nem csak iparvállalat - szervezet információrendszerének fejlesztése során alkalmazható módszerként. A BSP a teljes rendszerfejlesztési folyamatnak csak egy részét, nevezetesen a fejlesztés beindulásától a koncepcionális tervezésig terjedő szakaszt fedi le. A BSP a szervezeten belüli információrendszerek (IR) szerkezetével, kapcslódásukkal, megvalósításuk ütemezésével foglalkozik. Látható tehát, hogy fogalmaink szerint nem igazán tekinthető komplex fejlesztési módszertannak, mivel inkább az információrendszerek stratégiai tervezésének módszere. Mégis tárgyaljuk, mert a többi fejlesztési módszertan - bár elvileg alkalmas ilyen megközelítésre is - más, inkább taktikai aspektusból kezeli a fejlesztési folyamatot szemléletmódjában úttörő, más, későbbi módszertanokat is meghatározó elemeket hordoz. Nyugodtan tekinthetjük a struktúrált fejlesztési módszertanok első egyedének.

6.3.1 A BSP alapelvei


83

Abból a felismerésből kiindulva, hogy az adatfeldolgozás feladata a szervezet, nem pedig a szervezeti egységek és egyes feladatkörök igényeinek a kielégítése, a következő stratégiai elveket alakították ki: egyértelmű felelősség az adatok jóságáért az adatnak egy forrása és sok felhasználója legyen az információrendszerek irányítása és tervezése központi legyen az adatok a szervezeti felépítéstől üiggetlenek legyenek az adatok, az eszközök közös felhasználása a távadatátviteli lehetőségek figyelembevételével Látható, hogy ezek az elvek tulajdonképpen az integrált információrendszer elveit jelentik. Ezen stratégiai célokat figyelembe véve határozták meg a módszer elveit, amelyeken az egész tervezési módszer alapul. a) Az IR-nek támogatni kell a vállalat céljait és szándékait A BSP tulajdonképpen nem más, mint a vállalati stratégia lefordítása az információrendszer (IR) stratégiára. A BSP módszer e tekintetben tehát a felülről lefelé (top-down) elvet követi.

vállalati stratégia rendeltetés célkitűzések szándékok

BSP

IR strat. tervezés

IR stratégia IR célkitűzések IR politikák IR felépítés

b) Az IR stratégia a vállalat minden vezetői szintjének igényeit ki kell elégítse A szervezetek különböző szintjei eltérő szerkezetű, mennyiségű és gyakoriságú információkat igényelnek. Ezek teljes és ésszerű a kielégítése gyakorlatilag lehetetlen egyetlen rendszeren belül, de ugyanígy elképzelhetetlen az is, hogy valamely információigényt egy vezetői szinthez kössünk. A tervezett rendszernek alkalmasnak kell lenni ezen eltérő - és sokszor ; egymásnak ellentmondó - igények kielégítésére. c) Az IR ellentmondásmentes adatokat szolgáltasson az egész szervezet számára Egy rendszerben ugyanazok az információk térben és időben eltérően jelennek meg. A szervezet egyes részeiben ugyanazok az adatok eltérő módon kerülhetnek gyűjtésre, feldolgozásra. Bonyolítja a helyzetet, hogy az egyes egységekben mindez időeltéréssel mehet végbe. Az adatfeldolgozó rendszerek hagyományos alulról felfelé (bottom up) tervezési elvének alkalmazása önmagában is ezt a problémát szüli. A BSP ezt úgy oldja fel, hogy az adatokkal, mint erőforrásokkal gazdálkodik, biztosítva a szervezet bármely egységének hozzáférését ezen erőforrásokhoz (adatokhoz). d) Az IR képes legyen túlélni a szervezeti és a vezetői változásokat Az információrendszerek jelentős része a vállaltok egy-egy részlegéhez, esetleg vezetői igényekhez kötődnek. Az ilyen rendszerek esetén szervezeti átalakulások, vagy az érintett vezető cseréje a rendszer kidobását, jobb esetben átalakítását is jelenti. A B SP erre egy igen


84

kézenfekvő segédeszközt vezet be, amelynek alkalmazásával a fentiekből eredő problémákat megszünteti. Ez a "segédeszköz" : a vállalati folyamat. Tekintet nélkül a vállalati kapcsolatokra, függőségekre, vezetők személyére bármely vállalat típusra összeállítható egy olyan folyamat-együttes, amely mindaddig, amíg a vállalat terméke, vagy szolgáltatása alapvetően nem változik, csak minimális változáson fog keresztülmenni.e) Az IR stratégiát az átfogó IR szerkezet ismeretében alrendszerenként kell megvalósítani A szervezetek általában túl nagyok ahhoz, hogy egyetlen projektben megvalósítható IR-t hozzunk létre. Nem csak anyagi kérdés tehát, hogy a rendszereket fokozatosan, több lépcsőben valósítják meg, és csak a végén alakul ki az un. integrált rendszer (IR). Ugyanakkor a rendszerek alulról felfelé történő megvalósítása számos problémát vet fel, aminek a megoldása csak megfelelő keretek között lehetséges. A BSP elve erre az, hogy a rendszereket hosszú távú stratégiai célok figyelembevételével felülről lefelé tervezzük meg és alulról fölfelé haladva - a stratégiai tervnek megfelelően - hozzuk létre.

6.3.2 A BSP módszer lépései

A fejlesztés folyamatát a módszer "BSP tanulmány"-nak nevezi. A BSP tanulmány elindítását a vállalti információrendszer fejlesztési igénye indokolja, mint az előzőekben láttuk, feladata az információrendszer fő vonalainak, koncepcionális tervének elkészítése. A fejlesztési folyamatot tekintve beszélhetünk : a BSP-t megelőző tevékenységekről, a BSP tevékenységekről, és a BSP-t követő tevékenységekről A módszer kellóképpen nyitott, szükség esetén az igényeknek megfelelően " módosítható A módszertan nem ír elő dokumentálási technikát, bár a nevéből (BSP tanulmány) eredően is jelentőséget tulajdonít a dokumentációnak. A BSP tulajdonképpen megalapozta az IBM máig korszerűnek tekinthető dokumentációs rendszerét, a HIPO-t. Így - bár maga a módszertan még nyilvánvalóan nem igényli - bátran ajánlhatjuk a BSP-hez a HIPO dokumentálási használatát. A BSP folyamatát, lépéseit a következő ábrán követhetjük nyomon. Az egyes lépések részletes ismertetésétől e helyütt eltekintünk, mivel ezek ' technikailag nagyrészt a korábbiakban tanultak szerint zajlanak. A tartalmi, ' kérdésekre pedig a témakörhöz kapcsolódó előadások keretében terünk vissza.


85

Az elkötelezettség megszerzése

A BSP tanulmány előkészítése Indítóülés

Vállalati folyamatok meghatározása Rendszer kapcsolatok elemzése Interjúkészítés Problémák, és hasznának elemzése

megoldásuk

Inf. rendsz. szerkezet Inf. rendsz. irányítása Alrendszerek sorrendjének meghat. Javaslatok, akcióterv

Beszámoló az eredményekről


86

6.3.3 A BSP és a dokumentáció

Az eddigiekből láttuk, hogy a BSP a hangsúlyt a fejlesztés előkészítésére és kezdeti szakaszaira helyezi. Ez a szakasz igen nagymennyiségű dokumentumot termel, továbbá maga a módszer BSP tanulmány - neve is utal a dokumentáció kitüntetett szerepére. A módszer a BSP tanulmány irattárának létrehozását kiemelten kezeli. Az irattár javasolt tartalma : a fejlesztés szempontjából fontos levelezés rendszer célok és terjedelem megfogalmazása projekt terv ütemtervek előkészítés során gyűjtött adatok befejezett elemzések dokumentációja vezetői interjú feljegyzések vezetői interjú összefoglalók a tanulmány ellenőrzési pontjain megtartott ülések jegyzőkönyvei javaslatok jelentés és beszámoló

A módszertan kézikönyve javaslatot ad a tanulmányi jelentés tartalmára is: vezetői összefoglaló szándék, terjedelem, célok vizsgálat módszere a vállalat áttekintése az információrendszer (IR) áttekintése megállapítások, következtetések javaslatok akció terv a projektre az igényektől függő függelék

6.3.4 A BSP módszertan értékelése A korábbiakban láttuk, hogy jelentős szoftver cégek korábban - és a későbbiek során is ! több módszertant fejlesztettek - és fejlesztenek napjainkban is - azzal a céllal, hogy a segítségükkel készülő számítógépes információrendszerek az adott belső- és külső feltételek közepette a lehetséges hatékonysággal működhessenek. A korábbi módszerek is alkalmasak voltak arra, hogy a fejlesztendő rendszert egységes fejlesztési-tervezési elvek közé szorítsák. Ezek azonban elsősorban a gazdálkodó szervezetek egyes alrendszereinek kifejlesztésére voltak használatban. (Nyilvánvalóan az adott korszak hardver-, szoftver- és szervezésmódszertani lehetőségeinek alapján először az ilyen "alrendszerek" kerültek kialakításra, és csak ezt követően jelent meg az integrálás igénye.) A módszertan tulajdonképpen nem alkalmas a fejlesztési munka véghezvitelére, hiszen a rendszer életciklus igen kis részét fedi le. Ebben a szakaszban viszont a mai módszerekre is ható, igen jelentős újítást hozott. A BSP nagy jelentőségű eredménye a rendszer szintű


87

gondolkodás. Az alrendszerek öszszekapcsolásának sok problémával járó és valójában soha meg nem oldható elve helyett az információrendszer fejlesztés stratégiai tervezését teremtette meg, utat nyitva ezáltal a mai korszerű fejlesztési módszertanok megjelenésenek.

6.4 ARDOSZ '79 - a rendszerfejlesztés legismertebb hazai módszertana Az 1970-es évek a hazai számítástechnika látványos fejlődésének kezdeti időszaka. Ekkor jelentek meg az ESZR számítógépek, amelyek a korábban nyugati, - IBM, Honeywell, SIEMENS, stb. -, számítógépekhezképest viszonylagos olcsóságuk és főleg könnyebb hozzáférhetőségegük, - nem kellett a vásárlásukhoz konvertibilis deviza -, miatt - gyengébb minőségük ellenére is -, a számítástechnika addigiakhoz képest szélesebb körű felhasználását tették lehetővé.

6.4.1 Az ARDOSZ általános bemutatása Az ARDOSZ tulajdonképpen nem is annyira, módszertan, mint inkább egy dokumentációs előírás, amelyik tartalmaz fejlesztési eszközökre, technikákra utaló előírásokat is. Alapja a KGST tagországok Számítástechnikai Kormányközi Bizottságának (SZKB) normatívái, ajánlásai, illetve az ESZR szabványok rendszere. Az ARDOSZ a fejlesztés szakaszait, és így a fejlesztés során keletkező dokumentációt az alábbiak szerint csoportosítja : tervezést megelőző szakasz, tervezési szakasz, kivitelezési szakasz Látható tehát, hogy a módszer a rendszer életciklusát nem fedi le, annak csak egy részére ad megoldást. Az alkalmazandó fejlesztési eszközök és módszerek, valamint ábrázolási technikák tekintetében nem ad újat, csupán a kor ismert eszköztárát ajánlja. Jellemzője a dokumentáció során használandó "formalapok", amelyek mintegy mankóként segítik a kitöltőt abban, hogy milyen információt kell megadnia.

6.4.2 Az ARDOSZ tervezési módszerei is technikái

Mint általában a fejlesztési módszertanok, az ARDOSZ is abból indul ki, hogy a fejlesztés-, nem pedig az utólagos módosítások során kell a rendszert jól, a követelményeknek megfelelően elkészíteni. Ennek eszközét és biztositékát a hierarchikus, funkcionális tervezés módszerében látja. A módszer fogalmai : funkcionális tervezés : Funkció alatt a módszertan két definíciót is ad : o egy tárggyal kapcsolatos tevékenység o néhány input adatnak néhány visszatérési adattá transzformációja


88

A hierarchiát a következők szerint értelmezzük : a rendszer egy olyan funkciókomplexum, amely alsóbb szinteken további funkciókra osztható, egészen addig, amíg az elemi funkciók szintjére nem jutottunk. A funkciók közötti kapcsolatot az adatösszefüggések alkotják. A funkcionális tervezés annak a megállapítását jelenti, hogy mi a teendő az input- és az output adatok alapján. iteratív eljárás : A rendszertervezés iterációs eljárások sorozata. a tervezés koncepcionális szintjei : o rendszer szint o program szint o modul szint A módszertan megalkotói szerint a hierarchikus, funkcionális tervezés előnyei : a rendszer egyeztethető

tartalma

a

felhasználó

feladatmeghatározásával

könynyebben

hiányzó és következetlen információk időben feltárhatók funkciók jól definiálható egységekben jelennek meg, jól dokumentálhatók és ezért könnyen módosíthatók a dokumentációk a megvalósítás különböző fázisaiban folyamatosan készíthetők a hierarchikus tervezés struktúrált, fentről lefelé haladó kódolást tesz lehetővé A módszertan a fejlesztési ciklus következő fázisait határozza meg : igénymeghatározás rendszerelemzés rendszertervezés programtervezés részletes programmodul-tervezés rendszer- és programdokumentálás Az ARDOSZ a fejlesztési-tervezési munka során a következő technikák alkalmazását ajánlja : HIPO tervezési és dokumentálási technika folyamatábrák o adat-folyamatábra o program-folyamatábra o programháló-ábra o konfiguráció-ábra döntési táblázatok

6.4.3 Az ARDOSZ dokumentálási rendszere Mint a módszertan egyéb vonatkozásainál itt is hangsúlyozzák a készítők a dokumentálás hierarchikusan struktúrált, moduláris felépítését. A dokumentáció legmagasabb szintjét a


89

fejezetek alkotják. A fejezetek alkotóelemei a pontok, amelyekhez az ARDOSZ dokumentációs lapok rendelhetők Az ARDOSZ több, mint 40 dokumentációs lapot ajánl, amelyeket a különböző dokumentáció típusoknál használhatunk. A használatukra és kitöltésükre vonatkozóan részletes útmutatást ad az ARDOSZ kézikönyve. A módszertan az alábbi dokumentáció típusokat különbözteti meg: Rendszerjavaslat Nagyvonalú rendszerterv Részletes rendszerterv Programdokumentáció Operátori kézikönyv Felhasználói leírás A rendszer súlyt helyez a dokumentumok módosításának, karbantartásának kérdésére. Valamennyi fenti dokumentum típus az érdemi információk mellett tartalmaz egy : módosítási jegyzék és egy módosítások leírása nyilvántartást, amelyek vezetésére szintén forma lapok szolgálnak.

6.4.4 Az ARDOSZ értékelése Bár ez a módszertan ma már nem igazán használatos, elemi, főleg a dokumentálással kapcsolatos ajánlásai, a formalapok sok hazai fejlesztőnél megtalálhatók. Háttérbe szorulását sem kora, hiszen később született, mint bármelyik SDM, és alig idősebb az SSADM első verziójánál -, sem tulajdonságai nem indokolják. Legnagyobb hibája valószínűleg az, hogy itthon, nem pedig külföldön készítették, így nem lehetett a tanulmányozására Angliába, vagy más nyugati országba utazni. Mindenképpen jelentősnek kell ítélni a módszertant abból a szempontból is, hogy a számítógépes információrendszerek fejlesztésének (hazai) kezdeti időszakában igyekezett olyan eszköztárat adni a fejlesztők kezébe, amelynek segítségével sok buktató elkerülhető lett volna. Hogy ez nem sikerült, az nem a módszertan, - és főleg nem a készítői -, hibája. Az ARDOSZ végül is a kor színvonalán álló, korszerű fejlesztési módszertannak tekinthető, amely célkitűzését, eszközeit, módszereit tekintve semmiképpen sem maradt el a nyugati fejlesztési módszertanoktól. Legnagyobb hibája talán az, hogy nem kapott olyan hírverést, oktatási támogatást, aminek segítségével szélesebb körben terjedhetett volna el.

6.5 SDM-HOSKYNS rendszerfejlesztési módszertan Ezt a módszertant az angol HOSKYNS cégnél, a 1970-es években fejlesztették ki. Életciklusszemléleten és az un. top-down technikán alapuló strukturált fejlesztési módszertan, amelynek több használatos módszertannal szemben igen komoly előnye, hogy a rendszerfejlesztés teljes életciklusában használható. Az SDM ( System Development Managment ) módszertant fejlesztői azzal a kifejezett céllal hozták létre, hogy a rendszerfejlesztés során fellépő un. kockázati tényezők hatását a lehető legnagyobb mértékben csökkentsék. Ennek a kockázat-minimalizálásnak egyik "eszköze" a módszertan alapelveinek következetes érvényesítése.


90

6.5.1 Az SDM módszertan alapelvei Az SDM módszertan célja, hogy olyan rendszerek készüljenek a segítségével amelyek már a fejlesztés során az eredeti célnak megfelelően alakulnak, nem pedig utólagos javítgatásokkal, módosításokkal érik el - vagy nem! - a kitűzött célt. Ennek érdekében az SDM készítői a következő elveket határozták meg : kettős szintű tervezés tevékenységek több szinten való állandó iterálása elkötelezettség kényszerpályán tartása késleltetett döntések hangolás Ezek az elvek nem csak a módszertan vezérfonalát jelentik, de - mint azt a későbbiekben látni fogjuk -, jelen vannak az egyes munkafázisokban, lépésekben is.

6.5.1.1 Kettős szintű tervezés Az SDM kidolgozói szerint a rendszerfejlesztés egyik legkomolyabb kockázata az, hogy a projekt indításakor nem lehet pontosan meghatározni a munkához szükséges erőforrásokat. (munkaerő, költség, idő, eszköz, stb.) Nem véletlen ez a felismerés, hiszen mindig is a rendszerfejlesztés egyik kritikus pontja volt a határidők és a költségek tartása. Szinte alig találni olyan projektet, amelyben ne lépnék túl az előre megállapított költségeket és határidőket. Ahol pedig ezeket tartani igyekeznek, ott kapkodás és végül hibás működés, kevesebb szolgáltatás az eredmény. Az SDM tervezői szakítottak azzal a gyakorlattal hogy ;r projekt indításakor kell meghatározni annak minden lényeges paraméterét. Ezzel szemben bevezették a kettős szintű tervezésnek (two level planning) nevezett elvet, amelynek lényege a következő : A projekt indításakor nem láthatjuk előre, hogy az mikorra készülhet el, milyen költség-, erőforrás- és egyéb kihatásai lesznek. Ezért csak egy olyan nagyvonalú kalkulációt készítünk, amelyről tudjuk, hogy csak tájékoztató jellegűek, ezért nem is igazodunk hozzá feltétlenül. Adunk viszont egy pontos értéket a következő munkafázisra vonatkozóan, amit viszont "tűzzel - vassal" be is tartatunk. Minden fázis lezárásakor pontosítjuk az egész projektre vonatkozó becslésünket és meghatározzuk a következő fázisra vonatkozó pontos adatokat. Ennek a módszernek a következetes végrehajtása megment bennünket a fejlesztési munka külső - belső zavaró tényezőinek a költségekre és a határidőkre gyakorolt káros hatásaitól.

6.5.1.2 A tevékenységek több szinten való állandó iterációja A probléma hasonló az előzőhöz, de belső. Míg a határidők és a költségek elsősorban kifelé vannak hatással, - ti. a vezetők, felhasználók felé kell magyarázkodni -, addig itt a fejlesztő munka "vakvágányainak" kezeléséről van szó. Különösen a bonyolult, nagy rendszereknél fordul gyakran elő, hogy a fejlesztésnek csak egy későbbi fázisában derül ki, valamelyik részt másként kellett volna kezelni, megtervezni. Ilyenkor vagy - időt és jelentős költségeket felemésztve - újra elkészítjük a hibás részt, vagy pedig hibásan hagyjuk. Ebben az esetben viszont számolni kell azzal, hogy a rendszerünk nem az elvárásoknak megfelelően fog funkcionálni. Az SDM ezt a problémát az iteráció elvé nek bevezetésével igyekszik megoldani Mivel a fejlesztés során nem tudjuk elkerülni azt, hogy időnként korábbi állapotokra vissza kelljen nyúlni, és újra készíteni egyes részeket, legjobb, ha nem elkerülni akarjuk a lehetetlent, hanem eleve betervezzük a létét.


91

Az iteráció az SDM módszertanban három szinten valósul meg. Az első szint az SDM felépítéséből, az egyes munkafázisok belső struktúrájából fakad. Minden fázisban bele van ugyanis építve egy kontrol folyamat, amikor is az előző fázis munkáját áttekintjük és ha hiányosságot találunk, akkor azt azonnal javítjuk. A második iterációs szintet a fejlesztési projektbe beépített ellenőrző folyamatok jelentik. Ezt alapvetően a projektvezető építi be a rendszerbe. Az iteráció harmadik szintjét az egyes fejlesztés során elvégzendő munkafolyamatok több fejlesztési fázisra elnyújtása jelenti. Vagyis: nem egyetlen szakaszban végezzük el az adott tevékenységet, hanem először csak a körvonalait határozzuk meg, majd nagyvonalúan dolgozzuk ki, végül pontosítjuk, finomítjuk.

6.5.1.3 Az elkötelezettség kényszerpályán tartása Korábbi tanulmányaink során már találkoztunk azzal a furcsának tűnő megállapítással miszerint : a fejlesztés eredményéért a felhasználó a felelős. Az elkészült rendszer bevezetésekor a rendszert működtető felhasználók nagyobb kárt tudnak okozni, mint egy rosszul dolgozó munkatárs a fejlesztés folyamán Mi okozza a legnagyobb problémát a felhasználók esetében? Az, hogy nincsenek igazán felkészülve a rendszer fogadására. Nem ismerik igazán a rendszert, a szolgáltatásait Féltik a munkahelyeiket Nem bíznak abban, hogy egy gép el tudja végezni az ő munkájukat Nem érzik magukénak azt, ami elkészült Ezeken a gondokon csakis egyféleképpen lehet segíteni. Megfelelő formában el kell készíteni a felhasználót a rendszer fogadására. Ezt a munkát azonban am lehet csak a fejlesztőkre hagyni, és főleg nem elég a rendszer bevezetéét megelőző utolsó szakaszban - oktatás végezni, hanem már jóval az azt megelőző időszakban el kell kezdeni. Ez közös feladat! A fejlesztők el kell, hogy fogadtassák a rendszert a megbízó kiemelt képviselőivel, akik megértve .inak lényegét, szerepét, hatásait a folyamatban, fel tudják készíteni a dolgozókat is. Ennek a folyamatnak egyik eszköze a tárgyalt elv megvalósítása. Miről is van tehát szó? Amennyiben a felhasználó a megbízás, projekt indítás időszaka után a bevezetés szakaszában találkozik újra a rendszerrel, nagy a valószínűsége, hogy a hozzáállással kapcsolatban jelzett problémák fel fognak lépni. Rá kell tehát kényszeríteni, hogy vegyen részt a folyamatban, érezze úgy, hogy : "ő csinálta". A kettős szintű tervezés elvénél már láttuk, hogy az újbóli szerződés kötésekkel a felhasználó újra és újra aktivizálható. Ha ezt kiegészítjük azzal, hogy minden fázis végén az állásfoglalását is kérjük, tehát meg kell ismernie az addig elvégzetteket, akkor gyakorlatilag a teljes fejlesztési folyamatot végig követi. Jelen van, amikor valami történik, elmondhatja a javaslatait, kifogást emelhet, stb., tehát részt vesz a munkában. Ilyen körülmények között már nem utasíthatja el a rendszert, érdeke a rendszer sikere és ennek érdekében m e g i s t e s z mindent. A teljesség kedvéért megjegyezzük, hogy a felhasználó képviselője, - a módszertantól fiiggetlenül a fejlesztő team-nek is tagja. Ezen a tag(ok) részvételét is felhasználhatjuk a fenti cél elérése érdekében.

6.5.1.4 A késleltetett döntések elve Pontosabban : a majdnem késleltetett döntések elve.


92

Az iterációnál már láttuk, hogy a tevékenységek elnyújtása hogy szolgálja a módszertan céljait. Itt is valami hasonlóról van szó, de ellenkező előjellel. A fejlesztési munka bizonyos pontjain döntéseket kell hoznunk, állást kell foglalnunk bizonyos kérdésekben. Örök probléma, rendelkezünk-e a szükséges információkkal, tudunk-e eleget ahhoz, hogy a fejlesztés további menetét meghatározó döntést hozhassunk. Az SDM erre azt mondja : Ha már a döntés időpontját nem tudjuk kitolni, hozzuk előre az információ szerzés idejét. Ezért a előre hozunk tevékenységeket, idő előtt elvégzünk feladatokat, de meghatározó döntéseket csak a módszertan által meghatározott időpontokban hozunk. Ezzel az előre dolgozással viszont elértük, hogy az adott időpontban ténylegesen birtokában legyünk a szükséges ismereteknek.

6.5.1.5 A hangolás A végére maradt az SDM talán legszimpatikusabb alapelve. A legtöbb módszertan ui. mereven előírja, mikor mit kell tenni, ettől eltérés a módszertan elveinek megsértését jelenti. Ugyanakkor kijelenthetjük, hogy minden projekt más és más. Fő vonalaira ráhúzható egy általános elv, ami nagyon sok esetben nem is fog látható gondot fog okozni. Lesz viszont néhány olyan projekt, amit nem lehet a többivel azonos módszerekkel kezelni. Olyan ez, mint a konfekció. Az emberek nagy részének megfelel, de aki igazán jól akar kinézni, vagy nem fér bele az átlagba, az "mérték után" dolgoztat. A z S D M d e k l a r á l j a hogy nem minden p r o j e k t azonos E z é r t nem csak hallgatólagosan fogad el a módszertan alkalmázása során apróbb eltéréseket a sablontól, hanem kifejezetten elő is írja, hogy a módszertant az adott feladatra alkalmazzuk. A hangolás a fázisok menetében történő módosítást jelent. A szükségleteknek megfelelően vonhatunk össze, párhuzamosíthatunk, esetleg hagyhatunk el tevékenységeket. Ha a helyzet úgy kívánja, még be is iktathatunk új munkafázisokat. Egy dolgot nem tehetünk : a "testre szabás" nem érintheti a módszertan alapelveit. Ezeket ugyanis nem szabad megsérteni.

6.5.2 A rendszerfejlesztés folyamata a módszertan alkalmazásával Az SDM a teljes fejlesztési munkát szakaszokra, fázisokra osztja. Megjegyezzük, hogy ezek a fázisok a rendszerfejlesztés életciklusának megfelelően épülnek fel. (ld. 12. ábra) Az SDM módszertan egyik nagyszerű megoldása a fázisok belső felépítése. Az egyes fázisok ugyanis általában azonos felépítésűek, mintegy formalizáltak. A módszertan csak a legszükségesebb mértékben tér el ettől az uniformizált felépítéstől, de itt is utalunk a hangolásra, ami lehetővé tesz további - alkalmazótól eredő - eltérést. A fázisokon belüli % tevékenységek a módszertan alapelveiből következnek és egyúttal azokra vissza is hatnak. A fázisok belső felépítése és bennük az SDM elvek megvalósulása az alábbiak (vastag szedés) szerint történik: A fázis előkészítése - iteráció az aktuális fázis feladatainak végrehajtása következő fázis megtervezése, a projekt terveinek finomítása - kettős szintű tervezés az aktuális fázis dokumentálása, jelentés készítés


93

jóváhagyatás - felhasználói elkötelezettség biztosítása az előzőek újbóli áttekintése - iteráció

6.5.2.1 Előkészítés A z adott munkafázis előkészítése során egyrészt

a) visszatekintünk az előző fázis munkájára, másrészt b) a team vezetése (projektmanagament) áttekinti a terveket, informálja a szakasz résztvevőit. ad a.) Alapvetően a dokumentáció alapján áttekintjük az előző szakaszban elvégzetteket Az megállapításainkat, következtetéseinket összevetjük az elvá rásokkal. Amennyiben úgy találjuk, hogy eltérés, hiányosság van, netán hibát fedezünk fel, javítjuk, mielőtt tovább lépnénk. ad b.) Az előző munkafázis végén elkészített pontos - fázisra vonatkozó - és nagyvonalú - a projekt hátralévő részére szóló - terveket, szerződéseket átnézzük szükség esetén pontosítjuk. A team adott munkafázisban résztvevő lapjait tájékoztatjuk az adott szakasz és az egyes tagok feladatairól, a fázis paramétereiről.

6.5.2.2 Végrehajtás Ez a tevékenység a rendszer fejlesztéséből az adott munkafázisra eső, - természetesen minden szakaszban más és más -, feladatok elvégzését takarja. Ennek során felhasználhatunk minden eszközt, módszert, amit a rendszer fejlesztés illetve tervezés eddigi története során létrehoztak, vagy akár új elemeket is iktathatunk be. Az egyes fázisokban a "végrehajtás" természetesen más-más feladatok elvégzését, így más és más eszközök alkalmazását is jelenti Erre a kérdésre a következő fejezetben visszatérünk. Felhívjuk a figyelmet, hogy a felhasználó, - a fejlesztő team tagjaként -, a végrehajtás fázisában is jelen van.

6.5.2.3 Tervezés Ebben a szakaszban kettős szintű tervezés elvének megfelelően elkészítjük a következő fázis idő-, költség-, erőforrás tervét, és természetesen elkészítjük hátralevő munkákra vonatkozó becslést is. Ez a tevékenység sorozat elsősorban a projekt vezetését érinti. A tervezés során át kell tekinteni a rendszer céljait, az ismert korlátokat. El kell készíteni az erőforrások, úgy mint. : munkaerő költségek eszközök idő felhasználásának tervét. Célszerű, ha a tervezést olyan eszközök, módszerei segítségével végezzük, amelyek többszempontú tervezést és ellenőrzést is lehetővé tesznek. Ugyancsak meg kell tervezni a fázis ellenőrzési pontjait. El kell készíteni továbbá a módszer hangolását a projekt következő fázisához.


94

6.5.2.4 Jelentés készítés Nem lehet eleget hangsúlyozni a dokumentálás fontosságát. Ez a munkafázis tulajdonképpen a rendszerfejlesztés folyamatos dokumentálását célozza meg. A módszertan, - mint láttuk -, különösen nagy hangsúlyt helyez a megbízó, felhasználó részvételére a fejlesztési munka során. A szakaszok közötti döntés alapja az előző szakasz(ok) jól megszerkesztett dokumentációja, amely fejlesztési célok és a megbízó elvárásainak ismeretében tartalmazza a rend szer állapotát. A dokumentálást, jelentéskészítést ugyanúgy elő kell készíteni, meg kell tervezni mint magát a fejlesztési munkát. A jelentés készítésnek egyik célja, hogy a megbízó számára információt biztosítson a döntéshez, ezért nem csak előkészíteni kell, de át is kell adni a megbízónak és meg kell vitatni vele.

6.5.2.5 Szerződéskötés Az SDM módszertan minden szakasz lezárása után tulajdonképpen lezártnak tekinti a fejlesztést. A folytatás csak új szerződés alapján lehetséges. Természetesen sem a megbízónak, sem pedig a fejlesztőknek nem célja a munka tényleges befejezés előtti abbahagyása. A folytatás érdekében viszont mind a két félnek feltételei vannak. A megbízót meg kell győzni, hogy amit eddig végeztünk az az ő elvárásaival összhangban van, ha folytatjuk, akkor megszületik a megrendelt rendszer. Ennek a meggyőzésnek az egyik - talán a legfontosabb - eszköze a rendszer dokumentációja. Ugyanakkor a fejlesztés folytatásának csak akkor van értelme, ha a fejlesztés feltételeit a megbízó biztosítja Feltételek (többek között) : az eddig végzett munka elfogadása megbízóra háruló feladatok ütemezés szerinti elvégzése fejlesztési munka további terveinek elfogadása erőforrás igények elfogadása, biztosítása a következő szakasz szerződésének aláírása A feltéltételek tisztázása, mind a két fél részéről történő elfogadás után kerülhet s or a következő munkafázis szerződésének megkötésére, és ez alapján a m u nka folytatására.

6.5.2.6 Áttekintés A módszertan egyik sarkalatos pontja az állandó visszatekintés, a több szinten megvalósuló iteráció. A munkafázis teljes lezárta előtt még egyszer végignézzük a fázisban, - beleértve a következő szakasz tervét és a szerződést is! -, elvégzetteket. Még mindig jobb az esetleges hibát itt feltárni és korrigálni, mint tovább vinni, és ezáltal hatását halmozni. Az áttekintés természetesen nem csak a dokumentumok átnézését jelenti, sokkal inkább a fejlesztő : team közös értékelése.

6.5.3 Az S D M (HOSKYNS) módszertan munkafázisai A módszertan tehát összesen 12 szakaszra osztja a fejlesztés menetét. Ezek a munkafázisok részben sorosan, részben párhuzamos munkavégzést lehetővé . téve kapcsolódnak egymáshoz. Az egyes szakaszokat és kapcsolódásukat a 12. ábrán követhetjük, itt csak a megnevezésüket adjuk meg: Projekt indítás Kezdeti felmérés Megvalósíthatósági vizsgálat Részletes elemzés Vállalati rendszer tervezése

Közlekedési rendszertervezés Számítógépes rendszer tervezése Program tervezés Manuális eljárások tervezése Áttérés megtervezése Programozás Bevezetés Utólagos elemzés

95


96

Project indítás Kezdeti felmérés

Megvalósíthatósági vizsgálat Részletes elemzés

Vállalati

rendszer

tervezése

Utólagos értékelés

Számítógépes rendszer tervezése Programtervezés

Manuális eljárások tervezése Áttérés tervezése

Programozás

Bevezetés Az SDM módszertan fejlesztési szakaszai A következőkben megpróbáljuk részletesen megmutatni azokat e feladatokat amelyeket az egyes SDM szakaszokban el kell végeznünk. E helyütt csak a tevékenységek felsorolására szorítkozunk, nem foglalkozunk azokkal a technikákkal, módszerekkel, amelyek segítségével


97

a munkát ténylegesen elvégezzük, mivel ezeket előző félévi tanulmányaik során már kellő részleteséggel megismerték.

6.5.3.1 Projekt indítás Ebben a fázisban a fő feladat a projekt vezetésre hárul. A fázis célja, hogy a megbízás adataira és egyéb információinkra támaszkodva meghatározzuk : a jelenlegi rendszer problémáit, a fejlesztendő rendszer körvonalait, a fejlesztendő rendszer hatáskörét, a fejlesztési célok prioritásait, a fejlesztés kereteit és korlátait, továbbá felkészüljünk a projekt megvalósítására A projekt indítás munkafázisa igen fontos a teljes projekt szempontjából., Nem szabad elnagyolni, felületesen kezelni, mert ennek kihatása a projekt menetére katasztrofális lehet. Ebben a fázisban hozzuk létre a fejlesztő team-et, készítjük el a projekt nagy- , vonalú terveit, itt indítjuk a dokumentációt is. Itt készítjük el azokat hálóterveket, amelyekre a továbbiakban a pontosításokat alapozzuk, végezzük el a rendszer és a módszertan hangolását. Megtervezzük a munka és a következő fázis (a kettős szintű tervezés elvének megfelelően) erőforrásait, - hogy időben rendelkezésre lehessen ezeket bocsátani -, elkészítjük azokat a szerződés tervezeteket, amelyeket, - az elveknek megfelelően -, az egyes fázisokban már csak kitöltünk és végül de nem utolsó sorban kijelöljük az egyes részfeladatok felelőseit is. A vázolt feladatokat megvalósító fázist az SDM a következő szakaszokra bontva ajánlja elvégezni: A fejlesztendő terület meghatározása Kezdeti felmérés megtervezése Szerződéskötés előkészítése

6.5.3.2 Kezdeti felmérés A fázis fontosabb munkafolyamatai : Kezdeti felmérés előkészítése Szervezendő terület tanulmányozása Megoldási elképzelések felvázolása "Megvalósíthatósági vizsgálat" megtervezése Jelentéskészítés Szerződéskötés előkészítése Átnézés A fázis alapvető feladata, a meglevő rendszerről információ begyűjtése annak érdekében hogy: eldönthessük, érdemes-e az adott fejlesztést elvégezni, az új, fejlesztett rendszer céljait, körvonalait meghatározhassuk, pontosíthassuk, fejlesztési változatokat alakíthassunk ki. A munkafázis tulajdonképpen a nagyvonalú helyzetfelmérés fejlesztési szakasznak felel meg. A részleteket nem tárgyaljuk, mivel ezeket az ismereteket a jegyzet előző kötete tartalmazza.


98

6.5.3.3 Megvalósíthatósági vizsgálat Az előző fázis folytatásaként - és az SDM elveinek megfelelően, minimális költséggel - el kell dönteni, hogy a kitűzött fejlesztési célok milyen feltételekkel milyen ráfordításokkal milyen szervezeti módosításokkal milyen erőforrások bevonásával A fázis fontosabb munkafolyamatai :

Megvalósíthatósági vizsgálat előkészítése A vállalati funkciók és a környezet analízise A jelenlegi információs rendszerek leírása Jelenlegi költségek elemzése Megoldási alternatívák készítése Megoldási alternatívák összehasonlítása "Részletes elemzés" megtervezése Jelentéskészítés Szerződéskötés előkészítése átnézés A fázis célja, hogy a nagyvonalú felmérés eredményeinek ismeretében elv' gezhessük a feladatok, célok és fejlesztési területek pontosítását, az információrendszer megváltoztatásának lehetőségeit, a nagyvonalú elképzelésein alapján elkészíthessük a fejlesztési változatok pontosítását, összehasonlító elemzését. A tárgyalt fázisnak a "klasszikus" megfelelője a nagyvonalú helyzet felmérés és -elemzés. Ennek eszközei, módszerei előző tanulmányainkból ismertek, így a tevékenységek részletezésére nem térünk ki. A fázist lezáró dokumentum tulajdonképpen nem más, mint, - az itt "Megvalósíthatósági tanulmány"-nak nevezett -, Rendszerkoncepció.

6.5.3.4 Részletes elemzés Az információrendszer tulajdonképpeni fejlesztése ezzel a szakasszal veszi kezdetét. Az előző fázisban döntésre terjesztettük elő a rendszer fejlesztési koncepcióját. A megbízó dönti el, hogy az ott felvázolt alternatívák közül melyiket választja. A kiválasztott változat tervezése ezután a részletes elemzéssel kezdődik. Ennek során apró részleteiben is megismerkedünk a jelenlegi információrendszer elemeivel, folyamataival. A nyert információk feldolgozása alapján meghatározzuk az új rendszerrel szembeni elvárásokat követelményeket. Felvázoljuk a felhasználói elvárásokat, a rendszer szolgáltatásait, a beépíthető ellenőrzési pontokat és folyamatokat. Meghatározzuk az adatbázis alapvető . Az SDM módszertan elveinek megfelelően a munkafázis itt is több lépésre osztható : Részletes elemzés előkészítése Jelenlegi rendszer megismerése


99

Jelenlegi rendszer megbecslése A javasolt rendszer követelményeinek megtervezése A javasolt rendszer követelményeinek megbecslése A "vállalati rendszer tervezése" fázis megtervezése Jelentéskészítés Szerződéskötés előkészítése Átnézés A fázisa hagyományos módszerekkel végzett tervezés részletes felmérés és részletes elemzés szakaszainak felel meg. A szakaszban kerülnek részletesen meghatározásra, pontosításra a rendszerrel szemben támasztott követelmények. Ezek lehetnek : a rendszer szolgáltatásaira vonatkozó és biztonsági követelmények Az első csoportba a rendszerrel szemben támasztott közvetlen megbízói elvárások tartoznak, amelyek a rendszerből nyerhető informá~ ciókra vonatkoznak. A második csoport az előzőhöz kapcsolódik ugyan, de nem a majdani felhasználók igénye, hanem az igények kielégítésének biztonsága determinálja. Ennek keretében kell megoldani a rendszer védelmével kapcsolatos kérdéseket, helyesebben azt a problémát, hogy a lehetséges veszélyforrásokra szemben biztosítsuk az adatok védelmét és a rendszer műk ködését Ennek elfogadtatása, és az elfogadás dokumentálása a fázis súlyponti tevékenysége, mivel később, a rendszer átadásakor az itt egyeztetett és elfogadott követelményrendszer lesz az átvétel alapja. Ugyancsak ebben a szakaszban határozzuk meg a rendszer biztonsági követelményeit is.

6.5.3.5 Vállalati rendszer tervezése A fázis lépésein itt is megfigyelhetjük az SDM elvek érvényesülését. A fázis előkészítése Nagyvonalú tervezés Adatstruktúra tervezése Folyamatok tervezése Ellenőrzések tervezése Tesztelési terv készítés Kész formára hozás (komplementírozás) A vállalati rendszerterv kiértékelése A "Számítógépes rendszer tervezése", a "Manuális eljárások ter- vezése", és az "Áttérés megtervezése" előkészítő terve Jelentéskészítés Szerződéskötés előkészítése Átnézés, döntés A lépések száma is mutatja, hogy ez a fejlesztés menetének egyik kulcsfázisa. Míg eddig sorosan dolgoztunk, ezen fázis végrehajtésa után több tevékenység is indulhat párhuzamosan. Ebben a fázisban a fő munkafolyamat a rendszer működésének megtervezése. A tulajdonképpeni logikai tervezés fázisának tekinthető ez az SDM szakasz. Figyeljük meg, hogy a szakaszon belül is megjelenik az SDM itcrratív megközelítési szemlélete : nagyvonalú tervezés, részletes tervezés,


100

komplementírozás. A tervezés az elveknek megfelelően top-down módon történik Ez egy igen hatékony védekezés a felhasználói igények lehetséges változásával szemben Az információrendszer adathalmazainak összeállítása és az információ-feldolgozási folyamatok megtervezése mellett ebben a fázisban kell megterveznünk azokat az ellenőrzési folyamatokat is, amelyek a rendszer megfelelő működésének ellenőrzésében ill. az esetleg jelentkező hibák felderítésében lesznek majd az üzemeltetők segítségére. Ezek az ellenőrzések, továbbá az ugyancsak ide tartozó, meghibásodás, ármakimaradás stb. esetére megtervezendő újraindítási eljárások a rendszer szempontjából redundanciát jelentenek. Annak eldöntése, hogy hol van az ésszerű határ a hibák elleni védelemben, kulcsfontosságú kérdés. Itt a ráfordísok és a felmerülő költségek alapos elemzése szükséges.

6.5.3.6 A számítógépes rendszer tervezése A logikai terv elkészülte és elfogadása után egymással párhuzamosan indulhat a következő két munka-fázis. Ezek egyike a rendszer fizikai - számítógépes - tervezése. A fázisban elvégzendő munkafolyamatok önmagukért beszélnek : A fázis előkészítése Nagyvonalú tervezés Hw/Sw konfiguráció meghatározása fájl konverziós programok megtervezése Rendszerteszt megtervezése A tervezés befejezése Üzemeltetési feltételek felvázolása A "Programtervezés" és a "Programozás munkafázisok előkészítő tervezése Jelentéskészítés Szerződéskötés előkészítése Átnézés Ebben a fázisban formába öntjük az előzőekben felvázolt adatszerkezeteket, információkat és folyamatokat. Ennek megfelelően elkészítjük a : adatbázis tervet, specifikáljuk a rendszer hardver környezetét és az alapszoftvert,

specifikáljuk a rendszer információkezelési folyamatait lefedő felhasználói- és segéd programokat, megtervezzük a karbantartási folyamatokat, és a rendszer ellenőrzési folyamatait, megtervezzük a rendszer tesztjét. A számítógépes rendszerterv elkészülte után gyakorlatilag két vonalon mehetünk tovább Miközben folynak a rendszer kivitelezési munkái a : programok tervezése programok készítése, programok tesztelése, adatbázis létrehozás, segéd- és vezérlő programok készítése, programmodulok összekapcsolása, tesztelése, addig elvégezhetjük a rendszer bevezetésével kapcsolatban felmerülő szervezői feladatokat Figyeljük meg, hogy ebben a fázisban találkozunk utoljára a szerződéskötés előkészítése" lépéssel. Innentől kezdve ugyanis a folyamat megállíthatatlan


101

6.5.3.7 Programok tervezése Ebben a munkafázisban alapvetően a programtervezőké a szó. Természetesen a projekt menedzsmentnek is megvannak a szokásos feladatai. A szakaszban végrehajtandó fontosabb feladatok tehát : Program tervezés előkészítése A programok modulstruktúrájának kialakítása Program teszt megtervezése Programfejlesztési terv készítése Forráskönyvtári elemek létrehozása Jelentéskészítés Átnézés A fázisban tehát elkészül valamennyi felhasználói- és segédprogram terve, illetve kidolgozásra kerülnek a tezsteléshez szükséges adatok. Ezt követően a tervek alapján végrehajtható a programok kódolása, az elké szült modulok és programok kipróbálása, tesztelése.

6.5.3.8

Manuális eljárások tervezése

Egyetlen számítógépes információrendszer sem tisztán számítógépes információfeldolgozásra épül. A feldolgozási folyamatok jelentős része manuális marad. Elég, ha csak az inputok előkészítésére (bizonylat kitöltés és kezelés), vagy az output bizonylatok expediálását nézzük. Ezeknek a manuális folyamatoknak a felvázolása már a vállalati rendszerterv készítése során megtörtént. Ebben a fázisban ezek fizikai tervezése, konkrét formába öntése történik. Elkészítjük a : bizonylat- (I/O) és a képernyő terveket, a bizonylatok leírását, a kitöltési-, rögzítési- és a kezelési utasításaikat, pontosítjuk azokat a manuális információkezelési folyamatokat, amelyek beépülnek a számítógépes feldolgozás rendszerébe, elkészítjük a rendszer képzési (oktatási) tervét. Ezeket a tevékenységeket az SDM az alábbi keretek között javasolja elvé- gezni - amelyen természetesen a hangolás segítségével a konkrét feladatnak ; megfelelően módosíthatunk - : A fázis indítása Manuális eljárások részletes tervezése I/O bizonylattervek, formanyomtatványok letisztázása Oktatási terv készítése Előkészület az átadásra Jelentéskészítés Átnézés

A manuális eljárások tervezése a számítógépes rendszer tervezésével együtt a rendszer fizikai tervezésének folymatát alkotja


102

6.5.3.9 Az áttérés megtervezése

Itt már nincsenek nyitott pontok, tisztázatlan kérdések. A rendszer teljes kiviteli terve elkészült, megkezdődött a kivitelezés. Ha csak valami komoly probléma nem vetődik fel, elkerülhetetlen a rendszer bevezetése. A bevezetésre u úgy kell előkészíteni a felhasználói környezetet, hogy kellő idő álljon rendelkezésre a betanuláshoz, de ne is teljen el sok idő a képzés és a tényleges bevezetés között. Az áttérés természetesen nem csak oktatást jelent. Számos egyéb tevékenységet is el kell végezni. Ebben a fázisban ezekre készülünk fel, tervezzük meg a teendőket, azok időrendjét. A szakasz főbb lépései : Az áttérés megtervezése előkészítése Az áttérés módjának megtervezése Bevezetés módjának meghatározása A tervezés, programozás és manuális eljárások koordinálása A bevezetés megtervezése Jelentéskészítés Átnézés

6.5.3.10

Programozás

A programozás munkafázisa viszonylag kevés szervezési-, szervezői feladatot tartalmaz A kivitelezés során a szervezők elsősorban - ha van ilyen - a programtervezőkkel tartanak kapcsolatot. Szerepük ebben a munkaszakaszban elsősorban konzultatív jellegű. A munka-fázis belső felépítése természetesen at is az általános SDM elvekhez igazodik : A programozás előkészítése Kódolás Program teszt A dokumentáció véglegesítése Rendszer teszt Átnézés Bár az elvégzendő feladat nyilvánvaló, és, ha a tervek jók, akkor szinte el sem lehet rontani, mégis komoly odafigyelést igényel a projekt a vezetés részé- ről. Különösen nagy, több programozót foglalkoztató ozat munkáknál lényeges a feladatok megfelelő szétosztása, a határidők figyelemmel kísérése, a tesztekés a dokumentáció megkövetelése.

6.5.3.11

A rendszer bevezetése

A rendszerfejlesztés egyik legkritikusabb tevékenysége az elkészült rendszer üzembe helyezése, átadása. A folyamat - a korábban tanultaknak megfelelően - legalább két lépcsőből: próbaüzemből és "éles" üzembe helyezésből áll. A rendszer bevezetése, vagy elutasítása egész eddigi munkák sikerét, vagy éppen sikertelenségét jelenti. Az SDM módszertan elveit, munkamódszereit a teljes fejlesztési folyamaton keresztül következetesen végrehajtva –hiszen éppen ezért találták ki - komoly esélyünk van a sikeres rendszer bevezetésre. A bevezetés főbb SDM lépései:


103

Bevezetés előkészítése Felkészülés az elfogadási tesztre Elfogadási teszt végrehajtása Dokumentáció átadása A rendszer átadása

6.5.3.12

Utólagos elemzés

A rendszer életciklusa a bevezetéssel nem ért véget, sőt tulajdonképpen most kezdődik az igazi élete. A rendszer fejlesztési folyamat szintén tartogat még egy tevékenység csoportot, amit néhány hónapos üzemelés után el kell végettiünk. Ez a rendszer utólagos elemzése. Ennek során azt vizsgáljuk, hogy itt már beüzemelt, a használók által ismert és rutinszerűen működtetett rendszer megfelel-e a kezdeti célkitűzésnek. Az utólagos elemzés során nem csak a szigorúan vett szolgáltatásokat és a rendszer működését, hanem a teljes fejlesztéis tevékenységünket is elemezzük. Ennek során például a becsült és a tényleges ráfordításokat összevetjük. Az objektív tényezők vizsgálata mellett igen nagy jelentősége van a rendszer szubjektív szempontok szerinti elemzésének is, így legelső sorban a felhasználói megelégedettség vizsgálatának. Az utólagos elemzés fontosabb munkafolyamatai : Az utólagos elemzés tervezése A projekt menetének elemzése A felhasználói megelégedettség elemzése Üzemeltetési hatékonyság elemzése A becsült- és a valódi költségek elemzése A rendszertervezés kiértékelése

6.5.4 Az SDM módszertan dokumentációs rendje Az SDM módszertan tárgyalásakor az eddigiek során különösebben ne érintettük a dokumentálás kérdéseit. Ugyanakkor minden munka-fázisban o szerepel a "jelentés-készítési" tevékenység, és az SDM általános elvei között is kiemelhető a dokumentálás szükségessége. Az SDM rendszerfejlesztési módszertan a dokumentációt nem külön munka fázisként kezeli, hanem a munka természetes részeként. Az, hogy e jegy keretei között kiemelten, külön fejezetben tárgyaljuk, éppen a fontosság hivatott hangsúlyozni. Az SDM módszertan szerint végzett fejlesztési munka minden aktivitásában benne foglaltatik az elvégzett munka dokumentálása. Így az egyes munka- fázisokon belül is folyamatosan készül a rendszer dokumentációja, amit egyes fázisok végén "formába öntünk". Ezekből az anyagokból dolgozik fejlesztő team, ezekből születnek a következő szerződések, felhasznál döntések. A munka megfelelő szakaszaiban természetesen ezeket a munka közi dokumentumokat felhasználva készítjük el a rendszer "kifelé menő d kumentumait is. Az SDM ezzel a módszerrel egyfelől a tevékenységközpontú fejlesztési munkát kívánja támogatni, másrészt minimálisra csökkenti a pa pírmunkát, miközben maximális hatékonyságot ér el. Ahhoz, hogy ez a módszer tényleg hatékony legyen, a dokumentálási munka ugyanolyan következetes véghezvitelére van szükség, mint azt a módszertan egyéb elveinek az érvényesítésénél láttuk. Az SDM nem {r elő kötelező érvényű ábrázolási technikákat, vagy egyéb szabványokat, csupán az általunk választott, - mondhatjuk -, hogy a projektre hangolt dokumentálási rend következetes véghezvitelét kéri. A dokumentálásnak igen lényeges szerepe van a rendszer fejlesztése során. Ezzel a kérdéssel még többször fogunk találkozni, de


104

itt is utalunk a minőségbiztosítás dokumentálási követelményeire Ennek bármilyen jó módszertan, vagy rendszer csakis akkor tud megfelelni, ha a munka során kellő hangsúlyt kapott a dokumentálás is A módszertan dokumentálási rendje a - egyébként más körülmények között is szokásos - két fő csoportra osztható. Ezek a: projekt dokumentáció és a rendszerdokumentáció.

6.5.4.1 Az SDM projekt dokumentáció A projekt dokumentáció célja, hogy minden, a projekt irányításhoz és az eredményes munkához szükséges, a projekt végrehajtása során, vagy azzal kapcsolatban keletkező, a munkát bármilyen irányban befolyásoló információ, információ hordozó, szerződés, emlékeztető, jegyzőkönyv, levelezés, esetleges szóbeli értekezések feljegyzése, ill. rögzített hang-, esetleg képanyaga, a projekt idő-, költség-, erőforrás-, stb. tervei felmérések, ötletbörzék dokumentumai, a team javaslatai, közbenső véleményezések, stb. gyűjtsünk, azok szükség esetén megfelelő formában rendelkezésre álljanak. A projekt dokumentáció kezelése, karbantartáas igen komoly és nagy jelentőségű feladat. Kezelése a projekt menedzsment felelőssége.

6.5.4.2 Az SDM rendszerdokumentáció A rendszerdokumentáció tartalmazza a rendszert leíró információkat. Bár mint említettük az SDM nem tartalmaz a dokumentáció formájára nézve el . írásokat, igen fontos, hogy a team kialakítsa azokat a szabályokat, amelye alapján a rendszerdokumentáció készülhet. A teamen belül ugyanis meg kell lennie az egységes szemléletnek, hiszen tagjai olykor együtt, máskor külön külön, esetleg csoportokra szakadva végzik a munkájukat, amiről mind egy mást és a projekt vezetését, mind pedig a felhasználót (döntési pontok) tájékoztatni kell. A rendszerdokumentáció a fejlesztés során folyamatosan "keletkezik". A munka egy bizonyos szakaszától kezdve (vállalati rendszertervezés) kezd a külvilág felé is igazán komoly jelentőséggel bírni. A folyamatosan keletkező dokumentumok gyűjtése az SDM-ben az ún. "kádak"-ban történik. Ebből tudja minden érdeklődő előszedni a számára éppen szükséges dokumentumot. Ezek felhasználásával történik a végső dokumentációk összeállítása is. A kádak rendszerének felhasználásával ez egyébként rendkívül nehéz, - és éppen ezért jól ritkán megvalósuló -, felad igen egyszerűen végezhető el, hiszen csak össze kell szerkeszteni az egy "kádak"-ból az ott lévő (és karbantartott!) leírásokat.

6.5.5 A módszertan értékelése Igen jól fedi le a rendszer életciklusát, így a teljes fejlesztési folyamatra használható módszert ad a fejlesztők kezébe. Elveivel, fázisainak egységes szerkezetével jól szolgálja a projekt vezetést, ugyanakkor kellőképpen rugalmas, az adott projekthez igazítható módszer.


105

Felépítése, dokumentálási előírásai áttekinthető, a karbantartást is támogató fejlesztést tesznek lehetővé. A módszertannal fejlesztett rendszer alkalmas az ISO 9000 szabványcsoport előírásai szerinti auditálás követelményeinek produkálására. A kettős szintű tervezés elvének eremnyeként a fejlesztő kockázata nagymértékben csökken, ugyanakkor a megbízó részéről nagyobb odafigyelést, a munkában aktívabb részvételt kíván meg, ami viszont a rendszer szempontjából kifejezetten előnyös. A fejlesztés átfutási ideje viszonylag hosszú lesz , mivel a fázisonkénti szerződéskötés mind a két fél részéről felkészülést igényel. Ez a "lassúság" okozta hátrány viszont a termék minőségében visszatérül.

6.6

Az SDM - PANDATA fejlesztési módszertan

1970 végén készült el az SDM (Pandata) (System Development Methodology rendszerfejlesztési módszertan) fejlesztési módszertan első változata, amelyet a PANDATA Szoftverház készített és fejleszt azóta is. A 70-es évek elején három holland és egy amerikai cég - a Nationale Nederlanden biztosító, az AKZO és a Holland Postai, Telefon- és Távíró Szolgálat, valamint a Gemini Computer System INC. - megalapította a PANDATA szoftverházat.Ennek a cégnek az első feladata egy olyan fejlesztési módszertan kidolgozása volt, amely tartalmazta a rendszer kifejlesztéséhez szükséges valamennyi tevékenység és lépés leírását, meghatározta a szükséges be- és kimenő információkat amelyek ezen fejlesztési lépések leírásához szükségesek, továbbá definiálta a követendő módszereket is. Az SDM (P) módszertan végső soron egy jól szerkesztett kézikönyv, amely a rendszerfejlesztés lépéseit, eszközeit, módszereit és termékeit összegyűjtve, azokat fázisonként egymáshoz rendelve ad segítséget a fejlesztési munka végrehajtására. Tulajdonképpen tehát egy check lista, amelyben kipipálhatjuk az elvégzett, illetve elvégzendő feladatokat.

6.6.1 Az SDM - PANDATA fejlesztési módszertan áltlános felépítése A módszertan, - hasonlóan a Hoskyns féle SDM-hez -, a rendszer teljes életciklusát lefedő, valamennyi fejlesztési fázist segítő komplex fejlesztési módszertan. A módszertan nem tartalmaz különleges technikákat, hanem az i mert fejlesztési eszközöket használja fel a célok elérése érdekében. Az SDM (PANDATA) módszertan tehát igazából véve egyfajta rendszerezése a rendszerfejlesztés folyamatának, és ezen rendszerezés keretében felöleli a rendszerfejlesztés általános folyamatát, tennivalóit és menedzselési módsze- reit. Igazából nem határoz meg elveket, de kimondott célja, hogy biztosítsa a projekt sikeres kimenetelét, költségek szinten tartását, és alapja legyen a minőségbiztosításnak. A módszertan strukturált fejlesztési metodika. Szemléletében mindenhol a struktútráltság, a modularitás jelentkezik. A módszertan leírása minden egyes fejlesztési szakaszra a tevékenységekhez használható módszerek "maximumát" adja meg. Az adott projekt, - méret, bonyolultság -, végrehajtása során ezekből a tevékenységekből választhatjuk ki azokat a tevékenységeket, amelyeket a munka érdekében fontosnak, vagy szükségesnek ítélünk meg. Ez a HOSKYNS féle SDM hangolási elvére hasonlító folyamat, de valójában attól mégis eltér. Ott ugyanis a módszertan egyes munkafázisait alakítottuk a projekt kívánalmainak megfelelően, míg itt, mintegy -, étlapból választunk ki eszközöket, módszereket a tevékenységek végrehajtásához


106

6.6.2 A módszertan lépései Az SDM (P) megismerése előtt meg kell ismerkednünk négy fogalommal, amelyeket a módszertan tevékenységeinek ismertetésénél használunk. Ezek : a tevékenység-leírások, a módszerek, a szükséges termékek és a háttérhivatkozások. Tevékenység-leírás: Valamennyi tevékenységhez tarozik egy leírás, ami megadja az adott tevékenység definícióját. Módszerek: Az egyes tevékenységhez tartozó, annak végrehajtása során elvégzendő feladatok. Termékek: A tevékenységek végrehajtásakor, egy-egy tevékenységhez kapcsolódó dokumentáció. Háttérhivatkozás: A projektet kidolgozó team tagjai számára készülő, belső dokumentáció. Az SDM (P) - mint azt már említettük -, a fejlesztés életciklusára épülő módszertan, amelyik az életciklust a következő hét lépcsőben adja meg : Definíciós tanulmány készítése, Előzetes tervezés, Részletes tervezés, Programok és emberi feladatok fejlesztése, Tesztelés, Adatkonverzió és rendszer implementálás, Üzemeltetés és rendszerkövetés. A továbbiakban az SDM (P) fázisait ezen életciklus-lépcsőkön keresztül tárgyaljuk. A módszertan leírása rendkívül részletesen tárgyalják az egyes fázisok tevékenységeit, lépéseit, valamint a lépésekhez kapcsolódó termékeket és háttérinformációkat. Ettől a részletezettségtől már csak a jegyzet terjedelmi korlátai miatt is el kell tekintenünk. Másrészt a lépések termékei tulajdonképpen a fázis végtermékének részei, fejezetei, így nem csorbul a módszer, ha a lépésekhez külön nem adjuk meg a "termék-" és "háttérhivatkozás" listát.

6.6.2.1 Definíciós tanulmány készítése A definíciós tanulmány fejlesztési szakasz tevékenységei : l. Probléma meghatározás 2. Adatgyűjtés a meglévő módszerekről és eljárásokról 3. A meglevő módszerek és eljárások elemzése 4. A rendszercélok és teljesítménykritériumok kidolgozása 5. Az erőforrások, korlátok, feltevések, feloldandó döntési elemek meghatározása 6. A rendszerkimenetek, bemenetek és a fő funkciók elemzése 7. A rendszerrel szemben támasztott követelmények és a lehetséges megközelitések meghatározása. 8. A rendszer-megközelités értékelése, kiválasztása 9. Az implementálási, konverziós és átvételi követelmények meghatározása 10. A javasolt rendszer általános tervének és költség/haszon elemzésé-nek elkészítése 11.A definíciós tanulmány elkészítése A fázis ajánlott tevékenységi hálója


107

A szakaszban alkalmazható módszerek : A szakasz a rendszerfejlesztés klasszikus rendszer megismerési, elemzési, koncepció kialakítási szakasza. Az alkalmazandó módszerek ennek megfelelőek : a helyzetfelmérés általánosan ismert módszerei, a helyzetelemzés módszerei, költség vizsgálati módszerek, rendszerek összehasonlítására alkalmas elemzési módsze-rek, a projekt tervezés eszközei, egyéb matematikai eszközök, stb. A fejlesztési szakasz termékei és háttér-információk : A szakasz végterméke az itt "Definíciós tanulmány"-nak nevezett rendszerkoncepció. A módszertan kézikönyve a termékeket ennél sokkal részletesebben határozza meg, nevezetesen : minden lépéshez termékek és háttérinformációk tömegét írja elő. Ezek azonban végső soron az utolsó lépésben a jelzett végtermékké állnak össze. Ezért, - valamint azon ok miatt, hogy korábbi tanulmányaik során a rendszer fejlesztés alapvető dokumentumainak felépítésével már megismerkedtek -, nem tartjuk szükségesnek az újbóli ismétlést. Azok számára, akik érdeklődnek a részletek iránt ajánljuk az irodalomjegyzékben megadott művek tanulmányozását. A további tevékenységeknél a módszerek és termékek ismertetésétől eltekintünk mivel azok a fázis felépítéséből, az ott előírt feladatokból egyértelműen adódnak A módszertan kézikönyve teljes részletességgel tárgyalja ezeket.

6.6.2.2 Előzetes tervezés A fejlesztési szakasz tevékenységei : 1. A rendszer kifejlesztési követelményeinek specifikálása 2. Az általános rendszerkörnyezet definiálása 3. Az alrendszerek leírása 4. Az alrendszerek be-, kimeneti és interfész követelményeinek fejlesztése 5. A rendszer-, illetve alrendszer-folyamatábrák elkészítése 6. A folyamatleírások elkészítése 7. Rendszervédelmi követelmények előírása 8. Az ergonómiai problémák területeinek azonosítása 9. A logikai Ab-stuktíua megtervezése, elérési módszerek definiálása 10. Az adatátviteli követelmények előírása 11.A HW-konfiguráció megadása 12.A rendszer SW megadása 13.A fejlesztési és az implementálási terv elkészítése 14. Az előzetes tervezés jelentésének elkészítése 14. Az előzetes tervezés jelentésének elkészítése. Ez a szakasz leginkább a logikai rendszertervezés fázisának felel meg.


108

A fázis ajánlott tevékenységi hálója:

6.6.2.3 Részletes tervezés A fejlesztési szakasz tevékenységei : 1. Emberi eljárások tervezése 2. Kézi űrlapok és számítógépes i/o interfészek tervezése 3. Fizikai adatbázis tervezése 4. Főbb alrendszervédelmi paraméterek tervezése 5. Az alrendszerek programjainak definiálása 6. Logikai folyamatábrák és táblázatok fejlesztése 7. Segédprogramok és közös rutinok specifikálása 8. Alrendszer tesztelési terv kidolgozása 9. A részletes tervezés jelentésének összeállítása A munkafázis gyakorlatilag az információrendszer fizikai tervezésének szakasza. A fázis ajánlott tevékenységi hálója

6.6.2.4 A programok is emberi feladatok tervezése A fcjlesztési szakasz tevékenységei : 1. Munkaköri leírások összeállítása 2. A személyi és környezeti követelmények meghatározása 3. Részletes program-folyamatábrák elkészítése 4. A programok kódolása 5. A forrásnyelvi programok előkészítése, fordítás 6. A programok beállítási adatainak előkészítése 7. Programok beállítása 8. A programok és emberi feladatok tervezése jelentésének összeállítása A szakaszban tervezési és kivitelezési feladatok egyaránt jelen vannak. A programok tervezésvel párhuzamosan folyik a rendszer környezetének ponmsítása is. A fázis végére gyakorlatilag működő, tesztelt programokat kell kapnunk, rrgyanakkor tisztában vagyunk a rendszert működtető egységekkel és azok feladataival is. A fázis ajánlott tevékenységi hálója:


109

6.6.2.5 Tesztelés A fejlesztési szakasz tevékenységei : 1. A részletes tesztelési terv és az eljárások fejlesztése 2. Telephely előkészítése, eszközök installálása 3. A futtatási környezet meghatározása 4. A tanfolyamok, segédletek és az emberi eljárások tesztelése 5. A tesztadatbázis- és teszt-tranzakciós adatállományok felépítése 6. Az alrendszerek-, illetve a rendszer tesztelése 7. Átvételi teszt lefolytatása 8. A teszteredmény jelentés elkészítése A fázis ajánlott tevékenységi hálója:

6.6.2.6 Adatkonverzió és implementálás A fejlesztési szakasz tevékenységei : 1. A konverzió és az implementálás vezértervének és ütemezésének megállapítása 2. Az üzemeltető személyzet kiképzése (Hw, Sw és az új rendszer) 3. Az új rendszer mutatóinak teljessé tétele 4. Adatkonverzió . 5. A vezetőség figyelmének az új rendszerre irányítása 6. Az új rendszer felhasználói személyzete kijelölése, kiképzése 7. A követő team kiképzése 8. A rendszer átadása és a fázis dokumentumainak elkészítése A fázis ajánlott tevékenységi hálója:

A fejlesztési munka utolsó fázisa, amelyben az elkészült rendszer használatának betanítása, a rendszer próbaüzeme és üzembe állítása zajlik. Felhívnánk a figyelmet a 4. pontra. A módszer külön kiemeli a régi rendszer adatainak átvételét, az új rendszerhez illesztés fontosságát.


110

6.6.2.7 Üzemeltetés és rendszerkövetés A szakasz tevékenységei : 1. A kritikus mutatók kidolgozása és figyelése 2. A követés szervezési- és programozási feladatainak ütemezése 3. A számítógép üzemeltetésének ütemezése 4. A futási hibák megelőzése és gondoskodás a futás helyreállításár 5. A katasztrófa felügyelet és a biztonsági tervek figyelemmel kísérése 6. Módosítási kérelmek feldolgozása és a dokumentáció szétosztása 7. További képzés nyújtása 8. A rendszer állapotának felülvizsgálása és az üzemeltetés és köve éves tervének összeállítása A fázis ajánlott tevékenységi hálója:

Az SDM (P) utolsó szakasz a tárgyalt módszertanok között egyedülállónak számít. A módszertanok ezzel a szakasszal általában nem foglalkoznak kellő súllyal. Az SDM (P) ezzel szemben azt vallja, hogy a rendszer élete akkor ér véget, amikor egy újabb fejlszetés eredményeként új rendszer áll munkába. Ezt a szemléletet mutatja a Pandata féle SDM életciklus ábrája:


111

Definíciós tanulmány

Tesztelés

Adatkonverzió és implementálás

Programok és emberi feladatok tervezése

Előzetes tervezés

Üzemeltetés és rendszerkövetés Részletes tervezés

6.6.3 A módszertan értékelése A módszertan legnagyobb előnye, hogy a rendszer teljes életciklusát lefedi. E tekintetben, legalábbis a tárgyaltak között -, egyedülálló. Hangsúlyozza a projekt irányításának szerepét, és ezt eszközeivel, alapelveivel is támogatja. Igen alaposan határozza meg, - szinte mozzanatokra bontva -, a fejlesztés, során elvégzendő feladatokat. Hasonló részletezettséggel írja elő a rendszerfejlesztési munka termékeit, ezek összetételét. Igen figyelemre méltó, hogy a, - ma már szinte kötelező, de létrejöttekor még nem általános -, minőségel- lenőrzést kiemelt célként kezeli. Legnagyobb hátrányaként a nehézkes dokumentálási szisztémáját lehet említeni.

6.7 Egyéb strukturált módszertanok 6.7.1 SADT- Structured Analysis and Design Technique 1977 SofTech Incorporation (D. Ross) Az objektumorientált elemeket is tartalmazó módszertan lépésről lépésre finomítja a rendszert, sajátos, többdimenziós és többoldalú egyeztetéseken keresztül. A fejlesztési munka során a rendszerszervező actigrammok és datagrammok segítségével dolgozik. Az actigrammok az adatfolyam diagramhoz hasonlóan a rendszer funkciói és adatai közötti kapcsolatokat és áramlást mutatja, a datagrammok a rendszer adatait, és az azokat ért hatásokat ábrázolják.


112

Az elemzési és tervezési fázisban használják. Technika: elemző, grafikus dokumentálási technikák: actigram, datagram, Petri hálók. Funkcióorientáltság, illetve objektumorientáltság jellemzi.

6.7.2 DARTS – Design Method (Adatfolyamorientált tervezési feldolgozásokhoz)

for Real-Time Systems módszetan valós idejű

(Hassan Gomaa) Valós idejű feldolgozásoknál a rendszertervezőnek nehezebb feladata van, hiszen a korábban tárgyaltakon kívül még meg kell oldania a következő problémákat is: az adatok pontosságának megadott intervallumon belül kell maradnia adatok fogadásának, értelmezésének és elemzésének a megadott időintervallumon belül végre kell hajtódnia adatbázis karbantartást megfelelő időben el kell végezni a vezérlőműveletek végrehajtását semmi nem akadályozhatja. Felmerülő problémák: megszakítások kezelése multitasking és multiprocessing rendszerek párhuzamos alkalmazása kommunikációs és szinkronizációs problémák hardverproblémák megfelelő kezelése.

6.7.3 DOMINO: Integrált fejlesztési módszertan Siemens-Nixdorf AG, 1988 A teljes életciklust lefedő módszertan kifejlesztésénél a fejlesztők messzemenőkig fi gyelembe vették a módszertanokra vonatkozó standardizálási törekvéseket, pl: EROMETHOD. A DOMINO fázismodell eredményorientált, strukturáltfejlesztési módszertan, amelynél az egyes fázisok, a fázisok által szolgáltatott eredmények és a fejlesztés kritikus pontjai egyértelműen definiáltak. A módszertan az SADT technikáját veszi alapul, és különös gondot fordít a fejlesztés teljes ciklusában a szoftver minőségére. A mérföldkövek nemcsak a munkafázisokat határozzák meg, hanem egyben lehetővé tesznek egy hatékony projektirányítást és - ellenőrzést is. A DOMINO alapvetően három fázisban: • probléma-definiálás • elemzés, • technikai kivitelezés és a bevezetés javasolja a fejlesztési munkát végezni, de kitér a rendszerátadás és felügyeleti tevékenységekre is.

6.7.4 EuroMethod Egységes módszertan Európai fejlesztési projektekhez. Objektumorientált módszertan. (1994) Az EuroMethod kidolgozásának célja olyan nemzetközi, több országot átfogó, elsősorban az Európai Unió közös projektjeihez hatékonyan alkalmazható módszertan kidolgozása, amely


113

információrendszerek fejlesztésére vonatkozó projektek munka-módszerének és eszközeinek meghatározását írja elő. Az EuroMethod egy módszertani keretrendszer, az Európai Közösség tagállamai részére javasolt, a közpénzek felhasználásának olyan eljárás-rendje, amely az:  információrendszerek elemzésének  fejlesztésének, tervezésének  karbantartásának és  továbbfejlesztésének támogatásával segíti  a projektirányítást  a projekttervezést  az erőforrások beszerzését. Az EuroMethod, vagyis egy egységes módszertan és szimbólumrendszer kidolgozását az Európai Unió Tanácsa 1994-ben határozta el azzal a céllal, hogy a tagországok közös projektjeiben a fejlesztők, a nyelvi nehézségeket is könnyebben áthidalva legyenek képesek hatékony rendszerfejlesztésre. A módszertan alapját több, a gyakorlatban már sikeresen alkalmazott módszertanok képezték így az SSADM (1990, Anglia), a MERISE (francia), a holland SDM (Pandata), a német Vorgesehensmodell, a spanyol MEIN valamint kulcsmódszertanként az IEM információrendszer-fejlesztési módszertan (1990). Az EuroMethod alapelvei: az IR korszerűsítésére való törekvés termékorientáltság döntésközpontúság környezethez való alkalmazkodás determinizmus (determinálható kiinduló és végállapot) módszertani javaslat megbízó és fejlesztő kapcsolatának tervezése Az EuroMethod alkalmazásának előnyei kölcsönös megértés a megbízó/felhasználó és a fejlesztő közötti kommunikációban a nyitott nemzetközi piacon különböző fejlesztési módszerek közötti harmonizáció a fejlesztési módszereknek az adott problémához illesztése -munkaerőáramlás elősegítése Európában, nemzetközi projektek, konzorciumok létrejöttének segítése az európai gazdaság hatékonyságának, versenypozíciójának javítása egységesítésre való törekvés a közösen végezhető fejlesztés érdekében Az EuroMethod fejlesztésében az Európai Bizottság megbízásából számos európai szoftvercég vett részt.

6.8 Az SSADM rendszerfejlesztési módszertan Az SSADM a módszertan angol nevének (Structured Systems Analysis and Design Method) kezdő betűiből képzett betűszó. A módszertan neve magyarrul : Strukturált Rendszerelemzési és Tervezési Módszer.


114

Az SSADM az egyik legfiatalabb komplex rendszerfejlesztési módszertan. Első változatát az Egyesült Királyság egyik kormányzati szervének (Központi Számítástechnikai és Távközlési Ügynökség CCTA) megrendelésére az angol LBMS cég 1980-ban dolgozta ki. A javaslatot elfogadták és 1983-tól a kormányzati projektekben kötelezővé tették az alkalmazását. Az 1980-as évek végétől nyílttá vált az SSADM, így megindulhatott a módszertan nemzetközi alkalmazása. Jelenlegi, sorrendben a negyedik verziója 1990 júniusában jelent meg, amelyhez azóta több gyártó is készített számítógépes támogató eszközt, illetve CASE terméket. Ez a fajta támogatottság természetesen tovább növeli az SSADM felhasználóinak körét. Tárgyalásának számunkra különös jelentőséget ad, hogy a Miniszterelnöki Hivatal mellett működő Informatikai Tárcaközi Bizottság 1993-ban közzétett I. számú ajánlásában egységesen javasolja alkalmazni a közigazgatás informatikai fejlesztéseinél. A közigazgatás mellett előszeretettel alkalmazzák olyan fejlesztéseknél amelyeknél a felépítésből termékszerkeztéből adódóan nagyban hozzájárulhat a minőség javításához a koordináció erősítéséhez így végül a teljes beruházás sikeréhez

6.8.1 A módszertan célja, rendszerszemlélete Az információs rendszerek fejlesztésénél a különböző feladatok, környezeti eltérések ellenére is rendre hasonló problémákat kell megoldanunk. Ezeknek a problematikus pontoknak a kezelése nagyban befolyásolja egy informatikai beruházás sikerét. Attól függően, hogy a különböző problémák megoldásakor azok között milyen sorrendiséget állítunk fel fontosságuk szempontjából, beszélhetünk a minőségre ható tényezők prioritásáról. A különböző módszertanok természetesen megegyeznek abban, hogy célként a fejlesztendő rendszerrel szembeni felhasználói elégedettség elérését tűzik ki. Abban azonban már koránt sincs egyetértés a módszertanok között, hogy ennek elérése érdekében hogyan csoportosítsák erőforrásaikat, milyen szempontok érvényesítése kapjon előnyt más szempontok rovására. Elsőgként meg kell jegyeznünk, hogy az SSADM módszertan legkiemeltebb célja a fejlesztendő rendszer minőségének, a nem megfelelőség kiküszöbölésánek biztosítása. Ennek érdekében határozza meg lépéseit és technikáit, csoportosítja erőforrásait. Ennek érdekében történt a módszertan elveinek, fontosabb célkitűzéseinek kialalkítása is.

6.8.1.1 A felhasználói igények maradéktalan kielégítése Minden projekt akkor éri el a célját, ha a megbízó elégedett az eredménnyel. I Ennek természetesen nemcsak a munka legvégén szabad kiderülnie, hanem lehetőséget kell biztosítani a későbbi felhasználónak arra, hogy már a tervezés folyamán meggyőződhessen arról, hogy a munka az ő kívánságai szerinti irányba halad-e. Erre akkor van lehetősége, ha a fejlesztési munkába a lehető legjobban be van vonva. Az SSADM az elemzés és fejlesztés szakaszaiban a felhasználó teljes szervezetének bevonását igényli olyan módon, hogy a fejIcsztő team a megbízóval együtt készíti el a jelenlegi rendszer elemzését, a kialakítandó rendszerre vonatkozó követelményjegyzék összeállítását és prototipustechnikák segítségével magát a rendszertervezést is. A felhasználóval való kommunikációhoz kerültek kidolgozásra az ún. diagramos technikák, amelyek könnyen elsajátítható olvasási - ábrázolási módszert adnak a fejlesztők kezébe. Ezeknek, és a nem diagramos technikáknak felhasználásával készülnek el az egyes lépések, szakaszok végén az ún. t mékek. Az ilyen, a felhasználóval együtt kialakított termékek minden szakasz végén minőségi bevizsgáláson esnek át. Ezen részt kell vegyenek a fejlesztő a


115

megbízó és ISO 9001 szerinti minősítés esetén egy független minőség gá1ó képviselői. A következő szakasz elindítására csak a megfelelő termék elérése után van mód. Végső soron azzal, hogy az SSADM a végső termék, - átadott információ rendszer -, elérését több résztermék megfelelő minőségben való elkészítés. hez köti, csökkenti a rendszerfejlesztés bizonytalansági kockázatát. Ez a te: mékközpontúság azt jelenti, hogy az iterativ, - a fejlesztendő rendszert pontosabban leíró -, termékek segítségével a megbízó az általa elképzelt rendszer felé való haladást mindvégig könnyen ellenőrizni tudja, ha eltérést tapasztal, a fejlesztés irányát korrigálhatja.

6.8.1.2 A minőség biztosítása A kialakítandó rendszer minősége növelhető, ha a hibákat korán azonositani tudjuk. Ezt a fent leírt módon, a felhasználóknak a fejlesztésbe való bevoná sával tudjuk elérni. A szakaszok végén megtartandó minőségi szemlék küld nösen nagy jelentőséget kapnak a módszertanban. Erre a jobb minőségbiz tosítás elérése és az ISO 9001 szabvány bevezetése miatt van szükség. A sza kasz végén előállított termék minőségének megállapítása általában a termék_ leíró technikák és a termékre vonatkozó követelményjegyzék összevetésé jelenti, amelyen az összes, a minőségért felelős szervezet képviselőjének rés kell venni. Az SSADM módszertan kialakítása felépítése támogatja a minőségbiztosítási szabvány bevezetését, amelyre ma már egyre több esetben szükség van, pl. @Ay későbbi auditálhatóság biztosítása érdekében. Megjegyzésként ide kívánkozik hogy erre később beszállítóként is szüksége lehet a megbízónak, ezért az auditálhatóság kérdését az információs rendszerstratégia részeként kell kezelni

6.8.1.3 A határidők betartása Egy projekt sikeres teljesítésének lényeges kérdése az, hogy a beruházás határidőre elkészüle. Ennek biztosítása nemcsak az alkalmazott módszertantól, hanem a projektvezetés és ellenőrzés eszközeitől is függ. Az SSADM hierarchikusű felépítése és a már bemutatott termékközpontúság teszi lehetővé, hogy az elemi szintű feladatokig lebontva mindig tudjuk: mit, mikor és hogyan kell előállítanunk. Ennek segítségével a projektvezetés a projekt indításakor meg tudja határozni a projekt időtervét és ki tudja dolgozni annak ellenőrzési technikáját. A projekt előrehaladásának ellenőrzési pontjai általában az . elkészült termékek. Bár az SSADM mellett tetszőleges projektvezetési módszer alkalmazható, kifejezetten az SSADM projektek támogatására dolgoztak ki egy PRINCE nevű projektvezetési módszertant. Ezt külön kézikönyvek írják le, ezzel e könyv keretében nem foglalkozunk.

6.8.1.4 Beszállítótól való függés csökkentése Főleg a rendszer későbbi életciklusaiban (pl. üzemeltetés során), de a fejlesztés alatt is kialakulhat olyan helyzet, hogy a munkát elkezdő cég nélkülözhetetlenné válik azáltal, hogy rajta kívül senki sem érti a rendszer működését, vagy nem tudja folytatni a fejlesztést. Természetesen a megbízó ilyen esetekben kiszolgáltatottá válik a külső cég felé, amely az információ, - mint stratégiai erőforrás -, feldolgozása esetében különösen jelentős hátrány lehet számára. A megbízó elemi érdeke tehát az, hogy ilyen függőség ne is tudjon kialakulni. Lássuk először azt, milyen körülmények vezethetnek az ilyen kiszolgáltatottság kialakulásához. Az legnagyobb veszélyforrás, ha a szervező nem egy bevizsgált módszertannal dolgozik. Az ilyen esetekben általában már a feladat megfogalmazása is hiányos, mivel hiányzik az a módszertani kontroll, amellyel az anomáliák, meghatározatlanságok kideríthetők lennének.


116

A projektvezetésben a minőségbiztosítás szempontjai háttérbe szorulnak a pillanatnyi érdekkel szemben. Még a legalapvetőbb dokumentációk is hiányoznak, így a projekt ,, menetét sem lehet mérni, nemhogy a minőséget biztosítani. Bármely módszertan alkalmazása a felületes szemlélő számára csak idő- és energiapocséklásnak tűnhet, mivel kivétel nélkül valamennyi igen nagy súlyt '; fektet a megfelelő dokumentálásra, így igen sok anyagot kell előállítani. Arról azonban elfeledkeznek, hogy a szoftver terméktulajdonságaiból adódóan i csak ilyen módon lehet biztosítani a fentebb leírt célok megvalósulását. Az üzemeltetés szakaszában a függőség az ilyen módon készült rendszereknél már természetszerűen alakul ki, ami azt jelenti, hogy bármely hiba elhárításához, vagy módosítás végrehajtásához csak az eredeti gyártó illetve sokszor csak annak egyik alkalmazottja, programozója jöhet szóba. A megoldás ezek után kézenfekvő: a projekt végrehajtása során csak valamely kipróbált módszertant szabad alkalmazni, annak leírásait mindig betartva. (Ezt az ISO 9001 szabvány elő is írja.) Ezen követelmények betartása illetve betartatása azonban egyértelműen a megbízó kötelessége. Mit kínál az SSADM? Mint szabványos módszertan, biztosítja egyrészről a szállítók összevetésének lehetőségét és így a közöttük való választást. A projekt közben lehetőség van más szállító bevonására, mivel a szabványosított módszertan nyújtotta nyitott kommunikáción keresztül az új beszállító hamar be tud kapcsolódni a munkába. Az üzemeltetés során a már előállított rendszerdokumentáció segítségével akár egy másik cég is viszonylag könnyen megismerkedhet a rendszer működésével így azt karbantartani, ill. módosítani is képes lehet. Ezzel természetesen megszűnik a beszállítónak való kiszolgáltatottság és könnyen belátható, hogy a dokumentációs szabvány által megnövelhető a rendszer élettartama.

6.8.2 Az SSADM módszertan alapelvei, jellemzői Az SSADM un. adatorientált tervezést megvalósító módszertan. Ellentétben a/. eddig tárgyalt módszertanokkal nem követi a rendszer teljes életciklusát, annak kezdetére és a kivitelezés utáni életére vonatkozóan nem tartalmaz előírásokat A módszertan fontosabb jellemzői : adatvezéreltség, struktúráltság, logikai- és fizikai modell szétválasztása a top-down és a bottom-up technika ötvözése öndukumentálás

6.8.2.1 Adatvezérelt Egy rendszer életciklusa alatt az adatok szerkezete lényegesen kevesebbet változik, mint az adatokat feldolgozó eljárások. Ebből adódóan a rendszer alapjának az adatszerkezet tekinthető. (A jól megszerkesztett adatszerkezetből ún. "adatbányászattal" tulajdonképpen minden, a rendszert leíró információ kinyerhető.) Az SSADM is ezt használja ki, amikor a rendszeranalízist és a tervezést is az adatoktól kiindulva viszi végbe. A projekt egészen korai szakaszától folyamatosan finomítva jut el a fejlesztett rendszer adatszerkezetéig, amelyhez igazítja a rendszer egyéb folyamatait.


117

6.8.2.2 Felürül lefelé is alulról felfelé megközelítés A rendszer elemzése és a tervezés korai szakaszai a felülről lefelé (top-down), való megközelités jegyében történnek, míg a logikai tervezés szakaszában ill. a fizikai tervezés során megjelennek az alulról felfelé(bottom-up) történő tervezési módszerek. A top-down módszerek az analitikus megközelités eszközei, míg a bottom-up módszerek a szintetikus tervezést segítik. Végül a két úton nyert információ összevetésével születik meg az informáci- ós rendszer terve.

6.8.2.3 Logikai és fizikai tervezési lépések különválasztása Az SSADM-ben először a hardver ill. szoftverválasztástól függetlenül a rend-; szer logikai tervezését kell végrehajtani, amelyet így a tervezés e szakaszaiban még szükségtelen kényszerfeltételek beépítése nélkül lehet elvégezni. Az így kialakított logikai rendszerterv viszonylag nagy platformfüggetlenséget, biztosít a megvalósításban. Ennek előnyei nemcsak a tervezésnél, de a ké- sőbbi esetleges bővitésből adódó hardver- vagy szoftverplatform váltásnál is; jelentkeznek, mert az így kialakított rendszerterv könnyű adoptálhatóságot biztosít. A rendszer három nézetű modellje További előnyt jelent az, hogy megkönnyíti a kommunikációt az olyan fel- használókkal, akik járatlanok a számítástechnikában, hiszen e szakterület, fogalmait mellőzi.

6.8.2.4 Strukturáltság Felépítésében három nagyobb rész különíthető el, amelynek segítségével mintegy "receptként" előírja a szervező számára, mit, mikor és hogyan kell tennie. (24. ábra) Az SSADM termékleírásai megmondják, milyen technikákat tartalmazzanak, milyen tartalommal kell bírjanak az egyes lépésekben állított termékek, technikai része azt mondja hogyan kell az egyes termékeket előllítani míg strukturális résre az elvégzendő tevékenységek egymásutániságával időbeliségével foglalkozik.

6.8.2.5 A rendszer háromnézetű modellje Egy bonyolult tárgy, objektum leirásához gyakran nem elegendő annak egy nézőpontból való vizsgálata. Előfordul, hogy egy bizonyos nézetben elő sem tűnnek a tárgy nagyon fontos tulajdonságai, vagy ha láthatók is, más tulajdonságok mellett az alkalmazott nézetben nem tudnak érvényesülni. Ilyenkor a tárgyról több szempont szerinti külön felvételeket készítünk, amelyek együttesen adják vissza a tárgy valódi képét. (Ilyen megoldás pl. a térbeli tárgyak vetületi, műszaki ábrázolása. A felülnézet, oldalnézetek és az esetleg szükséges metszetek együttesen lesznek csak elegendők a tárgy rekonstruálá Az információs rendszerek sokkal bonyolultabbak mint egy gépészeti tárgy. I Természetes, hogy az ilyen rendszerek leírása sem valósítható meg csupán egyetlen kép, ábra segítségével. (Elegendő csak arra gondolnunk, hogy maga a mérés is igen sok problémát rejt, hiszen a rendszer elemei humán elemek, így a rendszerről vallott nézetük a rendszerben elfoglalt helyüktől sokban függ. Ilyen módon minden megkérdezett valószínűleg egy kicsit másként látja ugyanazt a rendszert.) Az alkalmazott módszertannak meg kell határoznia azokat a nézeteket, szempontokat amelyeket fel kell vennünk és egymással össze kell vetnünk azért, hogy a vizsgált rendszert pontosan megismerhessük ill. leírhassuk. Az SSADM a következő három "dimenziót" határozza meg: információk,


118

funkciók és idő. Mindegyik nézet kezelése a technikák révén valósul meg. Mindegyik technika hozzárendelhető valamelyik dimenzióhoz, amelynek mentén e rendszert leírja. A módszertan szerkezete biztosítja a technikák közötti összhangot. megteremtve ezzel a technikák szintéziséből a rendszer képét. Néhány dia az SSADM felépítéséről: Informatikai stratégia tervezése Megvalósíthatósági tanulmányok

Logikai rendszertervezés

Fizikai rendszertervezés

Project irányítás

SSADM

Helyzetfelmérés és elemzés

Kivitelezés, programok készítése

Tesztelés Üzembe helyezés Üzemeltetés

költség

Kockázat és költség

idő


119

Az SSADM szerkezete Modulok Szakaszok Lépések Feladatok

FS S S A D M

Megvalósíthat ósági elemzés

RA Követelmény elemzés RS Követelmény specifikáció LS

Logikai rendsz. specifikáció

rendszer PD Fizikai tervezés

0 Megvalósíthatóság eldöntése

010 020 030

helyzet 1 Jelenlegi vizsgálata

2

Rendszerszervezési változat kiválasztása

3 Követelmények meghatározása 4 Rendszertechnikai változat kiválasztása 5 Logikai rendszertervezés

6 Fizikai rendszertervezés

210 220 230


120

0. Megvalósíthatóság eldöntése

0. szakasz tervei Projekt dokumentáció 020

Projekt és a rendszerelemzés kiterjedése Problémamegfogalmazás

A PROBLÉMA MEGFOGALMAZÁSA

Megvalósíthatósági tanulmány A megvalósíthatósági tanul mány összeállítása

Akció terv

•A jelenlegi helyzet vázlatos leírása •Az igényelt környezet vázlatos leírása •Követelményjegyzék •Felhasználójegyzék

030

MEGVALÓSÍTHATÓSÁGI ALTERNATÍVÁK KIDOLGOZÁSA Megvalósíthatósági alternatívák

0. Megvalósíthatóság

010

040

Előkészület

Megvalósítható sági tanulmány

020

Probléma meghatározás

030

Megvalósítható vált. kialakítása


010. lépés: Felkészülés a megvalósíthatósági elemzésre Feladat

Leírás

011

A

012

A vizsgálat alá vont működési terület felmérése, a vizsgálati módszerek meghatározása. Az elemzéshez szükséges szakmai szerepkörök meghatározása. Megegyezés a vizsgálat határaiban a projektvezetőség szintjén.

013

Tevékenység háló, Tevékenység leírások, Termékfolyam ábrák, Termékfelbomlási szerkezetek és Termékleírások elkészítése az elemzés SSADM elemeiről. Megegyezés a fentiekről a projekt tanáccsal.

projektalapító okirat és más háttérdokumentumok tartalmának felülvizsgálata. Az elemzés terjedelmének és bonyolultságának felbecslése. Kontextusábra, jelenlegi fizikai adatfolyam-ábra (1. szintű) és áttekintő logikai adatszerkezet létrehozása. A rendszer követelményeinek azonosítása és meghatározása a követelményjegyzékben Jelentés minden olyan problémáról és ellentmondásról, ami a akadályozhatja az elemzés tervezett menetét.

020. lépés: A probléma meghatározása Feladat

Leírás

021

A

022

A jelenlegi környezet működésének vizsgálata. A létező első szintű adatfolyam ábra kiegészíthető második szintekkel, ahol a folyamatok kritikusak, bonyolultak vagy homályosak.

023

A lehetséges felhasználók felsorolása a felhasználójegyzékbe.

024

Az új rendszerbeli funkciók és adatok azonosítása a felhasználók segítségével. Az azonosított követelmények rögzítése a követelményjegyzékben és az igényelt környezet modelljeiben. Nem-funkcionális követelmények azonosítása.

025

Problémamegfogalmazás előállítása, felbecsülve az egyes követelmények működési célokhoz viszonyított prioritását.

026

A problémamegfogalmazás elfogadtatása a projektvezetéssel.

működési célok megvalósításához szükséges tevékenységek és információk azonosítása. Első szintű adatfolyam ábra rajzolása az igényelt környezetre. Az áttekintő logikai adatszerkezet kiegészítése az igényelt rendszer nagyobb egyedeivel.

121


122

1. Jelenlegi helyzet vizsgálata 110

120

Elemzés kereteinek megteremtése

Jelenlegi követelmények vizsg.

130 Jelenlegi folyamatok vizsg.

140 Jelenlegi adatok vizsg.

150 Jelenlegi rendszer logikája

160 A vizsgálat eredményeinek összeállítása

2. Rendszerszervezési változat kiválasztása

210 Rendszerszervezési alternatíva kidolgozása

220 Rendszerszervezési alternatíva kiválasztása


123

3. Követelmények meghatározása 310 Igényelt eljárások meghatározása

330 A rendszer funkcióinak előállítása

320 Igényelt adatmodell kifejlesztése

340

360

Igényelt adatmodell kibővítése

Feldolgozási folyamatok kifejlesztése

350

370

Specifikációs prototípusok kialakítása

Rendszer-célok véglegesítése

380 A követelményspecifikáció összeállítása

Információ gyûjtés / szolgáltatás és irányítás 3. szakasz irányítása

3. szakasz tervei Adatjegyzék Logikai adatmodell Logikai adattárentitás megfeleltetés Felhasználójegyzé k Szervezeti Követelményjegyzék tevékenység Kiválasztott rendszerszervezési modell alternatíva (BSO)

310

Igényelt rendszer DFM Felhasználói szerepkörök

AZ IGÉNYELT R. FOLYAMATAINAK MEGHATÁROZÁSA

Jelenlegi logikai adatmodell

320 IGÉNYELT R. ADATMODELLJÉNEK KIDOLGOZÁSA

330 A RENDSZER FUNKCIÓINAK ELÕÁLLÍTÁSA

Funkcióleírások Munkafolyamat modell

335 A MUNKAKÖRI LEÍRÁSOK ELKÉSZÍTÉSE

Szerepkör/ funkció mátrix B / K adatszerkezet

Követelmény jegyzék B / K adatszerkezet

B / K adatszerkezet Igényelt rendszer LDM

Szerepkör/ funkció mátrix Funkcióleírások

340

360

Eseményhatás-ábra

IGÉNYELT ADATFELDOLGOZÁSI Lekérdezési utak ADATMODELL FOLYAMATOK Entitás-élettörténetek MEGERÕSÍTÉSE Követelményjegyzék MEGHATÁROZÁSA Esemény és lekérdezés jegyzék Igényelt rendszer LDM

Szerepkör/ funkció mátrix

370 Követelményjegyzék

Szervezeti szintû környezeti útmutató Prototípus kiterjedése1

350 A SPECIFIKÁCIÓS PROTOTÍPUSOK KIDOLGOZÁSA

RENDSZERCÉLKITÛZÉSEK VÉGLEGESÍTÉSE

Funkcióleírások Követelményjegyzék Igényelt rendszer LDM

A KÖVETELMÉNY

SPECIFIKÁCIÓ Parancsszerkezet ÖSSZEÁLLÍTÁSA Prototípus kiértékelése Menüszerkezetek

Követelmény specifikáció


124

4. Rendszertechnikai változat kiválasztása

410 Rendszertechnikai alternatíva kidolgozása

420 Rendszertechnikai alternatíva kiválasztása

5. Logikai rendszertervezés 510 Dialógusok tervezése

520 Karbantartó folyamatok tervezése

530 Lekérdező folyamatok tervezése

540 Logikai rendszerterv összeállítása


125

6. Fizikai rendszertervezés 610 Előkészítés

620

640

Fizikai adatterv előkészítése

Fizikai adatterv optimálása

630

650

Funkcionális építőelemek megvalósításá nak ütemezése

Funkció specifikáció készítése

660 Adat-eljárás kapcsolat véglegesítése

3. Szakasz Követelmény specifikáció

670 Fizikai rendszerterv összeállítása

5. Szakasz Logikai rendszertervezés

4. Szakasz Rendszertechnikai alternatívák

6. Szakasz Fizikai rendszertervezés


126

Az SSADM technikái Diagramos technikák

Nem diagramos technikák

Adatfolyam modellezés

Követelmény meghatározás

Logikai adatmodellezés

Rendszerszervezési változatok kialakítása

Lekérdezési út

Funkció meghatározás

Bemeneti és kimeneti adatszerkezet

Relációs adatelemzés

Egyed-esemény modellezés

Specifikációs prototípus készítése

Logikai adatfeldolgozás tervezése

rendszertechnikai változatok kialakítása

Dialógus tervezés

Fizikai tervezés


127







Lekérdezési út








Dialógus tervezés

Fizikai tervezés

Adat folyam modellezés

• Célja: Egy adott információs rendszerről átfogó képet nyújtson, együtt ábrázolva a rendszer folyamatait és adatait. • A technika rövid leírása: Fizikai adatfolyam modell  logikai adatmodell (logikalizálás)  rendszerszervezési alternatíva kiválasztása  követelmény jegyzék készítésekor kiegészítendő • Termék: adatfolyam modell; adatjegyzék; Logikai adattár-egyed megfeleltetés


g Engedélyezõ

{

a1 Postabontó a Banki ügyletek

ismétlõdõ külsõ egyedek

128

}

a2 Folyószámlavezetés

g Engedélyezõ

Jelölések

felbomló külsõ egyedek

Környezeti elem azonosító

Folyamat

Foly.sz. vez.

3

folyamat neve

hely

AFD: Adat-folyam diagramm DFD: Data-flow diagram

Folyamat Bankszámla kivonat

Folyószámla zárás

Folyószámla adatok

2.1 Foly.sz. vez. Terhelési tételek rögzítése

Elemi folyamat

Feljegyzés könyvelési hibáról

Adattár

számítógépes (ismétlõdõ) fõ adattárak

D1

Folyószámlák

T2

Úton lévõ tételek

Adatfolyam

tovább nem bomlás jele

Anyagfolyam

D1 Folyószámlák

átmeneti adattár

folyamaton belüli szg. adattár (2. folyamat)

manuális fõ adattár

M3

Függõ bizonylatok

felbomló adattárak

{

M3a Függõ jóváírási biz. M3b Függõ terhelési biz.

Formalapok Elemi folyamat leírás Változat: Projekt/rendszer:

Szerzõ:

Folyamat / Közhasznú folyamat AZ Folyamat neve

Leírás

Irodaszerek

anyagfolyam

Raktár

anyagtár

D2/2 Függõ tételek

Dátum:

Verzió

Állapot:

oldal


129







Lekérdezési út








Dialógus tervezés

Fizikai tervezés


130


• Célja: A szervezeti információ igény modelljének kialakítása. (A szervezet működési szabályainak statikus leképezése) • A technika rövid leírása: – Adatszerkezeti ábra, egyed-, kapcsolat- és tulajdonság-leírásokkal – relációs modellezés

• Termék: Logikai adatmodell (áttekintő, környezet, igényelt rendszer logikai adatmodellje

Jelölések Egyedek:

ÁTUTALÁS

FOLYÓSZÁMLA

Kizáró kapcsolatok:

ÜGYFÉL

VEZETÕ

BEOSZTOTT

Indít

ÜGYFÉL

Kapcsolatok:

TÁROLÓHELY

Iktat

Létrejön

Nyilvántartásba kerül

DOKUMENTUM Birtokol

Tárol

Tartozik

Elhelyezkedik

FOLYÓSZÁMLA

DOKUMENTUM


131

Egyedleírás - 1. rész Projekt/rendszer

Szerzõ

Dátum

Verzió

Állapot

Egyed neve

oldal Egyed AZ.

Hely

Elõfordulások

Átlag

Max

Formalapok 1

Leírás

Szinonímá(k) Elsõdleges Külsõ kulcs kulcs

Attribútum név/ azon.

Összekötõ Kapcs.Opcionalitás Kizáró 'vagy' kifejezés sorsz. kapcsolat

Számosság

Kapcsolódó egyed neve

Megjegyzések

Egyedleírás - 2. rész Változat Projekt/rendszer

Szerzõ

Egyed neve Szerepkör

Felhatalmazó Növekedés egységnyi idõszak alatt

Egyéb kapcsolatok

Archiválás és megsemmisítés

Biztonsági szempontok

Állapotjelzõ értékei

Megjegyzések

Dátum

Verzió

Állapot

Oldal Egyed azon.

Hozzáférési jogok

Formalapok 2


132

Kapcsolatleírás Változat Projekt/rendszer

Szerzõ

Dátum

Állapot

Verzió

Egyed neve Kötelezõ?

oldal Egyed azon.

Opcionális?

Az opcionalitás %-os aránya:

Formalapok 3

Összekötõ kifejezés Leírás

Szinonimá(k) Tárgyegyed neve Egy (1:)

Több (m:)

Tárgyegyed azon. Minimum

Maximum

Átlag

A számosság eloszlása Növekedés egységnyi idõszak alatt Egyéb tulajdonságok Szerepkör

Hozzáférési jogok

Felhatalmazó Megjegyzések







Lekérdezési út








Dialógus tervezés

Fizikai tervezés


133


• Célja: A feldolgozási specifikáció egységeit, azaz a funkciókat azonosítja • A technika rövid leírása: Különbözik az eddigi technikáktól, inkább hivatkozás gyűjtemény • Termék: – Funkció leírások – Be/kimeneti adatszerkezetek – Követelményjegyzék

Relációs elemzés

Adatfolyam

modellezés




Dialógus tervezés

Egyed-esmény modellezés


választott BSO

134

rendszerszervezési alternatívák

adatfolyammodellezés

választott BSO

követelmények meghatározása

adatfolyam ábrák DFD kiegészítések

relációs adatelemzés

lekérdezési követelmények

B/K adatszerkezetek RDA adatmodellek

funkció meghatározás

mennyiségi adatok

rendszertechnikai alternatívák

B/K adatszerkezetek lekérdezések

logikai adatmodellezés

események és adatelemeik

B/K adatszerkezetek funkció leírások

kezdeti események egyedek

specifikációs prototípus készítés

eseményhatás elemzés

egyedtörténeti elemzés

funkció kiegészítések

hatások kritikus dialógusok B/K adatszerkezetek funkció leírások

Funkciómeghatározás kapcsolata más SSADM technikákkal

dialógus tervezés

logikai adatfeldolgozás tervezése

fizikai tervezés

Funkcióleírás Projekt/rendszer:.

Szerzõ:

Funkciónév

Dátum:

Verzió:

Állapot:

oldal

Funkció azonosító

Formalap 1

Típus Szerepkörök Funckcióleírás

Hibakezelés

DFD folyamatok: Események:

Esemény gyakorisága:

B/K leírások: B/K adatszerkezet Követelményjegyzék hivatkozás: Mennyiségi adatok: Kapcsolódó funkciók: Lekérdezés gyakorisága:

Lekérdezések: Közhasznú folyamatok: Dialógus nevek: Szolgáltatási szint követelményei Leírás

Cél-érték

Tartomány

Megjegyzések


135

B/K adatszerkezet leírás Projekt/rendszer

Formalap 2

Szerzõ

Dátum

Verzió

Állapot

oldal

Ábrázolt adatfolyamok: B/K adatszerkezeti elem

Adatelem

Megjegyzés







Lekérdezési út








Dialógus tervezés

Fizikai tervezés


136


• Célja: Optimális adatszerkezet meghatározása • A technika rövid leírása: Kiegészíti és ellenőrzi a logikai adatmodellezést. (funkcionális függések, kulcsok, normalizáció) • Termék: SSADM végtermék nem keletkezik, az eredmények a munkalapok

Formalapok Relációs adatelemzési munkalap Projekt/rendszer

Szerzõ

Dátum

Verzió

oldal

Állapot

Forrás neve:

Nem normalizált Attribútumok

Szint

1NF

2NF

3NF

Eredmény Reláció

Attribútumok


137







Lekérdezési út








Dialógus tervezés

Fizikai tervezés


• Célja: egyed-történet és eseményhatás diagram készítése. Az SSADM három dimenziós szemléletében az idő dimenziójának kezelése (360 lépésnél) • A technika rövid leírása: Az egyedek életének vizsgálata, az események meghatározása, a befolyásolás dokumentálása. • Kimenetek: – Eseményhatás-ábrák – Egyed-élettörténetek


138

Egyed történet EGYED

Létrehozás

Módosítás

Törlés

Eseményhatás Könyvelési tételek halmaza

Folyószámla

Terhelés (fedezethiány)

Terhelés (van fedezet)

Könyvelési tétel


139

Egyed-esemény mátrix Jmű beszerzés

Jármű

Jármű Foglalás kölcsönzés

Visszavétel

Karbantartás

L

Bérlő

M

Bérlet

L

Foglalás

T L

L - létrehozás; M - módosítás; T - törlés

SDM HOSKYNS

CASE

Tervezés előkészítése

Tervezés

Kivitelezés

SDM PANDATA BSP

SSADM

Próbaüzem

Éles üzem, rendszerkövetés


CASE eszközök: Computer Aided System Engineering Azokat a szoftver rendszereket, amelyek támogatják, illetve automatizálják a problémadefiniálási, -elemzési, tervezési, modellezési, kivitelezési tevékenységet, elvégzik a tesztelési, rendszerkövetési, karbantartási és minőségbiztosítási feladatokat, dokumentálják a fejlesztést, valamint irányítják, ellenőrzik és összehangolják a fejlesztő projekt munkáját számítógéppel támogatott fejlesztési eszközöknek, CASE rendszereknek nevezzük

A CASE lehetőségek olyan eszközök, amelyek célja a rendszerfejlesztési tevékenység elemzési és tervezési fázisaiban végzett munka hatékonyságának növelése: • a rendszer komponenseinek és működésének feltárásával • a fejlesztési információk rögzítésével és elemzésével • a projekt irányításával, valamint • a fejlesztéshez kapcsolódó információk és teendők adminisztrálásáva

140


CASE eszközök szerepe, kategóriák •

Programnyelv orientált eszközök: •

•

Adatbázis orientáció •

•

„szoftvergyártó computerek”, függnek az op. rendszertől

Fejlesztési integritás •

•

egyszerű kezelést biztosít a fejlesztőknek és felhasználóknak egyaránt (Excel, dBase, Desktop Publishing stb.)

Operációs rendszer-orientált lehetőségek •

•

célja, hogy megkönnyítsék a programozó implementálási munkáját

a probléma definiálástól az elemzésen keresztül a specifikációs szakasz, adatbázis definiálási kivitelezési és karbantartási fázisokban is végig kíséri a teljes rendszerfejlesztési életciklust.

Általános érvényűség •

az alkalmazott módszerek, az op. rendszer a program nyelvek, a szerezési és az üzleti modellek egységesen kezelhetők legyenek.

Integráltság szerint: • CASE Tools: legalább egy fázist támogat • CASE Toolkits: néhány fejlesztési fázist támogat • CASE Workbench: egész életciklust támogat • I-CASE: egész fejlesztési folyamatot támogató integrált eszközök.

141


142

A fejlesztés életciklusában való elhelyezkedés szerint: • Upper CASE: stragégiai tervezésre, projektvezetésre szolgál • Middle CASE: rendszerelemzési és tervezési fázisok munkáját támogatja • Lower CASE: egyszerűbb rendszerspecifikációk készítésére szolgál

7 Minőségbiztosítás a szoftverfejlesztésben: A szoftver termék tulajdonságai: Nem kötődik anyaghoz. Nem folytonos (nem írható le folytonos működéssel) A szoftver nem használódik el, nem öregszik.

A szoftver előállítási folyamat bizonytalansága: ld. ábrák!

A szoftver minőségi összetevői: még nem definiált fogalom, Korrektség: megfelelés a specifikációnak (nem pedig a tényleges használhatóságnak való megfelelés) Ha p annak a valószínűsége, hogy egy program korrekt, akkor n darab programból álló programrendszer korrektségének a valószínűsége P=pn Megbízhatóság: a program üzemkészsége. (korrektség+üzemkészség) Annak a valószínűsége, hogy egy adott időintervallumban a program hiba nélkül működik. Rendelkezésre állás: egy adott időpillanatban a program hiba nélkül fog működni. Használhatósági tényező: MTBF=MTBF/(MTBF+MTTR) MTBF Mean Time Between Failures, meghibásodások közötti átlagos működési idő MTTR Mean Time To Repair, átlagos javítási idő


143

Felhasználó barát jelleg: Adekvátság: bemenetek program szolgáltatásai kimenetek (átlátható, jól értelmezhető) Kezelhetőség: programrendszer funkciói funkciók használata stb. Stabilitás: Hibás adatbevitel, illetve hardver hibák esetén hogyan működik a program. Gyakori hibákra fel kell készülni, ritkább hibára kevésbé. Integritási fok: A szoftverekhez való illetéktelen hozzáférők elleni védelem szintjét, megbízhatósági fokát adja meg: P(V) illetéktelen beavatkozás valószínűsége P(T) visszautasított hozzáférési kérések valószínűsége integritási fok = {[1-P(V)]*[1-P(T)]} Karbantarthatóság: hiba okok lokalizálhatósága javítások érvényesítése programfunkciók megváltoztathatósága bővítésre való alkalmasság tesztelhetőség Ezekre csak jól strukturált és moduláris felépítésű programok esetén van mód. Hatékonyság. erőforrások optimális kihasználása Hordozhatóság: eszközfüggetlenség.

Közlekedési rendszertervezés

Recommend Documents