Számvitelszervezés Gyurkó György.

Slides:



Advertisements
Hasonló előadás
Tamás Kincső, OSZK, Analitikus Feldolgozó Osztály, osztályvezető A részdokumentumok szolgáltatása az ELDORADO-ban ELDORADO konferencia a partnerkönyvtárakkal.
Advertisements


Kamarai prezentáció sablon
ADATBÁZISOK.
Projekt vezetés és kontroll – Mi történik a gépházban?
4. gyakorlat Normalizálás.
Szoftverminőség, 2010 Farkas Péter. SG - Sajátos célok  SG 1. Termék / komponens megoldás kiválasztása  SP 1.1. Alternatívák és kiválasztási kritériumok.
Adatbázis-kezelés.
Erőállóképesség mérése Találjanak teszteket az irodalomban
Objektumorientált tervezés és programozás II. 1. előadás
Szoftvertechnológia Gyurkó György
Humánkineziológia szak
Fontosabb fogalmak Képesség :
2. Rendszer fejlesztés
1Objektumorientált elemzés és tervezés – Dinamikus modellezés Gyurkó György Objektumorientált elemzés és tervezés Dinamikus modellezés.
Microsoft Access V. Készítette: Rummel Szabolcs Elérhetőség:
Utófeszített vasbeton lemez statikai számítása Részletes számítás
A tételek eljuttatása az iskolákba
OBJEKTUMORIENTÁLT PROGRAM
Elektronikai Áramkörök Tervezése és Megvalósítása
Minőségmenedzsment 1. előadás
Minőségmenedzsment 2. előadás
2011. szeptember Az információtechnológia menedzselése Az információs rendszer fejlesztése Image of the slide: www2.raritanval.edu/departments/busadmin/.../Ch07-IntrotoBusiness.ppt.
2011. szeptember Az információtechnológia menedzselése Az információs rendszer fejlesztése Image of the slide: www2.raritanval.edu/departments/busadmin/.../Ch07-IntrotoBusiness.ppt.
ERD - feladatok szeptember Egyed-kapcsolat diagram (ERD)
Védőgázas hegesztések
Gazdasági informatika II.
Gazdasági informatika II.
1Gazdasági informatika II Gazdasági informatika II. Gyurkó György.
1. előadás. 1.) Szoftverfejlesztés, mint mérnöki tevékenység. Számítási eszközfejlődés. Számítási eszközfejlődés: hazai viszonyok. Mérföldkő: Simula 67.Klasszikus.
1. előadás. 1.) Szoftverfejlesztés, mint mérnöki tevékenység. Számítási eszközfejlődés. Számítási eszközfejlődés: hazai viszonyok. Mérföldkő: Simula 67.Klasszikus.
Megvalósíthatóság és költségelemzés Készítette: Horváth László Kádár Zsolt.
Szerkezeti elemek teherbírásvizsgálata összetett terhelés esetén:
Szoftvertechnológia Szoftvergyártás 2..
Szoftvertechnológia Rendszertervezés.
WEB MES (webes gyártásirányító rendszer) Kiss Miklós (G-5S8)
Komplex rendszertervezési módszerek
DRAGON BALL GT dbzgtlink féle változat! Illesztett, ráégetett, sárga felirattal! Japan és Angol Navigáláshoz használd a bal oldali léptető elemeket ! Verzio.
Anyagadatbank c. tárgy gyakorlat Féléves tematika Adatbázis alapfogalmak, rendszerek Adatmodellek, adatbázis tervezés Adatbázis műveletek.
Objektumorientált tervezés és programozás II. 3. előadás
szakmérnök hallgatók számára
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN
1 Informatikai Szakképzési Portál Adatbázis kezelés Alapfogalmak.
Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT
2007. május 22. Debrecen Digitalizálás és elektronikus hozzáférés 1 DEA: a Debreceni Egyetem elektronikus Archívuma Karácsony Gyöngyi DE Egyetemi és Nemzeti.
A pneumatika alapjai A pneumatikában alkalmazott építőelemek és működésük vezérlő elemek (szelepek)
Rendszertervezés Alapfogalmak; Az informatikai rendszer
Csurik Magda Országos Tisztifőorvosi Hivatal
A klinikai transzfúziós tevékenység Ápolás szakmai ellenőrzése
QualcoDuna interkalibráció Talaj- és levegövizsgálati körmérések évi értékelése (2007.) Dr. Biliczkiné Gaál Piroska VITUKI Kht. Minőségbiztosítási és Ellenőrzési.
Adatbázis-kezelés.
1. Melyik jármű haladhat tovább elsőként az ábrán látható forgalmi helyzetben? a) A "V" jelű villamos. b) Az "M" jelű munkagép. c) Az "R" jelű rendőrségi.
Adamkó Attila UML2 Adamkó Attila
Szoftver születik Eötvös Konferencia Köllő Hanna.
Információs rendszer fejlesztése 4. előadás
Információs rendszer fejlesztése 2. előadás
Programozás, programtervezés
Információs rendszer fejlesztése 5. előadás
Adatbáziskezelés. Adat és információ Információ –Új ismeret Adat –Az információ formai oldala –Jelsorozat.
Információs rendszer fejlesztése 1. előadás
Gyurkó György. Az OO programozás és tervezés története 1960-as évek: SIMULA (véletlen folyamatokat szimuláló programok írása) az OO nyelvek őse 1970-es.
Szoftvermenedzsment A szoftver fogalma programmodulok rendszerdokumentáció konfigurációs adatok, és ezeket tároló fájlok felhasználói dokumentáció a szoftver.
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method.
INFORMÁCIÓMENEDZSMENT Dr. Szalay Zsigmond Gábor adjunktus, intézeti tanszékvezető VEZETÉS ÉS SZERVEZÉS MSC SZAK SZENT ISTVÁN EGYETEM.
A szoftver mint komplex rendszer A fejlesztési módszertanok általános céljai: Összetett problémák kezelhetővé tétele A fejlesztési és megtérülési jellemzők.
1 SZAKKÉPZÉSI ÖNÉRTÉKELÉSI MODELL (SZÖM) 1 2 A SZAKKÉPZÉSI ÖNÉRTÉKELÉSI MODELL Komplex eszköz a teljes körű intézményi önértékeléshez, és ez által az.
Önértékelési projektterv
Adatbázis alapismeretek
Relációs adatmodell, normálformák
Adatbázis-kezelés 2. Relációs adatbázisok.
Előadás másolata:

