Planning and Design of Information Systems. André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987.



Hasonló dokumentumok
Információs rendszerek elméleti alapjai. Információelmélet

Planning and Design of Information Systems. 3. Előadás Minőség: normák és garanciák Dekomponálás

Információtartalom vázlata

Információs rendszerek Információsrendszer-fejlesztés

rendszerszemlélető, adatközpontú funkcionális

Nyilvántartási Rendszer

Adatmodellezés. 1. Fogalmi modell

Vezetői információs rendszerek

ADATBÁZIS-KEZELÉS. Adatbázis-kezelő rendszerek

Szoftvertechnológia ellenőrző kérdések 2005

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

Szoftver-mérés. Szoftver metrikák. Szoftver mérés

A szoftverfejlesztés eszközei

S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method

Programozás. Bevezetés. Fodor Attila. Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék

Adatbázis-kezelés alapjai 1. Ea: Infó Mátrix. Lehet, nem lehet

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

AZ ELőADÁS CÉLJA. a funkciók dokumentálásának bemutatása. az SSADM szerkezetben elfoglalt helyének bemutatása

VÁLLALATI INFORMÁCIÓS RENDSZEREK. Debrenti Attila Sándor

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

Történet John Little (1970) (Management Science cikk)

Magas szintű adatmodellek Egyed/kapcsolat modell I.

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique)

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Szoftver-technológia II. Modulok és OOP. Irodalom

Adatbázis-kezelés. alapfogalmak

Már megismert fogalmak áttekintése

Programfejlesztési Modellek

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

Bevezetés a programozásba

Eseménykezelés. Szoftvertervezés és -fejlesztés II. előadás. Szénási Sándor.

Web-programozó Web-programozó

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

Nagy bonyolultságú rendszerek fejlesztőeszközei

Magyar Projektmenedzsment Szövetség

Kölcsönhatás diagramok

1. előadás Alapfogalmak Modellezés, a Bachman-féle fogalomrendszer, adatmodell,

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység

Adatbázis rendszerek. dr. Siki Zoltán

Projectvezetők képességei

Járműinformatika A járműinformatikai fejlesztés

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Programozási technológia

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

DW 9. előadás DW tervezése, DW-projekt

Térinformatika amit tudni kell Márkus Béla

Adat és folyamat modellek

Szoftver-technológia I.

Projektfolyamat. ELŐADÁS ÁTTEKINTÉSE 2. ea.: Projekt Ciklus Menedzsment (PCM) PROJEKT ÉLETCIKLUS (1-2)

Java programozási nyelv

Adatmodellezés, alapfogalmak. Vassányi István

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Informatikai Intézet Alkalmazott Informatikai Intézeti Tanszék

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Dr. Topár József 3. Eladás Marketing Külső szolgáltatás Alvállalkozók Fogyasztók. Engineering Termelés Anyagszabályozás Beszerzés Minőség

Szoftver újrafelhasználás

Adatbázisok 1. Az egyed-kapcsolat modell (E/K)

Bevezetés a párhuzamos programozási koncepciókba

ADATBÁZIS ALAPÚ RENDSZEREK

Adatbázis rendszerek. 4. előadás Redundancia, normalizálás

IKT megoldások az ipar szolgálatában

BGF. 4. Mi tartozik az adatmodellek szerkezeti elemei

Dr. Mileff Péter

Autóipari beágyazott rendszerek. Funkcionális biztonságossági koncepció

Szoftver tervezés és design

ABAP dictionary objektumok SAP adatmodell Táblák kezelése. Az SAP programozása 1. Tarcsi Ádám

Szekvencia diagram. Szekvencia diagram Dr. Mileff Péter

Indikátorok projekt modellhelyszínein. Domokos Tamás szeptember 13.

A fejlesztési szabványok szerepe a szoftverellenőrzésben

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél

Szolgáltatás Orientált Architektúra a MAVIR-nál

Adatmodellek. 2. rész

AZ INTÉZMÉNYFEJLESZTÉSI TERVEK ÉRTÉKELÉSI SZEMPONTRENDSZERE

Rendszer-modellezés, modellezési technikák

IRÁNYTŰ A SZABÁLYTENGERBEN

Belső ellenőrzés és compliance. szolgáltatások. Cover. KPMG.hu

Rendszer-modellezés, modellezési technikák

