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

Slides:



Advertisements
Hasonló előadás
T ESZTELÉS. C ÉLJA Minél több hibát találjunk meg! Ahhoz, hogy az összes hibát fölfedezzük, kézenfekvőnek tűnik a programot az összes lehetséges bemenő.
Advertisements

Tamás Kincső, OSZK, Analitikus Feldolgozó Osztály, osztályvezető A részdokumentumok szolgáltatása az ELDORADO-ban ELDORADO konferencia a partnerkönyvtárakkal.
Projekt vezetés és kontroll – Mi történik a gépházban?
Hatékonyságvizsgálat, dokumentálás
Fischer Norbert. Szoftverfejlesztés jelenlegi problémái  Folyamatosan rövidülő határidők  Projekt indulásakor nem teljesen tiszta a funkcionalitás,
C++ programozási nyelv Gyakorlat hét
Rendszertervezés GIMP.
Munkaterv Miért szükséges, mik az előnyei?
Rendszerfejlesztés gyakorlat - © Fülöp Lajos
Minőségbiztosítási terv
A PROJEKT, A VÁLLALKOZÁSI SZERZŐDÉS SZEMSZÖGÉBŐL dr. Naszádos Krisztina NKKB Ügyvédi Iroda 2010.
Rendszerfejlesztés.
Energetikai gazdaságtan
INFORMÁCIÓRENDSZEREK FEJLESZTÉSÉNEK IRÁNYÍTÁSA.. Alkalmazás - projekt Alkalmazás - a vállalat tökéletesítésére irányuló új munkamódszer projekt - az új.
A webes tesztelés jövője
Programozás alapjai A programozás azt a folyamatot jelenti, melynek során a feladatot a számítógép számára érthető formában írjuk le. C++, Delphi, Java,
© Kozsik Tamás Beágyazott osztályok A blokkstrukturáltság támogatása –Eddig: egymásba ágyazható blokk utasítások Osztálydefiníciók is egymásba.
OSI Modell.
A szoftver.
Rendszerfejlesztés gyakorlat - © Nagy Csaba
UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Programozás II. 6. Gyakorlat const, static, dinamikus 2D.
Minőségirányítás a felsőoktatásban
Az e-kereskedelem (e-business)
Új OKJ vizsgafeladatok
Megvalósíthatóság és költségelemzés Készítette: Horváth László Kádár Zsolt.
Presentation Title Mozdonyvezetők információs rendszerének bővítése a Rail Cargo Hungaria Zrt-nél Készítette: Dányi Attila
Agilis szoftverkészítés (Agile software development)
Szervezetfejlesztési Program
Szoftvertechnológia Szoftvergyártás 2..
Szoftvertechnológia Bevezetés.
Szoftvertechnológia Rendszertervezés.
Miskolci Egyetem Informatikai Intézet Általános Informatikai Tanszé k Pance Miklós Adatstruktúrák, algoritmusok előadásvázlat Miskolc, 2004 Technikai közreműködő:
WEB MES (webes gyártásirányító rendszer) Kiss Miklós (G-5S8)
P ROGRAMOZÁS C# - BAN Kivételkezelés. P ÉLDA I. Nullával való osztás miatt kapjuk a hibaüzenetet.
Ipari középvállalat projektvezetőjének tapasztalatai az integrált vállalatirányítási szoftver bevezetési szakaszában Projektmenedzsment Fórum A kis-
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN
Programtesztelés. Hibák keletkezésének okai nem egyértelmű vagy hiányos kommunikáció fejlesztés közben maga a szoftver bonyolultsága programozói (kódolási)
Az elemzés és tervezés módszertana
1 Hernyák Zoltán Programozási Nyelvek II. Eszterházy Károly Főiskola Számítástudományi tsz.
VÉGES AUTOMATA ALAPÚ TERVEZÉSI MODELL
Rendszertervezés Alapfogalmak; Az informatikai rendszer
Controlling tevékenységek kritériumai Jelentésdialógus A jelentésben fontos tényezők ELŐADÁS ÁTTEKINTÉSE.
Programozás III UNIT TEST. És tényleg: Honnan lehet tudni, hogy működik-e vagy sem?
Az üzleti rendszer komplex döntési modelljei (Modellekkel, számítógéppel támogatott üzleti tervezés) II. Hanyecz Lajos.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia
Dr. Johanyák Zs. Csaba - Szoftvertechnológia
Szoftver születik Eötvös Konferencia Köllő Hanna.
Információs rendszer fejlesztése 4. előadás
Szoftver projektek Agilis
MTT MA Mérnöktanár mesterszak Elektronikus tanulás 3. konferencia.
A közszolgáltatásokra kifejlesztett általános együttműködési modell GYÁL VÁROS ÖNKORMÁNYZATÁNÁL Gyál, szeptember 30.
Haladó C++ Programozás Programtervezési minták – alapok Sonkoly Balázs
CMMI - VALIDÁCIÓ Suba Gergely.
2. Operációs rendszerek.
.NET FRAMEWORK Röviden Krizsán Zoltán 1.0. Tulajdonságok I Rövidebb fejlesztés 20 támogatott nyelv (nyílt specifikáció) 20 támogatott nyelv (nyílt specifikáció)
Continuous delivery: cél a működő szoftver
Modellek a számítógép megismeréshez Takács Béla
PROJEKTMENEDZSMENT. Projektmenedzsment a stratégia megvalósításának eszköze. Projekt egy-egy konkrét stratégiai program vagy részprogram.
Szoftvermenedzsment A szoftver fogalma programmodulok rendszerdokumentáció konfigurációs adatok, és ezeket tároló fájlok felhasználói dokumentáció a szoftver.
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method.
A szoftver mint komplex rendszer A fejlesztési módszertanok általános céljai: Összetett problémák kezelhetővé tétele A fejlesztési és megtérülési jellemzők.
Vállalatirányítási rendszerek bevezetése és tapasztalatai a KKV szektorban Oldal Zoltán vállalati tanácsadó Gy-M-S Kereskedelmi és Iparkamara KKV vezetők.
Ügyfélelégedettség-építés a HIFI-ben
Önértékelési projektterv
Istvan Simon, CEO & Founder
A problémafeltárás technikái
Kire milyen szerep vár egy mobil projekt során
Szoftver projektek Agilis
Elvárások és a realitás egy agilis pilot projektben a tanácsadó szemszögéből agilitas.hu | Copyright © 2013 Agile Coaching Kft. |
Szoftver projektek Agilis
Előadás másolata:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 SCRUM Források: http://en.wikipedia.org/wiki/Scrum_(software_development) http://hu.wikipedia.org/wiki/Scrum Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

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

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

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

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)

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 A Scrum folyamat Forrás: http://hu.wikipedia.org/wiki/F%C3%A1jl:Scrum_process.svg Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Scrum Task Board Forrás: http://upload.wikimedia.org/wikipedia/commons/1/1b/Scrum_task_board.jpg A követés történhet egy szoftver segítségével is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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: http://en.wikipedia.org/wiki/File:Daily_sprint_meeting.jpg 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 - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 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: http://en.wikipedia.org/wiki/File:SampleBurndownChart.png Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

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

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 http://www.inf.unideb.hu/kmitt/konvkmitt/szoftverteszteles/book.xml.html Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

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

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

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

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? 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 - 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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