A szoftverfejlesztési módszertan

Az előadások a következő témára: "A szoftverfejlesztési módszertan"— 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 Ú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.

2 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) 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. 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)
A szoftver fejlesztés első publikált modellje (1970), ami viszonylag stabil körülmények között mind a mai napig jól működik. A fejlesztési folyamatot fázisokra bontja, a fázisok szigorúan egymás után következnek, minden egyes fázisra jellemzőek azok a dokumentumokat, amiket el kell fogadni („alá kell írni”) a továbblépéshez. A visszalépés egy korábbi fázisba igencsak nehézkes, csakúgy mint vízesésen felfelé evezni. A gyakorlati alkalmazásban a fázisok többé-kevésbé átfedhetik egymást. Az egyes fázisok végrehajtása iteratív tevékenység. A dokumentumok előállításának, jóváhagyásának a költségei miatt elfogadott gyakorlat, hogy egy-egy fázist már néhány iteráció után befagyasztanak, a problémák megoldását lehagyják, kikerülik avagy későbbre halasztják. Ez viszont törvényszerűen azt eredményezi, hogy a rendszer már az átadás pillanatában sem felel meg az éppen aktuális követelményeknek. Ugyanakkor a rejtett, lappangó felhasználói igények, tapasztalatok csak nagyon későn, a rendszer működtetése során kerülnek felszínre. Ez a fejlesztési modell akkor alkalmazható hatékonyan, ha a követelmények jól definiáltak és stabilak. Ebben ez esetben viszont hatékony munkafolyamatot biztosít.

4 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ó. „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

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) Design (tervezés): 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) Implementation (implementáció, kódolás): A rendszer egységeinek kódolása Software Integration & Verification: modulok egyesítése, tesztelése 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. 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. 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. 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. 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. 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. A mérföldkövei könnyen érthetőek. 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. Nem kezeli a szoftverfejlesztésben elterjedt iterációkat. 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. 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ő. 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. 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). 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.

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. Minden tervezési fázisok van egy párja a tesztelési fázisok között A tesztelés hangsúlyozása

9

10

11 Evolúciós szoftverfejlesztés
Az evolúciós fejlesztés alapötlete, hogy a kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyűlt tapasztalatokat építsük be egy újabb termék verzióba. Ezt a folyamatot mindaddig ismételjük, amíg el nem érjük a kívánalmaknak már megfelelő rendszert. Ez a megközelítési mód sokkal inkább lehetővé teszi párhuzamosságot és a sokkal gyorsabban csatolja vissza a fejlesztési folyamatba a menet közben felmerülő felhasználói igényeket. Prototípus modell: A modell lényege, hogy a projekt első fázisában prototípust készít, amelyben a tervek fő gyengeségei kiderülhetnek, és megoldhatjuk az esetleges technológiai kérdéseket is. A pilot termék egyes részei később az éles projektben felhasználhatók, de szükség esetén következmény nélkül el is dobhatók: az egyetlen cél a tanulás és a tapasztalatszerzés. Feltáró fejlesztés Eldobható 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.
Valamennyi iteráció ugyanazon lépésekből áll Lehetővé teszi a kockázatok korai felismerését A megrendelőt minden fázisba aktívan bevonja A modell elég komplex, megértése nem egyszerű 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.

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

16 Key steps in the process were
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. Key steps in the process were 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. 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ő
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. 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. 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.

19 Az inkrementális fejlesztés előnye, hogy
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. 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 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. 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.

