Szoftverfejlesztési életciklus és módszerek BBXEMI2SLE

Az előadások a következő témára: "Szoftverfejlesztési életciklus és módszerek BBXEMI2SLE"— Előadás másolata:

1 Szoftverfejlesztési életciklus és módszerek BBXEMI2SLE
Információbiztonság szakember/szakmérnök I. évfolyam TGF 18 terem 2017/18/2. félév 2018. március 24. Szoftverfejlesztési életciklus és módszerek BBXEMI2SLE Bódi Antal ITS tanúsítási irodavezető, PhD hallgató Óbudai Egyetem Biztonságtudományi Doktori Iskola KTI Közlekedéstudományi Intézet Nonprofit Kft. 1119 Budapest, Than Károly u. 3-5. Mobil: (+36-30)

2 Magamról Tanulmányok:
Óbudai Egyetem PhD hallgató Óbudai Egyetem Biztonságtudományi Doktori Iskola BME MBA menedzsment és infokommunikációs szakirány, KLTE okl. anyagtudományi mérnök-fizikus, KLTE okl. matematika-fizika-számítástechnika szakos középiskolai tanár KTI Közlekedéstudományi Intézet ITS tanúsítási irodavezető 2016-tól, NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. informatikai biztonsági referens, kormányzati informatikai-biztonsági projektek menedzselése, auditok és sérülékenységvizsgálatok szervezése, vezetése. Fontosabb projekt: eSZIG-eSIGN, Önkormányzati ASP, SZEÜSZ-ök (pl. AVDH, GovCA, KAÜ), ESR 112. Kopint-Datorg ZRt., Budapest, Az informatikai-biztonsági projekt előkészítése, PAJZS menedzselése. EKOP projektek. A Kormányzati Portál integrálása az Elektronikus Kormányzati Gerinchálózatba, a horizontális Kormányzati Portál fejlesztésének és alkalmazásüzemeltetésének irányítása. Ügyfélkapu szolgáltatás kialakítása. 2001 – Az Antenna Hungária DVB-T projektjében új szolgáltatási modellek kidolgozása UPC Magyarország Kft. Budapest ( ) A UPC Broadband és a UPC chello 1996 –1999. Szab-I-Net Kht., Az első magyarországi kábeltévé alapú szélessávú Internet szolgáltatás kialakítása, üzemeltetése és szolgáltatásfejlesztése. BGYTF, Nyíregyháza (Nyíregyházi Egyetem )

3 Kutatási témám: Közlekedésbiztonság fokozását megalapozó komplex ITS ökoszisztéma kialakításának kérdései témavezető: Dr. Maros Dóra PhD. Az ITS Ökoszisztéma alapjainak megteremtésével és a közlekedés egészének EU szinten közhiteles digitalizációjával – a társadalom „nem önvezető világból” az „önvezető világba” való átvezetésének elősegítését, valamint a XXI. századi közlekedésben a bizalom és a biztonság növelését tűzte ki céljául tól az 5G hálózatok kialakítása már hazánkban is elérhető közelségbe kerül, amely majd a közlekedést, az ipari termelést, az egészségügyet, az infokommunikációt – közvetve az emberek mindennapjait – megreformálja. Így lehetővé válik a teljesen automatizált, önvezető közúti járművek elterjedése, amely a fejlesztőket komoly technológiai kihívás elé állítja. Ezen kívül, egy teljesen más természetű problémával is meg kell küzdeni, éspedig az emberek részéről az önvezető rendszerekkel szemben jelentkező bizalmatlansággal. Leegyszerűsítve, itt két fő kérdéssel kell szembe néznünk: 1. Rábíznám-e a családtagjaimat olyan nem kötött pályás járműre, amelyet, emberi kontroll nélkül, számítógépes algoritmusok vezetnek, és felügyelnek? 2. Milyen lesz az – az egyáltalán nem rövid időtartamú – átmeneti periódus, amikor az önvezető járműveknek és a hagyományos nem önvezető járműveknek a forgalomban együtt kell majd működniük? Az átmenet vizsgálatára és menedzselhetőségére nemzetközileg elfogadott elképzelés még nem áll rendelkezésre; így a tervezett, kiterjedt interdiszciplináris együttműködést feltételező kutatási munka eredményeként döntő fontosságú hiányzó fejlődési láncszem hozható létre; joggal feltételezhető, hogy a sikeres témaművelés eredménye jelentős nemzetközi érdeklődésre is számot tarthat majd.

4 Akit bővebben érdekel Bódi Antal; Szabó Tivadar;Dr Wührl Tibor Drónok követése közhiteles módon REPÜLÉSTUDOMÁNYI KÖZLEMÉNYEK 2017: (2) pp SecWorld Bódi Antal, KTI

5 Szoftverfejlesztési életciklus és módszerek Tematika
A szoftverfejlesztési projekt életciklusa, fázisai és feladatai. A szoftverfejlesztés ellenőrzései (review és teszt). A konfiguráció-menedzsment (CM) jelentése és követelményei. Szoftverfejlesztési módszertanok: Vízesés modell, V-Modell, Scrum, CMMI. A Scrum és a Vízesés modell módszertanok összehasonlítása, rövid áttekintése. A követelménykezelés jelentősége, lépései. (Meghatározások, funkcionális és nem funkcionális követelmények. Biztonsági követelmények.) A tesztelés fázisai, lépései, problémái. (Speciális biztonsági szempontú követelmények.)

6 Informatikai projektek
Miért különleges a szoftvermenedzsment? A termék nem materiális. A termék különlegesen flexibilis. A szoftvermérnökség nem rendelkezik más mérnöki tudományokhoz hasonló szilárd alapokkal (pl. gépész-, villamosmérnök). A szoftverfejlesztési eljárás nem teljesen szabványosított. Az informatikai projektek sokszereplősek, sok az érintett (megrendelő, felhasználó, üzemeltető, stb.). Magasan kvalifikált emberek dolgoznak együtt, akik ennek megfelelő kezelést igényelnek. Az informatikai projektek általában nem hatalmas méretűek

7

8 Informatikai projektek fajtái
(szoftver-) Termékfejlesztési projekt (egyedi) Alkalmazásfejlesztési projekt Alkalmazásintegrációs projekt rendszerintegrálási projekt bevezetési projekt infrastruktúrafejlesztési projekt tanulmánykészítési projekt (felmérés, előkészítés, bevizsgálás) tesztelési projekt