Követelmény meghatározás. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1

A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN

01. gyakorlat - Projektalapítás

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Önálló labor feladatkiírásaim tavasz

Informatika tanári mesterszak

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Szabálykezelés a gyakorlatban

Automatikus tesztgenerálás modell ellenőrző segítségével

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata

Adatbázis-kezelő rendszerek. dr. Siki Zoltán

kodolosuli.hu: Interaktív, programozást tanító portál BALLA TAMÁS, DR. KIRÁLY SÁNDOR NETWORKSHOP 2017, SZEGED

A szoftverfejlesztés eszközei

A Jövő Internete - általános tervezési ajánlások

Zöld Sándor. Műszaki informáci szeptember 6.

Interfészek. PPT 2007/2008 tavasz.

Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer

Eladásmenedzsment Bauer András, Mitev Ariel Zoltán

IT Szolgáltatás Menedzsment az oktatási szektorban - 90 nap alatt költséghatékonyan

Dr. Kulcsár Gyula. Virtuális vállalat félév. Projektütemezés. Virtuális vállalat félév 5. gyakorlat Dr.

Erőforrás gazdálkodás a bevetésirányításban

Átírás:

Planning and Design of Information Systems André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987.

4.3 A tervezés határai Mi a tető, mi a lent, mi a centrum - tisztázni kell előre. A 4 modell milyen részlet szintjén készül? 2 fő határ: A külső határ: Mi tartozik az IR-hez, vagy alkalmazási rendszerhez. A belső határ, vagy leírási határ: A szint, a részlet, ahol T-D megáll, ahonnan B-U indul, amelyik szintre a C-O készül. Torta szelet szemléltetés. Kész egy szeletelés, a következő gyűrű milyen szintre, részletességre készüljön? Az integritás betartása hogy teljesül? Teljes IS - teljes szemlélete egy rendszernek. Vagy egy része, amit alkalmazási rendszernek nevez.

4.3.1 Információs Rendszer tervezés határai A külső határ - az egészre vonatkozik, amire az IR hatása kiterjed. Lehet a teljes szervezet: vállalat, minisztérium, megye, stb. Lehet nagy szervezet része is. A belső határ: külön részletesen elemezi a III. rész a könyvben. Itt általános javaslat: független (információs) rendszer: egy homogén gazdasági objektum teljes életciklusát lefedő rendszer. (l. dekomponálás) A belső határ mozoghat, időlimit hatása, sok részlet magas minőség Másik belső határ: egy alkalmazás(i rendszer), egy menetben kivitelezhető rész, (50 felhasználói feladat, másfél év) Ezek a határok a Szervezeti és Információ modellre. Az Adatmodell a teljes szervezetre épül, alsó határ: az entitások. Külső határ megegyezik az SZR, IR külső határával.

4.3.2 Alkalmazás tervezése Szervezeti modell Külső határ: a független rendszer, vagy egy része, az alkalmazás Belső határ: kézmozgásig - túl finom, (mozdulattervezés), a munka módszere és felosztása fontos, a jó szint: a felhasználói feladat, független eljárás. Információ modell Választás külső határra: alkalmazás külső határ, vagy felhasználói feladat Jó elv: párhuzamosság SZM és IM között a felhasználói feladatokig, ezért IM külső határa a független eljárás legyen, addig implicit SZM-ből. Belső határ: - információ elv: teljes információ egy felhasználói feladathoz. Túl összetett. (Mai technikák támogatják!) - elemi üzenet (Langefors) /elég egyértelmű, mi elemi/ Mennyi? 8. Mi 8? Mi mennyi? Üzenetnév(Tárgy, tulajdonság, idő)

Adat modell Külső határ: teljes szervezet - független IR - alkalmazás Integráltság - legalább a független IR a határ. (FIR) Belső határ: bonyolult vita, szubentitás - szuperentitás - entitás izoláció, többszörös birtoklás optimalizálása FIR-ek között. Javasolt határ: adatelem (amit már az alkalmazás nem bont fel) Eljárás (processz) modell Külső határ lehet: FIR, alkalmazás, felhasználói feladat, független eljárás, elemi eljárás (:egyetlen elemi üzenet a kimenete.) Elemi lejárás túl finom, az inkább jó belső határnak. Az a dekomponálás legalsó szintje. Belső határ: programozási nyelvi szint. A 24. Ábra minden doboza olyan szintet reprezentál, amelynek meg kell jelennie a tervezésben.

