Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Szoftvertechnológia 2014/2015 – 1. félév. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Előadó Dr. Johanyák Zsolt Csaba

Hasonló előadás


Az előadások a következő témára: "Szoftvertechnológia 2014/2015 – 1. félév. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Előadó Dr. Johanyák Zsolt Csaba"— Előadás másolata:

1 Szoftvertechnológia 2014/2015 – 1. félév

2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Előadó Dr. Johanyák Zsolt Csaba Tel.:

3 KÖVETELMÉNYRENDSZER Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

4 Követelményrendszer nappali tagozaton 1 Vizsgára bocsátás feltétele: 50 pont megszerzése Megajánlott vizsgajegy 65 ponttól Előadás ZH Előadás ZH (végleges kérdéslista a honlapon okt. 1-től) November 20., pótlási lehetőség: december 4. Megszerezhető pontszám: 40 Kötelező minimum: 21Projektfeladat Első konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Második konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Végső bemutatás: megszerezhető pontszám: 50, kötelező minimum: 25 4

5 Követelményrendszer nappali tagozaton 2 Egyéb Ha egy csoport minden tagja minden konzultáción jelen van, akkor a csoport minden tagja 5 pontot kap. 15 perces kiselőadás tartása. Témaválasztás és jelentkezés a CooSpace-ben Megszerezhető: 5 pont/kiselőadás (angol nyelvű előadás esetén maximálisan 10 pont szerezhető) Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az oktató által a félév során kiadott pontszerző feladat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

6 Házi feladat nappali tagozaton azoknak, akik gyakorlattal vették fel a tárgyat Első gyakorlaton egy 4-5 fős csoport kialakítása (egy laborgyakorlaton legfeljebb három csoport lehet) A gyakorlatvezető által kiadott szoftverfejlesztési téma egyes részfeladatainak megoldása Értékelés a beadott projektdokumentáció és a bemutató előadás alapján a gyakorlatvezető pontozza a feladatmegoldást (FM) Minden csoporttag nyilatkozik arról, hogy a társak a as skálán milyen teljesítményt nyújtottak (T) Minden hallgató kap egy átlagértékelést a csapattársak értékelése alapján (ÁT) Végleges pontszám=FM*ÁT/100 Pl. ha FM=40 pont, T={80,90,90,100}→ÁT=90 VP=40*90/100=36 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

7 Követelményrendszer levelező tagozaton 1 Vizsgára bocsátás feltétele: 50 pont Megajánlott vizsgajegy Elmélet ZH Elmélet ZH (végleges kérdéslista a honlapon okt. 1-től) November , pótlási lehetőség: nov Megszerezhető pontszám: 40 Kötelező minimum: 21 Házi feladat Megszerezhető pontszám: 50 Kötelező minimum: 25 7

8 Követelményrendszer levelező tagozaton 2 Egyéb Egy kiválasztott témakör esszé jellegű kidolgozása (irodalomfeldolgozás, nem másolás!). Jelentkezés a kiírt témákra a CooSpace-ben Megszerezhető: 5 pont/témakör Részvétel a tantárgy témaköréhez kapcsolódó Informatika.Neked előadásokon (az előadó hirdeti ki, hogy melyek az érintett előadások) Megszerezhető: 2 pont/előadás Az egyéb kategóriában kötelezően megszerzendő pontszám: 4 pont Dr. Johanyák Zs. Csaba - Szoftvertechnológia

9 Használt szoftverek MS Project 2013 Software Ideas Modeler Microsoft Visual Studio 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

