Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

A szoftverfejlesztési módszertan A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le A fejlesztési modellek a fejlesztési.

Hasonló előadás


Az előadások a következő témára: "A szoftverfejlesztési módszertan A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le A fejlesztési modellek a fejlesztési."— Előadás másolata:

1 A szoftverfejlesztési módszertan A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le 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 Útmutatást ad a csoportmunka irányítására Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát 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 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 Ritkán jelennek meg tiszta, ideális formában A fejlesztési folyamat egyfajta logikai absztrakciója. A fejlesztési folyamat egyfajta logikai absztrakciója.

2 Szoftverfejlesztési modellek (életciklus modellek) „Do Until Done” modell „Do Until Done” modell Vízesés modell Vízesés modell V-Modell V-Modell Evolúciós modell Evolúciós modell Iteratív fejlesztések Iteratív fejlesztések Spirál modell Spirál modell Inkrementális fejlesztés (UP, RUP) 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 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.

3 A vízesés modell A modell eredeti fázisai (Royce, 1970)

4 A fejlesztés fázisai szekvenciálisan követik egymást A fejlesztés fázisai szekvenciálisan követik egymást Ironikus módon Royce mint vitatott modellt említi a tanulmányában, hiszen nincs visszacsatolás, iteráció. Ironikus módon Royce mint vitatott modellt említi a tanulmányában, hiszen nincs visszacsatolás, iteráció. „This process is represented by the "Waterfall" Model, which serves as the conceptual guideline for almost all Air Force and NASA software development.” (www1.jsc.nasa.gov) „This process is represented by the "Waterfall" Model, which serves as the conceptual guideline for almost all Air Force and NASA software development.” (www1.jsc.nasa.gov) Módosítás: visszacsatolás az előző fázisokra Módosítás: visszacsatolás az előző fázisokra

5 A fázisokról röviden Requirements (követelmények): A felhasználó igényeinek analizálása, a szoftverrel szemben támasztott követel- mények összegyűjtése (Requirements Specification Document) Requirements (követelmények): A felhasználó igényeinek analizálása, a szoftverrel szemben támasztott követel- mények összegyűjtése (Requirements Specification Document) Design (tervezés): Design (tervezés): System Design: hardver, szoftver környezet, architektúra (blokkok, interfészek) (System Architecture Document) System Design: hardver, szoftver környezet, architektúra (blokkok, interfészek) (System Architecture Document) Software Design: a rendszerarchitektúra fő szoftver blokkjainak továbbbontása modulokra (Software Design Document) Software Design: a rendszerarchitektúra fő szoftver blokkjainak továbbbontása modulokra (Software Design Document) Implementation (implementáció, kódolás): A rendszer egységeinek kódolása Implementation (implementáció, kódolás): A rendszer egységeinek kódolása Software Integration & Verification: modulok egyesítése, tesztelése Software Integration & Verification: modulok egyesítése, tesztelése Maintenance (karbantartás): átadás a felhasználónak, esetleges módosítások Maintenance (karbantartás): átadás a felhasználónak, esetleges módosítások

