5. előadás

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

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

3. 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 - 2014

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

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

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

7. Á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 - 2014

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

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

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

11. 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 - 2014

12. Agilis technikák eXtrém Programozás Scrum KristályTiszta és más Kristály módszertanok Dynamic Systems DevelopmentMethod FeatureDrivenDevelopment (Funkcionalitáson Alapuló Fejlesztés) Test DrivenDevelopment(Tesztelésen Alapuló Fejlesztés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

15. 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 - 2014

16. 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 - 2014

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

18. SCRUM Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

19. Scrum HirotakoTakeuchi & IkoyiroNonaka (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 - 2014

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

21. Scrum alapelvek • Avevő 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 - 2014

22. Szerepkörök1 • Termékgazda (ProductOwner): Termék teendőlista (ProductBacklog) • 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 - 2014

23. 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 - 2014

24. A Scrum folyamat Termék teendőlista (ProductBacklog) Sprint teendőlista (Sprint Backlog) Futam (Sprint) Egy működő szoftveregység (Working increment of the software) 2-4 weeks 24h

25. Termék teendőlista (ProductBacklog) • 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 - 2014

26. 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 - 2014

27. Futamtervező megbeszélés (Sprint planning) Elvégzendő feladatok kijelölése a termék teendőlistájáról (productbacklog) 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 - 2014

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

29. ScrumTaskBoard Forrás: http://upload.wikimedia.org/wikipedia/commons/1/1b/Scrum_task_board.jpg Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

30. Napi megbeszélés (Daily Scrum) Ábra: http://en.wikipedia.org/wiki/File:Daily_sprint_meeting.jpg • 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 - 2014

31. Burndown chart Ábra: http://en.wikipedia.org/wiki/File:SampleBurndownChart.png Naponta frissített diagram a futam állapotáról A hátralevő munka mennyisége Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

33. 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 - 2014

34. Szoftvertechnológia Szoftverek ellenőrzése és elemzése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

35. 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 - 2014

36. V modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

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

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

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

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

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

44. 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 - 2014

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

46. 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 - 2014

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

48. 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 - 2014

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

50. 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 - 2014