A Rational Unified Process (RUP) egy iteratív szoftverfejlesztési folyamat keretrendszer, amelyet a Rational Software Corporation, az IBM részlege hozott létre 2003-ban.

A RUP nem egy konkrét előíró folyamat, hanem egy adaptív folyamat keretrendszer, amelyet a fejlesztési szervezetek és a szoftverprojektek csapata szab meg, akik kiválasztják a folyamat elemeit, amelyek megfelelnek az igényeiknek. Megmutatja, hogy az egyes tervezési szakaszokban milyen feladatok vannak és ezeket a feladatokat milyen képzettségű embereknek kell kiosztani ahhoz, hogy a projektet sikeresen elemezzük, megtervezzük, implementáljuk és teszteljük. A módszertan célja az, hogy egy minőségi terméket tudjunk előállítani minél hamarabb, minél hatékonyabban és ellenőrizhető módon.

Története A Rational Software eredetileg az észszerű, egységes folyamat szoftver termékként lett kifejlesztve.. A termék tartalmaz egy hiperhivatkozással ellátott tudásbázist, minta-mellékletekkel és részletes leírásokkal a különféle tevékenységekhez. A RUP szerepel az IBM Rational Method Composer (RMC) termékben, amely lehetővé teszi a folyamat testreszabását.

Philippe Kruchten, a tapasztalt Rational műszaki képviselő feladata volt az eredeti RUP csapat vezetése. Ez a történet a Rational Objectory Process (ROP) létrehozásával kezdődött 1996-ban, amikor a Rational megszerezte az Objectory Process folyamatot, amelyet Ivar Jacobson és a cég írt. Ezt a későbbi kiadásokban Rational Unified Processre (RUP) nevezték át, részben annak érdekében, hogy a név összehangolódjon az Unified Modeling Language nevével.

Ezek a kezdeti verziók egyesítették a Rational Software szervezet kiterjedt területi tapasztalat-építési, objektumorientált rendszereit (amelyeket a Rational területi alkalmazottak Rational Approach-nak neveznek) az Objectory útmutatásaival olyan gyakorlatokról olvashatunk , mint például használati esetek, és beépítették a Jim Rumbaugh: Object Modeling Technology (OMT) kiterjedt tartalmát. ) modellezési megközelítés, Grady Booch Booch módszerét és az újonnan kiadott UML 0.8-at .

Annak érdekében, hogy ez a növekvő tudásbázis hozzáférhetőbbé váljon, Philippe Kruchtennek megbízást kapott egy modern szoftver-tervezés kifejezett keretrendszerének összeállítására. Ez az erőfeszítés az Objectory által kifejlesztett HTML-alapú folyamat-közlési mechanizmust alkalmazta. Az így kapott "Rational Unified Process" (RUP) stratégiai állványt készített a Rational számára:

testreszabható folyamat, amely a fejlődést irányította eszközök, amelyek automatizálták a folyamat alkalmazását szolgáltatások, amelyek felgyorsították mind a folyamatot, mind az eszközöket. Ezt az útmutatást a későbbi verziókban kiegészítették a Rational által megszerzett vállalatok tapasztalatain alapuló ismeretekkel.

1997-ben követelményeket és tesztelési diszciplínákat egészítették ki , és a kiegészítő anyagok nagy részét a Dean Leffingwell et al. Által kidolgozott Requirements College módszerrel nyerték. és a SQA Inc. által kifejlesztett SQA Process módszerrel, mindkét társaságot a Rational Software megszerezte.

1998-ban a Rational Software két új tudományágat adott hozzá:

üzleti modellezés, ennek a tartalomnak a nagy része már az Objectory folyamatban volt egy konfigurációs és változáskezelési szakirány, amelyet a Pure Atria Corporation megvásárlásával vezettek be.

Ezek a kiegészítések átfogó alapelvekhez vezetnek, amelyeket a Rational meghatározott és a RUP-en belül a modern szoftverfejlesztés hat legjobb gyakorlataként fogalmazott meg:

Fejlesztés iteratív módon, a kockázat mint elsődleges iterációs hajtóerő Kezelje a követelményeket Használjon komponens-alapú architektúrát A szoftver modellje vizuális Folyamatosan ellenőrizze a minőséget Vezérlő változások

Ezeket a bevált gyakorlatokat szorosan összehangolták a Rational termékcsaládjával, és mindkettő elősegítette a Rational termékek folyamatos fejlesztését, valamint a Rational helyszíni csapata felhasználta őket arra, hogy az ügyfelek javítsák szoftverfejlesztési erőfeszítéseik minőségét és kiszámíthatóságát.

