KOVEX Computer Kft. Nagy Géza

Az előadások a következő témára: "KOVEX Computer Kft. Nagy Géza"— Előadás másolata:

1 KOVEX Computer Kft. Nagy Géza nagy.geza@kovex.hu www.kovex.hu
informatikus KOVEX Computer Kft. Üdvözlés Bemutatkozás Megtisztelő feladat, hogy megnyissam a szerdai nap előadásait ebben a teremben Milyen szakról is vannak?

2 Ismerős valakinek valami az itt levő dolgokból.
Nem néztem meg az órarendeket, így nem tudom A fent levő dolgok iratkezelési szabványok Az előadás címéből lehetett már gondolni. Van valakinek ötlete mi az iratkezelés? (fontos dokumentumok megőrzése és kezelése, amíg ez szükséges)

3 Irat és Információ Mi tekinthető iratnak? Venn diagram.

4 Irat és Információ

5 Rövidítés MoReq MoReq2 MoReq2010
Model Requirements For The Management Of Electronic Records MoReq2 MoReq2010 Modular Requirements For Records Systems

6 Történelem – ISO 15489 2001: ISO 15489 Elektronikus iratok kezelése
Alapkifejezések Iratkezelési folyamatok Hogyan kell kezelni egy iratot Iratkezelő rendszer alapok 20 oldal

7 Történelem - MoReq 2001 DLM Forum és az Európai Bizottság
Elektronikus iratok kezelése Univerzális Több nyelven elérhető De facto szabvány Sablon követelmények, amelyek aztán később módosíthatóak az igények szerint Tartalmazza, hogyan kell fejezeteket hozzáadni, szerkeszteni, törölni 128 oldal

8 Történelem – MoReq2 2005 DLM Forum Case Study
Célja a MoReq kiterjesztése Metaadat modell XML séma Tesztelési keretrendszer Független tesztközpontok Minőség-ellenőrzés Független hitelesség Plecsni a megfelelésről 237 oldal

9 Történelem – MoReq2 2008, Toulouse: MoReq Governance Board Ütemterv
Karbantartás Fordítási program Tesztközpontok hitelesítése, és tesztelési módszereik ellenőrzése Oktatási program Marketing

10 Történelem – MoReq2

11 Történelem – Architektúrák

12 MoReq2010 2010: MoReq2010 Moduláris követelmények
Rugalmas, kiterjeszthető architektúra Nem csak elektronikus iratok kezelésére! Nincs szükség a specifikáció módosításra Tesztelés megkönnyíthető 520 oldal

13 Szolgáltatás alapú architektúra
Szolgáltatások, vagy szolgáltatáskötegek Egymástól független szolgáltatások Akár egymástól külön is létező szolgáltatások Centralizáció Feature-ök támogatása Beépülő modulok támogatása

14 Szolgáltatások Alapszolgáltatások Mintaszolgáltatások Interfészek
Felhasználó és csoport Besorolás Iratkezelés Selejtezési ütemterv Selejtezési visszatartás Keresés és Riportálás Export Mintaszolgáltatások Metaadat Szerepkör Interfészek GUI API Kétféle szolgáltatás létezik: Alap és Minta Alapszolgáltatás (Core Service): Alapvető követelménye a rendszernek Mintaszolgáltatás (Model Service): Nem mondjuk meg mit és hogyan csinálj, de ezt ezt ezt ezt ezt… tudja. Érezhető a hangnemből az irónia. Olyan ez mint a közbeszerési eljárások. Bárki pályázhat rájuk aki megfelel a feltételeknek. Az hogy aztán olyan feltételt szabunk, hogy csak Kovács János alvállalkozó teljesítheti, az már mellékes. Tehát mintaszolgáltatás. A MoReq2010 ad egy jó mintát amit „érdemes követni”.

15 Szolgáltatások és egyedtípusok
Felhasználó és csoport Felhasználók, csoportok Szerepkör ACL, szerepkör Besorolás Irat, komponens, gyűjtemény Metaadat Metaadat elem definíció Selejtezési ütemterv Selejtezési visszatartás Minden egyedtípus rendelkezik: Egyedi metaadat gyűjtemény Nem azonosak egyetlen egyedtípusnál sem. Ezek egyértelműen azonosítják az egyedtípust. Rendelkeznek azonosítóval, leíró információval, esetenként egyedhivatkozással. Minden szolgáltatás alá adott egyedtípusok tartoznak. Egyes egyedtípusok alatt lehetségesek egyed altípusok is. Például: metaadat elem definíció: környezeti metaadat elem definíció, rendszer metaadat elem definíció. Következő dia: Egyed felépítése

