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

TERMÉKTERVEZÉS PANDUR BÉLA

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 ÁGOSTON MIKLÓS

1


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


2


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

3


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.

•

Összetett komponensek.

•

Szekvencia: a végrehajtási sorrendet jelenti.

•

Szelekció: a végrehajtásban elágazás.

•

Iteráció: hurok, ciklus.

Párhuzamosság

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 Családnév

Képzettség Keresztnév

Szak

Dátum Kategória

Alkalmazott ELŐAD2_ANYAG.DOC ÁGOSTON MIKLÓS

Vállalkozó

Inaktív 4


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

Elvetés

Kód ellenőrzése

Válasz tevékenység

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


5


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

•

Implementációs fázis: fizikai megvalósítás

•

Futtatható alkalmazás

Tevékenység A

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

Érték Kódállomány Értékbekérés

Kilépés

Számlaállomány

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.


6


• • • •

- 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

A6

A3

A2

A5

•

•

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.

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.


7


•

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)


8


•

⇒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 Érték

Modul 1

Kód

Kódellenőrzés

Kód

Összeg

Modul 2 Kódok

Kódállomány

Értékbekérés

Számlaállás Összeg

Számlaállomány Új számlaállás

Modul 2 Számlaellenőrzés

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.


9


• • • • • • • • • •

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.


10


Állapotátmenet-diagram (STD) Kapcsolat

Kagyló le

Hívott válaszol

Foglalt

Tétlen

Készenlét Kagyló fel

Tárcsázás

Tárcsázás

Kicseng

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.


11


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 1.2.1 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 ÁGOSTON MIKLÓS

1


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

R rendszer V állapotválasztéka V= V1*V2

k3 k2

R2 rendszer V2

K4

Kimenet

⇒

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 ÁGOSTON MIKLÓS

2


Az eredmények, vagy célok választéka:

V0=

V ; VC

Az irányítandó rendszer választéka. Az irányítórendszer választéka.

Cél: a V0 é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 ÁGOSTON MIKLÓS

3


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: Zavaró Anyag

Eredmény

Vezérelt műszaki Beavatkozá

Energia

Hulladék

Vezérlőrendszer Célinformáci

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: Zavaró

Anyag

Eredmény

Vezérelt műszaki

Energia

Beavatkoz Szabályo

Mérő

⊗ Célinformáci

Hulladék

Megfigyelés (információ az irá-nyítandó objektum áll tá ól) Eredményinformác

Referencia

Szabályozórendszer

ELŐAD2a_ANYAG.DOC ÁGOSTON MIKLÓS

4



5


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. Beavatkozá

Előrevezetés Referenci a állapot generátor

Kompar átor

Irányítórendsz er

Ered mény

TÉNYLEGE S FOLYAMAT

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

Nem biztos, hogy

Referenci a állapot


Adatértel mező

Folyamat állapot

Akciógen erátor

FOLYAMA T

Szenzoro Visszavezetés

6


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. 1.3 . 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.


7


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


8


• • •

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


9


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 ÁGOSTON MIKLÓS

10


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.


11


• • • •

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.


12


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.


1


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.


2


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……………


3


EUROMETHOD szerkezete

ÁTTEKINTÉS

Szállítói útmutatú

Vevői útmutató Esettanulmány gyűjtemény

Kivitelezés tervezési útmutató

Módszertani összekapcsolá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 ÁGOSTON MIKLÓS

4


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

Használják

Folyamat

Együttesen tekintendők az információs rendszernek!!

Szereplők

Támogat / helyettesít 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.


5


VEVŐ - SZÁLLÍTÓ KAPCSOLAT: IR. adaptáció / információs rendszer

Követelmények

Szerződéses kapcsolat

Követelmények kielégítése

célkitűzések elvárások Termék/szolgáltat.

információ

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

Szervezeti felállás

Fejlesztési módszerek

Fogalmak, útmutatók Szabványok szabályok

Folyamat modell Termék profit

Probléma helyzet

Testre szabott megoldás

Kezdőállapot profil 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 /


6


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é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

Információs rendszer leírás

Működési elem

Kivitelezési terméktípus

Projekt terméktípus

Terv

Beszámoló

Az elemek tartalma a dokumentumokban (útmutatókban) találhatók meg.


7


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

Értékelés

Tervezés

Tervezés

Befejezés ELEMZÉS ELŐAD3_ANYAG.DOC ÁGOSTON MIKLÓS

KEZELÉS 8


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.)


9


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í-

Jellemzők nagyvonalú becslése

Küszöb meghatározása

Pontosítás, számszerűsítés

Egyedi értékek viszonyítása

tása Információ gyűjtés

Osztályozás


Fontossági sorrend meghatározása

Kategóriák a küszöbök alapján Végső sorrend

10


Előzetes kockázatkezelési terv: Az eljárási lánc részei: • A kockázat okának elhárítása (megelőzése). • A létező kockázat bekövetkezési valószínűségének csökkentése (megelőzése). • A kockázat azonnali, közvetlen hatásainak csökkentése (megelőzés, hatás csökkentés). • A kockázat későbbi, üzleti hatásainak csökkentése (megelőzés, hatáscsökkentés). • A kockázat átadása más szervezetnek (például biztosítás formájában). • További információk gyűjtése új vizsgálatok érdekében. • A kockázat elfogadása. A kockázatkezelés alternatív eljárásai Ok megszüntetése

Kockázat forrása

Kockázat

Közvetlen következmények

Következmények a működésre

Enyhíteni kell a működést érintő hatásokat

Csökkenteni kell az előfordulás lehetőségét

Csökkenteni kell az előfordulás lehetőségét

További vizsgálatok szükségesek

El kell fogadni a kockázatot" ahogy van."

A kockázat felismerési workshop (csoportos kiértékelési mechanizmus) 1. Csoportok kiválasztása: az értékelendő területet jól ismerő szakértőkből. 2. A becslés elvégzése: a szakértőkből álló csoport által.


11


A kockázat bekövetkezés valószínűségének és várható hatásának értékelése: Hatásrács: (táblázat)

Nagyon magas Közepes Nem valószínű

A-M

K-M

M-M

A-K

K-K

M-K

A-A

K-A

M-A

Nem fontos

Fontos

Nagyon fontos

A kockázat bekövetkezésének HATÁSA Események beírása a táblázatba: 1.

Az "M-M" kockába eső kockázati események kezelése rendkívül fontos ezért a kockázat kezelésére feltétlenül intézkedési tervet kell kidolgozni. 2. Vannak a táblázatba olyan területek, amelyre eső kockázatok kezelését gazdaságossági alapon meg kell vizsgálni. (Érdemes-e vele foglalkozni?) 3. Van olyan terület amelybe eső kockázatokat egyedileg meg kell vizsgálni, hogy mit érdemes kezdeni vele. A gyakorlatban a második ("Fontos") oszlopot ketté bontják, így négy oszlopos lesz a táblázat. A szabvány / magyar / 6-6 kategóriát ír elő mindkét irányban (sor-oszlop).


12

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

Recommend Documents