Kiegészítő technikák, ideértve a teljesítmény tesztelését, az UI tervezését, az adatgyűjtést, valamint egy frissítést, amely tükrözi az UML 1.1 változásait.

1999-ben bevezették a projektmenedzsment szakterületet, valamint technikákat valósidejű szoftverfejlesztés támogatására és az UML 1.3 tükrözésére szolgáló frissítéseket. Emellett ugyanebben az évben jelent meg a folyamatot leíró első könyv, az Egységes szoftverfejlesztési folyamat ().

2000 és 2003 között számos változtatás lett bevezetve az iteratív fejlesztéssel kapcsolatos folyamatos Rational tapasztalatok útmutatásai, a RUP-példányok bevezetésének és a RUP-keret testreszabásának eszköz-támogatása mellett. Ezek a változások magukban foglalják:

fogalmak és technikák bevezetése olyan megközelítésekből, mint az eXtreme Programming (XP), amelyeket később együttesen agilis módszereknek is neveznek. Ez olyan technikákat tartalmazott, mint a páros programozás, a teszt az első tervezési minta és a papírok, amelyek elmagyarázták, hogy a RUP miként tette lehetővé az XP méretarányát nagyobb projektekben történő felhasználáshoz. a tesztelési tudományág teljes átalakítása annak érdekében, hogy jobban tükrözze a tesztelési munka elvégzését különböző iteratív fejlesztési kontextusokban. támogató útmutatások bevezetése - az úgynevezett "szerszámmentorok" - a RUP gyakorlatok különböző eszközökben történő bevezetésére. Ezek alapvetően lépésről lépésre támogatják a Rational eszköz felhasználóit. automatizálja a RUP testreszabását oly módon, hogy az ügyfelek választhassanak alkatrészeket a RUP folyamatrendszeréből, testreszabhassák kiválasztását a saját kiegészítésekkel, és a továbbfejlesztéseket beépítsék a Rational későbbi kiadásaiba.

Az IBM 2003 februárjában vásárolta meg a Rational szoftvert.

2006-ban az IBM létrehozta az Agile projektek kézbesítésére szabott RUP-alcsoportot, amelyet OpenSource módszerként, OpenUP néven jelentettek meg az Eclipse weboldalon keresztül.

Észszerű, egységes folyamattematika

RUP építőelemek A RUP építőelemeken és tartalomelemeken alapul, amelyek leírják, mit kell előállítani, a szükséges készségeket és a lépésről lépésre történő magyarázatot, amely leírja, hogyan kell elérni a konkrét fejlesztési célokat. A fő építőelemek vagy tartalomelemek a következők:

Szerepek (ki?) - A szerep meghatározza a kapcsolódó készségeket, kompetenciákat és felelősségeket. Munkatermékek (mi) - A munkatermék valamely feladat eredményeként jelent meg, beleértve az összes dokumentumot és modellt, amely a folyamat során létrejön. Feladatok (hogyan?) - egy feladat egy Szerephez rendelt munkaegységet ír le, amely értelmes eredményt ad. Az iteráción belül a feladatokat kilenc tudományterületre osztják:

Hat "mérnöki tudományág" Üzleti folyamatok elemzése (Business Modeling) Követelmények elemzése (Requirements) Elemzés és tervezés (Analysis & Design) Implementáció (Implementation) Tesztelés (Test) Átadással kapcsolatos tevékenységek(Deployment) Három támogató tudományág Konfiguráció és változáskövetés (Configuration & Change Management) Projektvezetés (Project Management) Fejlesztői környezet felállítása ( Environment)

Négy projekt életciklus-szakasz Az RUP meghatározta a négy szakaszból álló projekt életciklusát. Ezek a szakaszok lehetővé teszik a folyamat magas szintű bemutatását, hasonlóan ahhoz, ahogyan egy „vízesés” stílusú projekt bemutatható, bár lényegében a folyamat kulcsa a fejlődés iterációiban rejlik, amely az összes szakaszban megtalálható.

Ezenkívül minden szakasznak van egy kulcsfontosságú célja és mérföldköve a végén, amely jelzi a megvalósítandó célt. A RUP fázisok és tudományágak időbeli megjelenítését RUP púpdiagramnak nevezzük.

Előkészítés Az elsődleges cél a rendszer megfelelő kiterjesztése a kezdeti költségek és a költségvetés érvényesítésének alapjául. Ebben a szakaszban az üzleti eset, amely magában foglalja az üzleti környezetet, a sikertényezőket (várható bevétel, piaci elismerés stb.) És a pénzügyi előrejelzést.

