TERMÉKTERVEZÉS PANDUR BÉLA TERMÉKTERVEZÉS

Átírás

1 TERMÉKTERVEZÉS A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA Szoftverfejlesztés: magában foglalja mindazon elveket, módszereket és eszközöket, amelyek célja a programok megbízható és hatékony elkészítésének támogatása. Szoftver életciklusa: a szoftver teljes élettartamát fogja át, a kezdeti elképzelésektől egészen a végső elavulásig. Az egyes tervezési műveletek felsorolását, azok egymásutániságát jól szemlélteti a klasszikus vízesés szoftver életciklus-modell. Egy részletesebb, a folyamat iteratív jellegét jobban kiemeli a spirálmodell. Egy egyszerűbb felbontásban a szoftver életciklusának a főbb lépései: Követelmények meghatározása. Analízis, specifikáció elkészítése. Tervezés. Implementáció. Tesztelés. Szoftverfejlesztés piramisa: Ötlet, követelményspecifikáció Struktúraanalízis Rendszertervezés Implementáció, kódolás A piramis az absztrakciós szint jelzésére, az elvégzett munka jellegének kiemelésére is alkalmas. A felső szinten absztraktabb, emberi heurisztikát igénylő műveletek állnak, míg az alsó szinten a rutintevékenységek vannak. A szoftver fejlesztést csak hatékony segédeszközökkel lehet a mai igényeknek megfelelően elvégezni!! Az eszközök lehetnek számítógépi segédprogramok (pl.: fordítók) de magukban foglalják a módszertani segédeszközöket is. A szoftverfejlesztéi módszerek Brooks féle sajátos vonásai: Komplexitás: a szoftver az egymáshoz kapcsolódó komplex tevékenységek, megkötöttségek és struktúrák leírására, leképezésére szolgál. A szoftver tükrözi a valós világ komplexitását, a tervező a valóságot különböző összetettségi szintekre képezheti le. Illeszthetőség: a szoftver nem önmagában működik, hanem meglévő hardver és szoftver környezetben. Rugalmasság: a valós világnak az alkalmazási területet érintő változásait követni kell, ami a módosítások gyorsaságát és áttekinthetőségét igényli. Elvontság: a leírt programkód alapján az ember nem tudja érzékelni a működést, a megvalósulást (legalábbis bizonyos szoftver méret felett). Így nem lehet közvetlenül ellenőrizni a szoftver helyességét, csak próbálkozással, ami viszont nem ad abszolút megbízhatóságot. ELŐAD2_ANYAG.DOC 1

2 A szoftvertervezés: a szoftver fejlesztésének élettörténetébe tartozó folyamat. A tervezőnek számos és különböző forrásból származó információ alapján kell elkészítenie a szoftver tervét, specifikációját. A rendszertervezőnek átfogó ismeretekkel kell rendelkeznie több szakterületről is. Ez utóbbiak indokoltságából eredően a szoftverfejlesztés csoportmunkán alapul. A szoftvertervezés általános modellje Követelményanalízis Megkötések, Keretfeltételek, Előírások Rendszertervezés Egyedi döntések a tapasztalatok alapján Szoftverspecifikáció A különböző tervezési módszerek a tervezési lépéseket, azok célját és sorrendjét adják meg. A Tervezés eredménye valamilyen modell, formalizmus. A modellek a valóság különböző összetevőit emelik ki. A tervezés szemléleti vetületei: Strukturális vetület: a rendszer objektumai között fennálló statikus kapcsolatokat írja le. Ez a vetület foglalja magában a különböző programegységek és hivatkozási kapcsolataik megadását. Viselkedési vetület: a rendszerben bekövetkező események és azok kapcsolatait ábrázolja. Funkcionális vetület: az egyes eseményeket és azok belső működését reprezentálja, vagyis megadja, hogy milyen lépéseket is jelentenek azok. Adatorientált vetület: az adatok struktúráját és az adatok közötti kapcsolatokat statikusan szemlélteti. Funkcióorientált vetület Viselkedési vetület Létrehozott modell Adatorientált vetület Strukturális modell ELŐAD2_ANYAG.DOC 2

3 A funkcióorientált vetületet tartalmazó módszerek, modellek fajtái: HIPO Jackson-féle strukturált tervezés SSA/DT SSADM SADT Petri SDT hálók Objektumorientált eszközök HIPO HIERARCHIKUSFUNKCIONÁLIS TERVEZÉS Jellemzői: Hierarchikus struktúrát alkot. A tervezés folyamata felülről-lefelé halad (top-down). A tervezés elemei: - észlelés, - elemi folyamatok IO struktúrába rendezése, - az IO struktúra táblázatban történő megjelenítése. - a táblázatból szöveges leírás létrehozása. A tervezés szintjei: - első szint (rendszerszint): emberi nyelven megírt specifikáció, - második szint (programodulszint: - harmadik szint: ): a program modulokból a program előállítása. Forrásnyelvű program áll elő. A HIPO tervezési modell dokumentációjának a felbontási finomsága szerinti fokozatai: - Összetétel-diagram: a főbb modulokat és azok kapcsolatát tartalmazza. - Áttekintő diagram: megadja a modulhoz tartozó be- és kimenő adategységeket, valamint a modulon belüli tevékenységek áttekintő leírását. - Részletező diagram: az adatok és a végrehajtandó utasítások részletes specifikációját tartalmazza. Összetétel-diagram Áttekintő diagram Input lista Tevékenység azonosítás Output lista ELŐAD2_ANYAG.DOC 3

4 Részletező diagram Input elemek Tevékenység művelet sora, Részlépések Outputlista JACKSON-FÉLE RENDSZERFEJLESZTÉS (JSD) A szoftverfejlesztési módszer sokban közös a Jackson-féle strukturált programozási elvvel (JSP). A JSP egy programozási technika, a JSD pedig szoftverfejlesztési koncepció. A fejlesztési leírás struktúradiagrammal történik. A struktúradiagram elemei: Elemi komponensek : egységként kezelt objektumok. Párhuzamosság Összetett komponensek. Szekvencia: a végrehajtási sorrendet jelenti. Szelekció: a végrehajtásban elágazás. Iteráció: hurok, ciklus. A JSP kétféle struktúradiagramot támogat: 1 Egyedstruktúra-diagram: az egyes adatokat tároló objektumokat írja le - az inputoutput adatok szerkezetét adja meg-. Az adatszerkezetben előfordulhatnak többértékű és öszszetett adatelemek is. Az időbeliségre semmilyen információt nem jelenít meg. Egyedstruktúra-diagram EMBER Név Képzettség Családnév Keresztnév Szak Dátum Kategória Alkalmazott Vállalkozó Inaktív ELŐAD2_ANYAG.DOC 4

5 2 Programstruktúra-diagram: a funkciómodulokat és kapcsolataikat ábrázolja. Programstruktúra-diagram PÉNZFELVÉTEL Üzenet kiírása Kód bekérése Kód ellenőrzése Válasz tevékenység Elvetés Elfogadás Tranzakció Összegbekérése Ellenőrzés Kifizetés A JSP lépéseinek megtervezése, lépései: Adatstruktúra-diagram kialakítása. Programstruktúra-diagram elkészítése. Atomi műveletek meghatározása és hozzárendelése a diagramegységekhez. Az utasításszöveg elkészítése az egyes atomi műveletekhez. A JSD a JSP -vel szemben az analízist-tervezést támogató módszertan! Középpontjában a rendszerben lezajló cselekvések, tevékenységek állnak. A JSD lépése, struktúrája: Követelményspecifikáció Modellezési fázis: a tervező a követelmények elemzése alapján meghatározza a körben szereplő egyedeket. Egyedi folyamatok leírása: az egyedekhez kapcsolódó folyamatok időbeliségének meghatározása. Rendszer-modellezési fázis: Egyedstruktúradiagram elkészítése. Ebben a diagramban a szekvencia időbeli egymásutániságot jelent. Rendszerleírás: Az adatok közös felhasználása alapján az egyedek közötti kapcsolatok meghatározása. A kapcsolatrendszer leírására a rendszerspecifikációs-diagram szolgál. Az egyedek kapcsolatait leírják: - Adatfolyam-diagram: az egyik egyed által előállított adatot a másik egyed felhasználja ELŐAD2_ANYAG.DOC 5