16 Egyed Az egyed az egyedtípus egy példánya. Programozásból ismerős lehet a fogalom, hasonló itt is. Az egyedtípus adja meg az elem vázát, az egyed pedig a váz szerkezetét viseli, de már rendelkezik konkrét hozzárendelt értékekkel. Az egyednek a fenti 3 része van. Metaadatok: ezek a korábban elmondottakkal megegyezőek. A Metaadatoknak is két része van: Metaadat elem definíció, ami meghatározza a metaadat szintaktikáját és szemantikáját, valamint a metaadat elem érték. Esemény történet: Eseményekkel van tele, kezdődik a létrehozás eseménnyel. Csak azok az események kerülnek bele, amelyek az egyeddel kapcsolatosak. Vagyis az egyed részt vett egy tranzakcióban, valamilyen módosításnak lett alávetve, stb. A hozzáférés vezérlési lista, vagy ACL. A felhasználók hozzáférését szabályozza: kinek mit engedünk meg, kinek mit nem. Hozzáférési szabályokat nem csak egyedhez lehet hozzárendelni, hanem konkrét szolgáltatásokhoz is. Következő dia: Egyed életciklusa

17 Egyed életciklusa Az eseménytörténettel kapcsolatos. Eseménytörténet: események sorozata időrendi sorrendben. A kezdő esemény a létrehozás esemény. Meghatározó események: Első használatba vétel, Ellenőrzés, Selejtezés kezdés, Megsemmisítés Megsemmisítés és törlés közötti különbség. Törlődhet: Egy iratot törölni lehet mindaddig, amíg nem szerepel sehol, vagyis nem lett még használatba véve. Onnastól csak megsemmisíteni lehet Első használat: Az egyed szerepel valamilyen másik eseményben, vagy hivatkozásként, vagy közvetlenül. Aktív: Léteznek a komponensei, megvan a teljes eseménytörténete, de a legfontosabb: NINCS KITÖLTVE A MEGSEMMISÍTÉS IDŐBÉLYEG

18 Szolgáltatások általában
Felépítés Szolgáltatás információk Alapkoncepciók Funkcionális követelmények R[fejezet sorszám].[4].[követelmény sorszáma] Pl. R3.4.11 Alapkoncepciók: Implementált szolgáltatás azonosító: Egy univerzálisan egyedi azonosító, a pontos szolgáltatást azonosítja. Alapkoncepciók: Általános magyarázatok természetes nyelven leírva. Általános elképzelések a szolgáltatások működésével kapcsolatban, általában ábrákkal illusztrálva. (Exportnál jól jönnek) Funkcionális követelmények: Tényszerű leírása annak, hogy mit kell, csinálnia az iratkezelő rendszernek. Ezeket követi egy rövidebb magyarázó szöveg, a könnyebb megértés, és a speciális esetek demonstrálására. Vegyük sorra a szolgáltatásokat.

19 Felhasználó és csoport szolgáltatás
Operációs rendszerben már létezik Létezhet címtár is Lényegtelen a hitelesítés módja Az MCRS-nek mindenesetre információkat kell tárolnia a felhasználókról A rendszer felhasználóit és a felhasználókat összegyűjtő csoportokat kezelő szolgáltatás. Létezhet egy ilyen szolgáltatás már az oprendszeren belül is. A probléma ezzel azonban az, hogy az objektumok nem egyeznek az iratkezelésben szükséges felhasználós és csoportobjektumokkal. Például: az oprsz. saját azonosítókat használ, saját felhasználónév attribútumokkal. Ez útjában áll az átjárhatóságnak. Ugyanez vonatkozik a címtárra is. Nagy előny, hogy a MoReq2010 nem foglalkozik a hitelesítés típusával. A MoReq2010 felsorol egy nagy adag protokollt, amit nyugodt szívvel lehet használni. Az MCRS tárolhatja az operációs rendszer adatait környezeti metaadatok formájában, de nem kötelező, viszont minden MoReq2010 által meghatározott adatot kötelező jelleggel tárolnia kell.

