Egy informatikus jó esetben sokra értékeli, ha az őt körülvevő dolgok jól definiáltak, mert a szakmánk megköveteli ezt a fajta hozzáállást. Hogyan tudnánk elvégezni egy olyan feladatot, aminek a célkitűzései nem világosak? Vagy hogy tudnánk eldönteni, hogy a követelményeknek megfelelő munkát végeztünk-e, ha nincsenek is explicit követelmények? Ezt a szemléletmódot vési kőbe az IBM által kifejlesztett RUP, teljes nevén Rational Unified Process, amellyel legalább érintőlegesen sokan találkozhattunk már, de lehet, hogy néha mi magunk se tudjuk hova tenni. Mire jó a RUP? Miért van rá szükségünk egyáltalán?

A RUP egyféle megközelítése annak a célnak, ami röviden a szoftverfejlesztés strukturálásáról, a projekt menedzselhetővé tételéről és a hibák kiküszöböléséről szól. Viszont igenis megéri ezt a célt magunk elé is kitűzni, mert a kezdeti energia-ráfordítás sokszorosan térül meg – és ha ez a cél megvan, az odavezető utak közül választhatjuk a RUP-ot is.

Felmerülhet a kérdés, hogy a middleware-ről szóló blogon miért van erről szó. Valóban, nem függ össze szorosan a kettő, létezik middleware RUP nélkül és RUP middleware nélkül is. Viszont ha megnézzük, hogy mi motiválta és motiválja a middleware kialakulását és fejlődését, hasonló elvekre bukkanunk, mint amiken a RUP alapszik, ezen belül is talán a legfontosabb összekötő láncszem a skálázhatóság. Ahogy egy vállalat informatikai rendszerénél is fontosnak tartjuk, hogy a méret ne szabhasson határt a fejlődésnek, úgy a szoftverfejlesztés bármelyik területén elmondható, hogy nem szeretnénk, ha egy projekt a saját súlya alatt omolna össze. A RUP ugyanúgy elosztottságra épül, mint a szolgáltatásalapú architektúrák, és hasonlóképpen nem a részletekre, hanem az átfogó rendszerre összpontosít.

Nézzük hát, hogy mire is jó az IBM módszere.
 

1. Segít minimalizálni a hibák okozta kárt.

A RUP alapvetően iteratív fejlesztési stratégiát ír le. Minden iteráció során igyekszünk a projekt minden részével haladni, hogy aztán felmérjük, mennyire értük el a követelményben kitűzött célokat. Így időben tudunk változtatni a dolgokon, mielőtt túl késő lenne. Az unásig emlegetett épület-allegóriával: addig kell újjáépíteni a felhőkarcoló elrontott huszadik emeletét, amíg nem húztak fel rá még harmincat. Bármilyen közhelyes, mindannyian megtapasztaltuk már, mennyivel több munka utólag kijavítani egy banális tévedést, mint ha időben észbe kaptunk volna.

2. Becsülhetővé teszi a projekt erőforrásigényét.

Az egyik legfontosabb erőforrás az idő. Az iteratív fejlesztés azért is jó, mert ha tudjuk, hogy pl. az első iteráció tartott 2 hétig, és az előzetes tervek szerint 20 iteráció várható, akkor máris van egy durva becslésünk, miszerint a projekt 40 hetet vesz igénybe. És míg ez egy igen nagyvonalú megközelítés, nem szabad elfelejteni, hogy ahogy előrehaladunk a projektben, egyre pontosabbá válik ez a becslés. De a RUP nemcsak időben, hanem tevékenységek szerint is tagolja a projektet, megkülönböztetve kilencféle aktivitást, amelyekről bővebben egy későbbi bejegyzésben lesz szó.

3. Konkretizálja a célkitűzéseket.

Mikor van vége egy projektnek? Mikor lehet belekezdeni a kódolásba? Mire kell figyelni, és még fontosabb: mire nem szabad figyelni? Ezekre a kérdésekre mindig van válasz, ha a RUP szerint dolgozunk. A RUP meghatároz bizonyos mérföldköveket, amelyek az egyes fázisok végét jelentik, erről szintén egy későbbi bejegyzésben írok. És nem csak a fázisok elkülönítése a fontos itt, hanem hogy elkerüljük az idő- és erőforrásrabló fölösleges kitérőket. Mindig tisztában kell lenni azzal, hogy mi a követendő irány, így a lehető legtöbb vargabetűt levághatjuk. Persze sokszor nem lehet biztosan megmondani, hogy egy adott lépés szükséges-e, de ha a RUP szerint van felépítve a folyamat, akkor mindent megtettünk a hatékonyság érdekében, ami elvárható.

És hogy miért választanánk éppen ezt az utat? Egyszerűen azért, mert bevált. A keréknek vannak alternatívái, és sose haszontalan újabbakat kitalálni, de az állandó újrafelfedezésére semmi szükség.

A következő RUP-pal foglalkozó bejegyzésben, amint ígértem, a folyamat egyes elemeit nézzük meg részletesebben.

Ferenczy Péter