Számvitelszervezés Gyurkó György

A könyvvizsgáló mint az információs rsz. fejlesztője

A szoftverfejlesztési folyamat

A fejlesztési folyamat az ISO 12207 szerint

Az IR fejlesztésének főbb tevékenységei Ezek minden életciklusmodellben megjelennek: Elemzés Tervezés Megvalósítás, tesztelés, integráció Bevezetés

Elemzés Cél a követelmények meghatározása A létező rendszer folyamatainak megfigyelése, elemzése Dokumentumok tanulmányozása Kérdőíves felmérés Interjúk a szakterület specialistáival, a felhasználókkal Termékek: Elemzési modellek Követelményleírások Rendszerszervezési változatok

Követelményleírások szerkezete

Rendszerszervezési változat A követelmények olyan részhalmaza, amely a projekt korlátai mellett teljesíthető és konzisztens (ellentmondásmentes és hivatkozásteljes) Megjegyzés: Kivételesen a fejlesztés (tervezés, megvalósítás) alatt megengedhetők ellentmondó követelmények is, de legkésőbb a szoftver telepítésekor el kell dönteni, hogy közülük melyik érvényes. Tehát ilyenkor a szoftvert fel kell készíteni a telepítési időre halasztott – és már a felhasználó által hozott - döntések fogadására.