10 Kötelező és ajánlott irodalom Kötelező Előadásdiák - minden előadást követően frissített változatot töltök fel [http://johanyak.hu]http://johanyak.hu Szabolcsi Judit: Szoftvertechnológia (a honlapomról letölthető) Ajánlott Ajánlott: Mileff Péter: Szoftverfejlesztés seg. [link]link Tarczali Tünde: UML diagramok a gyakorlatban [link]link Dr. Johanyák Zs. Csaba - Szoftvertechnológia

11 Ajánlott irodalom Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Ian Sommerville: Szoftverrendszerek fejlesztése Szentirmai Róbert: Projektirányítás Microsoft Office Project 2007 segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

12 Témakörök Szoftverfejlesztési projektek menedzselése Szoftver életciklus modellek UML Alap tevékenységek Elvárások elemzése és specifikáció Tervezés Implementálás + tervezési minták Ellenőrzés Objektum orientált szoftverfejlesztési módszerek Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

13 SZOFTVERFEJLESZTÉSI PROJEKTEK MENEDZSELÉSE Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

14 Projekt definíciók Egy időben behatárolt erőfeszítés, egy egyedi termék, szolgáltatás vagy eredmény létrehozása céljából (PMBOK GUIDE magyarul: Projektmenedzsment útmutató, Akadémia Kiadó 2009) Egyedi folyamatrendszer, amely kezdési és befejezési dátumokkal megjelölt, specifikus követelményeknek – beleértve az idő-, költség- és erőforrás korlátokat – megfelelő célkitűzés elérése érdekében vállalt, koordinált és kontrollált tevékenységek csoportja (ISO 8402) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

15 A menedzselés fontossága A menedzselés szükségessége igen fontos eltérés a professzionális szoftverfejlesztés és az amatőr programozás között A jó menedzsment nem garantálja a projekt sikerét A rossz menedzsment biztos kudarcot eredményez Idő-költség-minőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

16 A szoftvermenedzselés sajátosságai A szoftver nem kézzelfogható termék Gyakori technológiai váltások A nagy projektek gyakran eltérnek a korábbi projektektől Dr. Johanyák Zs. Csaba - Szoftvertechnológia

17 A szoftverprojekt vezetőjének feladatai Indítványok készítése, célok meghatározása és tervek készítése Csapattagok kiválogatása A projekt költségeinek figyelemmel kísérése A projektmegvalósulás követése és felülvizsgálata Beszámolók készítése és előadása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

18 Tervek készítése Projektterv és PDD Minőségbiztosítási terv Validációs terv Konfigurációkezelési terv Karbantartási terv Munkaerő-fejlesztési terv Dr. Johanyák Zs. Csaba - Szoftvertechnológia

19 A projekttervezési és vezetési folyamat 1. Projektcél? Megállapítani a projekt megszorításait Szervezeti keretek, felelősök A projekt paramétereinek egy kezdeti összegzését elkészíteni Definiálni a projekt részeredményeit és mérföldköveit A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

20 A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

21 A projekt ütemezése A folyamat tevékenységekre bontása Az egyes tevékenységekhez szükséges idő és erőforrások becslése Idő tartalékolása problémák megoldására és és előre nem látott feladatokra (pl. Sommerville: +30% probl. +20% fel.) Mely tevékenységek végezhetőek párhuzamosan? Összefüggő sorozatba rendezés Erőforrások (pl. munkatársak) tevékenységekhez rendelése Felelősségi körök meghatározása (felelősségi mátrix) Költségek becslése A munkaerő kihasználtsága optimális legyen Grafikus megjelenítés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

22 Hierarchikus tevékenység/feladat lebontás 1. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Projekt Fázis Szakasz Tevékenység Feladat Végrehajtás Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment 22

23 Hierarchikus tevékenység/feladat lebontás 2. Film Forgatóköny v StílusÍróTém a Sci-fiHorrorstb. Szereposzt ás Casting Helyszín KülsőBelső Rendező Stáb DíszletOperatőrHáttér munkáso k Zene Szerzés IllesztésSzínész ek Gyártá s v. Vágás v.Képi világ Utómunka v.

24 Mérföldkövek és részeredmények A mérföldkő A mérföldkő a szoftverfolyamat tevékenységeinek egy ellenőrző pontja, egy logikai szakasz vége. Egy vagy több olyan részfeladat után helyezzük el, ahol a részfeladatok eredményes befejezése nélkül nem lehet továbbhaladni. A részeredmények A részeredmények a projekt olyan eredményei, amelyek átadhatók a megrendelőnek. Ezek általában mérföldkövek is, de a mérföldkő nem szükségszerűen részeredmény. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

25 Tevékenységek és mérföldkövek Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendsszerek fejlesztése 25

26 Könyvesboltban történő vásárlás menete Tevékenység neve IdőtartamKezdésBefejezésMegelőzés (1) Vásárlás2 óraK (2) Vevő szempontjából 40 percK (3) Katalógus megtekintés 5 percK (4) Könyv kiválasztása 1 óraK (5) Könyv megtekintése 10 percK (6) Könyvből való következtetés levonása 5 percK

27 Tevékenység neveIdőtartamKezdésBefejezésMegelőzés (7) Alkalmazott szempontjából 20 percK (8) Alkalmazott hitelesítés 1 percK (9) Hitelesítés létrejövetele 0 percK (10) Kiválasztott könyv rögzítése 5 percK , 8 (11) Vevő adatainak bevitele (ha számlát kér) 5 percK (12) Könyv kifizetése2 percK Könyvesboltban történő vásárlás menete

28 Tevékenység – Időtartam – Függőségek táblázat TevékenységIdőtartam napbanFüggőségek T18 T215 T315T1;M1 T410 T510T2;T4;M2 T65T1;T2;M3 T720T1;M1 T825T4;M5 T915T3;T6;M4 T1015T5;T7;M7 T117T9;M6 T1210T11;M8 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 28

29 Tevékenység – Időtartam – Függőségek táblázat – MS Project 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

30 Tevékenységháló Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 30

31 Tevékenység háló – MS Project 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

32 Tevékenység (Gantt) diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 32

33 Gantt diagram – MS Project 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

34 Szervezet lebontási struktúra Dr. Johanyák Zs. Csaba - Szoftvertechnológia

35 Munkacsoport szintű felelősségi mátrix Dr. Johanyák Zs. Csaba - Szoftvertechnológia

36 Erőforrások ütemezése Gépek, berendezések, alap- és segédanyagok, tartozékok és egyéb költségforrások A projekt szempontjából lényeges erőforrások Korlátozott mennyiségben áll rendelkezésre Mérhető a költsége Erőforrás típusok Anyag Költség (összeg) Munka (alap óradíj, túlóra díj) – ide tartoznak általában a dolgozók is Dr. Johanyák Zs. Csaba - Szoftvertechnológia

37 Munkatársak lekötöttségi diagramja – MS Project 2013 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

38 Túlterhelés Megoldási lehetőségek Elcsúsztatás tartalékidő felhasználással Több erőforrás bevonásának megkísérlése Munkaóra növelés (túlóra) Zárási határidő elcsúsztatásának megkísérlése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

39 Költségvetés készítése Alap órabér számítási megközelítési módok Minden érintett munkatársnál visszaszámoljuk az órabért --> nem megoldható Projektszerep és végzettség szerint átlagos órabért határozunk meg  problémás Egységes átalánnyal számolunk Az órabérhez hozzáadunk átalányköltséget (pl. áram, szoftverbérlet, irodaszer) A teljes projektköltséghez hozzáadunk konkrét költségtételeket (pl. utazás) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

40 Kockázatkezelés Def.: A kockázatok azonosítását és az azok hatásának minimalizálása érdekében történő tervek felvázolását együtt kockázatkezelésnek nevezzük. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

41 Kockázati kategóriák Projekt: a projekt ütemtervére vagy az ott használt erőforrásokra ható kockázat Termék: a fejlesztett szoftver minőségére vagy teljesítményére ható kockázat Üzleti: a szervezetre ható kockázat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

42 Konkrét példák Tapasztalt programozó elhagyja a projektet – projekt Hardver elérhetetlensége – projekt CASE-eszköz alulteljesítése – termék A fejlesztendő szoftver méretének alulbecslése – termék Technológia megváltozása – üzleti Versenyképes termék kerül piacra, mielőtt a rendszer elkészülne - üzleti Dr. Johanyák Zs. Csaba - Szoftvertechnológia

43 A kockázatkezelés folyamata 1. Kockázat azonosítása 2. Kockázat elemzése (valószínűség és következmények) 3. Kockázat tervezése (hogyan kerülhetjük el) 4. Kockázat figyelése  2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

44 1. A kockázat azonosítása Kockázattípusok Technológiai - A rendszerhez használt adatbázis nem tud mp-ként annyi tranzakciót feldolgozni, mint amit elvárunk tőle. Emberi - A kulcsfontosságú munkaerő megbetegszik. Szervezeti - A projekt vezetősége megváltozik. Eszköz - A különböző típusú CASE-eszközöket nem lehet integrálni. Követelmény - A megrendelők nem képesek megérteni, hogy az általuk kívánt szolgáltatások miért lennének olyan drágák. Becslési - A szoftver kifejlesztéséhez szükséges időt alábecsülték. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

45 Kockázati tényezők Kockázattíp us Potenciális jelzés TechnológiaiA hardver vagy a támogató szoftver kései leszállítása, számos jelzett technológiai probléma. EmberiSzegényes munkamorál, rossz kapcsolatok a csapatok között. SzervezetiMunkahelyi pletykák, a felső vezetés tevékenységének hiánya. EszközA csapatok eszközökkel szembeni idegenkedése, a CASE eszközök körüli panaszok, nagyobb teljesítményű munkaállomások iránti igény. KövetelményIgény számos követelmény megváltoztatására, panaszok a megrendelő felől. BecslésiAz elfogadott ütemtervet nem sikerül betartani, nem lehet tisztázni a jelentett hibákat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

46 Halszálka diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

47 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

48 Vizuális programozás projektfeladat sikertelensége #1 Személyi #4 Módszer ----> Lustaság ---->Részfeladatokra bontás ----> Nem megfelelő végzettség---->Nem megfelelő kommunikáció ----> Együttműködő képesség hiánya---->Objektumorientáltsági problémák #2 Eszközök #5 Környezet ----> Számítástechnikai eszközök hiánya---->Távolság ----> Fejlesztőkörnyezet hiánya---->Túlterheltség ----> Jegyzetek hiánya ----> Internet hiánya ----> #3 Ismeretek ----> Hiányos programozói ismeretek ----> Hiányos nyelvi ismeretek ----> Hiányos matematikai ismeretek Dr. Johanyák Zs. Csaba - Szoftvertechnológia Enter specific causes associated with respective major causes below. Be precise and include data whenever possible. Click "finished" to continue.

49 Halszálka diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

50 2. A kockázat elemzése Valószínűség: nagyon kicsi (<10%), kicsi (10-25%), mérsékelt (25-50%), magas (50-75%) vagy nagyon magas (>75%); A kockázat hatása: nem jelentős, elviselhető, súlyos vagy katasztrofális Dr. Johanyák Zs. Csaba - Szoftvertechnológia

51 Kockázatelemzési táblázat Kockázat: Valószínűség (1- 5) Hatás (1-5)V*H Lustaság5525 Nem megfelelő végzettség3515 Együttműködő képesség hiánya5315 Távolság4312 Túlterheltség5210 Részfeladatokra bontás339 Hiányos nyelvi ismeretek248 Nem megfelelő kommunikáció155 Hiányos matematikai ismeretek224 Objektumorientáltsági problémák224 Internet hiánya414 Fejlesztőkörnyezet hiánya122 Jegyzetek hiánya122 Számítástechnikai eszközök hiánya212 Hiányos programozói ismeretek212 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

52 Pareto Dr. Johanyák Zs. Csaba - Szoftvertechnológia

53 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

54 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

55 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

56 2. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

57 Az 1. előadás tartalmából Projekt A vezető feladatai A projekttervezési és vezetési folyamat Hierarchikus tevékenység/feladat lebontás Mérföldkövek és részeredmények Tevékenység – Időtartam – Függőségek - Erőforrások Ütemezés Kockázatkezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ismétlés

58 A projekttervezési és vezetési folyamat 1. Projektcél? A projekt megszorításai Szervezeti keretek, felelősök A projekt paramétereinek kezdeti összegzése A projekt részeredményeinek és mérföldköveinek definiálása A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Ismétlés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

59 A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Ismétlés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

60 SWOT elemzés Belső tényezők Strengthserősségek Weaknessesgyengeségek Külső tényezők Opportunitieslehetőségek Threatsveszélyek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

61 SWOT elemzés (vállalati példa)

62 Erősségek Meghatározó a vállalat piaci szerepe? Jó a vásárlók véleménye? Fejlett technológiát használ a vállalat? Egyedülálló versenyelőnnyel rendelkezik? Jók a piaci erőforrásai? Gazdaságos üzemméretet használ? Jó a vállalat menedzsmentje? Kimagasló szakértelműek az alkalmazottak? Sikeres a vállalati stratégia? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia

63 Gyengeségek Elavult a technológia? Romlik a piaci pozíció? Nincs egyértelműen meghatározott stratégia? Hiányzik a megfelelő szakértelem? Elhasználódtak a létesítmények? Rossz a vállalat imázsa? Nem sikeres a kutatás-fejlesztési részleg? Rosszul funkcionál a menedzsment? A pénzügyi háttér nem rendezett? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia

64 Lehetőségek Gyorsabb piaci növekedés? Kiegészítő termékek fejlesztése? Új piacokra való belépés? Új technológia alkalmazása? A termékcsoport továbbfejlesztése? További célcsoportok feltérképezése? Egy nyersanyagforrás megszerzése? Beszállítás helyett saját előállítás? Új szervezeti felépítés kidolgozása? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia

65 Veszélyek Új versenytársak megjelenése a piacon. A piaci növekedés lassulása. Változó fogyasztói igények. Szigorodó szabályozás. Helyettesítő termékek megjelenése. Hátrányos demográfiai változások. Kedvezőtlen gazdasági ciklusok hatása. A beszállítók javuló alkupozíciója. Fogyasztói érdekvédelem fokozódó nyomása. Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia

66 Kockázat tervezése és menedzselése Stratégiák Elkerülési stratégiák Minimalizációs stratégiák Vészhelyzeti tervek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

67 Kockázat tervezése KockázatStratégia Szervezeti pénzügyi problémák Elkészíteni egy részletes dokumentumot a felső vezetés részére, amely bemutatja, hogy a projekt mennyire fontos kapcsolatban áll az üzleti célokkal Toborzási problémák Riasztani a megrendelőt, hogy potenciális nehézségek és lehetséges késések várhatók, kutatni a megvásárolható komponensek után. Munkaerő megbetegedése Újraszervezni a csapatot úgy, hogy a munkák jobban átfedjék egymást, így az emberek jobban megértik mások munkáit is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

68 A kockázat figyelése Változott-e az azonosított kockázatok bekövetkezési valószínűsége hatása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

69 Információgyűjtés Kitöltött űrlapok jelentések, jegyzőkönyvek, programok kimenetei, értekezleteken elhangzott információk Óraelszámolások Állapotjelentések Dr. Johanyák Zs. Csaba - Szoftvertechnológia

70 Elemzés - alapfogalmak ACWP ACWP – Actual Cost Of Work Performed – az elvégzett munka tényleges költsége BCWP BCWP – Budget Cost Of Work Performed – az elvégzett munkára ennyi költséget terveztünk BCWS BCWS – Budget Cost Of Work Scheduled – a tervezett (ütemezett) munkára ennyi költséget terveztünk Dr. Johanyák Zs. Csaba - Szoftvertechnológia

71 Elemzés – származtatott fogalmak CV CV – Cost Variance – költségeltérés CV=BCWP-ACWP SV SV – Schedule Variance – ütemezéstől való eltérés SV=BCWP-BCWS CPI CPI – Cost Performance Index – költséghatékonysági mutató CPI=BCWP/ACWP SPI SPI – Schedule Performance Index – ütemterv teljesülési mutató SPI=BCWP/BCWS CR CR – Critical Ratio – kritikus arány CR=SPI*CPI Dr. Johanyák Zs. Csaba - Szoftvertechnológia

72 Diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

73 Felügyelet Beavatkozási határokat meghatározni Pl. 0,9…1,1 - OK 0,8…0,9 vagy 1,1…1,2 - tendenciafigyelés 0,8 alatt vagy 1,2 felett - cselekvés Az SPI és CPI értékét folyamatosan figyelni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

74 Minta BCWSBCWPACWPCVSVCPISPIÉrtelmezés Időben és költségen ,25Időelőny és költségen ,8Késés és költségen ,81Időben és túlköltekezés ,831,25Időelőny és túlköltés ,8 Késés és túlköltés ,251Időben és megtakarítás ,25 Időelőny és megtakarítás ,250,83Késés és megtakarítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

75 Projekt lezárása A projekt akkor fejeződik be, ha teljesül a projektcél (elfogadták a projekt eredményét) Projektzáró dokumentum Projektadatok (…, tervezett és tényleges befejezési idő, bevétel, tervezett és tényleges költségek, emberóra ráfordítás) Lezárást követő teendők Vevői elégedettség Projekt általános értékelése Projektzáró értekezlet – értékelik a projekt lefutását Dr. Johanyák Zs. Csaba - Szoftvertechnológia

76 A projekt utóélete Szoftverrendszerrel kapcsolatos költségek 1/3-a fejlesztés és 2/3-a működtetés Projektzárást követő tevékenységek Üzemeltetés Garanciális javítások Későbbi karbantartás Támogatás (tanácsadás) Követés (változó jogi, hardver és szoftver környezet) Továbbfejlesztés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

77 Bejelentések fogadása Service Level Agreement (SLA) rögzíti Bejelentések súlyosság és prioritás szerinti kategorizálása Vállalt reakcióidők Informatikai infrastrukturális szolgáltatások módszertana (ITILv3) - Information Technology Infrastructure Library (ISO/IEC 20000) Informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény Dr. Johanyák Zs. Csaba - Szoftvertechnológia

78 Bejelentéskezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

79 SZOFTVER ÉLETCIKLUS MODELLEK Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

80 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Mi a szoftver? A számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége Két fő csoport Általános termékek és Rendelésre készített 80

81 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Igény a rendszerezett munkára Kezdetben kis programok Hardverfejlődés → bonyolultabb feladatok Folyamatábra, metanyelvű algoritmus leírás, stb. Szoftvertechnológia 81

82 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Boehm A szoftvertechnológia tudományos ismeretek gyakorlati alkalmazása számítógépes programok előállításához, a fejlesztéshez, a használathoz és karbantartáshoz szükséges dokumentációk tervezésében és előállításában. 82

83 Dr. Johanyák Zs. Csaba - Szoftvertechnológia IEEE A szoftvertechnológia olyan technológiai és vezetési alapelvek összessége, amelyek lehetővé teszik a programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával. 83

84 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás 84

85 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Szoftverfolyamat modellek Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V ISO/IEC (1995, 2008) Objektum orientált módszerek Agilis módszerek 85

86 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Vízesés modell Ábra forrása: Ficsor Lajos: / 86

87 Vízesés modell A következő fázis addig nem indulhat el, amíg az előző be nem fejeződött. Ez a modell akkor működik jól, ha a követelmények teljesen ismertek. Előny: Jól menedzselhető és ellenőrizhető. Minden fázisban jól definiált feladatok. Minden fázis jól dokumentálható. Előre jól definiálható követelmények esetén jól alkalmazható. Hátrány: Nagyon sok probléma csak az utolsó fázisban derül ki, így a javítás nagyon költséges. Korán kell jelentős döntéseket hozni, ez hibás döntésekhez vezethet. Nehéz a rendszert a fejlesztés közben változó követelményekhez igazítani. Sok dokumentációs munkát igényel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

88 Spirál modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. 88

89 Spirál Modell Elemzés Tervezés Megvalósítás Igények és Célok Prototípus 1 Prototípus 2 Prototípus 3

90 Spirál modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra forrása: megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. 90

91 Spirál modell Előny: a kockázati tényezőkkel explicite számol. A spirális modellben nincsenek rögzített fázisok, és felölelhet más folyamatmodelleket is (vízesés, evolúciós, stb.). Hátrányai: a modell alkalmazása bonyolult, munkaigényes feladat; a párhuzamos foglalkoztatás csak a 3. szektorban lehetséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

92 Dr. Johanyák Zs. Csaba - Szoftvertechnológia V modell Forrás: 92

93 V modell Egy módosított vízesés modell. Megkülönbözteti a fejlesztésen belül a konstrukciós és a tesztelési fázisokat. Definiálja a tesztelés szintjeit. Szemlélteti, hogy a tesztelési munka végigköveti a teljes fejlesztési folyamatot. Összefüggést tételez fel az egyes konstrukciós fázisok és az egyes tesztelési szintek között. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

94 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Inkrementális (evolúciós) Ábra forrása: Ficsor Lajos: / 94

95 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

96 Evolúciós modell Ki kell fejleszteni egy kezdeti implementációt (prototípust), azt a felhasználókkal véleményeztetni, majd sok-sok verzión át addig finomítani, amíg megfelelő nem lesz. Iterációs modellnek is nevezik. Objektum orientált fejlesztésben gyakran használják. Ez a modell a felhasználó kívánságait jobban kielégítő programot eredményez. A kis (< programsor) és közepes (<= programsor) rendszerek fejlesztéséhez ideális. Hátrányai: a folyamat nem látható; a rendszerek gyakran szegényesen strukturáltak; a gyors fejlesztés rendszerint a dokumentáltság rovására megy. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

97 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Újrafelhasználás orientált fejlesztés (komponens alapú) Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Fejlesztés és integráció 97

98 Komponens alapú modell Előnye: lecsökkenti a kifejlesztendő részek számát, így csökkenti a költségeket és a kockázatot. Ez általában a kész rendszer gyorsabb leszállításához vezet. Hátrányai: a követelményeknél hozott kompromisszumok elkerülhetetlenek, és ez olyan rendszerhez vezethet, ami nem felel meg a felhasználó valódi kívánságának. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

99 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Munka- folyamatok folyamatokKövetelményekTervezésImplementációTeszt RUP Ábra: Munkafolyamatok 99

100 RUP - dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

101 ISO Forrás: Tarczali Tünde: UML diagramok a gyakorlatban [link]link Dr. Johanyák Zs. Csaba - Szoftvertechnológia

102 Dr. Johanyák Zs. Csaba - Szoftvertechnológia CASE eszközök Computer-Aided Software Engineering Követelményspecifikáció: grafikus rendszermodellek, üzleti és domain Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfész- leírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP);verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. 102