20 Felhasználó és csoport szolgáltatás
Kapcsolat: Több a többhöz Megsemmisítés Egy felhasználó egyszerre több csoportnak is tagja lehet, és egy csoportnak több tagja is lehet. Fontos azonban megjegyezni, hogy egy csoport megsemmisítésekor a csoporttagságokat már nem szabad módosítani, a maradványcsoportnak ugyanazok a tagjai lesznek a maradványélete során mint megsemmisítésekor.

21 Minta szerepkör szolgáltatás
Mintaszolgáltatás Nincs megfelelő szabvány Szerepkörök hozzárendelése Mintaszolgáltatás, vagyis csak ajánlott követelmények vannak, amelyeket teljesíteni kell, de akár saját módszerekkel is helyettesíthetőek. Az egyik indoka ennek, hogy nincs pontos ipari szabvány a szerepkörök hozzárendelésére, és kezelésére. Az egyszerű CRUD modellek túl primitívek, valamint nem tesznek különbséget a törlés és a megsemmisítés között, ami itt fontos lenne. A mintaszolgáltatásnál két lehetőség van: vagy implementálják a teljes minta szerepkör szolgáltatást, vagy a sajátjukat használják, de akkor ekvivalensnek kell lennie a mintával, és exportálhatónak mintaformátumba. Szerepkör felépítése

22 Szerepkör hozzárendelés
ACL-ek segítségével.

23 Szerepkör Szerepkör definiálása Öröklés
Adminisztrátori, nem adminisztrátori szerepkörök Többszörös öröklés Előre konfigurált szerepkörök Művelet végrehajtásakor mindig ellenőrizni kell, hogy a végrehajtó felhasználónak van e jogosultsága azt végrehajtani. Szerepkör: funkciók gyűjteménye (logikusan összetartozó) Öröklés: Egy felhasználó örökölheti a szolgáltatástól és csoporttól az ahhoz rendelt szerepköröket. Akkor jó, ha nagy a rendszer, és a szerepkörök kiosztása egyesével problémás lenne. Az öröklés megszakítható közvetlen hozzárendeléssel. Kétféle szerepkör van: Az a. minden szolgáltatáson végigöröklődik, ha van értelme. A nem a.-t csak a gyermek örökli, és alapértelmezetten nem öröklődik, de beállítató egy fleggel. Többszörös: egyszerre több forrásból is örökölhet az egyed. Osztálytól és szülő egyedtől. A beszállító állítja be, a könnyebb használatba vétel érdekében.

24 Besorolási szolgáltatás
Osztály Mi a besorolás? Minden iratot be kell sorolni Osztály és alapértelmezett selejtezési ütemterv Osztály öröklése Az osztályok üzleti funkciókat, tevékenységeket vagy tranzakciókat jelölnek, ezekkel lehet az üzleti környezetet megteremteni. A besorolás egy osztály hozzárendelését jelenti. Az iratok nem csak osztályokhoz vannak hozzárendelve, hanem gyűjteményekbe is vannak sorolva. Egy gyűjtemény is besorolható, ekkor a gyermek gyűjteményei vagy az egyedei örökölhetik a besorolását. Létrehozás után azonnal be kell sorolni, ez történhet közvetlen hozzárendeléssel, vagy örökléssel. Azzal, hogy osztály kapott az irat, kapott üzleti környezetet is, de kapott alapértelmezett selejtezési ütemtervet, ezzel ki lett jelölve az egyed életciklusa.

25 Osztályozás öröklése Kérdés: Mi történik az egyik besorolás módosításakor? Az egyedeknek két állapota lehet öröklés szempontjából: Örökli a besorolását Közvetlenül van hozzárendelve A fenti ábra pontosan szemlélteti, hogy mi történik egy besorolás megváltoztatásakor. Újra besorolás: a besorolás megváltoztatása Egy besorolási szolgáltatás besorolási sémákat tartalmaz, egy ilyen a hierarchikus besorolási séma.