6 bemenő adatként. - Állapotvektor-diagram: az egyedek vektorokat használnak állapotaik leírására, amelyeket elolvasva más egyedek is tudomást szerezhetnek az egyed helyzetéről. Adatfolyam-diagram (elvi sémája) Tevékenység A Adat Tevékenység A Állapotvektor-diagram Tevékenység A Adat Tevékenység A Implementációs fázis: fizikai megvalósítás Futtatható alkalmazás STRUKTURÁLT RENDSZERANALÍZIS ÉS STRUKTURÁLT TERVEZÉS (SSA/DT) A módszer az 1970-es években fejlődött ki. A módszernek két fő komponense van az analízis- és a tervezésrész. Az analízisrész a modellezett problémakör absztrakt leírását szolgálja. A tervezésrész során a megvalósítás részleteit dolgozzák ki. Az SSA/DT módszer a felülről-lefelé ( top-down ) stratégián alapul, a kezdeti globalitás felől az egyre részletesebb absztrakció felé halad a tervezés. A módszer négy lépésből áll: Az első két lépés képezi az analízisrészt, míg a többi a tervezési fázishoz tartozik. Az analízisrész célja a rendszer funkcionális leírása, annak megadása, mikor, mi történik. Az elemzés eredménye az SSA/DT adatfolyam-diagramban (data-flow "DFD") kerül rögzítésre. SSA/DTAdatfolyam-diagram Kód Kódellenőrzés Elutasítás Kódállomány Számlaállomány Értékbekérés Érték Kilépés Számlaellenőrzés A DFD folyamatot leíró négy alapelem: - kör (vagy ellipszis), amely egy tevékenységet, műveletet jelképez. - téglalap, amely a külső információforrást, vagy nyelőt jelenti. ELŐAD2_ANYAG.DOC 6

7 - párhuzamos vonal az adatállományt jelöli. - irányított él, az adat, az információ áramlását mutatja be. A DFD szemléletesen ábrázolja a modellezett rendszer funkcióit, az egymás között fennálló kapcsolatokat. A tervezési lépések finomítása, a funkciók, adatelemek több szintre tagolódása szükség szerint adódik. A több szintű tagozódás kezelhetősége érdekében segítséget jelent a nyilvántartás, adatszótár. A harmadik lépésben a globális DFD -t felbontják az önálló, azonosított művelet soroknak megfelelően. Így a modell tagoltabbá válik. A negyedik lépésben a DFD -ből struktúradiagramot (strukture chart "SC") készítenek, amely a szoftverrendszer belső struktúráját, a definiálandó eljárásokat és azok hívási kapcsolatait írja le. SSA/DT Struktúradiagram A4 A1 A3 A6 A2 A struktúraleírás (SC) grafikai alapelemei: - téglalap (kör, ellipszis): eljárást azonosít. - él: eljárás meghívását jelöli. - nyíl: az adatáramlás irányát mutatja. Az SSA/DT tervezési fázisa ellenőrzéssel, az átfedések és elletmondások kiküszöbölésével zárul. A5 STRUKTURÁLT RENDSZERANALÍZIS ÉS TERVEZÉSI MÓDSZERTANA (SSADM) Az SSADM Angliába 1980-ban jött létre, ahol nem sokkal később szabvánnyá vált. Azóta a világon széles körbe terjedt el. Az SSADM jellemzői: Az SSADM a szoftver fejlesztés analízis- és a tervezésfázisait fogja át (inkább az analízis területét). Az SSADM nagy súlyt fektet az egyes tervezési lépések eredményeinek folyamatos ellenőrzésére, valamint a leendő felhasználókkal történő konzultációkra. Az SSADM -ben az adatorientált megközelítés a fontos. A rendszerek fix magját az adatok és azok kapcsolatai alkotják. (Tapasztalat) szerint nagyobb eséllyel változik meg a feldolgozás módja, mint a feldolgozott anyag, adat. Az SSADM öt modulra, ezen belül hat szakaszra tagolódik. Az első három modul (a legelső vagy van vagy nincs nélkülözhető, de nem célszerű elhagyni) az elemzési modul, míg az utolsó kettő modul a tervezési modul. ELŐAD2_ANYAG.DOC 7

8 Az SSADM moduljai: I. Megbízhatósági-elemzés modul: 0. Megvalósíthatóság eldöntése szakasz: Nem kötelező a végrehajtása. E szakaszban annak vizsgálata, hogy érdemes-e végrehajtani a fejlesztési projektet.? MEO! II: Követelmény-elemzés modul: 1. A jelenlegi helyzet vizsgálata szakasz: a jelenlegi (fejlesztendő) rendszer logikájának a megismerése (folyamatok, adatok feltárása, követelmények rögzítése). MEO 2. A rendszerszervezési változat kiválasztása szakasz: a fejlesztők és a felhasználó végleges döntése a változatok közül. MEO! III: Követelmény specifikáció modul (elemzés, előtervezés): 3. Követelmények meghatározása szakasz: - adatokra: adatmodellek, - funkciókra: adatfolyam modellezés, - felhasználói interfész: prototipizálás, képernyőtervek, dialógusok. MEO! IV. Logikai rendszerspecifikáció modul: 4. Rendszertechnikai változat kiválasztása szakasz: Több változat kidolgozása, majd a célra legmegfelelőbb kiválasztása. MEO! 5. Logikai rendszertervezés szakasz: Feldolgozások logikai szintű tervezése (lekérdezések stb.). Dialógusok tervezése. V. Fizikai rendszertervezés modul: 6. Fizikai rendszertervezés szakasz: A modul olyan végterméket szolgáltat eredményül, amely a programozásra alkalmas. - Adattervek, - Feldolgozástervek, -Interfésztervek. MEO! Az SSADM részmodelljei: - adatok és kapcsolatok leírása: - adatok és tevékenységek kapcsolata, az adatok áramlása a tevékenységek között: - adatok, egyedek módosulásainak története: Logikai adatstruktúra diagram (LDS): A problémakörhöz tartozó egyedeket és kapcsolataikat ábrázolja. Logikai adatstruktúra diagram Egyedek Kulcsszó Könyv Példány Kapcsolatok Szerző Kölcsönzés Olvasó Egyedek fogalma: a problématerületen jelenlévő, egymástól megkülönböztethető személyek, tárgyak, események. Az egyedek között több típusú kapcsolat (egyedtípus)lehet. Egyedtípusok: Egy-egy kapcsolat: (Pl: ember-személyiszám) ELŐAD2_ANYAG.DOC 8