103 Dr. Johanyák Zs. Csaba - Szoftvertechnológia CASE eszközök Automatikus dokumentumgenerálás; Projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) 103

104 OBJEKTUM ORIENTÁLT SZOFTVERFEJLESZTÉSI MÓDSZERTANOK Dr. Johanyák Zs. Csaba - Szoftvertechnológia

105 Objektum orientált szoftverfejlesztési módszertanok OMT Booch RUP Dr. Johanyák Zs. Csaba - Szoftvertechnológia

106 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Object Modeling Technique (OMT) Rumbaugh, Blaha, Premerlani, Eddy és Lorensen 1991 Egyszerű objektum orientált szoftverfejlesztési módszertan Jelölésrendszerének számos elemét átvették az UML-ben Alapgondolat: az OO gondolkodás közelebb áll az emberi problémamegoldáshoz, mint a korábbi próbálkozások A követelmény elemzés és tervezési fázis támogatására dolgozták ki Szekvenciális. Először a követelmény elemzés, majd a tervezés Mindegyik fázisban a kis lépések ciklikusan ismétlődnek Nem hangsúlyozza ki a tényleges implementációt, a tesztelést és a többi alaptevékenységet (fázist) 106

107 A modellezés célja (Rumbaugh ) A fizikai egységek tesztelése még beépítés előtt (szimuláció), Kommunikáció a megrendelővel Megjelenítés (vizualizáció) Bonyolultság csökkentése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

