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

Szoftvertechnológia 2016/2017 – 1. félév

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Előadó Dr. Johanyák Zsolt Csaba http://johanyak.hu Email: johanyak.csaba@gamf.kefo.hu Tel.: +36-76-516-413 2

Használt szoftverek MS Project Software Ideas Modeler http://www.softwareideas.net/en/download http://www.softwareideas.net/en/download Microsoft Visual Studio 2015 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20163

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 - 20164

Ajánlott irodalom Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Ian Sommerville: Szoftverrendszerek fejlesztése Szentirmai Róbert: Vállalati szintű projektirányítás Microsoft Office Project 2010 segítségével, Jedlik Oktatási Stúdió Bt., 2011 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20165

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 - 20166

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

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 - 20168

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 - 20169 Idő Erőforrás Minőség

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 - 201610

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 - 201611

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 - 201612

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 - 201613

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 - 201614

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 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 - 201615

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

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. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 17

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 - 201618

Tevékenységek és mérföldkövek Megvalósítható sági vizsgálat Követelmény elemzés Prototípus fejlesztés Terv- tanulmány Követelmények meghatározása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Forrás: Ian Sommerville: Szoftverrendsszerek fejlesztése 19 Megvalósíthatósági jelentés Prototípus fejlesztés Terv-tanulmány Követelmények meghatározása

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. 13.11.19. (2) Vevő szempontjából 40 percK. 13.11.19. (3) Katalógus megtekintés 5 percK. 13.11.19. (4) Könyv kiválasztása 1 óraK. 13.11.19. 3 (5) Könyv megtekintése 10 percK. 13.11.19. 4 (6) Könyvből való következtetés levonása 5 percK. 13.11.19. 5 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 20

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

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 - 2016 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 22

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

Kezdet 03/7/4 M5 03/7/18 T1 8 nap M1 03/7/14 T3 15 nap T9 15 nap M4 03/8/4 M6 03/8/25 M8 03/9/5 T11 7 nap T12 10 nap Vég 03/9/19 T8 25 nap T4 10 nap T2 15 nap T6 5 nap M3 03/7/25 M2 03/7/25 T7 20 nap T5 10 nap T10 15 nap M7 03/8/11 Tevékenységháló Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 24

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

7/47/117/18 7/25 8/1 8/88/15 8/22 8/299/59/12 9/19 Kezdet T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Befejezés Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése Tevékenység (Gantt) diagram

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

Szervezet lebontási struktúra Rektor GAMF MIK Informatika tanszék Járműtechnológia tanszék PKKVKGK Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201628

OBSWBS Fejlesztő főosztály TervezésElőállítás Oktatás és dokumentálás Műszaki támogatás LogikaiFizikaiKódolás TesztelésOktatás Felhasználói kézikönyv Tervező osztály Programozási osztáy Tesztelő osztály Oktatási osztály Dokumentációs osztály Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Felelősségi mátrix Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201629

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ás 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 - 201630

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

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 - 201632

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 - 201633

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 - 201634

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 - 201635

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 - 201636

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 - 201637

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 - 201638

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 - 201639 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

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

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

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 - 201642 Enter specific causes associated with respective major causes below. Be precise and include data whenever possible. Click "finished" to continue.

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

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

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 - 201645

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

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 - 201649

SWOT elemzés (vállalati példa) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201650

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 - 201651

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 - 201652

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 - 201653

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 - 201654

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 - 201655

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 - 2016 56 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

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 - 201657

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 - 201658 Ismétlés

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 - 201659

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 - 201660

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 - 201661

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 - 201662

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 - 201663

Költség Idő Most SV CV BCWS ACWP BCWP Diagram Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

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 - 201665

Minta BCWSBCWPACWPCVSVCPISPIÉrtelmezés 100 0011Időben és költségen 100125 02511,25Időelőny és költségen 125100 0-2510,8Késés és költségen 100 125-2500,81Időben és túlköltekezés 100125150-25250,831,25Időelőny és túlköltés 125100125-25 0,8 Késés és túlköltés 125 1002501,251Időben és megtakarítás 10012510025 1,25 Időelőny és megtakarítás 15012510025-251,250,83Késés és megtakarítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 66 Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

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 - 201667

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 - 201668

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 20 000) 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 - 201669

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 72

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Boehm - 1976 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. 74

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 IEEE - 1983 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. 75

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 76

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Szoftverfolyamat modellek Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V RUP (Rational Unified Process) ISO/IEC 12207 (1995, 2008) 77

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Vízesés modell Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek / 78

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 - 201679

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

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 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 81

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 - 201682

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 V modell Forrás: http://softwareandme.wordpress.com/2009/10/20/software-development-life-cycle/sdlc_v_model 83

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 - 201684

Specifiká- ció Tervezés Implemen- táció Tesztelés Specifiká- ció Tervezés Implemen- táció Tesztelés Specifiká- ció Tervezés Implemen- táció Tesztelés Implemen- táció Analízis Inkrementális (evolúciós) Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek /

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 (<100.000 programsor) és közepes (<=500.000 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 - 201686

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Ú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ó 87

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 - 201688

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes Munkafolyamatok 89

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 - 201690

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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. 92

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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. ) 93

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 96

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 - 201697

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

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 - 201699

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 101

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 - 2016102

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 - 2016103

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 - 2016104

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 - 2016105

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 - 2016 106

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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) 107

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 - 2016108

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 - 2016109

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 - 2016110

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 - 2016111

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 - 2016112

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

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 - 2016114

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 - 2016115

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 - 2016116

Interjú leírása szabad szöveges formában Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_17_17.html 117

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 - 2016118

Az üzleti folyamatok táblázatos leírása egyenként Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0008_tarcali/Tarczali_UML_diagramok_19_19.html 119

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 121

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

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 126

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

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009 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) 131

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 132

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 - 2016 133

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Á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 134

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

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

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

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

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

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

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

Á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 - 2016 143

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

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

Állapotátmenetek

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 - 2016147

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

Állapotgép - párátlanító Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 http://www.altova.com/umodel/state-diagrams.html 149

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 150

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

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 - 2016152

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

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 - 2016154

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 - 2016155

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Ö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. 157

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 - 2016158

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 - 2016159

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 - 2016160

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 - 2016161

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 - 2016162

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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) 166

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

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

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

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 173

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 - 2016174

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/353/Enterprise-Architect-for-Business-Analysts.aspx 176

Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 http://www2.pms.ifi.lmu.de/publikationen/diplomarbeiten/Sacha.Berger/illustrations/UML/SequenceDiagram-initiatingPhoneCall.pdf.png 177

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

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

Kommunikációs diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 http://afruj.wordpress.com/2008/07/28/the-unified-modeling-language-uml-part-8/ 180

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

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 - 2016 182

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 - 2016 183

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

Ü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 - 2016 185

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

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 - 2016 187

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 - 2016 188

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

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

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 - 2016191

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 - 2016192

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 - 2016193

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 - 2016194

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 - 2016195

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 - 2016196

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

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

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

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

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

ER modell Forrás: http://www.inf.unideb.hu/~fazek asg/oktata s/Adatbazi sok/adatb elm_nyh_ pdf.PDF Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016202 lelt_szam ar lakcim kolcs_e kiad_azon varos kiad_nev ISBN kiad_dat cim eloj_dat szerzo_azon vnev unev telszam beir_dat varos utca hazszam vnev unev dolcs_dat o_azon példány könyv kiadó szerzőírta van kiadja előjegyez kölcsönöz olvasó

OLVASÓ KOLCSON PELDANY KONYV KIADO ELOJEGY Relációs modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016203 Normalizálatlan1NF2NF3NFKonszolidáció o_azon vnev unev lakcim beir_dat lelt_szam kolcs_e isbn cim szerzo ar kolcs_dat o_azon vnev unev lakcim beir_dat o_azon vnev unev lakcim beir_dat o_azon vnev unev lakcim beir_dat o_azon lelt_szam kolcs_e isbn cim szerzo ar kolcs_dat o_azon lelt_szam kolcs_dat o_azon lelt_szam kolcs_dat lelt_szam kolcs_e isbn cim szerzo ar lelt_szam kolcs_e isbn ar isbn cim szerzo isbn cim kiad_azon kiad_nev varos kiad_dat o_azon vnev unev okod eloj_dat isbn cim kiad_azon kiad_nev varos kiad_dat isbn cim kiad_azon kiad_nev varos kiad_dat isbn cim kiad_azon kiad_dat kiad_azon kiad_nev varos isbn o_azon vnev unev okod eloj_dat isbn o_azon eloj_dat isbn o_azon eloj_dat o_azon vnev unev okod o_azon vnev unev okod több könyvet is kivihet több olvasó előjegyezhet egy könyvre o_azon vnev unev lakcim beir_dat okod o_azon lelt_szam kolcs_dat lelt_szam isbn kolcs_e ar isbn cim szerzo kiad_azon kiad_dat kiad_azon kiad_nev varos isbn o_azon eloj_dat O_azon olv.jegy. Számú olvasók kölcsönzése nyomtatvány ISBN azonosítójú könyvek előjegyzése nyomtatvány

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 - 2016204