9 Milyen a tökéletes szoftver projekt?
A megrendelő elégedett, mert a termék pontosan alkalmas a megadott célra. A felhasználók jól tudják használni a terméket, ettől munkájuk hatékonysága nő. A projekt pontosan a tervek szerint halad, betartja a határidőket és a költségkeretet. Minden hibát még az éles indulás előtt megtalálnak és kezelnek. A rendszer megfelel minden előírt követelménynek, legyen az a teljesítmény, a megbízhatóság, vagy a biztonság. A rendszer jól dokumentált, üzemeltethető és továbbfejleszthető.

10 Miért nem ilyen minden szoftverprojekt?
Röviden azért, mert jó szoftvert készíteni nehéz. Sok dolgot lehet elrontani, és elég egy is, hogy az egész projektet tönkre tegye. Rosszul felmért, vagy félreértelmezett követelmények, nem az készül el, amire a megrendelő számít. Rosszul kitalált felhasználói felület és folyamatok, vagy elhanyagolt oktatás, így a felhasználók kínlódnak a program használatával. A fejlesztési projekt egy „fekete doboz”, nem tudni hol tart, és milyen minőségű a készülő termék.

11 Miért nem ilyen minden szoftverprojekt?
Elhanyagolt, vagy rosszul végrehajtott a tesztelés, az éles üzemben jönnek elő a legkülönfélébb problémák. Rosszul megtervezett a rendszer, a továbbfejlesztések egyre nehézkesebbé válnak, egy-egy módosítás látszólag tőle független dolgokat is magával ránt, és a növekvő terheléssel a rendszer belassul. A rendszer rosszul dokumentált, az üzemeltetők kénytelenek a fejlesztőkhöz fordulni szinte minden problémával.

12 Mi kell a sikeres szoftverfejlesztéshez?
A programozókon kívül szükség van arra, aki: szakmailag irányítja a követelmény-felmérést és -elemzést, megtervezi a rendszer architektúráját irányítja a részletes tervezési, kivitelezési és tesztelési munkákat, elméleti és gyakorlati tapasztalattal egyaránt rendelkezik arról, hogy mitől működik jól egy szoftverprojekt, és mitől megy tönkre, felelős a szoftver koncepcionális egységéért, és az elvárt minőségéért.