6 A vízesés-modell előnyei Nemcsak a szoftverfejlesztésnél használható, hanem egyéb végfelhasználói projekteknél is. Nemcsak a szoftverfejlesztésnél használható, hanem egyéb végfelhasználói projekteknél is. A jól érthető és kevésbé komplex projektek esetén szabályozottan rögzíti a komplexitást, és jól megbirkózik azzal. A jól érthető és kevésbé komplex projektek esetén szabályozottan rögzíti a komplexitást, és jól megbirkózik azzal. Könnyű megérteni. Könnyű megérteni. Egyfázisú fejlesztéseknél egyszerű a használata. Egyfázisú fejlesztéseknél egyszerű a használata. Strukturáltságot biztosít még a kevésbé képzett fejlesztők számára is. Strukturáltságot biztosít még a kevésbé képzett fejlesztők számára is. Biztosítja a követelmények rögzítését, és azok nem is változnak a fejlesztés során. Biztosítja a követelmények rögzítését, és azok nem is változnak a fejlesztés során. Meghatározott sablont biztosít arra vonatkozóan, hogy mely módszereket használjuk az analízis, tervezés, kódolás, tesztelés és üzemeltetés során. Meghatározott sablont biztosít arra vonatkozóan, hogy mely módszereket használjuk az analízis, tervezés, kódolás, tesztelés és üzemeltetés során. Feszes ellenőrzést biztosít. Feszes ellenőrzést biztosít. Ha jól alkalmazzuk, a hibák már valamely korai fázisban kiderülnek, amikor javításuk még lehetséges, és kevésbé költségigényes. Ha jól alkalmazzuk, a hibák már valamely korai fázisban kiderülnek, amikor javításuk még lehetséges, és kevésbé költségigényes. A projekt menedzser számára könnyű a tervezés és a szereplők kiválasztása. A projekt menedzser számára könnyű a tervezés és a szereplők kiválasztása. Ha valaki készen van az adott fázisban rá kiosztott munkával, másik projekten dolgozhat, míg a többiek is elérik a fázis lezárásához szükséges állapotot. Ha valaki készen van az adott fázisban rá kiosztott munkával, másik projekten dolgozhat, míg a többiek is elérik a fázis lezárásához szükséges állapotot. A mérföldkövei könnyen érthetőek. A mérföldkövei könnyen érthetőek. Könnyű ellenőrizni a projekt aktuális állapotát. Könnyű ellenőrizni a projekt aktuális állapotát.

7 A vízesés-modell hátrányai Lineáris, így nehéz a visszalépés a felmerül problémák megoldására, és ez jelentősen megnöveli a javítás mind költség-, mind időigényét. Lineáris, így nehéz a visszalépés a felmerül problémák megoldására, és ez jelentősen megnöveli a javítás mind költség-, mind időigényét. Nem kezeli a szoftverfejlesztésben elterjedt iterációkat. Nem kezeli a szoftverfejlesztésben elterjedt iterációkat. Nincs összhangban a szoftverfejlesztés problémamegoldó természetével. Nincs összhangban a szoftverfejlesztés problémamegoldó természetével. Az integráció a teljes folyamat végén, egyben, robbanásszeren történik. A korábban fel nem fedezett hibák ilyenkor hirtelen, együttesen jelennek meg, így felderítésük és javításuk egyaránt nehezebb feladat. Az integráció a teljes folyamat végén, egyben, robbanásszeren történik. A korábban fel nem fedezett hibák ilyenkor hirtelen, együttesen jelennek meg, így felderítésük és javításuk egyaránt nehezebb feladat. A megrendelő csak a folyamat végén láthatja a rendszert, menet közben nincs lehetősége véleményezni azt. A megrendelő csak a folyamat végén láthatja a rendszert, menet közben nincs lehetősége véleményezni azt. A minőség szintén csak a folyamat utolsó fázisában mérhető. A minőség szintén csak a folyamat utolsó fázisában mérhető. Minden egyes fázis az előző fázis teljes befejezésére épít, ezzel jelentősen megnő a kockázat. Minden egyes fázis az előző fázis teljes befejezésére épít, ezzel jelentősen megnő a kockázat. A fejlesztés során a követelmények nem módosíthatók, hiszen már az életciklus elején befagyasztjuk őket. A fejlesztés során a követelmények nem módosíthatók, hiszen már az életciklus elején befagyasztjuk őket. Már a fejlesztés kezdetén ismernünk kell valamennyi követelményt, azok későbbi módosítására vagy bővítésére nincs lehetőség. Már a fejlesztés kezdetén ismernünk kell valamennyi követelményt, azok későbbi módosítására vagy bővítésére nincs lehetőség. Elképzelhető, hogy bár a végtermék megfelel valamennyi specifikációnak, mégsem működik (pl. mert az elvárásokban vannak ellentmondások). Elképzelhető, hogy bár a végtermék megfelel valamennyi specifikációnak, mégsem működik (pl. mert az elvárásokban vannak ellentmondások). Dokumentum-vezérelt, és túlzott dokumentálási követelményeket állít fel. Dokumentum-vezérelt, és túlzott dokumentálási követelményeket állít fel. Az egész szoftvertermék egy időben készül, nincs lehetőség kisebb részekre osztására. Az egész szoftvertermék egy időben készül, nincs lehetőség kisebb részekre osztására.

