A fejlesztés módszertana

Átírás

1 A fejlesztés módszertana (A térkép) május május 1/58

2 1. BEVEZETÉS A MÓDSZERTANOK VILÁGÁBA...5 MI A MÓDSZERTAN ÉS MIÉRT VAN RÁ SZÜKSÉG?... 5 A PROGRAMOZÁSTÓL A RENDSZERFEJLESZTÉSIG... 5 Adatbázis kezelés... 6 Túl az oo szemléleten... 6 NEVEZETES SZOFTVERFEJLESZTÉSI MODELLEK... 7 Vízesés modell... 7 Evolúciós fejlesztés... 8 Feltáró fejlesztés...9 Eldobható prototípus készítése... 9 Inkrementális fejlesztés...10 Spirális fejlesztés...11 Újrafelhasználás-orientált fejlesztés...11 Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Rendszerintegráció Formális rendszerfejlesztés...13 KULCSFOGALMAK...14 A használati esetek...14 Használati esetek és architektúrálisan fontos használati esetek Használati estek, mint rendszerhatárok Használati estek, mint funkcionalitás A használati esetek, mint az architektúra meghatározói A használati estek prioritásai meghatározzák a fejlesztés prioritásait Az architektúra...16 Az architektúra az alkalmazás jellege alapján Az iteratív és az inkrementális rendszerfejlesztés...16 Miért van szükség iteratív fejlesztésre Az iteratív fejlesztés tolerálja a követelmények megváltozását Az iteratív fejlesztés csökkenti a kockázatot Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását...19 Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű AZ EGYSÉGESÍTETT ELJÁRÁS...20 AZ EGYSÉGESÍTETT ELJÁRÁS ÁTTEKINTÉSE...20 Az Egységesített Eljárás szoftverfejlesztési módszertan...20 Az Egységesített Eljárás szoftverfejlesztési jellegzetességei...21 AZ EGYSÉGESÍTETT ELJÁRÁS KÉT DIMENZIÓJA...22 Buckás ábra átlós jellege...22 Az időbeli dimenzió...23 Iterációk Fázisok Fázisok és iterációk Előkészítő fázis (Inception) Kidolgozási fázis (Elaboration) Építési fázis (Construction) Átmenet (Transition) A tevékenységbeli dimenzió...26 Üzleti modellezés (business modelling) május 2/58

3 Követelmények összegyűjtése (requirements capture) Elemzés (analysis) Tervezés (design) Implementáció (implementation) Teszt (test)...28 Telepítés (deployment) Támogató munkafolyamatok AZ EGYSÉGESÍTETT ELJÁRÁS ARCHITEKTÚRÁJA...28 AZ EGYSÉGESÍTETT ELJÁRÁS TERMÉKEI...29 Modellek és nézetek...29 Nézetek...30 Modellek...30 A 4+1 nézet...30 Követelmény nézet Logikai nézet Dinamikus nézet Komponens nézet Telepítési nézet A modellek, avagy termék csoportok...31 A termék csoportok és a nézetek kapcsolata HASZNÁLATI ESET VEZÉRELT FEJLESZTÉS...32 A használati esetek, mint az architektúra meghatározói...32 ARCHITEKTÚRA KÖZPONTÚ FEJLESZTÉS...33 Architektúra: strukturálisan fontos elemek és ezek kapcsolata Az architektúrálisan fontos nézetek ITERATÍV ÉS INKREMENTÁLIS FEJLESZTÉS...34 Az iteratív fejlesztés tolerálja a követelmények megváltozását Az iteratív fejlesztés csökkenti a kockázatot Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását...34 Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű Absztrakt munkafolyamatok és az iterációs munkafolyamatok Az egyes termékcsoportok eltérő növekedése KOCKÁZAT-VEZÉRELT FEJLESZTÉS...36 VIZUÁLIS TERVEZÉS...37 KOMPONENS ALAPÚ FEJLESZTÉS ALKALMAZÁSFEJLESZTÉS...39 TÖBB DIMENZIÓS LEÍRÁS...39 ELLENŐRZÖTT FEJLESZTÉS...39 SZAKTERÜLETI MODELLEZÉS...40 Domain modell...41 Fogalomjegyzék...42 Szakterületi folyamat modell...42 Szakterületi állapotátmenet modell...42 Szakterületi együttműködések modellje...42 Szakterületi aktivitás modell...42 KÖVETELMÉNY FELTÁRÁS...42 Célkitűzés...43 Követelmény modell...43 Felhasználói követelmények Szakterületi követelmények Nem funkcionális követelmények május 3/58