26 Iratkezelési szolgáltatás
Gyűjtemények Célgyűjtemény Gyökér szintű gyűjtemény Gyűjtemények megszorításai Gyűjtemények és az öröklődés Gyűjtemények sorrendje Gyűjtemény megsemmisítése A gyűjtemények célja, hogy az iratokat egy csoportba fogja össze. Az ilyen gyűjtemény a célgyűjtemény. Neve alapján valami közös tulajdonság miatt gyűjti az iratokat. A gyökér szintű gyűjtemény a hierarchikus besorolási séma legfelső szintű eleme. Lehet több gyökér szintű gyűjtemény is egy besorolási sémában. Így akár többfelhasználóssá is lehet tenni egy MCRS-t. (Hasonló az SAP mandantjaihoz) Legfontosabb: irat és gyűjtemény nem lehet egy szinten. Ennek egyik következménye, hogy irat nem helyezhető el gyűjteményen kívül. Az öröklődő tulajdonságok: Besorolás, hozzáférési szabályok, metaadatok. Gyűjtemény sorrendje: Az időrendi sorrend miatt egyértelmű (keletkezési dátum/idő szerint). Ez a másik indok amiért nem helyezhetőek el gyűjtemények és iratok egy szinten, mivel nem dönthető el a sorrend pontosan. Gyűjtemények megsemmisítése: alulról felfelé: ha egy gyűjtemény zárt, és nincs benne aktív egyed, akkor meg lesz semmisítve, pont.

27 Iratok Iratok atomisága Duplikáció Iratkomponensek
Az iratokról már volt szó, most egy kicsit az egyéb tulajdonságaira is kitérünk. Minden irat önmagában tekintendő atominak a komponenseivel együtt. Az iratok zártak. Az átjárhatóságot szolgálja. Az átjárhatóság miatt a MoReq2010 nem támogatja az iratok másolását, hanem a duplikációt igényli. Másoláskor a létrehozott irat eseménytörténete elveszik a másolás pillanatáig, mivel a másolatelem, csak onnan él. Duplikáció: nem csak a metaadatokat másoljuk le, hanem az eseménytörténetét is. Ekkor azonban egyik egyed sem lesz másolat egyed, mindegyik eredetinek tekintendő. Ez akkor jó, ha azt akarjuk, hogy az irat egyszerre több gyűjteményben is megjelenjen. Átjárhatósági okokból. Irat tartalom: külön áll az irattól, akár máshol is tárolható pl: adatbázisban. Sőt akár különböző helyeken levő adatbázisban. Itt jön a MoReq2010 egyik legjobb újdonsága: a tartalmat a plug-in modulok határozzák meg. Lehet elektronikus de akár fizikai is. (A fizikait itt úgy kell érteni, mint a korai sakk gépeket.) Az iratkomponenseknek azonban 4 nagyon fontos feltételt kell teljesíteniük. (Következő dia)

28 Iratkomponensek Diszkrétség
Minden komponensnek egyedülállónak kell lenni, és jól el kell különülnie az összes többitől. Az sem lehetséges, hogy a komponensek külön vannak, de egy tartalomra mutatnak. A probléma első sorban duplikáció esetén jön elő. Fizikai diszkréció: egy teljes másolata a tartalomnak Logikai diszkréció: Egy mutatót tartalmaz a másik tartalomra.

29 Iratkomponensek Teljesség
A komponensek által hivatkozott tartalmak együttesen alkotják az iratot. Ezek a tartalmak nem hivatkozhatnak külső forrásokra. (megszűnhet, megváltozhat, frissülhet) Hivatkozás: egy külső adótörvényre, amit módosítanak: totálisan más lesz benne mint ami a hivatkozás létrehozásakor. Megengedett: egymásra hivatkozás.

30 Iratkomponensek Állandóság
Állandóság: az irat tartalma létrehozás után nem módosítható. Metaadatok: igen, komponens tartalom nem. Biztosítani kell a módosítás, csere, törlés védelmét. Emiatt használnak egyébként saját tartalomtárakat az iratkezelő rendszerek. Ez nem mindig praktikus. Sokkal praktikusabb lehet több, külső tartalomtárban tárolni az adatokat, ez már megengedi a MoReq2010. Feltéve persze, hogy a módosítás ellen védve vannak az információk.