108 Dr. Johanyák Zs. Csaba - Szoftvertechnológia OMT Három modell kidolgozását javasolja Objektum modell: a rendszer építőelemei  OM diagramok: objektumok és osztályok közötti statikus kapcsolatok Dinamikus modell: építőelemek közötti kölcsönhatás (események, állapotok átmenetek)  állapot diagram és esemény folyam diagram Funkcionális modell: a rendszer eljárásai adatfolyam/áramlás szempontból  adatfolyam diagramok 108

109 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Objektum diagram 109

110 Dr. Johanyák Zs. Csaba - Szoftvertechnológia OMT fázisai Elemzés - f eladatmeghatározás (célok és alapkoncepciók felsorolása is) Rendszertervezés fázis A rendszer felépítése (architektúra) Alrendszerek meghatározása Alrendszerek folyamatokhoz rendelése figyelembe véve a párhuzamos végrehajtást és együttműködést Perzistens adattárolás (adatbázis) Megosztott – globális információ kezelése, Határesetek vizsgálata, prioritások meghatározása Objektum tervezés fázis Implementációs terv elkészítése Osztályok és algoritmusok definiálása Adattárolás optimalizálás Öröklődés, asszociáció, aggregáció, alapértelmezett értékek vizsgálata Szoftver implementálás 110