4 Használati eset modell...45 ELEMZÉS ÉS TERVEZÉS...47 Réteg, alrendszer architektúra...48 Funkcionális tagozódás Strukturális architektúra minták...49 Rétegzett architektúra A rétegzett architektúra ajánlott rétegei Az architektúra függése a többi terméktől Dinamikus nézet...50 Szekvencia diagramok Együttműködési diagram Állapot diagram Tevékenység diagram A dinamikus nézet függése a többi terméktől A függések kezelése...55 A naiv fejlesztési sorrend szerinti tevékenységek Fejlesztés csonkok alkalmazásával IMPLEMENTÁCIÓ...57 TESZTELÉS...57 TELEPÍTÉS...57 AZ ELŐKÉSZÍTŐ FÁZIS...57 A KIDOLGOZÁSI FÁZIS...57 AZ ÉPÍTÉSI FÁZIS...57 AZ ÁTADÁSI FÁZIS IRODALOMJEGYZÉK...58 Angolul Magyarul május 4/58

5 1. Bevezetés a módszertanok világába Mi a módszertan és miért van rá szükség? Kezdetben olyan programokat írtunk, ami egytől százig kiírja a prímszámokat. Később egyre többet ismertünk meg, s a feladatok is egyre nőttek. S bár erőnk, képességeink, ismereteink növekednek, de a feladatok bonyolultsága gyorsabban növekszik. Szükségünk van valamilyen módszerre, hogy uralni tudjuk a bonyolultságot. Változnak a programozási eszközök: A hőskorban közvetlenül gépi kódban írták a programokat, aztán megjelent az assembly, majd az úgynevezett magas szintű nyelvek, ma meg színes-szagos 4GL eszközök, hihetetlenül összetett API-k segítik a programozó munkáját. Másrészt, a csupasz programozásról nagyon hamar kiderül, hogy nem elég. Meg kell tervezni a programot. Azonban sokszor nem elegendő, ha csak a programot tervezzük meg, föl kell mérni az igények, ki kell deríteni a követelményeket, a fejlesztés sok résztvevőjét koordinálni kell. Ezzel jutottunk el a szoftver fejlesztési módszertanhoz. A fejlesztés célja a megrendelői, felhasználói igényeknek megfelelő szoftver rendszer előállítása megadott határidőre, megadott költség kereteken belül, s mindez jó minőségben. A megfogalmazott felhasználói igényekből a legritkább esetben vezethető le közvetlenül a teljes szoftver rendszer. A meghatározott peremfeltételek (minőség, határidő, költségek) rendszerint ellentmondanak egymásnak. Klasszikus megfogalmazás szerint 1 a szoftver fejlesztési módszertan o Útmutatást ad a csoportmunka irányítására o Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor o Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát o Kritériumokat ad a termékek és tevékenységek mérésére és minősítésére A cél a felhasználói követelmények és a késztermék közötti szakadék áthidalása. A programozástól a rendszerfejlesztésig Jellemzően egy-egy szemlélet (gépközeli, strukturált, objektum-orientált) legalábbis az eddigiekben a programozás felől indult, programozók találták ki önmaguknak, hogy a saját életüket tegyék kényelmesebbé. 1 Grady Booch, Object Solutions Managing the Object-Orientéd Project. Reading, MA: Addison- Wesley, május 5/58

