IT Controlling tanfolyam. Az informatikai fejlesztés controllingja

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "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

Információs rendszerek Információsrendszer-fejlesztés

Információs rendszerek Információsrendszer-fejlesztés Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés

Részletesebben

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok

Részletesebben

Informatikai ellenırzések, az informatika szerepe az ellenırzések támogatásában

Informatikai ellenırzések, az informatika szerepe az ellenırzések támogatásában Nincs informatika-mentes folyamat! Informatikai ellenırzések, az informatika szerepe az ellenırzések támogatásában Oláh Róbert számvevı tanácsos Az elıadás témái 2 Miért, mit, hogyan? Az IT ellenırzés

Részletesebben

KÉPZÉS NEVE: Informatikai statisztikus és gazdasági tervezı TANTÁRGY CÍME: Projektmenedzsment. Készítette: Dr. Sediviné Balassa Ildikó

KÉPZÉS NEVE: Informatikai statisztikus és gazdasági tervezı TANTÁRGY CÍME: Projektmenedzsment. Készítette: Dr. Sediviné Balassa Ildikó Leonardo da Vinci Kísérleti projekt által továbbfejlesztett Szakmai program KÉPZÉS NEVE: Informatikai statisztikus és gazdasági tervezı TANTÁRGY CÍME: Projektmenedzsment Készítette: Dr. Sediviné Balassa

Részletesebben

Informatikai projektmenedzsment

Informatikai projektmenedzsment Schwarczenberger Istvánné dr.: Informatikai projektmenedzsment Az informatikai projektek sikeres végrehajtásához megfelelı projektvezetési technikát kell alkalmaznunk, egyébként nem számíthatunk a határidık

Részletesebben

Teszt terv Új funkció implementációja meglévı alkalmazásba

Teszt terv Új funkció implementációja meglévı alkalmazásba Teszt terv Új funkció implementációja meglévı alkalmazásba Passed Informatikai Kft. www.passed.hu Farkas Gábor 2007-P-123-45-T-1-1 IIR - Test Manager course 2 Szerepkör Név Aláírás Aláírás dátuma IT Projekt

Részletesebben

Szépmővészeti Múzeum térszint alatti bıvítése: A projekt idıt befolyásoló kockázatok értékelése. Készítette: Kassai Eszter Rónafalvi György

Szépmővészeti Múzeum térszint alatti bıvítése: A projekt idıt befolyásoló kockázatok értékelése. Készítette: Kassai Eszter Rónafalvi György Szépmővészeti Múzeum térszint alatti bıvítése: A projekt idıt befolyásoló kockázatok értékelése Készítette: Kassai Eszter Rónafalvi György Tartalom A kockázatról általában A kockázatelemzés folyamata Az

Részletesebben

Projekttervezés alapjai

Projekttervezés alapjai Projekttervezés alapjai Langó Nándor 2009. október 10. Közéletre Nevelésért Alapítvány A stratégiai tervezés folyamata Külsı környezet elemzése Belsı környezet elemzése Küldetés megfogalmazása Stratégiai

Részletesebben

Object Orgy PROJEKTTERV 1 (9) Adattípusok menedzselése Palatinus Endre 2010-09-27 1.0

Object Orgy PROJEKTTERV 1 (9) Adattípusok menedzselése Palatinus Endre 2010-09-27 1.0 Object Orgy PROJEKTTERV 1 (9) Projektterv 1 Összefoglaló 2 Verziók Ez az projekt projektterve, ahol kitérünk a megrendelt szoftver elvárt szolgáltatásaira, és a tárgy keretein belül a projekt során felhasználandó

Részletesebben

Verifikáció és validáció Általános bevezető

Verifikáció és validáció Általános bevezető Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának

Részletesebben

A GRUNDFOS gyakorlati problémamegoldás módszertana: PDCA és A3

A GRUNDFOS gyakorlati problémamegoldás módszertana: PDCA és A3 A GRUNDFOS gyakorlati problémamegoldás módszertana: PDCA és A3 Mi a PROBLÉMA? Alapértelmezés szerint : Valamely szabványtól / szabálytól való eltérés. A Lean gondolkodásmód szerint : Egy állapot ami számunkra

Részletesebben

Információbiztonsági Szabályzat elkészítése és javasolt tartalma. Debrıdy István Németh Ákos

Információbiztonsági Szabályzat elkészítése és javasolt tartalma. Debrıdy István Németh Ákos Információbiztonsági Szabályzat elkészítése és javasolt tartalma Debrıdy István Németh Ákos 2013. évi L. törvény Az e törvény hatálya alá tartozó elektronikus információs rendszerek teljes életciklusában

Részletesebben

Szigma Integrisk integrált kockázatmenedzsment rendszer

Szigma Integrisk integrált kockázatmenedzsment rendszer Szigma Integrisk integrált kockázatmenedzsment rendszer A rendszer kidolgozásának alapja, hogy a vonatkozó szakirodalomban nem volt található olyan eljárás, amely akkor is megbízható megoldást ad a kockázatok

Részletesebben

6. A szervezet. Az egyik legfontosabb vezetıi feladat. A szervezetek kialakítása, irányítása, mőködésük ellenırzése, hatékonyságuk növelése,

