Cím:
1133 Budapest,
Kárpát u. 2/a. III/43.

Telefon:
(36-1) 450-2460

Fax:
(36-1) 450-2469

E-mail:
rdsystems@rdsystems.hu

Oracle Designer Repository felhasználása fejlesztési projektek
követésére és saját adatok tárolására

Egy összetettebb fejlesztési projekt során rengeteg olyan információ és dokumentum születik, amelyet valamilyen formában meg kell őrizni. Igaz ez a fejlesztést végző és a fejlesztést végeztető félre egyaránt. Az sem mellékes, hogy ezeket a dokumentumokat, bár a projekt más és más szereplője (projektvezető, szervező, programozó, tesztelő stb…) készíti, úgy kell tárolni, hogy az együtt dolgozó munkatársak mindegyike hozzáférjen a megfelelő anyagokhoz. Gondolunk itt a felmérés során keletkezett emlékeztetőktől, jegyzőkönyvektől a logikai, fizikai tervezés és kivitelezés (programozás, tesztelés) dokumentumain keresztül, egészen a bevezetési dokumentumok, valamint a működés során végzett support (hibajavítás, módosítás) írásos anyagaira.

A feladat megoldásának egyik szokásos és egyszerű módja, hogy a hálózati szerveren kialakítunk egy megfelelően tagolt könyvtár struktúrát, és ott tároljuk az adott projekthez kapcsolódó dokumentumokat. Ha valaki már végigvitt (akár vállalkozó, akár megrendelő oldalról) egy összetettebb fejlesztési projektet, tudja, hogy a kezdeti időszak rendjét előbb vagy utóbb felváltja a dokumentum-káosz, és nincs arra mód, hogy időrendi sorrendben áttekintsük a projekt állását, dokumentumait. A különböző megoldás-változatok dokumentumainak, a programverziók nyilvántartásának kezelése pedig szinte lehetetlen. A tapasztalatok szerint már egy 100-200 programból álló rendszer moduljainak állapotát (pl. készültségi fokát) naprakészen tartani is jelentős adminisztrációs feladatot jelent, amelyre a projektek időben történő előrehaladtával egyre kevesebb idő jut.

Nem elhanyagolható szempont az sem, hogy munka minőségének biztosítása is megköveteli (megkövetelné) a történések követhetőségét. Csak valóban nagy szervezetek, valóban nagy projektjei mellett áll igazi minőségi felügyelet, ahol több-kevesebb sikerrel betartatják a minőség ezen követelményét. Tekintettel arra, hogy a projektek mellé kinevezett minőségbiztosítók az esetek többségében nem IT szakemberek, nem nehéz őket - általuk nem érthető - informatikai "mellébeszéléssel" átejteni úgy, hogy észre sem veszik a lazaságot. Ez pedig sem a vállalkozónak, sem a megrendelőnek nem jó, mert rengeteg energiát, időt és ebből adódóan pénzt lehetne megtakarítani, ha a fejlesztési projekt minden mozzanata követhető és átlátható lenne.

Nagyobb fejlesztési projekt esetén előfordulhat, de nem jellemző, hogy az igény megfogalmazása (felhasználó, szervező, programozó, tesztelő oldalról egyaránt) kizárólag "fülbe súgással" történjék. Minden esetben születik valamiféle írásos anyag, és a megszületett dokumentum kapcsolódik a projekt valamelyik eleméhez (igény megfogalmazás, szervezői instrukció, programozói vélemény, tesztelői tapasztalat, hibabejelentés stb…), csak rendszerezésük és nyilvántartásuk nem megoldott.

A Oracle Designer által biztosított lehetőségek, és néhány alkalmazás

Ma már az ORACLE alapon fejlesztő vállalkozók mind ORACLE partnerek is egyben. Az ORACLE üzletpolitikája pedig lehetővé teszi számukra, hogy szinte minden olyan tervező és fejlesztő eszközzel rendelkezzenek, amelyre szükségük van. Ezek közé tartozik a Designer is, amely a tervezés és a kivitelezés eszköze egyaránt. Lehet, hogy tervezésre, kivitelezésre nem ezt az eszközt használják, de a partneri csomagban rendelkezésükre áll. Valójában ez az eszköz az, amelynek a Repository része (ma már egy külön termék) biztosíthatja a fejlesztési projektek követését.