6 Később ezt a személetet kiterjesztették, elmélet gyártottak mögé, s lett belőle program tervezési módszertan, modellezési szemlélet. Később ez a szemlélet tovább gyűrűzik, lesz belőle szoftver fejlesztési módszertan, aztán rendszertervezés, rendszertervezés, üzleti folyamatok újraszervezése. Azaz a kicsiben jól működő módszereket kiterjesztik, általánosítják és magasabb logikai szintre emelik. Rendszerszervezés Szoftver fejlesztési módszertan Program tervezés Programozás 1. ábra A strukturált szemlélet jól kidolgozott mind a programozásra, mind a program tervezésre (Jackson módszer, Wairner módszer), mind rendszertervezésre (SSADM). Ma az objektumorientált szemlélet a programozásban megkerülhetetlen (szinte minden 4GL eszköz az oo szemléletre épít), vannak jól kidolgozott program tervezési módszerek (OMT, UML, Design patterns), s az oo szemlélet mostanság kezdi kiterjedni a szoftver fejlesztés módszertanok területére (Egységesített Eljárás). Jelenleg még valóban oo szemléletű rendszerszervezési módszertan nincsen. ADATBÁZIS KEZELÉS További érdekesség, hogy bár az adatbázis-kezelés logikailag nagyjából a programozással egy absztrakciós szinten van, de mind a mai az adatbázis-kezelésben szinte egyeduralkodó a strukturált (relációs; Codd féle) szemlélet. Bár kísérletek meglehetősen hosszú ideje folynak oo adatbázis-kezelőkkel, de valóban használható, valóban oo szemléletű adatbázis-kezelő nincsen piaci forgalomban. TÚL AZ OO SZEMLÉLETEN Természetesen az oo szemlélet nem végállomás, nem old meg mindent, vannak olyan feladatok, helyzetek, amikre az oo szemléletnek nincsen kellően jó megoldása. Léteznek is kísérletek, kutatások az oo szemlélet meghaladására, talán a két legígéretesebb irányzat a minták alkalmazása (patterns), illetve az extrém programozásnak május 6/58