6. A szervezet. Az egyik legfontosabb vezetıi feladat. A szervezetek kialakítása, irányítása, mőködésük ellenırzése, hatékonyságuk növelése, 6. A szervezet Az egyik legfontosabb vezetıi feladat A szervezetek kialakítása, irányítása, mőködésük ellenırzése, hatékonyságuk növelése, 1 Formális és informális szervezetek A formális szervezet formákban

Részletesebben

A kompetencia alapú képzés bevezetésének elméleti és gyakorlati kérdései

A kompetencia alapú képzés bevezetésének elméleti és gyakorlati kérdései PANNON EGYETEM MÉRNÖKI KAR A kompetencia alapú képzés bevezetésének elméleti és gyakorlati kérdései Dr. Kelemen Gyula 2009. február 09. Az oktatás-képzés és a gazdasági teljesítmény közötti kapcsolat megköveteli

Részletesebben

Alkalmazásportfólió. Szoftvermenedzsment. menedzsment. Racionalizálás. Konszolidáció. Nyilvántartás. Elemzés

Alkalmazásportfólió. Szoftvermenedzsment. menedzsment. Racionalizálás. Konszolidáció. Nyilvántartás. Elemzés Megjegyzés: Egyes megoldásokban, ahol -szel kell jelölni a helyes választ, K (= közömbös) jelzés arra utal, hogy az és az hiánya egyaránt elfogadható (= valami lehetséges, de nem jellemzı). 5.1. A sorokban

Részletesebben

Projektmenedzsment sikertényezők Információ biztonsági projektek

Projektmenedzsment sikertényezők Információ biztonsági projektek Projektmenedzsment sikertényezők Információ biztonsági projektek A Project Management Institute (PMI, www.pmi.org) részletesen kidolgozott és folyamatosan fejlesztett metodológiával rendelkezik projektmenedzsment

Részletesebben

Sämling Kft. LEAN menedzsment. A veszteségek folyamatos és szisztematikus kiküszöbölése Több mint eszköztár. 18 év 5 fı terület:

Sämling Kft. LEAN menedzsment. A veszteségek folyamatos és szisztematikus kiküszöbölése Több mint eszköztár. 18 év 5 fı terület: Sämling Kft. 18 év 5 fı terület: 1.Oktatásszervezés (>100 képzés), 2.Projektmenedzsment, 3.Soft-skills, 4.LEAN és SixSigma 5.Szervezetfejlesztés LEAN menedzsment A veszteségek folyamatos és szisztematikus

Részletesebben

Agilis projektmenedzsment

Agilis projektmenedzsment Agilis projektmenedzsment 2013. április 10. 1 Adaptive Consulting Kft. Csutorás Zoltán Agile coach, tréner zoltan.csutoras@adaptiveconsulting.hu 2 www.scrummate.hu 3 Agilis ernyő Scrum Lean/Kanban Crystal

Részletesebben

Mindezek figyelembevételével Tengelic Község Önkormányzatának 2015. évi belsı ellenırzési terve a következıket tartalmazza.

Mindezek figyelembevételével Tengelic Község Önkormányzatának 2015. évi belsı ellenırzési terve a következıket tartalmazza. Melléklet a. /2014. (XII. 16.) kt. határozathoz Tengelic Község Önkormányzatának 2015. évi belsı ellenırzési terve A Magyarország helyi önkormányzatairól szóló 2011. évi CLXXXIX. Törvény, az államháztartásról

Részletesebben

DW/BI rendszerek kialakítása bevezetői szemszögből. Gollnhofer Gábor - Meta Consulting Kft.

DW/BI rendszerek kialakítása bevezetői szemszögből. Gollnhofer Gábor - Meta Consulting Kft. DW/BI rendszerek kialakítása bevezetői szemszögből Gollnhofer Gábor - Meta Consulting Kft. Bemutatkozás Meta Consulting Kft. BI, DW és CRM rendszerek tervezése és kialakítása rendszerintegráció, egyedi

Részletesebben

30 MB INFORMATIKAI PROJEKTELLENŐR

30 MB INFORMATIKAI PROJEKTELLENŐR INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai

Részletesebben

Folyamatmenedzsment módszerek a projekt menedzsment eszköztárában

Folyamatmenedzsment módszerek a projekt menedzsment eszköztárában Folyamatmenedzsment módszerek a projekt menedzsment eszköztárában Kisbej András vezető tanácsadó 2007. április 5. Projektszerű működés és a funkcionális szervezeti működés szabályozása nem egyen szilárdságú

Részletesebben

KISKÖRE VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATAL. Szervezetfejlesztés Kisköre Város Polgármesteri Hivatalában ÁROP-1.A.2.

KISKÖRE VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATAL. Szervezetfejlesztés Kisköre Város Polgármesteri Hivatalában ÁROP-1.A.2. KISKÖRE VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATAL Szervezetfejlesztés Kisköre Város Polgármesteri Hivatalában ÁROP-1.A.2./A-2008-0163 A PROJEKT LEÍRÁSA Kisköre, 2010. március 31. A projekt az Európai Unió