111 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch módszertan Grady Booch A grafikus jelölésrendszer egy része bekerült az UML-be Az követelmény elemzési és a tervezési fázist fedi le Négy modellt dolgoz ki a feladatról Logikai modell (az osztályok és objektumok) Fizikai modell Statikus modell Dinamikus modell A modellek dokumentálására használt diagramok Osztály, objektum, modul, Állapot, kölcsönhatás, folyamat 111

112 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch osztálydiagram Forrás: Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN ,

113 Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN , 1994 Hidrokultúrás kertészeti rendszer 113

114 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch objektum diagram Forrás: 114

115 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn Booch modul diagram Forrás: 115

116 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill Booch állapot átmenet diagram 116

117 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch - Fázisok Követetelmény-elemzés (analízis) – ciklikusan ismétli a három részfeladatot Követelmények a megrendelő szempontjából (a rendszer feladatainak és struktúrájának magasszintű leírása) Domain elemzés (osztályok attribútumok, öröklődés, metódusok + állapot diagramok az objektumokhoz) Validálás Tervezés (design) – ciklikusan ismétli a részfeladatokat Logikai tervezés Fizikai tervezés (Végrehajtási szálak, folyamatok, teljesítmény, adattípusok, adattstruktúrák) Prototípus létrehozása és tesztelése 117

118 UML Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

119 Dr. Johanyák Zs. Csaba - Szoftvertechnológia UML Unified Modeling Language Egységes modellező nyelv (2.1.2 ISO/IEC ) Object Management Group Eric J. Naiburg, Robert A. Maksimchuk: UML földi halandóknak. Kiskapu Kiadó, Budapest,

120 Dr. Johanyák Zs. Csaba - Szoftvertechnológia UML Dokumentálható A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Grafikus elemek Nem programozási nyelv Nem módszertan „Csak” segédeszköz 120

121 Mire jó az UML? 1. szemléltetésre a fejlesztői csoporton belül, illetve a fejlesztők, tesztelők, menedzserek és a megrendelők közötti kommunikációra specifikálásra megvalósításra dokumentálásra Dr. Johanyák Zs. Csaba - Szoftvertechnológia

122 Mire jó az UML? 2. Evolúciós programfejlesztés „szoftver mag ültetés és hajtatás” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

123 Sikeres szoftverfejlesztési folyamat Jelölésrendszer (notation) – ez lehet az UML Folyamat (process) – pl. RUP (Rational Unified Process) Eszköz (tool) – pl. Enterprise Architect, Rational Rose, Visual Studio 2010 osztálydiagram készítő része, stb. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

124 UML szabvány részei 1. Infrastructure (4 rétegű metamodell, a nyelv alapvető szerkezetei, a „mag”) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

125 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

126 A metamodell architektúra M3 Meta- metamodell EBNF (Extended Backus-Naur Form) MOF M2metamodell A C# nyelv nyelvtana UML M1modell Egy C# program Számkitaláló M0rendszer Egy konkrét C# program végrehajtása A program futásának egy állapota Dr. Johanyák Zs. Csaba - Szoftvertechnológia

127 Az UML szabvány részei 2. Superstructure (a felhasználó milyen diagramokat, azon belül milyen elemeket és kapcsolatokat használhat; mi főleg ezt tanuljuk) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

128 Az UML szabvány részei 3. UML Diagram Interchange (UMLDI) – lehetővé teszi a különböző UML szerkesztő szoftverek közötti dokumentumcserét UML Human-Usable Textual Notation – egyes UML diagramokból ember által is olvasható szöveget generál MOF 2 XMI Mapping – MOF = Meta Object Facility XMI = XML Metadata Interchange – XML adatok és objektumok cseréje, manipulálása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

129 Modell - diagram A kettő nem ugyanaz! „A modellek (tehát) több diagramból állnak, a diagramok pedig az elemek és azok más elemekkel való kölcsönhatásának ábrázolásai.” (Forrás: UML földi halandóknak könyv) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

130 Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés d. (timing) Kontextus diagram Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

131 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Kontextus d., Szakarchitektúra d. Összetett szerkezet diagram (composite stucture) Kihelyezési/telepítési/kihelyezési diagram (deployment) Viselkedési diagramok: Tevékenység diagram (activity) Használati eset vagy feladat diagram (use-case) Állapotautomata vagy állapotgép diagram (state machine) Kölcsönhatási diagramok: Sorrend diagram (sequence) Kommunikációs diagram (communication) Időzítés diagram (timing) Kölcsönhatás áttekintő diagram (interaction overview) 131