9 Egy-több kapcsolat: (Pl: ember-autó) Több-több kapcsolat: (Pl: színész-színdarab) Adatfolyam-diagram: az információk áramlását mutatja be. A diagram meghatározza a rendszer környezetét is, megadja, hogy milyen funkciók részei a rendszernek, illetve mely adatok származnak a környezetből. Az SSADM adatfolyam-diagramja funkciójában és formájában is rokon az SSA/DT rendszer DFD diagramjával. A két modell az egyes elemek jelölésrendszerében, illetve az adatok kijelölésében tér el. SSADM adatfolyam-diagram Kód Modul 1 Kód Kódállomány Számlaállomány Új számlaállás Kódellenőrzés Kódok Számlaállás Modul 2 Értékbekérés Modul 2 Számlaellenőrzés Érték Összeg Összeg Szintaktika: - Tevékenységek: téglalap, benne tevékenység azonosítója és a tevékenység rövid tartalma. - Adatfolyam: nyíl, mellette megadva az áramló adat azonosítóját. Több szintű, felülről-lefelé irányuló szétbontást lehet megvalósítani. Egyedtörténet-diagram: a bekövetkező események hatására a rendszer adatainak megváltozását mutatja be. A diagram minden egyedre megadja az egyedhez tartozó eseményeket, tevékenységeket és azok időbeli kapcsolatait. Az események alkothatnak szekvenciát, szelekciót és iterációt. Formalizmus azonos a struktúra-diagrammokéval. Egyedtörténet-mátrix: az egyedek - események (tevékenységek) közötti kapcsolatot összefoglalóan mutatja be. A mátrix jól szemlélteti, hogy egy adott egyed mely eseményekben vesz részt, illetve egy esemény mely egyedeket érint. A mátrixban az "X" szimbólum jelöli a kapcsolódó egyedeket és eseményeket. Dialógusvázlat (LDO): lehetővé teszi az ember-gép kapcsolat, párbeszéd megtervezését. Minden interaktív eseményhez készítenek dialógusvázlatot. A vázlat elemei: - Adat; - Képernyő; - Tevékenység. Az SSADM folyamata Megvalósíthatósági tanulmány: a fejlesztési projekt végrehajthatóságának a tisztázása. Követelmények elemzése: annak felmérése, hogy mit kell az elképzelt rendszernek tudni. Adatfolyam-diagram: annak ábrázolása, hogy melyik adat hová megy. ELŐAD2_ANYAG.DOC 9

10 Követelményspecifikáció: a fejlesztendő rendszerrel szemben specifikált követelmények meghatározása. A DFD, LDS és egyedtörténeti diagramok létrehozása. Platform kijelölés: az adott (fejlesztendő rendszert) fejlesztést megvalósító operációs rendszer kijelölése (NOVELL, UNIX). Platformfüggő specifikációk rögzítése: a kiválasztott OP. rendszernek megfelelő specifikumok rögzítése. Adattervezés: Normalizált adatok, relációs modell: Algoritmus-tervezés: az egyes folyamatokat végrehajtó algoritmusok meghatározása. Javított egyedtörténet-diagramok: Programtervezés Adatstruktúra, algoritmus-leírások Az SSADM módszertan kritikái: A tervezett bonyolultabb rendszer nehezen modellezhető e módszerrel. Nem tartalmaz a módszer arra vonatkozó információkat, hogy miképpen fog a rendszer kommunikálni a környezettel. Erre kíván megoldást adni a módszer a dialógusvázlattal (LDO-val). ÁLLAPOTÁTMENETEK KEZELÉSE, STD DIAGRAM ÉS STM MÁTRIX Állapotátmenet-diagram (STD): Elsősorban vezérlő-irányító rendszerek különböző állapotaiban bekövetkező rendszer viselkedések dinamikus vetületének leírására szolgál. Ezen rendszerek véges automaták (FSM) köréhez tartoznak. Az FSM rendszereknek véges számú különböző állapota lehetséges, minden idő pillanatban egy lehetséges állapotban van a rendszer. A rendszer állapota, ebből eredő viselkedése az idő múlásával megváltozhat. Az új állapot a rendszer aktuális állapotától, a környezet bemenő adataitól függ. A rendszer az állapota megváltozásával párhuzamosan kimenő adatokat is generálhat. A diagram vázolja a rendszer lehetséges állapotait, a hozzájuk kapcsolódó tevékenységeket. Nem tájékoztat azonban a műveletek megvalósításáról, a műveletek pontos ütemezéséről. Az STD elsősorban rendszerelemzési, analizációs módszer. Az STD alkotóelemei: Állapot: téglalap, vagy ellipszis jelképezi, amely jelben megadják az állapotjelző leírását. Állapotátmenetek: nyilak jelképezik. Átmenet feltételei: szöveges formában adnak meg az ábrában. Átmenetnél bekövetkező tevékenységek: az átmenethez tartozó nyílnál adnak meg. ELŐAD2_ANYAG.DOC 10

11 Állapotátmenet-diagram (STD) Kagyló le Kapcsolat Foglalt Hívott válaszol Tétlen Készenlét Tárcsázás Kicseng Kagyló fel Tárcsázás Tárcsázás vége Kagyló le Átmenetmátrix (STM): a táblázat sorai a rendszer lehetséges állapotait, az oszlopai pedig az állapotot kiváltó eseményeket rögzíti. A táblázat célja annak kijelölése, hogy a rendszer egyes állapotaiban milyen események következhetnek be. Az STD és az STM hátránya: olyan komplex rendszerek modellezése esetén, amikor sok rendszerállapot és számtalan akció lehetséges, valamint nagyszámú lehet az egyes rendszerállapothoz tartozó bemenő adat (feltétel), a diagram, táblázat ábrázolása nagyméretűvé, nehezen áttekinthetővé válik. ELŐAD2_ANYAG.DOC 11

12 1. Információs rendszerek sajátosságai. 1.1 A minőségbiztosítás és az informatika kapcsolata. A minőségbiztosítás és az informatika kapcsolata két nézőpontból vizsgálható. Az egyik megközelítésben az informatikai termék ( Hardver, szoftver, hálózat, dokumentum ) előállításához szükséges folyamatok minőségbiztosításához szükséges tevékenységet vizsgáljuk. A másik megközelítés, mikor az informatika eszköz a vállalat egészét átfogó termelési, minőségbiztosítási célok elérésére. 1.2 Egyszerűsített kibernetikai modell A valós rendszerek rendkívül bonyolultak, végtelen sok tényező határozza meg a működésüket. Ebből a halmazból mindig válogatnunk kell, ki kell emelni a fontosakat. A rendszerépítés legkritikusabb része a lényeges és a lényegtelen tényezők kiválasztása. Fogalmak: Rendszer: a kitűzött célok elérésére koordinált (rendezett) elemek halmaza. Rendszernek tekinthető pl. a vállalt és annak alkotórészei (gyár, üzem, műhely stb). Rendszerszemlélet : a rendszerek tudományos vizsgálatában alkalmazott elméleti megközelítés módszereinek összessége. A rendszerszemlélet legfontosabb szempontjai: (C.W. Chruchman: Rendszerszemlélet - Statisztikai Kiadó 1974) Az egész (komplex) rendszer célja és működésének értékmérője (jósági fok, optimum-kritérium). A rendszer környezete: a meg nem változtatható korlátok. A rendszert kölcsönhatások kapcsolják a környezethez. A rendszer erőforrásai (ember, gép, tudás, találmányok) minden, ami a céljaink eléréséhez használható. A rendszer alkotóelemei: - tevékenységek és értékmérői; - célok. A rendszer vezetése (irányítása). Részrendszerek: a rendszereket alkotó alrendszerek. A rendszer tulajdonságai: a rendszer és részeinek aritmetikailag és formálisan mérhető ismérvei. A rendszer tulajdonságok fajtái: Rendszerjellemzők: a rendszer és alrendszereinek változatlan, azonos ismérvei. Rendszerhatározók (jelzők): a rendszer és alrendszereinek változó ismérvei. Állapot: a jelzők (határozók) valamely együttese. Vizsgálható a rendszer és a környezet, illetve a rendszer belső állapota. ELŐAD2a_ANYAG.DOC 1