8 V-modell Ezt a változatát a vízesésmodellnek a német védelmi minisztérium fejlesztette ki, és tette a német hadsereg szoftver- fejlesztési modell szabványává 1992-ben. Ezt a változatát a vízesésmodellnek a német védelmi minisztérium fejlesztette ki, és tette a német hadsereg szoftver- fejlesztési modell szabványává 1992-ben. Minden tervezési fázisok van egy párja a tesztelési fázisok között Minden tervezési fázisok van egy párja a tesztelési fázisok között A tesztelés hangsúlyozása A tesztelés hangsúlyozása

9

10

11 Evolúciós szoftverfejlesztés Feltáró fejlesztésFeltáró fejlesztés Eldobható prototípus készítéseEldobható prototípus készítése

12 Spirál modell – iteratív fejlesztés

13

14 A spirál modell iterációkból áll, melyek folyamatosan ismétlődnek a projekt során. A spirál modell iterációkból áll, melyek folyamatosan ismétlődnek a projekt során. Valamennyi iteráció ugyanazon lépésekből áll Valamennyi iteráció ugyanazon lépésekből áll Lehetővé teszi a kockázatok korai felismerését Lehetővé teszi a kockázatok korai felismerését A megrendelőt minden fázisba aktívan bevonja A megrendelőt minden fázisba aktívan bevonja A modell elég komplex, megértése nem egyszerű A modell elég komplex, megértése nem egyszerű Jelentős kockázatkezelési szakértelem szükséges. Jelentős kockázatkezelési szakértelem szükséges. A nagyszámú köztes iteráció miatt sok, végül felesleges dokumentáció születhet. A nagyszámú köztes iteráció miatt sok, végül felesleges dokumentáció születhet.

15 Iteratív-inkrementális fejlesztési modell

16 The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Learning comes from both the development and use of the system, where possible. Key steps in the process were Key steps in the process were to start with a simple implementation of a subset of the software requirements to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. At each iteration, design modifications are made and new functional capabilities are added.

17

18 A kész szoftvert az egymást követő iterációk során állítja elő A kész szoftvert az egymást követő iterációk során állítja elő Az egyes iterációk végén a követelmények egyre nagyobb részhalmazát kielégítő rendszer áll elő. Az egyes iterációk végén a követelmények egyre nagyobb részhalmazát kielégítő rendszer áll elő. Az iterációk során a rendszer szélességében bővül és nem bonyolódik. Az iterációk során a rendszer szélességében bővül és nem bonyolódik. Kiválasztjuk a kritikus funkciókat és azt valósítjuk meg legelőbb, majd szélességében bővítjük a rendszert. Kiválasztjuk a kritikus funkciókat és azt valósítjuk meg legelőbb, majd szélességében bővítjük a rendszert. Minden egyes iteráció egy-egy kis vízesés (vagy evolúciós) fejlesztés. Minden egyes iteráció egy-egy kis vízesés (vagy evolúciós) fejlesztés. A jól definiált követelményeket kielégítő inkremensek fejleszthetőek a vízesés modell alapján A jól definiált követelményeket kielégítő inkremensek fejleszthetőek a vízesés modell alapján Ahol a specifikáció nem kellően egyértelmű, ott alkalmazható az evolúciós megközelítés. Ahol a specifikáció nem kellően egyértelmű, ott alkalmazható az evolúciós megközelítés.