4.3.3 Választási feladatok Minden modellhez, bármely részletek között készül, választani kell: 1. Egy vagy több komplexitás kezelési stratégiát, sorrendjüket a modellezés során. 2. Egy technikát: megelőzési analízis, követési analízis, funkcionális dekomponálás, stb. 3. Jelölést: adatáramlási diagram, HIPO diagram, döntési tábla, stb. 4.4 Választott megoldások (a könyvben) Csak leírják - indoklás, motiváció a részletek kifejtése során lesz. 1. Teljes szervezet FIR, alkalmazásig: ( III. fejezet - ISP) - A szervezet, üzleti-gazdasági eljárások: C-O, követési analízis, grid ch. - Az (információs rendszer) architektúra: B-U, megelőzési anal., grid ch. - Az adatmodell: C-O adatmodellezés.

2. Az alkalmazás szervezeti modellje: (Part IV) C-O követési analízis felhasználói feladat szinten, arra építve B-U szintézis alrendszerekig, szgépes grid charting, megelőzési gráf jelölés. 3. Az alkalmazás információ modellje: (Part V) T-D a felhasználói feladatoktól (független eljárásoktól) az elemi üzenetekig és eljárásokig, megelőzési analízis és megelőzési gráf jelölés. 4. Az alkalmazások adatmodellje: a. Vázlatos fogalmi adatmodell, C-O adatmodellezéssel. b. Adatelem definiálás: T-D elemi üzenettől adatelemig, komponens analízis és komponens leírás. c. Fogalmi adatmodell: adatszintézis, B-U az adatelem szinttől az információs rendszer szintjéig. d. Végső adatmodell: normalizálás. 5. Az alkalmazások eljárásmodellje: a. A komponens leíráshoz adjuk az elemi eljárás algoritmus leírását, ha összetett, döntési tábla. b. A felhasználói. feladat eljárása: T-D elemi eljárásig, strukturált eljárások, és Nassi- Shneiderman diagram. (struktogram)

A 25. Ábra szemléltető összefoglaló. A tortaszelet - gyűrű elv szerint a következő fázisok ismerhetők fel: A teljes szervezet: teljes - FIR - alkalmazások: a szeletek. Az alkalmazások szervezeti modellje: az alkalmazások és felhasználói feladatok, független eljárások között: szeletek. Az információ modell: új gyűrű. Szeletek független eljárások és elemi üzenetekre, eljárásokra. Az adatmodell: új gyűrű. Nincsenek szeletek, entitások és relációk azonos szinten. (Mai OODB, XML új elveket hozhat be.) Az adatelemek következő finomsági szint. Ez az alkalmazások és adatelemek közötti modell. Nincs benne alrendszer, nincs új szeletelés. Az eljárás modell: új gyűrű. Szeletek a független eljárások és elemi eljárások között, új szeletek az elemi eljárások és algoritmusok között.

5.0 Egyéb kritériumok 5.1 TELJESSÉG ÉS REDUNDANCIA 25. Ábra: nincs minden doboz lefedve. Teljesség- implicit definiálások. Például: Szervezeti modell az információs modellt is leírja, független eljárásokig. Minden leírható elemezhető - technika, jelölés kérdése. Teljesség: impliciten - expliciten. Kérdéses: a redundancia a modellekben. Teljes redundancia-mentesség nem lehet - kell a modellek között kapcsolat, kellenek interfészek a modellek köözött, vagy egy módszer lépései között. Kell redundancia a teljesség miatt - részek átdolgozása, újrakészítése - nincs átmenet a jelölés, technika alapján a lépések között - új aspektus nem vezethető le az eddigiekből

5.2 Konzisztens filozófia a technikákban alapfilozófia választás - ne változzon a módszer során mit kell elkerülni ezzel: - nyelvek összekeveredése a fázisok, specialisták között - redundancia növekedése, ami a filozófiák közötti fordításhoz kell Például: rendszer-szemlélet - fekete doboz elv, maradjon végig: inputok és outputok, majd komponens analízis szervezeti modell: I-O: személy, anyag, információ információs modell: I-O: információ adat.modell: felhasználói szemléletek eljárás modell: I-O: személyek, é/v anyag, é/v adat, é/v információ attól függően, mit dolgoz fel. Ugyanez implementáláshoz is ajánlott. Kritikák: Funkcionális szemlélet - az adatmodellre nem jó. Adat-szemlélet: az eljárás modellt kell utólag hozzáépíteni.

