MÓDSZERTANOK A HATÉKONYSÁG ELLEN. Nyitrai Attila YGOMI Europe Kft (ROC Development) Összefoglaló
|
|
- Endre Fazekas
- 7 évvel ezelőtt
- Látták:
Átírás
1 MÓDSZERTANOK A HATÉKONYSÁG ELLEN METHOLODY VS EFFECTIVENESS Nyitrai Attila YGOMI Europe Kft (ROC Development) Összefoglaló A debreceni székhelyű ROC Development Kft, ami a YGOMI Europe Kft részeként működik, mint a McDonald s cég első számú távoli rendelésfelvételt megvalósító komplex informatikai megoldásszállítója, három éve alakult, és két éve sikeresen alkalmazza a SCRUM fejlesztési módszertant, ebben az előadásban rá akarok világítani egy kicsit a műhelytitokra, bár az elsődleges cél egy általánosabb kép kialakítása volt. A SCRUM tud sikeres lenni, ha azt jól átgondoltan, esetleg az igényekhez igazítottan használják, veszik át. Az előadás címe a Módszertanok a hatékonyság ellen is arra akar utalni, hogy sok olyan fejlesztő cég működik, ahol egy-egy módszertan sokban tudja hátráltatni a tényleges munkát, és sokszor a fejlesztők úgy érzik, hogy a felesleges adminisztráció viszi el az idő nagy részét. Az én meglátásom az, hogy ha a fejlesztők így érzik, akkor ez így is van. Ezen tudni kell változtatni, hatékonyabbá tenni egy módszertant, de ahhoz az kell, hogy ki is legyen próbálva, és rá legyen világítva az egyes gyengeségeire, ami még a legjobban megkomponált, és tapasztalati tényeke alapuló technikáknál is előfordul, hiszen minden cég más, minden termék egyedi(nek kellene lennie) Kulcsszavak Fejlesztési módszertan, SCRUM Abstract The ROC Development is seated at Debrecen and works as a branch of the YGOMI Europe Kft. as the first service provider of McDonald s remote order taking solution. ROC Development was formed 3 years ago and has been using SCRUM methodology for 2 years now. However the original plan was to form a general picture, in the lecture I am highlighting workshop secrets as well. Used wisely and adjusted to the needs, SCRUM can be a success. The title of the lecture is Methodologies Against Efficiency (Módszertanok a hatékonyság ellen) refers to those development companies, where different methodologies can serious drawbacks on work efficiency and where developers feel that administration takes most of the time. My view is that if many developers see it this way, they must be right. Companies must be ready for a change and to enhance the methodology they are using but this requires testing the methodology, finding the weak spots of the methodology, what is quite common even in case of experience based methods as all companies are different and all products are (should be) unique. Keywords Methodology of IT development, SCRUM 1
2 1. SCRUM módszertanról pár szóban - bevezetés 1.1. Történet A Scrum egy projektmenedzsment módszertan, az agilis szoftver fejlesztés egyik eszköze. Bár a scrum eredetileg szoftverfejlesztési projektek menedzselésére készült, szoftverkarbantartásra is használják. Ellentétben a hagyományos, prediktív, tervezős módszerrel a scrum egyik alapelve az, hogy a megrendelő a fejlesztés során meggondolhatja magát azzal kapcsolatban, hogy mit akar. A scrum nem törekszik a probléma teljes megértésére és definiálására, hanem arra törekszik, hogy a csapat gyors legyen és reagáljon a változó követelményekre SCRUM az YGOMI ROC-nál A YGOMI ROC-nál 2005-től kezdve kezdtük el használni és hasznosítani a módszertant, ha nem is egészében véve, pontról pontra az ajánláshoz tartva magunkat, de a sarokköveket kötelező érvénnyel betartva. Mivel Ken Schwaker-rel a SCRUM egyik atyjával az amerikai központunkban dolgozók közül többeknek is szerencséjük volt előzőleg együtt dolgozni, az elkötelezettség már korábban is megvolt. 2. Dedikált személyek 2.1. Product owner - az ügyfél A fejlesztés szempontjából tekinthető kívülállónak, bár tőle jönnek a többé-kevésbé megfogalmazott igények elsősorban. Majd egy üzleti elemzést követően pontosítja a képet, de akkor már a fejlesztő csapat dedikált személyével együtt Scrum master - az irányító A scrum master sokszor egy már létező csapat vezetője (team leader) vagy egy nagyobb szervezeti egység irányítója (PM). Minden megb eszélésnek kell lennie egy irányítójának (moderátor), aki úgymond levezényli az adott témakörben összehívott meetinget. A scrum master főbb feladatai A csapat szakmai irányítása A csapat irányítása humán-erőforrás kezelés szerint Feladatok koordinálása o Irányadás o Code-review (átadható más senior státuszú csapattagnak is) Megbeszélések levezénylése o Felkészülés a megbeszélésre, témafelvetés o Dokumentálás 2.3. Scrum team - a megvalósítók Egy adott feladat végrehajtására mindig egy csapatot kell deklarálni, ahol jól k övethetőek a hatáskörök, jogok és kötelességek. A team a feladat kiszabása előtt véglegesedik, összetételét felső vezetők határozzák meg. 2
3 2.4. Mindenki más... Az iterációba szükség szerűen bekapcsolódnak olyan személyek, akik a csapat munkáját segítik, de nem tekinthetőek szorosan véve a csapat tagjainak. Ilyenek lehetnek például: Business analyst (üzleti elemző) Architect (tervező-mérnök) Project manager Technical writer (Műszaki Dokumentáció Készítő) IT director (műszaki igazgató) Tesztelők (software assurance és teszter team) Más csapatok tagjai Külső szakmai és üzleti tanácsadók 3. A SCRUM folyamatlépcsői 3.1. Üzleti igények Sokszor előfordul, hogy az ügyfél nem tudja (akarja) pontosan, lépésről-lépésre meghatározni azokat a sarokpontokat, amik támpontok lehetnek egy informatikai projectben. Természetesen alapvető elképzelése (vision) van a kész termékről, de elfogadható az az álláspont is, hogy ő nem kivitelező, ebben az esetben informatikai szakember, nem tudja, nem kell tudni lépésekre lebontani a teendőket. Ilyen kor lép be a képbe a fejlesztő cég (csapat) által kirendelt személy, az üzleti elemző, aki alapos górcső alá veszi a meglévő (átírandó) rendszert vagy interjúk során kialakítja az az elképzelést, ami pontosan le tudja fedni az új rendszer funkcionalitását. Ennek kimenete az úgynevezett "requirement document", azaz igénydokumentáció. Majd ezt követően a "detailed functional specification", ami már részletesen leírja, kifejti a születendő megoldáscsomag működését Rendszer igényei Miután képet kapott a fejlesztő csapat arról, hogy mi is lenne a feladat. Ismert a komplexitása, kapcsolatrendszere más rendszerekkel, elvárt funkciói, akkor meg kell határozni a következő tényezőket Infrastruktúra Szükséges idő (emberórában vagy embernapban) Szükséges fejlesztő cs apat o fejlesztők száma o csapatösszetétel (junior, developer, senior) 3.3. Tervezés Habár a fejlesztés a SCRUM-ban iteratív, ami magában foglalja, az egyes részekre való visszatérés lehetőségét is, a fejlesztés soha nem indulhat el szakmai tervezés nélkül. Ennek a folyamatnak a dedikált személyei: Team leader Mivel az ő feladata a team koordinálása, neki kell elsődlegesen magáénak érezni a feladatot, és minden lépésével tisztában lennie. Development project manager 3
4 Felsőbb irányítás valósítja meg a team szempontjából kapcsolattartó is az ügyféllel. Vertikális irányban nyújt segítséget, azaz a konkrét fejlesztésnél is jelen van. Architect A rendszer egészéről alkotott képpel rendelkező személy, ő dönti el, hogy az egyes fejlesztések beleillenek-e és ha igen, hogyan az egészbe. Horizontális rálátással rendelkezik, interfész definíciókkal, kapcsolatrendszer felépítésével, fejlesztési irányadásokkal segíti a team-et. Business analyst 3.4. Fejlesztés (kódolás, tesztelés) A fejlesztést a csapat (team) végzi, a team leader segítsé gével, aki opcionálisan végezhet fejlesztést is. Mivel a fejlesztés nem csak a kódolásból áll, szükség szerűen be kell vonni más részlegek team-jeit, elsősorban a SA (teszter) csapatra kell gondolni. Bár a tesztelés több fázisú developer teszt - a fejlesztő csapat tagja tesztelik SA teszt - informatikus szakemberek, de nem csapat tagok tesztelik preproduction teszt - a megrendelő (ügyfél) szakemberei tesztelik 3.5. Integráció Összetett rendszereknél fontos tényező a rendszer integráltsága. Nagyon fontos, hogy milyen verziójú komponensek, milyen más verziójúakkal tudnak, képesek együtt működni. Az ROC-nál a verziókövetés több lépcsőjét is elkülönítjük, úgymint developer verzió - legfrissebb, fejlesztés alatt álló, de nem publikus released verzió - tesztelésre kiadott verzió, de még házon belül marad sign-off verzió - tesztelők és felsőbb vezetők által szignózott publikus verzió in production verzió - az ügyfél tesztjén átesett, be élesített verzió 3.6. Telepítés A termék (fejlesztési) életútja végén mindig a telepítés áll. Az ügyfélnél lévő informatikai specialistákból álló csoport, az úgy ITOps (információtechnológiai operátorok csoportja) végzi a telepítést miden esetben. Persze ez "éles" rendszer telepítése (inicializálás vagy frissítés) már akkor jöhet szóba, ha az ún. preprod rendszeren ők azt kitesztelték. A tesztelési folyamat leírására, megkönnyítésére több dokumentum is a rendelkezésükre áll. Mindkettő a technical writer csapat által előállítva. user guide - felhasználói kézikönyv deployment guide - telepítési útmutató 4. A sprint mint a fejlesztési folyamat A sprint az a folyamat, amelyben egy termék vagy egy termék jól körülhatárolható részegysége elkészül vagy magasabb készültségi szintre ér, azaz eléri a megfelelő verziót. 4
5 4.1. Az iteráció mint alaptényező A sprint mint iterációs folyamat A fej lesztés iteratív folyamatként zajlik a ROC-n belül, ez annyit is tesz, hogy egy problémára való legjobb megoldást nem biztos, hogy az első fejlesztési folyamat végén (sprint) el tudják érni a csapattagok. Tehát lehetőség nyílik arra, hogy egy sprint végén levonva a tanulságokat, újra neki lehessen futni a probléma jobb, célszerűbb, lényegre törőbb megoldásának. Bár ez inkább rekurzió A megoldást szinte soha nem egy lépésben, azaz egy sprint alatt tudják elérni, hanem több sprint végeredménye egy jól működő termék A sprint ideális hossza A sprintnek mindig könnyen lefuthatónak kell lenni. Mivel az iterációk gyors egymásutánban következnek, nem célszerű egy sprintet egy hónapnál hosszabb időre tervezni. Bár a túl rövid sprintnek is megvan az a hátránya, hogy az elkészült termék nem tesz hozzá kellő mértékben az összképhez. Az egy hónapnyi átfutás pedig elégnek kell lennie ahhoz, hogy értékelhető és produktív legyen a termék Önmenedzselés vs feladatkiosztás Minden egyes feladatot a csapat tagjai kérik maguknak. Ugyanis az üzleti elemző által megfogalmazott product backlog item-eket a scrum master fejlesztési szempontból jól körülhatárolt sprint backlog item-ekké konvertálja. A sprint indulásakor ezeket a részfeladatokat kell majd kiosztani, de úgy, hogy csak akkor lehet rátaksálni valamit egy csapattagra, ha az a item előzőleg nem kelt el, azaz els ődlegesen mindenki magának választ feladatot. Természetesen a scrum master meghatározhatja azon csapattagok körét, akik bizonyos feladatokból nem választhatnak. Ergo kritikus feladatot ne kapjon már meg egy újon. 5
6 5. Megbeszélés típusok 5.1. Sprint tervezés A sprint tervezése egy úgynevezett sprint plannaing meetingen megy végebe, de ekkor már az üzleti elemzések lezajlottak, és a scum master által létrejönnek az egyes részfeladatok. Itt publikálódik a sprint célja, végtermékének (amennyire csak lehet) pontos meghatározása. Többször előfordul, hogy ezt a megbeszélést meg kell előznie egy másik, ezt előkészítő meetingnek, ahol a scrum master a product owner-rel egyeztet, ez a sprint pre-planning meeting. Szoftver háttér A sprint ledokumentálásához a Microsoft Team Fundation Server-ét használjuk, ami megenged saját lekérdezések definiálását is, de sok előre beépített riport, grafikon, ellenőrzési pont segíti a munkát. Moduláris szemlélet Minden esetben moduláris megközelítést alkalmazunk, még akkor is, ha ez nehéz vagy körülményes. A sprint jól meghatároz egy terméket, részterméket, modult. Ergo már a metodika is úgy kívánja meg, hogy egymással kommunikáló, de jól elkülöníthető részegységek alkossák a solution-t. A verziókról pár szóban Egy termék három fázison esik át a fejlesztési fázisban o release Ha egy csapat elvégezte a munkát, és a scrum master kiadás kész állapotúnak ítéli meg a terméket, akkor a csapat egy dedikált tagja release-t készít belőle. Ami annyit tesz, hogy installálható verziót készít el, és csatolja hozzá a fejlesztés alatt keletkezett ún. develop dokumentumokat, ezek többnyire folyamatábrák, funkcionális leírások. o SA sign-off A software assurance team felel azért, hogy a kiadot termék minőségét leellenőrizzék, az esetleges hibákat ledokumentálják, priorizálják, és egy bizonyos minőségi szint felé érve minősítsék kiadhatónak. Ez abban valósul meg, hogy az SA team által letesztelt, és jónak ítélt termék egy igazgatói aláírást (sign-off) kap, és így elhagyhatja a fejlesztői területet, kiküldhető az ügyfélhez. o in production Az ügyfél szükség és igény szerint még saját tesztelési metódusoknak is alávetheti a terméket, kipróbálhatja, funkcionális, integrációs és stressz tesztelésnek vetheti alá, bár ez megtörténik az SA által is Stand-up meeting Mikor már elindult a sprint, minden egyes munkanap kezdetén lennie kell egy ún. stand-up meetingnek. Ezt természetesen a scrum master vezeti, és nevéből adódóan nem lehet túl hosszú, hiszen elvileg le sem lehet ülni, mert az is csak a megbeszélés hosszát növeli. A stand-up meeting-nek több állandó eleme van 6
7 a csapattagok visszajeleznek az előző napi munkájukról, mit sikerült teljesíteni, mivel vannak elmaradva a csapattagok ismertetik, hogy aznapra milyen munkát terveztek (ebbe a scrum master csak akkor szól bele, ha valaki kifutott a munkából) az esetleges szűk keresztmetszetekről (előre nem látott nehézségekről) mindenkinek tájékoztatást kell adni a team számára (itt nagy szerepe van a scrum master-nek, mert az ő feladata ezeket megoldani szakmailag (kutatás) vagy erőforrás áthelyezéssel) 5.3. Sprint closing meeting A sprint ugyan rövid átfutású, és sokszor kézzelfogható végterméke van, de egy közös szemléletmód kialakítása céljából mindig javallott egy összegzést csinálni, erre hivatott ez a meeting. Sok más mellett a következő pontokra mindenképpen ki kell térni a sprint lezárásakor Előremutató megoldások ebben a sprintben Előre nem látott, de a továbbiakban kikerülhető buktatók Megfelelő hatékonyságú erőforrás elosztás Információáramlás megfelelő volta Esetleges szakmai képzések (belső/külső) Intersprint (sprintek közti) idő tervezése 6. Feladatok 6.1. Taskok, bugok, issue-k, A TFS több fajta feladattípust enged deklarálni, de ez a három mindenképpen kiemelendő. Task Tervezett feladat, ez már a sprint kezdetekor tudott Bug Az SA (vagy developer) által talált hiba, aminek a mértéke lehet több féle cosmetic, low, normal, high, critical, issue Az issue lényegében egy rendszerfüggetlen bug, ergo egy olyan hátráltató tényező, ami nem volt tervezett, de a csapatnak kell megoldani, ha időre akarják implementálni a feladatokat 6.2. Dokumentálás A dokumentálást a technical writer team csapathoz kapcsolt tagjai végzik. Ebben a fázisban több típusú dokumentumnak kell elkészülnie, hogy az SA által elfogadott minőségűnek lehessen minősíteni egy terméket Deployment guide Telepítési útmutató. Részletes, pontokba szedett leírás arról, hogyan lehet az adott terméket működésbe helyezni, illetve beintegrálni a már működő rendszerbe, vagy upgrade-elni egy előző verziót Operational manual 7
8 Működtetési kézikönyv. Hogyan, kiknek, mikor kell manuális interakciót folytatni a komponenssel mint adminisztratív személy (hálózati rendszergazda, DBA, technikai személyzet, stb...) User guide Felhasználói kézikönyv. Ez a dokumentáció szól a végfelhasználónak. 7. A sprint végterméke 7.1. Termék-e a termék? Ha erre egy szóval akarok válaszolni, akkor azt kell mondjam, hogy NEM. Mint az előzőekből kiderült a sprint végtermékeként előálló informatikai szoftver vagy szoftvercsomag, még nem biztos, hogy életképes önmagában, és be kell várnia más termékeket, amit esetleg más csapatok fejlesztenek, más határidőre Egymásra épülő sprintek A project managerek egyik fő feladata az, hogy az alájuk tartozó csapatok munkáját koordinálják. 8. Mikor érdemes sprintben fejleszteni, mikor nem? 8.1. Gyakorlati példa - YGOMI ROC Reporting team Az ROC kereten beleül működő reporting team nem fejleszt sprintekben. Ennek az az oka, hogy olyan mennyiségű ad-hoc jellegű riportra van még jelenleg is szükség a tengerentúli üzleti egységeknek, hogy itt maximum pár napos sprintekről beszélhetnénk, és annak tetemes részét csak a feladatok ledokumentálása venne el, s így bár tartanak stand-up meetingeket, és a feladataikat TFS-be rögzítik is, de nem futnak sprinteket. 9. Mit érdemes részben átvenni a SCRUMból, ha az egészet nem is? 9.1. Gyakorlati példa a ROC egészéről Az itt leírtak nem fedik le teljes egészében a SCRUM fejlesztési módszertant, ez "csak" az a vetülete, amit mi jónak láttunk átvenni. S bár maga a SCRUM jól körülhatárolt, pontosan definiált feladatokat, feladatköröket fogalmaz meg, mi megpróbáltunk a saját ritmusunknak, elgondolásainknak is teret engedni, és azokat a sarokköveket megtartani, amikről mi is úgy gondoljuk, hogy alapjában véve pozitív irányba befolyásolják a munkánk hatékonyságát. Van olyan csapat, aki nem fut sprintet soha, van olyan akiknek nincs project managere, van olyan, hogy bizonyos termékeknél nem ragaszkodunk a rögzített release folyamathoz. Mindez azt mutatja, hogy megpróbálunk rugalmasan alkalmazkodni a felmerülő igényekhez, hogy minél hatékonyabban oldjuk meg a feladatainkat, javítsuk a hibáinkat, és végső soron a hatékonyságunkat. 10. Összegzés A debreceni székhelyű ROC Development Kft, ami a YGOMI Europe Kft részeként működik, mint a McDonald's cég első számú távoli rendelésfelvételt megvalósító komplex informatikai megoldásszállítója, három éve alakult, és két éve sikeresen alkalmazza a 8
9 SCRUM fejlesztési módszertant, ebben az előadásban rá kívántam világítani egy kicsit a műhelytitokra, bár az elsődleges cél egy általánosabb kép kialakítása volt. A SCRUM tud sikeres lenni, ha azt jól átgondoltan, esetleg az igényekhez igazítottan használják, veszik át. Az előadás címe: Módszertanok a hatékonyság ellen végül is arra akar utalni, hogy sok olyan fejlesztő cég működik, ahol egy-egy módszertan sokban tudja hátráltatni a tényleges munkát, és sokszor a fejlesztők úgy érzik, hogy a felesleges adminisztráció viszi el az idő nagy részét. Az én meglátásom az, hogy ha a fejlesztők így érzik, akkor ez így is van. Ezen tudni kell változtatni, hatékonyabbá tenni egy módszertant, de ahhoz az kell, hogy ki is legyen próbálva, és rá legyen világítva az egyes gyengeségeire, ami még a legjobban megkomponált, és tapasztalati tényeke alapuló technikáknál is előfordul, hiszen minden cég más, minden termék egyedi(nek kellene lennie) Felhasznált irodalom [1] Mező Csaba - SCRUM interpretation in ROC (2008, belső dokumentum) [2] Szacsúri László - Csoportmunka- és feladatszervezési methodológiák (2007, DE) 9
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észletesebbenFejlesztési projektek menedzselése IBM Rational CLM termékekkel. Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó
Fejlesztési projektek menedzselése IBM Rational CLM termékekkel Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó Tartalom I. CLM termékek rövid ismertetése II. Projekt menedzsment módszertanokról III. Demo
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenTeszt 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észletesebbencí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észletesebbenINPUT PROGRAM 2. Kanban és SCRUM. KANBAN alapok
INPUT PROGRAM 2. Kanban és SCRUM KANBAN alapok 1 2 3 4 SCRUM alapok 5 Mit ígér a SCRUM? Mennyire bonyolult? 6 A SCRUM két alapelve Empirikus folyamat: a részletes tervek és meghatározott folyamatok helyét
RészletesebbenSzemléletmód váltás a banki BI projekteken
Szemléletmód váltás a banki BI projekteken Data Governance módszertan Komáromi Gábor 2017.07.14. Fókuszpontok áthelyezése - Elérendő célok, elvárt eredmény 2 - Egységes adatforrásra épülő, szervezeti egységektől
RészletesebbenTESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK
TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
RészletesebbenA Scrum Útmutató. Meghatározó útmutató a Scrumhoz: A játék szabályai. Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland
A Scrum Útmutató Meghatározó útmutató a Scrumhoz: A játék szabályai Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland Tartalomjegyzék A Scrum útmutató célja... 3 A Scrum meghatározása... 3
RészletesebbenHaté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észletesebbenVerifiká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észletesebbenInformatikai 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észletesebbenAmi a vízesésen túl van
Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két
RészletesebbenElő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észletesebbenITIL alapú folyamat optimalizációs tapasztalatok
ITIL alapú folyamat optimalizációs tapasztalatok Berky Szabolcs vezető tanácsadó szabolcs.berky@stratis.hu A Stratisról dióhéjban 1998 2008: 10 éve vagyunk a tanácsadási piacon Független, tisztán magyar
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. Bánsághi Anna 1 of 54
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT Bánsághi Anna 1 of 54 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK
RészletesebbenV. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
RészletesebbenA TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE
A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenTRL Hungary Kft. Cégismertető. TRL Hungary Kft. www.trl.hu
Cégismertető www.trl.hu Cégismertető A 2000. óta Magyarország, Szlovénia, Horvátország, Finnország és a balti államok regionális Maconomy disztribútora. A ezenkívül Európától Ázsiáig számos nemzetközi
RészletesebbenSzoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar
Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver
RészletesebbenFolyamatmodellezé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észletesebbenSAS szoftverek felhasználási lehetőségei a felsőoktatásban
SAS szoftverek felhasználási lehetőségei a felsőoktatásban Hodász Attila BDX Kft. Abrán József SAS Magyarország Miért SAS? Integrált keretrendszer amely a teljes feladat támogatására alkalmas Kiforrott
RészletesebbenA személyes siker tényezői az amerkai vállalati kultúrában az NI példája alapján
A személyes siker tényezői az amerkai vállalati kultúrában az NI példája alapján Pajor Ferenc National Instruments Hungary Értelmezés. A számítástechnikai vállalatok, egységek, osztályok sikeres működése
RészletesebbenA 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észletesebbenKis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével. Gyutai Balázs Loxon Tessényi András - Supercharge
Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével Gyutai Balázs Loxon Tessényi András - Supercharge Kik Vagyunk Szoftverfejlesztő cégünk nagy üzleti tudással és
RészletesebbenUnit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22
Unit Teszt Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 1 / 22 Tartalomjegyzék 1 Bevezetés 2 Unit Teszt 3 Példa Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 2 / 22 Szoftvertesztelés
RészletesebbenAngolul: 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észletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
RészletesebbenA projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál
A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál Előadó: Ulicsák Béla műszaki igazgató BRIT TECH Üzleti Tanácsadó Kft. Napirend 1. Az építő-, szerelőipar érdekcsoportjai
Részletesebben01. 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Összefoglaló jelentés
Összefoglaló jelentés A 2018. évi országgyűlési képviselők választásának lebonyolítási időszakában a választást támogató informatikai rendszerek működése során történt informatikai események vizsgálatáról
RészletesebbenKERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS
KERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS BEVEZETÉSÉRE ÉS TÁMOGATÁSÁRA 1 TARTALOMJEGYZÉK Vezetői Összefoglaló...3 Projekt
RészletesebbenFunkciópont elemzés: elmélet és gyakorlat
Funkciópont elemzés: elmélet és gyakorlat Funkciópont elemzés Szoftver metrikák Funkciópont, mint metrika A funkciópont metrika alapelveinek áttekintése Bonyolultsággal korrigált funkciópont A funkciópont
RészletesebbenIT Szolgáltatás Menedzsment az oktatási szektorban - 90 nap alatt költséghatékonyan
IT Szolgáltatás Menedzsment az oktatási szektorban - 90 nap alatt költséghatékonyan Bácsi Zoltán Bedecs Szilárd Napirend Közép Európai Egyetem (CEU) bemutatása IT stratégia kialakítása Változás előtt Termék
RészletesebbenIntelligens 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észletesebbenDIAGNOSZTIKA - A FOLYAMAT FELMÉRÉS LEGHATÉKONYABB ESZKÖZE
ERP-rendszerek bevezetésének csupán egyharmada mondható sikeresnek. Unalomig ismert tény, hogy az informatikai projektek mintegy 2/3-a sikertelennek minősíthető, és még a fennmaradóknak is csupán csekély
RészletesebbenMIÉ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észletesebbenA cloud szolgáltatási modell a közigazgatásban
A cloud szolgáltatási modell a közigazgatásban Gombás László Krasznay Csaba Copyright 2011 Hewlett-Packard Development Company HP Informatikai Kft. 2011. november 23. Témafelvetés 2 HP Confidential Cloud
RészletesebbenDR. SZABÓ LÁSZLÓ 1 DOBOS GÁBOR 2
Szolnoki Tudományos Közlemények XIII. Szolnok, 2009. DR. SZABÓ LÁSZLÓ 1 DOBOS GÁBOR 2 JAK-52 OKTATÓ REPÜLŐGÉP EGY KONSTRUKCIÓS PROBLÉMÁJÁNAK MEGOLDÁSI LEHETŐSÉGEI FESTO FLUIDSIM SZOFTVER FELHASZNÁLÁSÁVAL
RészletesebbenHogyan lehet megakadályozni az üzleti modellezés és az IT implementáció szétválását? Oracle BPM Suite
Hogyan lehet megakadályozni az üzleti modellezés és az IT implementáció szétválását? Oracle BPM Suite Petrohán Zsolt Vezető tanácsadó zsolt.petrohan@oracle.com Napirend Oracle Fusion Middleware BPM kihívásai
RészletesebbenTest Strategy. Monotonitá s tűrése (0 5) Biztonsági tudás (0 5) Adatbázis ismeret (0 5)
Test Strategy Agilis módszertant alkalmazunk a projektjeink tesztelése során, ahol rövid sprintekben dolgozunk, melyekben csak néhány követelményre fokuszálunk. Előzőekből adódik, hogy ezen feladatok nem
RészletesebbenSoftware Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/
RészletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
RészletesebbenLaborinformációs menedzsment rendszerek. validálása. Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH)
Laborinformációs menedzsment rendszerek validálása Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH) Tartalom Túl a címen 17025:2017(8) elvárásai Gondolatok a NAH-tól LIMS validálás Számoló táblák/eszközök
RészletesebbenFogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...
RészletesebbenA MINŐSÉGÜGY SZERVEZETI KITERJESZTÉSE ÉS A PROBLÉMÁK MEGOLDÁSA DOKUMENTUM MENEDZSMENT RENDSZER ÁLTAL
A MINŐSÉGÜGY SZERVEZETI KITERJESZTÉSE ÉS A PROBLÉMÁK MEGOLDÁSA DOKUMENTUM MENEDZSMENT RENDSZER ÁLTAL IdeSol Vezetési és Informa3kai Tanácsadó K: Wiandt László vezető tanácsadó The Ideal Solu3on www.idesol.hu
RészletesebbenMinőségmenedzsment és Informatika Test-Driven Development
Minőségmenedzsment és Informatika Test-Driven Development Varga Balázs G5S8 2008.10.27 Szoftverfejlesztés jellemzői Megrendelői igények Tervezés Implementálás Tesztelés Dokumentálás
RészletesebbenA Projekt portfoliómenedzsment projekt iroda (PMO) alkalmazási feltételei, lehetőségei - szekció bevezető gondolatok
A Projekt portfoliómenedzsment projekt iroda (PMO) alkalmazási feltételei, lehetőségei - szekció bevezető gondolatok Szalay Imre, PMP PMI Budapest 18. PM Forum, 2014. április 9. 1 A projektek feladata
RészletesebbenFolyamatmodellezé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 Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
RészletesebbenAdattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.
Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel Németh Rajmund Vezető BI Szakértő 2017. március 28. Szövetkezeti Integráció Központi Bank Takarékbank Zrt. Kereskedelmi Bank FHB Nyrt.
Részletesebben(Teszt)automatizálás. Bevezető
(Teszt)automatizálás Bevezető Órák ( az előadások sorrendje változhat) 1. Bevezető bemutatkozás, követelmények, kérdések és válaszok 2. Előadás Unit test in general, 3. Előadás Unit test, Tools and practices,
RészletesebbenKövetelmény alapú minőségbiztosítás az államigazgatásban
Követelmény alapú minőségbiztosítás az államigazgatásban László István 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Témák Követelmény
RészletesebbenTisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu
Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu BEVEZETŐ az ASP-szolgáltatásról Az ASP-szolgáltatás (Application Service Providing) előnyei A megrendelő
RészletesebbenSzoftver technológia. Projektmenedzsment eszközök. Cserép Máté ELTE Informatikai Kar 2019.
Szoftver technológia Cserép Máté ELTE Informatikai Kar 2019. Szoftvereszközök A fejlesztőcsapat munkáját megfelelő szoftvereszközökkel kell alátámasztani projektmenedzsment eszközzel (project tracking
Részletesebbenextreme 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észletesebbenMegfelelés a PSD2 szabályozásnak, RTS ajánlásokkal Electra openapi
Megfelelés a PSD2 szabályozásnak, RTS ajánlásokkal Electra openapi Gyimesi István Fejlesztési vezető gyimesi.istvan@cardinal.hu CARDINAL Kft. Termékbemutató 2017.05.31. Heiter Ferenc Termékfejlesztési
RészletesebbenTest Management Strategy Document. Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán
Test Management Strategy Document Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán Agenda Bevezetés Ki mit tud statisztika Tesztelési környezet Felelősségek, szerepek és feladatok Tesztelési
RészletesebbenKÉPZÉSI PROGRAM. GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02. Szolnok
KÉPZÉSI PROGRAM GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02 Szolnok 2015 KÉPZÉSI PROGRAM A képzési program Megnevezése Gazdasági informatikus OKJ azonosító 54 481 02 A képzés során megszerezhető kompetenciák
RészletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK TESZTELÉSI TECHNIKÁK KIVÁLASZTÁSA
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK TESZTELÉSI TECHNIKÁK KIVÁLASZTÁSA MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
RészletesebbenProjektmenedzsment 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észletesebbenCloud computing. Cloud computing. Dr. Bakonyi Péter.
Cloud computing Cloud computing Dr. Bakonyi Péter. 1/24/2011 1/24/2011 Cloud computing 2 Cloud definició A cloud vagy felhő egy platform vagy infrastruktúra Az alkalmazások és szolgáltatások végrehajtására
RészletesebbenGYÁRTÓ VÁLLALAT VEVŐI AUDITJA
GYÁRTÓ VÁLLALAT VEVŐI AUDITJA MORAUSZKI Kinga posztgraduális képzésben résztvevő hallgató Debreceni Egyetem, ATC Műszaki Főiskolai Kar Műszaki Menedzsment és Vállalkozási Tanszék 4028 Debrecen, Ótemető
RészletesebbenCloud computing Dr. Bakonyi Péter.
Cloud computing Dr. Bakonyi Péter. 1/24/2011 Cloud computing 1/24/2011 Cloud computing 2 Cloud definició A cloud vagy felhő egy platform vagy infrastruktúra Az alkalmazások és szolgáltatások végrehajtására
RészletesebbenProjekt siker és felelősség
Projekt siker és felelősség dr. Prónay Gábor 10. Távközlési és Informatikai Projekt Menedzsment Fórum 2007. április 5. AZ ELŐADÁS CÉLJA figyelem felhívás a siker kritériumok összetettségére, az elmúlt
RészletesebbenMagyar Projektmenedzsment Szövetség
Magyar Projektmenedzsment Szövetség A projektmenedzsment szerepe az irányításban Ulicsák Béla Műszaki igazgató BRIT TECH Üzleti Tanácsadó Kft. bela@brit-tech.hu Budapest, 2010. március 17. Tartalom Bevezető
RészletesebbenMiskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
RészletesebbenDebreceni Szakképzési Centrum
Telefonszám: 52/437-311 Debreceni Szakképzési Centrum A Felnőttképzési Tevékenység Minőségbiztosítási Kézikönyve (FTMK) Érvényességi terület: Jelen kézikönyv az intézmény minőségbiztosítási rendszerének
RészletesebbenBlackBerry Professional Server szoftver
BlackBerry Professional Server szoftver Telepítési útmutató 1. Telepítési útmutató A következő dokumentum csatolt ábrák segítségével mutatja be a BlackBerry Professional Server szoftver telepítését. A
RészletesebbenSLA RÉSZLETESEN. 14. óra
14. óra SLA RÉSZLETESEN Tárgy: Szolgáltatás menedzsment Kód: NIRSM1MMEM Kredit: 5 Szak: Mérnök Informatikus MSc (esti) Óraszám: Előadás: 2/hét Laborgyakorlat: 2/hét Számonkérés: Vizsga, (félévi 1db ZH)
RészletesebbenSzoftvertesztelés - Bevezető
Szoftvertesztelés - Bevezető Csirmaz Péter Livesoft Kft. 2010.03.13. Bevezetés A szoftvertesztelés egy rendszer vagy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. A
RészletesebbenTesztmérnök: tesztautomatizálási mérnök Feladat: Elvárások: Előnyt jelent: Beágyazott rendszer tesztmérnök beágyazott rendszer tesztmérnök Feladat:
Tesztmérnök: Új munkatársakat keresünk tesztautomatizálási mérnök pozícióba. Várjuk a téma iránt elkötelezett, nyitott és motivált kollégák jelentkezését, tapasztalt, illetve kevésbé tapasztalt jelöltek
RészletesebbenA Java EE 5 plattform
A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési
RészletesebbenBevezeté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észletesebbenTest Strategy. Tartalomjegyzék
Test Strategy Tartalomjegyzék Tartalomjegyzék Bevezetés Beosztások, hatásköri leírások Projekt Menedzser Teszt Menedzser Projekt Asszisztens Tesztelő Emberi erőforrások kezelése Alkalmazottak és kompetenciáik
RészletesebbenRobotot vezérlő szoftverek fejlesztése Developing robot controller softwares
Robotot vezérlő szoftverek fejlesztése Developing robot controller softwares VARGA Máté 1, PÓGÁR István 2, VÉGH János 1 Programtervező informatikus BSc szakos hallgató 2 Programtervező informatikus MSc
RészletesebbenA modern e-learning lehetőségei a tűzoltók oktatásának fejlesztésében. Dicse Jenő üzletfejlesztési igazgató
A modern e-learning lehetőségei a tűzoltók oktatásának fejlesztésében Dicse Jenő üzletfejlesztési igazgató How to apply modern e-learning to improve the training of firefighters Jenő Dicse Director of
RészletesebbenKomponens alapú fejlesztés
Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenObject 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észletesebbenGyöngy István MS osztályvezető
Gyöngy István MS osztályvezető www.emi-tuv.hu Hogyan készítsük el az új MIR dokumentációt, hogyan készüljünk fel a külső fél általi auditra?. 25 éve Magyarországon Tanúsítás / Hitelesítés: NAT akkreditáció
RészletesebbenAzonnali fizetési rendszer megvalósítása
Azonnali fizetési rendszer megvalósítása 2017. 05. 24. Keretek, alapvetések, megoldandók (minden projekt résztvevőnek) 24/7/365-ös működés (folyamatos működés a karbantartások, upgrade-ek alatt is). Tranzakciók
RészletesebbenInformatikai alkalmazásfejlesztő alkalmazásfejlesztő 54 481 02 0010 54 02 Információrendszer-elemző és - Informatikai alkalmazásfejlesztő
A 10/2007 (II. 27.) SzMM rendelettel módosított 1/2006 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről alapján. Szakképesítés,
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (1) Szoftverminőségbiztosítás Bevezetés Tematika Hét Téma 1. Általános bevezetés, minőség koncepciók (termék- és folyamatminőség) szoftver minőségi jellemzők, kritériumok. 2.
RészletesebbenPénzügy, számvitel. Váradi Mónika 2013.01.29.
Pénzügy, számvitel Váradi Mónika 2013.01.29. Pénzügy, számvitel A rendszer megoldást nyújt a teljeskörű pénzügyi, számviteli műveletek elvégzésére a törvényi megfelelőségek biztosítása mellett. Pénzügy,
RészletesebbenSzemélyügyi nyilvántartás szoftver
Személyügyi nyilvántartás szoftver A nexonhr személyügyi nyilvántartás szoftver a személyügyi, továbbképzési és munkaköri adatok kezelését teszi lehetővé. A szoftver támogatja a HR adminisztrációs feladatokat,
RészletesebbenAz Oracle Fusion szakértői szemmel
Az Oracle Fusion szakértői szemmel Pigniczki László ügyvezető igazgató ProMigCon Kft. HOUG 2017. november 8. ProMigCon Kft. 2009 novemberében alakult. Alapvető tevékenység: Oracle E-Business Suite bevezetés,
RészletesebbenTANÚSÍTVÁNY. tanúsítja, hogy a E-Group Magyarország Rt. által kifejlesztett és forgalmazott. Signed Document expert (SDX) Professional 1.
TANÚSÍTVÁNY A HUNGUARD Számítástechnikai-, informatikai kutató-fejlesztő és általános szolgáltató Kft. a 15/2001.(VIII. 27.) MeHVM rendelet alapján, mint a Magyar Köztársaság Informatikai és Hírközlési
RészletesebbenMICROSOFT DYNAMICS NAV RENDSZER SAAS MODELLBEN
Az ERP bevezetések 30%-a amiatt hiúsul meg, mert a bevezetést tervező vállalat nem tudja előteremteni az igényeinek megfelelő ERP rendszer bevezetéséhez szükséges erőforrást, vagy úgy gondolja, hogy az
RészletesebbenDobozos vagy egyedi szoftver
Konstantinusz Kft. 2011 1 Tartalomjegyzék 1 Tartalomjegyzék... 2 2 Bevezetés... 3 3 Mit értünk dobozos vagy egyedi rendszeren... 4 3.1 Dobozos rendszer:... 4 3.2 Egyedi rendszer:... 4 4 A megrendelő szempontjából...
RészletesebbenOracle Enterprise Manager: Az első teljesértékű felhő üzemeltetési megoldás
2011 November 8. New York Palota Hotel Boscolo Budapest Oracle Enterprise Manager: Az első teljesértékű felhő üzemeltetési megoldás Sárecz Lajos, Vezető tanácsadó Oracle Hungary Átfogó felhő üzemeltetés
RészletesebbenTOGAF 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észletesebbenTITLE ON CAP. Subtitle
TITLE ON CAP Subtitle OeBS in Sanofi HOUG Oct, 2014 1 TITLE ON CAP AND ON 2 LINES Bevezetett modulok, főbb funkciók Gyógyszergyártási. vegyipari sajátosságok (minőség, termék-életciklus) Integrációs térkép
RészletesebbenMiskolci 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észletesebbenA 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észletesebbenElőterjesztés a Képviselő-testület 2014. december 16. napján tartott ülésén 6. napirendi pont
Előterjesztés a Képviselő-testület 2014. december 16. napján tartott ülésén 6. napirendi pont Tárgy: Beszámoló a Közös Hivatal tevékenységéről Tisztelt Képviselő-testület! A Magyarország helyi önkormányzatairól
Részletesebben1 SAP Business Transformation and Plan Services Az SAP Business Transformation and Plan Services szolgáltatások jelenleg az alábbiakat tartalmazzák:
Szolgáltatásleírás Üzleti i és Tervezési Szolgáltatások Az SAP Business Transformation and Plan Services olyan tanácsadási és prototípustervezési szolgáltatásokat biztosítanak, melyek a versenyelny érdekében
RészletesebbenIMIR fejlesztése, bevezetése és működés-támogatása - módosító hirdetmény. Közbeszerzési Értesítő száma: 2015/99
IMIR 2014-2020 fejlesztése, bevezetése és működés-támogatása - módosító hirdetmény Közbeszerzési Értesítő száma: 2015/99 1 Beszerzés tárgya: A 2014-2020 programozási időszak Európai Területi Együttműködési
RészletesebbenKinek szól a könyv? Hogyan épül fel a könyv? Megjelenés előtti szoftver A hálózati kézikönyv tartalma A könyv támogatása Kérdések és megjegyzések
Előszó Köszönetnyilvánítás Bevezetés Kinek szól a könyv? Hogyan épül fel a könyv? Megjelenés előtti szoftver A hálózati kézikönyv tartalma A könyv támogatása Kérdések és megjegyzések xiii xv xvii xvii
RészletesebbenTartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet
Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés
RészletesebbenBevezető gondolatok az ISO 9001:2015 és az ISO 14001:2015 szabványok jelentőségéről
Bevezető gondolatok az ISO 9001:2015 és az ISO 14001:2015 szabványok jelentőségéről Sződi Sándor minőség szakértő IFKA Iparfejlesztési Közhasznú Nonprofit Kft. Kérdések várakozások Mit várhatunk az új
RészletesebbenStratégiai döntés előkészítő
DUNAÚJVÁROS MEGYEI JOGÚ VÁROS ÖNKORMÁNYZATA ÁROP-1.A.5-2013-2013-0090 kódszámú Önkormányzati Szervezetfejlesztés projektje 2014. június 30. DOKUMENTUM ADATLAP A projekt címe: A pályázat kódszáma: Fejlesztési
Részletesebben