19 A fejlesztés indításakor a megrendelő vázlatosan közli a követelményeit, illetve meghatározzák mely követelmények a fontosabbak, s melyek kevésbé fontosak. A fejlesztés indításakor a megrendelő vázlatosan közli a követelményeit, illetve meghatározzák mely követelmények a fontosabbak, s melyek kevésbé fontosak. Amikor egy inkremens elkészül, azt integrálni kell a már elkészült rendszerbe, s utána azt a felhasználó használatba is veheti. Az üzemeltetéssel kapcsolatos tapasztalatok visszacsatolhatóak a további inkremensek tervezésébe. Amikor egy inkremens elkészül, azt integrálni kell a már elkészült rendszerbe, s utána azt a felhasználó használatba is veheti. Az üzemeltetéssel kapcsolatos tapasztalatok visszacsatolhatóak a további inkremensek tervezésébe. Az inkrementális fejlesztés előnye, hogy Az inkrementális fejlesztés előnye, hogy A megrendelőnek nem kell megvárnia a teljes rendszer elkészültét, hanem már az első inkremens átadása után használhatja a rendszer legfontosabb szolgáltatásait. A megrendelőnek nem kell megvárnia a teljes rendszer elkészültét, hanem már az első inkremens átadása után használhatja a rendszer legfontosabb szolgáltatásait. A korábban kifejlesztett inkremensek tekinthetők prototípusnak, a használatuk során szerzett tapasztalatok beépíthetőek a fejlesztés folyamatába. A korábban kifejlesztett inkremensek tekinthetők prototípusnak, a használatuk során szerzett tapasztalatok beépíthetőek a fejlesztés folyamatába. Csökkenti a kockázatot. Az egyes inkremensekben ugyan lehetnek hibák, azonban nem valószínű, hogy ezek az egész projekt kudarcát okozzák. Csökkenti a kockázatot. Az egyes inkremensekben ugyan lehetnek hibák, azonban nem valószínű, hogy ezek az egész projekt kudarcát okozzák. A magas prioritású inkremenseket szállítjuk le először, így azok lesznek a legjobban kitesztelve. A magas prioritású inkremenseket szállítjuk le először, így azok lesznek a legjobban kitesztelve. Az egyes inkremenseknek viszonylag kicsinyeknek kell lenniük (Sommerville szerint 20 ezer sornál kisebbek), minden egyes inkremensnek szolgáltatni kell valamilyen rendszerfunkciót. Időnként nehézségeket okozhat a rendszer ilyen méretű elemekre való particionálása. Az egyes inkremenseknek viszonylag kicsinyeknek kell lenniük (Sommerville szerint 20 ezer sornál kisebbek), minden egyes inkremensnek szolgáltatni kell valamilyen rendszerfunkciót. Időnként nehézségeket okozhat a rendszer ilyen méretű elemekre való particionálása.

20 Tolerálja a követelmények megváltozását Tolerálja a követelmények megváltozását Csökkenti a kockázatot Csökkenti a kockázatot Biztonságosabb, hibatűrőbb alkalmazást eredményez Biztonságosabb, hibatűrőbb alkalmazást eredményez Lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását Lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását Lerövidíti a fejlesztés időtartamát Lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű Az iteratív fejlesztés terv szerű

21 Egységesített eljárás – Rational Unified Process A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre ben (OMT + Booch + OOSE) A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít, és mindazt egyesíti Nagyon sok előző módszertanból merít, és mindazt egyesíti Keret módszertan -> testre kell szabni Keret módszertan -> testre kell szabni

22 Használatieset-vezérelt (use case driven) Használatieset-vezérelt (use case driven) A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést Architektúra központú (architecture centric) Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája A teljes fejlesztést meghatározza a rendszer architektúrája Iteratív és inkrementális (növekvő) Iteratív és inkrementális (növekvő) Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Végighaladunk a fejlesztés fázisain. Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Végighaladunk a fejlesztés fázisain. Az egyes iterációk munkafolyamatokból állnak Az egyes iterációk munkafolyamatokból állnak Főbb jellemzői