7 nevezett szemlélet. Közös azonban ezekben a kísérletekben, hogy nem elvetik, hanem továbbfejlesztik az oo szemléletet, és megvalósításukat tekintve is jellemzően oo eszközökre támaszkodnak. A programozáson túli területek (szoftver fejlesztési módszertanok, rendszerfejlesztés területén pedig még nyomai is alig látszanak az oo szemléleten túli megközelítéseknek, azaz még jó pár évig van létjogosultsága az oo szemléletnek. Nevezetes szoftverfejlesztési modellek A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le. Az alább ismertetendő modellek ritkán jelennek meg tiszta, ideális formában, sokkal inkább a fejlesztési folyamat egyfajta logikai absztrakciója. Vízesés modell 2 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 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. 2 [Som] május 7/58

8 Követelmények meghatározása Elemzés Tervezés Implementáció és egységtesztelés Integráció és rendszerteszt Működttetés és karbantartás 2. ábra 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. Evolúciós fejlesztés 3 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. 3 [Som] május 8/58

9 Specifikáció Fejlesztés Végső termék verzió Validálás Közbenső termék v erzió 3. ábra Két lényegében eltérő típusa ismert: FELTÁRÓ FEJLESZTÉS A fejlesztés célja, hogy a megrendelővel szorosan együttműködve feltárjuk a valós igényeket és kifejlesszük a végleges rendszert. A rendszer fejlesztését a már ismert részekkel kell kezdeni, s újabb és újabb elemek hozzáadásával jutunk el a végtermékig. ELDOBHATÓ PROTOTÍPUS KÉSZÍTÉSE Az evolúciós fejlesztés célja a követelmények mennél pontosabb feltárása. A prototípus próbálgatásos módszerrel közelíti meg a követelményeket, első sorban az ismeretlen követelmények feltárására koncentrál. Az eldobható prototípus készülhet más technológiával, s belső strukturálására sem kell akkor a figyelmet fordítani, illetve a sokszori átdolgozás miatt törvényszerű, hogy a belső struktúra nehezen átláthatóvá válik. Az eldobható prototípust végtermékké minősíteni, avagy az eldobható prototípus kódját közvetlenül felhasználni a végtermékben súlyos szakmai hiba. A prototípuskészítés akkor hatékony, ha a követelmények nem ismertek a fejlesztési folyamat elején. Sommerville 4 szerint rövid élettartamú, kicsiny, közepes ( ezer sornál kisebb) rendszereknél hatékony. Ugyanakkor nagyobb rendszerek esetében az evolúciós megközelítés nehézségei kritikussá válhatnak. Hátránya ennek a modellnek, hogy A fejlesztési folyamat előrehaladása nem látható, nem mérhető. Ez gyakran pro- 4 [Som] május 9/58

10 jektmenedzselési gondokhoz vezet. Rosszul strukturált, nehezen továbbfejleszthető terméket eredményez. Inkrementális fejlesztés 5 Hibrid megközelítési mód, a vízesés illetve az evolúciós modell előnyeit ötvözi. 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. Az első inkremens kifejlesztésével párhuzamosan folyat a további inkremensek specifikálása, tervezése. 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. Követelmények vázlatos meghatározása Követelmények inkremensekhez rendelése Rendszer architektúra meghatározása Inkremens fejlesztése [Nem teljes a rendszer] Inkremens v alidálása Inkremens integrálása Rendszer v alidálása [Végleges rendszer] 4. ábra Az egyes inkremensek fejlesztése történhet eltérő fejlesztési modell alapján is. A jól definiált követelményeket kielégítő inkremensek fejleszthetőek a vízesés modell alapján, míg, ahol a specifikáció nem kellően egyértelmű, ott alkalmazható az evolú- 5 [Som] május 10/58

11 ciós megközelítés. 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 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 6 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. A fejlesztés kezdetén számos a későbbi inkremensekben megvalósítandó rendszerfunkció még nincsen kellő pontossággal definiálva, ezért a rendszer közös alapszolgáltatásainak a meghatározása nehézségekbe ütközhet. Spirális fejlesztés 7 Az iteratív megközelítés során a fejlesztés mintegy spirál vonalban halad előre, a felhasználó, avagy a megrendelő rendszeresen megkapja az újabb és újabb futtatható program verziókat. Tervezés és prototípus Modellezés és design Használat és újabb követelmények Implementáció 5. ábra Újrafelhasználás-orientált fejlesztés 8 Jelenleg még viszonylag szűkebb körben alkalmazott fejlesztési megközelítés, azon- 6 [Som] 7 [Som] 8 [Som] május 11/58

12 ban feltehetőleg a közeli jövőben egyre többen fogják tudatosan ezt a megközelítést választani. A fejlesztési folyamatot a meglévő komponensek újrafelhasználása határozza meg. Jelentős méretű komponens könyvtárak létét tételezi fel. Ebben a megközelítésben a komponens nem csak a 4GL eszközök szokásos, finom szemcsézettségű komponensei (nyomógombok, címkék, stb.), hanem nagyméretű, üzleti komponensek (főkönyv, kezelő alrendszer, stb.) is lehetnek, gyakran önálló létjogosultsággal rendelkező alrendszerek (pl.: szövegszerkesztő, számolótábla, stb.) Követelmények specifikációja Komponens elemzés Követelmények módosítása Rendszertervezés újrafelhasználással Fejlesztés és integráció Rendszervalidáció 6. ábra KOMPONENSELEMZÉS A hozzáférhető komponensek a legritkább esetben valósítják meg a rendszertől elvárt szolgáltatásokat, jellemzően a kívánalmaknak csak egy részét elégítik ki, s sokszor egyéb, nem igényelt szolgáltatásokat is nyújtanak. KÖVETELMÉNYMÓDOSÍTÁS A rendelkezésre álló komponens szolgáltatások és a követelmények összehangolása. Ez történhet a követelmények megváltoztatásával, illetve történhet újabb komponensek beszerzésével, esetleg kifejlesztésével is május 12/58

13 RENDSZERTERVEZÉS ÚJRAFELHASZNÁLÁSSAL A készítendő rendszer vázát kell meghatározni, avagy egy már meglévő struktúrát kell felhasználni. Hangsúlyos tevékenység a komponensek együttműködésének a biztosítása. RENDSZERINTEGRÁCIÓ A megvásárolt, illetve a kifejlesztett komponensek összeépítése. Ebben a fejlesztési modellben az integráció lényegesen fontosabb tevékenység, mint a többi megközelítési módban. E módszer csökkenti a fejlesztési időt és a kockázatokat. Ugyanakkor a leszállított rendszer törvényserűen tartalmaz kompromisszumokat a követelmények meghatározása területén, ami a rendszer használhatóságát rontja. Az összeépítendő komponensek ritkán eredményeznek tiszta, átlátható architektúrát, az architektúrális gyengeségek akadályozhatják a továbbfejlesztés. A komponensek számos, a rendszer szempontjából felesleges kódot illetve szolgáltatást tartalmazhatnak, amik szintén ronthatják a rendszer struktúráját. Formális rendszerfejlesztés 9 A fejlesztés kiinduló pontja egy matematikailag egzakt rendszerdefiníció. Ezt a formális definíciót matematikailag meghatározott, ellenőrzött transzformációkkal alakítják át működő rendszerré. A matematikailag egzakt program helyesség bizonyítás hihetetlenül drága. Ezzel szemben a formális fejlesztés során mindig matematikailag egzakt lépések történnek, így a fejlesztés végén az elkészült termék törvényszerűen megfelel a specifikációnak. Ez a fejlesztési modell biztonság, avagy védelem kritikus rendszerek fejlesztése során használatos, egyéb fejlesztésekben alig használják 9 [Som] május 13/58

14 Követelmények meghatározása Formális specifikáció Formális transzformációk Integráció és rendszertesztek 7. ábra Kulcsfogalmak A használati esetek HASZNÁLATI ESETEK ÉS ARCHITEKTÚRÁLISAN FONTOS HASZNÁLATI ESETEK Az aktor a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől. A használati eset a rendszernek egy értelmes kerek egysége. A használati eset kívülről írja le a rendszer viselkedését, szolgáltatásait. Architektúrálisan fontosnak nevezzük azokat a használati eseteket, amelyek a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg. Ilyen architektúrálisan fontos használati eset a mikrohullámú sütő esetében a sütés, a számlázó estében a számla készítés, avagy a családfa felderítő esetében a családfa felderítése. Egy-egy alkalmazás esetében jellemzően egy, vagy csak néhány architektúrálisan fontos használati eset szokott lenni. Nagy, összetett rendszerek esetében ez az alrendszerek szintjén igaz. A használati esetek határozzák meg, hogy o mit fejlesztünk? (rendszerhatárok, funkcionalitás) o milyen sorrendbe fejlesszük? (prioritás) o milyen legyen a termékünk belső szerkezete (architektúra) május 14/58

15 HASZNÁLATI ESTEK, MINT RENDSZERHATÁROK A rendszer határát a rendszer által nyújtott, a felhasználó számára fontos funkciók adják. Azt kell kifejleszteni, amire a felhasználónak szüksége van. Nem többet és nem kevesebbet. 8. ábra A kulcsfontosságú használati estek rajzolják körül a rendszer szolgáltatás halmazát. A későbbiekben csak azok a szolgáltatások indokoltak, amik szervesen kapcsolódnak az architektúrálisan fontos használati esetekhez, s minden olyan igény, ami nincsen szerves kapcsolatban az architektúrálisan fontos használati esetekkel, azok rendszeridegenek, azokat egy másik alkalmazásban kell elhelyezni. Az alkalmazás is egy objektum: van egy, logikailag összefüggő, zárt felelősségi köre. Ne pakoljuk tele az alkalmazást fölösleges csingilingikkel! HASZNÁLATI ESTEK, MINT FUNKCIONALITÁS A rendszer teljes funkció-halmazát a fentebb említett a kulcsfontosságú használati esetek részletes lebontása, illetve az ezekhez tartozó kiegészítő, járulékos használati esetek adják. A rendszer feladata a felhasználó számára hasznos szolgáltatások nyújtása. Ebben a megközelítésben a használati esetek által nyújtott funkció térkép adja a rendszer külső szempontból való leírását. Ezek a használati esetek nagyban befolyásolják a rendszer másik négy nézetét is. A HASZNÁLATI ESETEK, MINT AZ ARCHITEKTÚRA MEGHATÁROZÓI 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 ESTEK PRIORITÁSAI MEGHATÁROZZÁK A FEJLESZTÉS PRIORITÁSAIT Általánosságban elmondható, hogy célszerű előbb megvalósítani a központi funkciókat, majd később foglalkozni a periférikus feladatokkal. Lényegestől, fontostól a kevésbé lényeges felé, a központtól a periférikus részek felé célszerű haladni a fej május 15/58

16 lesztéssel. Mind a műszaki, mind a piaci kockázatok jelentősen csökkenthetőek, a központi részek viszonylag korai kialakításával. Az architektúra AZ ARCHITEKTÚRA AZ ALKALMAZÁS JELLEGE ALAPJÁN 10 Az alkalmazás jellege (egyed, vagy kontroll, vagy határ dominanciájú alkalmazás) befolyásolja, hogy a tervezési modell mely sztereotípusai lesznek architektúrálisan meghatározóak. Control Entity Boundary 9. ábra Entitás dominanciájú alkalmazások Ezek a klasszikus információs rendszerek, fő feladatuk az adatkezelés. Az architektúrára lényeges hatással van a domain modell, illetve a perzisztens tárolás az esetek többségében ez SQL táblákat jelent. Megvalósítására további tervezési minták állnak rendelkezésre. Meglehetősen gyakori alkalmazás típus. Felület dominanciájú alkalmazások Jellegzetes desktop alkalmazások, szövegszerkesztők, kép-manipuláló programok, vizuális felhasználói környeztek, stb. Az architektúrát a határ jellegű elemek dominálják, az architektúra leírásánál a határ jellegű elemek osztály illetve együttműködés diagrammjai a mérvadóak, valamint a felhasználói felület prototípusa. Algoritmus dominanciájú alkalmazások Az architektúrát a megvalósítandó algoritmusok döntően befolyásolják. Meglehetősen ritkák fordulnak elő a napi fejlesztői gyakorlatban ilyen alkalmazások. Az iteratív és az inkrementális rendszerfejlesztés 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 megren- 10 Részletesebben lásd a szerző Architektúra tananyagában május 16/58

17 delő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. Kockázat Követelmény elemzés Tervezés Implementáció Tesztelés Átadás 10. ábra 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. Idő május 17/58

18 Kockázat Előkészítés Vízesés Kidolgozás Iteratív Építés Átadás 11. ábra Idő 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 május 18/58

19 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 rendseres 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 május 19/58

20 2. Az Egységesített Eljárás ábra: az Egységesített Eljárás szimbóluma Az Egységesített Eljárás áttekintése Az Egységesített Eljárás szoftverfejlesztési módszertan A fejlesztés célja a megrendelői, felhasználói igényeknek megfelelő szoftver rendszer előállítása megadott határidőre, megadott költség kereteken belül, s mindez jó minőségben. A megfogalmazott felhasználói igényekből a legritkább esetben vezethető le közvetlenül a teljes szoftver rendszer. A meghatározott peremfeltételek (minőség, határidő, költségek) rendszerint ellentmondanak egymásnak. Az Egységesített Eljárás, mint szoftverfejlesztési módszertan meghatározza, hogy ki, mit és mikor csináljon a közös cél érdekében, illetve ajánlásokat ad az ellentmondások feloldására. Felhasználói követelmények Sw. fejlesztési módszer 13. ábra Sw. rendszer Természetesen az Egységesített Eljárás nem több, mint egy forgatókönyv, ad ajánlásokat, ad módszereket de a fejlesztést élő, hús-vér személyek végzik, a konkrét fejlesztés sajátosságainak az ismeretében nekik kell dönteniük a felmerülő kérdésekben. Több, mint programozás módszertan foglalkozik szakterületi, üzleti modelle- 11 [Jacobson+99], [RUP2001A] május 20/58

21 zéssel, elemzéssel. Kevesebb, mint a klasszikus szervezéstudomány nem foglalkozik a reálfolyamatok újraszervezésével, racionalizálásával, csak a szoftver fejlesztésére koncentrál. Életciklus szerint teljes az első ötlet felmerülésétől a termék teljes haláláig végigkíséri a teljes életciklust, beleértve az újabb és újabb verziók kifejlesztését is. 12 Szakterület szerint alkalmas mindenféle szoftver termék fejlesztésére, nem csak információs rendszerek ( adatmasszírozó alkalmazások ) kifejlesztésére koncentrál. 13 Objektum-orientált módszertan, azaz a ma divatos, hatékony programozási paradigmával szinkronban van, nincs szükség szemléleti transzformációra, sőt a jelölésrendszer is azonos (UML). 14 Viszonylag fiatal módszertan, azaz számos helyen kiforratlan. Az Egységesített Eljárás szoftverfejlesztési jellegzetességei Szinte minden, az Egységesített Eljárással foglalkozó publikációban visszatér a módszertan jellemzéseként a RUP három legfontosabb jellegzetessége, s e jellegzetességek felsorolásában lényegében minden szerző egyetért. A hasonlat szerint a háromlábú szék egy-egy lába a módszertan egy-egy jellegzetessége: Használati eset vezérelt milyen célra? Architektúra központú mi a lényege? Iteratív és inkrementális hogyan? 14. ábra Az Egységesített Eljárás e három jellegzetessége egymást kölcsönösen feltételezi, egymás nélkül értelmetlenek a kisszéknek szüksége van mindhárom lábára, hogy stabilan álljon. További jellegzetességek: o Objektum-orientált 12 Az SSADM alig fordít figyelmet a tényleges megvalósításra, az implementációra, illetve az implementáció közeli tervezésre. 13 Az SSADM alapfeltevése, hogy információs rendszert építünk, van adatbázisunk, s az adatbázisunk megvalósítása relációs. Mindezeket a korlátokat az Egységesített Eljárás nem tartalmazza. 14 Az SSADM strukturált módszertan, azaz nem ismeri az oo szemlélet fogalmait, az SSADM tervet le kell fordítani oo tervre május 21/58