Azoknál a vállalkozásoknál, ahol a fejlesztéshez is az Oracle Designer eszközt használják, ott adott, hogy az információk, dokumentumok mellett a fejlesztés többi adatait is itt tároljuk, de ez nem előfeltétele a Repository használatának a projektek követésében, mivel mód és lehetőség van a Repository "testre szabásának", új elemek új tulajdonságok felvételének, a meta-modell megváltoztatásának. Minden elemhez 20 új tulajdonságot lehet felvenni, de gyakorlatilag bármennyi új elemet is létrehozhatunk. Ezeket az új elemeket tetszőlegesen köthetjük a már meglévő, másik, Designer elemekhez. A Repository Reports eszközben lehetőség van saját listák felvételére, és ezzel az eszközzel lehet elkészíteni a különböző lekérdezést biztosító listákat, amelyekre még kitérünk.

A Designer kínálta lehetőséget felismerve és kihasználva, fokozatosan jutottunk el azokhoz a megoldásokhoz, amelyeket először fejlesztési "segédeszközként", majd ISO szabványként definiáltunk a saját fejlesztési, projektvezetési munkánkban.
Három egyszerű példa arra, hogy a többéves fejlesztői tapasztalatokból kiindulva milyen megoldásokat tartottunk szükségesnek, és hoztunk létre. Ezek a megoldások nem elsősorban a projekt követést illusztrálják, hanem a fejlesztői munka színvonalának emelését és könnyítését céloztuk meg velük, de gyakorlati hasznuk az elmúlt évben egyértelműen beigazolódott.

Jegyzetlapok, melyet a support során használunk

A fejlesztett alkalmazásokról a felhasználók bejelentéseket tehetnek, telefonon vagy írásban. A bejelentéseket fogadó munkatárs a megfelelő alkalmazáshoz (modulhoz) csatolva felrögzíti az információt, illetve az információ tulajdonságait. Ezzel az eljárással gyakorlatilag biztosítani tudjuk, hogy az adott modul (program) support során átvezetett változtatásait időrendben követni tudjuk. Ezekről a jegyzetlapokról különböző listákat tudunk készíteni az általunk meghatározott adattartalommal.

Javaslatok felvétele

A fejlesztő munkatársaknak a munkavégzés során sok olyan fejlesztési ötletük van, amit akkor éppen nincs idő, vagy lehetőség elmondani, illetve másokkal is megvitatni. A "Javaslatok" panelben ezeket lehet felírni. Az összegyűlt javaslatokat fejlesztőink rendszeres időközönként megvitatják és értékelik. Azok a javaslatok, amelyek "arra érdemesek" bekerülnek a fejlesztési konvenciók közé, és attól kezdve alkalmazásuk a konvenciókhoz hasonlóan minden fejlesztő számára kötelezővé válik. Ebben az esetben is lehetőség van egy általunk megírt céllista nyomtatására a Repository Reportsból.

Modul paraméterek

Ebben a megoldásban a modulhoz rendelt paraméterek tulajdonságait bővíthetjük olyan adattartalommal, amely a modulparaméter táblába szükségesek. A Repositoryból a fizikai adatbázisba egy általunk írt "paraméter generátor" segítségével kerül a bővítés, amellyel jelentős programozási munkát takarítunk meg.

Fejlesztési munkalapkezelés (fejlesztési projektirányítás és követés)

Ezzel a megoldással gyakorlatilag meg lehet oldani a projekt irányításának és követésének a feladatait.
Minden "modulhoz" (programhoz) munkalapokat lehet rendelni, amelyek gyakorlatilag vezérlik a fejlesztés menetét.
A vezérelt fejlesztési folyamat lépései maximálisan leegyszerűsítve a következők:

• A projektvezető (témavezető) kiadja a feladatot a szervezőnek. Amennyiben ennek külső (pl. MS Word) dokumentumai vannak, azok beemelhetők az adatbázisba, (az ORACLE a szöveges részek keresésére is alkalmas), de a leírások direktben is berögzíthetők.