20 Tolerálja a követelmények megváltozását Csökkenti a kockázatot
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 Lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű Miért van szükség iteratív fejlesztésre Egyszerű, kicsiny rendszerek esetében alkalmazható a feladat definiálása, tervezés, kódolás, tesztelés szekvenciális, „vízesésszerű” fejlesztési mód. Nagyobb, bonyolultabb rendszerek esetében más módszert kell keresni. A megrendelői, felhasználói igények is folyamatosan változnak. A hagyományos „vízesés-modell” alkalmazásakor számos hiányosság, félreértés, hiba csak a fejlesztés végén, a tesztelési fázisban bukik elő. Ugyanakkor ez a modell nagyon nehezen viseli el a fejlesztési célok menet közbeni megváltozását. Szemben a „vízesés-modellel” az iteratív fejlesztés lényegesen rugalmasabb, s így kisebb a kockázata is. A fejlesztés iteratív megközelítése beépíti a módszertanba a fokozatos megértést, illetve az igények folyamatos változását. Ugyanakkor lehetővé teszi a kockázatok korai felismerését és kezelését. Az iteratív fejlesztés tolerálja a követelmények megváltozását A határidő illetve a költségek túllépése általában a megváltozott követelményekből adódik. A fejlesztés időtartama alatt viszont a követelmények törvényszerűen megváltoznak, mivel a rendszer környezete, a szabályok és az előírások, a technológia is változik, a felhasználók folyamatosan ismerik meg a rendszer szolgáltatásait. A fejlesztési iterációk eredményeként létrejövő újabb és újabb szoftver verziókat a megrendelő rendszeresen megkapja, így szoros a kapcsolat a megrendelői és a fejlesztői csapat között. A megváltozott követelményeket viszonylag hamar be lehet építeni a rendszerbe. Az iteratív fejlesztés viszonylag jól tolerálja a taktikai jellegű változtatásokat. Elképzelhető, hogy az üzleti viszonyok változása miatt hamarabb kell piacra dobni a terméket – az iteratív fejlesztés esetén az egyes iterációk végeredménye kibocsátható termék. Az iteratív fejlesztés csökkenti a kockázatot Az egyes iterációk által előállított termékeket a megrendelő megkapja, teszteli így a követelmények megváltozása, az esetlegesen pontatlanul, avagy hiányosan rögzített követelményekre viszonylag hamar fény derül, s ezzel jelentősen csökkenti az üzleti jellegű kockázatokat. A műszaki jellegű kockázatok jelentős része a késői integrációból adódik. A klasszikus, vízesés-szerű fejlesztés esetében az egyes részrendszerek integrációja a fejlesztés végén, egyetlen nagy összeépítési kampányban (big bang) történik meg. A hibák és a kockázatok jelentős részére az integrációkor derül fény. Iteratív fejlesztés esetén folyamatos az integráció. A folyamatos integráció révén az egyes kockázati elemekre hamar fény derül, az esetlegesen hézagosan illeszkedő elemek javítására több idő van. Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Iteratív fejlesztésnél a rendszer tesztelése az integrációval együtt, már a fejlesztés korai szakaszában elkezdődik. A sokszori tesztelésnek köszönhetően valószínűbb, hogy még a fejlesztés időszaka alatt felszínre kerülnek az esetleges rejtett hibák, illetve a kritikus kódrészleteknek van idejük „megérni”. Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását Az iteratív fejlesztési folyamat során több lehetőségük van a fejlesztésben résztvevő személyeknek, hogy a módszertant és a fejlesztési technológiákat elsajátítsák, gyakorolják. Az iterativitás, az inkrementális növekedés miatt ez esetleges hibáknak, emberi tévedéseknek kisebb a kockázata: a rendszeres tesztelés az esetleges tökéletlen megoldásokat fel fogja deríteni. A fejlesztői csapat személyi összetétele egy hosszabb fejlesztés során meg szokott változni. Iteratív fejlesztés során az új tagoknak lehetőségük van a módszertan, a belső szabványok, szokások, konvenciók elsajátítására. Az egyes iterációk végén az áttekintés nem csak a fejlesztés eredményét, a terméket vizsgálja, hanem magát a fejlesztési folyamat, a fejlesztői csapatban is javasolhat változtatásokat. Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés növeli a fejlesztés hatékonyságát, lerövidíti a fejlesztés időtartamát, mert az egymást követő munkafolyamatok hamarabb elkezdhetők. Az implementációnak meg kell várnia a tervezés befejezését, a tesztelésnek meg kell várnia az implementációt, a kézikönyvek és oktató anyagok írásával meg kell várni a végleges, kijavított verziót, stb. Az iteratív fejlesztés a teljes fejlesztést sok mini-projektre bontja fel, s ezek a mini-projektek egymástól többé-kevésbé függetlenül fejleszthetők. Az egyes szakterületek, munkafolyamatok technológia függése megmarad, azonban több, részben párhuzamos mini-projekt esetében az egyes szakterületek egymásra való várakozása jelentősen csökkenhet. Az iteratív fejlesztés révén könnyebb felismerni az újrafelhasználható szoftver komponenseket is. Az iteratív fejlesztés terv szerű Vannak, akik az iteratív és inkrementális fejlesztést az ötletszerű, kapkodó fejetlen munka „tudományos” megfogalmazásának vélik, s mint ilyen ellen berzenkednek. Ezzel szemben az iterációik 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 megtervezik.

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 1997-ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít, és mindazt egyesíti Keret módszertan -> testre kell szabni

22 Főbb jellemzői 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 Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája 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 munkafolyamatokból állnak

