Rational egységes fejlesztési módszer

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:

1. Fejlesztés iteratív módon, a kockázat mint elsődleges iterációs hajtóerő
2. Kezelje a követelményeket
3. Használjon komponens-alapú architektúrát
4. A szoftver modellje vizuális
5. Folyamatosan ellenőrizze a minőséget
6. 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 (ISBN 0-201-57169-2).

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:

1. 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.
2. 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.
3. 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.
4. 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.

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

Az IBM Rational Method Composer termék eszköz a folyamatok készítéséhez, konfigurálásához, megtekintéséhez és közzétételéhez. További részletek: IBM Rational Method Composer és egy nyílt forráskódú Eclipse Process Framework (EPF) projekt.

Tanúsítvány

2007 januárjában megjelent az IBM Rified Unified Processer - Rational Unified Process 7.0 RUP tanúsító vizsga, amely felváltja az IBM Rational Certified Specialist - Rational Unified Process tanfolyam korábbi verzióját. Az új vizsga nem csak a RUP-tartalommal kapcsolatos ismereteket próbálja ki, hanem a folyamatszerkezeti elemeket is.

Az új RUP tanúsítási vizsga teljesítéséhez a személynek el kell végeznie az IBM Test 839: Rational Unified Process v7.0 tesztet. 75 percet kap az 52 kérdéses vizsgára. A sikeres eredmény 62%-tól kezdődik.

A hat legjobb gyakorlat

A hat legjobb szoftverfejlesztési gyakorlat került meghatározásra a szoftverprojektek számára a hibák minimalizálása és a termelékenység növelése érdekében. Ezek:

Iteratív fejlesztés

A legjobb, ha az összes követelményt előre ismerik; azonban gyakran nem erről van szó. Számos szoftverfejlesztési folyamat létezik, amelyek megoldások bizonyításával foglalkoznak a fejlesztési szakaszok költségeinek minimalizálása érdekében.

Követelmény kezelés

Mindig tartsa szem előtt a felhasználók által támasztott követelményeket.

Komponensek használata

Egy fejlett projekt lebontása nemcsak javasolt, hanem valójában elkerülhetetlen. Ez elősegíti az egyes részek tesztelésének képességét, még mielőtt azok nagyobb rendszerbe integrálódnának. A kód újrahasznosítása szintén plusz munka, és így objektumorientált programozással könnyebben megvalósítható.

Modell vizualizáció

A diagramok segítségével ábrázolhatjuk az összes fő összetevőt, a felhasználókat és azok interakcióját. Az "UML", az Unified Modeling Language rövidítése, az egyik eszköz, amely ezt a feladatot megvalósíthatóbbá teszi.

Minőség-ellenőrzés

Mindig tesztelni kell a projektet. A tesztelés a projekt előrehaladtával nehezebbé válik, de állandó tényezőnek kell lennie minden szoftver termék létrehozásában.

Változtatások ellenőrzése

Sok projektet sok csapat készít, néha különböző helyszíneken, különböző platformokat lehet használni, stb. Ennek eredményeként alapvető fontosságú annak ellenőrzése, hogy a rendszerben végrehajtott változtatásokat folyamatosan szinkronizálják és ellenőrzik. (Lásd a folyamatos integrációt).

További irodalom

• • Ivar Jacobson, Grady Booch, and James Rumbaugh (1999). The Unified Software Development Process
  • Gary Pollice, Liz Augustine, Chris Lowe, and Jas Madhur (2003). Software Development for Small Teams: A RUP-Centric Approach
  • Per Kroll, Philippe Kruchten (2003). Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP
  • Per Kroll, Bruce Mac Isaac (2006). Agility and Discipline Made Easy: Practices from OpenUP and RUP
  • Philippe Kruchten (1998). The Rational Unified Process: An Introduction
  • Ahmad Shuja, Jochen Krebs (2007). RUP Reference and Certification Guide
  • Walker Royce, Software Project Management, A Unified Framework

Források

• Kusper Gábor: Programozási technológiák