23 Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Munka- folyamatok folyamatokKövetelményekTervezésImplementációTeszt Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző tevékenységeket szimbolizálja. Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző 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. 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 illetve diszciplínát érint, ugyanakkor az egyes diszciplínák a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Egy-egy fázis elkészítése során több munkafolyamatot illetve diszciplínát érint, ugyanakkor az egyes diszciplínák a különböző fázisokban különböző intenzitásúak, erőforrás igényűek.

24 Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell elállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell elállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. Minden egyes iteráció egy-egy mini fejlesztés. Minden egyes iteráció egy-egy mini fejlesztés. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezi az Egységesített Eljárás. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezi az Egységesített Eljárás.

25 The Rational Unified Process

26 Az elkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. Az elkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet.

27 A fejlesztés fázisai Előkészítés Előkészítés a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők; a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők; megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Kidolgozás Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; a „használati eseteket” részleteiben is kidolgozzuk; alaparchitektúrát kialakítása (Executable Architecture Baseline); alaparchitektúrát kialakítása (Executable Architecture Baseline); az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. Megvalósítás Megvalósítás a rendszer iteratív és inkrementális növelése. a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás Átadás bétaváltozatok, tesztelés, módosítás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek dokumentációk, egyéb kapcsolódó termékek

28

29 A fázisok erőforrás- és időigénye 5% 20% 65% 10% 10% 30% 50% 10%

30 Egy iteráció munkafolyamatai a tevékenységbeli dimenzió A módszertan statikus, tevékenység típusok szerinti tagozódása (ábra függőleges tengelye) A módszertan statikus, tevékenység típusok szerinti tagozódása (ábra függőleges tengelye) Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. Üzleti modellezés (Business Modeling) Üzleti modellezés (Business Modeling) Követelmények (Requirements) Követelmények (Requirements) Elemzés és Tervezés (Analysis & Design) Elemzés és Tervezés (Analysis & Design) Implementáció (Implementation) Implementáció (Implementation) Teszt (Test) Teszt (Test) Telepítés (Deployment) Telepítés (Deployment)

31 Egy iteráció munkafolyamatai (RUP) Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti (szakterületi) környezetének vizsgálata Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti (szakterületi) környezetének vizsgálata Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti elképzelések összegyűjtése (a felhasználó szemszögéből) Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti elképzelések összegyűjtése (a felhasználó szemszögéből) Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. Implementáció (Implementation): forráskódok, bináris és futtatható állományok, szövegek, képek, stb. előállítása. Az állományok elállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelentik. Implementáció (Implementation): forráskódok, bináris és futtatható állományok, szövegek, képek, stb. előállítása. Az állományok elállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelentik. Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre. Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre.

32 Egységesített Eljárás architektúrája

33 Az Egységesített Eljárás termékei A fejlesztés eredménye mindig több, mint a kód: tervek, dokumentációk, modellek. A fejlesztés eredménye mindig több, mint a kód: tervek, dokumentációk, modellek. Egymásra épülnek a termékek Egymásra épülnek a termékek Két különböző kategorizálás Két különböző kategorizálás Nézetek: Lényegében ugyanannyira részletes leírások, de a rendszer különböző „oldalait” mutatják. Egyenrangúak, az alkalmazás jellege dönti el, hogy melyik nézet mennyire határozza meg az architektúrát. Nézetek: Lényegében ugyanannyira részletes leírások, de a rendszer különböző „oldalait” mutatják. Egyenrangúak, az alkalmazás jellege dönti el, hogy melyik nézet mennyire határozza meg az architektúrát. Modellek: A rendszer logikailag különböző absztrakciós szintjeit mutatják be. Az egyes munkafázisok, diszciplínák különböző modelleket, más néven termék csoportokat hoznak létre, illetve bővítenek. Modellek: A rendszer logikailag különböző absztrakciós szintjeit mutatják be. Az egyes munkafázisok, diszciplínák különböző modelleket, más néven termék csoportokat hoznak létre, illetve bővítenek. (ld. UML)

34 Az egyes termékcsoportok eltérő növekedése