132 Szerkezeti és viselkedési A szerkezeti diagramok (statikus) nem törődnek az időbeli változással, ők a modellezett rendszer állapotát egy adott időpillanatban mutatják be. Viselkedési diagramok (dinamikus) folyamatában, változásában mutatják ugyanazt a modellezett rendszert. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

133 Szerkezeti diagramok 1 Osztálydiagram: az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Objektumdiagram: a rendszer egy adott időpontban érvényes pillanatképét határozza meg. Az osztálydiagramból származtatjuk. Csomagdiagram: a csomagok olyan modellelemek, amelyek más modellelemek csoportosítására szolgálnak, és ezeket valamint a köztük lévő kapcsolatokat ábrázolja ez a fajta diagram. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

134 Szerkezeti diagramok 2 Összetevő diagram: az összetevő vagy komponens a rendszer fizikailag létező és lecserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Főleg implementációs kérdések eldöntését segíti. A megvalósításnak és a rendszeren belüli elemek együttműködésének megfelelően mutatja be a rendszert. Összetett szerkezeti diagram: A modellelemek belső szerkezetét mutatja. Kialakítás/kihelyezés/telepítési diagram: A fizikai (kész) rendszer futásidejű felépítését mutatja. Tartalmazza a hardver és a szoftverelemeket is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

135 Viselkedési diagramok Tevékenységdiagram: A rendszeren belüli tevékenységek folyamatát jeleníti meg. Általában üzleti folyamatok leírására használjuk. Használati eset/feladat diagram: A rendszer viselkedését írja le, úgy, ahogy az egy külső szemlélő szemszögéből látszik. Állapotautomata diagram: Az objektumok állapotát és az állapotok közötti átmeneteket mutatja, valamint azt, hogy az átmenetek milyen esemény hatására következnek be. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

136 Kölcsönhatási diagramok Kommunikációs diagram: Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. Sorrenddiagram: Az objektumok közötti üzenetváltás időbeli sorrendjét mutatja. Időzítés diagram: A kölcsönhatásban álló elemek részletes időinformációit és állapotváltozásait vagy állapotinformációit írja le. Kölcsönhatás áttekintő diagram: Magas szintű diagram, amely a kölcsönhatás-sorozatok közötti vezérlési folyamatról ad áttekintést. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

137 3. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

138 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás Ismétlés 138

139 ELVÁRÁSOK ELEMZÉSE ÉS SPECIFIKÁCIÓ Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

140 Elvárások elemzése és specifikáció A vevői/megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?) A rendszer környezetének felmérése A feladat leírása Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása A feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

141 Lépések Szakterületi fogalomtár Interjú – leírás szabad szöveges formában Interjú – leírás strukturáltan rendezve Az üzleti folyamatok táblázatos leírása egyenként Használati eset diagram elkészítése Használati esetek részletes, táblázatos dokumentálása Folyamatok (lépések) modellezése tevékenység diagram segítségével Dr. Johanyák Zs. Csaba - Szoftvertechnológia

142 Szakterületi fogalomtár A témakörhöz, feladathoz kapcsolódó fontosabb kifejezések, elnevezések felsorolása és magyarázata Nem szükséges minden esetben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

143 Interjú leírása szabad szöveges formában Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: 143

144 Interjú leírása strukturált szövegként Forrás:http://www.tankon yvtar.hu/hu/tartalom/tam op425/0008_tarcali/Tarc zali_UML_diagramok_18 _18.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia

145 Az üzleti folyamatok táblázatos leírása egyenként Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás: 145

146 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

147 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Használati eset diagram Leggyakrabban a követelményelemzés és a specifikáció során alkalmazzák A rendszer viselkedését írja le, ahogyan az egy külső szemlélő szemszögéből látszik Összetevői Használati eset Szereplő Rendszerhatár 147

148 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kapcsolatok Asszociáció Általánosítás 148

149 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kapcsolatok - függőségek > 149

150 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Használati eset diagram készítése Enterprise Architectben Könyvtári rendszer használati eset diagramja 150

151 Folyamatok modellezése Tevékenység diagram Állapotautomata Dr. Johanyák Zs. Csaba - Szoftvertechnológia

152 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Tevékenység diagram A probléma megoldásának a lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt Hasznos az üzleti vagy munkafolyamatok modellezésére, használati esetek vagy konkrét algoritmusok lefutásának leírására Az állapotautomata egy változatának is tekinthető, ahol az állapotok helyére a végrehajtandó tevékenységeket tesszük, az állapotátmenetek pedig a tevékenységek befejezésének eredményeként valósulnak meg. Action, Activity 152

153 Pénzfelvétel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

154 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Másodfokú egyenlet megoldása 154

155 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Párhuzamos feladatvégrehajtás Elágazás (fork) Csatlakozás (join) 155

156 Tevékenység diagram aktorok szerinti partícióval Dr. Johanyák Zs. Csaba - Szoftvertechnológia

157 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn Kivétel Mi idézheti elő? Külső esemény (pl. adathordozóval megszakad a kapcsolat) Időpont (pl. inaktív ftp kapcsolat megszakítása) Esetválasztás (pl. hibás paraméterezés következtében a hívott metódus kivételt idéz elő) Célzott előidézés - továbbadás (throw) 157

158 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás Ismétlés 158

159 Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés diagram (timing) Kontextus diagram Szakarchitektúra diagram Ismétlés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

160 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Állapotgép Az objektumok, a használati eseteknek és a protokollok dinamikus viselkedését mutatja, vagy a dialógusok lefutásának leírására is alkalmas Állapot Állapot: az objektum állapotát az attribútumai konkrét értékeinek n-esével jellemezzük. Tervezés és implementálás során Állapotátmenet: két állapot közötti kapcsolat, amely kifejezi, hogy egy adott állapotban lévő objektum egy esemény vagy valamely feltétel bekövetkezésének hatására milyen másik állapotba kerül 160

161 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

162 Állapot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

163 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Álapotdiagram 163

164 Diszjunkt alállapotok

165 Állapotátmenetek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

166 Egy kezdőállapot, több végállapot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

167 Állapotgép könyv – könyvtári rendszer Dr. Johanyák Zs. Csaba - Szoftvertechnológia

168 Összetett állapotok Állapotok aggregációja Diszjunkt szub- vagy alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

169 Állapotok aggregációja A B és C alrendszerek párhuzamosan működnek Az A állapotát a B és C állapotának az „összege” adja. Ezek egymással párhuzamosan kerülnek különböző állapotokba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

170 Diszjunkt alállapotok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

171 Emlékező vagy történeti állapot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

172 Állapotátmenetek