Részletesebben

Self Service szekció. XXVIII. Budapesti Menedzsment és Controlling Fórum. Havas Levente. Budapest, május 26. IFUA Horváth & Partners

Self Service szekció. XXVIII. Budapesti Menedzsment és Controlling Fórum. Havas Levente. Budapest, május 26. IFUA Horváth & Partners Self Service szekció XXVIII. Budapesti Menedzsment és Controlling Fórum Havas Levente Budapest, 2016. május 26. Self Service szekció XXVIII. Budapesti Menedzsment és Controlling Fórum Havas Levente Budapest,

Részletesebben

ISO 9001 kockázat értékelés és integrált irányítási rendszerek

ISO 9001 kockázat értékelés és integrált irányítási rendszerek BUSINESS ASSURANCE ISO 9001 kockázat értékelés és integrált irányítási rendszerek XXII. Nemzeti Minőségügyi Konferencia jzr SAFER, SMARTER, GREENER DNV GL A jövőre összpontosít A holnap sikeres vállalkozásai

Részletesebben

Transzferáras kerekasztal

Transzferáras kerekasztal Transzferáras kerekasztal Kerényi Máté Fülöp Budapest, 2011. július 8. A megbeszélés javasolt témái I. Mikor lehet/kell összevont nyilvántartást készíteni és mikor nem? Mi a piaci kamatláb a hátrasorolt

Részletesebben

Nonprofit szervezeti menedzsment területek

Nonprofit szervezeti menedzsment területek XX/a. Nonprofit szervezeti menedzsment területek a Társadalmi Megújulás Operatív Program Civil szervezeteknek szolgáltató, azokat fejlesztı szervezetek támogatása c. pályázati felhívásához Kódszám: TÁMOP-5.5.3/08/2

Részletesebben

Vezetői információs rendszerek

Vezetői információs rendszerek Vezetői információs rendszerek Kiadott anyag: Vállalat és információk Elekes Edit, 2015. E-mail: elekes.edit@eng.unideb.hu Anyagok: eng.unideb.hu/userdir/vezetoi_inf_rd 1 A vállalat, mint információs rendszer

Részletesebben

Integráci. ciós s tesztek. ciós s tesztek (folyt.) Integration Level Testing (ILT) Ficsor Lajos. Miskolci Egyetem Általános Informatikai Tanszék

Integráci. ciós s tesztek. ciós s tesztek (folyt.) Integration Level Testing (ILT) Ficsor Lajos. Miskolci Egyetem Általános Informatikai Tanszék ciós s tesztek ciós s tesztek Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 11. 27. IntegraciosTeszt / 1 ós tesztek IntegraciosTeszt / 2 ciós s tesztek (folyt.) Feltételezzük,

Részletesebben

Kompetenciák fejlesztése a pedagógusképzésben. IKT kompetenciák. Farkas András f_andras@bdf.hu

Kompetenciák fejlesztése a pedagógusképzésben. IKT kompetenciák. Farkas András f_andras@bdf.hu Kompetenciák fejlesztése a pedagógusképzésben IKT kompetenciák Farkas András f_andras@bdf.hu A tanítás holisztikus folyamat, összekapcsolja a nézeteket, a tantárgyakat egymással és a tanulók személyes

Részletesebben

Informatikai kommunikációs technikák a beszállító iparban

Informatikai kommunikációs technikák a beszállító iparban Informatikai kommunikációs technikák a beszállító iparban A FLUID-WIN projekt Nyertes projekt az EU 6. Kutatás fejlesztési és demonstrációs keretprogramjában Prioritás: Információs Társadalom Technológiák

Részletesebben

01. gyakorlat - Projektalapítás

01. gyakorlat - Projektalapítás 2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:

Részletesebben

extreme Programming programozástechnika

extreme Programming programozástechnika extreme Programming programozástechnika Készítette: Török T k Balázs G5-S8 Kezdetek Martin Fowler : The New Methodology Legtöbb projekt követelményei állandóan változnak Megoldást adaptív módszerek Kezdetek

Részletesebben

Vállalati mobilitás. Jellemzők és trendek

Vállalati mobilitás. Jellemzők és trendek Vállalati mobilitás Jellemzők és trendek Vállalati mobilitás értelmezése és előnyei A mobil eszközök (okos telefon, tablet, laptop) száma világszerte rohamosan növekszik és használatuk már nem luxus, hanem

Részletesebben

Nemzetközi projektmenedzsment. Balázsy Eszter, csoportvezetı ÉARFÜ Nonprofit Kft. 2009. augusztus 17.

Nemzetközi projektmenedzsment. Balázsy Eszter, csoportvezetı ÉARFÜ Nonprofit Kft. 2009. augusztus 17. Nemzetközi projektmenedzsment Balázsy Eszter, csoportvezetı ÉARFÜ Nonprofit Kft. 2009. augusztus 17. Nemzetközi pályázatok: miben más? Hosszú elıkészítés, egyeztetés Partnerek száma 10-15 is lehet Kommunikáció

Részletesebben

Informatikai biztonsági elvárások