31 Iratkomponensek Megsemmisíthetőség
Irat nem semmisíthető meg, csak ha a tartalma már meg lett semmisítve. A fizikai tartalom megsemmisítése külön (vicces) dolog. Nem dolgoztak még irattárban nyári munkában? Volt úgy, hogy le kellett selejtezni egy csomó iratot, és egyszerűen meg kellett gyújtani, ez volt a hivatalos utasítás, sőt meg is kellett várni, hogy megsemmisüljön. Az elektronikus tartalom megsemmisítése is cuki egy feladat lehet, mivel törlés után egy szimpla merevlemezről visszaállíthatóak az adatok. Sőt, akár formázás után. Sőt, fizikai tönkretétel után is akár (Debrecen: Adatmentés Kft.). Ez lehet vicces folyamat, de pl egy költségvetési terv, vagy akár egy elektronikus bankszámlakivonat is ha rossz kezekbe kerül, a részvények árfolyamát például nagyban tudja befolyásolni. Ha nem lehet automatikusan törölni egy tartalmat, a MoReq2010 lehetőséget biztosít, hogy törléskor megerősítéssel lehessen jelezni, hogy a tartalom törlődött, a megsemmisítés csak ez után folytatódik. Ezt a selejtezési ütemterv szolgáltatás vezérli.

32 Minta metaadat szolgáltatás
Mintaszolgáltatás Átjárhatóság Rendszer és környezeti metaadatok Sablonok Megfelelés a mintaszolgáltatásnak Mivel mintaszolgáltatás, ugyanazok vonatkoznak rá, mint a szerepkör szolgáltatásra. Van adva egy minta, amit implementálva működni fog, de igazából az adaptálóra van bízva. Átjárhatóság: legfontosabb követelmény Cél: metaadatok minden rendszerben ugyanúgy legyenek értelmezve. Példa: WWW Ez az előirányzat az iratkezelő rendszereknél is. A Moreq2010 szigorúbb mint a korábbiak, meghatározza a metaadatok kezelésének megsemmisítésének pontos módját is. Egy szabványos metaadat modellt ad, amit a megfelelő rendszerek használhatnak Rendszer: az egyedekhez szükséges metaadat elemek Környezeti metaadatok: a rendszerben nincsenek definiálva, a felhasználó teszi ezt meg. (pl digitális fotó felbontása) Tartozik hozzájuk egy definíció, és kapnak egy értéket. Probléma: a létező rendszerek már használhatnak egy eltérő metaadat modellt Sablonok: nem egyesével kell az egyedekhez hozzárendelni a kö.met.el.-eket, hanem a sablonhoz kell sokat, és a sablont az egyedhez. Vagy implementálod a mintát, vagy demonstrálod, hogy egyenértékű, és exportkor az XML sémában szereplő formátumra konvertálod.

33 Egyed kapcsolatok Osztály-példány viszony a programozásban.
Elmagyarázni az ábrát. Nagyjából: minden egyednek egy egyedtípusa van, és minden elemnek egy elem definíciója. Egy definícióhoz, és típushoz több pédány is tartozhat.

34 Selejtezési ütemterv szolgáltatás
Törlés és megsemmisítés Törlés Csak, ha nincs használatba véve Megsemmisítés Csonkolás Maradványegyed Volt már róla szó korábban, pontosítjuk. Különbség van törlés és megsemmisítés között. Mikor nincs használatba véve az egyed? Hasonló mint a mikor nincs megsemmisítve az egyed. Nincs kitöltve az első használat metaadata. Nyom nélkül eltűnik, mintha nem is létezett volna. Maradványegyed marad vissza, korlátozott metaadatokkal. Két okból korlátozott: tárolókapacitás, visszaállíthatatlanság.

35 Selejtezési ütemterv szolgáltatás
Irat életciklus