13 A rendszer külső állapotát szabják meg a rendszer és a környezet közötti kölcsönhatásokon vizsgálható jelzők. A rendszer belső állapotát szabja meg a rendszer részei közötti kölcsönhatásokon vizsgálható jelzők. Folyamat: a rendszerben bekövetkező állapotváltozások időbeli sorozata. Ha a rendszer stacioner állapotban van, az időbeliségtől el lehet tekinteni. Ha a rendszerben dinamikus, vagy meg nem fordítható változások is vannak, akkor az időbeli vizsgálat elengedhetetlen. A termelés és a szolgáltatás is dinamikus folyamat. Van kezdete és vége. Különös gonddal kell eljárnunk a diszkrét állapotú rendszerek esetén. A valóságban az átmeneteknek van ideje. Az átmeneteknek a vizsgálat szempontjából lehet is jelentősége, de lehet elhanyagolható is. ( Egy gépkocsi karambolnál a biztosítás szempontjából csak az a fontos, hogy a bal ajtó cserére szorul, és előtte új állapotú volt. A gépkocsi gyártót a deformáció pontos időbeli lefolyása érdekli a tervezéskor). A rendszer komplexitása: a modellezhető különböző állapotoknak, választékoknak az összessége. (A rendszer lehetséges állapotainak a száma.) Több rendszer kombinálásából létrehozott új rendszer komplexitása, állapotválasztéka egyenlő az alkotó rendszerek állapotválasztékainak szorzatával. R1 rendszer V1 Be men et k1 k2 k3 R2 rendszer V2 R rendszer V állapotválasztéka V= V1*V2 Kimenet K4 K6 K5 K1 - K6 komponensek V1 rendszer komponensei: "a" mennyiségű "K1"; "b" mennyiségű "K2" és "c" mennyiségű "K3"; V1 állapotválasztéka: V1= a*b*c V2 állapotválasztéka: hasonlóan számítható. V állapotválasztéka: V= V1*V2 ELŐAD2a_ANYAG.DOC 2

14 Az eredmények, vagy célok választéka: V V 0 = ; V C Az irányítandó rendszer választéka. Az irányítórendszer választéka. Cél: a V 0 értékének minimalizálása (az eredmény komplexitásnak minél kisebbnek kell lenni). Az egyébként minimumszinten lévő eredmények választékát, komplexitását oly módon van lehetőség csökkenteni, hogy az irányítórendszer komplexitását az irányítandó rendszer komplexitásával, vagy azonos, vagy nagyobb választjuk. Szabályozási alapelv: Egy rendszerszabályozása szigorúan megkövetel egy olyan irányítórendszert, amelynek komplexitása azonos, vagy nagyobb, mint az irányítandó rendszeré SZITUÁCIÓMODELL Megközelítések: Rendszerelméleti megközelítés: az egyes egységek viselkedését vizsgálja, nem foglalkozik az egységek belső szerkezetével. ("fekete doboz" szemlélet.) Veszélyes lenne csak a rendszerelméleti megközelítést alkalmazni. Információelméleti megközelítés: a rendszerek elemei közötti kommunikációs kapcsolatoknak a hangsúlyozása. ENTITÁS: a legkisebb, tovább már nem bontható egység. OBJEKTUMOK: A rendszer objektumai között kölcsönhatások vannak. A rendszer objektumai közötti kölcsönhatások anyagáramlással, energiaátadással és információátvitellel járnak. Az információ átvitelét jelek közvetítik. A jel: valamely megfigyelhető állapotjelző, amely információ hordozására képes. A rendszer állapota: a rendszer állapotjelzői egy adott időpillanatban felvett értékeinek halmazát értjük. A rendszer állapota időben lehet állandó, vagy változó. A változó rendszer állapotban a rendszer folyamatait a rendszer állapotjelzőinek időbeli változásai írják le. A RENDSZER IRÁNYÍTÁSA: A műszaki rendszerekben zajló folyamatokat a kívánt technikai, gazdasági cél érdekében irányítják. Az irányítás olyan célirányos tevékenység, amely egy folyamatot elindít, megváltoztat, vagy leállít, azaz beavatkozik a folyamat időbeli fejlődésébe, állapotváltozóinak alakulásába. A beavatkozás a folyamat előre megtervezett kívánt állapota és a folyamat megfigyelt tényleges állapota összehasonlításával, ezt követő ésszerű döntések alapján történik, hasznos eredmény elérése érdekében. Az irányítandó rendszer folyamatai anyagot és energiát alakítanak át. Az átalakítás során hasznos eredmény és rendszerint hulladék is keletkezik. A műszaki folyamatokat külső és belső zavarások érik. A zavarások is a valószínűbb, rendezetlenebb irányba terelik a rendszer állapotát. A kimenet kívánt eredménye, csak beavatkozással, a folyamatok célszerű irányításával érhető el. ELŐAD2a_ANYAG.DOC 3

15 1/ Vezérlés: Az irányítás egyszerűbb struktúráját vezérlésnek nevezzük. A vezérlőegység a beavatkozó jel képzéséhez a vezérelt rendszer állapotára vonatkozó információt nem használ fel (a szabályzással szemben). 2/ Szabályzás: a vezérlőegység a beavatkozó jel képzéséhez a vezérelt rendszer állapotáról monitorozott információt is felhasználja. Vezérlés általános struktúrája: Anyag Energia Vezérelt műszaki Zavaró Beavatkozá Eredmény Hulladék Célinformáci Vezérlőrendszer A vezérlőrendszer (objektum) semmilyen járulékos információt nem kap a vezérelt műszaki rendszertől, objektumtól. Szabályozás általános struktúrája: Anyag Energia Vezérelt műszaki Zavaró Eredmény Hulladék Beavatkoz Célinformáci Szabályo Referencia Mérő Megfigyelés (információ az irá-nyítandó objektum áll tá ól) Eredményinformác Szabályozórendszer ELŐAD2a_ANYAG.DOC 4

16 ELŐAD2a_ANYAG.DOC 5

17 Hagyományos szabályozási rendszer felépítése: Jellemzők: A beavatkozó jel a referencia és a mért állapot összehasonlítása alapján képződik. A szabályozás tehát olyan többletinformációk alapján valósul meg, amelyet a folyamat állapotának megfigyelése, mérése biztosít. Nincsenek "tapasztalatok", nincs tudás bázis. Az elérendő cél változtatása a Referencia állapot generátorral. Referenci a állapot generátor Előrevezetés Kompar átor Irányítórendsz er Beavatkozá TÉNYLEGE S FOLYAMAT Ered mény Szenzorok Mért állapot "Intelligens" szabályozási rendszer felépítése: Jellemzők: A beavatkozó jel képzéséhez a rendszer szabályalapú következtető-rendszert használ, amely szükség szerint alternatív beavatkozási javaslatokat állít elő egy döntéshozó modul számára. Van "tapasztalat", az adat és tudás bázisban. Beavatkozá Adat és tudá sbáz is Következt etőrendszer Döntésho zó modul Akciógen erátor FOLYAMA T Nem biztos, hogy Szenzoro Referenci a állapot Adatértel mező Folyamat állapot Visszavezetés ELŐAD2a_ANYAG.DOC 6