Tervezés A szoftvertervezés termékei: szakterületi (termék)modell: a szakterület fogalmainak, objektumainak, viszonyainak közvetlenül megfeleltethető absztrakciókat tartalmazó modell; architektúramodell: a tervezés és a megvalósítás struktúráját és követendő mintáit és az architekturális komponensek interfészeinek specifikációit tartalmazó modell; termékterv: nagyvonalú rendszer-, illetve szoftverterv, funkcionás modulok között interfészek specifikációk, valamint részletes szoftverterv; tesztspecifikációk: egységtesztekre, integrációs tesztekre, validáló tesztelésre; megoldásmodell: az architektúramodellt maradéktalanul érvényesítő részletes szoftverterv.

Tervezés / 2 A szoftvertermék elemezhetőségét, változtathatóságát, tesztelhetőségét, stabilitását, hordozhatóságát, valamint a komponenseinek újrafelhasználhatóságát szolgáló alapvető tervezési (konstrukciós) elv: Egymástól függetlenül előforduló problémákat nem szabad egyazon megbonthatatlan építőelemben megoldani!!! A problémák függetlenségének felismerését segítő osztályozási szempontok: szintek és vetületek - a strukturált megközelítés szerint; szintek, rétegek és minőségek – a korszerűbb módszertanokban.

Felhasználói felület / Környezet, események A szoftvertervezés szintjei és vetületei a strukturált megközelítés szerint Vetületek Szintek Adat Feldolgozás Felhasználói felület / Környezet, események Fogalmi szint A szakterületi igények, szabályok figyelembevétele A kiszolgált szakterület adatai és ezeknek a szakterület szabályaiból következő kapcsolatai. Mit?: Milyen szolgáltatásokat kell nyújtani a rendszernek? Ennek érdekében milyen funkciói lesznek? (A funkciókat mint fekete dobozokat leíró specifikációk.) Szűkebben: az ember-gép kapcsolatra vonatkozó elképzelések. Tágabban: a környezet azon eseményei, amelyekre a rendszer reagál. Logikai szint Hatékonysági, biztonsági szempontok és szervezeti korlátok figyelembevétele Informatikai hatékonysági, biztonsági szempontok miatt szükséges további adatok, adatkapcsolatok. A szervezeti korlátokat is figyelembe vevő struktúra. Hogyan?: A megoldás – az egyes funkciók működésének – részletes megtervezése. Szűkebben: a felhasználói felület, párbeszédek részletes megtervezése – minden előtérfunkcióhoz. Tágabban: részletes eseménymodellek – a rendszer és a környezete interakcióinak megtervezése. Fizikai szint A technikai környezet sajátosságainak, korlátainak figyelembevétele Konkrét adatbázis-kezelő rendszer képességeit kihasználó és korlátait figyelembe vevő tervezés. Operációs rendszer, programnyelv, fejlesztő környezet, üzemeltető környezet sajátosságait figyelembe vevő tervezés. A párbeszédeszközök, konkrét kommunikációs kapcsolatok sajátosságait figyelembe vevő tervezés.

Egy finomabb rendszerezés: A SunTone módszertan architektúra-sémája Az alkalmazás minden építőeleme egy meghatározott szintbe, illetve rétegbe sorolható, és egy meghatározott minőségért felel.

Az elemzés és tervezés technikái, eszközei Grafikus modellezési technikák: tömörség, egyértelműség CASE (Computer Aided Software Engineering) eszköztár: a grafikus modellezési technikák integrált támogatása elektronikus formában készülő redundanciamentes konzisztens terv szabványok és módszertan követésének kikényszerítése (automatizált ellenőrzés) hatékony csoportmunka eszköze kódgenerálás, nyomtatott dokumentáció generálása

A fejlesztés további tevékenységei Kivitelezés (kódolás és egységtesztek) Integráció és integrációs teszt Minőségi teszt Szoftver telepítése, bevezetése a használatba a szervezeti folyamatok újraszervezése – a szoftver szakmai felhasználási környezetének kialakítása; a szoftver testreszabása; az üzemeltetési, technikai környezet kialakítása, a rendszer üzemeltetési környezetbe telepítése; adatmigráció, azaz a korábbi rendszer adatainak konvertálása és betöltése az új rendszer adatbázisába; a felhasználók kiképzése; próbaüzemi teszt, azaz üzemi környezetben tényleges volumenek és csúcsterhelés melletti teszt; átállás az új rendszerre

