1 / 55

Számvitelszervezés

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

milek
Télécharger la présentation

Számvitelszervezés

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Számvitelszervezés Gyurkó György

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

  3. A szoftverfejlesztési folyamat

  4. A fejlesztési folyamat az ISO 12207 szerint

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

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

  7. Követelményleírások szerkezete

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

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

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

  11. A szoftvertervezés szintjei és vetületeia strukturált megközelítés szerint

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

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

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

  15. Életciklusmodellek

  16. Vízesés modell

  17. 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ő.

  18. V modell

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

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

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

  22. Inkrementális modell - átlapolással

  23. Iteratív és inkrementális modell

  24. Inkrementális modell előnyei, hátrányai Előnyei: • 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.

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

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

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

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

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

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

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

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

  33. Adatmodellezés

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

  35. Egyed-kapcsolat diagram

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  50. Szintetikus modellezés /2

More Related