Az üzleti eset kiegészítésére elkészítjük az alapvető használati modellt, a projekt tervet, a kezdeti kockázatértékelést és a projekt leírását (a projekt alapvető követelményei, korlátozások és főbb jellemzők). Ezek befejezése után a projektet a következő kritériumok alapján ellenőrzik:

Az érintettek egyetértése a hatály meghatározásával és a költség / ütemterv becsléseivel. A követelmények megértése, amelyet az elsődleges felhasználási esetek bizonyítanak. A költség / ütemterv becsléseinek, prioritásainak, kockázatainak és fejlesztési folyamatának hitelesítése. Prototípus kifejlesztése Kiindulási alap létrehozása a tényleges kiadások és a tervezett kiadások összehasonlításához.

Ha a projekt nem teljesíti ezt a mérföldkövet, az életciklus-célkitűzés mérföldkövét, akkor azt meg lehet szüntetni vagy megismételni, miután újratervezték, és megfelel a kritériumoknak. bélyegkép|275x275px|RUP-folyamatok

Kidolgozás Elsődleges cél az elemzéssel azonosított legfontosabb kockázati tételek enyhítése e szakasz végéig. A kidolgozási szakaszban kezdődik a projekt kialakulása. Ebben a fázisban elkészül a problémakör elemzése, és a projekt architektúrája megkapja alapvető formáját.

A kidolgozási szakasz eredménye:

Olyan használati eset modell, amelyben a felhasználási eseteket és a szereplőket azonosították, és a legtöbb felhasználási eset leírást kidolgozták. A felhasználási eset modelljének 80% -ban teljesnek kell lennie. A szoftver-architektúra leírása a szoftverrendszer-fejlesztési folyamatában. Végrehajtható architektúra, amely megvalósítja felépítésében jelentős felhasználási eseteket. Felülvizsgált üzleti eset- és kockázatlista. A teljes projekt fejlesztési terve. Prototípusok, amelyek bizonyítottan csökkentik az egyes azonosított műszaki kockázatokat. Előzetes felhasználói kézikönyv (opcionális)

Ennek a szakasznak meg kell felelnie az életciklus-architektúra mérföldkő kritériumainak, válaszolva a következő kérdésekre:

A termék kinézete stabil? A felépítése stabil? A végrehajtható demonstráció azt jelzi, hogy a fő kockázati elemekkel foglalkoznak és megoldódnak? Az építési szakasz terve elegendően részletes és pontos? Valamennyi érdekelt fél egyetért azzal, hogy a jelenlegi elképzelés a jelenlegi terv felhasználásával valósítható meg a jelenlegi felépítés összefüggésében? Elfogadhatóak-e a tényleges és a tervezett erőforrás-kiadások?

Ha a projekt nem tudja meglépni ezt a mérföldkövet, akkor még van ideje annak visszavonására vagy újratervezésére. E szakasz elhagyása után azonban a projekt nagy kockázattal járó műveletre vált át, ahol a változtatások sokkal nehezebbek és károsak is lehetnek.

A kidolgozás kulcsfontosságú a domain elemzéséhez a rendszer architektúrájával.

Megvalósítás Az elsődleges cél a szoftverrendszer felépítése. Ebben a szakaszban a fő hangsúly a rendszer komponenseinek és egyéb tulajdonságainak fejlesztésére összpontosít. Ebben a szakaszban történik a kódolás nagy része. Nagyobb projektekben több építési iterációt lehet kidolgozni annak érdekében, hogy a felhasználási eseteket kezelhető szegmensekre bonthassák, és megfelelő prototípusokat állítsanak elő.

Átadás Az elsődleges cél a rendszernek a fejlesztésről a termelésre történő átvitele, hozzáférhetővé tétele és a végfelhasználó számára történő megértése. E szakasz tevékenységei között szerepel a végfelhasználók és karbantartók képzése, valamint a béta tesztelése a rendszerrel, hogy érvényesítsék azt a végfelhasználók elvárásaival szemben.

A rendszer egy értékelési szakaszon is keresztül megy, minden olyan fejlesztőt kicserélnek vagy eltávolítanak, amely nem készíti el a szükséges munkát. A terméket a kezdő szakaszban beállított minőségi szinttel is összevetik.

Ha az összes cél teljesül, akkor a termék kiadási mérföldköve teljesül, és a fejlesztési ciklus befejeződik.

Az IBM Rational Method Composer termék