5.3 Minőségi kérdések A tervezés két alapvető kérdése: a minőség és a produktivitás. Először a minőség jön - mi a minőség? Az IR 3 minőségi kérdése és a termék, gyártási minőség. 1) a felhasználók elvárásának, igényének kielégítése 2) flexibilitás 3) hordozhatóság 1) a tervezők és a felhasználók - két külön világ IR technikai minősége a felhasználók elfogadása (hatékonyság, DP szak- ez kérdéses! emberek kezében.) - felhasználók részvétele tervezés, célkitűzés során -érthető technikai jelölés; világos, megfelelő felhasználói oktatás -kommunikációs technika a fentiek hatékony megvalósításához

2) flexibilitás: kibővíthetőség és karbantarthatóság +igények - bevezetés után tanulás - új igény merül fel várhatóan. Lehet valamennyire csökkenteni - pl- prototípussal, tervezési technikával- Fel kell készülni fogadására, megoldására - kibővíthetőség, fenntarthatóság. Hogyan érhető el? Függetlenségre törekvéssel. Az IR részei, mint részrendszerek lehető legfüggetlenebbek legyenek. Coupling/binding (cohesion/strength) csatolás/kötés 3) hordozhatóság - a kialakítási befektetés maradjon meg a jövő felhasználói, tervezői, programozói számára. Meg kell őrizni a rendszerre vonatkozó ismereteket! Kell: elérhető, olvasható, aktuális dokumentáció! (Aki csinálta könnyebben érti, mint más.) Nehéz jól megoldani. Rövidre zárt módosítások dokumentálás nélkül - gyakori hiba! Lehetőségek: -módosítás menedzsment, -módosítás csak dokumentáción keresztül.

5.3.1 Kötési (egybetartozási) szabályok Részrendszeren belül: homogén feladatok - egyszerű vezetés szétszórt, sokféle feladat - bonyolult A következő ábra a gyengétől az erős felé halad. esetleges logikai idő szerinti kommunikációs eljárási funkcionális Gyenge kötés Erős kötés

-esetleges kötés: a részek között nincs felismerhető szabályszerűség -logikai kötés: hasonló jellegűek, de mindig csak egy aktív -idő szerinti kötés: olyan részek, amelyek egy időben indulnak/hajtódnak végre -kommunikációs kötés: a rendszer tevékenységei ugyanazt az entitást használják. (közös alkatrész raktár, közös adatbázis) -eljárási kötés: a rész(tevékenység)ek előre adott sorrendben hajtódnak végre -funkcionális kötés: minden rész ugyanazt a célt szolgálja T-D dekomponálás: a végén erősen kötött rendszerek keletkezzenek, közben nem feltétlenül! Ha nem ez a végeredmény - gyenge minőségű a módszer.

5.3.2 Csatolási szabályok A (rész)rendszerek közötti ( külső) összekötés. A csatolás erősségét a rendszerek közötti kommunikáció típusa adja. Minél egyszerűbb a kommunikációs, annál egyszerűbb a csatolás. Ha sok információ kell egy rendszer informálásához, a csatolás erős. Példa: TV vásárlás - lakás vásárlás. Vevő - eladó kommunikációja. Csatolás kielégítési külső kontrol közös adat/anyag Erős csatolás Gyenge csatolás

-kielégítési csatolás: egy rendszer részét hívja egy másik rendszer, vagy része. Ehhez ellenőrzési információ kell, hogy az eredeti rendszerhez a megfelelő pillanatban térjünk vissza. -külső csatolás: megváltoztatják egy rendszer végrehajtását külsők által, azok ellenőrzése alatt, a megváltoztatott rendszert nem informálják, mi történik. -vezérlési csatolás: egy rendszer végrehajtását két vagy több rendszer ellenőrzi. Az ellenőrzött tudja, ki ellenőrzi éppen. -közös (használati) csatolás: két vagy több rendszer használ egy másik rendszert, amely ellenőrzi saját erőforrásait. -adat/anyag csatolás: A kapcsolat a rendszerek között mindössze adat vagy anyag átadása.