18 Következtető rendszer : Logikai (igen - nem éles határok.) Fuzzy log. (nincs éles határ, 90% fekete stb.) Neurális háló: minden egyes elem a közvetlen szomszédos elemtől is függ. Problémák: Az adatértelmező rendszer nem írható le egzakt módon. Ma már nem NEUMANN elvű. (Nem közvetlenül programozható.) Matematikailag egyirányú függvények!! (Nehéz a rendszer eredményét meghatározni valószínűség alapú.) Adat és tudásbázis információi az Adatértelmező információival bővül. (Rakéta elhár.!!) SZABÁLYOZÁSOK STABILITÁSA A szabályozók fontos általános tulajdonsága a stabilitás. A szabályozott rendszer stabilis, ha egyensúlyi állapotából kitérítve és magára hagyva, oda visszatér. 1. Lineáris esetek vizsgálata: Lineáris megközelítés. Túllendülések vizsgálata. Feltételezés, hogy létezik állandósult állapot. 2. Nemlineáris esetek, állapotegyenletek vizsgálata: Az állapotegyenletek közvetlen megoldására és a rendszer jövőbeni viselkedésének megítélésére, csak bizonyos korlátozások mellett van lehetőség. Ha ez nem lehetséges, az állapotegyenletek alapján szimulációs kísérleteket végezhetünk, amelyek ma már megfelelő számítógépes programokkal bonyolultabb rendszerek esetén is elvégezhetők. MATLAB, Taylor II., Simple++. Labview. Cél: a FENNTARTHATÓSÁG: A fellépő zavarok ellenére a folyamat a lehető legtovább fenntarthat legyen A VÁLLALATI KOMPLEX INTEGRÁCIÓ MEGVALÓSÍTÁS SZÜKSÉGESSÉGE, CIM RENDSZER ÉPÍTŐ MÓDSZERTAN A CIM módszertan nyílt rendszerfejlesztő szabvány. (Computer Integrated Manufacturing) Az integrációt megvalósító módszertan ( CIM ) főbb jellemzői: A fejlesztő számára szabványosítást jelent. Biztosítja a funkciók széles körű elosztottságát. A felhasználók számára könnyű hozzáférést és alkalmazást biztosít. ELŐAD2a_ANYAG.DOC 7

19 Az információtechnológia alapelvei, ( CIM ) főbb jellemzői: 1. Szabványos, objektumorientált módszereket alkalmaz. 2. Szabványos adatbázisokat, adatkezelést és elérhetőséget biztosít. (Pl.: SQL) 3. Szabványos módszereket kell alkalmazni a kommunikációban a források, tárolási helyek között. 4. A közös, vagyis több funkció vagy folyamat által használt adatoknak neutrálisnak (szabványos formátumúnak kell lenni.) 5. A felhasználói kérések kiszolgálása -az eredmények felhasználóhoz történő visszaküldése- a felhasználó számára világosnak, átlátszónak kell lenni. A CIM architektúra céljai: a.) A közeli jövőben - öt éven belül - elérhető reális célok: A megfelelő információ, a megfelelő helyen és a megfelelő időben legyen elérhető. A környezet és a gyártási folyamatok folyamatos változásaihoz történő alkalmazkodás. Az összes vállalati folyamat és szervezeti struktúra rugalmassága. A vállalt összes tevékenységéhez tartozó funkcióknak olyan mélységű leírás biztosítása, amely segítségével a számítógépes irányítás és szimuláció lehetővé válik. Minden vállalati folyamat valós idejű irányítása. Az információtechnológia leggazdaságosabb alkalmazása. b.) A távolabbi jövő céljai: A különböző szállítóktól származó programok és gépek együttes (konzisztens, kompatibilis ) felhasználási lehetősége. Lehetőség a CIM architektúrák formális eszközökkel ( szigorúan meghatározott szintaxissal és szemantikával) történő leírására. A vállalti referenciaarchitektúrákhoz használandó modellezési elvek: 1. Az összes leírt funkció és objektum ( üzleti folyamatok, adatok, anyagok, erőforrások, szerszámok..stb.) teljesség - és konzisztencia (ellentmondás - mentesség) igazolása (verifikálása). 2. A vállalti modell szimulálása tetszőleges részletezési szinten legyen. (SAP!!) 3. A modellek egyszerű és gyors cseréje az üzleti folyamatok, a módszerek, vagy az eszközök változása esetén (PL.: az SAP nehezen módosítható!!) lehetővé váljon. 4. A modell alkalmazása a vállalat napi működésének indítására, ellenőrzésére, irányítására és ellenőrzésére. 5. Támogassa az erőforrás-allokációt (elhelyezés, elosztás), hogy lehetővé váljon az erőforrások hatékony kihasználása. 6. Olyan legyen ennek a CIM -nek a struktúrája, hogy lehessen modellt generálni (modellezni) a már létező, illetve a még csak tervezett vállalatok számára is. Az architektúrán túli igények, kívánalmak a vállalatintegrálásban: Olyan módszereket kell kifejleszteni, alkalmazni, amelyek a modellezési technikákat, az eszközöket, a projektfejlesztő keretrendszereket könnyen ELŐAD2a_ANYAG.DOC 8

20 kezelhetővé, átláthatóvá teszik a felhasználóknak a nem csak számítógépes szakemberekből álló köreire is. A fejlesztendő, bevezetendő vállaltirányítási rendszernek a felhasználók számára min teljesebb átláthatósága érdekében, széleskörű, a szakemberek szakma specifikumaihoz mért oktatást kell biztosítani. Törekedni a fejlesztés során a meglévő rendszer megfelelő részeinek minél nagyobb mértékű átvételére, adaptációjára. A vállalti integrált irányítási rendszernek a vállalaton belüli mind szelesebb elfogadtatása. Meggyőzni a dolgozókat arról, hogy a rendszer bevezetése mindenki számára előnyös. Miért van szükség a vállalati referenciaarchitektúrára? Modellezni kell az emberek és az információs rendszer kapcsolatát. Az ember és a gyártórendszer, valamint az információs rendszer és a gyártórendszer, valamint a külvilág és a rendszer elemei közötti kapcsolatokat. Mindent meg kell tenni annak érdekében, hogy formális módszereket alkalmazhassunk (mint pl. a szigorúan meghatározott szintaxis és szemantika), hogy leírjuk és értelmezzük az architektúrát és vele a specifikus rendszerek reprezentációját. Ha referencia modellt csinálunk, akkor azt függetlenné kell tenni a meglévő számítógépes és gyártásautomatizálási technológiáktól. (az információs modell = az információ és az emberek közötti kapcsolatot írja le és ne szűkítsük le arra, ahogyan most van). Azt kell meghatározni, mire van szükség az ember és a rendszer kapcsolatában. Ne tegyünk különbséget az adatok és az információ között azok átvitele (továbbítása) és tárolása szempontjából. Az adat és az információ közti különbség: az adat a környezettől függetlenül értelmezhető valami, míg az információ azonban csak a környezettel együtt értelmezhető. (Minden információhoz tartozik valamilyen szemantikus és kulturális összefüggés azt illetően, ahogyan használjuk. Az adatoknál nincs ilyen. ) A helybeliség elvének (lokalizáció elve) túlsúlya. Az azonos földrajzi területen lévő egységek igyekeznek szorosan együttdolgozni. Egy egység általában szorosabban dolgozik a szomszédjával, mint távolabbi egységekkel. A CIM rendszerrel szemben támasztott követelmények: Hibatűrő rendszer: a bekövetkezett hiba hatására ne vesszenek el az adatok. Redundáns rendszer: a rendszer alapvető (rendszer specifikus fogalom) működését a rendszer biztosítja még akkor is, ha egyes alkatrészek meghibásodnak. Enyhe meghibásodás tulajdonság: biztosítja a személyzet, berendezések és a környezet biztonságát mindenféle lehetséges esemény bekövetkezésére. A modularitás és a funkcionalitás meghatározása.: Megfelelő viszonyt kell kialakítani a modularitás és a rendszer funkcionális teljesítménye között. Me ELŐAD2a_ANYAG.DOC 9