Életciklusmodellek

Vízesés modell

Vízesés modell / 2 Előnyei: - Világos struktúra. - A projekt egyszerűen ütemezhető, irányítható. Hátrányai: - Csak a szakaszok végén van visszacsatolás. - Feltételezi, hogy a követelmények pontosan ismertek és nem változnak. - Hosszú a fejlesztési idő.

V modell

V-modell / 2 Előnyei / hátrányai: - Többnyire azonosak az egyszerű vízesés modellével. - Az egyszerű vízesés modellnél világosabb képet ad arról, hogy adott tevékenység és annak terméke mely korábbi tevékenység termékének kell megfeleljen.

Iteratív fejlesztés Iteráció: Azonos tevékenység vagy tevékenységsor ismételt végrehajtása. Iteratív fejlesztés: Minden iteráció újabb minőséget ad az előző végrehajtás termékéhez. - Az iterációkat határozott célkitűzés, átfogó projektterv előzi meg. Nem önálló modell, hanem egy olyan, a célt fokozatosan közelítő megoldás, amelyet klasszikus életciklusmodellekkel kombinálva új életciklusmodellt kapunk. Iteratív fejlesztésen alapuló nevezetes modellek: az inkrementális modell a spirálmodell

Iteratív fejlesztés / 2 Az iteratív fejlesztés motivációi: kezelni, hogy kezdetben nem lehet ismert minden követelmény; számolni az ismert követelmények megváltozásával; különlegesen nagy kockázatú projekteket is kezelhetővé tenni (lásd spirálmodell); minél korábban szülessen egy működő, átadott verzió (lásd inkrementális modell); az előző iterációk során szerzett tapasztalatok felhasználásával a módszerek, a termékminőség folyamatos javítása (inkrementális modell); megbízhatóbb termék (inkrementális modell: előbbi következménye; spirálmodell: kifejezetten a minőségi kockázatok csökkentését célzó prototípusok).

Inkrementális modell - átlapolással

Iteratív és inkrementális modell

Inkrementális modell előnyei, hátrányai Kezelni tudja a követelmények változásait. Korán megszületik egy működő, átadott verzió (ez a projekt megítélése, a megrendelő elégedettsége szempontjából nagyon fontos); Az előző verziók fejlesztése és használata során szerzett tapasztalatok felhasználásával a módszerek folyamatosan javulnak, a követelmények finomodnak, a kockázatok csökkennek. A későbbi verziók egyre megbízhatóbbak (több tapasztalat, több sokszorosan kipróbált komponens a termékben). A teljes rendszer helyett csupán egy inkrementumot fejlesztő projekt akkor is elindítható, ha a szervezet szűkösebb emberi és pénzügyi erőforrásokkal rendelkezik. Elegendő erőforrások birtokában viszont az inkrementumok fejlesztésének átlapolásával a teljes rendszer fejlesztésének időtartama is csökkenthető. Hátrányai: Szűkös erőforrások esetén a teljes rendszer lassan készül el. A soklépéses folyamat és a párhuzamos tevékenységek irányítása nehéz feladat. A már működő részeket és a későbbi lépések eredményeit újra és újra integrálni kell.

További életciklusmodellek Az iteratív fejlesztés valamilyen változatai (pl. Boehm-féle spirálmodell) A kombinált iteratív-inkrementális modell változatai (pl. a Rational Unified Process – RUP-modell) A felhasználó és a fejlesztő közötti jobb megértést, a követelmények pontosabb meghatározását, valamint a fejlesztés gyorsítását szolgáló modellek (pl. egyszerű prototípusmodell és annak evolúciós fejlesztés nevű változata) A követelmények megváltozásával szemben különösen toleráns modellek (pl. agilis módszertanok - extrém programozás) A ráfordítások – megvásárolható kész komponensek beépítésével való – csökkentő modellek (komponens alapú fejlesztés) Az esetleges minőségi hiányosságok katasztrofális következményeinek kockázatát módszeresen csökkentő modell (pl. Boehm-féle spirálmodell)

