Rational egységes fejlesztési módszer

A Wikipédiából, a szabad enciklopédiából

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[szerkesztés]

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 Process (RUP) néven 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, objektum-orientá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, az OpenUP néven jelentettek meg az Eclipse weboldalon keresztül.

Észszerű, egységes folyamattematika[szerkesztés]

RUP építőelemek[szerkesztés]

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[szerkesztés]

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[szerkeszté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[szerkeszté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[szerkeszté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[szerkeszté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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

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[szerkeszté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[szerkesztés]

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

Komponensek használata[szerkesztés]

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 objektum-orientált programozással könnyebben megvalósítható.

Modell vizualizáció[szerkesztés]

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[szerkeszté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[szerkesztés]

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[szerkesztés]

    • 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

Jegyzetek[szerkesztés]

Források[szerkesztés]

  • Kusper Gábor: Programozási technológiák[1]
  1. Kusper Gábor - Programozási technológiák. (Hozzáférés: 2020. június 12.)