21 kell határozni az egyes modulokat és a hozzájuk tartozó funkciókat. Továbbá biztosítani kell, hogy az egyes modulok cserélhetőek legyenek egy fejlettebb változatra anélkül, hogy tönkre tennénk a kapcsolatokat a javított funkcionális lehetőségek és a szomszédai, kvázi a rendszer egésze között. Fontos még annak megállapítása, hogy mekkorák legyenek az egyes modulok? Cél, hogy minél kisebbek, minél kisebbek legyenek az átadandó - átveendő paraméterek száma. Sem a túl nagy sem a túl kicsi modul nem jó. A sok kicsi modul esetén a rendszer lelassul, mivel egymásnak adogatják az adatokat a kicsiny " szabványos határfelületeken". PL.: a távközlésben egy jól bevált modell az OSI-modell, amely egy kétrétegű. Az alatta lévő réteg szolgáltat adatot a fölötte lévő rétegnek. A változások aktív kezelése A sikeres vállalati működés legfontosabb jövőbeli jellemzője a változások aktív kezelése lesz. Ez a külső változások lehető legkorábbi észlelését és a gyors reagálását jelenti, valamint (reagálásként) a belső változások gyors meghatározását és végrehajtását. A modellnek tartalmaznia kell egy döntéshozó rendszert is. A vállalti integrálás területe CIM integráltsági szint Üzleti Alkalmazási Fizikai CIM fejlődési szint Rendszer integrációk: Üzleti integrációk: az üzleti folyamatokat figyelik, felhasználó szinten koordinálják a napi teendőket. Alkalmazási integrációk: adatfeldolgozási szempontból integrált a rendszer. Az adat a tárolási helyétől függetlenül elérhető. Cél: az adatok elérése optimalizált legyen és az adtok lehetőleg több helyen legyenek tárolva, a jogosultságokat pedig a teljes hálózatra nézve állítsák be. Fizikai integrációk: fizikailag elérhetőek az egyes állományok. (Van egy valamilyen hálózat, amelyen az adatok valamilyen módon elérhetőek.) A kommunikáció szabványosítását jelenti. CIM - OSA rendszer megvalósítási elve: 1. Modellezési keretrendszer megvalósítása. Az elvonatkoztatást támogatja. Szemlélteté ELŐAD2a_ANYAG.DOC 10

22 Létrehozá Referencia Nézőpont ok Származtatá Építőkocká Modellek Általános dimenzió: az általános blokkok felől rakják össze egy specifikus vállalati terület modelljévé. Modellezési dimenzió: a rendszer életciklus számára adja meg a támogatást a követelmény megállapításoktól a rendszer megvalósítás leírásáig. Nézőpont dimenzió: a rendszer viselkedésével és működésével foglalkozik. Ez teszi lehetővé, hogy a felhasználó a vállalat különböző szempontjai szerinti (funkció, információ, forrás, szervezet) almodellekkel dolgozzon. 2. Környezet tervezés. 3. Integráló infrastruktúra megtervezése. Előnyei: Folyamatokban való gondolkodásra kényszerít. Tevékenység. Működés. A modellek időbeliséget is tudnak szemléltetni. - Meglévő és leendő alapmodellek. A CIM - OSA architektúrához a szabvány semmilyen megvalósítási módot nem ad meg. A szállító feladata. Mire jó a CÍM - OSA architektúra? Modell alapú irányítás: feltételezi, hogy a vállaltnak létezik naprakész és ellentmondás mentes modellje. A folyamatokhoz felelősöket kell rendelni (hogy a folyamat naprakész legyen). Ott jó ez a rendszer, ahol a cég vagy információtechnológiai, vagy nagy tőke erejű. Nagy volumenű gyártású cég. Hogyan kapcsolódik a termék minőséghez? Az automatizálás és a robotosítás a sztochasztikus hibákat csökkenti. Kisebb az elkészült termékek szórása. ELŐAD2a_ANYAG.DOC 11

23 Kimaradnak a napi és naptári hatások (emberi tényezők). növekszik a beépített szenzorok száma nagyobb számú mérés több visszacsatolás hibák előbb történő kiszűrése. Növelhetjük az automatizált méréseknek a számát. lehetőséget ad a statisztikai módszereknek az alkalmazására. Műszaki adatbázisok létrehozás, tárolása. (Tudásbank!) A számítógéppel támogatott rendszer biztosítása. Az integráció újabb keletű elve Változó környezetben kell biztosítani a rendszereknek a működését. Erőforrás takarékosan kell gyártani. A termelésnek egyidőben több feladatot kell ellátni. A struktúrák helyett a folyamatok veszik át a vezető szerepet a folyamatokat operátorok irányítják szerepük újra megnőtt. Lehetővé kell tenni a folyamat lényeges részeinek újra létrehozásának a lehetőségét új eszközök bevezetése > CASE = számítógéppel támogatott tervezés). Ezek az eszközök alkalmasak magának az információtechnológiai folyamatoknak rendezett és számítógéppel segített fejlesztéséhez. Formalizmust visznek be és nagyon sok támogatást nyújtanak. Pl.: Automatikus változat követés stb. > Adatszótár: ebben nyilvántartják a vállat egészére vonatkozó adat típusokat, formátumaikat, neveit. Egy prodzsektre vonatkozóan mindenki ugyan azt ért. Automatizált adat tulajdonság követés a különböző programok kezelésében. ELŐAD2a_ANYAG.DOC 12

24 TERMÉKTERVEZÉST TÁMOGATÓ SZOFTVEREK I-CASE rendszer Először definiálja a felhasználói felületet. (Hogyan kommunikál a rendszer a felhasználóval.) A rendszer magja a fejlesztési adatbázis, amelyhez kapcsolódnak: A prodzsekt tervezése és dokumentációja. Elemzés, logikai tervezés és fizikai forráskód generátor. A fejlesztési adatbázis által meghatározott pontok: 1. megvalósíthatósági vizsgálat, 2. követelmények elemzése, 3. követelmények specifikálása, 4. logikai rendszer tervezése, Dokumentáló interface: a dokumentálás támogatása, adatszerkezetek, paraméter függetlenség vizsgálathoz, szöveges részeket is megírja. Fejlesztői környezet megválasztása. (Az SSADM a tervezői lépéseket fogja össze.) - fejlesztendő rendszer működési környezete. Az ICASE/SSADM architektúra tartalmazza: - megvalósíthatósági vizsgálat: (rendszer szintű adatfolyam diagram elkészítése, kezdeti követelmények meghatározása, áttekintő diagram elkészítése.) - követelmény elemzés: összefüggés táblázat létrehozása, erőforrás diagram, egyed megfeleltetés. - követelmény specifikáció: adatmodell logikai adatmodell, I/O adatszerkezetek, azt a részt specifikáljuk itt, amit a fejlesztett rendszertől elvárunk. - logikai rendszer specifikáció: funkció modell, milyen funkciókat várunk el a rendszertől. (egyedtörténeti diagram, felhasználói felület definiálása) - fizikai rendszer specifikáció: ORACLE A Nyugat-európai államigazgatási rendszerek döntő ( 60%) hányada ilyen rendszer. A rendszer fő részei: 1. Alapja: CASE DICTIONARY (szótár jellegű). Integrált fejlesztőrendszer. - Lefedi a szoftver fejlesztés teljes élettartamát. - Tartalmazza az egyes adatelemeket és azok leírását. - Karbantartja és ellenőrzi az adatbázist. (PL.: egy adattípus módosítása után a rendszer automatikusan végig módosít minden érintett rendszer elemet. A rendszer aut. figyelmeztetést ad a fejlesztőnek amennyiben valahol az automatikus módosítás akadályba ütközik.) - Amennyiben Oracle adatbázis-kezelővel, vagy egy IBM DB2 -el együtt alkalmazzuk akkor a rendszer generálja az adatbázist is. ELŐAD3_ANYAG.DOC 1