Kiinduló relációk könvy – van – példány könvy(ISBN, cim, kiad_dat), példány(lelt_szam, isbn, kolcs_e, ar) könyv – kiadja – kiadó kiadó(kiad_azon, kiad_nev, varos), könvy(ISBN, cim, kiad_dat, kiad_azon) olvasó – előjegyez – könyv olvasó(o_azon, vnev, unev, varos, utca, hazszam, beir_dat), könvy(ISBN, cim, kiad_dat), előjegyez(o_azon, ISBN, eloj_dat) szerző – írta – könyv szerző(szerzo_azon, vnev, unev, telszam), könyv(ISBN, cim, kiad_dat), írta(szerzo_azon, ISBN) olvasó – kölcsönöz – példány olvasó(o_azon, vnev, unev, varos, utca, hazszam, beir_dat), példány(lelt_szam, kolcs_e, ar), köcsönöz(lelt_szam, o_azon, kolcs_dat) olvasó – előjegyez – könyv olvasó(o_azon, vnev, unev, varos, utca, hazszam, beir_dat), könvy(ISBN, cim, kiad_dat), előjegyez(o_azon, ISBN, eloj_dat) szerző – írta – könyv szerző(szerzo_azon, vnev, unev, telszam), könyv(ISBN, cim, kiad_dat), írta(szerzo_azon, ISBN) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016205

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 - 2016206

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

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 - 2016208

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

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 - 2016210

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 - 2016211

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 - 2016212

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 - 2016213

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 - 2016 Kép forrása http://en.wikipedia.org/wik i/File:360-91-panel.jpg 214

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 - 2016215

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: http://en.wikipedia.org/wiki/Fourth- 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 - 2016216

Programozási nyelvek 5 GL: mesterséges intelligencia nyelvek, feladatmegoldás a korlátok/kényszerek megadásával, logikai nyelvek - ? Prolog, OPS5, Mercury MI technikák használata Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016217

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 - 2016218

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 - 2016219

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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) 222

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 - 2016223

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 224

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 226

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 227

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Booch osztálydiagram Forrás: http://en.wikipedia.org/wiki/File:Booch-diagram.png Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN 0-8053- 5340-2, 1994 228

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Booch objektum diagram Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node7.html 230

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009 Booch modul diagram Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node8.html#picmodule_diagram 231

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill Booch állapot átmenet diagram 232 Disabled Operator::TurnOffAlarm Enabled SoundAlarm SilenceAlarm SilencedSounding AlarmFixed Enable Disable

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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 233

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Egységesített eljárás – Rational Unified Process A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre 1997-ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít Keret módszertan -> testre kell szabni 234

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Használati eset vezérelt (use case driven) A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája Iteratív és inkrementális (növekvő) Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Az egyes iterációk munkafolyamatokból állnak Főbb jellemzői 235

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Architektúra központú fejlesztés Architektúra: strukturálisan fontos elemek és ezek kapcsolata A rendszer nagy léptékű tagolását írja elő Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül A klasszikus példa : ház Alaprajz Homlokzati rajz Elektromos kábelezés és berendezések Épületgépészet, vízvezetékek, fűtés 236

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Az architektúra célja Lehetővé teszi a bonyolultság kezelését Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható projekt menedzsment Kockázatok csökkentése Lehetővé válik a párhuzamos fejlesztés 237

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 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: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes 238

RUP – mérföldkövek - iterációk Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell felállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. Minden egyes iteráció egy-egy mini fejlesztés. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016239

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 RUP – átlós jelleg Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes 240

Átlós jelleg Az előkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016241

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 A fejlesztés fázisai Előkészítés a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők; megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; alaparchitektúra kialakítása (Executable Architecture Baseline); az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. Megvalósítás a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek 242

RUP irodalom http://www.sze.hu/~heckenas/okt/RUP.pdf http://www.iit.uni- miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf http://www.iit.uni- miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf http://courses.cs.tamu.edu/lively/cpsc606/rup. ppt Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016243

AGILIS MÓDSZEREK Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 244

Gyors szoftverfejlesztés – agilis módszerek Lassú fejlesztési folyamatok Gyorsan változó környezet A gyors szoftverfejlesztési folyamatokat arra tervezték, hogy segítségükkel gyorsan készíthessük használható szoftvereket Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016245

Kiáltvány az agilis szoftverfejlesztéséért (2001. február) http://agilemanifesto.org/ Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016246

Az agilis fejlesztés 12 alapelve 1 Legfontosabbnak azt tartjuk, hogy a vevőnk elégedett legyen, mert értékes szoftvert szállítunk neki hamar és folyamatosan. Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében. Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva. A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során. Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát. A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016247

Az agilis fejlesztés 12 alapelve Az előrehaladás elsődleges mércéje a működő szoftver. Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére. A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást. Az egyszerűség – az el nem végzett munkamennyiség maximalizálásának művészete – alapvető érték. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki. A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá, és ennek megfelelően változtatja viselkedését. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016248

Általános jellemzők - alapelvek A specifikáció, a tervezés és az implementálás párhuzamosan zajlik. Nincs részletes rendszerspecifikáció. Inkrementális fejlesztés. A végfelhasználók is részt vesznek minden lépés specifikációjában és az eredmény kiértékelésében. Indítványozhatnak változtatásokat és új követelményeket (gyakran). Felhasználói felület vizuális tervezéssel Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016249

Előnyök A szolgáltatások hamar használhatók Mivel a felhasználót bevonják a fejlesztésbe, a rendszer sokkal jobban meg fog felelni az igényeiknek és ráadásul jobban elkötelezik magukat a szoftver mellett Az inkrementális szoftverfejlesztés közel áll az emberek probléma-megoldási módjához: mivel ritkán dolgozunk ki teljes megoldásokat, hanem a megoldásainkat lépésenként továbbfejlesztjük, és visszalépünk, ha hibáztunk Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016250

Nehézségek Nem biztos, hogy az ügyfél tud és akar is időt tölteni a fejlesztőcsapattal Személyi adottságok hiánya Gyakori áttervezés Az egyszerűség fenntartása külön munkát igényel Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016251

Hátrányok Kezelési problémák - kevés a rendszerdokumentáció Szerződésbeli problémák - nincs rendszer- specifikáció A független validáció nehezen oldható meg A folyamatos változtatás elronthatja a rendszer struktúráját Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016252

Alkalmazás Mikor alkalmazzák? Kis rendszerek/ kis projekt Kevés fejlesztő Alacsony kritikussági fok Gyakran változó követelmények Csak gyakorlott, szenior fejlesztők esetén Mikor nem? Nagy és elosztott rendszerek Kritikus rendszerek Hosszú élettartamú rendszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016253