Informatikai biztonsági elvárások Informatikai biztonsági elvárások dr. Dedinszky Ferenc kormány-fıtanácsadó informatikai biztonsági felügyelı 2008. július 2. Tartalom Átfogó helyzetkép Jogszabályi alapok és elıírások Ajánlások, a MIBA

Részletesebben

A külsı minıségbiztosítás jelentısége az e-kormányzati fejlesztésekben, a magyar IIER fejlesztésben szerzett tapasztalatok alapján

A külsı minıségbiztosítás jelentısége az e-kormányzati fejlesztésekben, a magyar IIER fejlesztésben szerzett tapasztalatok alapján A külsı minıségbiztosítás jelentısége az e-kormányzati fejlesztésekben, a magyar IIER fejlesztésben szerzett tapasztalatok alapján Podolcsák Ádám projektvezetı BlomInfo Konzorcium 1. Bevezetés A dán BlomInfo

Részletesebben

Schwarczenberger Istvánné dr. Az emberi erőforrás szerepe a beruházási projektek minőségében

Schwarczenberger Istvánné dr. Az emberi erőforrás szerepe a beruházási projektek minőségében Schwarczenberger Istvánné dr. Az emberi erőforrás szerepe a beruházási projektek minőségében Nemzeti Minőségügyi Konferencia D Szekció Emberi erőforrás és kommunikáció, mint minőségi sikertényezők Balatonalmádi,

Részletesebben

a A vezetés fogalmi meghatározása, a vezetés lényegi kérdései. A vállalkozáson belül

a A vezetés fogalmi meghatározása, a vezetés lényegi kérdései. A vállalkozáson belül 1.tétel a A vezetés fogalmi meghatározása, a vezetés lényegi kérdései. A vállalkozáson belül létrehozandó vezetıi szintek, azok fontosabb, elkülönült feladatai. b. Az innováció fogalma,szerepe a vállalkozásoknál.

Részletesebben

Munkaerı megtartást támogató marketing belsı kommunikációs stratégia

Munkaerı megtartást támogató marketing belsı kommunikációs stratégia Munkaerı megtartást támogató marketing belsı kommunikációs stratégia Dr. Kópházi Andrea Ph.D egyetemi docens, Humán-szakfelelıs NYME Közgazdaságtudományi Kar, Sopron Vezetés-szervezési és Marketing Intézet

Részletesebben

A Web-alapú tudásbázis a logisztika és kereskedelem területén (WebLogTrade) projekt bemutatása

A Web-alapú tudásbázis a logisztika és kereskedelem területén (WebLogTrade) projekt bemutatása A Web-alapú tudásbázis a logisztika és kereskedelem területén (WebLogTrade) projekt bemutatása Típus: Leonardo da Vinci projekt Innovációtranszfer Fıpályázó: TÜV Rheinland Akademie GmbH, Berlin, Németország

Részletesebben

Bevezetés a programozásba

Bevezetés a programozásba Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények

Részletesebben

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét

Részletesebben

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél Molnár László MNB, ITIL Projektvezető Fábián János ICON Professional Services Vezérfonal Az MNB IT működése, a SIP kiváltó okai A projekt módszereinek

Részletesebben

ELİLAP AZ ELİTERJESZTÉSEKHEZ

ELİLAP AZ ELİTERJESZTÉSEKHEZ ELİLAP AZ ELİTERJESZTÉSEKHEZ ÜLÉS IDİPONTJA: Vecsés Város Önkormányzata Képviselı-testületének 2012. május 22-i ülésére ELİTERJESZTÉS TÁRGYA: Vincent Auditor Számviteli Szolgáltató és Tanácsadó Kft. 2011.

Részletesebben

LOGISZTIKA FOGALMA, ALAP KÉRDÉSEI

LOGISZTIKA FOGALMA, ALAP KÉRDÉSEI LOGISZTIKA FOGALMA, ALAP KÉRDÉSEI Történelmi áttekintés Római Birodalom: Marcus Terentius Varro: Logisticon c. mőve A római hadseregben a logistas-ok biztosították a hadtápellátást. Középkor: Baron de

Részletesebben

MIÉRT KELL TESZTELNI?

MIÉRT KELL TESZTELNI? Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT

Részletesebben

Adatstruktúrák, algoritmusok, objektumok

Adatstruktúrák, algoritmusok, objektumok Adatstruktúrák, algoritmusok, objektumok 2. Az objektumorientált programozási paradigma 1 A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 1. A szoftveres megoldások szerepe folyamatosan

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver

Részletesebben

Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.

Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25. Fejlesztéskövetés fejvesztés nélkül, avagy Kiadáskezelés megvalósítása banki környezetben Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.

Részletesebben

Üzletmenet-folytonosság és katasztrófa helyzet kezelés (Honnan indultunk, miért változtunk, hova tartunk?)

Üzletmenet-folytonosság és katasztrófa helyzet kezelés (Honnan indultunk, miért változtunk, hova tartunk?) Üzletmenet-folytonosság és katasztrófa helyzet kezelés (Honnan indultunk, miért változtunk, hova tartunk?) Év indító IT szakmai nap - PSZÁF Budapest, 2007.01.18 Honnan indultunk? - Architektúra EBH IT

Részletesebben

Miskolci Egyetem Általános Informatikai Tanszék

Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

A tesztelés feladata. Verifikáció

A tesztelés feladata. Verifikáció Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

Módszertani útmutató hulladéklerakók rekultivációjára irányuló projektek költség-haszon elemzéséhez KVVM FI

Módszertani útmutató hulladéklerakók rekultivációjára irányuló projektek költség-haszon elemzéséhez KVVM FI Módszertani útmutató rekultivációs célú projektek költség-haszon elemzéséhez 0 KVVM FI Módszertani útmutató hulladéklerakók rekultivációjára irányuló projektek költség-haszon elemzéséhez Változatelemzés,

Részletesebben

Mi a folyamat? Folyamatokkal kapcsolatos teendőink. Folyamatok azonosítása Folyamatok szabályozása Folyamatok folyamatos fejlesztése

Mi a folyamat? Folyamatokkal kapcsolatos teendőink. Folyamatok azonosítása Folyamatok szabályozása Folyamatok folyamatos fejlesztése 1 Mi a közös? Vevő Folyamatok Résztvevők (emberek) Folyamatmenedzsment Azonosított, szabályozott, ellenőrzött, mért És állandóan továbbfejlesztett folyamatok Cél: vevői elégedettség, üzleti siker 2 az

Részletesebben

KAIZEN WORKSHOP. Dr. Németh Balázs Ügyvezetı igazgató Kvalikon Kft. LEAN modulok KAIZEN. Folyamatos. anyagáram. Emberek bevonása

KAIZEN WORKSHOP. Dr. Németh Balázs Ügyvezetı igazgató Kvalikon Kft. LEAN modulok KAIZEN. Folyamatos. anyagáram. Emberek bevonása KAIZEN WORKSHOP Dr. Németh Balázs Ügyvezetı igazgató Kvalikon Kft. LEAN modulok KAIZEN Stratégiai megközelítés Húzó rendszer Folyamatos anyagáram Emberek bevonása 0 hiba JIDOKA Vizuális mgmt. STABIL MŐKÖDÉS

Részletesebben

A projekt folyamatcsoportok és a projekt tudásterületek kapcsolata. Projektmenedzsment-folyamatcsoportok. Tervezési folyamatcsoport

A projekt folyamatcsoportok és a projekt tudásterületek kapcsolata. Projektmenedzsment-folyamatcsoportok. Tervezési folyamatcsoport A projekt folyamatcsoportok és a projekt tudásterületek kapcsolata Projektmenedzsment-folyamatcsoportok Tudásterületek Kezdeményezési folyamatcsoport Tervezési folyamatcsoport Végrehajtási folyamatcsoport

Részletesebben

Az 50001-es szabvánnyal, illetve a törvényi elvárásokkal kapcsolatos felmérési, tervezési tevékenység

Az 50001-es szabvánnyal, illetve a törvényi elvárásokkal kapcsolatos felmérési, tervezési tevékenység Az 50001-es szabvánnyal, illetve a törvényi elvárásokkal kapcsolatos felmérési, tervezési tevékenység Qualidat Kft. Együttműködésben az ÉMI TÜV SÜD-del Tartalomjegyzék Bevezetés A feladatok Projektmenedzsment

Részletesebben

Szervezeti működésfejlesztés komplexitása CMC minősítő előadás

Szervezeti működésfejlesztés komplexitása CMC minősítő előadás Szervezeti működésfejlesztés komplexitása CMC minősítő előadás Sarlósi Tibor 2012. február 28. Érintett területek 1 Diagnózis 2 Stratégiamenedzsment 3 Folyamatmenedzsment 4 Projektmenedzsment 6 rendszerek

Részletesebben

Projektmenedzsment státusz autóipari beszállító cégeknél tréning tapasztalatok alapján herczeg.ivan@pmakademia.hu mobil: +36-20-485-02-80

Projektmenedzsment státusz autóipari beszállító cégeknél tréning tapasztalatok alapján herczeg.ivan@pmakademia.hu mobil: +36-20-485-02-80 Projektmenedzsment státusz autóipari beszállító cégeknél tréning tapasztalatok alapján herczeg.ivan@pmakademia.hu mobil: +36-20-485-02-80 Herczeg Iván Mesteroktató Semmelweis Egyetem. Szervező mérnök First

Részletesebben

Végső változat, 2010 Szeptember Integrált Irányítási Rendszer (IIR) a helyi és regionális szintű fenntartható fejlődésért

Végső változat, 2010 Szeptember Integrált Irányítási Rendszer (IIR) a helyi és regionális szintű fenntartható fejlődésért Végső változat, 2010 Szeptember Integrált Irányítási Rendszer (IIR) a helyi és regionális szintű fenntartható fejlődésért Hatókör Folyamatos kiterjesztés földrajzi és tartalmi értelemben: Adott helyszíntől

Részletesebben

Pécel Város Önkormányzatának Jegyzıje 2119 Pécel, Kossuth tér 1. Tel: 28/452-745, 452-751; Fax: 28/452-755 e-mail: jegyzo@pecel.hu

