Adattárház fejlesztés módszertani tapasztalatok a HIFI-ben

Az előadások a következő témára: "Adattárház fejlesztés módszertani tapasztalatok a HIFI-ben"— Előadás másolata:

1 Adattárház fejlesztés módszertani tapasztalatok a HIFI-ben
Ami a vízesésen túl van… Adattárház fejlesztés módszertani tapasztalatok a HIFI-ben Ponori Ajtony 2012. április 26.

2 Miről is lesz szó?

3 HIFI – háttér HIFI projekt szkóp HÍD és SOFI rendszerek integrációja
Riporting szelektív migrációja: Ugyanaz, de más formában Legfőbb kihívás motívum

4 Kérdésfelvetés Az agilis fejlesztési módszertannak van-e, és, ha igen, milyen mértékben van létjogosultsága a BI rendszerek esetében? A HIFI projekttapasztalatok tükrében (Van-e bármi a vízesésen túl?)

5 Fejlesztési módszertani alapok – és az ügyfél

6 Ügyfél oldali tesztelés
Vízesés modell Tanulságok Két ügyfél interakció között hónapok, sőt… A múltat képezzük le A követelmény specifikáció fázisában a kérdések töredékét látjuk A legtöbb (és legmélyebb) probléma a fejlesztés közben derül ki Követelmény felmérés Köv. spec. elfogadása Köv. spec. Rendszerterv elfogadása Rendszerterv Fejlesztés Ügyfél oldali tesztelés Átvétel, élesítés

7 Agilis fejlesztési módszertan
Az üzleti problémára koncentrálva egy iteratív tervezési, fejlesztési folyamat. Agilis kiáltvány (2001)*: Mi felfedezzük a szoftverfejlesztés jobb eljárásait azáltal, hogy fejlesztünk és segítünk másokat fejleszteni. E munkában értékesebbnek tartjuk: Egyének és interakcióik, szemben az eljárásokkal és eszközökkel. Működő szoftver, szemben a teljes körű dokumentációval. Együttműködés az ügyféllel, szemben a szerződésről való alkudozással. Változásokra való reagálás, szemben a terv követésével. * Forrás:

8 Agilis módszertan és az ügyfél
Tanulságok Folyamatos konzultáció az ügyféllel Hangsúlyok, prioritások kialakítása az ügyféllel A mélyebb problémák időben felszínre kerülnek Átvétel, élesítés

9 HIFI tapasztalatok

10 Vízesés modell és a HIFI 1.
Az adattárház alaprétegének fejlesztése Kötött szkóp alapján Rendszerterv - tervezési szakasz Rendszerterv elfogadása Fejlesztés Ügyfél oldali tesztelés Elfogadás

11 Vízesés modell és a HIFI 2.
Tapasztalatok Több tisztázatlan kérdés a tervekben Terv módosítások, akár teljes terv átalakítások Nehézkes tervező – fejlesztő kommunikáció a projekt csapaton belül Elhúzódó szakaszok

12 Agilis fejlesztés és a HIFI 1.
Adatpiacok és a riporting réteg: Rögzített szkóp mellett szelektív riporting migráció Követelmény specifikáció Követelmény specifikáció elfogadása Tervezés – fejlesztés – tesztelési szakaszok Két szálon Riportok a szkóp mentén Teljesen új, vagy deklaráltan módosítandó riportok

13 Agilis fejlesztés és a HIFI 2.
Riportok a szkóp mentén Nagyobb periódusú (több hónap) agilis szakaszok Új, vagy módosítandó riportok Ad-hoc, akár heti rendszerességű konzultációk Tapasztalatok Ügyféloldali elégedettség „Azt kaptuk, amit szerettünk volna” Gördülékenyebb belső kommunikáció - csapatmunka

14 Mit nem old meg az agilitás?
Szkópvédelem CR kezelés Határidő tartás Költség tartás Projektvezetői hozzáadott értékre szükség van!

15 Miért agilis a BI?

16 Miért agilis a BI? Ahogyan mások látják: Ahogyan mi látjuk:
Az ügyfél rövid időn belül képet kap az új rendszer előnyeiről. A megrendelő nagyon ritkán tudja pontosan, hogy mit szeretne, útközben módosíthatók az elvárások. Az IT és az üzleti felhasználók közötti közvetlenebb kapcsolat, így az IT szakemberek üzleti tudása relevánsabb lesz. A riportokra általában azonnal szükség van. A szokásos – akár több hónapig tartó – fejlesztési folyamat igen lassú. Ahogyan mi látjuk: Bonyolult kontrolling és egyéb folyamatok – megértéshez mély elemzések és konzultációk szükségesek. Kapott adatok – több probléma fordul elő, mint ahogyan azt elsőre látszik. BI – „evés közben jön meg az étvágy”.

17 Konklúzió

18 Agilitás, vagy vízesés? Az agilis fejlesztési módszertannak van-e, és, ha igen milyen mértékben van létjogosultsága a BI rendszerek esetében? Igen! De: ~ 1/3 vízesés modell, ~ 2/3 agilis modell

19 Agilitás – HIFI módra Agilis kiáltvány (2001) – kiegészítve:
Egyének és interakcióik, szemben az eljárásokkal és eszközökkel. A megfelelő eszköz kiválasztása fontos! Működő szoftver, szemben a teljeskörű dokumentációval. A működő szoftver utólagos dokumentálása fontos! Együttműködés az ügyféllel, szemben a szerződésről való alkudozással. Szkóp védelemre szükség van! Változásokra való reagálás, szemben a terv követésével. Alap követelmények rögzítésére szükség van!

20