IT Controlling tanfolyam. Az informatikai fejlesztés controllingja

Átírás

1 Véry Zoltán IT Controlling tanfolyam Az informatikai fejlesztés controllingja Budapest, 2007.

2 TARTALOMJEGYZÉK 1. AZ INFORMATIKAI FEJLESZTÉS ÉS AZ ÜZLET KAPCSOLATA AZ INFORMATIKAI FEJLESZTÉS TARTALMA ÉS ÖSSZETEVİI A SZOFTVERFEJLESZTÉS RENDSZERE Tervezési alrendszer Fejlesztési alrendszer Ellenırzési alrendszer Irányítási alrendszer Implementációs alrendszer Információs- és dokumentációs alrendszer ALKALMAZOTT SZOFTVERFEJLESZTÉSI MÓDSZEREK ÉS ESZKÖZÖK8 4.1 Teljes életciklus szemlélet: Vízesés Modell Teljes életciklus szemlélet: V-MODELL Célvezérelt projektmenedzsment (GDPM) AGILIS fejlesztési módszerek Dinamikus Rendszerfejlesztési Modell (DSDM) SCRUM Modell A SZOFTVERFEJLESZTÉS MINİSÉGBIZTOSÍTÁSA CMMI minıségvezérelt projektmenedzsment Six Sigma (6б RENDSZER- ÉS SZOFTVERFEJLESZTÉSI CONTROLLING...22 Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

3 Az informatikai fejlesztés controllingja A fejezetben tárgyalt témák: Az informatikai fejlesztés és az üzlet kapcsolata Az informatikai fejlesztés tartalma, összetevıi Az üzlet és az informatika összehangolása Az informatikai fejlesztés rendszere és funkciói Rendszer- és szoftverfejlesztési módszerek A szoftverfejlesztés felügyelete és szabályozása 1. Az informatikai fejlesztés és az üzlet kapcsolata Globalizált, hálózatos világunkban a vállalkozások üzleti modelljében az információs rendszer egyre inkább stratégiai elemmé válik. Az informatika szerepe átértékelıdik, a vezetık sokkal nagyobb hangsúlyt fektetnek az informatikai fejlesztések irányának meghatározására. A fejlesztéseknél mindig a stratégiai célokból kell kiindulni. Az alkalmazásoknak illeszkedniük kell az üzleti folyamatokhoz. Az üzleti folyamatokra azonban a gyors és gyakori változások jellemzıek, melyek követése a szoftverekben nem könnyő feladat. A fejlesztések egyik generálója az üzleti folyamatokban bekövetkezett változások leképezése az információs rendszerben. A változások sokféle okból következhetnek be, például: Változnak a jogszabályok, szabványok, amelyeknek meg kell felelni; Új termékeket, szolgáltatásokat vezetünk be a piacon; Új vevıkört akarunk meghódítani; Változik a szervezeti struktúra; Változnak a mőködési folyamatok; A felhasználók új információs igényekkel lépnek fel; Online folyamatokat alakítunk ki; Új felhasználói csoportok lépnek be a rendszerbe. További fejlesztést generáló tényezık például: A meglévı erıforrások már nem elegendıek az üzemszerő mőködéshez; Az alkalmazott információtechnológia elavult, a gyártók által nem támogatott; A rendszer nem elég biztonságos; Az adatbázis mérete és növekedési üteme meghaladja a tervezett szintet. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

4 2. Az informatikai fejlesztés tartalma és összetevıi Az információtechnológia Informatikai fejlesztések aspektusai progresszív ágazat. Az ágazati innovációs hullámok folyamatos hatást gyakorolnak az üzlet és Innovációs hajtóerık ill. Üzleti igények, követelmények társadalom összes szereplıjére. Az IT képessé tesz. Képessé Üzletfejlesztés Rendszerfejlesztés Eszközfejlesztés Képességfejlesztés tesz arra, amit nélküle képtelenek lennénk megtenni. Képessé tesz a magas szintő szellemi munkára és együttmőködésre, kommunikációra. Fontos azonban, hogy állandó összhangot teremtsünk és tartsunk fenn, üzlet és technológia között. A IT IT / BUSINESS ÖSSZEHANGOLÁS BIZ technológiai hardver és szoftver eszközök illetve módszerek fejlesztése mellett, fejlesztenünk kell az orgver (szervezeti) eszközöket, illetve módszereket egyaránt. Azaz a folyamatokat, az üzleti funkciókat, az üzleti modellt, az integritást, az alkalmazásokat, az információkezelési szabályokat, a projektvezetési módszereket és a felhasználók képességeit egyaránt. A rendszerszerő gondolkodás, illetve a rendszerelvő fejlesztés ezt kívánja. A minıségirányítás (minıségbiztosítás, minıségellenırzés) is ezt várja el tılünk. Az informatikai fejlesztések, ma már, üzletfejlesztéssel is együtt jár(hat)nak. Az információtechnológia és üzleti stratégia, hatással vannak egymásra. Szinergiahatással. Folyamatfejlesztés Funkció fejlesztés Rendszerintegráció Architektúra-fejlesztés Alkalmazás-fejlesztés Software-fejlesztés Módszer-fejlesztés Képzés, továbbképzés Az információtechnológia üzleti folyamatokat is megvalósít, illetve támogat. A folyamatok definiálása nélkülözhetetlen az IT-rendszer helyes kialakításához. Ezért gyakori, hogy egy új alkalmazás bevezetése együtt jár a mőködés folyamatrendszer átgondolásával, esetleges átszervezésével (BPR Business Process Reengineering). Az üzletmenetre egyre inkább jellemzı a változékonyság. A növekvı vevıi igények kielégítése, a termékfejlesztés, a szolgáltatások bıvítése, ill. átalakítása, a szervezeti-mőködési rendszer változtatása, a jogszabályok változása mind olyan tényezı, amely szükségessé teszi az informatikai rendszer folyamatos változtatását is, hogy megfeleljen az új követelményeknek. Ennek megvalósításához az informatikai csapatnak szorosan együtt kell mőködnie a szervezettel, idıben értesülnie kell a tervezett változásokról, hogy felkészíthessék ezekre az ICT rendszert. Az informatika a fentiek alapján nemcsak egy szakterületi funkció, amely speciális tudást igényel, hanem része a stratégiai tervezésnek és irányításnak is. Ezt ábrázolja az alábbi ábra: Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

5 3. A szoftverfejlesztés rendszere A szoftverfejlesztés széleskörő, összetett szakterület, többféle szakemberrel, számtalan fejlesztési céllal, eszközzel és módszerrel. Szoftvereket készítünk a társadalom szinte összes területére. A kutatás, a mőszaki fejlesztés, az üzleti verseny, a kommunikáció, az automatizálás, a személyes eszközhasználat, az egészségügy, a szolgáltatások, a kormányzás, a védelem, stb. mind használnak szoftvert. A szoftver egy eszköz, mely beépült az életünkbe és az üzletünkbe. A szoftverfejlesztés magas szintő innovációs szakterület. Nem csak a szoftverfejlesztık tudásterülete! Mindannyian kapcsolatban vagyunk, vagy kerülünk vele. Ismerjük meg. A szoftverfejlesztés rendszerként értelmezhetı, mely több alrendszerbıl épül. A szoftverfejlesztés alrendszerei: 3.1 Tervezési alrendszer A konkrét tervezési munkát összetett, mindenre kiterjedı követelményspecifikáció elızi meg, mely a tervezés alapja. A koncepcionális (logikai) rendszerterv jóváhagyása után történik a részletes (fizikai) rendszerterv összeállítása és jóváhagyása. A tervezési alrendszer a fejlesztési feladat kidolgozásának és elfogadtatásának a szakterülete. A tervezési alrendszerben készül a tesztelési-, a minıségi-, a kommunikációs-, a konfigurációs-, és a költségvetés-terv is. 3.2 Fejlesztési alrendszer A fejlesztés a tervek megvalósítását jelenti. Algoritmuskészítés, programkódolás, programkövetés (debugging), parametrizálás, próbafuttatás, stb. tevékenységek szerint épül a szoftver. Célszerő ezeket a releváns fejlesztési tevékenységeket azonosítani és teljesítménytényezıkkel ellátni, a méréshez és elszámoláshoz. A fejlesztés többféle fejlesztési módszert ismer és használ. Néha egyidıben. Az egyes módszerek eltérı fejlesztési szakaszokkal, folyamatokkal, tevékenységekkel, mérföldkövekkel számolnak. Célszerő ezt egy fejlesztési tevékenység-katalógusban is jelölni és majd kezelni a kontroll munkában. 3.3 Ellenırzési alrendszer Az ellenırzés a tesztelési munkafolyamaton (körfolyamat) túl, minıségellenırzést is jelent. A minıséget több aspektusból kell megfognunk és irányítanunk. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

6 A fejlesztési minıség három dimenziója Megfelelıség ISO IT SERVICE Támogatás Nyújtás 6 Sigma CMM Level 5 A keresztfunkciós folyamatok felügyelete Fókusz a fejlesztésre A kipróbálás módszere a tesztelés. Ekkor ismert bemenı adatokkal próbáljuk ki az alkalmazást, és elıre tudjuk az elvárt eredményt. A teszteléskor a tesztelési tervet használjuk, ami már a rendszertervezéskor elkészült. A tesztelési tervben tükrözıdik a kockázati helyzet. A kockázatokat tartalmazó funkciókat kell alaposan tesztelni. A tesztelés jelentıs költséget okoz és a felhasználóktól is jelentıs többletmunkát vár el. Egy vezetı akkor bízhat az alkalmazásban, ha a tesztelést szakszerően tervezték és a sikeres tesztelést megfelelıen dokumentálták. A tesztelési terv kockázatelemzésen nyugszik. Ehhez felsorolják a szoftver összes funkcióját, majd elemzik az adott funkció kockázatosságát. Azokat a funkciókat kell tesztelni, amelyek kockázatot tartalmaznak. Íme egy példa: Tranzakció Teszte- Sorsz. kódja Mővelet megnevezése Kritikus lendı. 32. FBL5N Számla tétel megjelenítés Nem Igen 33. FBL6 Számla tétel módosítás Igen Igen 34. FD10N Számla egyenlegek megjelenítése Nem Nem 35. FD11 Számla elemzés Nem Nem. 53. LS01N Raktári tárhely létrehozása, manuális Igen Igen 54. LS02N Raktári tárhely módosítása, egyenként Igen Igen 55. LS03N Raktári tárhely megjelenítése Nem Igen 56. LS04 Üres tárhelyek Nem Nem MI04 Leltár rögzítés Igen Igen 289. MI05 Leltár módosítás Igen Igen 290. MI06 Leltár rögzítés megjelenítés Nem Igen 291. MI07 Leltáreltérés könyvelése Igen Igen. Megjegyzés: Sok helyen használt programcsomagról van ez esetben szó. Ezért a lekérdezéseknél azonos adatra csak egy fajta lekérdezés tesztelését tervezik. Tesztelési dokumentum kódja A tesztelési terv megléte és az arra alapozott sikeres tesztelés még önmagában nem garancia a megfelelı tesztelésre. Nagyon fontos, hogy a tesztelési tervben az alkalmazás elemi funkciói szerepeljenek. Ez összetett alkalmazásnál igen nagymérető tesztelési tervhez vezet. Az egyes elemi funkciók is tartalmazhatnak különféle lényegesen eltérı gazdasági eseményeket az adatok fajtái szerint. Például az anyagmegrendelési funkció takarhat gyártáshoz szükséges nyersanyagokat, karbantartáshoz szükséges mőszaki anyagokat, rezsi anyagokat stb. Ha minden apró változatában ki akarnánk próbálni egy integrált alkalmazást, akkor több tízezer, néhány százezer esetet kellene tesztelni. Ezek közül az ésszerő kockázatviselésig kell válogatni a lehetséges esetekbıl. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

7 A tesztelés önmagában kockázatos, mert hibás adatok is keletkezhetnek a tesztelés során. Ezért a tesztelést egy külön rendszerben, általában egy külön számítógépen végzik. Az alkalmazás kipróbálása tekintetében a vezetınek ellenırzési feladata van. Azt kell ellenıriznie, hogy a kockázatoknak megfelelı minden fajta kipróbálást elvégeztek a felelısök és a kipróbálás során az alkalmazás megfelelınek mutatkozott. A tesztelésen kívüli megfelelıségi bizonyítások különös esetekben használatosak. Rendkívüli kockázatot jelentı alkalmazásoknál az alkalmazás minden programját sorról sorra átvizsgálhatják (inspekción alapuló kvalifikáció). Egyes iparágakban pedig a validálásnak nevezett eljárás-együttes kötelezı mindazon alkalmazásokra, amelyek az adott iparágban jelentıs kockázatot tartalmaznak. A tesztelés, kvalifikálás és validálás elengedhetetlen háttér tevékenység a vezetı számára. A kockázattal arányos mélységig le nem tesztelt alkalmazást nem szabad használni! 3.4 Irányítási alrendszer A fejlesztés többnyire projektalapú munkával, több szakember együttmőködésével bonyolódik. A fejlesztést a projektvezetı irányítja. Több projektirányítási módszert ismerünk (lásd a következı fejezetben) és alkalmazunk - akár egyidıben. A fejlesztendı termék és a fejlesztési munka komplexitása, terjedelme, idıkorlátok szerint eltérı módszertant használ(hat)unk. Ez azt jelenti, hogy új és újabb módszertanok elsajátítása és frissítése többletráfordítással jár. A fejlesztési részfeladatok irányítását azok az önszervezıdı szakmai team-ek végzik, akik felelısek a szoftver komponensek és/vagy a komponensek összeszerelési, integrálási folyamataiért, illetve a termékért. A projektvezetı a projekt folyamatait, a változásokat, a határidık betartását, a projekt termékek és szolgáltatások minıségét és költségkeretet (budget) menedzseli. Kiszolgáló munkatársa: a controller pedig, üzemgazdasági-, pénzügyi-, kalkulációs-, felügyeleti-szabályozási szakértéssel támogatja. A szoftverfejlesztés minıségi követelményeinek specifikálása, minıségbiztosítása és minıségellenırzése is tartozhat a controllerhez. Amennyiben rendelkezik ilyen képzettséggel és jogosítványokkal. A controller koordinálja akár több projekt számára - a költségvetés készítés folyamatot. Követi a tevékenységeket és változásokat. Szükség esetén elemzést, kalkulációt készít a változások pénzügyi következményeirıl, illetve a változások teljesítmény, kapacitás és a költség kihatásairól. Jelentéskészítési és jelentés-értékelési (kommentálási) tevékenységgel segíti a projektvezetıt és teameket. Az együttfutó fejlesztési projektek egymás közötti teljesítményátadásait és a közös erıforrások beszerzését is ı koordinálja. A szoftverfejlesztés egészének pénzügyi-üzemgazdasági szakértıje illetve teljesítmény-, kapacitás-, kompetencia-tényezık kontrollıre. A szoftverfejlesztés irányításialrendszerének tipikus szereplıje. 3.5 Implementációs alrendszer A projekt eredményei, a szolgáltatások, a komponensek, a félkész- és késztermékek kerülnek átadásra. Az implementációs alrendszer készíti elı az átadást, mely a validálással kezdıdik. A validálás a felhasználó követelményeknek való megfelelıség. Ez azt jelenti, hogy nem csak jól mőködik a szoftver, hanem úgy mőködik, ahogy a felhasználó elvárja és a környezetében is megfelel minden követelménynek. (pl.: integrációs-, vagy terhelés-követelmények, stb.) Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

8 Megfelelıség (Compliance) Az üzletvitelben egyre fontosabbak az ellenırzött folyamatok. A számítógépes alkalmazásokban is egyre több ellenırzési funkció van. Ennek lényeges eleme a vezetıi, vagy a vezetı nevében végzett ellenırzés. Az elkészült szoftveren, például az alkalmazáson túl magát az üzleti folyamatot is ellenırizni kell speciális esetekben. A Sarbanes-Oxley törvény elıírja például, hogy amerikai vállalatoknak és az amerikai tızsdéken szereplı vállalatoknak olyan ellenırzési rendszert kell kiépíteni és folyamatosan mőködtetni, amely biztosítja a pénzügyi beszámolók megfelelıségét. Az ellenırzött rendszer, az ellenırzött alkalmazás fogalma két dolgot takar: - maga az alkalmazás és a számítógépes rendszer olyan ellenırzött módon készült, amely biztosítja a követelmények szerinti folyamatos mőködést, - az alkalmazásba (és a számítógépes rendszerbe) olyan úgynevezett folyamatba épített ellenırzéseket terveztek és használnak, amelyek biztosítják az adatok megfelelıségét is. Olyan ellenırzött szoftvert, alkalmazást kell építeni és mőködtetni, mikor a cég és a vezetı bízhat az elıállított és közzétett adatokban. A validációt a telepítés és próbaüzemeltetés követi, amit az implementációs alrendszer személyzete végez, szakértıi felügyelnek. A telepítéssel nem fejezıdött be a fejlesztés, csak lezárult. Az életciklus-szemlélet azt követeli meg a fejlesztéstıl, hogy folyamatosan informálódjon az üzemeltetésrıl, a továbbfejlesztés készültségével. Az üzletvitel és az üzleti környezet változásai jelentıs tovább-fejlesztést indukál. Az életciklus szemlélető fejlesztés megelızi a továbbfejlesztési igényeket, kéréseket. 3.6 Információs- és dokumentációs alrendszer A fejlesztési program és projekt-portfoliók olyan adatokat, adatbázisokat feltételeznek, mellyel átláthatóvá, befolyásolhatóvá - és ezáltal irányíthatóvá válnak. A projektirányítási információs- és dokumentációs rendszerek (PSA, EPM, stb.) teljeskörő megoldást nyújtanak az adatok, információk és digitális tartalmak rendszerezésére, kezelésére és hálózati eléréséhez. Többnyire az ERP rendszerek részeként, vagy azokkal együttmőködésben. 4. Alkalmazott szoftverfejlesztési módszerek és eszközök Inputs Code & Test Cycle Outputs Ez nem szoftverfejlesztési módszer, hanem végtelen szoftverkészítési munka! Ahhoz, hogy módszeressé, átláthatóvá és befolyásolhatóvá tegyük a fejlesztést, ismernünk kell az alkalmazott fejlesztési módszereket, melyek meghatározóak a számunkra. Az alkalmazott folyamatokat, tevékenységeket magukba foglalják. A módszertanok elemei, összetevıi, szereplıi és moduljai a fejlesztés-controlling rendszer számára alapul szolgálnak. Úgy a Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

9 felelısség-felügyelet (költséghelyi elszámolás), mint az értékteremtés-felügyelet vonatkozásában. A teljesítmények és a ráfordítások mérésekor és elszámolásakor. Az alábbiakban összefoglaljuk a legelterjedtebb szoftverfejlesztési metodikákat: 4.1 Teljes életciklus szemlélet: Vízesés Modell A teljesség kedvéért szerepeltetjük. Ma már nem használják, mert változott a vevık, a megrendelık környezete, ritmusa és igénye. 4.2 Teljes életciklus szemlélet: V-MODELL A módszert több német egyetem fejlesztette ki. Ma már széles körben használják a német nyelvő területeken: üzleti vállalkozások és államigazgatási szervezetek egyaránt. V-MODELL alapséma Felhasználói Követelmények definíció Validálás Szoftver- Követelmények definíció Rendszer tesztelés Architektúra tervezés Integrációs tesztelés Részletes tervezés Komponensek tesztelése Kódolás Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

10 V-MODEL GBV 1 minta Javaslat: Pro A gyakorlatra épül Fentrıl le (top down) tervez Lentrıl fel (bottom up) valósít meg Nagyon részletesen kidolgozott Kontra A megtanulása idıbe telik Sok az adminisztrációs munka A V-Model több változata épült ki és mőködik fıleg német nyelvterületeken. A rendszer a következı modulokat tartalmazza: Rendszerfejlesztés (System Development, SD) modul. Minıségbiztosítás (Quality Assurance, AQ) modul. Szoftverkonfiguráció-kezelés (Configuration Management, CM) modul. Projektmenedzsment (Project Management, PM) modul. Ez lehet a PMI PMBOK vagy a Célvezérelt projektmenedzsment (GDPM 2 ) módszertan akár Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

11 4.3 Célvezérelt projektmenedzsment (GDPM) A feladat kisebb mérete, összetettsége esetén a szoftverfejlesztéshez olyan módszertant válasszunk, mely megkönnyíti a munkánkat. A GDPM ilyen eszköz és módszer. A Mérföldkıtervezés során az egyes projekt mérföldkövekhez rendelhetünk részeredményeket, eredményeket, azaz olyan outputokat, melyekkel követhetıvé és értékelhetıvé válik a megrendelık számára is a szoftverfejlesztési munka. Átfogó célok meghatároz. A koordináció elvei Az erıforrások elosztása Eredmény kontroll Steering Committee PROJECT DEFINITION Global Reporting Mérföldkı tervezés A felelısség kijelölése A célok ütemezése Változás kontroll Project Manager Contact GlobalPlanning & Organising Detail Reporting Tevékenységek listája A szerepkörök kijelölése Tevékenységütemezés Tevékenység kontroll Project Team Rolling wave Planning DetailPlanning & Organising MIKOR? KINEK? MIT? Milestone Plan Responsibility Chart Activity Schedule & Progress Report A GDPM módszertan részletes megismerésére és elsajátítására külön tananyagot és kurzust kínálunk. (ld. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

12 4.4 AGILIS fejlesztési módszerek A gyorsan változó üzlet, gyors megoldásokat vár a fejlesztıktıl. Ezen követelmény teljesítéséhez alkották meg az agilis szoftverfejlesztési 3 módszertanokat, melyek közül a DSDM és a SCRUM módszertant mutatjuk be áttekintı jelleggel Dinamikus Rendszerfejlesztési Modell (DSDM) A DSDM alkalmazásfejlesztéshez, illetve alkalmazás bevezetéshez készült. A DSDM alapelvei A DSDM fı célja, olyan rendszer fejlesztése, amelyik a jelenlegi üzleti igényeket elégíti ki. A cél nem egy tökéletes üzleti rendszer szállítása, amely minden elképzelhetı igényt kielégít, hanem a projekt létfontosságú céljainak elérése. Egyetlen rendszert sem lehet elsıre tökéletesre megírni. A rendszerfejlesztés során a funkcionalitás 80 százalékát meg lehet írni a tökéletes rendszer kifejlesztéséhez szükséges idı 20 százalékában. Az a 20 százalék, ami a mőködı és a tökéletes rendszer között van, gyakran okozza a projektek kicsúszását a határidıbıl és a költségvetésbıl. A DSDM célja éppen ezért a 80 százaléknak az elıállítása. A projektnek a határidın és a költségvetésen belül kell végzıdnie, jó minıségő termék elıállításával. A rendszerrel szemben támasztott követelményeknek tartalmaznia kell valamelyes rugalmasságot, a fenti elvekbıl következıen. 3 Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

13 A DSDM-ben minden lépésnek addig kell eljutnia, hogy a következı lépést lehetıvé tegye, egy centivel se tovább. Így a következı lépéssel a lehetı legkevesebbet kell várni, és a rendszer minden lépésben fejlıdni fog. A kommunikáció a projekt összes résztvevıje között elengedhetetlen követelmény a projekt sikeréhez. Az ügyfél bevonása nélkül ebbıl kifolyólag lehetetlen sikeres projektet végrehajtani. A csapatnak felhatalmazást kell kapnia olyan döntések meghozására, amik fontosak lehetnek a haladás érdekében. A DSDM tartalmaz projekt menedzsment technikákat, és szoftverfejlesztési technikákat is. A DSDM használható létezı rendszerek továbbfejlesztésére is, sıt nem IT-vel kapcsolatos, hanem inkább üzleti változás-jellegő projektekben is. A DSDM használatának feltételei A DSDM sikeres alkalmazásához szükség van néhány feltételre. Elıször is arra, hogy a csapat tagjai között, a leendı végfelhasználók között, és a felsıvezetés között interaktív, kétirányú kapcsolat legyen. Ez azért kell, hogy elkerülhetık legyenek azok az ismert hibák, amik a felsıvezetés motivációjának hiányából erednek, és/vagy a felhasználó közremőködésének hiányából adódnak. Másodszor is, a projektnek felbonthatónak kell lennie, vagyis lennie kell értelmes dekompozíciónak. A DSDM iteratív, inkrementális technikái csak elkülönülı részekre mőködnek igazán jól. Azt is meg lehet tenni, hogy a nagy projekt szétesik sok kis alprojektre, amelyek egymástól függetlenül használnak DSDM-et, vagy valami mást, és a nagy projektet kezeljük DSDM-mel. Harmadszor, a követelményeket egyértelmően meg kell határozni, és prioritás szerint sorba kell rendezni. Ha egy projekt ennek a három dolognak nem felel meg, akkor kevésbé célszerő DSDM-et alkalmazni. Például túlságosan bonyolult projekteket, amik nem esnek szét független részekre, nem lehet iteratívan fejleszteni. Hasonlóképpen, olyan projektek, amelyeknek nincsenek egyértelmően meghatározott céljai, következésképpen nem is lehet ezeket prioritás szerint sorba rendezni, jó eséllyel fognak minden létezı határidıbıl és költségvetésbıl kicsúszni, és ezen a DSDM sem tud segíteni. Ezenfelül vannak olyan projektek, amelyeknek mindennél fontosabb célja a biztonságos mőködés, vagyis olyan alkalmazás készítése, ami minden körülmények között rendelkezésre áll. Ezek tipikusan emberélettel kapcsolatos alkalmazások. Az ilyen projektekben az égvilágon mindent le kell tesztelni, és a legkisebb hibát is addig kell csiszolni, amíg el nem tőnik, ez pedig ellentmond annak, hogy a DSDM célja nem a tökéletes szoftver elkészítése, hanem egy elfogadhatóan jó szoftver készítése határidın és költségvetésen belül. Ugyanebbıl az okból nem alkalmas a DSDM újrahasznosítható komponensek és hasonlók készítésére sem, ahol az 'elég jó' nem elég jó, hanem csak a tökéletes felel meg, hiszen nem lehet elıre tudni, hogy milyen alkalmazás mit fog elvárni a komponenstıl. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

14 A DSDM szakaszai A DSDM három szakaszból áll, a projekt-elıtti szakaszból, a projekt-szakaszból, és a posztprojekt szakaszból. A projekt-szakasz a legbonyolultabb, ennek 5 kapuja van, amelyek iteratívan, lépésrıl-lépésre közelítik meg a projekt célját. A projekt-elıtti szakasz A projekt-elıtti szakaszban elıször is meg kell határozni a lehetséges projekt-jelölteket, meg kell szerezni a támogatást a projekthez, és ki kell alakítani a projekt iránti elkötelezettséget minden résztvevıben. Azzal, hogy ezeket a dolgokat az elején tisztázzuk, sok fejfájástól kíméljük meg magunkat a késıbbiekben. A projekt életciklusa A fenti ábra mutatja a projekt kapuit a második szakaszban. Az elsı két kapu egymás után következik, és egymást egészítik ki. Miután ezeket elhagyjuk, megkezdıdik a rendszer iteratív és inkrementális fejlesztése, a Funkcionális modell, Tervezés és építés iteráció, és Megvalósítás kapukon keresztül. Elsı kapu: a Megvalósíthatósági Tanulmány (Feasibility Study) Ezen a kapun azt kell megvizsgálni, hogy a projekt megvalósítható-e DSDM segítségével. A már említett elıfeltételek meglétét kell megvizsgálni, olyan kérdéseken keresztül, mint például Ez a projekt alkalmas-e az üzleti igény kielégítésére?, Mik a legkomolyabb kockázatok és a legfontosabb célok?. A legcélszerőbb erre a workshop-ok, mőhelytalálkozók szervezése. A végeredmény pedig a Megvalósíthatósági Tanulmány és a Megvalósítható Prototípus, amelyek alátámasztják a projekt megvalósíthatóságát. Ezt ki lehet bıvíteni még egy globális Körvonalas Tervvel, ami a projekt hátralévı részét írja le körvonalakban, és egy Veszélynaplóval, amelyik a legfıbb kockázatokat tartalmazza. Második kapu: az Üzleti Terv (Business Study) Az üzleti terv a Megvalósíthatósági Tanulmány kiterjesztése. Miután kiderült, hogy a projektet meg lehet valósítani DSDM segítségével, meg kell vizsgálni, hogy milyen üzleti eljárásokra van szükség, kik a felhasználói csoportok, és milyen igényeik és kívánságaik vannak. Itt is a mőhelytalálkozók a leghasznosabbak, ahol a különbözı résztvevık összeülnek, és megbeszélik a rendszert. Ezekbıl az ülésekbıl áll össze a végsı igénylista, amelynek fontos jellemzıje, hogy az igények prioritással együtt kerülnek rá. Az igények prioritására a Mükéné rendszert javasoljuk. Ez négy csoportba sorolja az igényeket: Muszáj; Kéne, ha lehet; Nem ártana, ha belefér; Nem kerül be, de majd késıbb esetleg. Ezekre a prioritásokra alapozva készül el a fejlesztési terv, ami iránymutatóként szolgál a projekt teljes idıtartama alatt. A terv kialakításának fontos része az idıkeretek megállapítása. A DSDM sikere jórészt itt dıl el, hiszen a végsı cél az, hogy az idıkereteken Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

15 és a költségvetésen belül maradva sikerüljön elég jól megközelíteni a célt, a helyes idıkeretek meghatározása tehát nagyon fontos. Lehet készíteni architektúra-tervet is, ami szintén iránymutatóként szolgálhat a fejlesztés során. A kimenet pedig annak az üzleti területnek a meghatározása, amelyet a projekt le akar fedni, továbbá egy rendszerterv és fejlesztési terv, amelyek együtt határozzák meg a fejlesztés legfontosabb lépéseit és kapuit. Ezen két dokumentum alapja pedig a prioritásos követelménylista, amely a Mükéné-elv alapján van sorba rendezve. A Veszélynaplót is frissíteni kell, mert jó eséllyel változnak a projektre leselkedı veszélyek is. Harmadik kapu: Funkcionális Modell Iteráció (Functional Model Iteration) Az igényeket, amelyeket az elızı lépésben összegyőjtöttünk, most funkcionális modellé alakítjuk. Ez a modell egy mőködı prototípusból, és modellekbıl áll. A prototípus-készítés fontos része ennek a lépésnek, mert ettıl függ a felhasználók bevonása a projektbe. A kifejlesztett prototípusokat meg kell néznie minden érintett felhasználói csoportnak. A minıség biztosításának érdekében a DSDM minden iterációs ciklusában szükség van tesztelésre. A funkcionális modell négy további lépésre bontható: A funkcionális prototípus meghatározása: Meg kell határozni, hogy milyen funkcionalitása legyen a prototípusnak, ami majd az iteráció végén létrejön. Ütemterv: ki kell egyezni, hogy mikor és hogyan fogjuk kifejleszteni a prototípust. A funkcionális prototípus létrehozása. A prototípus átnézése: ellenırizni kell a kifejlesztett prototípust. Ez történhet a végfelhasználók által, és/vagy a dokumentáció átnézésével. Mindennek az eredménye egy Funkcionális Prototípus, meg egy Funkcionális Modell, amelyek együtt képviselik azt a funkcionalitást, amit ebben az iterációban ki lehetett fejleszteni, és készen állnak a felhasználói tesztelésre. Aztán frissíteni kell a Követelménylistát, ki kell törölni, ami elkészült, és a maradék igények prioritását újra kell gondolni. Negyedik kapu: Tervezési és Építési Iteráció (Design and Build Iteration) A lényege ennek a kapunak, hogy a komponenseket, amik az elızı szakaszban létrejöttek, integrálni lehessen egy rendszerbe, amelyik a felhasználóknak megfelel. Itt kell gondolni a nem funkcionális jellegő követelményekre, amelyeket a rendszerrel szemben támasztunk. A tesztelés ennek a kapunak is nélkülözhetetlen része. Ez a kapu is négy lépésre bontható: A tervezési prototípus meghatározása: Meg kell határozni azokat a funkcionális és nem funkcionális követelményeket, amelyeket a tesztrendszerrel szemben támasztunk. Ütemterv: ki kell egyezni, hogy mikor és hogyan történik a tesztrendszer megvalósítása. Tervezési prototípus elkészítése: Olyan rendszert kell készíteni, amelyet bátran oda lehet adni a végfelhasználóknak napi használatra. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

16 A tervezési prototípus átnézése: le kell ellenırizni a kész rendszer helyességét. A tesztelés és az átnézés a legfontosabb. A végeredmény egy Tervezési Prototípus lesz, amelyet a végfelhasználók teszteltek, és Tesztelt Rendszer címszóval mehet tovább a következı kapura. Ötödik kapu: Bevezetés (Implementation) A bevezetés során a tesztelt rendszert a dokumentációval együtt átadjuk a végfelhasználóknak, és betanítjuk a további végfelhasználókat. A kész rendszert átnézzük, hogy megfelel-e azoknak a követelményeknek, amiket a projekt elején állapítottunk meg. Ezt a kaput is négy lépésre lehet bontani: Felhasználói jóváhagyás és útmutatás: A végfelhasználók jóváhagyják a rendszert, és közösen létrehozunk egy útmutatást, hogy hogyan kell használni a rendszert, mit tud, és mire való. Felhasználók betanítása: a majdani végfelhasználókkal meg kell ismertetni a rendszert. Bevezetés: A tesztelt rendszert feltelepítjük a végfelhasználó telephelyén. Az üzleti terület átnézése: megnézzük a bevezetett rendszer hatását az elején meghatározott üzleti területre. Ennek végeredményétıl függıen a projekt vagy átkerül a poszt-projekt szakaszba, vagy egy korábbi kapura kerül vissza, további fejlesztés céljából. A végeredmény egy Bevezetett Rendszer a végfelhasználók munkahelyén, és részletes felhasználói dokumentáció a rendszerrıl. Harmadik szakasz: poszt-projekt A poszt-projekt szakasz célja, hogy biztosítsa a rendszer hatékony mőködését. Ez karbantartással, javításokkal és bıvítésekkel érhetı el, a DSDM elveknek megfelelıen. Akár új projekteket is lehet indítani a létezı rendszer kibıvítésére, vagy új rendszerkomponens kifejlesztésére. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

17 4.4.2 SCRUM Modell A SCRUM 4 menedzsment jellemzıi Kell egy prioritás szerint rendezett lista az élı, felgyülemlett feladatokról. Ebbıl a listából kell egy nagyon szigorúan meghatározott részlistát készíteni egy rövid nekifutással, amit sprintnek nevezünk. Kell egy rövid megbeszélés mindennap, amit SCRUMnak nevezünk, ahol kiderül, hogy mi készült el, mi lesz készen a közeljövıben, és mik a problémák. Kell egy rövid tervezési találka, ahol az aktuális sprintre vonatkozó feladatokat kell kitalálni. Kell egy szívdobbanásnyi visszatekintés, amikor a csapattagok visszatekintenek a hátuk mögött lévı sprintre. A SCRUM-oknál van egy SCRUM-Mester, akinek az a fı dolga, hogy elhárítsa a csapat útjában lévı akadályokat, amik meggátolják, hogy a projekten dolgozzanak. A SCRUM Mester nem a csapat fınöke, lévén a csapat jobbára önszervezıdı, de pufferként funkcionál a csapat és a destabilizáló hatású befolyások között. A SCRUM azzal segíti elı a csapatok önszervezıdését, hogy bátorítja a kommunikációt a csapat tagjai között, meg egyáltalán mindenki között, aki csak a projektben érintett. A SCRUM egyik fı alapelve, hogy alapvetıen gyakorlati jellegő kihívásokat nem lehet pusztán tekintély-alapon megoldani. Ezért a SCRUM elfogadja, hogy a problémát nem mindig lehet teljesen megérteni, vagy meghatározni, ehelyett inkább a csapat teljesítményét kell maximumig fokozni, hogy aztán a csapat agilisan és rátermetten oldja meg ezeket a problémákat. A SCRUMnak nincs 'receptje' a sikeres projekt menedzsmentre, mert nem elıre meghatározott elıírásokban látja a projekt sikerét. A SCRUM inkább egyfajta hozzáállás. SCRUM Sok szervezet van, amelyik igencsak ellenáll a lentrıl jövı módszertani kezdeményezéseknek. A SCRUM azonban könnyen bevezethetı fő alatt is. Ehhez három alapvetı dologra van szükség: Ütemezz be egy demo bemutatót az ügyféllel, mostantól számított 1 hónap múlva. A csapat készítse fel a szoftvert a bemutatóra - írja meg, amit kell, semmi screenshot. A bemutatott programról kérd ki az ügyfél véleményét, aztán ugorj a lista elejére, és a csapat eme vélemény alapján fejlessze tovább a szoftvert egy újabb demora. 4 scrum angol szó, jelentése: közelharc, összecsapás, viaskodás Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

18 Ezzel az eljárással, ami egyszerő és a józan észen alapul, a SCRUM módszerének a lényegét megvalósítottuk, és lehet rá építeni. Alkalmazkodó projektmenedzsment Manapság nem túl gyakori, hogy egy szolgáltató megmondja a projekt jellemzıit és követelményeit elsıre. Sokkal gyakoribb az inkrementális szállítás, vagy az, hogy az ügyfél nem veszi át az eredményt. Viszont senki sem akarhatja megkövezni az ügyfelet azért, mert nincs tisztában azzal, hogy pontosan mire van szüksége. Lehet, hogy az ügyfél nem is végfelhasználó. Az ilyesfajta sokszereplıs helyzetekben gyakran csak agilis módszerekkel lehet sikerre vinni egy projektet, mert hiába határozta meg az ügyfél hajszálpontosan, hogy mi kell neki, ha a végfelhasználó közbeszól, és mindent megváltoztat. Néhány tipp a SCRUM-ból: Az ügyfélnek valamilyen formában részévé kell válnia a fejlesztıcsapatnak. Gyakori közbülsı kiadások KÖTELEZİEK. A fejlesztıcsapatnak kell kockázattervet készítenie, minél gyakrabban. Napi szintő megbeszéléseket kell tartani a helyzetrıl. o Mit csináltál meg tegnapról? o Mit tervezel holnapra? o Van-e bármi probléma? Az egyes modulok tervének és a modulok összefüggéseinek MUSZÁJ átláthatónak lenni. Ha valamelyik tulajdonsággal baj van, nem szabad a programot kiadni. Gyakran kellenek olyan találkozók, amikre MINDEN résztvevı eljön. Semmilyen problémát nem szabad a szınyeg alá söpörni. Senkit nem szabad megbüntetni egy probléma miatt. Energikus munkahely, és hasznosan töltött munkaórák ELENGEDHETETLENEK. A túlóra nem szükségképpen jelent túlmunkát is. A napi találkozók ütemezése A legjobb pillanat a napi találkozókra ebéd után van. A reggeli találkozó nem jó ötlet, különösen olyan cégeknél nem, amelyek flexibilisen dolgoznak. Általában ezek a találkozók nem tartanak sokáig, úgyhogy tarthatunk állófogadást is, amikor mindenki feláll, és odasétál egy táblához, aztán ott beszélgetnek egy kicsit. Az ebédszünet alatt az emberek általában úgyis megbeszélik az élet nagy dolgait, úgyhogy az ebéd utáni beszélgetéseket könnyebb a munkára koncentrálni, és az emberek is jobban oda tudnak figyelni. Ráadásul miután mindenki mögött fél nap munka áll már, ezért az eszük is jobban rááll addigra a feladatra. Kristálytiszta elvek Kristály: emberközpontú, kommunikációban erıs, kicsiket szállít, ön-adaptálódó. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

19 Az alábbi központi elemekbıl áll: Kezdd azzal, hogy jól megnézed magadnak a projekt tagjait, a kulturális hátterüket, faggasd ki ıket négyszemközt. Használd valamelyik agilis módszertant, hogy eldöntsd, mit kell tenni, és mit kell elkerülni. Szedd szét a projektet elkülönülı, független részekre (partíciókra). Határozd meg a lehetı legkevesebb szabályt, ami nélkül abszolút nem haladna a projekt elıre. Határozd meg, mi az elképzelhetı minimum, amivel elı kell állni a projekt végén. 1-4 hónapig tartó lépésekben haladj elıre. Minden lépés közepén és végén tarts visszapillantás-jellegő találkozókat, határozd meg, hogy mi mőködik, és mi nem. Készíts egy 3 oszlopos táblázatot, az oszlopok fejléce legyen rendre Elkezdeni, Abbahagyni, Folytatni legyen. Így finomítsd az eljárást. Ehhez igazából 3 dologra lesz elıre szükséged, amiket némi utánajárással a NET-rıl, vagy könyvekbıl lehet összeszedni: Alapvetı technikák a projekt-interjúkhoz. Alapvetı technikák az eredmények meghatározásához Alapvetı technikák a visszapillantó-találkozókhoz. Egy képzeletbeli párbeszéd, ami segít megvilágítani, hogy mirıl szól a Kristálytiszta gondolkodásmód: Én: Az ön-alkalmazkodás része a Kristálynak. Jómagam: Igen, de egy másik, alapvetıbb elvbıl következik: Azok tudják legjobban, hogy hogyan kell dolgozni, akik a munkát ténylegesen végzik. Én: Igen, de ebbıl következik: Ha a munkát végzık megkapják azt a munkát, hogy határozzák meg, hogyan lehet a legjobb dolgozni, akkor ezt a munkát is ık fogják tudni legjobban elvégezni. Jómagam: Igen, de ennek elıfeltétele, hogy az legyen a céljuk, hogy a munka el legyen végezve. Ugyanakkor az is igaz, hogy az ön-alkalmazkodás nem csak alulról jöhet, egy rátermett menedzser is megtalálhatja a módját annak, hogy a munkavégzés módja alkalmazkodjon a körülményekhez. Az is megtörténhet, hogy bár az embereknek nem az a célja, hogy a munka el legyen végezve, de rá vannak kényszerítve, és viszont akkor már jobban megéri a lehetı leghatékonyabban dolgozni. Olyan is van, hogy ık ugyan szeretnék, ha a munka el lenne végezve, de nem áll rendelkezésükre minden, ami a munka leghatékonyabb kialakításához kell - jogkör, információ, tapasztalat, vagy erıforrás is hiányozhat ehhez. A Kristály lényege tehát egyfajta decentralizált ön-alkalmazkodás, egy közös cél érdekében. Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24

20 5. A szoftverfejlesztés minıségbiztosítása Az ISO mellett számtalan szoftverfejlesztést támogató minıségbiztosítási és minıségellenırzési módszert használnak: Az egyes módszerek alkalmazása az USA-ban, a távol-keleti országokban és Európában eltérıek lehetnek. Az alábbi ábra áttekintést nyújt ezen a téren: A három legelterjedtebb minıségbiztosítási rendszer az ISO 9000, a Capabilitiy Maturity Model (CMM) és a Six Sigma, melyek nem kizárják, hanem adott esetben feltételezik egymást. A szoftverfejlesztés minıségbiztosítása folyamatjellegő, míg a szoftver - mint termék - minıségbiztosítása tárgyra vonatkozó követelményrendszer és módszertan. 5.1 CMMI minıségvezérelt projektmenedzsment A CMMI (Capability Maturity Model Integration) minıségvezérelt projektmenedzsment módszer amelynek alkalmazása az USA-ban már az 1990-es évek óta alapvetı elvárás a szoftverfejlesztı cégekkel szemben - több szinten értelmezhetı az alábbiak szerint: Szerzı: Véry Zoltán Kiadó: BMS Informatikai Kft., /24