36 Selejtezési ütemterv Selejtezési ütemterv tevékenységek:
Végleges megőrzés A megőrzési időszak végén ellenőrzés A megőrzési időszak végén transzfer A megőrzési időszak végén megsemmisítés Megőrzési időszak meghatározása A selejtezés megerősítése Alulról felfelé megsemmisítés Ütemterv: mikor kell selejtezni az adott elemet. Meddig maradhat meg az iratkezelő rendszerben az egyed. Megsemmisíteni csak a selejtezési folyamat alatt lehet. Minden iratnak rendelkeznie kell selejtezési ütemtervvel! Elmondani mi a 4 verzió. Nap pontosságú legalább de napokban, hetekben, hónapokban, években szokás meghatározni. Egy nap egyszer számolják ki Selejtezési ütemterv változtatásakor újra kell számolni. Az idő kiszámításának alapja: Keletkezési Dátum/idő A Megőrzési időszak mellett: megerősítési időszak. Meg kell erősíteni a megsemmisítést. Transzfer: két megerősítési időszak. Egy hogy a transzfer be lett e már fejezve, egy hogy a eredeti helyen meg lettek e már semmisítve. Átlépéskor figyelmeztetést küld az MCRS. Gyűjtemények megsemmisítése. A selejtezési folyamatot egy folyamatábra segíti, mint a rendőröknek, hogy mikor kell megbírságolni a delikvenseket, ha külföldi a rendszámuk.

37 Selejtezési visszatartás szolgáltatás
Jogi, vagy adminisztratív szabály Irat, gyűjtemény, osztály Hatásai Selejtezési visszatartás feloldása Centralizált megvalósítás Megakasztják a selejtezési folyamatot. Csak addig gátolják, amíg nincsenek megsemmisítve. Például: Vizsgálat indul a cég ellen egy projekt miatt, ekkor a rendőrség, bíróság stb. elrendelheti az iratok megtartását. Közvetlenül a selejtezés előtt akasztják meg a folyamatot, ettől még az ellenőrzés, export lehetséges. Egyszerre akár több s.v. is érvényben lehet. Feloldás: a visszatartás megsemmisítése. Ki lehet vonni bizonyos iratokat a feloldás hatálya alól, de ez általában csak azért szükséges, mert véletlenül lett bevonva az eslő lépésben is. Megsemmisítés után maradványegyed szintén visszamarad. Ha véletlenül lett feloldva, újat kell létrehozni, de ekkor már valószínűleg a megakasztott selejtezések végbemennek. Az architektúra miatt lehetséges.

38 Keresési és riportálási szolgáltatás
Egyedek „felfedezése” Keresési módok Szöveg keresése Keresési eredmények Biztonság Keresések mentése Jelentések Jelentések mentése 2 mód: böngészés, keresés, vagy esetleg ezek kombinációja Keresés: szofisztikáltabb nagy rendszerben, olyan elemeket is meg lehet találni, amit böngészéskor nem biztos. MoReq2010: minden rendszernek rendelkeznie kell keresőmotorral (metaadat értékekben keres). Keresés legfontosabb követelményei: konzisztencia, teljesség Sokszor végrehajtva a keresést, ugyanazt az eredmény kapjuk, feltéve, hogy nem volt változás az adatokban. Egyedtípusra, keresési feltétel alapján adattípusra, fulltext kereséssel a szöveges metaadatokban, kombinálni Szöveges metaadatok, karakteres alapú, de nem szöveges (azonsoítók) Fulltext keresés: Google (ragozás eltávolítása, kötőszavak eltávolítása stb.) Keresési eredmények: Egyed lista. Rendezhető a tulajdonságok alapján, beállítható mit lehessen látni. Megjelenítése nincs megszabva, de érdemes táblázatos formában. Hozzáférés vezérlések: Ne láthasson már olyan dolgokat kereséssel, amihez nincs jogsija. Mentés: nem MoReq2010 egyed a mentett keresés, tehát exportban nem szerepel, és nem az eredmény van elmentve, hanem a feltétel. Jelentés: összegző, részletes Részletes: egy feltétel sok keresési eredmény, táblázatos forma Összegző: sok feltétel, találatok száma