Pécel Város Önkormányzatának Jegyzıje 2119 Pécel, Kossuth tér 1. Tel: 28/452-745, 452-751; Fax: 28/452-755 e-mail: jegyzo@pecel.hu Pécel Város Önkormányzatának Jegyzıje 2119 Pécel, Kossuth tér 1. Tel: 28/452-745, 452-751; Fax: 28/452-755 e-mail: jegyzo@pecel.hu Iktatószám: SZ/706/16/2009 ELİTERJESZTÉS a 2010. évre vonatkozó Éves i

Részletesebben

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,

Részletesebben

Ingatlanvagyon értékelés

Ingatlanvagyon értékelés Nyugat-Magyarországi Egyetem Geoinformatikai Kar Ingatlanfejlesztı 8000 Székesfehérvár, Pirosalma u. 1-3. Szakirányú Továbbképzési Szak Ingatlanvagyon értékelés 6. A vállalatértékelési és az ingatlanértékelési

Részletesebben

Továbblépés a TQM felıl a LEAN menedzsment bevezetése felé

Továbblépés a TQM felıl a LEAN menedzsment bevezetése felé Továbblépés a TQM felıl a LEAN menedzsment bevezetése felé Dr. Németh Balázs 2008. Március 27. Mőködési kiválóság szintjei Best Practice Hibátlan Folyamatok A legjobb gyakorlat Mások által is követésre

Részletesebben

Risk and Compliance Management mit jelent ez egy lízing cég gyakorlatában?

Risk and Compliance Management mit jelent ez egy lízing cég gyakorlatában? Risk and Compliance Management mit jelent ez egy lízing cég gyakorlatában? PROVICE Üzleti és Informatikai Szolgáltató és Tanácsadó Kft. EXCLUSIVE PARTNER 1027 Budapest, Kapás u. 11-15. Tel: + 36 1 488

Részletesebben

Informatikai projekteredmények elfogadottságának tényezői

Informatikai projekteredmények elfogadottságának tényezői Informatikai projekteredmények elfogadottságának tényezői Rabi Ákos 2014.02.18. Tartalom 1. Problémafelvetés Informatikai projekteredmények elfogadottsága 2. Informatikai projektek sikertényezői 3. Szoftverek

Részletesebben

Tisztán kivehetı tendencia: kommunikációs hálózatok egyre bonyolultabbakká válnak Hálózat bonyolultsága

Tisztán kivehetı tendencia: kommunikációs hálózatok egyre bonyolultabbakká válnak Hálózat bonyolultsága @ Budapest University of Technology and Economics Nagy hálózatok evolúciója Gulyás András, Heszberger Zalán High Speed Networks Laboratory Internet trendek Tisztán kivehetı tendencia: kommunikációs hálózatok

Részletesebben

Projektmenedzsment Szervezet Szervezeti és Mőködési Szabályzat

Projektmenedzsment Szervezet Szervezeti és Mőködési Szabályzat SAJÓSZENTPÉTER VÁROS ÖNKORMÁNYZATA Projektmenedzsment Szervezet Szervezeti és Mőködési Szabályzat 2009 Tartalomjegyzék 1. A szervezet feladat- és hatásköre... 3 2. Szervezet felépítése... 4 3. A tagok

Részletesebben

A Tisza vízgyőjtı helyzetértékelése 2007

A Tisza vízgyőjtı helyzetértékelése 2007 A Tisza vízgyőjtı helyzetértékelése 2007 Kovács Péter P fıosztályvezetı-helyettes Vízgyőjtı-gazdálkod lkodási és s VízvV zvédelmi Fıosztály Szolnok, 2008. június 26. Az ICPDR létrehozta a Tisza Csoportot,

Részletesebben

A TÁMOP 3. 3. 2.- 08/2 pályázat keretében képzési és mentori szolgáltatás ellátására benyújtott ajánlati dokumentációról

A TÁMOP 3. 3. 2.- 08/2 pályázat keretében képzési és mentori szolgáltatás ellátására benyújtott ajánlati dokumentációról 2.számú melléklet SZAKMAI ZSŐRI ÉRTÉKELÉSE A TÁMOP 3. 3. 2.- 08/2 pályázat keretében képzési és mentori szolgáltatás ellátására benyújtott ajánlati dokumentációról Ajánlattevı: Baranyai Pedagógiai Szakszolgálatok

Részletesebben

A CMMI alapú szoftverfejlesztési folyamat

A CMMI alapú szoftverfejlesztési folyamat A CMMI alapú szoftverfejlesztési folyamat Készítette: Szmetankó Gábor G-5S8 Mi a CMMI? Capability Maturity Modell Integration Folyamat fejlesztési referencia modell Bevált gyakorlatok, praktikák halmaza,

Részletesebben

E-Számlázás az ECOD rendszeren belül. Horváth Péter, Senior Projekt Menedzser Synergon Retail Systems Kft.

E-Számlázás az ECOD rendszeren belül. Horváth Péter, Senior Projekt Menedzser Synergon Retail Systems Kft. E-Számlázás az ECOD rendszeren belül Horváth Péter, Senior Projekt Menedzser Synergon Retail Systems Kft. Tartalom ECOD EDI rendszer Magyarországon és a helyi ECOD HelpDesk E-számlák archiválása az ECOD