Agilis technikák eXtrém Programozás Scrum KristályTiszta és más Kristály módszertanok Dynamic Systems Development Method Feature Driven Development (Funkcionalitáson Alapuló Fejlesztés) Test Driven Development (Tesztelésen Alapuló Fejlesztés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016254

eXtrém Programozás Minden követelmény forgatókönyv (felhasználói történet) Ez feladatokra bontható és egy-egy feladat önállóan implementálható A programozók változó párokban dolgoznak, és minden feladatra teszteket készítenek mielőtt még a kódot megírnák Minden tesztnek sikeresen le kell futnia, mielőtt az új kódot elhelyeznék a rendszerben A rendszer kiadásai között csak kis idő telik el (pl. 1 hét) Folyamatos tökéletesítés (a kódot át kell írni, átszervezni, hatékonyabbá tenni, amikor csak lehet) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016255

XP lépések 1. A kiadáshoz történő felhasználói történet kiválasztása 2. A történet feladatokra bontása 3. A kiadás tervezése 4. A szoftver fejlesztése/integrálása/tesztelése 5. A szoftver kiadása 6. A rendszer értékelése 7. Vissza  1. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016256

Felhasználói történet „Egy cikk letöltése és kinyomtatása Először válasszuk ki egy megjelenített listából a kívánt cikket. Aztán adjuk meg a rendszernek a fizetési módot – ez lehet előfizetéses vagy vállalati számláról történő vagy hitelkártyával. Ezután kapunk egy kitöltendő szerzői jogi űrlapot. Ha ezt elküldtük, a cikk letöltődik a számítógépünkre. Ezután választunk egy nyomtatót és kinyomtatjuk a cikk egy másolatát. Közöljük a rendszerrel a sikeres nyomtatás tényét. Ha a cikk csak nyomtatható, akkor nem őrizhetjük meg a PDF-verziót, így az automatikusan törlődik a számítógépünkről.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016257

Feladatokra bontás „3. feladat: A fizetési lehetőségek implementálása A fizetés három különböző úton történhet. A felhasználó kiválasztja, hogy milyen módon szeretne fizetni. Ha a felhasználónak van könyvtári olvasójegye, akkor beírhatja ide annak azonosítóját, amit a rendszernek ellenőriznie kell. Másik lehetőség, hogy megad egy szervezeti számlaszámot. Ha az érvényes, akkor a cikknek megfelelő költséggel megterhelik a számlát. Végül beírható a 16 számjegyből álló hitelkártyaszám és lejárati dátum. Ellenőrizni kell ennek az érvényességét, és amennyiben érvényes, akkor terhelést kell küldeni a hitelkártyaszámlára.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016258

Teszteset-leírás 4. teszt: Hitelkártya érvényességének ellenőrzése Bemenet: A hitelkártyaszám egy karaktersorozat, míg a kártya lejárati hónapját és évét két egész szám reprezentálja. Tesztek: Ellenőrizni kell, hogy a karaktersorozat minden bájtja számjegy- e. Ellenőrizni kell, hogy a hónap egy és 12 között van-e és az év nagyobb vagy egyenlő-e az aktuális évvel. A hitelkártya számának első négy számjegye alapján ellenőrizni kell, a kibocsátó érvényességét a kártyakibocsátók táblázata alapján. A hitelkártya érvényességét ellenőrizzük úgy, hogy elküldjük a kártyaszámot és a lejárati dátuminformációt a kártya kibocsátójához. Kimenet: OK vagy hibaüzenet, ami a kártya érvénytelenségét jelzi. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016259

SCRUM Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 260

Scrum Hirotako Takeuchi & Ikoyiro Nonaka (1986) új, gyors termékfejlesztési módszer A Scrum elnevezés a rugby-ből ered Iteratív és inkrementális agilis szoftverfejlesztési keretrendszer Rugalmas Demokratikus, rugalmas, felelősség- és eredményközpontú, emberközpontú módszer A határidő szent és sérthetetlen Elsősorban kis csapatok 5-9 fő esetén működik jól A csapat végig együtt dolgozik Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016261

Scrum jellemzők Szóbeli kommunikáció Gyakran önszerveződő csapat Nem fedi le a teljes termékfejlesztési életciklust, ezért gyakran együtt alkalmazzák más módszerekkel Pl. kezdeti követelményelemzés, prioritások meghatározása, kezdeti magas szintű tervezés, ütemezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016262

Scrum alapelvek A vevő igényei menet közben változhatnak Elfogadjuk, hogy lehet, hogy a feladatot nem tudjuk teljesen megérteni vagy definiálni Arra összpontosít a csapat, hogy a lehető leggyorsabban szállítson reagáljon az új követelményekre Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016263

Szerepkörök 1 Termékgazda (Product Owner): Termék teendőlista (Product Backlog) Biztosítja az értékteremtést Felhasználói történeteket ír és karbantartja azokat A fejlesztő csapat tagja lehet, lehet ő a projektmenedzser Fejlesztő csapat Feladata a sprint cél teljesítése A sprint végére átadható terméket kell előállítson 7±2 fő Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016264

Szerepkörök 2 SrumMaster: Segíti a csapatot Elhárítja a sprintcélt veszélyeztető akadályokat Gondoskodik arról, hogy helyesen alkalmazzák a Scrum-ot Nem csapatvezető, nem lehet azonos a projekt menedzserrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016265

Termék teendőlista (Product Backlog) Sprint teendőlista (Sprint Backlog) 2-4 weeks 24h Futam (Sprint) Egy működő szoftveregység (Working increment of the software) A Scrum folyamat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 266

Termék teendőlista (Product Backlog) Magas szintű követelmény leírások Fejlesztési célok (funkciók leírásai, kívánságok, ötletek, stb.) Prioritások Üzleti érték becslés ← Terméktulajdonos Ráfordításigény becslés ← Fejlesztők Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016267

Sprint - Futam Egy előre meghatározott időtartamú részfolyamat 1 hét … 1 hónap (ált. 2 hét) Futamtervező megbeszélés → feladatok beazonosítása → Futam teendőlistája Sprintcélok megvalósítása (fejlesztés) és napi megbeszélés A végén értékelés (sprint forduló) Futamáttekintés Visszatekintés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016268

Futamtervező megbeszélés (Sprint planning) Elvégzendő feladatok kijelölése a termék teendőlistájáról (product backlog) a terméktulajdonos közreműködésével Futam teendőlistájának előkészítése, amely a teljes csapat figyelembevételével részletezi az egyes részfeladatok időszükségleteit Annak meghatározása és kommunikálása, hogy mennyi feladat elvégzése várható el az aktuális futam során 4 hetes futam esetén maximum 8 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016269

Futam teendőlistája (Sprint Backlog) A fejlesztő csapat "vállalja be a termék teendőlistáról" A csapat kezeli Felhasználói történetek/Funkciók részfeladatokra bontva A csapattagok önkéntesen vállalnak egy-egy részfeladatot a napi megbeszélések során – prioritások és készségek alapján Követés: Scrum Task Board Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016270

Scrum Task Board Forrás: http://upload.wikim edia.org/wikipedia/c ommons/1/1b/Scru m_task_board.jpg Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016271

Napi megbeszélés (Daily Scrum) Minden nap ugyanott, ugyanakkor, max. 15 perc Minden csapattagnak válaszolni kell: Mit csináltál az előző „Daily Scrum” óta? Mit tervezel mára? Akadályozza-e valami a munkádat? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016272 Ábra: http://en.wikipedia.org/wiki/File:Daily_sprint_meeting.jpg

Burn down chart Naponta frissített diagram a futam állapotáról A hátralevő munka mennyisége Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016273 Ábra: http://en.wikipedia.o rg/wiki/File:Sample BurndownChart.png

Futamáttekintés (Demo vagy Sprint Review) Mely munkák készültek el és melyek nem? Az elkészült munka bemutatása a terméktulajdonos és a fejlesztésben érdekeltek részére (demo) Be nem fejezett munkát nem lehet bemutatni 4 hetes futam esetén maximum 4 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016274

Visszatekintés (Sprint Retrospective) A csapattagok véleményt alkotnak az elmúlt futamról Javaslatokat tesznek a folyamatok továbbfejlesztésére Két kérdés merül fel a megbeszélésen: Mi az, ami jól ment a futam alatt? Mi az, amit a következő futam során jobban lehetne csinálni? 4 hetes futam esetén maximum 3 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016275

SZOFTVEREK ELLENŐRZÉSE ÉS ELEMZÉSE Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 276

Verifikáció és validáció Verifikáció: a specifikációnak való megfelelés ellenőrzése Validáció: a vevői elvárások teljesülésének ellenőrzése (pl. ide tartozhat a hatékonyság e., hibatűrés e., erőforrásigény e. is) V&V-re a teljes fejlesztési folyamat során szükség van Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016277

V modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 278

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Ellenőrzési technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer (integrációs) tesztelés 279

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Szoftver átvizsgálás Legalább 4 fős csapat: szerző, olvasó, tesztelő, moderátor Átvizsgálás ↔ Szerző módosít Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h., kivételkezelési h. A program hibáinak több mint 60%-a felderíthető ily módon 280

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Automatikus elemzés Szoftver, ami a forrásszöveget vizsgálja (nem futtat) Nem használt kódrészlet, inicializálatlan változók Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h. Pl. LINT/Splint C; VS beépített figyelmeztetések, ReSharper Nem ismeri fel a helytelen inicializálást 281

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Szoftverek ellenőrzése és elemzése Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Mit? 282

A hiányosságtesztelés folyamata Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 283

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Hiányosság tesztelés Célok A specifikáció és a megvalósított program közötti eltérések felderítése A rendszer helytelen működésének előidézése Irányelvek Válasszunk olyan bemeneteket, amelyekkel az összes lehetséges hibaüzenetet előidézhetjük Próbáljuk meg elérni a bemeneti pufferek túlcsordulását Ugyanaz a bemenet ugyanazt a kimenetet adja mindig? Kényszerítsük ki az érvénytelen kimenetet 284

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Hiányosság-tesztelési módszerek Fekete doboz tesztelés A rendszer/komponens belseje nem ismert A bemenetre adott válaszok tanulmányozása Fehér doboz tesztelés Ismert a szerkezet Kis egységekre alkalmazzák Minden független végrehajtási utat kipróbálnak (útvonal teszt) 285

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Fehér doboz tesztelés Útvonalak felderítése Egyszerű esetekben folyamatgráf felrajzolása kézzel Bonyolult esetekben dinamikus programelemzővel (DPE) DPE: a fordítóval együttműködő szoftver, számolja, hogy az egyes utasítások hányszor kerültek végrehajtásra – mi maradt ki → futási profil 286

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Útvonalak - folyamatgráf 287

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Stressz (teljesítmény) tesztelés Cél A teljesítmény és a megbízhatóság tesztelése A tervezett terhelés mellett képes legyen dolgozni a rendszer Olyan hiányosságok is kiderüljenek, amelyek nem jelennek meg normál körülmények között Eljárás Addig növeljük a terhelést, amíg a rendszer teljesítménye elfogadhatatlanná nem válik 288

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Szoftverek ellenőrzése és elemzése Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Mit? 289

Komponenstesztelés (egységteszt) Cél a komponensekben levő hibák felderítése Általában hiányosságtesztelés Mit tesztelünk? Metódusok Osztályok Teljes komponens (több osztály) funkcionalitása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016290

Rendszertesztelés A komponensek integrálásával kapott egész tesztelése Szakaszok Integrációs tesztelés – fehér doboz tesztelés Cél a hiányosságok felderítése Kiadás tesztelés – fekete doboz tesztelés Jól működik-e a rendszer? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016291

Integrációs tesztelés Cél az együttműködésből adódó problémák felderítése Képesek-e együttműködni? Megfelelőek-e a metódushívások? Mely komponens csoportok biztosítják az egyes funkcionalitás elemeket? Leggyakoribb az inkrementális integrációs tesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016292

Regressziós tesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Forrás: Mileff Péter: Szoftverfejlesztés segédlet [Link]Mileff PéterLink 293

PROGRAMTERVEZÉSI MINTÁK Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 294

Programtervezési minták Design Patterns Újrahasznosítható osztályok: igazodnia kell a megoldandó problémához  eléggé általánosnak kell lennie ahhoz, hogy később könnyen módosítható legyen Típusfeladatokra bevált megoldások Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (GoF - Gang of Four) 23 minta Minta: „Egymással együttműködő objektumok és osztályok leírása, amely testreszabott formában valamilyen általános tervezési problémát old meg egy bizonyos összefüggésben.” Azonosítja a résztvevő osztályokat és objektumokat, szerepüket és kapcsolataikat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016295

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC, MVP, MVVM Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016296

Egyke - singleton A minta neve és besorolása: Egyke, objektum-létrehozási minta Cél: Egy osztályból csak egy példányt engedélyezni, és ehhez globális hozzáférési pontot megadni Egyéb nevek: Singleton Feladat: Egyes osztályok esetén fontos, hogy pontosan egy példány legyen belőlük. Egy rendszerben több nyomtató is lehet, de nyomtatási sorból csak egyet lehet használni. Vagy csak egy fájlrendszer és csak egy ablakkezelő futhat. Hogyan biztosíthatjuk, hogy egy osztályból csak egyetlen példány legyen, de azt könnyen el lehessen érni? Ha globális változót hozunk létre, akkor az objektum könnyen elérhető lesz, de akkor akárhány példányt létrehozhatunk belőle. Maga az osztály a felelős a példányok nyilvántartásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016297

Egyke Alkalmazhatóság: Pontosan egy példányra van szükség egy osztályból és annak elérhetőnek kell lennie az ügyfelek számára. Az osztály bővíthető kell legyen (leszármazott osztályok), és az ügyfelek legyenek képesek a saját kódjuk módosítása nélkül használni a bővített osztály példányát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016298

Egyke Résztvevők: Egyke: Meghatároz egy olyan Példány műveletet, amely lehetővé teszi, hogy az ügyfelek hozzáférjenek az osztály egyedi példányához. A Példány statikus metódus. Felelős saját egyedi példányának (objektumának) létrehozásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016299

Egyke Együttműködés: Az ügyfelek az Egyke példányt kizárólag az Egyke Példány műveletén keresztül érik el. Következmények: Az Egyke minta előnyei: Szabályozott hozzáférés az egyetlen példányhoz. Nincs globális változó. A leszármazással bővíthető az Egyke osztály funkcionalitása. Nem csak pontosan egy, hanem akárhány példány ellenőrzött létrehozására is alkalmas. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016300

C# megvalósítás public class Egyke { private static Egyke EgyediPéldány; public static Egyke Példány() { if (EgyediPéldány == null) EgyediPéldány = new Egyke(); return EgyediPéldány; } protected Egyke(){ … } … } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016301

Alternatív megoldás public class Egyke { private static Egyke EgyediPéldány; public static Egyke Példány() { return EgyediPéldány ?? (EgyediPéldány = new Egyke()); } protected Egyke() { … } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016302

Használat Egyke e=new Egyke(); Miért nem jó a fenti utasítás? A jó megoldás: Egyke e=Egyke.Példány(); Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016303

Simple Factory Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016305

Simple Factory Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016306

ClassicStyle public class ClassicStyle:Name {public ClassicStyle(string FullName) {string[] sa = FullName.Split(' '); LastName = sa[sa.Count() - 1]; FirstName = ""; for (int i = 0; i < sa.Count()-1; i++) {FirstName += sa[i]+" "; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016307

CommaStyle public class CommaStyle:Name {public CommaStyle(string FullName) { string[] sa = FullName.Split(','); FirstName = sa[1].Trim(); LastName = sa[0].Trim(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016308

NameFactory public class NameFactory {public NameFactory(string FullName) {if (FullName.IndexOf(",") > -1) Name = new CommaStyle(FullName); else Name = new ClassicStyle(FullName); } public Name Name{get; set;} } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016309

Adapter - Illesztő A cél egy olyan új osztály/objektum létrehozása, ami a korábbi osztály felhasználásával megvalósít egy elvárt új interfészt Például: a korábbi osztály rendelkezik Vezetéknév és Utónév tulajdonságokkal, de Teljesnév tulajdonsággal nem, és nekünk erre a tulajdonságra van szükségünk Megvalósítási módok Öröklődés Beágyazás Kiegészítés Bővítő metódus Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016311

Megoldás öröklődéssel public class Alap {public Alap(string V, string U) {Vezetéknév = V; Utónév = U; } public string Vezetéknév{ get; set; } public string Utónév { get; set; } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016312

Megoldás öröklődéssel public class Leszármazott:Alap { public Leszármazott(string V, string U):base(V,U){} public string Teljesnév { get { return Vezetéknév + " " + Utónév; } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016313

Megoldás öröklődéssel static void Main(string[] args) { Leszármazott l = new Leszármazott("Duli", "Fuli"); Console.WriteLine(l.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016314

Megoldás beágyazással public class Beágyazott {Alap Alap; public string Teljesnév { get { return Alap.Vezetéknév + " " + Alap.Utónév; } } public string Vezetéknév { get { return Alap.Vezetéknév; } set { Alap.Vezetéknév = value; } } public string Utónév { get { return Alap.Utónév; } set { Alap.Utónév = value; } } public Beágyazott(string V,string U) { Alap = new Alap(V,U); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016315

Megoldás beágyazással static void Main(string[] args) { Beágyazott b = new Beágyazott("Zsákos", "Bilbó"); Console.WriteLine(b.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016316

Megoldás kiegészítéssel public partial class Alap {public Alap(string V, string U) {Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016317

Megoldás kiegészítéssel public partial class Alap { public string Teljesnév { get { return Vezetéknév + " " + Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016318

Megoldás kiegészítéssel static void Main(string[] args) { Alap a = new Alap("Zsákos", "Frodó"); Console.WriteLine(a.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016319

Megoldás bővítő metódussal Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016320

Megoldás bővítő metódussal public sealed class Alap {public Alap(string V, string U) {Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016321

Megoldás bővítő metódussal public static class Bővítő { public static string Teljesnév(this Alap a) { return a.Vezetéknév + " " + a.Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016322

Bridge - Híd Egy képzeletbeli okos TV, amivel nézhetünk Kábel TV-t Műholdas adást IPTV-t A felhasználó lekérheti a műsort (Guide) és indíthatja a kiválasztott műsorforrás megtekintését Absztrakció: műsor lekérés, indítás Minden műsorforrás esetén más a megvalósítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 Forrás: http://www.codeproject.com/Articles/434352/Understanding-and-Implementing-Bridge-Pattern-in-C 324

Interfész interface IVideoSource { string GetTvGuide(); string PlayVideo(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016326

Megvalósítás class LocalCabelTv : IVideoSource { const string SOURCE_NAME = "Local Cabel TV"; string IVideoSource.GetTvGuide() { return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() { return string.Format("Playing - {0}", SOURCE_NAME); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016327

LocalDishTv class LocalDishTv : IVideoSource { const string SOURCE_NAME = "Local DISH TV"; string IVideoSource.GetTvGuide() { return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() { return string.Format("Playing - {0}", SOURCE_NAME); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016328

IPTvService class IPTvService: IVideoSource { const string SOURCE_NAME = "IP TV"; string IVideoSource.GetTvGuide() { return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() { return string.Format("Playing - {0}", SOURCE_NAME); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016329

RefinedAbstraction class MySuperSmartTV {IVideoSource currentVideoSource = null; public IVideoSource VideoSource { get { return currentVideoSource; } set { currentVideoSource = value;} } public void ShowTvGuide() { if (currentVideoSource != null) { Console.WriteLine(currentVideoSource.GetTvGuide()); } else { Console.WriteLine("Please select a Video Source to get TV"+ " guide from"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016330

RefinedAbstraction public void PlayTV() { if (currentVideoSource != null) { Console.WriteLine(currentVideoSource.PlayVideo()); } else { Console.WriteLine( "Please select a Video Source to play"); } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016331

class SuperSmartTvController { static void Main(string[] args) { MySuperSmartTV myTv = new MySuperSmartTV(); Console.WriteLine("Select A source to get TV Guide and Play"); Console.WriteLine("1. Local Cable TV\n2. Local Dish TV\n3. IP TV"); ConsoleKeyInfo input = Console.ReadKey(); switch (input.KeyChar) { case '1': myTv.VideoSource = new LocalCabelTv(); break; case '2': myTv.VideoSource = new LocalDishTv(); break; case '3': myTv.VideoSource = new IPTvService(); break; } myTv.ShowTvGuide(); myTv.PlayTV(); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016332

Futás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016333

Composite - Összetétel Forrás: Mathias Bartoll, Nori Ahari, Oliver C. Moldez: Design Patterns in C# Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016335

Az összetétel minta szerkezete Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016336

Composite – Ábra készítése Adattárolás fastruktúrában Demo: Composite Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016338

Observer - Megfigyelő Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 340

Közzétevő osztály (Részvény) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 341

Megfigyelő (Befektető) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 342

Feliratkozás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 343

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016344

Strategy - stratégia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 345

Megoldások/stratégiák Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 346

Illesztő modul Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 347

Használat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 348

Dependency Injection Interfész konkrét osztálynév helyett A Client csak az IService interfészről kell tudjon, az azt megvalósító Service osztály nevét nem kell ismerje Megoldások Constructor Injection Property (Setter) Injection Method Injection Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016350

Constructor Injection A szolgáltatást nyújtó osztály public interface IService { void Serve(); } public class Service : IService { public void Serve() { Console.WriteLine("Service Called"); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016351

Az ügyfél osztály public class Client { private IService _service; public Client(IService service) { this._service = service; } public void Start() { Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016352

Használat class Program { static void Main(string[] args) { client = new Client(new Service()); client.Start(); Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016353

Property (Setter) Injection A szolgáltatást nyújtó osztály public interface IService { void Serve(); } public class Service : IService { public void Serve() { Console.WriteLine("Service Called"); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016354

Az ügyfél osztály public class Client { private IService _service; public IService Service { set { this._service = value; } public void Start() { Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016355

Használat class Program { static void Main(string[] args) { Client client = new Client(); client.Service = new Service(); client.Start(); Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016356

Method Injection A szolgáltatást nyújtó osztály public interface IService { void Serve(); } public class Service : IService { public void Serve() { Console.WriteLine("Service Called"); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016357

Az ügyfél osztály public class Client { private IService _service; public void Start(IService Service) { this._service=Service Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016358

Használat class Program { static void Main(string[] args) { Client client = new Client(); client.Start(new Service()); Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016359

Template Method - Sablonfüggvény http://www.codeproject.com/Articles/482196/Understanding-and- Implementing-Template-Method-Des Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016361

Az absztrakt ős osztály abstract class AbstractClass { public abstract void PrimitiveOperation1(); public abstract void PrimitiveOperation2(); // The "Template method" public void TemplateMethod() { PrimitiveOperation1(); PrimitiveOperation2(); Console.WriteLine(""); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016362 http://www.codeproject.com/Articles/482196/Understanding-and-Implementing- Template-Method-Des

Leszármazottak class ConcreteClassA : AbstractClass { public override void PrimitiveOperation1() { Console.WriteLine("ConcreteClassA.PrimitiveOperation1()"); } public override void PrimitiveOperation2() { Console.WriteLine("ConcreteClassA.PrimitiveOperation2()"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016363 http://www.codeproject.com/Articles/482196/Understanding-and-Implementing-Template- Method-Des

Használat class MainApp { /// /// Entry point into console application. /// static void Main() { AbstractClass aA = new ConcreteClassA(); aA.TemplateMethod(); AbstractClass aB = new ConcreteClassB(); aB.TemplateMethod(); // Wait for user Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016364 http://www.codeproject.com/Articles/482196/Understanding-and-Implementing-Template- Method-Des

Eredmény Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016365 http://www.codeproject.com/Articles/482196/Understanding-and-Implementing-Template- Method-Des

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP, MVVM Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016366

Model-View-Controller (MVC) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 367 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0038_informatika_Projektlabor/ch01s04.html

MVC alapelvek „Loose coupling” „Program to the interface” Eredmények Jobb karbantarthatóság Könnyebb újrahasznosíthatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016368

MVC - általánosan Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 369 http://www.c- sharpcorner.com/UploadFile/rmcochran/MVC_intro12122005162329PM/MVC_intro.aspx

ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 370

MVC – ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 371 http://www.c- sharpcorner.com/UploadFile/rmcochran/MVC_intro12122005162329PM/MVC_intro.aspx

Preliminaries public enum AbsoluteDirection { North = 0, East, South, West } public enum RelativeDirection { Right, Left, Back } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016372

Program to the Interface + loose coupling Step 1 – Interfaces v1.0 Step 2 – Interfaces v2.0 Step 3 – Abstract Class Automobile Automobile.cs Step 4 – Concrete Automobile Implementations Truck.cs and RaceCar.cs Step 5 – Concrete Control Step 6 – Concrete View Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016373

Control Interface v1.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016374

Model Interface v1.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016375

View interface v1.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016376

Control Interface v2.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); void SetModel(IVehicleModel paramAuto); void SetView(IVehicleView paramView); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016377

Model Interface v2.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); void AddObserver(IVehicleView paramView); void RemoveObserver(IVehicleView paramView); void NotifyObservers(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016378 Observer Pattern

View interface v2.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); void Update(IVehicleModel paramModel); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016379

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

MVC minta megvalósítása Megolvalósítás Visual Studio 2013 segítségével Demo Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016381

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP, MVVM Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016382

Model-View-Presenter (MVP) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 383 Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0038_informatika_Projektlabor/ch01s04.html

MVC MVP Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 384

MVP Alkalmazási terület: adattárolással, megjelenítéssel, adatbevitellel kapcsolatos alkalmazások Célok: A kód minél nagyobb része automatikusan tesztelhető legyen (egységtesztek) Jól áttekinthető, könnyen megírható és könnyen karbantartható forráskód előállítása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016385

Alapgondolat A felhasználói felület, az üzleti logika és az alkalmazáson belüli adatmodell szétválasztása – külön osztályok Szerepkörök Model (adatmodell) View (megjelenítő réteg) Presenter (eseménykezelést, üzleti logikát megvalósító osztály) Laza csatolás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016386

Passive View A View nem tartalmaz semmilyen alkalmazáslogikát  a teljes alkalmazáslogika könnyen tesztelhető A P felelős a teljes munkafolyamatért – gyakran alkalmazzák ASP.NET alkalmazásokban Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016387

MVVM tervezési minta MVP továbbfejlesztése adatkötés alkalmazásával A minta megismerése egy gyakorlati példán keresztül Feladat: egy WPF-es hagyományos módon megírt alkalmazás átalakítása az MVVM tervezési mintának megfelelő struktúrába Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016389 Ábra forrás: http://www.codeproject.com/Articles/100175/Model-View-ViewModel- MVVM-Explained

Az alap alkalmazás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 390

Három részre bontás Model ViewModel View Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016391

A három interfész definiálása 1 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016392

A három interfész definiálása 2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 393

A Model és View osztályok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 394

A ViewModel osztály Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 395

Mikor érdemes? Jellemzők MVC: adatkötés, eseménykezelés a V rétegben MVP és MVVM : laza csatolás és növekvő kódmennyiség Mikor? Többen dolgoznak együtt, külön designer Párhuzamos munka lehetősége az interfészek definiálását követően Egységtesztek alkalmazhatósága Újrahasznosítható komponensek Könnyen cserélhető felület Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016396

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP, MVVM Data Mapper Repository Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016397

Data Mapper Martin Fowler 2003 Egy leképezési réteg, ami biztosítja az adatbázis és a memória objektumok közötti adatáramlást úgy, hogy az adatok az ábrázolási technikától és leképezésektől függetlenek maradjanak. Miért van rá szükség? – az objektumok és a relációs adatbázisok eltérően strukturálják az adatokat (pl. gyűjtemények, öröklődés, stb.) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016398

A DM használata mellett a memória objektumok nem kell tudjanak a relációs tárolásról, nem kell tartalmazzanak SQL kódot Így a DM réteget vagy az adatbázis réteget könnyen lecserélhetjük a teszteléshez Egyszerű DM: adattábla mező—adattag Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016399

Insert és Update esetén a DM-nek tudnia kell, hogy mely objektumok módosultak, keletkeztek, szűntek meg  tranzakció kezelési keretrendszer szükséges ld. Unit of Work minta Egy alkalmazáshoz több DM is tartozhat Hol találkozhattunk eddig DM-el? Table/DataAdapter EntityFramework Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016400

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC, MVP, MVVM Data Mapper Repository Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016401

Repository minta Alkalmazási terület Olyan programok, amelyek adatbázisban, SharePoint listákon, webszolgáltatásokon elérhető adatokon dolgoznak Célok A kód minél nagyobb része automatikusan tesztelhető legyen Központosítottan felügyelt adathozzáférés, következetes hozzáférés szabályozás Központosított adat-gyorstárazás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016402

Repository Célok (folytatás) Jól áttekinthető, könnyen megérthető és könnyen karbantartható forráskód előállítása Üzleti logika elválasztása az adat és szolgáltatás hozzáférési logikától Erősen típusos megoldások alkalmazása (ellenőrzés már fordítási időben) „Viselkedés” rendelése adatcsoportokhoz (pl. számított mezők, komplex kapcsolatok) Üzleti logika egyszerűsítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016403

Megvalósítás Egy „raktár” segítségével elválasztjuk az adatokat az őket lekérdező logikától Az üzleti logika független kell legyen az adatforrás rétegben alkalmazott adattárolási eszköztől (DB, SP, WS) Az R végzi az adatforrás lekérdezést, leképezi azt üzleti entitássá és visszafelé gondoskodik az üzleti entitáson végrehajtott módosítások tartós tárolásáról Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016404

Ábra Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 405 Data Mapper Adatforrás Query Object Üzleti entitás Tárolás Lekérdezés Üzleti entitás Ügyfél üzleti logika WS DB SP WS Proxy cache

Az R általában gyengén típusos alakban kapja meg a lekérdezés eredményét az adatforrástól és erősen típusos (objektum) formába alakítva továbbítja azt az üzleti logikai réteg felé Átalakítás: Data Mapper minta Az R elfedi a tényleges adatlekérés módját (pl. SQL), azaz az ügyfél nem kell tudjon arról, hogy pontosan milyen paranccsal lett lekérdezve az adatforrás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016406

Gyorstárazás és WS Az R gyakran gyorstárazást is megvalósít, amire akkor van különösen szükség, ha az adatelérés lassú (pl. WS) Ha az adatforrás egy WS, akkor az R némileg módosul, megjelenik egy proxy osztály: Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016407

Az alkalmazás hatásai Csökkenti a kódredundanciát Növeli az osztályok számát Részekre bont, ami megkönnyíti az egységtesztek készítését, az egyes részek mock objektumokkal való helyettesítését Többszálú környezetben a cache hozzáférést szinkronizálni kell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016408

Facade – Homlokzat minta Feladat: egy olyan objektum létrehozása, ami egyszerű interfészt biztosít egy komplex kódbázishoz, pl. egy osztálykönyvtárhoz Könnyebben használhatóvá teszi a könyvtárat Egyetlen átlátható rendszerbe foglal egy több API-ból álló szoftver gyűjteményt Elrejti a rendszer komplexitását egy burkoló osztály alkalmazásával. Pl. hitelképesség ellenőrzés (http://www.dofactory.com/net/facade-design- pattern)http://www.dofactory.com/net/facade-design- pattern Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016409

Bank osztály Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 410 class Bank { // … public bool HasSufficientSavings(Customer c, int amount) { Console.WriteLine("Check bank for " + c.Name); return true; } // … } http://www.dofactory.com/net/facade-design-pattern

KHR osztály Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 411 class KHR { // … public bool CreditHistory(Customer c) { Console.WriteLine("Check credit history for " + c.Name); return true; } // … }

Customer osztály Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 412 class Customer { private string name; public Customer(string name) { this.name = name; } public string Name { get { return name; } }

Credit osztály – a homlokzat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 413 class Credit { private Bank Bank = new Bank(); private KHR KHR = new KHR(); public bool IsEligible(Customer cust, int amount) { Console.WriteLine("{0} applies for {1:C} loan\n", cust.Name, amount); var eligible = true; if (!Bank.HasSufficientSavings(cust, amount)) { eligible = false; } else if (!KHR.GoodCreditHistory(cust)) { eligible = false; } return eligible; }

Program osztály Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 414 class Program { static void Main() { var Credit = new Credit(); var customer = new Customer("Ann McKinsey"); var eligible = Credit.IsEligible(customer, 125000); Console.WriteLine("\n" + customer.Name + " has been " + (eligible ? "Approved" : "Rejected")); Console.ReadKey(); }

Facade - homlokzat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 415 http://www.dofactory.com/net/facade-design-pattern

Tervezési minták osztályozása LétrehozásiSzerkezetiViselkedési Singleton (Egyke)AdapterObserver Simple FactoryBridgeStrategy Dependency InjectionCompositeTemplate Method MVC MVP MVVM Facade Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016416

Fontosabb szoftverminőség modellek Termék alapú megközelítés modellek McCall ISO 9126  ISO 25010 SCOPE NF Logiciel Folyamat alapú megközelítés CMM/CMMI Bootstrap SPICE Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016417

McCall 1978, James McCall a General Electrics egyik projektvezetője a végtermékre koncentrál a modellben meghatározzák a felhasználói alapszempontokat meghatározzák a termék minőségfaktorait (quality factors) a minőségfaktorokat minőségi jellemzőkre bontják (quality criteria) a minőségi jellemzőkhöz mérőszámokat rendelnek (metrics) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016418

McCall modell Három fő kategória (alapszempontok) Termék működése Termék átdolgozása Termék átvitel Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016419

A termék működéséhez kapcsolódó faktorok Correctness - Helyesség Reliability - Megbízhatóság Efficiency - Hatékonyság Integrity - Biztonság Usability - Használhatóság How well does it run and ease of use. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016420

Helyesség működési faktor ‘correctness’ issues are arising from the requirements documentation and the specification of the outputs… Examples include: Specifying accuracies for correct outputs at, say, <1% errors, that could be affected by inaccurate data or faulty calculations; Specifying the completeness of the outputs provided, which can be impacted by incomplete data Specifying the timeliness of the output (time between event and its consideration by the software system) Specifying the standards for coding and documenting the software system Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016421

Megbízhatóság és hatékonyság működési faktorok Megbízhatóság Reliability requirements deal with the failure to provide service. Address failure rates either overall or to required functions. Example specs: A heart monitoring system must have a failure rate of less than one per million cases. Downtime for a system will not be more than ten minutes per month Hatékonyság Deals with the hardware resources needed to perform the functions of the software. Here we consider MIPS, MHz (cycles per second); data storage capabilities measured in GB or TB; communication lines (usually measured in MBPS, or GBPS). Example spec: simply very slow communications… Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016422

Biztonság és használhatóság működési faktorok Biztonság – deals with system security that prevent unauthorized persons access. Használhatóság – deals with the scope of staff resources needed to train new employees and to operate the software system. Deals with learnability, utility, and more. Example spec: A staff member should be able to process n transactions / unit time. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016423

Termék átdolgozásához kapcsolódó faktorok Maintainability - Karbantarthatóság Flexibility - Átalakíthatóság Testability - Tesztelhetőség Can I fix it easily, retest, version it, and deploy it easily? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016424

Karbantarthatóság These deal with requirements that affect the complete range of software maintenance activities: corrective maintenance, adaptive maintenance, and perfective maintenance 1. Maintainability Requirements The degree of effort needed to identify reasons (find the problem) for software failure and to correct failures and to verify the success of the corrections. Deals with the modular structure of the software, internal program documentation, programmer manuals Example specs: size of module <= 30 statements. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016425

Átlakíthatóság és tesztelhetőség Átalakíthatóság– deals with resources to change (adopt) software to different types of customers that use the app perhaps a little differently May also involve a little perfective maintenance to perhaps do a little better due to the customer’s perhaps slightly more robust environment. Tesztelhetőség Are intermediate results of computations predefined to assist testing? Are log files created? Does the software diagnose itself prior to and perhaps during operations? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016426

Termék átvitel faktorai Portability - Hordozhatóság Reusability - Újrahasznosíthatóság Interoperability - Együttműködés Can I move the app to different hardware? Interface easily with different hardware / software systems; can I reuse major portions of the code with little modification to develop new apps? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016427

Hordozhatóság és újrahasznosíthatóság Hordozhatóság: If the software must be ported to different environments (different hardware, operating systems, …) and still maintain an existing environment, then portability is a must. Újrahasznosíthatóság: Are we able to reuse parts of the app for new applications? Can save immense development costs due to errors found / tested. Certainly higher quality software and development more quickly results. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016428

Együttműködés Együttműködési követelmények: Does the application need to interface with other existing systems Frequently these will be known ahead of time and plans can be made to provide for this requirement during design time. Sometimes these systems can be quite different; different platforms, different databases, and more Also, industry or standard application structures in areas can be specified as requirements. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016429

ISO/IEC 9126 (1991) ISO 9126:2001: „Software engineering — Product quality”. ISO 9126-1 helyett : ISO/IEC 25010:2011: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models Felhasználta: a McCall és Boehm modelleket a modellek használatában szerzett tapasztalatokat a korabeli piaci igényeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016430

Elvek az ISO által meghatározott szoftverminőség –a definícióból adódó összes aspektust lefedje a szoftvertermék minőségét a lehető legkevesebb átfedéssel határozza meg az alkalmazott technológiához a lehető legközelebb legyen az egyszerűség kedvéért max. 6-8 minőségi jellemzőt azonosítson azonosítsa a továbbiakban javítandó területeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016431

Minőségi jellemzők Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016432

Funkcionalitás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016433

Használhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016434

Megbízhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016435

Hatékonyság és karbantarthatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016436

Hordozhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016437

SCOPE Software assessment and CertificatiOn Programme in Europe http://www.cse.dcu.ie/essiscope/sm2/atwork/ scope.html 1989 – 1993 16 szervezet 8 országból (EU és EFTA) módszertan és technológia szoftver termékek értékelésére és tanúsítására Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016438

Célok hagyományos mérési technikák alkalmazási lehetőségeinek kutatása és ezen technikák kombinálása szoftver termékek értékelése céljából termék értékelése aszerint, hogy milyen mértékben felel meg az elvárásoknak, pl. az ISO 9126-ban megfogalmazott minőségi jellemzőknek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016439

Módszertan az értékelés ötlépéses folyamat az ISO 14598 két része (a hatból) innen lett átvéve négy értékelési szint: A (legszigorúbb) – D minden szinthez különböző értékelési módszerek szint minden minőségi jellemzőre egyedileg megválasztható magas kockázatú jellemzőknél szigorú értékelési szintet kell választani Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016440

Értékelési szintek megválasztása D: tulajdon kismértékű megkárosítása, emberek számára nem okoz kockázatot C: tulajdon veszélyeztetése, néhány személy kismértékű veszélyeztetése B: életveszély A: többen meghalhatnak Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016441

Értékelési modulok az értékelő által használható metrikákat és technikákat rögzítő dokumentum alkalmazási módszertan, alkalmazási módok előny: ismételhetőség és újra előállítható eredmények Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016442

D szintC szintB szintA szint Funkcionalitá s funkcionális tesztelés (black box) átvizsgálás (check lists) komponens teszt (glass box) formális ellenőrzés Megbízhatós ág programnyelvi adottságok hibatűrési elemzés Megbízhatóság növelési modell formális ellenőrzés Használható ság Felhasználói interfész felülvizsgálata Interfész szabványok nak való megfelelés labor teszt Felhasználói modell Hatékonyság Végrehajtási idő mérése benchmark algoritmikus komplexitás Teljesítmény elemzés Karbantartah atóság Dokumentumok felülvizsgálata statikus elemzés A fejlesztési folyamat elemzése Visszavezethe tőségi elemzés Hordozhatós ág Telepítés elemzése Programozási szabályokna k való megfelelés Környezeti korlátozások értékelése Programterv értékelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 443

NF Logiciel AFNOR (Association Francaise de NORmalisation) 1996 Logiciel =szoftver minden szoftverre alkalmazható alkalmazási területtől, funkcionalitástól és eredettől függetlenül megszerzéséhez nem előfeltétel a tanúsítás megléte az elvárások a minőségrendszerek tanúsításánál megfogalmazott elvárásokon alapulnak célja a szállított termék minőségének garantálása az NF Logiciel célja a szállított termék minőségének garantálása nem célja a minőségrendszer értékelése az NF Logicielnek nem célja a minőségrendszer értékelése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016444

NF Logiciel alapelvek 1 ISO/IEC 12119-ből levezetett elvárások teszt dokumentációval szembeni elvárások egyes szoftverkategóriákhoz speciális elvárások Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016445

NF Logiciel alapelvek 2 ISO/IEC 12119-ből levezetett elvárások minden szoftvercsomaghoz készüljön termékleírás fő célja, hogy segítse a felhasználót vagy potenciális vásárlót annak értékelésében, hogy megfelelő-e a termék számára és megalapozza a tesztelést tartalmi követelmények minden szoftvercsomaghoz készüljön felhasználói dokumentáció legyen teljes, korrekt, következetes, érthető és könnyen áttekinthető programokhoz és adatokhoz kapcsolódó elvárások: telepíthetőség, elvárt funkciók, megbízhatóság, használhatóság... előírások arra, hogy hogyan kell tesztelni a minőségi elvárásoknak való megfelelést Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016446

NF Logiciel alapelvek 3 A teszt dokumentációval kapcsolatos elvárások: tartalmaznia kell: teszt tervet validálási stratégiát teszt specifikációt teszt eredményeket követhetőséghez szükséges azonosító elemeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016447

NF Logiciel alapelvek 4 egyes szoftverkategóriákhoz speciális elvárások, mint pl. mechanikai szerkezetek számításai, fordítók, adatátvitel minőségbiztosítási szempontokból az ISO 9001 követelményeinek egy részét átvették Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016448

Tanúsítási eljárás az ANFOR (francia tanúsítási testület) által akkreditált tesztlabor egy tesztjelentést készít ANFOR minőségügyi audit bizottsági döntés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016449

Fontosabb szoftverminőség modellek Termék alapú megközelítés modellek McCall ISO 9126  ISO 25010 SCOPE NF Logiciel Folyamat alapú megközelítés CMM/CMMI Bootstrap SPICE Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016450 Ismétlés

A SZOFTVERMINŐSÉG FOLYAMAT ALAPÚ MEGKÖZELÍTÉSE Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 451

Szoftverfolyamat érettsége A szoftver folyamat érettsége: Annak mértéke, hogy egy folyamat mennyire pontosan meghatározott, vezérelt, mért, ellenőrzött és hatékony. Az érett szoftver folyamat: Meghatározott (definiált), vezérelt, mért, ellenőrzött, hatékony és javulásra képes. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016452

Érettségi modellek Lépcsős modellek (staged models) Teljes szervezet CMM, Bootsrap Folytonos modellek (continuous models) Kiválasztott folyamat(ok) SPICE/ISO 15504 Kombinált, integrált modellek: ötvözik a kétféle modellt, a bizonyítottan hasznos elemeket kiválasztva Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016453

Lépcsős modellek A szervezet egészét vizsgálják Úgy tekintik, hogy a szervezetben „egyetlen” folyamat van, a „szervezeti szintű folyamat”, ez maga a szoftverfejlesztési folyamat, amely magába foglalja: a szoftverfejlesztésben részt vevő embereket a szoftverfejlesztésben alkalmazott technológiát a szoftverfejlesztésben alkalmazott módszereket a szoftverfejlesztésben alkalmazott eszközöket... Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016454

CMM Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016455 1 2 5 4 3 Kezdő Ismételhető Definiált Menedzselt Optimalizált

Capability Maturity Model Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 456 Értékelési kérdőív (módszer) kidolgozása szoftverfejlesztő vállalatok számára (Eredetileg az Amerikai Védelmi Minisztérium megrendelésére készült, amelyet a SW-beszállítóinak értékelésére akart használni) (1987) Ezt a módszert az USA-ban a Carnegie Mellon Egyetem Software Engineering Institute (SEI) intézete dolgozta ki (1991) Referenciamodell a később ez alapján levezetett modellek számára: Bootstrap-Assessment (európai értékelési módszer) (1992) és a Siemens-OPAL-Assessment (ZT SE) (1992) Először csak szoftver folyamat értékelése (SW-CMM), majd kibővül általános folyamatmodell értékeléssel (SW-A-CMM, SE- CMM, People-CMM) (1995)

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 457 A CMM szerepe CMM egy referenciamodell, amely a helyes gyakorlatot mutatja a szoftverfejlesztésben CMM szintek alapján meghatározható a szervezet érettségi szintje egy adott referenciamodellhez viszonyítva CMM szintek alapján értékelhetők a SW-beszállítok (pl. DoD, Boeing, NASA) CMM Assessment (értékelés) irányadó a szoftverfejlesztési tevékenység folyamatfejlesztésében a célok prioritások koncepciók meghatározásában

A CMM felépítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016458 Folyamatváltozás-menedzselés Technológiai innováció Hibamegelőzés Minőségmenedzselés Folyamatmérés és -elemzés Képzési program Review-k, szemlék Folyamatközpontúság Szervezeti folyamatok meghatározása Integrált folyamat menedzselés Szoftvertechnológia Csoportközi együttműködés Konfiguráció-menedzselés Minőségbiztosítás Alvállalkozó-menedzselés Projektkövetés Projekttervezés Követelménymenedzselés

Első - Kezdő szint Jellemzői: Tervezés hiánya Dokumentálás hiánya, ill. ésszerűtlensége „Tűzoltóakciók” Nem működő kommunikáció Tisztázatlan kompetenciák és felelősségek Végeredmény : Hibás szoftver (funkcionális, technikai) Kötbér Elégedetlen vevő Elégedetlen munkatársak, vezetők, tulajdonosok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016459

Második - Ismételhető szint Jellemzők: Dokumentált folyamatok Projekt tervezés és követés (költség, idő, minőség) Kialakult projekt menedzsment irányvonal Tapasztalati bázis (becslések, előrejelzések) Állandó módszerek, technikák, eljárások Végeredmény: Ismételhető folyamat Ismételhető folyamat Reális ígéretek tétele Hosszú távú működőképesség Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016460

Harmadik - Definiált szint Hangsúly a szervezeten A menedzsment folyamatosan kap adatokat a szervezet és az egyes folyamatok működéséről A folyamatokat a szervezet speciális igényeihez igazítva alakítják ki A folyamatok rendszerezettek és ellenőrzöttek „Helyes gyakorlat” (minták) definiálása Hangsúly a dolgozók oktatásásn Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016461

Negyedik - Menedzselt szint Jellemzők: Statisztikai kontroll Mutatószámrendszer (termelékenység, minőség) Eltérésvizsgálat („kell” és „van” érték) Hatékony korrekciós intézkedések Végeredmény: Szabályozott menedzselt folyamat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016462

Ötödik - Optimalizált szint Jellemzők: Hibamegelőzés Állandó folyamatjavítás Innovatív szellemiség Motivált munkatársak Végeredmény: Önadaptív folyamat Lehetőségeinek határát ostromló vállalat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016463

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 464 Az értékelés (Assessment) kérdéslistája Folyamatkritériumok Vezetési Projekttervezés és projektkövetés Alvállalkozó- menedzselés Minőségbiztosítás Konfiguráció- menedzselés Mérnöki Követelmény- menedzselés Rendszer -engineering és -érvényesítés SW-előállítás SW-integráció és teszt HW-előállítás HW- integráció és teszt Újrafelhasználás Szervezési Folyamatdefiníció és -fejlesztés Képzés Folyamat és termék mérése Folyamat- és technológiai javítások

A CMM felépítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016465

A Bootstrap módszer A CMM kiterjesztése / változata Az EU ESPRIT projektje keretében dolgozták ki, 1991.szept. és 1993 febr. között a szoftverfejlesztési folyamat minőségének felmérésére és javítására szolgál, és többek között CMM-re valamint az ISO, ESA, DoD, IEEE, NATO szoftverminőségi szabványokra épül Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016466

Bootstrap a felmérés a CMM-en kívül az ISO 9001 és ISO 9000-3 szabványokat is felhasználja, így kimutatható az is, hogy az ISO 9001 tanúsítvány megszerzéséhez mely követelmények teljesülnek, és melyek nem a szoftver fejlesztési folyamat szervezettségét tekinti elsődlegesnek, de foglalkozik a fejlesztés módszertanával és a fejlesztés technológiájával is Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016467

Bootstrap jellemzők a szoftverfejlesztési egység (SPU: Software Production Unit) és a projektek számára szükséges területeket, folyamatokat és tevékenységeket határoz meg három vonatkozásban auditálja az SPU-t és a projekteket: szervezet módszerek technológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016468

Alkalmazásának előnyei felkészít az ISO 9000 szerinti minősítésre olcsóbb az ISO 9000 felmérésnél útmutatást ad a magasabb szint elérésére nemcsak egész értékekben kifejezhet érettségi szinteket mutat (pl. lehet 2.75) a különböző attribútumok érettségi szintjeit külön is megmutatja Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016471

Folytonos modellek Az egyes folyamatokra (és nem a teljes szervezetre) állapítanak meg érettségi szinteket bizonyos jellemzők alapján A modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét szeretné vizsgálni SPICE/ISO 15504 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016472

SPICE/ISO 15504 Software Process Improvement and Capability dEtermination A projekt 1993-ban indult, hivatalos szabvány 2002 http://www.esi.es/Projects/SPICE.html http://www.sei.cmu.edu/iso-15504/ folyamatos modell az egyes folyamatokra (és nem a teljes szervezetre) állapít meg érettségi szinteket bizonyos jellemzők alapján a modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét szeretné vizsgálni Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016473

Jellemzők átfogó, referenciamodell a folyamatokra és a folyamatok érettségére vonatkozóan, kis-, közepes- és nagyvállalatok nemzetközi tapasztalatait összegezve keretrendszer folyamatok erősségeinek és gyengeségeinek feltérképezésére szoftverfolyamatok javítására és ilyen javítások mérésre amely segíti a szoftvert felhasználókat felmérni, hogy a szoftver gyártói mennyire „érettek” a célnak megfelelő, árban, időben és minőségben szoftvert szállítani folyamat felmérési modellek harmonizációjára szolgáló lehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016474

Jellemzők általános keretet és nyelvezetet ad a szoftver folyamat értékeléséhez egy referencia modellhez (folyamatok és folyamat képességek) folyamatképesség értékeléséhez elvárásokat fogalmaz meg, amelyeket ki kell elégíteni a sikeres felülvizsgálathoz a referenciamodellel való kompatibilitáshoz Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016475

Process Capability Dimension Defined on a six point nominal scale (0 to 5) Low end - level 0 (Not Performed): general failure to attain the purpose of the process; little or no easily identifiable work products or outputs of the process High end - level 5 (Optimizing): performance of the process is optimized to meet current and future business needs, and the process achieves repeatability in meeting its defined business goals. Based upon the ratings assigned to a set of nine process attributes Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016477

Képességi szintek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 478

Szintek 1. Végrehajtott 2. Menedzselt 1. teljesítmény menedzsment: 1. erőforrás igények meghatározása 2. a folyamat teljesítményének tervezése 3. a definiált tevékenységek implementálása 4. a tevékenységek elvégzésének menedzselése 2. a munka eredményének menedzselése 1. az integritásra és minőségre vonatkozó követelmények meghatározása 2. a szükséges tevékenységek meghatározása 3. a munka eredményének konfigurációkezelése 4. a munka eredményének minőségmenedzsmentje Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016479

3. Meghatározott 1. Meghatároz: 1. a szabvány folyamat meghatározása, 2. a szabvány folyamat testre szabása, 3. a meghatározott folyamat bevezetése, 4. visszajelzés a szabvány folyamatnak 2. a folyamathoz rendelt erőforrások 1. az emberi erőforrás kompetenciájának meghatározása 2. a folyamat infrastrukturális követelményeinek meghatározása 3. megfelelő képesség emberi erőforrások biztosítása 4. megfelelő infrastruktúra biztosítása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016480

4. Jósolható 1. folyamat mérése 1. folyamatok céljainak és a kapcsolódó mérőszámoknak a meghatározása 2. megfelelő erőforrások és infrastruktúra biztosítása 3. a meghatározott mérési adatok gyűjtése 4. annak figyelése, hogy a folyamat céljai teljesültek-e 2. folyamat ellenőrzése 1. elemzési és ellenőrzési technikák meghatározása 2. megfelelő erőforrások és infrastruktúra biztosítása 3. meglévő mérési eredmények elemzése 4. az eltérések azonosítása és szükséges beavatkozás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016481

5. Optimalizált 1. folyamat változása 1. a szabvány folyamatban szükséges változások azonosítása és jóváhagyása 2. a bevezetéshez szükséges erőforrások rendelkezésre bocsátása 3. a jóváhagyott változás bevezetése 4. a változtatás hatékonyságának vizsgálata 2. folyamatos javítás 1. javítási lehetőségek beazonosítása 2. bevezetési stratégia meghatározása 3. a testre szabott folyamat meghatározott területén végrehajtott módosítás bevezetése 4. a változtatás hatékonyságának vizsgálata Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016482

Az érettségi szint kiszámolása kérdőív Teljes – 1, Széleskörű – 0.666, Részleges – 0.333, Nem létező – 0 -ez 1-es szinten érvényes, más szinteken más számok vannak!!! átlagszámítás kérdéscsoportokra Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016483

Kérdőív Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 484

A folyamatok érettsége megállapítására un. „generic practices”- általános gyakorlat – leírásokat használnak hogy egy folyamat bizonyos érettségi szinten legyen, ahhoz meg kell lenniük a szinthez tartozó általános gyakorlat-elemeknek azt is értékelik, hogy ha egy folyamat bizonyos szinten van, akkor bizonyos (szintén általánosan leírt) célokat ki kell elégítenie, és bizonyos munka eredményeket (termékeket) kell létrehoznia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016485

SPICE és CMM azonosságok az állandó folyamatjavításra koncentrálnak a referencia modellt és az érettségi szint skálát az értékelés keretrendszreként alkalmazzák felismerik a képzett felülvizsgáló fontosságát felismerik az ismételhetőség, konzisztencia és összehasonlíthatóság fontosságát eltérések keretrendszer  módszer/modell referencia modell felépítése referencia modell célja Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016486

Referencia modell felépítése SPICE Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 487

Referencia modell felépítése CMM Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016 488

Referencia modell célja CMM a szoftver előállításával és karbantartásával kapcsolatos irányítási és technológiai gyakorlatra koncentrál – ez a 15504 céljainak egy alrendszerét fedi a legtöbb 15504 szerinti folyamat valamilyen szinten megtalálható a szoftver CMM-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016489

SPICE for SPACE kiinduló pontja az ISO 15504 European Cooperation for Space Standardisation ECSS E 40: Space Engineering – Software ECSS Q 80: Space Product Assurance – Software Product Assurance ISO 12207 European Space Agency értékelési modell az európai űripar szoftverei számára a 15504-hez képest: 4 új folyamat, 50 új "általános gyakorlat", Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2016490

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés