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

Az 1. előadás tartalmából Ismétlés Az 1. előadás tartalmából Projekt A vezető feladatai A projekttervezési és vezetési folyamat Hierarchikus tevékenység/feladat lebontás Mérföldkövek és részeredmények Tevékenység – Időtartam – Függőségek - Erőforrások Ütemezés Kockázatkezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

A projekttervezési és vezetési folyamat 1. Ismétlés A projekttervezési és vezetési folyamat 1. Projektcél? A projekt megszorításai Szervezeti keretek, felelősök A projekt paramétereinek kezdeti összegzése A projekt részeredményeinek és mérföldköveinek definiálása A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet A kockázatelemzéshez kapcsolódik a mai előadás első témaköre a SWOT elemzés. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

A projekttervezési és vezetési folyamat 2. Ismétlés A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Az első pontban megjelenő ciklus az ún. projekt követési folyamat. Itt három fő tevékenység jelenik meg. Ezek az Információgyűjtés Elemzés Cselekvés A továbbiakban az első két tevékenység néhány fontosabb lépését/elemét fogjuk áttekinteni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 SWOT elemzés Belső tényezők Strengths erősségek Weaknesses gyengeségek Külső tényezők Opportunities lehetőségek Threats veszélyek A kockázat elemzés része lehet a SWOT elemzés is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

SWOT elemzés (vállalati példa)

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Erősségek Meghatározó a vállalat piaci szerepe? Jó a vásárlók véleménye? Fejlett technológiát használ a vállalat? Egyedülálló versenyelőnnyel rendelkezik? Jók a piaci erőforrásai? Gazdaságos üzemméretet használ? Jó a vállalat menedzsmentje? Kimagasló szakértelműek az alkalmazottak? Sikeres a vállalati stratégia? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Gyengeségek Elavult a technológia? Romlik a piaci pozíció? Nincs egyértelműen meghatározott stratégia? Hiányzik a megfelelő szakértelem? Elhasználódtak a létesítmények? Rossz a vállalat imázsa? Nem sikeres a kutatás-fejlesztési részleg? Rosszul funkcionál a menedzsment? A pénzügyi háttér nem rendezett? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Lehetőségek Gyorsabb piaci növekedés? Kiegészítő termékek fejlesztése? Új piacokra való belépés? Új technológia alkalmazása? A termékcsoport továbbfejlesztése? További célcsoportok feltérképezése? Egy nyersanyagforrás megszerzése? Beszállítás helyett saját előállítás? Új szervezeti felépítés kidolgozása? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Veszélyek Új versenytársak megjelenése a piacon. A piaci növekedés lassulása. Változó fogyasztói igények. Szigorodó szabályozás. Helyettesítő termékek megjelenése. Hátrányos demográfiai változások. Kedvezőtlen gazdasági ciklusok hatása. A beszállítók javuló alkupozíciója. Fogyasztói érdekvédelem fokozódó nyomása. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment

Kockázat tervezése és menedzselése Stratégiák Elkerülési stratégiák Minimalizációs stratégiák Vészhelyzeti tervek A kockázat tervezése fázisban az előző fázisban kiválasztott néhány kulcskockázat kezelési stratégiáját határozzuk meg. Elkerülési stratégiák Cél: csökkenteni a bekövetkezés valószínűségét. Minimalizációs stratégiák Cél: a hatás csökkentése. Vészhelyzeti tervek Mit kell tenni, ha már bekövetkezett a kockázat által jelölt probléma. Alkalmazható módszerek Brainstorming Kártyatechnikák Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kockázat tervezése Kockázat Stratégia Szervezeti pénzügyi problémák Elkészíteni egy részletes dokumentumot a felső vezetés részére, amely bemutatja, hogy a projekt mennyire fontos kapcsolatban áll az üzleti célokkal Toborzási problémák Riasztani a megrendelőt, hogy potenciális nehézségek és lehetséges késések várhatók, kutatni a megvásárolható komponensek után. Munkaerő megbetegedése Újraszervezni a csapatot úgy, hogy a munkák jobban átfedjék egymást, így az emberek jobban megértik mások munkáit is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 A kockázat figyelése Változott-e az azonosított kockázatok bekövetkezési valószínűsége hatása Minden vezetőségi felülvizsgálaton minden kulcskockázatot meg kell vizsgálni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Információgyűjtés Kitöltött űrlapok jelentések, jegyzőkönyvek, programok kimenetei, értekezleteken elhangzott információk Óraelszámolások Állapotjelentések Óraelszámolások Az élőmunka-ráfordítás költségszámításának alapját képezik. Vállalati szabályozástól függ lebontása: havi, heti, napi. Nagyobb pontosság=jobb kép a költségekről, DE nagyobb adminisztrációs teher a dolgozónak. Állapotjelentés A projektvezető tájékoztatja a projektet felügyelő vezető(ke)t az előrehaladásról. Ajánlott a heti gyakoriság. Tartalmaz összesítéseket, vizualizációs eszközöket (főként diagramok). Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Elemzés - alapfogalmak ACWP – Actual Cost Of Work Performed – az elvégzett munka tényleges költsége BCWP – Budget Cost Of Work Performed – az elvégzett munkára ennyi költséget terveztünk BCWS – Budget Cost Of Work Scheduled – a tervezett (ütemezett) munkára ennyi költséget terveztünk Az ideális eset az lenne, ha egyetlen számmal teljes körűen jellemezhető lenne a projekt állapota. A valóságban több mérőszám is számítható, amik különböző jellemzőket mutatnak. Igaz ezekből előállítható kombinált értékelési mutató, de az elfedi azt, hogy hol a gond és néha magát a probléma meglétét is. A továbbiakban az "Megtermelt érték számítási módszere"nevű megközelítést mutatjuk be. Eszerint a projekt egy adott időpillanatában az itt (ezen a dián) megnevezett három költségtípust számítjuk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Elemzés – származtatott fogalmak CV – Cost Variance – költségeltérés CV=BCWP-ACWP SV – Schedule Variance – ütemezéstől való eltérés SV=BCWP-BCWS CPI – Cost Performance Index – költséghatékonysági mutató CPI=BCWP/ACWP SPI – Schedule Performance Index – ütemterv teljesülési mutató SPI=BCWP/BCWS CR – Critical Ratio – kritikus arány CR=SPI*CPI A három alapfogalomból (költségtípusból) kétfajta eltérési mennyiséget és kétfajta mutatót állíthatunk elő. A CPI az elvégzett munka (Work Performed) tervezett (Budget Cost) és tényleges (Actual Cost) költségének arányát mutatja. Ha értéke kisebb mint 1, akkor a tervezettnél nagyobb költséggel hajtotta végre eddig a csapat a feladatokat. Az SPI a tervben szereplő költségeket (Budget Cost) használva értékelő számként a ténylegesen elvégzett munkamennyiséget (Work Performed) a tervezetthez (ütemezetthez) (Work Scheduled) hasonlítja. Ha értéke kisebb mint 1, akkor a tervezettnél kevesebb munkát végzett eddig el a csapat. Ezt a mutatót a tervezett és a valójában megtermelt érték arányának is nevezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Diagram Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Felügyelet Beavatkozási határokat meghatározni Pl. 0,9…1,1 - OK 0,8…0,9 vagy 1,1…1,2 - tendenciafigyelés 0,8 alatt vagy 1,2 felett - cselekvés Az SPI és CPI értékét folyamatosan figyelni Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Minta BCWS BCWP ACWP CV SV CPI SPI Értelmezés 100 1 Időben és költségen 125 25 1,25 Időelőny és költségen -25 0,8 Késés és költségen Időben és túlköltekezés 150 0,83 Időelőny és túlköltés Késés és túlköltés Időben és megtakarítás Időelőny és megtakarítás Késés és megtakarítás Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Projekt lezárása A projekt akkor fejeződik be, ha teljesül a projektcél (elfogadták a projekt eredményét) Projektzáró dokumentum Projektadatok (…, tervezett és tényleges befejezési idő, bevétel, tervezett és tényleges költségek, emberóra ráfordítás) Lezárást követő teendők Vevői elégedettség Projekt általános értékelése Projektzáró értekezlet – értékelik a projekt lefutását A termék átadását követő garanciális időszak, karbantartás, követés, ügyfélszolgálati tevékenység már nem része a projektnek. A projektzáró dokumentum segít abban, hogy a későbbi projektjeinket jobban tervezhessük. A projekt értékelés hosszú távon is hat a végre, a vállalati kultúrára. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 A projekt utóélete Szoftverrendszerrel kapcsolatos költségek 1/3-a fejlesztés és 2/3-a működtetés Projektzárást követő tevékenységek Üzemeltetés Garanciális javítások Későbbi karbantartás Támogatás (tanácsadás) Követés (változó jogi, hardver és szoftver környezet) Továbbfejlesztés A projektzárást követő tevékenységek nem projekt jellegűek, hanem folyamatosak. Egy munkafolyamat leírás vezérli őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Bejelentések fogadása Service Level Agreement (SLA) rögzíti Bejelentések súlyosság és prioritás szerinti kategorizálása Vállalt reakcióidők Informatikai infrastrukturális szolgáltatások módszertana (ITILv3) - Information Technology Infrastructure Library (ISO/IEC 20000) Informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Bejelentéskezelés Fontos a bejelentések és kezelésük pontos dokumentálása és a folyamat követése. Ezt a munkafolyamatot egy vagy állapotgép diagrammal vagy állapotátmenet mátrixxal lehet leírni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szoftver életciklus modellek Szoftvertechnológia Szoftver életciklus modellek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Mi a szoftver? A számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége Két fő csoport Általános termékek és Rendelésre készített Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftver a számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége. A szoftvertermékeknek két fő csoportja van: általános termékek és rendelésre készített (egyedi igényeknek megfelelő) termékek. Az általános termékeket nevezik dobozos szoftvereknek is. Ezeket egy fejlesztő szervezet készíti és adja el a piacon bármely vevőnek. Itt a vevők közvetlenül nem befolyásolhatják a termék jellemzőit, a szoftverspecifikációt a gyártó cég tartja kézben. Ilyenek a játékok, az operációs rendszerek, az adatbázis-kezelők, a szövegszerkesztők, a különböző rajz- és tervezőprogramok, fordítóprogramok és a projektmenedzselési eszközök. A rendelésre készített termékek esetében a megrendelő igényei szerint kell a terméket kifejleszteni. Itt a megrendelő adja meg a specifikációt (vagy legalábbis annak a vázlatát) és az elkészült szoftverterméket ez alapján ellenőrzi. Ilyenek lehetnek: könyvelőprogramok, egyéni üzleti folyamatokat támogató rendszerek, forgalomirányító (pl. légi, vasúti), elektromos eszközök vezérlőrendszerei vagy ellenőrző rendszerek. A kétfajta termékcsoport közötti választóvonal egyre inkább elmosódik, mivel egyre több szoftvercég fejleszt általános termékeket, amiket azután a vásárlók igénye szerint testre szab. A vállalatirányítási rendszerek (ERP – Enterprise Resource Planning), mint pl. az SAP jó példa erre. Ezeket tekinthetjük egy harmadik csoportnak is, amely részben az általános termékek, részben a rendelésre készítettek tulajdonságaival rendelkezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Igény a rendszerezett munkára Kezdetben kis programok Hardverfejlődés → bonyolultabb feladatok Folyamatábra, metanyelvű algoritmus leírás, stb. Szoftvertechnológia Az első számítógép programok viszonylag egyszerűek és a hardverkorlátokból adódóan kis méretűek voltak, így gyakran egyetlen programozó is át tudta látni a feladatot, és meg tudta írni a programot. Mindenki tudna mondani programozási tanulmányaiból/gyakorlatából olyan egyszerű feladatot, amit bárki, aki megfelelő programozási ismeretekkel rendelkezik, különösebb előzetes tervezés vagy „vázlat készítés” nélkül azonnali kódolással meg tudna oldani. Például ilyen két szám átlagának a kiszámítása. A hardver robbanásszerű fejlődésével egyre nagyobb lélegzetű, komplexebb problémák váltak a számítógép által megoldhatóvá. A bonyolultabb feladatok előkészítést, rendszerzett munkát kívántak meg. Egyszerűbb esetekben elegendő volt egy folyamatábra vagy más ezzel egyenértékű eljárás segítségével felvázolni a megoldás algoritmusát, majd ezt követhette a kódolás valamilyen programozási nyelven. A mai valós feladatok azonban a legtöbb esetben olyan nagy méretűek, hogy programozó csoportok dolgoznak a megoldásukon, és az eredmény nem ritkán egy sok százezer utasításból álló szoftver monstrum. Egy ilyen termék előállítása, karbantartása és a folyamatosan változó környezeti feltételekhez, vevői elvárásokhoz igazítása elképzelhetetlen precíz és jól előkészített, szervezett, összehangolt, ellenőrzött és dokumentált munka nélkül. Az erre a célra alkalmazott módszerek és eljárások összességét szoftvertechnológiának nevezzük. A szoftvertechnológia fontos célja a költséghatékony fejlesztés. Nézzünk meg két definíciót erre a fogalomra. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Boehm - 1976 A szoftvertechnológia tudományos ismeretek gyakorlati alkalmazása számítógépes programok előállításához, a fejlesztéshez, a használathoz és karbantartáshoz szükséges dokumentációk tervezésében és előállításában. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 IEEE - 1983 A szoftvertechnológia olyan technológiai és vezetési alapelvek összessége, amelyek lehetővé teszik a programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás A szoftverfolyamat Bár a szoftver sokban különbözik más hagyományos, kézzel fogható terméktől, és az elmúlt években sokféle modell és ajánlás született arra, hogy hogyan is állítsuk elő, azonban szinte minden ilyen modellben visszaköszönnek olyan lépések és tevékenységek, amelyekkel más területek és iparágak mérnöki tervezési és előállítási folyamataiban is találkozhatunk. Ezek a következőek. 1. Követelményelemzés A vevői /megrendelői elvárások összegyűjtése, elemzése (Mit is kellene csinálni? Mikorra, és mennyiért?), a rendszer környezetének felmérése, feladat leírása. Információgyűjtés az adott területen dolgozó szakemberektől (pl. interjúk). Az adott terület üzleti folyamatainak beazonosítása. Ezt követi a feladat lefordítása a szakmai nyelven megfogalmazott specifikációkra, ami magában foglalja a megvalósíthatóság vizsgálatát is. Dokumentálás: szakterületi fogalomtár, üzleti folyamatok strukturált leírása táblázatos formában és használati eset diagramok segítségével, tevékenység diagramok, állapot automata. 2. Tervezés Az elemzés és a tervezés szorosan összekapcsolódó feladatok. A megoldás vázlatának, tervének elkészítése egy magasabb absztrakciós szinten. Ide tartozik az architekturális tervezés, absztrakt specifikáció, interfész tervezés. Dokumentálás: összetevő diagram, rendszer-montázs diagram. Az architektúra a tervezés során többször módosul, finomodik. Fontosabb osztályok megtervezése – oszálydiagram, objektum diagramok. 3. Implementálás (megvalósítás) A technológiai részletek kidolgozása, a tényleges kód előállítása. Ide tartozik a komponens tervezés, adatszerkezet tervezés és algoritmus tervezés. Felhasználói interakció megtervezése, felülettervek. Ide tartozik még az integrálás (modulok összekapcsolása). Dokumentáció: objektum diagramok, rendszer montázsdiagramok. 4. Kipróbálás, validálás, bevezetés Tesztelés és telepítés. Kipróbálás valós környezetben. Két módszer: szoftverátvizsgálás és tesztelés. Ide tartozik még a felhasználói dokumentáció elkészítése. Kihelyezési diagram. 5. Működtetés, karbantartás, továbbfejlesztés, leállítás A felismert hibák javítása, esetleg új igényeket kielégítő új funkciók megvalósítása – folyamatos fejlesztés (igény esetén). Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szoftverfolyamat modellek Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V RUP (Rational Unified Process) ISO/IEC 12207 (1995, 2008) A rendszerezett/módszeres szoftverfejlesztés iránti igény olyan technikák (modellek) megjelenését eredményezte, amelyek eligazítást adnak, meghatározzák, hogy milyen lépéssorozattal (hogyan) célszerű előállítani úgy a szoftvert, hogy az lehetőleg minden érintett fél elégedettségét eredményezze. Hasonlóan más technológiákhoz itt is megfigyelhető a fejlődés, továbbá itt sem mondhatjuk el egyetlen megközelítésről sem, hogy ő az egyedüli üdvözítő megoldás. Az előnyöket és hátrányokat mérlegelve a lehetőségek/körülmények ismeretében választhatjuk egyiket vagy másikat optimális megoldásként. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Vízesés modell A vízesés modellt széles körben használták a gyakorlatban. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek/

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Vízesés modell A következő fázis addig nem indulhat el, amíg az előző be nem fejeződött. Ez a modell akkor működik jól, ha a követelmények teljesen ismertek. Előny: Jól menedzselhető és ellenőrizhető. Minden fázisban jól definiált feladatok. Minden fázis jól dokumentálható. Előre jól definiálható követelmények esetén jól alkalmazható. Hátrány: Nagyon sok probléma csak az utolsó fázisban derül ki, így a javítás nagyon költséges. Korán kell jelentős döntéseket hozni, ez hibás döntésekhez vezethet. Nehéz a rendszert a fejlesztés közben változó követelményekhez igazítani. Sok dokumentációs munkát igényel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Spirál modell megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. Forrás: Szabolcsi Judit: Szoftvertechnológia A szoftverfolyamatot spirálként kezeli. Minden egyes körben a spirál a szoftverfolyamat egy-egy fázisát reprezentálja. A legbelső kör a megvalósíthatósággal foglalkozik, a következő a rendszer követelményeinek meghatározásával, aztán a rendszer tervezéssel, stb. A spirál minden egyes ciklusát négy szektorra osztjuk fel: célok, alternatívák meghatározása; kockázat becslése és csökkentése; a fázis termékének megvalósítása és validálása; következő fázis tervezése. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Spirál Modell Prototípus 3 Elemzés Igények és Célok Prototípus 2 Megvalósítás Tervezés

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Spirál modell megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. Ábra forrása: http://sloanreview.mit.edu/the-magazine/articles/2008/spring/49315-3/the-spiral-model-of-software-development/ Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Spirál modell Előny: a kockázati tényezőkkel explicite számol. A spirális modellben nincsenek rögzített fázisok, és felölelhet más folyamatmodelleket is (vízesés, evolúciós, stb.). Hátrányai: a modell alkalmazása bonyolult, munkaigényes feladat; a párhuzamos foglalkoztatás csak a 3. szektorban lehetséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 V modell Egy módosított vízesés modell. Megkülönbözteti a fejlesztésen belül a konstrukciós és a tesztelési fázisokat. Definiálja a tesztelés szintjeit. Szemlélteti, hogy a tesztelési munka végigköveti a teljes fejlesztési folyamatot. Összefüggést tételez fel az egyes konstrukciós fázisok és az egyes tesztelési szintek között. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Inkrementális (evolúciós) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek/

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Evolúciós modell Ki kell fejleszteni egy kezdeti implementációt (prototípust), azt a felhasználókkal véleményeztetni, majd sok-sok verzión át addig finomítani, amíg megfelelő nem lesz. Iterációs modellnek is nevezik. Objektum orientált fejlesztésben gyakran használják. Ez a modell a felhasználó kívánságait jobban kielégítő programot eredményez. A kis (<100.000 programsor) és közepes (<=500.000 programsor) rendszerek fejlesztéséhez ideális. Hátrányai: a folyamat nem látható; a rendszerek gyakran szegényesen strukturáltak; a gyors fejlesztés rendszerint a dokumentáltság rovására megy. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Újrafelhasználás orientált fejlesztés (komponens alapú) Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Fejlesztés és integráció Forrás: Szabolcsi Judit: Szoftvertechnológia Ez a módszer nagymértékben az elérhető újrafelhasználható szoftverkomponensekre támaszkodik. A komponensek lehetnek teljes rendszerek, pl. egy szövegszerkesztő, vagy kisebb egységek (osztályok, modulok, stb.) A fejlesztés szakaszai: Komponenselemzés: Adott a követelményspecifikáció, ami alapján megkeressük, hogy milyen kész komponensek valósítják meg. A legtöbb esetben nincs egzakt illeszkedés, és a kiválasztott komponens a funkcióknak csak egy részét nyújtja. Követelménymódosítás: A követelmények elemzése a megtalált komponensek alapján. A követelményeket módosítani kell az elérhető komponenseknek megfelelően. Ahol ez lehetetlen, ott újra a komponenselemzési tevékenységet kell elővenni, és más megoldást keresni. Rendszertervezés újrafelhasználással: A rendszer szerkezetét kell megtervezni, vagy egy már meglévő vázat felhasználni. A tervezőknek figyelembe kell venniük, hogy milyen újrafelhasznált komponensek lesznek, és úgy kell megtervezni a szerkezetet, hogy ezek működhessenek. Ha nincs megfelelő újrafelhasználható komponens, akkor új szoftverrészek is kifejleszthetők. Fejlesztés és integráció: A nem megvásárolható komponenseket ki kell fejleszteni és a COTS (Commercial-Off-The-Shelf – kereskedelemben kapható)-rendszerekkel össze kell kapcsolni. A rendszerintegráció itt sokkal inkább tekinthető a fejlesztési folyamat részének, mint különálló tevékenységnek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Komponens alapú modell Előnye: lecsökkenti a kifejlesztendő részek számát, így csökkenti a költségeket és a kockázatot. Ez általában a kész rendszer gyorsabb leszállításához vezet. Hátrányai: a követelményeknél hozott kompromisszumok elkerülhetetlenek, és ez olyan rendszerhez vezethet, ami nem felel meg a felhasználó valódi kívánságának. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 RUP Munkafolyamatok Munka- folyamatok Követelmények Tervezés Implementáció Teszt Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 RUP - dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 CASE eszközök Computer-Aided Software Engineering Követelményspecifikáció: grafikus rendszermodellek, üzleti és domain Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfész-leírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP);verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Forrás: Szabolcsi Judit: Szoftvertechnológia A számítógéppel támogatott szoftvertervezéshez (Computer-Aided Software Engineering - CASE) használt szoftvereket nevezzük CASE-eszközöknek. A szoftverfolyamatban a következő tevékenységeket támogatják a CASE eszközök: Követelményspecifikáció során: grafikus rendszermodellek, üzleti és domain (a modellezni kívánt terület) modellek megtervezése. Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfészleírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP); verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. Mindegyik fázisban alkalmazható: automatikus dokumentumgenerálás; projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) A CASE-eszközök korai pártolói azt jósolták, hogy a szoftverek minőségében és a termelékenységben nagyságrendi javulást okoznak ezek az eszközök, de valójában csak 40% körüli a javulás. Az eredményességet két tényező korlátozza: A szoftvertervezés lényegében tervezői tevékenység, amely kreatív gondolkodást igényel. A létező CASE-eszközök automatizálják a rutintevékenységeket és hasznosítják a mesterséges intelligencia bizonyos technológiáit, de ez utóbbival még nem értek el átütő eredményt. A legtöbb szervezetben a szoftvertervezés csoportos tevékenység, és a benne résztvevők rengeteg időt töltenek a csapat más tagjaival való eszmecserével. A CASE-technológia ehhez nem nyújt túl nagy segítséget. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 CASE eszközök Automatikus dokumentumgenerálás; Projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 UML Unified Modeling Language Egységes modellező nyelv 2.4.1 (2.1.2 ISO/IEC 19505 ) http://www.uml.org Object Management Group Eric J. Naiburg, Robert A. Maksimchuk: UML földi halandóknak. Kiskapu Kiadó, Budapest, 2006. A továbbiakban röviden áttekintjük a diagram típusokat. A részletes ismertetésre a szoftverfejlesztési folyamat főbb lépései szerinti csoportosításban kerül sor a későbbiekben. Néhány diagramtípus több lépésben is felhasználásra, finomításra kerül, ezek általában az első olyan lépésnél lesznek bemutatva, ahol hasznosítjuk őket. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 UML Dokumentálható A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Grafikus elemek Nem programozási nyelv Nem módszertan „Csak” segédeszköz Az UML egy eszköztár, amelynek segítségével ember és számítógép által jól érthető/kezelhető/feldolgozható módon dokumentálhatóak a A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Az UML grafikus elemei a szoftver fejlesztés minden fázisában jól alkalmazhatóak. Számos szoftver nyújt támogatást az UML használatához. Létezik pl. osztálydiagramból kódot generáló és kódból osztálydiagramot generáló implementáció. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Mire jó az UML? 1. szemléltetésre a fejlesztői csoporton belül, illetve a fejlesztők, tesztelők, menedzserek és a megrendelők közötti kommunikációra specifikálásra megvalósításra dokumentálásra Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