25 2. CASE DESIGNER - A fejlesztés során létrejövő diagrammok, - grafikus interfészek, - felhasználói hierarchia, - adatáramlási diagramm, - egyedkapcsolati diagramm. Minden módosításkor automatizáltan grafikus formátumban megjelennek. 3. CASE GENERATOR for SQL FORMS - Automatikusan generálja a felhasználói programot. Léteznek a táblázataink, megvannak az adat összefüggéseink, megvannak a felhasználói interfészek (táblaformátum, nyomtatási formátum) és ezt követően a rendszer annélkül, hogy programoznánk a rendszer generálja a felhasználói programot. A PROGRAM PROGRAMOZÓI HIBÁKTÓL MENTES!! A rendszer fő fejlesztési fázisai: 1. Stratégiai fejlesztési fázis: Üzleti célok és különböző prioritások meghatározása. Szervezeti modell. A rendszerfejlesztési terv létrehozása a vezetőség bevonásával. 2. Elemzési fázis: Az információ rendszer elemeinek elemzése. Az elemek egymás közti dinamikus viszonyát. A mátrixok, diagrammok elkészítése. Az átadásnak és a betanítási tervek elkészítése. 3. Tervezési fázis: A rendszer struktúra meghatározása. A logikai és a fizikai adatmodellt meghatározása. A relációs-adatbázis méretének és hatékonysági paramétereinek a meghatározása. A rendszer egyes moduljai program tervének a meghatározása. Az egyes modulok együttműködési paramétereinek a meghatározása. 4. Megvalósítási fázis: A relációs adatbázis létrehozása. Alkalmazói program rendszer létrehozása. Modulok tesztelése a felhasználók bevonásával. 5. Dokumentációs fázis: A rendszer dokumentáció elkészítése. Betanításhoz és üzemeltetéshez szükséges dokumentáció elkészítése. ELŐAD3_ANYAG.DOC 2

26 6. Átadási fázis: Legfontosabb cél: ténylegesen üzembe helyezni a prodzsekt "termékét" a rendszert. Az adatkonverzióknak a megvalósítása. (Problémák: kitöltési hiányok átvitelének nehézségei, az értékek értelmezése, ) Rendszer tesz: a funkciók vizsgálata. A fejlesztő rendszerek közös jellemzői: Az adatokkal foglalkoznak. Az adatokat felhasználó folyamatokkal foglalkoznak. Milyen I/O -k vannak? Az idővel nem foglalkoznak. Ezek a fejlesztő rendszerek nem alkalmasak IDŐKRITIKUS rendszerek tervezésére. DARTS ( Design Method for Real Time Systems) / Pl.: légiirányító rendszer, atomerőmű reaktor védelmi rendszere./ A rendszer jellemzői: Az adatoknak egy előre meghatározott intervallumban kell, hogy legyenek. Az adatok fogadásának és feldolgozásának egy meghatározott időn belül kell lezajlania. Az adatbázis karbantartást meghatározott időn belül el kell végezni. A vezérlő műveleteket semmilyen rendszer funkció nem gátolhatja. - Történik esemény megszakítást hoz létre, amelyeket a programban kezelni kell. A kommunikációs szinkronizációs problémák megoldásra kerüljenek. (A külső eszközökkel, illetve az egyes rendszerek egymással történő kommunikációinak kérdései.) Időfeltételek: - Egyes műveleteket bizonyos időn belül be kell fejezni. - Vannak műveletek, amelyek csak bizonyos idő elteltével követik egymást - Aszinkron feldolgozás: bizonyos dolgok esemény vezéreltek. - Az operációs rendszerek, hardverek és együttműködésük kezelése. Tervezési szempontból új feladatok: Kommunikáció és szinkronizálás. Állapotfüggetlenséget leíró jelölő rendszer. Lehetőség, hogy a folyamat leíró rendszereket össze ELŐAD3_ANYAG.DOC 3

27 EUROMETHOD szerkezete ÁTTEKINTÉS Szállítói útmutatú Vevői útmutató Módszertani összekapcsolási útmutató Esettanulmány gyűjtemény Kivitelezés tervezési útmutató Fogalmi kézikönyv: Tranzakció modell szótár. Terméktípus modell szótár. Stratégiai modell szótár. HOL JAVASOLHATÓ?? Ott ahol egy vevő egy szállítóval áll szemben. - A szerződéses kapcsolatok létrehozását támogatja. - Minden féle tevékenységet támogat. Új információs rendszer műszaki megtervezése. Szoftver fejlesztések. Új számítógéprendszer kialakítása. Egy adott szoftvercsomagra alapozott. Alkalmazói szoftverek karbantartása. Információ rendszeres, szükségessé váló változások elemzése. Meglévő rendszerek dokumentálására. Alkalmazás feltétele Legyen meghatározva a projekt célja akkor segít a tender kiírás feltételeinek megteremtésében. A projekt befejezési fázisában: az állapot jóváhagyásában. ELŐAD3_ANYAG.DOC 4

28 Fő célkitűzése: Az EU -n belül egységes fogalmi rendszer elősegítse az információs rendszerek piacainak egységesítését. Követelmények egységes definiálása. Megszűnik a versenyelőnye egyes már bevezetett rendszereknek. Erősíti a mobilitást, erősíti az európai piac versenypozícióit. MIÉRT JÓ?? A vevő nem tudja megfogalmazni az igényeit. (Ködös!!) Garantálja, hogy a vevő nem a számára legjobb megoldást kapja!!!! A NEHÉZSÉGEK MÁSIK FORMÁJA A VEVŐ ÉS A SZÁLLÍTÓ KULTÚRÁJÁNAK A KÜLÖNBSÉGE. Felfogható humán menedzsmentnek is.: Információ erőforrás Folyamat Szereplők Támogat / helyettesít Használják Együttesen tekintendők az információs rendszernek!! Számítógép rendszer Amit kiszoktak felejteni a rendszer fejlesztéséből! Milyen érdekeltségűek? Mennyibe kerül a szereplők generálása (képzése)? Adott rendszer működtetése milyen emberi erőforrásokat igényel? A teljes birtoklási készség költségeibe ez is bele értendő. Szerződések: Egy meghatározott állapotból egy másik meghatározott állapotba juttatják el a rendszert. Pl.: KARBANTARTÁS Kezdőállapot: probléma feltárás Végállapot: Rendszer új üzembe helyezése. RENDSZER LEÍRÁS Kezdőállapot: Globális terv Végállapot: Részletes működési terv. ELŐAD3_ANYAG.DOC 5