Részletesebben

Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás

Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás Alvicom HP szeminárium 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without

Részletesebben

Területi tervezés, programozás és monitoring

Területi tervezés, programozás és monitoring Területi tervezés, programozás és monitoring 8. elıadás Regionális politika egyetemi tanár A területi tervezés fogalma, jellemzıi Területi tervezés: a közösségi beavatkozás azon módja, amikor egy területrendszer

Részletesebben

ISO 9001 revízió Dokumentált információ

ISO 9001 revízió Dokumentált információ ISO 9001 revízió Dokumentált információ Dokumentumkezelés manapság dokumentált eljárás Minőségi kézikönyv DokumentUM feljegyzés Dokumentált eljárás feljegyzések kezeléséhez Dokumentált eljárás dokumentumok

Részletesebben

Új szereplı a közlekedésfejlesztésben: a Budapesti Közlekedési Központ

Új szereplı a közlekedésfejlesztésben: a Budapesti Közlekedési Központ CATCH-MR Dissemination Workshop Budapest, 2011. május 9. Új szereplı a közlekedésfejlesztésben: a Budapesti Közlekedési Központ Kerényi László Sándor fıosztályvezetı Budapesti Közlekedési Központ Tartalom

Részletesebben

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család

Részletesebben

INNOVATÍV ÖTLETEK MEGVALÓSÍTÁSA

INNOVATÍV ÖTLETEK MEGVALÓSÍTÁSA Innovatív ötletek megvalósítása INNOVATÍV ÖTLETEK MEGVALÓSÍTÁSA tanácsadó füzet Megvalósíthatósági tanulmány, üzleti terv, különös tekintettel a pénzügyi tervezésre A kiadvány a Kutatás-fejlesztési Pályázati

Részletesebben

SZEGHALOM VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATALÁNAK SZERVEZETFEJLESZTÉSE MINİSÉGIRÁNYÍTÁS AZ ÖNKORMÁNYZATOKNÁL 1. MINİSÉGÜGY AZ ÖNKORMÁNYZATOKNÁL

SZEGHALOM VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATALÁNAK SZERVEZETFEJLESZTÉSE MINİSÉGIRÁNYÍTÁS AZ ÖNKORMÁNYZATOKNÁL 1. MINİSÉGÜGY AZ ÖNKORMÁNYZATOKNÁL V I AD ORO KÖZIGAZGATÁSFEJLESZTÉSI TANÁCSADÓ ÉS SZOLGÁLTATÓ KFT. 8230 BALATONFÜRED, VAJDA J. U. 33. +36 (30) 555-9096 A R O P.PALYAZAT@YAHOO.COM SZEGHALOM VÁROS ÖNKORMÁNYZATA POLGÁRMESTERI HIVATALÁNAK

Részletesebben

Határon átnyúló együttmőködés a TÁMOP 2. prioritása keretében

Határon átnyúló együttmőködés a TÁMOP 2. prioritása keretében Határon átnyúló együttmőködés a TÁMOP 2. prioritása keretében A TÁMOP 2. prioritás tartalma A gazdaság és a munkaerıpiac változása folyamatos alkalmazkodást kíván meg, melynek legfontosabb eszköze a képzés.

Részletesebben

Innovatív HR fejlesztés jövıje a magán és közszféra számára 2010

Innovatív HR fejlesztés jövıje a magán és közszféra számára 2010 Humán Szakemberek Országos Szövetsége Gyır, 2010. január 17. Innovatív HR fejlesztés jövıje a magán és közszféra számára 2010 Dr. Poór József egyetemi tanár, CMC HSZOSZ elnöke Változni, de hogyan Fred,

Részletesebben

AZ INTEGRÁLT KOMMUNIKÁCIÓ ELMÉLETI ÉS GYAKORLATI KÉRDÉSEI. Dr.Tasnádi József fıiskolai tanár

AZ INTEGRÁLT KOMMUNIKÁCIÓ ELMÉLETI ÉS GYAKORLATI KÉRDÉSEI. Dr.Tasnádi József fıiskolai tanár AZ INTEGRÁLT KOMMUNIKÁCIÓ ELMÉLETI ÉS GYAKORLATI KÉRDÉSEI Dr.Tasnádi József fıiskolai tanár Gábor Dénes Fıiskola www.gdf.hu e-mail: tasnadi@gdf.hu Magyar Tudomány Napja - 2008 1 Tartalom Bevezetés Fogalom

Részletesebben

Junior PROJEKT MÉRNÖK

Junior PROJEKT MÉRNÖK Junior PROJEKT MÉRNÖK - Gépész- vagy villamosmérnöki (automatizálási szak) végzettség. - Gyakorlat nem szükséges pályakezdık számára is nyitott a pozíció - Angol nyelv kommunikációs szintő ismerete. -

Részletesebben

HELYES zárójelentése) Válasz sikeresnek vagy sikertelennek nyilvánítja a projektet HIBAS