Megközelítési módok és módszertanok

A (szoftver)fejlesztési megközelítési mód egy sajátos absztrakciós szemlélet, amelyből sajátos fogalomrendszer, eszköztár, elemzési (felbontási) és konstrukciós elvek következnek. A (szoftver)fejlesztési módszertan a fejlesztési folyamat minden architekturális összetevőjét lefedő, a kidolgozók által figyelembe vett célkitűzések és feltételek mellett legjobb gyakorlatnak szánt terméksémák, folyamatsémák és szervezeti sémák, valamint a felsoroltakhoz kapcsolódó értékelési (mérési) kritériumok együttese.

Megközelítési módok Moduláris Strukturált Objektumorientált

Módszertanok Alaptípusok: Folyamatvezérelt Eseményvezérelt Adatvezérelt Felhasználóvezérelt Az előbbieket kombináló kevert típusok: Hagyományos Objektumorientált

Az IR fejlesztésének módszerei, modellezési technikái

A szimbólikus modellek jelentősége A szöveges leírásnál lényegesen: tömörebb és egyértelműbb.

Modellezési technikák Rendszerfolyamatábra - tevékenységi diagram (UML) Adatszerkezet-diagram - IO-szerkezet diagram Egyed-kapcsolat diagram - ERD (adatmodellezés - relációs adatanalízis) Osztály- vagy objektumdiagram (sztatikus modellezés az UML-ben) Egyedéletrajz-diagram (SSADM eseménymodellezés) Állapotdiagram (dinamikus modellezés - az UML-ben) Eseményhatás-diagram (SSADM eseménymodellezés) Adatáramlási diagram (feldolgozástervezés, adattranszformációk tervezése - a rendszer felülről lefelé haladó funkcionális lebontása) Funkció-specifikáció (feldolgozástervezés, az egyes programfunkciók definiálása - ez egyben szöveges technika is) Használati eset (use case) diagram (funkcionális követelmények - UML) Szekvencia-diagram (dinamikus modellezés - UML) Együttműködési diagram (dinamikus modellezés - UML) Komponensdiagram (UML) Telepítési diagram (UML)

Adatmodellezés

Adatmodellezés Cél: Adatbázis szerkezetének meghatározása. Alapfogalmai: Egyed – egyedtípus, egyed-előfordulás Tulajdonság – tulajdonságtípus és érték Kapcsolat – kapcsolattípus, kapcsolat-előfordulás

Egyed-kapcsolat diagram

Kapcsolatok jellemzői, speciális esetei Fokszáma (1:N, M:N, 1:1) Kötelező v. opcionális szerep Stabil v. változó szerep Egymást kizáró kapcsolatok Főtípus-altípus viszony Visszamutató kapcsolat Többszörös kapcsolat

Relációs adatbázis Egyedtípus => reláció = táblázat Tulajdonság => táblázat oszlopa Egyed-előfordulás => táblázat sora (elsődleges kulcs) Kapcsolat => idegen kulcs

Relációs adatanalízis (normalizálás) Cél: Tranzakciókezelő rendszer relációs adatbázisa szerkezetének kialakítása. – Követelmény a minimális redundancia a relációk szerkezetében. Alapfogalmak: Reláció Elsődleges kulcs Idegen kulcs Funkcionális függés (közvetlen, közvetett)

Elsődleges kulcs. Idegen kulcs Egyed elsődleges kulcs: Az egyed minden előfordulására értelmezett. Értékei és az egyed előfordulásai között kölcsönösen egyértelmű megfelelés áll fenn. Stabil (értéke az egyed-előfordulás élettartama alatt nem változik). Minimális (nincs az előző kritériumokat teljesítő része) Idegen kulcs: A fölérendelt elsődleges kulcsa megjelenik az alárendelt egyedtípus szerkezetében.