23 Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás folyamatok
Munka- folyamatok Követelmények Tervezés Implementáció Teszt Másik megközelítésben a fázisok iterációkra bonthatók. Minden egyes iteráció egy-egy mini fejlesztés. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. Hasonlóan az iterációkhoz, a fázisok is a projekt időbeli lefolyását tagolják, számuk és nevük azonban kötött. A hasonló iterációk összességét fázisoknak nevezzük. A fázisokhoz jellegzetes mérföldkövek, azaz elérendő célok tartoznak. A fázis végén, a mérföldkő elérésekor lehet és kell dönteni a projekt további sorsáról. 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. 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. 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. 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
Buckás ábra átlós jellege Az ábrának van egy nagyon határozott átlós jellege, azaz az előkészítés során az üzleti modellezés és a követelmény felmérés a leghangsúlyosabb, az átadáskor a telepítés, a tesztelés. Ugyanakkor érdemes megfigyelni, ez az átlós jelleg nem kizárólagos! Az üzleti modellezés ugyan jellemző a ciklus elejére, de bármikor előfordulhat. Ugyan így, elemzés, tervezés a ciklus első harmadára a jellemző, de nem kizárólagos, előfordulhat már a fejlesztés első pillanatától az utolsóig akármikor. – Ez az, ami az iteratív fejlesztés alapvetően megkülönbözteti a vízesés jellegű fejlesztéstől. Nem igaz, hogy az előkészítés egyenlő lenne az üzleti modellezéssel és a követelmények összegyűjtésével. Ezek a leghangsúlyosabb tevékenységek, mellette van elemzés, tervezés, implementálás, tesztelés is. A kidolgozás nem egyenlő az elemzéssel és a tervezéssel. Ugyan a kidolgozásra ezek a munkafolyamatok a legjellemzőbbek, de nem csak ezekből áll. Van mellette üzleti modellezés, követelmény összegyűjtés, implementáció, tesztelés is. Az építésre nagyon jellemző a részletes tervezés és az implementálás, tesztelés, de lehet benne üzleti modellezés, követelményelemzés is. És ugyan ez igaz az átadásra is. Az átadás nem csak telepítés, bár az a legfontosabb tevékenysége.

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

27 A fejlesztés fázisai Előkészítés Kidolgozás Megvalósítás Átadá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; 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. Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; 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. Megvalósítás a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek

28

29 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% % % %

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) Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. Üzleti modellezés (Business Modeling) Követelmények (Requirements) Elemzés és Tervezés (Analysis & Design) Implementáció (Implementation) Teszt (Test) 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 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. 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. 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. Minden iteráció különböző, minden iterációt külön meg kell tervezni.

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. Egymásra épülnek a termékek 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. 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) Egyetlen fejlesztési cikluson belül is állandóan használjuk a megelőző tevékenységek dokumentációit. Újra felhasználhatunk már elkészített dokumentációkat.

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 Architektúra központú Iteratív és inkrementális További jellegzetességek Objektum-orientált Komponens alapú Vizuális modellezésre (UML) épül Ellenőrzött Konfigurálható 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. A vizuális tervezés nagymértékben segíti az absztrakciót, a logikai szintek megkülönböztetését. Az Egységesített Eljárás termék csoportjai (modelljei) különböző absztrakciós szintet valósítanak meg. A vizuális tervezés nagymértékben segíti a bonyolultság kezelését, egy-egy ábra a rendszernek egy vetületét mutatja egy meghatározott részletességgel.

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 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 A használati esetek határozzák meg, hogy mit fejlesztünk? (rendszerhatárok, funkcionalitás) milyen sorrendbe fejlesszük? (prioritás) 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)
Dinamikus nézet (Dynamic View) vagy Folyamat nézet (Process 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)

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

39 Architektúra központú fejlesztés
Architektúra: strukturálisan fontos elemek és ezek kapcsolata. A rendszer nagy léptékű tagolását írja el 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 klasszikus példa: ház Alaprajz Homlokzati rajz Elektromos kábelezés és berendezések É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
Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható project menedzsment Kockázatok csökkentése 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”. 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!

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

43 The 3-Tier architecture has the following 3-tiers.
Three-tier The 3-Tier architecture has the following 3-tiers. Presentation Tier Application Tier/Logic Tier/Business Logic 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). 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. 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 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 The controller in a J2EE application may be represented by a servlet. Model The model is represented by entity beans.

50 Komponens alapú fejlesztés
Buy the best, build the rest 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 A komponensek megoszthatóak az alkalmazások között