35 Az Egységesített Eljárás jellegzetességei Fő jellegzetességek Használati eset vezérelt Használati eset vezérelt Architektúra központú Architektúra központú Iteratív és inkrementális Iteratív és inkrementális További jellegzetességek Objektum-orientált Objektum-orientált Komponens alapú Komponens alapú Vizuális modellezésre (UML) épül Vizuális modellezésre (UML) épül Ellenőrzött Ellenőrzött Konfigurálható Konfigurálható

36 Használatieset-vezérelt fejlesztés Azt akarjuk elkészíteni, amire a felhasználónak szüksége van. Aktor: a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől Aktor: a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől Használati eset: a használatnak egy értelmes, kerek egysége, kívülről írja le a rendszer viselkedését, szolgáltatásait Használati eset: a használatnak egy értelmes, kerek egysége, kívülről írja le a rendszer viselkedését, szolgáltatásait Architektúrálisan fontos használati eset: a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg Architektúrálisan fontos használati eset: a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg A használati esetek határozzák meg, hogy mit fejlesztünk? (rendszerhatárok, funkcionalitás) mit fejlesztünk? (rendszerhatárok, funkcionalitás) milyen sorrendbe fejlesszük? (prioritás) milyen sorrendbe fejlesszük? (prioritás) milyen legyen a termékünk belső szerkezete (architektúra) milyen legyen a termékünk belső szerkezete (architektúra)

37 Követelmény nézet (Requirements View) vagy Használatieset-nézet (Use Case View) Követelmény nézet (Requirements View) vagy Használatieset-nézet (Use Case View) Dinamikus nézet (Dynamic View) vagy Folyamat nézet (Process View) Dinamikus nézet (Dynamic View) vagy Folyamat nézet (Process View) Logikai nézet (Logical View) vagy Tervezési nézet (Design View) Logikai nézet (Logical View) vagy Tervezési nézet (Design View) Komponens nézet (Component View) vagy Implementációs nézet (Implementation View) Komponens nézet (Component View) vagy Implementációs nézet (Implementation View)

38 A használati eset nézet meghatározza a tervezési nézetet, mert a használati eseteket megvalósító osztályok, együttműködések alkotják a kívánt rendszert. A használati eset nézet meghatározza a tervezési nézetet, mert a használati eseteket megvalósító osztályok, együttműködések alkotják a kívánt rendszert. A használati eset nézet meghatározza az implementációs nézetet, mert a használati eseteket megvalósító szoftver komponenseket kell kifejleszteni vagy megvásárolni. A használati eset nézet meghatározza az implementációs nézetet, mert a használati eseteket megvalósító szoftver komponenseket kell kifejleszteni vagy megvásárolni. A használati eset nézet meghatározza a folyamat nézetet, mert a használati esetek befolyásolják, hogy hol és milyen mértékű párhuzamosságra, illetve hol és milyen aktív osztályokra van szükség. A használati eset nézet meghatározza a folyamat nézetet, mert a használati esetek befolyásolják, hogy hol és milyen mértékű párhuzamosságra, illetve hol és milyen aktív osztályokra van szükség. A használati eset nézet meghatározza a telepítési nézetet, mert a használati eseteknek megfelelő topológiát célszerű kialakítani. A használati eset nézet meghatározza a telepítési nézetet, mert a használati eseteknek megfelelő topológiát célszerű kialakítani. A használati esetek a rendszer funkcionális tagolását, „függőleges”, felosztását, a funkcionális alrendszerekre való felosztás határozzák meg. A használati esetek a rendszer funkcionális tagolását, „függőleges”, felosztását, a funkcionális alrendszerekre való felosztás határozzák meg.

39 Architektúra központú fejlesztés Architektúra: strukturálisan fontos elemek és ezek kapcsolata. Architektúra: strukturálisan fontos elemek és ezek kapcsolata. A rendszer nagy léptékű tagolását írja el A rendszer nagy léptékű tagolását írja el Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül. A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül. A klasszikus példa : ház A klasszikus példa : ház Alaprajz Alaprajz Homlokzati rajz Homlokzati rajz Elektromos kábelezés és berendezések Elektromos kábelezés és berendezések Épületgépészet, vízvezetékek, fűtés Épületgépészet, vízvezetékek, fűtés