Funkcionális függés A funkcionálisan meghatározza B-t = A-tól funkcionálisan függ B: Az A tulajdonság bármely értékéhez legfeljebb egy érték tartozik a B tulajdonság értékei közül. (Általában nem szimmetrikus.) A (pl. személyi szám) A  B B (pl. személy neve) Tranzitív tulajdonság: AB, BC: AC Projektív tulajdonság: A+B  A, B.

Közvetlen v. közvetett funkcionális függés A  B közvetett funkcionális függés, ha létezik olyan C tulajdonság, amellyel fennáll: A  C  B, de nem A C, és nem C = B+D. Egyébként közvetlen függés.

Normálformák Első normálforma (1NF): A reláció minden tulajdonsága függ a reláció elsődleges kulcsától Boyce-Codd normálforma (BCNF): A reláció minden tulajdonsága közvetlenül függ a reláció elsődleges kulcsától.

Relációs adatanalízis (normalizálás) Az ALKALMAZOTT egyedtípus kiinduló állapota

Relációs adatanalízis (normalizálás)/2 A normalizált ALKALMAZOTT egyedtípus

Relációs adatanalízis (normalizálás)/3 Az 1NF-re hozott JÁRANDÓSÁGTÉTEL egyedtípus

Relációs adatanalízis (normalizálás)/4 Az 1NF JÁRANDÓSÁGTÉTEL függési diagramja

Relációs adatanalízis (normalizálás)/5 A normalizált JÁRANDÓSÁGTÉTEL egyedtípus

Relációs adatanalízis (normalizálás)/6 A normalizált JOGCÍM és SZJA KATEGÓRIA egyedtípusok

Szintetikus modellezés Konstrukciós szabály: Ha az A tulajdonságtól közvetlenül függ a B tulajdonság, akkor van egy olyan egyedtípus (reláció) amelynek szerkezete, mindkét tulajdonságot tartalmazza, és az egyedtípus elsődleges kulcsa az A vagy egy olyan C tulajdonság, amely az A-val kölcsönös függésben áll (A  B).

Szintetikus modellezés /2

Szintetikus modellezés /3

Szintetikus modellezés / 4

Egy mintafeladat Az ERD-ben pótolja az egyedtípusok neveit a következő lapon adott relációk alapján!

Relációk (egyedtípus-szerkezetek) PARTNER (Partnerkód, Partnernév) PARTNERCÍM (Címazonosító, Partnerkód, Cím) TERMÉK (Termékkód, Terméknév, ……………………………..) TERMÉKÁR (Árazonosító, Termékkód, Ártípus, Egységár, Devizanem, Mértékegység) ÁR-ÁTSZÁMÍTÁS (Árazonosítóról + Árazonosítóra, Arány) Az Árazonosítóról és az Árazonosítóra az Árazonosító szerepnevei. VTSZ (VTszám, Megnevezés) ÁFAMÉRTÉK (VTszám + Érvényesség kezdete, Érvényesség vége, ÁFA mérték) SZÁMLAFEJ (Számlasorszám, Partnerkód, Címazonosító, Számlatípuskód, Kiállító törzsszáma, Kiállítás dátuma, Első nyomtatás dátuma, Nyomtatott példány, Teljesítés dátuma, Fizetési határidő, Fizetési mód) A Kiállító törzsszáma a Törzsszám szerepneve. FEJSZÖVEG (Számlasorszám + Szövegkód, Szöveg) SZÁMLATÉTEL (Számlasorszám + Tételsorszám, Termékkód, Mértékegység, Mennyiség, Tételérték) TÉTELSZÖVEG (Számlasorszám + Tételsorszám + Szövegsorszám, Tételszöveg) ALKALMAZOTT (Törzsszám, Név)

A megoldás TERMÉK (Termékkód, Terméknév, VTszám)