29 VEVŐ - SZÁLLÍTÓ KAPCSOLAT: IR. adaptáció / információs rendszer Követelmények célkitűzések elvárások Szerződéses kapcsolat információ Követelmények kielégítése Termék/szolgáltat. IR. projekt készségek/ismeretek Helyzetvezérelt rendszer: Mindig alkalmazkodik a pillanatnyi helyzethez. Bizonytalansági és kockázati tényezőket is figyelembe vesz. Törekszik a kockázatok minimalizálására. EURO method Fogalmak, útmutatók Probléma helyzet Szervezeti felállás Testre szabott megoldás Szabványok szabályok Kezdőállapot profil Fejlesztési módszerek Folyamat modell Termék - profit Végállapot profil IR stratégia Döntési pontok Stratégiai - kivitelezési terv az elvárt termék absztrakt leírása / pontosan leírni a valós követelményt / ELŐAD3_ANYAG.DOC 6

30 Döntésközpontú: Elemei: Tendereztetés Tender felhívás Szerződés Létrehozási folyamat Terméktípus jóváhagyása Projekt állapot, terv jóváhagyás Szerződésváltozás, ellenőrzés Befejezési folyamat Végső terméktípus jóváhagyása Szerződés lezárása TERMÉKTERVEZÉS Termékközpontú A termékre összpontosít, nem tudva, hogyan készül a termék. A folyamat kevésbé érdekes. Terméktípus Célterületi terméktípus Kivitelezési terméktípus Projekt terméktípus Információs rendszer leírás Működési elem Terv Beszámoló Az elemek tartalma a dokumentumokban (útmutatókban) találhatók meg. ELŐAD3_ANYAG.DOC 7

31 KOCKÁZATELEMZÉS Kockázat: Általánosságban kockázatnak tekintünk bármely olyan tényezőt, amelynek kimenetele bizonytalan és valamilyen értelemben, mértékben veszélyezteti a feladat végrehajtásának sikerét. Minden kockázat jelenlegi vagy jövőbeni események hatásával, bekövetkezésével kapcsolatos. A kockázatkezelés a feladat végrehajtásával párhuzamosan, egyidejűleg történik, a végrehajtásban résztvevők különböző szintjein, de a feladattól elválaszthatatlanul, a végrehajtás szerves részeként. A kockázat nem azonos a problémával vagy - rosszabb esetben - a válsággal. A kockázatoknak kiváltó okai vannak, a kockázatok minőségileg is és mennyiségileg is jellemezhetőek. A kockázat problémává válását, azaz a kockázati esemény bekövetkezését, vagy lehet jelezni, vagy nem. Kockázatkezelési részfolyamatok 1. Kockázatelemzés lépései: / Két dologra készítenek: - Számítógépes projektre, - Működő rendszert érő behatásra a kockázati tényezők felismerése, egymásra és a folyamat kimenetelére vonatkozó hatások becslése, a hatás kiértékelése. 2. Kockázatkezelés módszere: a kezelési eljárások megtervezése, az ehhez szükséges erőforrások biztosítása, a kezelési terv végrehajtása, a végrehajtás eredményességének nyomon követése. Indulás Tervezés Felismerés Tervezés Becslés Tervezés Értékelés Tervezés Befejezés ELEMZÉS KEZELÉS ELŐAD3_ANYAG.DOC 8

32 A kockázat alapkategóriái: 1. Kockázat keletkezésének forrása szerint: Gazdasági: erőforrások (pénzügyi és egyéb erőforrások kockázata), piaci feltételek. Politikai / jogi: szociálpolitikai, törvényi szabályozás kockázata. Ergonómiai: földrajzi, környezeti feltételek, dolgozók munkafeltételei változás kock. Technológiai adottságok / kötöttségek, elérhető lehetőségek. Infrastrukturális: kommunikációs adottságok, ellátási feltételek / lehetőségek. Szociális: megfelelés az értékrendnek, ellenállás a változásoknak. Szervezeti: döntési hierarchia, személyzeti politika, szervezeti kultúra. 2. Kockázat keletkezésének jellege szerint: Külső kockázatok: amik a projekt szempontjából nem befolyásolhatók. Belső kockázatok: a (projekt) végrehajtás során a végrehajtótól függenek. Szereplők értékelése: Szereplők: A program/projekt végrehajtásához több szereplő, érdekelt fél kapcsolódik. Érdekelt félnek nevezzük azokat az embereket, akik viselkedését stratégia irányítja. Az emberi szereplők két irányból vesznek részt a kockázati folyamatokban: 1. A kockázatok előidézőjeként résztvevő szereplők. 2. A kockázatok kezelőjeként fellépő szereplők. A kockázatok értékelési ismérvei: kik az érdekelt felek, az érdekelt felek belső vagy külső szereplők-e, az érdekelt fél mit nyerhet/veszíthet, melyek az érdekelt fél erős/gyenge pontjai, befolyásolásának lehetőségei, az érdekelt fél stratégiai célja a projekt segítése -e vagy annak akadályozása. Külső szereplők : fővállalkozó, alvállalkozó, versenytárs, beszállító, közvélemény, kormányhivatal hozzáállása Belső szereplők: felső vezetőség, programigazgató, leendő felhasználó hozzáállása. Kockázatkezelési folyamat módszeressé tétele: A kockázat kezelési folyamat (elemzés, kezelés) során állandóan végezni kell.: ELEMZÉS: 1. A kockázatok felismerése: Megfelelő környezet biztosítása az elemzéshez. (Amennyiben a résztvevők hajlandóak a problémákat a felszínre hozni. Anonim kérdőív.) Széleskörű információ gyűjtés. (Minél szélesebb körben.) Osztályozás. (A kockázatokat kiváltó okaik szerint.) ELŐAD3_ANYAG.DOC 9

33 2. A kockázatok becslése: Jellemzők nagyvonalú becslése: a becslésben résztvevők egyetértése szükséges a becslés módszerének elfogadásában. Pontosítás, számszerűsítés: a becslés pontos adatokat és sajátos matematikai módszereket igényel. Fontossági sorrendbe állítás: a becslés eredményeként, a kockázatok között kialakult fontossági sorrend. 3. A kockázat értékelése: Küszöbérték meghatározása: minden kockázatoz tartozik egy elfogadhatósági érték, egy küszöb, amely értékig a projekt megvalósítható és amely érték felett csak rendkívüli intézkedés mellett valósítható meg a projekt. A küszöböt minden kockázati típusra meg kell határozni külön-külön. Egyedi érték és a kockázati küszöb viszonya: valamennyi kockázati tényező egyedi értékét össze kell hasonlítani a küszöb értékkel. Ha a kockázat egyedi értéke a küszöb fölött van, akkor sürgős intézkedésekre (az intézkedések végrehajtáshoz pedig akciótervre) van szükség. Kategorizálás a küszöbhöz való viszony alapján: Elkerülhetetlen: a kockázat kezelhetősége érekében változtatni kell a projekt célkitűzésein. Kezelhető, de csak bizonyos határon belül: bizonyos költségvetési, ütemezési intézkedések megtételével válik kezelhetővé a kockázat. Kezelhető: amennyiben a projekt alapvető céljait ugyan nem befolyásoló, intézkedéseket végrehajtják. Kockázatok végső sorrendje, javasolt kezelési eljárások: a sorrend és a kezelési eljárások meghatározásához fontos, hogy a kockázat bekövetkezésének valószínűségét és a varható hatását körültekintően és dokumentáltan végre kell hajtani, hogy ezálta elegendő információ álljon a "kezelés" szolgálatában. KOCKÁZATKEZELÉS FOLYAMATA Felismerés Becslés Értékelés Megfelelő környezet biztosítása Információ gyűjtés Osztályozás Jellemzők nagyvonalú becslése Pontosítás, számszerűsítés Fontossági sorrend meghatározása Küszöb meghatározása Egyedi értékek viszonyítása Kategóriák a küszöbök alapján Végső sorrend ELŐAD3_ANYAG.DOC 10