Sikeres szoftverfejlesztési folyamat Jelölésrendszer (notation) – ez lehet az UML Folyamat (process) – pl. RUP (Rational Unified Process) Eszköz (tool) – pl. Enterprise Architect, Rational Rose, Visual Studio 2010 osztálydiagram készítő része, stb. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

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

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

A metamodell architektúra Meta-metamodell EBNF (Extended Backus-Naur Form) MOF M2 metamodell A C# nyelv nyelvtana UML M1 modell Egy C# program Számkitaláló M0 rendszer Egy konkrét C# program végrehajtása A program futásának egy állapota EBNF egy metanyelv, környezetfüggetlen nyelvtan, programozási nyelvek és más formális nyelvek leírására szolgál Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Az UML szabvány részei 2. Superstructure (a felhasználó milyen diagramokat, azon belül milyen elemeket és kapcsolatokat használhat; mi főleg ezt tanuljuk) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Az UML szabvány részei 3. UML Diagram Interchange (UMLDI) – lehetővé teszi a különböző UML szerkesztő szoftverek közötti dokumentumcserét UML Human-Usable Textual Notation – egyes UML diagramokból ember által is olvasható szöveget generál MOF 2 XMI Mapping – MOF = Meta Object Facility XMI = XML Metadata Interchange – XML adatok és objektumok cseréje, manipulálása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Modell - diagram A kettő nem ugyanaz! „A modellek (tehát) több diagramból állnak, a diagramok pedig az elemek és azok más elemekkel való kölcsönhatásának ábrázolásai.” (Forrás: UML földi halandóknak könyv) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés d. (timing) Kontextus diagram Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Kontextus d. , Szakarchitektúra d. Összetett szerkezet diagram (composite stucture) Kihelyezési/telepítési/kihelyezési diagram (deployment) Viselkedési diagramok: Tevékenység diagram (activity) Használati eset vagy feladat diagram (use-case) Állapotautomata vagy állapotgép diagram (state machine) Kölcsönhatási diagramok: Sorrend diagram (sequence) Kommunikációs diagram (communication) Időzítés diagram (timing) Kölcsönhatás áttekintő diagram (interaction overview) Az UML vizuális megjelenítést, ún. diagramokat használ a modell elemek leírására. Ezek két fő csoportba sorolhatók. Forrás: Szabolcsi Judit: Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Szerkezeti és viselkedési A szerkezeti diagramok (statikus) nem törődnek az időbeli változással, ők a modellezett rendszer állapotát egy adott időpillanatban mutatják be. Viselkedési diagramok (dinamikus) folyamatában, változásában mutatják ugyanazt a modellezett rendszert. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Szerkezeti diagramok1 Osztálydiagram: az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Objektumdiagram: a rendszer egy adott időpontban érvényes pillanatképét határozza meg. Az osztálydiagramból származtatjuk. Csomagdiagram: a csomagok olyan modellelemek, amelyek más modellelemek csoportosítására szolgálnak, és ezeket valamint a köztük lévő kapcsolatokat ábrázolja ez a fajta diagram. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Szerkezeti diagramok2 Összetevő diagram: az összetevő vagy komponens a rendszer fizikailag létező és lecserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Főleg implementációs kérdések eldöntését segíti. A megvalósításnak és a rendszeren belüli elemek együttműködésének megfelelően mutatja be a rendszert. Összetett szerkezeti diagram: A modellelemek belső szerkezetét mutatja. Kialakítás/kihelyezés/telepítési diagram: A fizikai (kész) rendszer futásidejű felépítését mutatja. Tartalmazza a hardver és a szoftverelemeket is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Viselkedési diagramok Tevékenységdiagram: A rendszeren belüli tevékenységek folyamatát jeleníti meg. Általában üzleti folyamatok leírására használjuk. Használati eset/feladat diagram: A rendszer viselkedését írja le, úgy, ahogy az egy külső szemlélő szemszögéből látszik. Állapotautomata diagram: Az objektumok állapotát és az állapotok közötti átmeneteket mutatja, valamint azt, hogy az átmenetek milyen esemény hatására következnek be. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014

Kölcsönhatási diagramok Kommunikációs diagram: Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. Sorrenddiagram: Az objektumok közötti üzenetváltás időbeli sorrendjét mutatja. Időzítés diagram: A kölcsönhatásban álló elemek részletes időinformációit és állapotváltozásait vagy állapotinformációit írja le. Kölcsönhatás áttekintő diagram: Magas szintű diagram, amely a kölcsönhatás-sorozatok közötti vezérlési folyamatról ad áttekintést. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014