173 Történeti állapot Egyszerű történeti állapot H – csak az állapotkonfiguráció legfelső szintjét őrzi meg Mély történeti állapot H* - teljes mélységében megőrzi az állapotkonfigurációt Dr. Johanyák Zs. Csaba - Szoftvertechnológia

174 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Állapotgép - tanulmányi rendszer - tantárgyfelvétel 174

175 Állapotgép - párátlanító Dr. Johanyák Zs. Csaba - Szoftvertechnológia

176 TERVEZÉS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

177 Tervezés Szoftverarchitektúra beazonosítása (K-A-RM) Felhasználói interfészeken lefutó interakciók modellezése Osztályok és felépítésük Objektum életciklusok és objektum interakciók kidolgozása A tervezés során alkalmazható diagramok: kontextus d., architektúra d., rendszer- montázs d., tervezési osztálydiagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

178 Kontextus diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

179 Táblázat Ügyfél FeladatPénzkivétel, mobil egyenleg feltöltés, stb. Mennyiség* FajtaTermészetes személy Betanítási idő- Dr. Johanyák Zs. Csaba - Szoftvertechnológia

180 Táblázat Alkalmazott (pénzfeltöltő) FeladatKészpénz elhelyezése az automatába MennyiségHeti két alkalom FajtaAlkalmazott Betanítási időFél nap Dr. Johanyák Zs. Csaba - Szoftvertechnológia

181 Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

182 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Összetett szerkezeti diagram Composite structure diagram Megmutatja egy osztály belső szerkezetét és az egységek közötti együttműködési lehetőséget. 182

183 Osztálydiagram Az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Általában a rendszer logikai és fizikai felépítésének ábrázolására szolgál. UML-beli osztály NEM UGYANAZ, mint a programozási nyelvek osztályfogalma! – többféle jelentés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

184 UML-beli osztály jelentései Fogalom: Ez az elemzési/ tervezési fázisban gyakori, ahol a szakterület fogalmait nevezzük osztálynak Típus: Ez már programozási nyelv közelibb; az objektumok az osztály típus értékei, példányai. Objektumhalmaz: Az osztály itt csak egy csoportosítás, az azonos felépítésű objektumok halmaza Implementáció: Az OOP nyelvekben az osztály egyszerűen csak egy implementáció (kód) is lehet, amin az objektumai osztoznak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

185 Szoftver életciklus fázisai 1. Elemzési fázisban az osztály mint Fogalom – igen Típus – esetleg Objektumhalmaz – nem Implementáció (kód) - nem Dr. Johanyák Zs. Csaba - Szoftvertechnológia

186 Szoftver életciklus fázisai 2. Tervezési fázisban az osztály mint Fogalom – esetleg Típus – igen Objektumhalmaz – igen Implementáció (kód) - esetleg Dr. Johanyák Zs. Csaba - Szoftvertechnológia

187 Szoftver életciklus fázisai 3. Megvalósítási fázisban az osztály mint Fogalom – nem Típus – igen Objektumhalmaz – igen Implementáció (kód) - igen Dr. Johanyák Zs. Csaba - Szoftvertechnológia

188 Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia

189 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Osztálydiagram 189

190 Osztálydiagram példa

191 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Az osztályok közötti kapcsolatok Asszociáció/társítás (association) Aggregáció/rész-egész kapcsolat (aggregation) Általánosítás (generalization) Függőség (dependency) Megvalósítás (realization) 191

192 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Asszociáció Reflexív asszociáció – Többes asszociáció 192

193 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Aggregáció Kompozíció (erős tartalmazás) Gyenge tartalmazás 193

194 Példák Dr. Johanyák Zs. Csaba - Szoftvertechnológia

195 Dr. Johanyák Zs. Csaba - Szoftvertechnológia További kapcsolatok Általánosítás Függőség Megvalósítás 195

196 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Objektum diagram 196

197 Sokszög Dr. Johanyák Zs. Csaba - Szoftvertechnológia

198 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kölcsönhatási diagramok Sorrend diagram – kevés résztvevő sok üzenettel Kommunikációs diagram – sok résztvevő kevés üzenettel Időzítés diagram – kevés résztvevő, komplex időbeli egymásra hatás 198

199 Sorrend diagram Üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

200 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Sorrend diagram 200

201 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

202 Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

203 Sorrend diagram

204 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kommunikációs diagram ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. 204

205 Kommunikációs diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

206 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Időzítés diagram kevés résztvevő, komplex időbeli egymásra hatás 206

207 Kölcsönhatás áttekintő diagram A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő az előző három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

208 Kölcsönhatás áttekintő diagram Olyan, mintha egy tevékenységdiagramot rajzolnánk (kezdőpont, végpontok, elágazás, stb.), de a tevékenységek helyett ref-ek állnak (referenciák). A referenciák általában egy sorrenddiagramra vonatkoznak, amit már részletesen megrajzoltunk. A példában mindkét ref mögött létezik egy-egy ugyanilyen nevű sorrenddiagram, ami megmutatja a bejelentkezés és a felhasználó megrendeléseinek a részleteit. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

209 Kölcsönhatás áttekintő diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