HELYES zárójelentése) Válasz sikeresnek vagy sikertelennek nyilvánítja a projektet HIBAS MC Jelölje be a helyes választ! (több válasz is lehetséges) A projektmenedzser feladatai: döntés a megvalósításról a projekt tervének elkészítése csapatépítés, a csapaton belüli kompetenciák és felelősségek

Részletesebben

Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.

Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft. Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft. Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.

Részletesebben

Logisztikai rendszerek. Termelési logisztika

Logisztikai rendszerek. Termelési logisztika Logisztikai rendszerek Termelési logisztika Termelési logisztika A termelési logisztika a mőködési területek jellegzetessége szerint a mikrologisztika, ezen belül a vállalati logisztika legmeghatározóbb

Részletesebben

Software project management Áttekintés

Software project management Áttekintés Software project management Áttekintés Miskolci Egyetem Általános Informatikai Tanszék PMAN / 1 Miért szükséges? A software fejlesztési tevékenység Csoportmunkát igényel Jelentős erőforrásokat használ

Részletesebben

Információtartalom vázlata

Információtartalom vázlata 1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos

Részletesebben

Salgótarján Megyei Jogú Város. emihaly@salgotarjan.hu JAVASLAT

Salgótarján Megyei Jogú Város. emihaly@salgotarjan.hu JAVASLAT Salgótarján Megyei Jogú Város Alpolgármesterétıl emihaly@salgotarjan.hu Szám: 81317/02/09. JAVASLAT az Észak-magyarországi Operatív Program Turisztikai Desztináció Menedzsment Szervezet támogatására vonatkozó

Részletesebben

Tanúsítási módszer kidolgozása meglévı épületekre TANULMÁNY

Tanúsítási módszer kidolgozása meglévı épületekre TANULMÁNY COMFORT CONSULTING Mérnöki Tanácsadó Kft TANULMÁNY A meglévı épületek energetikai jellemzıinek energiafogyasztás alapján történı tanúsítási módszere Megbízó: VÁTI Magyar Regionális Fejlesztési és Urbanisztikai

Részletesebben

TÁMOP 1.3.1 07/1-2008-0002 A FOGLALKOZTATÁSI SZOLGÁLAT FEJLESZTÉSE AZ INTEGRÁLT MUNKAÜGYI ÉS SZOCIÁLIS RENDSZER RÉSZEKÉNT

TÁMOP 1.3.1 07/1-2008-0002 A FOGLALKOZTATÁSI SZOLGÁLAT FEJLESZTÉSE AZ INTEGRÁLT MUNKAÜGYI ÉS SZOCIÁLIS RENDSZER RÉSZEKÉNT TÁMOP 1.3.1 07/1-2008-0002 A FOGLALKOZTATÁSI SZOLGÁLAT FEJLESZTÉSE AZ INTEGRÁLT MUNKAÜGYI ÉS SZOCIÁLIS RENDSZER RÉSZEKÉNT 1.1.5 Szolgáltatási akkreditáció modellezése alprojekt Záró tanulmány 2011. 11.

Részletesebben

1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI

1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI 1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI 1.1 MIT JELENT ÉS MIÉRT FONTOS A KOCKÁZATMENEDZSMEN T? A Project Management Institute (PMI) definíciója szerint a projekt egy ideiglenes

Részletesebben

A kockázat alapú felügyelés módszertana Mérő Katalin ügyvezető igazgató PSZÁF november 13

A kockázat alapú felügyelés módszertana Mérő Katalin ügyvezető igazgató PSZÁF november 13 A kockázat alapú felügyelés módszertana Mérő Katalin ügyvezető igazgató PSZÁF 2006. november 13 A felügyelés közeljövője a kockázat alapú felügyelés Miért? Mert a Felügyelet sok,különböző típusú és nagyságú

Részletesebben

DW 9. előadás DW tervezése, DW-projekt

DW 9. előadás DW tervezése, DW-projekt DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés

Részletesebben

A R E M E M B E R S O F T H E K B C G R O U P Group ICT IT-kormányzás, a varázsige? Némethy Dániel K&H CIO Tartalom A szolgáltató jellegű informatika kapcsolati modellje Üzem és fejlesztés - szolgáltatás-fenntartás

Részletesebben

TOGAF elemei a gyakorlatban

TOGAF elemei a gyakorlatban TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési

Részletesebben

A kockázatkezelő feladatai az AEGON gyakorlatában Zombor Zsolt 2013. május 30.

A kockázatkezelő feladatai az AEGON gyakorlatában Zombor Zsolt 2013. május 30. A kockázatkezelő feladatai az AEGON gyakorlatában Zombor Zsolt 2013. május 30. aegon.com Védelmi vonalak Kockázat 1. védelmi vonal Mindenki (Aktuáriusok) 2. védelmi vonal Kockázatkezelés, Compliance 3.

Részletesebben

OTSZ VILLÁMVÉDELEM. Elemzés és módosítási javaslat

OTSZ VILLÁMVÉDELEM. Elemzés és módosítási javaslat OTSZ Elemzés és módosítási javaslat OTSZ 3. rész Elemzés Válasz a következı kérdésekre: - a szabályzat tartalmaz-e szabványhivatkozásokat - a hivatkozások megfelelnek-e az európai elveknek és az európai

Részletesebben