• A kijelölt szervező asztalán automatikusan megjelenik a feladat minden olyan paraméterrel, amelyet a vezető meghatározott. A szervező megszervezi (megtervezi) a rendszert (modult stb…), majd kijelöli a programozó(ka)t és átadja a feladatot az ő asztalukra. Különböző teljesítési és nehézségi paraméterek beállíthatók a feladat kiadása során, amelyből később a munka végzésére vonatkozó statisztikák nyerhetők ki. (Pl. ki és mennyi időt foglalkozott a modullal).

• A programozó elvégzi a programozási feladatot, elvégzi az alapvető működésre vonatkozó alfatesztet, adminisztrálja a ráfordított időt és átadja a tesztelőnek a feladatot.

• A tesztelő elvégzi az összefüggéseket is vizsgáló béta tesztet, és az eredményét (hiba, javaslat) leírja a munkalap megfelelő rovatában.

• Ez után a munkalap újra a projektvezetőhöz (témafelelőshöz) kerül, aki a tesztelési eredmények alapján dönt a modul további sorsáról. A modul telepíthető vagy újból vissza kell adni javításra, amennyiben a tesztelő észrevételeit a témavezető elfogadja.

Minden fázisban, minden résztvevő feljegyezi a ráfordított időt, a kezdési befejezési dátumokat. Tételesen meghatározhatók a határidők, a feladat elfogadások, illetve elutasítások, a feladat nehézségi foka osztályokba sorolható stb. Minden adat a Repositoryban kerül eltárolásra, de az adatok kezelésére külső programokat is irtunk. A bekerült adatokból többféle információs lista (pl: nyitott feladatok) statisztikai listák (pl. egy modulra fordított átlagos idők) kérhetők le.

Amennyiben egy adott modul történetére vagyunk kíváncsiak, a modul neve alapján a fejlesztés teljes történetiségét áttekinthetjük. Ugyanebben a szemléletben a support során végzett hibajavítás, módosítás is nyomon követhető. A rendszerben megoldottuk a jogosultsági hierarchia alapján történő kezelést, a program verzióváltásainak kezelését, ezzel gátat szabtunk az "önkényes", nyom nélküli belenyúlásoknak és ebből adódó problémáknak. A fejlesztést követő munkalap alkalmazásával gyakorlatilag megteremtettük az ISO 9001 igen szigorú előírásainak az alapját anélkül, hogy manuális feladat-követő munkalapokat kelljen gyártanunk a fejlesztés során.
 

A kifejlesztett eljárás amellett, hogy biztosítja a minőségi követelményeket, igen fontos tapasztalatokat is eredményez a munka-ráfordítás, és a modulok nehézségi fokának viszonyában. Ez a tapasztalat pedig egy következő projekt tervezésénél meghatározó lehet.

A módszer használata a fejlesztést igénybe vevő szervezetek számára

A fejlesztéssel foglalkozó szervezetek mellett a fejlesztést igénybe vevő szervezetek számára is rendkívül hasznos lehet egy ilyen megoldás. Jelentősebb fejlesztési projekt standard követelményeként a minőségbiztosítás szellemében módszertanilag előírható ez a követési metódus legalább a rendszer helyszínen történő telepítésének pillanatától. Amennyiben pedig a forráskód megvétele is tárgyát képezi a fejlesztési szerződésnek, megkövetelhető a rendszer kialakításának teljes folyamatára a módszer használata. Az alkalmazás biztosítani tudja, hogy a fejlesztő a telepítéstől a bevezetésig, a rendszergazda pedig a követő support során naprakészen átlássa a projekt állását, és követni tudja a változásokat.

Kezelése nem nehéz, kizárólag fegyelmet követel, hogy minden információ, tárolásra kerüljön. Ez a feladat nem jelent többletmunkát, hiszen a nagyobb projekteket mindenképpen adminisztrálni kell, és a kísérő dokumentumok a fejlesztés során megszületnek, csak nem biztos, hogy e módszer nélkül követhetők lesznek a változások. Ahol fejlesztői, vagy megrendelői oldalon a Designer Repository rendelkezésre áll, a kezelést biztosítani lehet. Folyamatban van a rendszer olyan irányú átírása, hogy Designer nélkül is (ORACLE adatbázis táblákban tárolva) használható legyen a módszer.