40 Az architektúra célja Lehetővé teszi a bonyolultság kezelését Lehetővé teszi a bonyolultság kezelését Átláthatóvá tesz a fejlesztést Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható project menedzsment Átlátható project menedzsment Kockázatok csökkentése Kockázatok csökkentése Lehetővé válik a párhuzamos fejlesztés Lehetővé válik a párhuzamos fejlesztés

41 Rétegzett architektúra Fizikai, telepítési rétegzettség (layer): az egyes rétegek különböző futtatható állományokban vannak, ezek a futtatható állományok különböző gépeken helyezkednek el, az egyes futtatható elemek hálózati protokollon keresztül beszélgetnek – divatos, de „drága”. Fizikai, telepítési rétegzettség (layer): az egyes rétegek különböző futtatható állományokban vannak, ezek a futtatható állományok különböző gépeken helyezkednek el, az egyes futtatható elemek hálózati protokollon keresztül beszélgetnek – divatos, de „drága”. Logikai rétegzettség (tier): a forráskód belső tagozódása. Ez áttekinthetővé teszi az alkalmazást, nem hat a teljesítményre Logikai rétegzettség (tier): a forráskód belső tagozódása. Ez áttekinthetővé teszi az alkalmazást, nem hat a teljesítményre Egyirányú a logikai függés: a fizikai rétegzettség feltételezi a logikait, de fordítva nem! Egyirányú a logikai függés: a fizikai rétegzettség feltételezi a logikait, de fordítva nem!

42 Logikai rétegek Kezelői felület Kezelői felület Csak a megjelenés Csak a megjelenés Nem „gondolkodik”, de „csinos” Nem „gondolkodik”, de „csinos” Alkalmazás logika Alkalmazás logika Az alkalmazásra jellemző elemek Az alkalmazásra jellemző elemek Adatbázis logika Adatbázis logika Egész szervezetre, egész adatbázisra jellemző, nem alkalmazás függő Egész szervezetre, egész adatbázisra jellemző, nem alkalmazás függő

43 Three-tier The 3-Tier architecture has the following 3-tiers. The 3-Tier architecture has the following 3-tiers. Presentation Tier Presentation Tier Application Tier/Logic Tier/Business Logic Tier Application Tier/Logic Tier/Business Logic Tier Data Tier Data Tier

44

45

46 Model-view-controller Model: Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items). Model: Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model. Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model. View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page. View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page. Controller: Processes and responds to events, typically user actions, and may invoke changes on the model and view. Controller: Processes and responds to events, typically user actions, and may invoke changes on the model and view.

47 Events typically cause a controller to change a model, or view, or both. Whenever a controller changes a model’s data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.

48

49 Java Platform, Enterprise Edition (J2EE) View View The view in a J2EE application may be represented by a Java Server Page. Alternately, the code to generate the view may be part of a servlet. The view in a J2EE application may be represented by a Java Server Page. Alternately, the code to generate the view may be part of a servlet. Controller Controller The controller in a J2EE application may be represented by a servlet. The controller in a J2EE application may be represented by a servlet. Model Model The model is represented by entity beans. The model is represented by entity beans.

50 Komponens alapú fejlesztés Buy the best, build the rest Buy the best, build the rest Az alkalmazás diszkrét, jellegzetesen önállóan fejleszthető és futtatható elemből épül fel Az alkalmazás diszkrét, jellegzetesen önállóan fejleszthető és futtatható elemből épül fel Kis lépésekben, kis változással fejleszthető tovább az alkalmazás Kis lépésekben, kis változással fejleszthető tovább az alkalmazás A komponensek megoszthatóak az alkalmazások között A komponensek megoszthatóak az alkalmazások között


Letölteni ppt "A szoftverfejlesztési módszertan A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le A fejlesztési modellek a fejlesztési."

Hasonló előadás


Google Hirdetések