13 architektúra: Terv, koncepció
architektúra: Terv, koncepció. A kifejezést tipikusan csak nagy vonalakban rögzített működési elvek, rendszerek leírására használják, de azonos alapelvek szerint működő hardverek vagy szoftverek gyűjtőfogalmaiban (pl. "x86 architektúra" vagy „ kliens-szerver architektúra") is előfordul. koncepció: elgondolás, terv, ötlet, nézőpont

14 A szoftver fogalma Szoftver (software) alatt a számítógépet működtető programok, szellemi termékek összességét értjük A szoftverfogalom tágabb körébe tartoznak mindazon utasítások illetve ezek sorozata (program), amelyek bizonyos feladatokat digitális számítógépen megvalósítanak, adatstruktúrák, amelyek lehetővé teszik az információfeldolgozást és dokumentumok, amelyek leírják a programok és a rendszer működését, használatát.

15 A jó szoftver tulajdonságai
a szoftverterméknek rendelkeznie kell a megkövetelt funkcionalitással és az elvárt teljesítménymutatókkal üzembiztonság (megbízhatóság és biztonságosság) hatékonyság (nem pazarolhatja a rendszererőforrásokat) használhatóság (rendelkeznie kell a megfelelő felhasználói interfész-szel és a szükséges dokumentációval) karbantarthatóság (követni tudja az igények változását)

16 Milyen jellemzők alapján értékeli az ügyfél a terméket?
költség (tágabb értelemben ideértve mindennemű ráfordítást, erőfeszítést és felhasznált időt) minőség (szabványoknak, előírásoknak, követelményeknek való megfelelés) rugalmasság (gyors reagálás az ügyfél és/vagy az üzleti környezet megvál­tozott igényeire és követelményeire)

17 Az információrendszer-szervezési projekt
Az információrendszer szervezési projektben megoldandó feladatok: ütemezés minőség-kezelés tervezés, modellezés megszervezése kódrendszer kialakítás be és kimenő adatok tervezés felhasználói felület-tervezés szoftver elkészítés dokumentálás bevezetés, üzemeltetés

18 Információrendszerek projektjeinek speciális jellemzői
a termék nehezen szabványosítható nehéz megtalálni a legmegfelelőbb szakembert kommunikáció, együttműködés fontossága könnyen elhúzódhat, külső hatások a végtermék nem kézzel fogható (egy információrendszer átalakítása jobb ter­melékenységgel jár, de nem kézzel fogható a termék) gyorsan változó környezetben helyezkedik el a számítógépes információrendszer úgynevezett ember-gép rendszer: az em­ber a meghatározó elem, a számítógép csak kiszolgáló funkciót tölt be a vezetőktől új szemléletmódot, új ismereteket követel meg

19 Munkaerő feltételek: A munkaerő képezi az informatikai projektek egyik legfontosabb erőforrását. Rendszerszervező Rendszertervező Programtervező Programozó Ügyvitelszervező Munkaszervező Üzemszervező Projektvezető Operációkutató IT és/vagy adat biztonsági felelős

20 Rendszertervező képes a rendszerszervező által vázolt elképzelés, koncepció megvalósítására főleg alrendszerek tervezését végzi együttműködik a felhasználóval, a programozókkal, az ügyvitelszervezőkkel Programtervező több programnyelvet is ismer szorosan együttműködik a rendszerszervezővel, a rendszertervezővel, az operációkutatóval, a programozóval és az ügyvitelszervezőkkel ismeri a program- és file-szervezést és az operációs rendszert Programozó programnyelveket ismer ismeri az információrendszer-fejlesztés folyamatát Ügyvitelszervező feladata az ügyviteli folyamatok kézi és számítógéppel (ügyviteli progra­mokkal) történő szervezése együttműködik a munka- és üzemszervezőkkel

21 Munkaszervező feladata a munkaerő hatékony foglalkoztatása, kihasználása Üzemszervező épületkialakítás, termelő és energiaellátó berendezések, közlekedés, szállítás szervezése (logisztika) Operációkutató különböző tevékenységek, folyamatok valamilyen szempontból optimális megoldásmódjával foglalkozik programozandó algoritmus meghatározása Projektvezető felelős a fejlesztésre fordított munka hatékonyságáért, illetve az idő- és költ­ségkeret, valamint a minőség betartásáért

22 Szoftvermenedzsment A szoftvermenedzsment vagy alkalmazás-menedzsment adott szoftverhez vagy szoftvercsomaghoz kapcsolódóan a beszerzésre, fejlesztésre, bevezetésre, üzemeltetésre, szolgáltatás-működtetésre, karbantartásra; továbbá az ezeket támogató folyamatokra, úgymint a dokumentálásra, minőségbiztosításra, konfiguráció-kezelés­re, problémakezelésre, változás-kezelésre vagy az érintett humánerőforrás képzésé­re koncentráló irányítási és végrehajtási funkciók együttese.

23 A szoftvertervezés (Mérnöki) tudományág, amely a szoftver-termékek minden nézetét érinti a rendszerspecifikációtól a rendszerkarbantartásig, továbbá felöleli a projekt­menedzsment gyakorlatát és a támogató eszközök fejlesztését

24 Szoftverköltségek A szoftverköltségek általában dominálják a teljes rendszerköltséget A SW/HW aránya 80% / 20% (korábban 20% / 80%). A karbantartás és szoftverevolúció költsége gyakran többszöröse a fejlesztés költségének. A szoftvertervezők célja költséghatékony szoftverek előállítása a lehető legrö­videbb idő alatt. Az integráció és a tesztelés költségei gyakran elérik a rendszerfejlesztés költségét. A rendszerevolúció költsége gyakran akár négyszerese is lehet a fejlesztés költségének. A költségek nagyban függnek a fejlesztendő rendszer típusától és a teljesít­mény és üzembiztonság követelményétől. A költségek megoszlása nagyban függ a fejlesztés modelljétől

25 A szoftvertechnológia
A szoftverfejlesztés tipikus kérdései: Miért tart olyan sokáig a programok befejezése? Miért nem találják meg az összes hibát, mielőtt a programot átadnák a megrendelőnek? Miért vannak nehézségek a fejlesztés előrehaladottságának mérésében? Miért olyan magasak a költségek? A szoftvertechnológia (software-engineering) a fentebbi kérdések megválaszolásával foglalkozik.

26 Szoftvertechnológia fogalma
A szoftvertechnológia elvárások, számítógépes technológiák, emberek és képességeik, idő, pénz és egyéb források kezelése egy olyan termék létre­hozására, amely megfelel a megrendelők elvárásainak, és ezt a terméket egy olyan folyamat során állítják elő, amelyik megfelel a fejlesztők elvárásainak. (Steward, 1987)

27 A szoftvertechnológia történetének főbb szakaszai
A kezdeti időszak (hatvanas évek) Kis programozói csoportok Kis programozói környezetek Gépi kódok és assembler nyelvek Primitív programozási segédeszközök Minden műveletet a programozó hajtott végre

28 A szoftvertechnológia történetének főbb szakaszai
A fejlesztés-központú időszak (hetvenes évektől a nyolcvanas évek második feléig) Magas szintű programnyelvek Strukturált programozás Fejlesztésközpontú vezetés A konfigurációkezelés bevezetése Rendszerszoftver-támogatás

29 A szoftvertechnológia történetének főbb szakaszai
A folyamat-központú időszak (nyolcvanas évek első felétől a kilencvenes évek végéig) Fejlesztő csoport Minőségbiztosítás Vezetési eszközök használata Életciklus szabványok Negyedik generációs nyelvek Alkalmazás-generátorok Objektum-orientált fejlesztés

30 A szoftvertechnológia történetének főbb szakaszai
A termelés-központú időszak (kilencvenes évek közepétől) Rendszerintegrátorok csoportja Termelő környezetek kialakítása Eszköz-specialisták Műhely-szerű termelés Megaprogramozás Kódgenerálás Magas szintű absztrakciók Formalizmus Következetes újrafelhasználás

31 Szoftver-fejlesztés A szoftverfejlesztési folyamat előre meghatározott célok érdekében végzett elemzési, tervezési és kivitelezési munka, amelynek eredménye egyrészt a számítógép-rendszer működését biztosító programrendszer, másrészt pedig valamilyen valós folyamatot, tevékenységet támogató szoftvertermék

32 A fejlesztés módszertana
A módszertan a módszerek egységes rendszere, amely meghatározott filozófiai álláspontra helyezkedve specifikálja az eszközöket, és a techno­lógiát. A módszer bizonyos feladatok elvégzéséhez szükséges, meghatározott feltételek között érvényes szisztematikus végrehajtási mód és ennek előírása.

33 A fejlesztési elvek-módszerek-eszközök csoportosítása

34 A fejlesztés kulcselemei
fejlesztési elvek fejlesztési módszerek/eljárások fejlesztési eszközök végrehajtás módja

35 . A szoftverfejlesztés háromszöge

36 A szoftver életciklusa
Annak megítélésében, hogy a szoftver-életciklust tárgyalva miről kell szólni, az MSZ ISO/IEC szabványt (továbbiakban ISO 12207) vesszük alapul. A szabvány egyik legnagyobb erőssége az, hogy a szoftvertermékekkel és szoftverszolgáltatásokkal a beszerzői, szállítói, fejlesztői, üzemeltetői, karbantartói, vezetői, minőségbiztosítói és egyéb támogatói, valamint felhasználói szerepben érintettek mindegyikének szempontjait figyelembe veszi

37 A szabvány tárgya, alkalmazási köre
Az ISO szabvány informatikai rendszerek és szoftvertermékek, valamint szoftverszolgáltatások beszerzői, szállítói, fejlesztői, üzemeltetői, karbantartói, veze­tői, minőségbiztosítási vezetői és felhasználói számára készült. A szabványt két felet érintő helyzetekben történő használatra tervezték, de lehet alkalmazni akkor is, ha a két fél ugyanabból a szervezetből való, továbbá saját ma­gára vonatkozó előírásként egyetlen fél is használhatja. A szabvány leírja a szoftver-életciklus folyamatok szerkezetét, de - érthetően - nem adja meg a folyamatokban szereplő tevékenységek és feladatok végrehajtásának, megvalósításának részleteit, azokat az alkalmazóinak kell magukra (szerződő felek­re, adott szervezetre, adott projektre) nézve kötelezően rögzíteni. Így a szabvány nem ír elő semmilyen konkrét életciklus-modellt vagy szoftverfejlesztési módszertant, megengedve a szabvány használójának, hogy ezeknek mindenkor az aktuális projekt sajátosságaihoz (tárgyköréhez, bonyolultságához, időtartamához, részvevőihez) leg­jobban illeszkedő változatát alkalmazza.

38 A szabvány a szoftverek életciklusa során végbemenő folya­matoknak három nagy csoportját különbözteti meg. Ezek a fő folyamatok, a támogató folyamatok és a szervezeti (irányítási) folyamatok. A szabvány összetettség tekintetében felülről lefelé haladva az aktivitások három szintjét eltérő nevekkel illeti. Legfelül állnak a folyamatok, ezek összetevői a tevékenységek, az utóbbiak pedig feladatokra tagolódnak

39

40 A szoftver-életciklus fő folyamatai
1.1 Beszerzési folyamat A rendszert, a szoftverterméket vagy szoftverszolgáltatást beszerző szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: a beszerzés indítása, ajánlati felhívás készítése, szerződés elkészítése és aktualizálása, szállítófigyelés, átvétel és befejezés. 1.2 Szállítási folyamat A beszerzőt a rendszerrel, a szoftvertermékkel vagy szoftverszolgáltatással ellátó szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: a rendelés (ajánlatkérés) megválaszolása, szerződéskötés, tervezés, végrehajtás és ellenőrzés, átvizsgálás és értékelés, leszállítás és befejezés.

41 1.3 Fejlesztési folyamat A szoftverterméket meghatározó és kifejlesztő szervezet (leginkább egy projekt) tevékenységeit tartalmazó folyamat. 1.4 Üzemeltetési folyamat A számítógépes rendszer üzemeltetését (rendelkezésre állását) annak valós környezetében a felhasználói számára biztosító szervezet tevékenységeit tartalmazó folya­mat. 1.5 Karbantartási folyamat A szoftvertermék karbantartását biztosító; vagyis a szoftver - aktualitásának és üzemeltethetőségének fenntartása céljából szükséges - módosításait intéző szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: probléma és módosításelemzés; módosítás kivitelezése; a karbantartás vizsgálata, elfogadása; átállás az új szoftverváltozatra, az elavult változat visszavonása.

42 A szoftver-életciklus támogató folyamatai
2.1 Dokumentálási folyamat Az életciklus-folyamatok által előállított ismeretek (értelmezések, követelmények, megoldások, megállapodások, döntések, utasítások, tervek, tények) rögzítésének tevékenységeit (dokumentum-tervezés és fejlesztés, előállítás, karbantartás) támo­gató folyamat. (Például a követelmény-leírások sablonjának elkészítése vagy a leírások utólagos formai szerkesztése ide tartozik, de a követelmény-leírások tartalmi szerkesztése a fejlesztési folyamat része).

43 2.2 Konfigurációkezelési folyamat
A konfiguráció-kezelés a szoftverkomponensek, a szoftverek, a szoftverekből felé­pülő rendszerek változatainak (verzióinak) azonosítását; a verziók változtatásainak felügyeletét, állapotfelmérését, értékelését, kiadását, leszállítását, visszavonását; továbbá mindezek nyilvántartását jelenti. Konfigurációkezelésre olyan termékek esetében van szükség, amelyek több változatban készülhetnek el. A szoftvertermék tipikusan ilyen: lehet egy üzemi környezetben, használatban lévő változata; de már elkészült a használt változat bizonyos hibáit, hiányosságait kiküszöbölő újabb változata, amely tesztelés alatt áll; közben folyamatban lehet egy lényegesen bővebb tudású változat fejlesztése is.

44 2.3 Minőségbiztosítási folyamat
Olyan tevékenységeket tartalmazó folyamat, amelyek objektív biztosítékot szolgáltat­nak arra, hogy a szoftvertermékek és szoftverfolyamatok megfelelnek a megfogalmazott követelményeknek és követik a kialakított terveket. Speciális területei a termékbiztosítás, a folyamatbiztosítás, a minőségügyi rendszer biztosítása. – Az együttes átvizsgálás, a felülvizsgálás, az igazolás és az érvényesítés a minőségbiztosítás operatív funkciói.

45 2.4 Igazolási folyamat – Verifikálás
A beszerző, a szállító vagy valamilyen független fél olyan tevékenységeit tartalmazó folyamat, amely szoftvertermékek igazoló ellenőrzésére szolgál a szoftverprojekttől függő, különböző mélységben. Az igazolási folyamat keretében azt kell bizonyítani, hogy a termék megfelel a rá vonatkozó terveknek (specifikáció). 2.5 Érvényesítési folyamat – Validálás A beszerző, a szállító vagy valamilyen független fél olyan tevékenységeit tartalmazó folyamat, amelyek a projektben szereplő szoftvertermékek érvényesítő ellenőrzésére szolgálnak. Az érvényesítési folyamat keretében azt kell bizonyítani, hogy a termék megfelel a rá vonatkozó szerződéses követelményeknek

46 2.6 Együttes átvizsgálási folyamat
Valamilyen projekttevékenység helyzetének vagy termékei állapotának értékelésére szolgáló tevékenységekből álló folyamat. Ezt a folyamatot tetszőleges két fél alkal­mazhatja, ahol valamilyen együttes ülésen az egyik fél (átvizsgáló fél) átvizsgálja a másik felet (átvizsgált fél). 2.7 Felülvizsgálási folyamat Ezt a folyamatot tetszőleges két fél alkalmazhatja, ahol az egyik fél (felülvizsgáló fél) felülvizsgálja a másik fél (felülvizsgált fél) szoftvertermékeit és tevékenységeit. Olyan tevékenységekből áll, amelyek megállapítják a követelményeknek, terveknek és szerződésnek való megfelelést. (Tehát a felülvizsgálat keretében történhet akár iga­zolási, akár érvényesítési célú vizsgálat, a lényeg hogy ezt két fél – a felülvizsgált és a felülvizsgáló – együttműködésben hajtja végre

47 2.8 Probléma-megoldási folyamat
Ez a folyamat a fejlesztés, az üzemeltetés, a karbantartás vagy más folyamat végrehajtása során feltárt problémák elemzésére és kiküszöbölésére szolgál, bármi legyen is azok természete és forrása. (A problémák elemzése változtatási igények megfogalmazásához is vezethet, ilyenkor a probléma-megoldási folyamat változás-kezelési folyamatba megy át.)

48 A fejlesztési, üzemeltetési, problémakezelési és karbantartási folyamatok kapcsolatai

49 Változáskezelési folyamat
A szabványban nem jelenik meg külön folyamatként a változáskezelés. Ez nem jelenti azt, hogy a szabvány készítői teljesen megfeledkeztek róla, csupán annak feladatait részben a konfigurációkezelési folyamatnak, részben a problémamegoldási folyamatnak adták át. A konfigurációkezelés és azon belül a konfigurációfelügyelet leírásából következik, hogy a szoftvertermékre vonatkozó változáskezelést – tehát a változtatási kérelmek nyilvántartásba vételét, elemzését, a jóváhagyott változtatási igényt teljesítő konfiguráció kijelölését, a teljesítés felügyeletét – a konfiguráció­kezelés részének tekintették. Ha azonban egy (beszerzési vagy fejlesztési) projekten belül felmerülő változtatási igény nem a projekt termékére, hanem a projekt tevé­kenységeire, ütemezésére, erőforrásaira, az alkalmazott módszerekre vagy a költségvetésre vonatkozik, akkor az ilyen igény kezelése a szabványban inkább a probléma-megoldási folyamat részét képezi.

50 Szoftverfolyamat A szoftverfolyamat olyan tevékenységek és kapcsolódó eredmények halmaza, ame­lyek célja a szoftver kifejlesztése és/vagy továbbfejlesztése. Számos szoftverfolyamat létezik, de néhány tevékenység azért minden szoftver­folyamatban közös: Követelményelemzés/szoftverspecifikáció: a szoftver működésének, és a működésre vonatkozó megszorításoknak a definiálása (mit kell tudnia a rendszernek). Szoftverfejlesztés: a szoftver elkészítése a specifikáció alapján. Validáció: annak ellenőrzése, hogy a szoftver valóban az, amit az ügyfél megrendelt. Szoftverevolúció: a szoftver átalakítása a megváltozott igényeknek megfelelően, a szoftver utóélete, továbbfejlesztése, javítása.

51 A fejlesztési folyamat életciklusa

52 A szoftverfolyamat modellje
A szoftverfolyamat modellje a szoftverfolyamat egyszerűsített leírása egy bizonyos nézőpontból: Szoftverfolyamat perspektívák: munkafolyam nézőpont adatfolyam nézőpont szerepkör / tevékenység nézőpont Munkafolyam (workflow) nézőpont A tevékenységek folyamatbeli sorrendiségét mutatja azok bemeneteivel, kimene­teivel és függőségeikkel. Minden tevékenység egy-egy emberi cselekmény.

53 Adatfolyam (dataflow) nézőpont
A folyamatokat olyan tevékenységekre bontja, amelyek mindegyike valamilyen adat-transzformációt hajt végre - bemutatja, hogy a folyamat bemenete hogyan alakul át kimenetté, pl. a specifikációból hogyan lesz kész szoftver – minden tevékenység em­berek, vagy gépek által végrehajtandó transzformáció. Szerepkör/tevékenység (role/action) nézőpont A szoftverfolyamatban résztvevő emberek szerepköreit, és a felelősségük alá tartozó tevékenységeiket mutatja be

54 Szoftverfejlesztési nézetek:
Vízesés modell V modell Inkrementális fejlesztés Evolúciós (prototípus) fejlesztés Spirális modell Rendszerintegráció újrafelhasználható komponensekből

55 Vízesés-modell „Vízesés” megközelítési módszerben az egyes tevékenységek a folyamat különálló fázisai, (pl. specifikáció, szoftvertervezés, implementáció, tesztelés, stb). Amikor egy tevékenység befejeződött, csak akkor kezdődhet el a következő.

56

57 Vízesés-modell jellemzői
A modell a folyamat alapvető tevékenységeit különálló fázisként tekinti. Ezek a fázisok lépcsősen kapcsolódnak egymáshoz A vízesés-modell problémája abból adódik, hogy a korai szakaszokban kell bizonyos kérdésekben állást foglalni. Akkor lehet jól alkalmazni, ha a követelmények előre jól ismertek. Az iterációk költségesek, hiszen a fázisok lezárásaként elkészülő dokumentumok előállítása idő és költségigényes. Egy-két iteráció után befagyasztják az egyes fázisokat, és a következő fázisra térnek át.

58 A modell előnyei: Világos struktúra; a projekt egyszerűen ütemezhető, irányítható.
A modell hátrányai: Mivel a követelmények meghatározása és végleges rögzítése az egyszeri elemzési fázis feladata, ez a modell feltételezi, hogy a követelmények az elején pontosan ismertek és később nem változnak. A valóságban a legtöbb esetben ez nem teljesül. Az elemzési szakasz végére nem lesz ismert minden követelmény, hiszen a felhasználó sem tudja pontosan, mit szeretne (majd akkor lesznek ötletei, ha lát valamit működni a rendszerből). Az összegyűjtött követelményeket is másképpen értelmezi a felhasználó és a fejlesztő; hosszabb projekt során a követelmények egy része közben elavul, helyettük újak keletkeznek. Így mind a követelmények, mind a tervek nem-megfelelőségét a felhasználó csak a működő szoftver bemutatásakor veszi észre; illetve a fejlesztő az időben fel nem fedezett hibák miatti problémák tömegével a finisben, az integráció során szembesül

59 „V” modell A V-modell a vízesés modell speciális változatának tekinthető (következő ábra). A V-modell életciklus elképzelése nemcsak az egyes fázisok időbeli sorrendjéről szól, hanem arról is, hogy az egyes fázisokban mely korábbi fázisok termékeit kell felhasználni; illetve az adott fázis tevékenységét és termékét mely korábbi fázisban leírt követelmények, illetve elkészített tervek alapján kell ellenőrizni (verifikálni).

60

61 „V” modell jellemzői Azon felül, hogy ez a modell nagyon jó támpontokat ad a verifikáció végrehajtásához, előnyeiről és hátrányairól hasonlók mondhatók el, mint a vízesés modellnél.

62 Evolúciós fejlesztés nem választja szét, hanem összemossa a specifikáció, a fejlesztés, és a kódolás fázisát egy kezdeti specifikációból előállít egy prototípust, a megrendelő ennek alapján finomítja a specifikációt. Ebből a fejlesztők készítenek egy újabb verzi­ót, és a folyamat addig ismétlődik, amíg a kívánt rendszer el nem készül.

63 A modellnek többféle változata ismert, ezek főleg abban különböznek, hogy a prototípus
csak a követelményeket teszteli a terveket is teszteli

64

65 Evolúciós fejlesztés jellemzői
A modell előnyei: Gyorsan elkészülnek az ember-gép kommunikációval kapcsolatos funkciók; idejében kiderülnek a félreértések, pontosabbak lesznek a követelmények, kipróbálhatók az alternatív megoldások, csökken a kockázat. A fejlesztő és a felhasználó személyes együttműködése növeli a felhasználó elégedettségét, a fej­lesztési célok iránti elkötelezettségét

66 A modell hátrányai: Egy átfogó projektterv helyett a fejlesztést a felhasználó ötletei irányítják, így nincs átlátható folyamat, nem mondható meg, hogy a „kész állapothoz” képest hol tart a projekt. A módszer újabbnál újabb igények támasztására ad ötletet a felhasználónak, ezért az igények folyamatos növekedésének gátat kell szabni a rendszer határainak megvonásával és egy erőskezű projektvezetéssel.

67 Inkrementális fejlesztés
Az inkrementális fejlesztési szemlélet a részfeladatok kidolgozását egy kezdeti modellel indítja, majd ezt a gyakorlati hasznosság, és a felhasználói követelmények szerint több lépésben finomítja. Ezzel valójában az egyes elemeknek több verziója készül el, ezeket nevezzük inkrementumoknak. Mivel a fejlesztés során a komponensek elkészítésének sorrendje nincs szigorúan szabályozva, a fejlesztés kockázatának csökkentése érdekében először a problema­tikus részeket érdemes kifejleszteni. Ha ezek elfogadhatóak, akkor a már meglévő termékből kiindulva elkészíthető egy megnövelt képességű, újabb változat . (inkrementális: növekvő)

68

69 Inkrementális fejlesztés jellemzői
Az inkrementális fejlesztés nagy hátránya, hogy rendszerint hosszú átfutási időt, és soklépéses fejlesztés igényel, hibái ellenére mégis egyértelmű előnyeként kell felhozni, hogy hatékony megoldást kínál olyan fejlesztéseknél, ahol: nem definiálhatók előre pontosan a működés architektúrája és algoritmusai a megoldhatóság legalkalmasabb technikai-technológiai feltételrendszere a pontos, fejlesztéssel kapcsolatos elvárások

70 Spirális modell A szoftverfolyamatot nem tevékenységek, és a közöttük található esetleges visszalépések sorozataként tekinti, hanem inkább spirálként reprezentálja. A spirálban minden egyes kör a szoftverfolyamat egy-egy fázisát jelenti

71

72 A spirált 4 szektorra oszthatjuk fel:
Célok kijelölése: egy adott projektfázis által kitűzött célok meghatározása Kockázat becslése és csökkentése: minden egyes felismert projektkockázati tényező esetén részletes elemzésre kerül sor. Ha például fennáll a kockázata annak, hogy a követelmények nem megfelelők, akkor prototípust lehet fejleszteni.

73 Fejlesztés és validálás: a kockázatok mérlegelése után egy megfelelő fejlesztési modellt választunk. Például, ha a felhasználói felület kérdései domi­nánsak, akkor evolúciós fejlesztés, ha az alrendszerek integrálása kritikus, akkor vízesésmodell. Tervezés: A projektet áttekintjük, és eldöntjük, hogy elkezdhető-e a következő fázis. Ha igen, akkor felvázoljuk a projekt következő fázisát

74 Fontos különbség az inkrementális és a spirális modell között, hogy a spirális kimondottan számol a kockázati tényezőkkel.

75 Rendszerintegráció újrafelhasználható komponensekből
A modell szerinti fejlesztés az új rendszert újrafelhasználható komponensekből állítja össze. Feltételezzük, hogy a rendszer egyes komponensei már léteznek. Ekkor a feladat a megfelelő elemek kiválasztására és integrálására „egyszerűsödik”. Ha ismert olyan implementáció, amely hasonlít a kívánthoz, akkor célszerű azt átalakítani, majd beépíteni a rendszerbe. Ez elősegíti a gyors fejlesztést.

76

77 Fejlesztő és tesztelő eszközök
A nagy, komplex informatikai rendszerek, szoftveralkalmazások fejlesztése napjaink­ban rendkívüli kihívást jelent a fejlesztők számára. A gazdasági versenyre való gyors reagálás, az új digitális technológiák alkalmazása, a hatékonyabb módszerek kihasz­nálása a hagyományos megoldásokkal már nem lehetséges

78 Annak érdekében, hogy garantálni lehessen a fejlesztett alkalmazás biztonságos, hibamentes működését, már a fejlesztési munka során arra kell törekedni, hogy valós folyamatok érthető módon legyenek modellezve, ezek a modellek egyszerűen módosíthatóak legyenek, és hogy a fejlesztő és a felhasználó egyformán értelmezze azokat. A fejlesztési munka különböző technikai támogatással végezhető, a fejlesztésben részvevők közötti párbeszéd eltérő formákban valósítható meg, a dokumentációk készítésénél pedig számos szemléltetésre alkalmas eszköz áll rendelkezésre

79 A fejlesztés alapvető célja a valós folyamatok számítógéppel történő támogatása, egy olyan szoftvertermék kifejlesztése, amely magas szinten elégíti ki a felhasználó elvárásait. Egy elkészített program akkor adható át a felhasználónak, ha mind a reális folyamatokból vett, mind pedig a szélsőséges adatokkal kipróbálták, és a szoftver minden esetben hibátlanul működve az elvárt eredményt produkálta. A tesztelés célja a szoftvertermék elvárt minőségének garantálása, a tesztadatok előírása, a tesztelési és elfogadási kritériumok definiálása, a lefuttatott eredmények minősítése pedig a tesztelő szakemberek feladata.

80 Fejlesztő eszközök 4GL, 5GL alkalmazásfejlesztők:
a 4GL-ek platform-független, feladatorientált környezetet biztosítanak a fejlesztők (programozók) szá­mára. Az adatbázis-definiálási és -manipulációs megoldásokkal, a CASE eszközök­höz való csatlakozás lehetőségével a változtatásokhoz könnyen igazodó fejlesztési támogatást nyújtanak.

81 Adatspecifikációs, -lekérdezési és –manipulációs lehetőségek
Ezek a fejlesztőeszközök számos területen segítik a programfejlesztők munkáját: Környezeti feltételek pontos specifikálása, kezelése, dialógustervezés, képer­nyőszerkesztés Adatspecifikációs, -lekérdezési és –manipulációs lehetőségek Adatszótár Adatbázis fizikai struktúrája Adatbázis-elemek létrehozása, törlése, módosítása Lekérdezések létrehozása

82 Programtervezési támogatás
Adatnézet, programszótár Kifejezéstábla Folyamatleírás-tábla Kódgenerálás Grafikus felhasználói felület tervezése, létrehozása Output-terv generálása, jelentéskészítés Interaktív űrlapok Űrlapok összekapcsolása Mezők verifikálása

83 Előnyei: csökken a fejlesztési idő, nincsenek szemantikai hibák, bizonyos funkciók tesztelésére nincs szükség Növekszik a fejlesztési munka hatékonysága, optimalizált programok készülnek, nincs szükség a program szintaktikájának pontos ismeretére, egyszerűen készíthetők prototípus-változatok. A nyelvek rugalmassága leegyszerűsíti a fejlesztés során a változtatások átvezetését

84 jól illeszkedik a Windows-ban megszokott felülethez.
A szabványos megoldások lehetővé teszik a különböző környezetben végzett munkát, és biztosítják a platform-függetlenséget, hordozhatóságot. Támogatják a web-böngészőkön alapuló adatbázis-felületek fejlesztését. Rendelkeznek csoportmunka-támogatás képességgel, javul a tervező és a programozó közti kommunikáció.

85 Hátrányai: A 4GL/5GL-es fejlesztések termékei a működtetés során lassúbbak, mint a hagyományos nyelven elkészített alkalmazások, összetett rendszerek esetében pedig nemcsak az egyes programok belső struktúrája, hanem a programrendszer architektúrája is áttekinthetetlenné válhat.

86 A szoftverfejlesztési módszertan
A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le Útmutatást ad a csoportmunka irányítására Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát Kritériumokat ad a termékek és tevékenységek mérésére és minősítésére Ritkán jelennek meg tiszta, ideális formában A fejlesztési folyamat egyfajta logikai absztrakciója.

87 Szoftverfejlesztési modellek (életciklus modellek)
„Do Until Done” modell Vízesés modell V-Modell Evolúciós modell Iteratív fejlesztések Spirál modell Inkrementális fejlesztés (UP, RUP) Az idő és az információ „áramlása” szerint tárgyalják, csoportosítják a fejlesztési tevékenységeket A szoftverfejlesztés kezdeti időszakában a programozók még többnyire egyedül dolgoztak, így nem volt szükség módszertanokra és folyamatmodellekre. A munka az úgynevezett „Do Until Done” modell alapján folyt, vagyis a programozó addig próbálkozott a program javításával, amíg az azt nem csinálta, amit várt tőle. A modellválasztás függ a feladat jellegétől. Például kis project számára a vízesés modell lehet a legjobb, egy nagy projectnek viszont megfelelőbb lehet egy iteratív eljárás.

88 A fázisok erőforrás- és időigénye
65% 10% 20% 5% A különböző jellegű fejlesztéseknél az egyes fázisok idő illetve erőforrás igénye lényegesen különbözhet. Például egy létező termék újabb verziójánál az előkészítő fázis majdnem nullára zsugorodhat, s a kidolgozási fázis is rövid lehet. Ugyanakkor egy ismeretlen szakterülten, ismeretlen eszközökkel végzett fejlesztés esetében az előkészítés igen hosszú ideig tarthat. Egy viszonylag átlagos fejlesztés esetében szokásos idő és erőforrás ráfordítást mutatja az ábra: Általános jellegzetesség, hogy az építési fázis a leghosszabb és a legnagyobb erőforrás igényű. Viszonylag általános jellegzetesség, hogy az előkészítő fázisnak jellemzően nagyobb az idő, mint az erőforrás igénye. Az elkészítő fázisban viszonylag kevés ember s viszonylag csekély intenzitással foglalkozik a projekttel. Ezzel szemben az építési fázisnak jellemzően nagyobb az erőforrás és arányosan kisebb az időigénye, mivel az építés fázis viszonylag jól párhuzamosítható, a már jól definiált feladatokon párhuzamosan sok fejlesztő dolgozhat. 10% % % %

89 Biztonsági tesztelés a fejlesztés különböző életciklusaiban
A biztonsági tesztelések célja, hogy a fejlesztés különböző életciklusaiban felderíthető információbiztonsági hiányosságok azonosításra és mielőbbi javításra kerülhessenek. Az informatikai fejlesztések életciklusait alapvetően 6 jól elkülöníthető csoportra oszthatjuk:

90 Tervezési szakasz: a fejleszteni kívánt alkalmazás a különböző előzetes specifikációk alapján megtervezésre kerül, amivel párhuzamosan az információbiztonság szemszögéből a biztonsági intézkedések azonosítása és specifikációja is megtörténik. Ebben a fázisban a biztonsági tesztelés a dokumentációkban meghatározott folyamatok, követelmények információbiztonsági vonatkozású megfelelőségét hivatott biztosítani. Fejlesztési szakasz: az elfogadott tervek alapján az informatikai rendszer fejlesztése megtörténik. A fejlesztési folyamat mérföldköveinél a fejlesztés típusától függően érdemes lehet a biztonsági teszteléseket elvégezni az elkészült rendszerelem vonatkozásában, hogy a fejlesztés során a rendszerbe kódolt hibák a lehető legkorábbi fázisban azonosításra és javításra kerülhessenek. Tesztelési szakasz: az elkészült alkalmazás tesztelése, esetleges hibák felderítése, hibajavítások elvégzése, felkészülés az éles üzemre való átállásra. Ebben a szakaszban a teljes rendszer funkcionális tesztelése mellett a biztonsági tesztelések is végrehajtásra kerülnek, de még nem az éles környezetben.

91 Implementációs szakasz: az elkészült alkalmazás beüzemelése, valamit az üzembe állításhoz köthető biztonsági intézkedések (szervezési és technikai intézkedések) megvalósítása. A biztonsági teszteléseket fontos elvégezni az éles rendszeren is, mivel számos esetben az éles- és a tesztrendszer biztonsági szempontból releváns paraméterekben különbözhet. Fenntartási szakasz: a fejlesztés eredményeként előállt alkalmazás folyamatos üzemeltetése mellett szükséges az előre meghatározott biztonsági intézkedések, tesztesetek napi szintű alkalmazása, visszacsatolása, a rendszer ellenőrzése. A biztonsági tesztelések tehát ebben a fázisban annak teljes élettartama alatt ciklikusan elvégzésre kerülnek. Nyugdíjazás: a rendszer leállításra kerül, mely során az előzetes terveknek megfelelően gondoskodni kell a rendszerben tárolt adatok megsemmisítéséről, vagy éppen mentéséről, esetleg új rendszerbe való migráció esetén adatkonverzióról és/vagy adattisztításról. A biztonsági tesztelés képes lehet a nyugdíjazás során meghatározott folyamatok elvégzésének megfelelőségét ellenőrizni.

92 Életciklus megnevezése
Információbiztonság érvényesítésének költségvonzata Tervezési szakasz alapértelmezett, 1x költségigény Fejlesztési szakasz 6.5x költségvonzat Tesztelési szakasz 15x költségvonzat Fenntartási szakasz 100x költségvonzat

93 Szoftver biztonsági tesztelés
Szoftver biztonsági tesztelésén általában a szoftver forráskódjának célirányos átvizsgálását értjük, mely megelőző tevékenységként számos előnyt biztosít: csökkenti a szoftverfejlesztés és karbantartás költségeit segít a forráskód értelmezésében, karbantarthatóságában információval szolgál a termék minőségéről a jobb minőségű kód kevesebb tesztelést igényel felfedezhetőek, majd javíthatóak a biztonsági rések az éles indulás előtt

94 Szoftver biztonsági tesztelés
Adott funkciót megvalósító szoftver termék megrendelése esetén általában 2 lehetőség adódik: egyedi fejlesztés dobozos termék Egyedi fejlesztés esetén a biztonsági tesztek elvégzése vagy a fejlesztői oldalon történik meg a fejlesztő csapat mérnökeinek bevonásával, vagy független, kódaudit tesztelésre specializálódott szolgáltató bevonásával. Ezek eredményeiről a megrendelőnek is célszerű tudnia. Később, a termék átadását követően lehet kérni a fejlesztőtől független biztonsági bevizsgálást a termékre vonatkozóan, ezt nevezzük általában etikus hacking eljárásnak, mely során a sérülékenység vizsgálat befejezését követően, annak eredményeként előállt és a szerződésben meghatározott kockázati szintet elérő hiányosságokat a megrendelőnek javítania kell. Ezen felül elengedhetetlen a szerződésben a forráskód tulajdonjogának kérdését is rögzíteni. Dobozos termék esetén előfordulhat, hogy nem lesz lehetőség kódaudit elvégzésére, mivel a fejlesztő fenntarthatja a jogot a zárt forráskódra. Ebben az esetben is elvégezhető az audit black-box módszerrel, ahol a forráskód, illetve dokumentáció nem áll rendelkezésére a tesztelőknek.

95 A szoftveres környezetnek megfelelő bemeneti paraméter ellenőrzése
(input validation)  engedélyezett karakterek listája  adattípus ellenőrzés  formátum vagy kép ellenőrzés  fájl meglevőségének ellenőrzése  hash összesítő ellenőrzés  adatkorlát ellenőrzés  mennyiségi ellenőrzés  számossági ellenőrzés  tartomány ellenőrzés  ellenőrző szám vagy számsor használata  logikai hiba ellenőrzés  jelenlét ellenőrzés  konzisztencia ellenőrzés  összesítő ellenőrzés  keresztplatformos konzisztencia ellenőrzés  hivatkozás integritás  helyesírás ellenőrzés  egyediség ellenőrzés

96 További szükséges intézkedések
 webes könyvtár és fájl indexálhatóság tiltása  tartalomszűrő rendszer használata  hozzáférési azonosítók titkosított formában való tárolása  megfelelő autentikáció és autorizáció használata  megfelelő minőségű jelszavak kikényszerítése  nem hitelesített (anonim) bejelentkezések tiltása  kriptográfiai technikák alkalmazása  backup management kialakítása  beépített felhasználók tiltása, egyedi felhasználónevek alkalmazása  gyári beállítások módosítása  adminisztratív felületek elérhetőségének korlátozása  log management használata  ciklikus sérülékenység vizsgálatok végzése, eredményeinek felhasználása

97 Sérülékenység-vizsgálat
A megbízott feladata az informatikai rendszerek teljes körű technikai és adminisztratív informatikai biztonsági sérülékenység-vizsgálata az elfogadott munkaterv és a törvényi feltételek betartásával A vizsgálat eredményeként előálló dokumentációnak tartalmaznia kell a feltárt technikai, adminisztratív és folyamatkomponens fenyegetések ismertetését, a fenyegetések elleni kontrollok azonosítását és a fenyegetések ezen kontrollokkal való összevetését. Ismertetnie kell a feltárt résekre adandó tételes és részletes megoldási javaslatokat és a javasolt rendszerek minősítési javaslatát. A vizsgálat eredményeként szükséges előállni azon információknak, hogy a vizsgált rendszerek, adott időpillanatban, különböző irányokból és jogosultságokkal milyen mértékig kompromittálhatók. A sérülékenység-vizsgálatnak tartalmaznia kell jogosultság nélküli black-box fázist, felhasználói jogosultsággal végzett grey-box fázist, illetve adminisztrátori jogosultsággal végzett white-box fázist.

98 Amiről nem beszéltünk Code review, code audit Common Criteria
Rendszerbiztonsági terv 0.day probléma GDPR, NIS Forráskód védelem és futtató környezet BCP/DRP Mentés és logolás Jogi védelmek és felelősségek

99 Esettanulmányok

100 KÖSZÖNÖM A FIGYELMET! Bódi Antal
ITS tanúsítási irodavezető, PhD hallgató Óbudai Egyetem Biztonságtudományi Doktori Iskola KTI Közlekedéstudományi Intézet Nonprofit Kft. 1119 Budapest, Than Károly u. 3-5. Mobil: (+36-30)