Rational Unified Process a szoftvertesztelésben
A Rational Unified Process (RUP) módszertan az objektumorientált megközelítést használja a tervezés során, és az UML (Unified Modeling Language) jelölés használata a folyamatok működésének bemutatására szolgál. Kereskedelmi szempontból bevált technikákat és gyakorlatokat használ.
Ezt a folyamatot nehézkesnek és lehetőleg nagy fejlesztőcsapatok és nagy projektek esetében alkalmazhatónak tekintik, de az a tény, hogy széleskörűen testreszabható, lehetővé teszi, hogy bármilyen léptékű projektekhez alkalmazkodjon.
Specifikumok
A projektmenedzsment számára a RUP(Rational Unified Process) modell olyan fegyelmezett megoldást nyújt, mint a szoftverfejlesztési szervezeten belül körvonalazódó feladatok és felelősségek.
A RUP (Rational Unified Process) önmagában egy szoftvertermék. Moduláris és automatizált, és a teljes módszertanát számos fejlesztési eszköz támogatja, amelyeket az IBM integrált és értékesít a “Rational Suites”-en keresztül.”
A szoftverfejlesztés területén a versenyben lévő módszerek közé tartoznak a “tiszta szobák” (nehéznek tekintett) és az agilis (könnyű) módszerek, mint például az extrém programozás (XP-Extreme Programming), a Scrum, az FDD és mások.
Vannak bizonyos irányelvek és sablonok, amelyeket a RUP határoz meg, egy termelési ciklus munkatársai számára: az ügyfél egy része és a projekt előrehaladásának értékelése a vezetőség által. Ez segít a fejlesztőknek abban, hogy a projektre összpontosítsanak.
Vezetési követelmények
A megfelelő dokumentáció minden nagyszabású projekthez elengedhetetlen; vegye figyelembe, hogy a RUP leírja, hogyan kell dokumentálni a funkcionalitást, a rendszer korlátait, a tervezési korlátozásokat és az üzleti követelményeket.
A használati esetek és a forgatókönyvek példák a függő folyamatok műtárgyaira, amelyeket sokkal hatékonyabbnak tartanak a funkcionális követelmények rögzítésében.
A komponensalapú architektúra használata
A komponensalapú architektúra olyan rendszert hoz létre, amely könnyen bővíthető, elősegíti az újrafelhasználást és a szoftver intuitív megértését. A komponens általában egy objektumra utal az objektumorientált programozásban.
A RUP szisztematikus módot biztosít az ilyen típusú rendszer kiépítésére, a projekt korai szakaszában, azaz az erőforrások nagymértékű lekötése előtt egy végrehajtható architektúra létrehozására összpontosítva.
Az itt említett komponensek általában a helyben már meglévő infrastruktúrák részét képezik. Ezek az infrastruktúrák közé tartozik a CORBA, valamint a Component Object Model (COM).
A vizuális szoftvermodellek használata a RUP modellben
A kód programozásának absztrahálásával és grafikus építőelemek segítségével történő ábrázolásával a RUP hatékony módja lehet a megoldás áttekintésének.
A vizuális modellek használata azt is lehetővé teheti, hogy a kevésbé műszaki profilú személyek (mint az ügyfelek) jobban megértsenek egy adott problémát, és így jobban részt vehessenek a projekt egészében.
Az UML modellezési nyelv a projektek ábrázolásának ipari szabványává vált, és a RUP széles körben használja!
Tudjon meg többet! Olvassa el az Agilis tesztelés exkluzív részleteit
Szoftverminőség ellenőrzése
Nem biztosítja a szoftver minőségét a leggyakoribb hiba minden számítógépes rendszerprojektben. Általában a projektek befejezése után gondolunk a szoftver minőségére, vagy a minőségért egy másik fejlesztőcsapat felel.
A szoftverek változásainak kezelése és ellenőrzése
Minden szoftverprojektben elkerülhetetlen a változás megléte. A RUP módszereket határoz meg a változások irányítására és ellenőrzésére. Mivel egy apró változás teljesen kiszámíthatatlan módon befolyásolhatja az alkalmazásokat, a változások ellenőrzése elengedhetetlen a projekt sikeréhez.
A RUP (Rational Unified Process)meghatározza a munka és a biztonság területeit is, ami garantálja a programozónak, hogy egy másik rendszerben bekövetkező változások nem befolyásolják az Ön rendszerét.
A RUP-módszertan fázisai
Ezidáig ezek az irányelvek általánosak, betartva kell végigmenni egy projektciklus életén. A fázisok (lásd az alábbi ábrát) jelzik, hogy egy adott pillanatban milyen hangsúlyt kap a projekt. A projekt időbeli dimenziójának megragadására a RUP négy különböző fázisra osztja a projektet:
Iniciation or Design: a rendszer terjedelmének hangsúlyozása;
Preparation: az architektúrára való hangsúlyozás;
Construction: a fejlesztésre való hangsúlyozás;
Transition: az alkalmazásra való hangsúlyozás.
A RUP is a 4 P-n alapul:
- People
- Design
- Product
- Process
A rétegek iterációkból állnak. Az iterációk időablakok; az iterációk határozták meg a fogalmat, mivel a fázisok objektívek.
Minden fázis artefaktumokat generál. Ezeket a következő fázisban használják fel, és dokumentálják a projektet, valamint lehetővé teszik a jobb nyomon követést.
Tervezési fázis
A tervezési vagy kezdeményezési fázis tartalmazza azokat a munkafolyamatokat, amelyek ahhoz szükségesek, hogy az érdekelt felek – az érdekeltek – megállapodjanak a projekt céljaival, architektúrájával és tervezésével. Ha ezek a szereplők jó ismeretekkel rendelkeznek, nem lesz szükség elemzésre. Ellenkező esetben részletesebb elemzésre van szükség.
Ebben a szakaszban a rendszer alapvető követelményeit használati esetekké alakítják át. A cél az, hogy ezeket egyáltalán ne zárjuk le, hanem csak azokat, amelyek a vélemény kialakításához szükségesek.
A lépés általában rövid, és annak meghatározására szolgál, hogy megvalósítható-e a projekt folytatása, valamint az utolsó lépés kockázatainak és költségeinek meghatározására. Elkészíthető egy prototípus, amelyet az ügyfélnek jóvá kell hagynia. Ahogy a RUP idézi, az ideális az iterációk elvégzése, amelyeknek mennyiségüket és céljaikat tekintve jól meghatározottnak kell lenniük.
Elkészítési fázis
A rendszer tervezésének előkészítése, a használati esetek felmérésének és/vagy dokumentálásának kiegészítéseként, a rendszer architektúrája előtt, a projekt üzleti modelljének áttekintése és a felhasználói kézikönyv változatának megkezdése. El kell fogadni: A termékleírás (növekedés + integráció) stabil; a projektterv megbízható? A költségek támogathatóak?
Konstrukciós fázis
A konstrukciós fázisban megkezdődik a szoftver fizikai fejlesztése, a gyártási kódok, az alfa tesztek. Az átmeneti fázis elején béta teszteket végeztek.
A teszteket el kell fogadni, stabil és tesztelési folyamatok, és a rendszer kódja “alapvonal”.
Átmeneti fázis
Ez a fázis a szoftver szállítása (“deployment”), amely elvégzi a telepítési és szállítási tervet, a felügyeletet és a szoftver minőségét. A termékek (kiadások, verziók) leszállítása, és az ügyfél elégedettségének elhelyezése. Ebben a szakaszban kerül sor a felhasználók képzésére is.
A RUP (Rational Unified Process) módszertan diszciplínái
Az üzleti modellezés diszciplínája
A szervezetek egyre inkább függnek az informatikai rendszerektől, ezért elengedhetetlen, hogy az informatikusok tudják, hogyan integrálódnak az alkalmazások a szervezet fejlesztésébe. A vállalatok olyan informatikába fektetnek be, amely megérti a technológia által hozzáadott értékből származó versenyelőnyt.
Az üzleti modellezés célja először is az üzleti tervezés és a szoftverfejlesztés közötti jobb megértés és kommunikáció kialakítása.
Az üzlet megértése azt jelenti, hogy a szoftvermérnököknek meg kell érteniük a célvállalat (az ügyfél) felépítését és dinamikáját, a szervezet jelenlegi problémáit és a javítás lehetséges módszereit és stratégiáit.
Egy másik fontos szempont, amelyet nem szabad aláásni, hogy az érintett feleknek, például a fejlesztőknek, valamint az ügyfeleknek és a végfelhasználóknak is világos ismeretekkel kell rendelkezniük a szervezetről, és ennek a megértésnek fontos jellemzője, hogy az összes érintett félnek közösnek kell lennie.
Az üzleti modellezés elmagyarázza, hogyan kell leírni egy olyan szervezet jövőképét, amelyben a rendszert bevezetik, és hogyan lehet ezt a jövőképet alapul venni a folyamatok, funkciók és felelősségek leírásához.
Követelmények
Ez a kurzus elmagyarázza, hogyan lehet az érdekelt felektől (“érdekelt felek”) igényeket szerezni, és azokat olyan követelményrendszerré alakítani, hogy a termékek a megépítendő rendszerben működjenek, és hogyan lehet a rendszerhez szükséges részletes követelményeket biztosítani.
A szakterület elemzése és tervezése (“tervezés”)
Az elemzés és tervezés célja, hogy megmutassa, hogyan fog megvalósulni a rendszer. A cél egy olyan rendszer létrehozása, amely:
Elvégzi egy adott végrehajtási környezetben a használati esetek leírásában meghatározott feladatokat és funkciókat
Elégíti az összes igényt
Egyszerűen karbantartható, ha nem változnak a funkcionális követelmények, a projekt eredményei egy elemzési és tervezési modellben opcionálisan egy elemzési modellel rendelkezik.
A tervezési modellt a forráskód koncepcionális változataként hasznosítják, csak a legszükségesebbeket jeleníti meg. Ez lehetővé teszi, hogy bármelyik ellenőrzést végző felhasználó megállapítsa, hogy a forráskód milyen stílusban került megjelenítésre.
A tervezési modell úgy kerül megjelenítésre, hogy a tervek különböző felosztásait tartalmazza. Ezek a felosztások meghatározott alrendszereken belül vannak tárolva.
Minden alrendszernek van egy különálló, pontosan megtervezett interfésze. Tartalmazza továbbá annak leírását, hogy az ezekben az osztályokban lévő objektumok hogyan működnek együtt a használati esetek tervezésének megvalósítása érdekében.
A diszciplína megvalósítása
Az alkalmazás hatásai:
- Az alkalmazáshoz szervezett rétegzett alrendszerekre való hivatkozással a szervezési kódot konfigurálják.
- A komponensek különböző osztályai vagy felosztásai valósulnak meg. Ezek a komponensek közé tartoznak
- A forrásfájlok
- Végrehajtható fájlok és
- Binárisok
- Az egységekként kifejlesztett komponenseket tesztelik
Az egyes végrehajtók (vagy csoportok) által előállított eredményeket egy végrehajtható rendszerbe foglalják. A rendszerek az alkalmazás összetevőin keresztül valósulnak meg.
A folyamat célja egy fontos funkció ellátása, azaz a felhasználandó eljárás pontos meghatározása annak érdekében, hogy a már meglévő vagy frissen bevezetett komponenseket újra felhasználják.
Ez lehetővé teszi a rendszer karbantartásának könnyebbségét és a komponensek felhasználási esélyeinek jelentős javulását.
Fegyelmi tesztelés
A fegyelmi tesztelés céljai a következők:
- Az objektumok közötti kölcsönhatás ellenőrzése
- A szoftverkomponensek helyes integrációjának ellenőrzése
- A követelmények helyes végrehajtásának ellenőrzése
- A hibák azonosítása és a hibák kezelésének biztosítása a szoftver megvalósítása előtt
- A hibák kijavításának biztosítása, felülvizsgálják és lezárják
Következtetés
Ha a projektben vannak hibák, azok kijavítása felesleges költségeket igényelhet, mivel a hibák nem kerülnek időben napvilágra.
Ha azonban a projektet teljes egészében tesztelik, az előnyös, mivel a projektekbe esetlegesen belopakodó hibák a legkorábban azonosíthatók és megállapíthatók.
Ez viszont a hibák kijavításával járó költségek hatalmas csökkenésével jár. Ez a Rational Unified Process által javasolt iteratív megközelítés.
Azért, hogy a tesztelés meghozza gyümölcsét és a lehető legjobb eredményt hozza, a teszteket négy minőségi paraméter alapján kell elvégezni, és meghatározott szabványoknak is meg kell felelni ahhoz, hogy a projektet úgy lehessen tekinteni, mint ami átment a teszten.