210 Üzenettípusok Az első háromfajta kölcsönhatási diagramban egyaránt a következő háromfajta üzenettípust használjuk. Kérés: Szinkron üzenet. Kérés alkalmával a küldő szünetelteti aktivitását (vár) és a fogadó aktiválása következik be. (pl. telefonálás) Válasz: Szinkron üzenet. A kérést küldő a válaszüzenet hatására újra aktiválódik. Szignál: Aszinkron üzenet, vagyis a küldő nem szünetelteti az aktivitását az üzenet elküldése után, hanem tovább dolgozik. (pl. levélküldés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

211 Kérés, válasz és szignál Dr. Johanyák Zs. Csaba - Szoftvertechnológia

212 Komplex interakció Az első háromfajta kölcsönhatási diagramban szerepelhetnek. Folyamatok egész halmazát reprezentálhatják, amelyeket az interakciós operátorok kötnek össze. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

213 Interakciós operátorok strict operátor – szigorú sorrend ref operátor – névvel hivatkozik más interakciókra opt operátor – opcionális alt operátor – alternatívák (választási lehetőség) brk operátor - megszakítás seq operátor – sorrend, de nem szigorú sorrend, mint a strict-nél loop operátor – ciklus, ismétlés par operátor – párhuzamosság … (vannak még továbbiak) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

214 Interakciós operátorok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

215 IMPLEMENTÁLÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

216 Implementálás A technológiai részletek kidolgozása, a tényleges kód előállítása Komponens tervezés, adatszerkezet tervezés Felhasználói interakció megtervezése, felülettervek Integrálás (modulok összekapcsolása). Dokumentáció: objektum d., csomag d., komponens d. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

217 Csomag diagram Az UML-elemek csoportosítására, közös névtérben való elhelyezésére alkalmas Tartalmazhat további csomagot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

218 Csomag láthatóság és útvonal megadás Public (default) – más névtérből is látható, private Teljes minősített név egymásba ágyazásnál: gyökércsomag_neve::csomag_neve::elemnév Relatív útvonal >-al Dr. Johanyák Zs. Csaba - Szoftvertechnológia

219 Csomag beolvasztás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

220 Csomagok közötti kapcsolatok > a csomag összes elemét vagy egy elemet láthatóvá tesz a másik csomag számára > privát import, ez az elem nem importálható tovább újabb csomagokba > összeolvasztás, a csomagimportálás egy fajtája, a beolvasztott része lesz a beolvasztónak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

221 Összetevő (komponens) diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

222 Komponens Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

223 Interfész Van nyújtott (szolgáltatott) interfész (kör a jele) Van elvárt (required) interfész (félkör a jele) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

224 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Összetevő diagram 224

225 Interfészek összefogása csatlakozóba (portba) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

226 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kialakítási diagram 226

227 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kihelyezési/telepítési diagram 227

228 ADATBÁZISOK MODELLEZÉSE Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ismétlés és kiegészítés a tervezés témakörhöz 228

229 ER modell Forrás: asg/oktata s/Adatbazi sok/adatb elm_nyh_ pdf.PDF Dr. Johanyák Zs. Csaba - Szoftvertechnológia

230 Relációs modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

231 Leképezési szabályok Egyedtípus → reláció Összetett attribútumok → komponensekre bontás → reláció Kulcsattr. → elsődleges kulcs N:M kapcsolat → kapcsolat reláció Dr. Johanyák Zs. Csaba - Szoftvertechnológia

232 Kiinduló relációk Dr. Johanyák Zs. Csaba - Szoftvertechnológia

233 Normálformák 1. A táblázat minden cellájában csak egy attribútum érték szerepel (1NF) 2. Minden nem kulcs (másodlagos) attribútum funkcionálisan teljesen függ minden kulcstól (2NF) 3. Nincs olyan másodlagos attribútum, ami tranzitívan függne valamilyen kulcstól Dr. Johanyák Zs. Csaba - Szoftvertechnológia

234 Entity Framework Dr. Johanyák Zs. Csaba - Szoftvertechnológia

235 Entity Framework modell kialakítása Id Egyedtípus → entitás Összetett attribútumok → komponensekre bontás → entitás Kulcsattr. → elsődleges kulcs (Entity key) N:M kapcsolat → kapcsolat Automatikusan keletkező navigációs tulajdonságok Dr. Johanyák Zs. Csaba - Szoftvertechnológia

236 IMPLEMENTÁLÁS - FOLYTATÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

237 Prototípus A szoftverrendszer kezdeti verziója, amelyet arra használnak, hogy bemutassák a koncepciókat kipróbálják a tervezési opciókat jobban megismerjék a problémát és annak lehetséges megoldásait Támogatott tevékenységek a követelménytervezési folyamatban követelmények feltárása követelmények validálása Felhasználható Felhasználók képzésére Rendszer tesztelésére Dr. Johanyák Zs. Csaba - Szoftvertechnológia

238 A prototípus készítés előnyei A funkciók bemutatásakor azonosítani lehet a szoftverfejlesztők és a felhasználók közötti félreértéseket A szoftverfejlesztésen dolgozók hiányos és/vagy ellentmondásos követelményekre akadhatnak Hamar a rendelkezésünkre áll egy működő rendszer, így demonstrálhatjuk a vezetőségnek az alkalmazás megvalósíthatóságát és hasznosságát A prototípus felhasználható a valódi rendszer specifikációjának megírásakor A rendszer jobban használható lesz A rendszer jobban illeszkedik a felhasználói igényekhez Jobb a tervezés minősége Jobb a rendszer karbantarthatósága Kevesebb erőfeszítés szükséges a fejlesztéshez Dr. Johanyák Zs. Csaba - Szoftvertechnológia

239 Prototípus típusai Evolúciós prototípus - készítésének célja egy működő rendszer átadása a végfelhasználóknak Eldobható prototípus - készítésének célja a rendszerkövetelmények validálása vagy származtatása. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

240 Gyors prototípus készítési technikák Magas szintű nyelvek (3GL, 4GL) Komponensek és alkalmazások összeépítése Alkalmazási szinten Komponens szinten Dr. Johanyák Zs. Csaba - Szoftvertechnológia

241 Programozási nyelvek 1. generációs: gépi szintű nyelv/utasítások, kapcsolókkal vitték be Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kép forrása i/File: panel.jpg 241

242 Programozási nyelvek 2. generációs (2GL): assembly nyelvek – van logikai struktúra, lassú fejlesztés 3. generációs (3GL): magasszintű nyelvek, strukturált programozás támogatása, kényelmi funkciók, nem kell a programozó kidolgozzon minden egyes részletet pl. C, C++, C#, Java, BASIC and Delphi gyorsabb fejlesztés, de sok hibalehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

243 Programozási nyelvek 4. generációs(4GL): kereskedelmi/üzleti célú szoftverek fejlesztéséhez, magasabb absztrakciós szint még gyorsabb fejlesztés kevesebb hibával, cél a fejlesztési költségek csökkentése PowerBuilder, jelentés generáló rendszerek, form generáló rendszerek, adatfeldolgozó rendszerek: SAS, SPSS Pl: generation_programming_language#Some_fourt h-generation_languageshttp://en.wikipedia.org/wiki/Fourth- generation_programming_language#Some_fourt h-generation_languages Dr. Johanyák Zs. Csaba - Szoftvertechnológia

244 Programozási nyelvek 5 GL: mesterséges intelligencia nyelvek, feladatmegoldás a korlátok/kényszerek megadásával, logikai nyelvek - ? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

245 Az objektum-orientált tervezés néhány kérdése Mik az objektumok? Alapelvek: egységbezárás, öröklődés, többrétűség, adatrejtés Vezérlés – szolgáltatáskérés Szinkron kommunikáció Aszinkron kommunikáció Ütemezés – szabályozott megosztott hozzáférés erőforráshoz Nem preemptív – pl. szemaforok Preemptív Dr. Johanyák Zs. Csaba - Szoftvertechnológia

246 Az objektum-orientált tervezés néhány kérdése Objektum belső állapota Objektumok élettartama Perzisztens objektumok: élettartamuk hosszabb mint a program futási ideje Tranziens objektumok Nagyszámú perzisztens objektum  adatbáziskezelő rendszer alkalmazása RDB ha sok objektum, de kevés osztály OODB Dr. Johanyák Zs. Csaba - Szoftvertechnológia


Letölteni ppt "Szoftvertechnológia 2014/2015 – 1. félév. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Előadó Dr. Johanyák Zsolt Csaba"

Hasonló előadás


Google Hirdetések