39 Export szolgáltatás Export célja Export okai Részleges export
Transzfer Migráció Másodlagos hosting Replikáció Részleges export XML használata Egyedek importálása Exportálás nem megfelelő rendszerből Átjárhatóság biztosítása. Adatokat át tudjuk tenni egy másik rendszerbe. Alapelv: veszteségmentes export. Részleges export: csak néhány metaadat, esemény, hozzáférési info, kapcsolódó elem lesz exportálva. Veszteséges. Csak ajánlott a támogatása. A MoReq2010 megadja a használandó XML sémát. A XML hátrányai jelentkeznek: kis adatoknál jó, de nagy mennyiségűeknél probléma: adatfájl méret határok, XML esetleges tömörítése. Sebezhetőség Új technológia: XML adatfolyam Importálás: nem alapvető követelmények egy MCRS-nek. Bár tud importálni az MCRS-ekből, a régi rendszerekhez céleszköz kell úgyis. Ezért csak az export kötelező, hogy ne legyen a rendszer adatcsapda. Adaptorok kifejlesztése: exportálni tudja az iratkezelő rendszer adatait MoReq2010 formátumba. Ezzel annyira nem foglalkozik a M2010, de az XML séma adott, így hajrá.

40 Export szolgáltatás Teljes Környezet exportálása
Rendszer és környezeti metaadatok Hivatkozott egyedek Részegyedek ACL-ek (a tényleges, a fontos és a kapcsolódó egyedeké) Az ACL-ek által hivatkozott felhasználók vagy csoportok Eseménytörténet Rendszerazonosítók által hivatkozott egyedek

41 Export szolgáltatás Kapcsolódó egyedek exportja
Rendszer metaadat elemek Fontos egyedek ACL (a tényleges egyedé és a fontos egyedeké) Az ACL-ek által hivatkozott felhasználók vagy csoportok Helyőrzőként! Metaadatok exportálása: környezeti metaadat elem: definíció+érték

42 Export szolgáltatás Egy gyakori export cél. Jól mutatja, hogy mit hogyan kell exportálni. Elmagyarázni az ábrát.

43 Nem funkcionális követelmények
Teljesítmény Rendelkezésre állás Skálázhatóság Megbízhatóság Kezelhetőség Visszaállíthatóság Hordozhatóság Karbantarthatóság Biztonság Támogatottság Adatvédelem Biztosság Használhatóság Megfelelés Hozzáférhetőség Nem határozott követelmény, inkább kérdés a beszállító felé. Teljesítmény: mennyi idő alatt tud végrehajtani egy műveletet a rsz terhelés alatt. Nagyban függ az alátolt vastól. Ne várjunk csodát egy WinXPtől 1 giga rammal, ha 500-an akarjuk kezelni a rendszert. Skálázhatóság: a terhelés elosztása növekvő adatmennyiség esetén. Felskálázás, oldalra skálázás. Kezelhetőség: Technikai: telepítés, monitorozás, bővítés Iratkezelési: adminisztratív jelentések, használati statisztikák Hordozhatóság: Különböző környezetekben való működés. Általában egy rendszer egy platformra épül. Mennyire lehet működésre bírni különböző hardverkiépítésű környezetekben. Biztonság: belső integritás megőrzése, támadásoktól való védelem, véletlen károkozás, vagy rongálás elleni védelem. Ideális rendszer: fizikailag, adatügyileg biztonságos, illetéktelen behatolás ellen véd, biztoságos kommunikáció, belső biztonság (ACL-ek) Adatvédelem: személyes adatok védelme, különösen fontos pl kórházaknál. Használhatóság: a felhasználók mennyire szenvednek tőle/vele. Milyen könnyű megtanítani? Hozzáférhetőség: bármilyen fogyatékossággal rendelkező ember férhessen hozzá. Milyen százalékban elérhető a rendszer? Milyen a támogatása? Milyen gyakran vét hibát? Mennyire pontos? Hiba vagy katasztrófa esetén mennyire könnyű, illetve mennyire lehetséges visszaállítani az eredeti rendszert? A rendszer mennyire egyszerűen javítható? A pathchek mennyi szívással telepíthetőek? Milyen support elérhető? Telefonos? Kijönnek e? A beszállító biztosítsa a rendszerműködését, és a hibáit javítsa, és ha esetleg a beszállító nem foglalkozik tovább a termékkel akkois legyen legalább egy forráskód ami támpontot ad a felhasználó szervezetnek. Milyen szabványoknak felel meg a rendszer?

44 Q&A

45 KOVEX-COMPUTER KFT. Köszönöm a figyelmet!
Az előadás a „Dokumentum- és tudáskezelés domain specifikus nyelvre (DSL) alapozva (EDMS&KMS)” c. projekt (GOP / ) keretében készült.