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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
5. előadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 A szoftverrendszereknél ma a legkritikusabb követelmény a gyors fejlesztés és üzembe helyezés. A hagyományos szoftverfejlesztési folyamatok viszont túl lassúak a gyorsan változó üzleti környezethez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Az agilis fejlesztés 12 alapelve1
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

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

Á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. Amikor csak lehet, aktívan kell dolgozni a rendszer komplexitásának (összetettségének) csökkentésén. Az ügyfél bevonása: az ügyfeleket minél jobban be kell vonni a fejlesztési folyamatba, hogy a rendszerkövetelményekről gondoskodjanak, azokat prioritizálják és kiértékeljék a rendszer minden egyes iterációját. Inkrementális átadás: a szoftver lépésenként fejlődik, az ügyfél adja meg a követelményeket, amelyeket majd az egyes lépésekben implementálni kell. Az emberek nem folyamatok: a fejlesztőcsapat képességeit ismerni kell és ki is kell használni. Hagyjuk, hogy a csapattagok a feladatokat a saját módszerükkel végezzék el, nem pedig előírt folyamatok szerint. A változtatás törvényszerű: számítani kell a rendszerkövetelmények változására, és úgy kell megtervezni a rendszert, hogy könnyű legyen a változtatások megvalósítása Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Amikor csak lehet, aktívan dolgozni kell a rendszer komplexitásának csökkentésén. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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 Mikor ne alkalmazzuk az agilis megközelítést? Nagyon nagy rendszerek, ahol a fejlesztésen több, különböző helyen lévő csapat dolgozik Beágyazott rendszerek, ahol a szoftver erősen függ a hardvertől Néhány kritikus rendszer, ahol a minden követelményt elemezni kell, hogy átvizsgáljuk a rendszert olyan kölcsönhatások után kutatva, amelyek veszélyeztetik a rendszer biztonságát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

SCRUM Források: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

Szerepkörök1 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ő A termékgazda feladata a product backlog karbantartása. A felhasználói történetek megírása történhet a csapattal közösen. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szerepkörök2 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

A Scrum folyamat 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 Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Termék teendőlista A „termék teendőlistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelmény leírásokat. A lista elemei lehetnek funkciók leírásai, kívánságok, ötletek, stb., amelyek prioritás szerint vannak rendezve. Tulajdonképpen azt tartalmazza, hogy mi a fejlesztés célja. A lista szabadon szerkeszthető bárki által, és becsléseket tartalmaz a bejegyzések üzleti értékére és ráfordításigényére vonatkozóan. A becslések abban segítik a terméktulajdonost, hogy meghatározza a bejegyzések sorrendjét és bizonyos mértékig a prioritásukat. Ha például a „helyesírás-ellenőrzés” és „repülőgép-szimulátor” funkcióknak azonos az üzleti értékük, akkor a kevesebb fejlesztési ráfordítást igénylő funkció fog magasabb prioritást kapni, hiszen annak jobb a megtérülése. A termék teendőlistája a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordításigényt a fejlesztők határozzák meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Ez lényegében egy iterációs ciklus. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Minden futam elején futamtervező megbeszélést tartanak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 A futam teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a futam során megvalósítandó funkciókat. Ez egyes funkciókat részfeladatokra bontják. A felbontást célszerű úgy elvégezni, hogy egy részfeladat 4-16 óráig tartson. Ilyen szintű részletezettség mellett a csapat összes tagja pontosan érti, hogy mit kell elvégezni, és mindenki kiválaszthatja a neki legmegfelelőbb részfeladatot. A futam teendőlistájában levő részfeladatokat nem rendelik személyhez, inkább a csapattagok választják ki azokat a meghatározott prioritások, szükségletek és a csapattag képességeinek megfelelően. A futam teendőlistája a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy feladattáblát (Task Board) használnak, amely követhető a teendők állapots („elvégzendő”, „folyamatban”, „elvégzett”, stb.) a futam során. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Scrum Task Board Forrás: A követés történhet egy szoftver segítségével is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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? Ábra: A napi megbeszélés célja, hogy a csapat tagjai összehangolják tevékenységüket. A résztvevők általában állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el). A Scrum Master feljegyzi és megpróbálja elhárítani az akadályokat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Burn down chart Naponta frissített diagram a futam állapotáról A hátralevő munka mennyisége The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart,[18] which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline. It should not be confused with an earned value chart. Ábra: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Sprint bemutató, elemzés (sprint review) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 A vélemény lehet egy puszta benyomás is, nem kell kidolgozott, szilárd álláspontnak lennie. A javaslatok nem kell kiérleltnek lenniük, a kidolgozás nem a visszatekintés része. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Növekmény (Increment) A korábbi és a jelenlegi futam által megvalósított teendők összessége The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints. At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The increment must be in usable condition regardless of whether the Product Owner decides to actually release it. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szoftverek ellenőrzése és elemzése
Szoftvertechnológia Szoftverek ellenőrzése és elemzése Szoftverellenőrzéssel kapcsolatos további irodalom: Ficsor Lajos, Dr. Kovács László, Krizsán Zoltán, Dr. Kusper Gábor: Szoftvertesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Bonyolult rendszereknél a V&V a teljes költségek 50%-át is kiteheti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

V modell A V&V szükségességét a teljes fejlesztési folyamat során tükrözi a V (szoftver életciklus) modell. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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 Egy menetben több független hiba is felderíthető. A ~ alapja a résztvevők szakmai tapasztalata. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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? Az ellenőrzés kezdetben kisebb egységekre összpontosít, majd a fejlesztés előrehaladtával a nagyobb egységek és végül a teljes rendszer következik. A legvégén a vevő végrehajthat egy elfogadási tesztsorozatot. Mit? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A hiányosságtesztelés folyamata
Teszteset: Input+elvárt output+ rövid leírás Minden követelményhez és rendszertulajdonsághoz legalább egy teszteset. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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) Olyan bemenet kell találni, ami rendellenes viselkedést eredményez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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 Integráció: a rendszer felépítése komponensekből. Az integrációs tesztelés magában foglalhat regressziós tesztelést is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Programtervezési minták
Szoftvertechnológia Programtervezési minták Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 Az újrahasznosítható osztályok tervezése nehéz feladat, mert két néha ellentmondó követelménynek kell megfelelni egyszerre. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

Egyke Szerkezet: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

C# megvalósítás 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(){ … } … A felhasználó csak a Példány() metóduson keresztül tudja példányosítani az osztályt. A metódus létrehozza az objektumot vagy visszaadja a már létező objektum referenciáját. Csak a Példány metódus nyilvános és statikus egyszerre, minden mást az objektum referencián Keresztül lehet elérni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

Hasonló előadás

Az előadások a következő témára: "Dr. Johanyák Zs. Csaba - Szoftvertechnológia"— 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:

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

Hasonló előadás

Az előadások a következő témára: "Dr. Johanyák Zs. Csaba - Szoftvertechnológia"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés