A fejlesztés módszertana

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

Download "A fejlesztés módszertana"

Átírás

1 A fejlesztés módszertana (A térkép) május május 1/58

2 1. BEVEZETÉS A MÓDSZERTANOK VILÁGÁBA...5 MI A MÓDSZERTAN ÉS MIÉRT VAN RÁ SZÜKSÉG?... 5 A PROGRAMOZÁSTÓL A RENDSZERFEJLESZTÉSIG... 5 Adatbázis kezelés... 6 Túl az oo szemléleten... 6 NEVEZETES SZOFTVERFEJLESZTÉSI MODELLEK... 7 Vízesés modell... 7 Evolúciós fejlesztés... 8 Feltáró fejlesztés...9 Eldobható prototípus készítése... 9 Inkrementális fejlesztés...10 Spirális fejlesztés...11 Újrafelhasználás-orientált fejlesztés...11 Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Rendszerintegráció Formális rendszerfejlesztés...13 KULCSFOGALMAK...14 A használati esetek...14 Használati esetek és architektúrálisan fontos használati esetek Használati estek, mint rendszerhatárok Használati estek, mint funkcionalitás A használati esetek, mint az architektúra meghatározói A használati estek prioritásai meghatározzák a fejlesztés prioritásait Az architektúra...16 Az architektúra az alkalmazás jellege alapján Az iteratív és az inkrementális rendszerfejlesztés...16 Miért van szükség iteratív fejlesztésre Az iteratív fejlesztés tolerálja a követelmények megváltozását Az iteratív fejlesztés csökkenti a kockázatot Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását...19 Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű AZ EGYSÉGESÍTETT ELJÁRÁS...20 AZ EGYSÉGESÍTETT ELJÁRÁS ÁTTEKINTÉSE...20 Az Egységesített Eljárás szoftverfejlesztési módszertan...20 Az Egységesített Eljárás szoftverfejlesztési jellegzetességei...21 AZ EGYSÉGESÍTETT ELJÁRÁS KÉT DIMENZIÓJA...22 Buckás ábra átlós jellege...22 Az időbeli dimenzió...23 Iterációk Fázisok Fázisok és iterációk Előkészítő fázis (Inception) Kidolgozási fázis (Elaboration) Építési fázis (Construction) Átmenet (Transition) A tevékenységbeli dimenzió...26 Üzleti modellezés (business modelling) május 2/58

3 Követelmények összegyűjtése (requirements capture) Elemzés (analysis) Tervezés (design) Implementáció (implementation) Teszt (test)...28 Telepítés (deployment) Támogató munkafolyamatok AZ EGYSÉGESÍTETT ELJÁRÁS ARCHITEKTÚRÁJA...28 AZ EGYSÉGESÍTETT ELJÁRÁS TERMÉKEI...29 Modellek és nézetek...29 Nézetek...30 Modellek...30 A 4+1 nézet...30 Követelmény nézet Logikai nézet Dinamikus nézet Komponens nézet Telepítési nézet A modellek, avagy termék csoportok...31 A termék csoportok és a nézetek kapcsolata HASZNÁLATI ESET VEZÉRELT FEJLESZTÉS...32 A használati esetek, mint az architektúra meghatározói...32 ARCHITEKTÚRA KÖZPONTÚ FEJLESZTÉS...33 Architektúra: strukturálisan fontos elemek és ezek kapcsolata Az architektúrálisan fontos nézetek ITERATÍV ÉS INKREMENTÁLIS FEJLESZTÉS...34 Az iteratív fejlesztés tolerálja a követelmények megváltozását Az iteratív fejlesztés csökkenti a kockázatot Az iteratív fejlesztés biztonságosabb, hibatűrőbb alkalmazást eredményez Az iteratív fejlesztés lehetővé teszi a résztvevők folyamatos tanulását, a módszertan finomítását...34 Az iteratív fejlesztés lerövidíti a fejlesztés időtartamát Az iteratív fejlesztés terv szerű Absztrakt munkafolyamatok és az iterációs munkafolyamatok Az egyes termékcsoportok eltérő növekedése KOCKÁZAT-VEZÉRELT FEJLESZTÉS...36 VIZUÁLIS TERVEZÉS...37 KOMPONENS ALAPÚ FEJLESZTÉS ALKALMAZÁSFEJLESZTÉS...39 TÖBB DIMENZIÓS LEÍRÁS...39 ELLENŐRZÖTT FEJLESZTÉS...39 SZAKTERÜLETI MODELLEZÉS...40 Domain modell...41 Fogalomjegyzék...42 Szakterületi folyamat modell...42 Szakterületi állapotátmenet modell...42 Szakterületi együttműködések modellje...42 Szakterületi aktivitás modell...42 KÖVETELMÉNY FELTÁRÁS...42 Célkitűzés...43 Követelmény modell...43 Felhasználói követelmények Szakterületi követelmények Nem funkcionális követelmények május 3/58

4 Használati eset modell...45 ELEMZÉS ÉS TERVEZÉS...47 Réteg, alrendszer architektúra...48 Funkcionális tagozódás Strukturális architektúra minták...49 Rétegzett architektúra A rétegzett architektúra ajánlott rétegei Az architektúra függése a többi terméktől Dinamikus nézet...50 Szekvencia diagramok Együttműködési diagram Állapot diagram Tevékenység diagram A dinamikus nézet függése a többi terméktől A függések kezelése...55 A naiv fejlesztési sorrend szerinti tevékenységek Fejlesztés csonkok alkalmazásával IMPLEMENTÁCIÓ...57 TESZTELÉS...57 TELEPÍTÉS...57 AZ ELŐKÉSZÍTŐ FÁZIS...57 A KIDOLGOZÁSI FÁZIS...57 AZ ÉPÍTÉSI FÁZIS...57 AZ ÁTADÁSI FÁZIS IRODALOMJEGYZÉK...58 Angolul Magyarul május 4/58

5 1. Bevezetés a módszertanok világába Mi a módszertan és miért van rá szükség? Kezdetben olyan programokat írtunk, ami egytől százig kiírja a prímszámokat. Később egyre többet ismertünk meg, s a feladatok is egyre nőttek. S bár erőnk, képességeink, ismereteink növekednek, de a feladatok bonyolultsága gyorsabban növekszik. Szükségünk van valamilyen módszerre, hogy uralni tudjuk a bonyolultságot. Változnak a programozási eszközök: A hőskorban közvetlenül gépi kódban írták a programokat, aztán megjelent az assembly, majd az úgynevezett magas szintű nyelvek, ma meg színes-szagos 4GL eszközök, hihetetlenül összetett API-k segítik a programozó munkáját. Másrészt, a csupasz programozásról nagyon hamar kiderül, hogy nem elég. Meg kell tervezni a programot. Azonban sokszor nem elegendő, ha csak a programot tervezzük meg, föl kell mérni az igények, ki kell deríteni a követelményeket, a fejlesztés sok résztvevőjét koordinálni kell. Ezzel jutottunk el a szoftver fejlesztési módszertanhoz. A fejlesztés célja a megrendelői, felhasználói igényeknek megfelelő szoftver rendszer előállítása megadott határidőre, megadott költség kereteken belül, s mindez jó minőségben. A megfogalmazott felhasználói igényekből a legritkább esetben vezethető le közvetlenül a teljes szoftver rendszer. A meghatározott peremfeltételek (minőség, határidő, költségek) rendszerint ellentmondanak egymásnak. Klasszikus megfogalmazás szerint 1 a szoftver fejlesztési módszertan o Útmutatást ad a csoportmunka irányítására o Meghatározza, hogy milyen termékeket kell kifejleszteni és mikor o Meghatározza az egyes fejlesztőknek, valamint a csoportnak a feladatát o Kritériumokat ad a termékek és tevékenységek mérésére és minősítésére A cél a felhasználói követelmények és a késztermék közötti szakadék áthidalása. A programozástól a rendszerfejlesztésig Jellemzően egy-egy szemlélet (gépközeli, strukturált, objektum-orientált) legalábbis az eddigiekben a programozás felől indult, programozók találták ki önmaguknak, hogy a saját életüket tegyék kényelmesebbé. 1 Grady Booch, Object Solutions Managing the Object-Orientéd Project. Reading, MA: Addison- Wesley, május 5/58

6 Később ezt a személetet kiterjesztették, elmélet gyártottak mögé, s lett belőle program tervezési módszertan, modellezési szemlélet. Később ez a szemlélet tovább gyűrűzik, lesz belőle szoftver fejlesztési módszertan, aztán rendszertervezés, rendszertervezés, üzleti folyamatok újraszervezése. Azaz a kicsiben jól működő módszereket kiterjesztik, általánosítják és magasabb logikai szintre emelik. Rendszerszervezés Szoftver fejlesztési módszertan Program tervezés Programozás 1. ábra A strukturált szemlélet jól kidolgozott mind a programozásra, mind a program tervezésre (Jackson módszer, Wairner módszer), mind rendszertervezésre (SSADM). Ma az objektumorientált szemlélet a programozásban megkerülhetetlen (szinte minden 4GL eszköz az oo szemléletre épít), vannak jól kidolgozott program tervezési módszerek (OMT, UML, Design patterns), s az oo szemlélet mostanság kezdi kiterjedni a szoftver fejlesztés módszertanok területére (Egységesített Eljárás). Jelenleg még valóban oo szemléletű rendszerszervezési módszertan nincsen. ADATBÁZIS KEZELÉS További érdekesség, hogy bár az adatbázis-kezelés logikailag nagyjából a programozással egy absztrakciós szinten van, de mind a mai az adatbázis-kezelésben szinte egyeduralkodó a strukturált (relációs; Codd féle) szemlélet. Bár kísérletek meglehetősen hosszú ideje folynak oo adatbázis-kezelőkkel, de valóban használható, valóban oo szemléletű adatbázis-kezelő nincsen piaci forgalomban. TÚL AZ OO SZEMLÉLETEN Természetesen az oo szemlélet nem végállomás, nem old meg mindent, vannak olyan feladatok, helyzetek, amikre az oo szemléletnek nincsen kellően jó megoldása. Léteznek is kísérletek, kutatások az oo szemlélet meghaladására, talán a két legígéretesebb irányzat a minták alkalmazása (patterns), illetve az extrém programozásnak május 6/58

7 nevezett szemlélet. Közös azonban ezekben a kísérletekben, hogy nem elvetik, hanem továbbfejlesztik az oo szemléletet, és megvalósításukat tekintve is jellemzően oo eszközökre támaszkodnak. A programozáson túli területek (szoftver fejlesztési módszertanok, rendszerfejlesztés területén pedig még nyomai is alig látszanak az oo szemléleten túli megközelítéseknek, azaz még jó pár évig van létjogosultsága az oo szemléletnek. Nevezetes szoftverfejlesztési modellek A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le. Az alább ismertetendő modellek ritkán jelennek meg tiszta, ideális formában, sokkal inkább a fejlesztési folyamat egyfajta logikai absztrakciója. Vízesés modell 2 A szoftver fejlesztés első publikált modellje (1970), ami viszonylag stabil körülmények között mind a mai napig jól működik. A fejlesztési folyamatot fázisokra bontja, a fázisok szigorúan egymás után következnek, minden egyes fázisra jellemzőek azok a dokumentumokat, amiket el kell fogadni ( alá kell írni ) a továbblépéshez. A gyakorlati alkalmazásban a fázisok többé-kevésbé átfedhetik egymást. Az egyes fázisok végrehajtása iteratív tevékenység. A dokumentumok előállításának, jóváhagyásának a költségei miatt elfogadott gyakorlat, hogy egy-egy fázist már néhány iteráció után befagyasztanak, a problémák megoldását lehagyják, kikerülik avagy későbbre halasztják. Ez viszont törvényszerűen azt eredményezi, hogy a rendszer már az átadás pillanatában sem felel meg az éppen aktuális követelményeknek. Ugyanakkor a rejtett, lappangó felhasználói igények, tapasztalatok csak nagyon későn, a rendszer működtetése során kerülnek felszínre. 2 [Som] május 7/58

8 Követelmények meghatározása Elemzés Tervezés Implementáció és egységtesztelés Integráció és rendszerteszt Működttetés és karbantartás 2. ábra Ez a fejlesztési modell akkor alkalmazható hatékonyan, ha a követelmények jól definiáltak és stabilak. Ebben ez esetben viszont hatékony munkafolyamatot biztosít. Evolúciós fejlesztés 3 Az evolúciós fejlesztés alapötlete, hogy a kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyűlt tapasztalatokat építsük be egy újabb termék verzióba. Ezt a folyamatot mindaddig ismételjük, amíg el nem érjük a kívánalmaknak már megfelelő rendszert. Ez a megközelítési mód sokkal inkább lehetővé teszi párhuzamosságot és a sokkal gyorsabban csatolja vissza a fejlesztési folyamatba a menet közben felmerülő felhasználói igényeket. 3 [Som] május 8/58

9 Specifikáció Fejlesztés Végső termék verzió Validálás Közbenső termék v erzió 3. ábra Két lényegében eltérő típusa ismert: FELTÁRÓ FEJLESZTÉS A fejlesztés célja, hogy a megrendelővel szorosan együttműködve feltárjuk a valós igényeket és kifejlesszük a végleges rendszert. A rendszer fejlesztését a már ismert részekkel kell kezdeni, s újabb és újabb elemek hozzáadásával jutunk el a végtermékig. ELDOBHATÓ PROTOTÍPUS KÉSZÍTÉSE Az evolúciós fejlesztés célja a követelmények mennél pontosabb feltárása. A prototípus próbálgatásos módszerrel közelíti meg a követelményeket, első sorban az ismeretlen követelmények feltárására koncentrál. Az eldobható prototípus készülhet más technológiával, s belső strukturálására sem kell akkor a figyelmet fordítani, illetve a sokszori átdolgozás miatt törvényszerű, hogy a belső struktúra nehezen átláthatóvá válik. Az eldobható prototípust végtermékké minősíteni, avagy az eldobható prototípus kódját közvetlenül felhasználni a végtermékben súlyos szakmai hiba. A prototípuskészítés akkor hatékony, ha a követelmények nem ismertek a fejlesztési folyamat elején. Sommerville 4 szerint rövid élettartamú, kicsiny, közepes ( ezer sornál kisebb) rendszereknél hatékony. Ugyanakkor nagyobb rendszerek esetében az evolúciós megközelítés nehézségei kritikussá válhatnak. Hátránya ennek a modellnek, hogy A fejlesztési folyamat előrehaladása nem látható, nem mérhető. Ez gyakran pro- 4 [Som] május 9/58

10 jektmenedzselési gondokhoz vezet. Rosszul strukturált, nehezen továbbfejleszthető terméket eredményez. Inkrementális fejlesztés 5 Hibrid megközelítési mód, a vízesés illetve az evolúciós modell előnyeit ötvözi. A fejlesztés indításakor a megrendelő vázlatosan közli a követelményeit, illetve meghatározzák mely követelmények a fontosabbak, s melyek kevésbé fontosak. Az első inkremens kifejlesztésével párhuzamosan folyat a további inkremensek specifikálása, tervezése. Amikor egy inkremens elkészül, azt integrálni kell a már elkészült rendszerbe, s utána azt a felhasználó használatba is veheti. Az üzemeltetéssel kapcsolatos tapasztalatok visszacsatolhatóak a további inkremensek tervezésébe. Követelmények vázlatos meghatározása Követelmények inkremensekhez rendelése Rendszer architektúra meghatározása Inkremens fejlesztése [Nem teljes a rendszer] Inkremens v alidálása Inkremens integrálása Rendszer v alidálása [Végleges rendszer] 4. ábra Az egyes inkremensek fejlesztése történhet eltérő fejlesztési modell alapján is. A jól definiált követelményeket kielégítő inkremensek fejleszthetőek a vízesés modell alapján, míg, ahol a specifikáció nem kellően egyértelmű, ott alkalmazható az evolú- 5 [Som] május 10/58

11 ciós megközelítés. Az inkrementális fejlesztés előnye, hogy A megrendelőnek nem kell megvárnia a teljes rendszer elkészültét, hanem már az első inkremens átadása után használhatja a rendszer legfontosabb szolgáltatásait. A korábban kifejlesztett inkremensek tekinthetők prototípusnak, a használatuk során szerzett tapasztalatok beépíthetőek a fejlesztés folyamatába. Csökkenti a kockázatot. Az egyes inkremensekben ugyan lehetnek hibák, azonban valószínű, hogy ezek az egész projekt kudarcát okozzák. A magas prioritású inkremenseket szállítjuk le először, így azok lesznek a legjobban kitesztelve. Az egyes inkremenseknek viszonylag kicsinyeknek kell lenniük (Sommerville 6 szerint 20 ezer sornál kisebbek), minden egyes inkremensnek szolgáltatni kell valamilyen rendszerfunkciót. Időnként nehézségeket okozhat a rendszer ilyen méretű elemekre való particionálása. A fejlesztés kezdetén számos a későbbi inkremensekben megvalósítandó rendszerfunkció még nincsen kellő pontossággal definiálva, ezért a rendszer közös alapszolgáltatásainak a meghatározása nehézségekbe ütközhet. Spirális fejlesztés 7 Az iteratív megközelítés során a fejlesztés mintegy spirál vonalban halad előre, a felhasználó, avagy a megrendelő rendszeresen megkapja az újabb és újabb futtatható program verziókat. Tervezés és prototípus Modellezés és design Használat és újabb követelmények Implementáció 5. ábra Újrafelhasználás-orientált fejlesztés 8 Jelenleg még viszonylag szűkebb körben alkalmazott fejlesztési megközelítés, azon- 6 [Som] 7 [Som] 8 [Som] május 11/58

12 ban feltehetőleg a közeli jövőben egyre többen fogják tudatosan ezt a megközelítést választani. A fejlesztési folyamatot a meglévő komponensek újrafelhasználása határozza meg. Jelentős méretű komponens könyvtárak létét tételezi fel. Ebben a megközelítésben a komponens nem csak a 4GL eszközök szokásos, finom szemcsézettségű komponensei (nyomógombok, címkék, stb.), hanem nagyméretű, üzleti komponensek (főkönyv, kezelő alrendszer, stb.) is lehetnek, gyakran önálló létjogosultsággal rendelkező alrendszerek (pl.: szövegszerkesztő, számolótábla, stb.) Követelmények specifikációja Komponens elemzés Követelmények módosítása Rendszertervezés újrafelhasználással Fejlesztés és integráció Rendszervalidáció 6. ábra KOMPONENSELEMZÉS A hozzáférhető komponensek a legritkább esetben valósítják meg a rendszertől elvárt szolgáltatásokat, jellemzően a kívánalmaknak csak egy részét elégítik ki, s sokszor egyéb, nem igényelt szolgáltatásokat is nyújtanak. KÖVETELMÉNYMÓDOSÍTÁS A rendelkezésre álló komponens szolgáltatások és a követelmények összehangolása. Ez történhet a követelmények megváltoztatásával, illetve történhet újabb komponensek beszerzésével, esetleg kifejlesztésével is május 12/58

13 RENDSZERTERVEZÉS ÚJRAFELHASZNÁLÁSSAL A készítendő rendszer vázát kell meghatározni, avagy egy már meglévő struktúrát kell felhasználni. Hangsúlyos tevékenység a komponensek együttműködésének a biztosítása. RENDSZERINTEGRÁCIÓ A megvásárolt, illetve a kifejlesztett komponensek összeépítése. Ebben a fejlesztési modellben az integráció lényegesen fontosabb tevékenység, mint a többi megközelítési módban. E módszer csökkenti a fejlesztési időt és a kockázatokat. Ugyanakkor a leszállított rendszer törvényserűen tartalmaz kompromisszumokat a követelmények meghatározása területén, ami a rendszer használhatóságát rontja. Az összeépítendő komponensek ritkán eredményeznek tiszta, átlátható architektúrát, az architektúrális gyengeségek akadályozhatják a továbbfejlesztés. A komponensek számos, a rendszer szempontjából felesleges kódot illetve szolgáltatást tartalmazhatnak, amik szintén ronthatják a rendszer struktúráját. Formális rendszerfejlesztés 9 A fejlesztés kiinduló pontja egy matematikailag egzakt rendszerdefiníció. Ezt a formális definíciót matematikailag meghatározott, ellenőrzött transzformációkkal alakítják át működő rendszerré. A matematikailag egzakt program helyesség bizonyítás hihetetlenül drága. Ezzel szemben a formális fejlesztés során mindig matematikailag egzakt lépések történnek, így a fejlesztés végén az elkészült termék törvényszerűen megfelel a specifikációnak. Ez a fejlesztési modell biztonság, avagy védelem kritikus rendszerek fejlesztése során használatos, egyéb fejlesztésekben alig használják 9 [Som] május 13/58

14 Követelmények meghatározása Formális specifikáció Formális transzformációk Integráció és rendszertesztek 7. ábra Kulcsfogalmak A használati esetek HASZNÁLATI ESETEK ÉS ARCHITEKTÚRÁLISAN FONTOS HASZNÁLATI ESETEK Az aktor a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől. A használati eset a rendszernek egy értelmes kerek egysége. A használati eset kívülről írja le a rendszer viselkedését, szolgáltatásait. Architektúrálisan fontosnak nevezzük azokat a használati eseteket, amelyek a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg. Ilyen architektúrálisan fontos használati eset a mikrohullámú sütő esetében a sütés, a számlázó estében a számla készítés, avagy a családfa felderítő esetében a családfa felderítése. Egy-egy alkalmazás esetében jellemzően egy, vagy csak néhány architektúrálisan fontos használati eset szokott lenni. Nagy, összetett rendszerek esetében ez az alrendszerek szintjén igaz. A használati esetek határozzák meg, hogy o mit fejlesztünk? (rendszerhatárok, funkcionalitás) o milyen sorrendbe fejlesszük? (prioritás) o milyen legyen a termékünk belső szerkezete (architektúra) május 14/58

15 HASZNÁLATI ESTEK, MINT RENDSZERHATÁROK A rendszer határát a rendszer által nyújtott, a felhasználó számára fontos funkciók adják. Azt kell kifejleszteni, amire a felhasználónak szüksége van. Nem többet és nem kevesebbet. 8. ábra A kulcsfontosságú használati estek rajzolják körül a rendszer szolgáltatás halmazát. A későbbiekben csak azok a szolgáltatások indokoltak, amik szervesen kapcsolódnak az architektúrálisan fontos használati esetekhez, s minden olyan igény, ami nincsen szerves kapcsolatban az architektúrálisan fontos használati esetekkel, azok rendszeridegenek, azokat egy másik alkalmazásban kell elhelyezni. Az alkalmazás is egy objektum: van egy, logikailag összefüggő, zárt felelősségi köre. Ne pakoljuk tele az alkalmazást fölösleges csingilingikkel! HASZNÁLATI ESTEK, MINT FUNKCIONALITÁS A rendszer teljes funkció-halmazát a fentebb említett a kulcsfontosságú használati esetek részletes lebontása, illetve az ezekhez tartozó kiegészítő, járulékos használati esetek adják. A rendszer feladata a felhasználó számára hasznos szolgáltatások nyújtása. Ebben a megközelítésben a használati esetek által nyújtott funkció térkép adja a rendszer külső szempontból való leírását. Ezek a használati esetek nagyban befolyásolják a rendszer másik négy nézetét is. A HASZNÁLATI ESETEK, MINT AZ ARCHITEKTÚRA MEGHATÁROZÓI A használati esetek a rendszer funkcionális tagolását, függőleges, felosztását, a funkcionális alrendszerekre való felosztás határozzák meg. A HASZNÁLATI ESTEK PRIORITÁSAI MEGHATÁROZZÁK A FEJLESZTÉS PRIORITÁSAIT Általánosságban elmondható, hogy célszerű előbb megvalósítani a központi funkciókat, majd később foglalkozni a periférikus feladatokkal. Lényegestől, fontostól a kevésbé lényeges felé, a központtól a periférikus részek felé célszerű haladni a fej május 15/58

16 lesztéssel. Mind a műszaki, mind a piaci kockázatok jelentősen csökkenthetőek, a központi részek viszonylag korai kialakításával. Az architektúra AZ ARCHITEKTÚRA AZ ALKALMAZÁS JELLEGE ALAPJÁN 10 Az alkalmazás jellege (egyed, vagy kontroll, vagy határ dominanciájú alkalmazás) befolyásolja, hogy a tervezési modell mely sztereotípusai lesznek architektúrálisan meghatározóak. Control Entity Boundary 9. ábra Entitás dominanciájú alkalmazások Ezek a klasszikus információs rendszerek, fő feladatuk az adatkezelés. Az architektúrára lényeges hatással van a domain modell, illetve a perzisztens tárolás az esetek többségében ez SQL táblákat jelent. Megvalósítására további tervezési minták állnak rendelkezésre. Meglehetősen gyakori alkalmazás típus. Felület dominanciájú alkalmazások Jellegzetes desktop alkalmazások, szövegszerkesztők, kép-manipuláló programok, vizuális felhasználói környeztek, stb. Az architektúrát a határ jellegű elemek dominálják, az architektúra leírásánál a határ jellegű elemek osztály illetve együttműködés diagrammjai a mérvadóak, valamint a felhasználói felület prototípusa. Algoritmus dominanciájú alkalmazások Az architektúrát a megvalósítandó algoritmusok döntően befolyásolják. Meglehetősen ritkák fordulnak elő a napi fejlesztői gyakorlatban ilyen alkalmazások. Az iteratív és az inkrementális rendszerfejlesztés MIÉRT VAN SZÜKSÉG ITERATÍV FEJLESZTÉSRE Egyszerű, kicsiny rendszerek esetében alkalmazható a feladat definiálása, tervezés, kódolás, tesztelés szekvenciális, vízesésszerű fejlesztési mód. Nagyobb, bonyolultabb rendszerek esetében más módszert kell keresni. A megren- 10 Részletesebben lásd a szerző Architektúra tananyagában május 16/58

17 delői, felhasználói igények is folyamatosan változnak. A hagyományos vízesés-modell alkalmazásakor számos hiányosság, félreértés, hiba csak a fejlesztés végén, a tesztelési fázisban bukik elő. Ugyanakkor ez a modell nagyon nehezen viseli el a fejlesztési célok menet közbeni megváltozását. Kockázat Követelmény elemzés Tervezés Implementáció Tesztelés Átadás 10. ábra Szemben a vízesés-modellel az iteratív fejlesztés lényegesen rugalmasabb, s így kisebb a kockázata is. A fejlesztés iteratív megközelítése beépíti a módszertanba a fokozatos megértést, illetve az igények folyamatos változását. Ugyanakkor lehetővé teszi a kockázatok korai felismerését és kezelését. Idő május 17/58

18 Kockázat Előkészítés Vízesés Kidolgozás Iteratív Építés Átadás 11. ábra Idő AZ ITERATÍV FEJLESZTÉS TOLERÁLJA A KÖVETELMÉNYEK MEGVÁLTOZÁSÁT A határidő illetve a költségek túllépése általában a megváltozott követelményekből adódik. A fejlesztés időtartama alatt viszont a követelmények törvényszerűen megváltoznak, mivel a rendszer környezete, a szabályok és az előírások, a technológia is változik, a felhasználók folyamatosan ismerik meg a rendszer szolgáltatásait. A fejlesztési iterációk eredményeként létrejövő újabb és újabb szoftver verziókat a megrendelő rendszeresen megkapja, így szoros a kapcsolat a megrendelői és a fejlesztői csapat között. A megváltozott követelményeket viszonylag hamar be lehet építeni a rendszerbe. Az iteratív fejlesztés viszonylag jól tolerálja a taktikai jellegű változtatásokat. Elképzelhető, hogy az üzleti viszonyok változása miatt hamarabb kell piacra dobni a terméket az iteratív fejlesztés esetén az egyes iterációk végeredménye kibocsátható termék. AZ ITERATÍV FEJLESZTÉS CSÖKKENTI A KOCKÁZATOT Az egyes iterációk által előállított termékeket a megrendelő megkapja, teszteli így a követelmények megváltozása, az esetlegesen pontatlanul, avagy hiányosan rögzített követelményekre viszonylag hamar fény derül, s ezzel jelentősen csökkenti az üzleti jellegű kockázatokat. A műszaki jellegű kockázatok jelentős része a késői integrációból adódik. A klasszikus, vízesés-szerű fejlesztés esetében az egyes részrendszerek integrációja a fejlesztés végén, egyetlen nagy összeépítési kampányban (big bang) történik meg. A hibák és a kockázatok jelentős részére az integrációkor derül fény. Iteratív fejlesztés esetén folyamatos az integráció. A folyamatos integráció révén az május 18/58

19 egyes kockázati elemekre hamar fény derül, az esetlegesen hézagosan illeszkedő elemek javítására több idő van. AZ ITERATÍV FEJLESZTÉS BIZTONSÁGOSABB, HIBATŰRŐBB ALKALMAZÁST EREDMÉNYEZ Iteratív fejlesztésnél a rendszer tesztelése az integrációval együtt, már a fejlesztés korai szakaszában elkezdődik. A sokszori tesztelésnek köszönhetően valószínűbb, hogy még a fejlesztés időszaka alatt felszínre kerülnek az esetleges rejtett hibák, illetve a kritikus kódrészleteknek van idejük megérni. AZ ITERATÍV FEJLESZTÉS LEHETŐVÉ TESZI A RÉSZTVEVŐK FOLYAMATOS TANULÁSÁT, A MÓDSZERTAN FINOMÍTÁSÁT Az iteratív fejlesztési folyamat során több lehetőségük van a fejlesztésben résztvevő személyeknek, hogy a módszertant és a fejlesztési technológiákat elsajátítsák, gyakorolják. Az iterativitás, az inkrementális növekedés miatt ez esetleges hibáknak, emberi tévedéseknek kisebb a kockázata: a rendseres tesztelés az esetleges tökéletlen megoldásokat fel fogja deríteni. A fejlesztői csapat személyi összetétele egy hosszabb fejlesztés során meg szokott változni. Iteratív fejlesztés során az új tagoknak lehetőségük van a módszertan, a belső szabványok, szokások, konvenciók elsajátítására. Az egyes iterációk végén az áttekintés nem csak a fejlesztés eredményét, a terméket vizsgálja, hanem magát a fejlesztési folyamat, a fejlesztői csapatban is javasolhat változtatásokat. AZ ITERATÍV FEJLESZTÉS LERÖVIDÍTI A FEJLESZTÉS IDŐTARTAMÁT Az iteratív fejlesztés növeli a fejlesztés hatékonyságát, lerövidíti a fejlesztés időtartamát, mert az egymást követő munkafolyamatok hamarabb elkezdhetők. Az implementációnak meg kell várnia a tervezés befejezését, a tesztelésnek meg kell várnia az implementációt, a kézikönyvek és oktató anyagok írásával meg kell várni a végleges, kijavított verziót, stb. Az iteratív fejlesztés a teljes fejlesztést sok mini-projektre bontja fel, s ezek a mini-projektek egymástól többé-kevésbé függetlenül fejleszthetők. Az egyes szakterületek, munkafolyamatok technológia függése megmarad, azonban több, részben párhuzamos mini-projekt esetében az egyes szakterületek egymásra való várakozása jelentősen csökkenhet. Az iteratív fejlesztés révén könnyebb felismerni az újrafelhasználható szoftver komponenseket is. AZ ITERATÍV FEJLESZTÉS TERV SZERŰ Vannak, akik az iteratív és inkrementális fejlesztést az ötletszerű, kapkodó fejetlen munka tudományos megfogalmazásának vélik, s mint ilyen ellen berzenkednek. Ezzel szemben az iterációik tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre megtervezik május 19/58

20 2. Az Egységesített Eljárás ábra: az Egységesített Eljárás szimbóluma Az Egységesített Eljárás áttekintése Az Egységesített Eljárás szoftverfejlesztési módszertan A fejlesztés célja a megrendelői, felhasználói igényeknek megfelelő szoftver rendszer előállítása megadott határidőre, megadott költség kereteken belül, s mindez jó minőségben. A megfogalmazott felhasználói igényekből a legritkább esetben vezethető le közvetlenül a teljes szoftver rendszer. A meghatározott peremfeltételek (minőség, határidő, költségek) rendszerint ellentmondanak egymásnak. Az Egységesített Eljárás, mint szoftverfejlesztési módszertan meghatározza, hogy ki, mit és mikor csináljon a közös cél érdekében, illetve ajánlásokat ad az ellentmondások feloldására. Felhasználói követelmények Sw. fejlesztési módszer 13. ábra Sw. rendszer Természetesen az Egységesített Eljárás nem több, mint egy forgatókönyv, ad ajánlásokat, ad módszereket de a fejlesztést élő, hús-vér személyek végzik, a konkrét fejlesztés sajátosságainak az ismeretében nekik kell dönteniük a felmerülő kérdésekben. Több, mint programozás módszertan foglalkozik szakterületi, üzleti modelle- 11 [Jacobson+99], [RUP2001A] május 20/58

21 zéssel, elemzéssel. Kevesebb, mint a klasszikus szervezéstudomány nem foglalkozik a reálfolyamatok újraszervezésével, racionalizálásával, csak a szoftver fejlesztésére koncentrál. Életciklus szerint teljes az első ötlet felmerülésétől a termék teljes haláláig végigkíséri a teljes életciklust, beleértve az újabb és újabb verziók kifejlesztését is. 12 Szakterület szerint alkalmas mindenféle szoftver termék fejlesztésére, nem csak információs rendszerek ( adatmasszírozó alkalmazások ) kifejlesztésére koncentrál. 13 Objektum-orientált módszertan, azaz a ma divatos, hatékony programozási paradigmával szinkronban van, nincs szükség szemléleti transzformációra, sőt a jelölésrendszer is azonos (UML). 14 Viszonylag fiatal módszertan, azaz számos helyen kiforratlan. Az Egységesített Eljárás szoftverfejlesztési jellegzetességei Szinte minden, az Egységesített Eljárással foglalkozó publikációban visszatér a módszertan jellemzéseként a RUP három legfontosabb jellegzetessége, s e jellegzetességek felsorolásában lényegében minden szerző egyetért. A hasonlat szerint a háromlábú szék egy-egy lába a módszertan egy-egy jellegzetessége: Használati eset vezérelt milyen célra? Architektúra központú mi a lényege? Iteratív és inkrementális hogyan? 14. ábra Az Egységesített Eljárás e három jellegzetessége egymást kölcsönösen feltételezi, egymás nélkül értelmetlenek a kisszéknek szüksége van mindhárom lábára, hogy stabilan álljon. További jellegzetességek: o Objektum-orientált 12 Az SSADM alig fordít figyelmet a tényleges megvalósításra, az implementációra, illetve az implementáció közeli tervezésre. 13 Az SSADM alapfeltevése, hogy információs rendszert építünk, van adatbázisunk, s az adatbázisunk megvalósítása relációs. Mindezeket a korlátokat az Egységesített Eljárás nem tartalmazza. 14 Az SSADM strukturált módszertan, azaz nem ismeri az oo szemlélet fogalmait, az SSADM tervet le kell fordítani oo tervre május 21/58

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

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

Projectvezetők képességei

Projectvezetők képességei Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés

Részletesebben

Objektum orientált software fejlesztés (Bevezetés)

Objektum orientált software fejlesztés (Bevezetés) Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok

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-technológia aspektusai

Részletesebben

4. A szoftvergyártás folyamata

4. A szoftvergyártás folyamata 4. A szoftvergyártás folyamata Kérdések Mi a szoftvergyártás modellje? Mi a három alapvető modell és mikor használjuk ezeket? Mik a követelménytervezés, a szoftverfejlesztés, a tesztelés és az szoftver-evolúció

Részletesebben

Szoftvermenedzsment 4. fejezet A szoftverfolyamat

Szoftvermenedzsment 4. fejezet A szoftverfolyamat 4. fejezet A szoftverfolyamat Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai és Gazdasági Intézet 2007. július 1 A szoftverfolyamat Ahogyan az első fejezetben megbeszéltük: A szoftverfolyamat

Részletesebben

SW-project management

SW-project management SW-project management 1 PM tárgya tervezés megfigyelés ellenőrzés emberek folyamat események 4P People (emberek) Product (termék) Process (folyamat) Project PM szintjei 3 SW előállítási folyamat bizonytalansága

Részletesebben

A dokumentáció felépítése

A dokumentáció felépítése A dokumentáció felépítése Készítette: Keszthelyi Zsolt, 2010. szeptember A szoftver dokumentációját az itt megadott szakaszok szerint kell elkészíteni. A szoftvert az Egységesített Eljárás (Unified Process)

Részletesebben

Alkalmazá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 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észletesebben

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység MINISZTERELNÖKI HIVATAL Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1188-06/1 Szóbeli vizsgatevékenység Szóbeli vizsgatevékenység időtartama: 45 perc A 20/2007. (V. 21.) SZMM rendelet

Részletesebben

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció CCS Hungary, 2000 szeptember Handling rendszer technikai specifikáció Hálózati architektúra SITA Hálózat/ Vám/ Internet/... CodecServer üzenet központ DB LA N Laptop computer RAS elérés Adatbázis szerver

Részletesebben

ALKALMAZÁS KERETRENDSZER

ALKALMAZÁS KERETRENDSZER JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak

Részletesebben

Komponens alapú fejlesztés

Komponens 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észletesebben

1. Bevezetés a szoftvertechnológiába

1. Bevezetés a szoftvertechnológiába 1. Bevezetés a szoftvertechnológiába Kérdések Mi a szoftvertechnológia (szoftvermérnökség)? Mik a szoftvertechnológiát érintő legfontosabb kérdések és válaszok? Etikai és szakmai kérdések: hogyan érintik

Részletesebben

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt Programozási Technológia 1. 1. előadás bevezetés Előadó: Lengyel Zsolt Tartalom Információk a tantárggyal kapcsolatban Programozási technológiai eszközök áttekintése UML tervezőeszközök JAVA fejlesztőeszközök,

Részletesebben

Tamagocsi Projektterv

Tamagocsi Projektterv Tamagocsi Projektterv Csapat: CamelCase { Laczik Sándor János; Szőke Gábor; Vasas Szabolcs; } Évfolyam: PTI MSc II. 2011/2012 1. Összefoglaló A feladat egy PC-n futtatható tamagocsi játék fejlesztése.

Részletesebben

IRÁNYTŰ A SZABÁLYTENGERBEN

IRÁNYTŰ A SZABÁLYTENGERBEN IRÁNYTŰ A SZABÁLYTENGERBEN amikor Bábel tornya felépül BRM konferencia 2008 október 29 BCA Hungary A Csapat Cégalapítás: 2006 Tanácsadói létszám: 20 fő Tapasztalat: Átlagosan 5+ év tanácsadói tapasztalat

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

Programrendszerek tanúsítása szoftverminőség mérése

Programrendszerek tanúsítása szoftverminőség mérése SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát

Részletesebben

Rational Unified Process

Rational Unified Process RUP áttekintés Cs. Vég (2001) 1 Rational Unified Process Áttekintés Vég Csaba (www.logos2000.hu) ( 2001 ) RUP áttekintés Cs. Vég (2001) 2 A fejlesztés folyamata A Unified Process a rendszerfejlesztés folyamatát

Részletesebben

Cégprofil publikus CÉGPROFIL 1

Cégprofil publikus CÉGPROFIL 1 CÉGPROFIL 1 BEMUTATKOZÁS A Molaris Kft-t magyar magánszemélyek alapították 2006-ban, jelenleg is 100%-ban magyar tulajdonban van. Cégünk legfontosabb célkitűzése, hogy kiemelkedő színvonalú szolgáltatásai

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Szoftver minőségi alapkérdések Hogyan hasznosítsuk a know-how-t

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment

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

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Tartalom. 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észletesebben

Települési ÉRtékközpont

Települési ÉRtékközpont TÉR Települési ÉRtékközpont Lajosmizse Város Önkormányzata településüzemeltetési és - fejlesztési programjának kidolgozása KÉPZÉS menedzsment VANIN 2009. Erőforrás gazdálkodás- üzemeltetés benchmark Cél,

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

Hát én immár mit válasszak?

Hát én immár mit válasszak? Hát én immár mit válasszak? Az SQI szoftverminőséggel kapcsolatos kutatási projektjei Dr. Balla Katalin 2005.04.15. ~ A környezet ~ Az SQI kutatási-fejlesztési projektjei ~ TST ~ IKKK Miről lesz szó 2005.04.15.

Részletesebben

Programtervezés. Dr. Iványi Péter

Programtervezés. Dr. Iványi Péter Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű

Részletesebben

Tartalom A projektmenedzser teendői Projekttervezés Projekt ütemezés Kockázatkezelés

Tartalom A projektmenedzser teendői Projekttervezés Projekt ütemezés Kockázatkezelés 5. Projektmenedzsment Kérdések Mik a projektmenedzsment legfontosabb feladatai? Mik a szoftvermenedzsment legfőbb ismertető jegyei? Mi a projekttervezés és hogyan zajlik? Hogyan használhatók a grafikus

Részletesebben

Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi

Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi Projektterv Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi Verziók: Verzió Dátum Szerző Státusz Megjegyzés 0.1 2008.10.14 Balikó Ivett Tervezet Kiindulási változat, véleményezésre 0.2 2008-10-20

Részletesebben

Osztott Objektumarchitektúrák

Osztott Objektumarchitektúrák 1. Kliens szerver architektúra Osztott Objektumarchitektúrák Dr. Tick József Jól bevált architektúra Kliens-szerver szerepek rögzítettek Szerver szolgáltatást nyújt, vagy igénybe vesz Kliens csak igénybe

Részletesebben

Fogalomtá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. 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észletesebben

Fejleszté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ó 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észletesebben

Komponens alapú szoftverfejlesztés. 1. Előadás Bevezetés

Komponens alapú szoftverfejlesztés. 1. Előadás Bevezetés Komponens alapú szoftverfejlesztés 1. Előadás Bevezetés 1. Bevezetés Hagyományos, nem komponensalapú fejlesztés: általában top-down, felülrőllefelé haladó módszer Komponensalapú fejlesztési módszer: bottom-up,

Részletesebben

Szoftverfejlesztő képzés tematika oktatott modulok

Szoftverfejlesztő képzés tematika oktatott modulok Szoftverfejlesztő képzés tematika oktatott modulok 1148-06 - Szoftverfejlesztés Megtervezi és megvalósítja az adatbázisokat Kódolja az adattárolási réteget egy adatbáziskezelő nyelv használatával Programozás

Részletesebben

1 Informatikai beszerzések.

1 Informatikai beszerzések. 1 Informatikai beszerzések. Az informatikai szabályzat beruházási fejezete az informatikai eszközök beszerzésével kapcsolatos belső tevékenységet, illetve a szállítóktól elvárt, a beszállítás részeként

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai

Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai Török Tamás Szántó Iván torok.tamas@ulx.hu szanto.ivan@ulx.hu ULX Open Source Consulting

Részletesebben

A kockázatközpontú környezetmenedzsment átfogó kérdései. Zöldi Irma VITUKI Kht.

A kockázatközpontú környezetmenedzsment átfogó kérdései. Zöldi Irma VITUKI Kht. A kockázatközpontú környezetmenedzsment átfogó kérdései Zöldi Irma VITUKI Kht. Modern Mérnöki Eszköztár Kockázat-alapú Környezetmenedzsment megalapozásához MOKKA Nemzeti Kutatási Fejlesztési Programok

Részletesebben

Üzletmenet folytonosság menedzsment [BCM]

Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment Megfelelőség, kényszer? Felügyeleti előírások Belső előírások Külföldi tulajdonos előírásai Szabványok, sztenderdek, stb Tudatos

Részletesebben

Fekete Csaba Csongor Üzleti intelligencia vezető Citibank ZRt.

Fekete Csaba Csongor Üzleti intelligencia vezető Citibank ZRt. Fekete Csaba Csongor Üzleti intelligencia vezető Citibank ZRt. Tartalom BI mérföld kövek Kezdeti architektúra és kontextus Lokális Adattárház Kialakítása CRM Evolúció Üzleti Intelligencia kiaknázó eszközök

Részletesebben

Hogyan lesz adatbányából aranybánya?

Hogyan lesz adatbányából aranybánya? Hogyan lesz adatbányából aranybánya? Szolgáltatások kapacitástervezése a Budapest Banknál Németh Balázs Budapest Bank Fehér Péter - Corvinno Visontai Balázs - KFKI Tartalom 1. Szolgáltatás életciklus 2.

Részletesebben

OO rendszerek jellemzői

OO rendszerek jellemzői OO rendszerek jellemzői Problémák forrása lehet teszteléskor: Problémák feldarabolása. Adatrejtés. Az OO rendszerek nagyszámú, egymással aktívan kapcsolatban levő, együttműködő komponensekből állnak. A

Részletesebben

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás

Részletesebben

Nyíregyháza Megyei Jogú Város Önkormányzata

Nyíregyháza Megyei Jogú Város Önkormányzata Nyíregyháza Megyei Jogú Város Önkormányzata Projektmenedzsment képzés Oktatási tematika Budapest, 2009. szeptember 4. IFUA Horváth & Partners Kft. H-1119 Budapest Fehérvári út 79. Telefon: +36 (1) 382

Részletesebben

Magas szintű adatmodellek Egyed/kapcsolat modell I.

Magas szintű adatmodellek Egyed/kapcsolat modell I. Magas szintű adatmodellek Egyed/kapcsolat modell I. Ullman-Widom: Adatbázisrendszerek. Alapvetés. 4.fejezet Magas szintű adatmodellek (4.1-4.3.fej.) (köv.héten folyt.köv. 4.4-4.6.fej.) Az adatbázis modellezés

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

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

Szoftverprototípus készítése

Szoftverprototípus készítése Dr. Mileff Péter 1 Szoftverprototípus készítése A prototípus fogalma: a szoftverrendszer kezdeti verziója Mi a célja? Arra használják, hogy bemutassák a koncepciókat, kipróbálják a tervezési opciókat,

Részletesebben

S atisztika 2. előadás

S atisztika 2. előadás Statisztika 2. előadás 4. lépés Terepmunka vagy adatgyűjtés Kutatási módszerek osztályozása Kutatási módszer Feltáró kutatás Következtető kutatás Leíró kutatás Ok-okozati kutatás Keresztmetszeti kutatás

Részletesebben

Fentiek alapján javaslom az értekezés nyilvános vitára bocsátását és a Jelölt számára az MTA doktora fokozat odaítélését.

Fentiek alapján javaslom az értekezés nyilvános vitára bocsátását és a Jelölt számára az MTA doktora fokozat odaítélését. Opponensi vélemény Szerb László: Vállalkozások, vállalkozási elméletek, vállalkozások mérése és a Globális Vállalkozói és Fejlődési Index című MTA doktori értekezéséről Szerb László doktori értekezésének

Részletesebben

Projektmenedzsment projektmenedzsment alapjai logikai kapcsolatban hálótervezés

Projektmenedzsment projektmenedzsment alapjai logikai kapcsolatban hálótervezés Projektmenedzsment A projektmenedzsment alapjai Hálótervezés A könyvtári rendszerfejlesztési projekt A projektmenedzsment alapjai alaptevékenységek a szervezet (rendszerint hosszú távú, a küldetésben és

Részletesebben

A SAJÁTOS NEVELÉSI IGÉNYŰ ÉS/VAGY A FOGYATÉKKAL ÉLŐ TANULÓK RÉSZVÉTELE A SZAKKÉPZÉSBEN SZAKPOLITIKAI TÁJÉKOZTATÓ

A SAJÁTOS NEVELÉSI IGÉNYŰ ÉS/VAGY A FOGYATÉKKAL ÉLŐ TANULÓK RÉSZVÉTELE A SZAKKÉPZÉSBEN SZAKPOLITIKAI TÁJÉKOZTATÓ A SAJÁTOS NEVELÉSI IGÉNYŰ ÉS/VAGY A FOGYATÉKKAL ÉLŐ TANULÓK RÉSZVÉTELE A SZAKKÉPZÉSBEN SZAKPOLITIKAI TÁJÉKOZTATÓ Szakpolitikai kontextus A nemzetközi adatok azt mutatják, hogy a fogyatékkal élő, valamint

Részletesebben

Fejlesztési stratégiák

Fejlesztési stratégiák UML alapok Példa Fejlesztési stratégiák Csapatmunka Stratégia, közös nyelv (modellezési nyelvek, pl. UML) Eszközök: verziókövetés (CVS/SVN), hibajelentés (bugzilla), stb. Klasszikus alapszakaszok, vízesés

Részletesebben

Oktatási környezetek vizsgálata a programozás tanításához

Oktatási környezetek vizsgálata a programozás tanításához Oktatási környezetek vizsgálata a programozás tanításához Horváth Győző, Menyhárt László Gábor Zamárdi, 2014.11.21. Készült az "Országos koordinációval a pedagógusképzés megújításáért című TÁMOP- Tartalom

Részletesebben

SZÁMÍTÓGÉP AZ IRODÁBAN KÉPZÉSI PROGRAM

SZÁMÍTÓGÉP AZ IRODÁBAN KÉPZÉSI PROGRAM SZÁMÍTÓGÉP AZ IRODÁBAN KÉPZÉSI PROGRAM a Felnőttképzésről szóló 2013. évi LXXVII. tv. 12. (1) bekezdésének megfelelően. A képzési program Megnevezése Nyilvántartásba vételi száma Számítógép az irodában

Részletesebben

Felhasználói felületek. Felhasználói felületek. Felhasználói felületek 2011.12.29.

Felhasználói felületek. Felhasználói felületek. Felhasználói felületek 2011.12.29. Felhasználói felületek Dr. Mileff Péter A felhasználói felület az elsődleges kapcsolódási pont a felhasználó és a számítógép között. A jól áttekinthető, gondos felhasználói felület kidolgozása fontos!

Részletesebben

2012.02.08. Ajánlott irodalom. Adatbázisok I.

2012.02.08. Ajánlott irodalom. Adatbázisok I. Ajánlott irodalom Adatbázisok I. Szendrői Etelka főiskolai docens Rendszer- és Szoftvertechnológia Tanszék szendroi@pmmk.pte.hu Ullmann, Jeffry David, Adatbázisrendszerek: Alapvetés Kovács László (2004)

Részletesebben

NETinv. Új generációs informatikai és kommunikációs megoldások

NETinv. Új generációs informatikai és kommunikációs megoldások Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok

Részletesebben

Adatbázis rendszerek 6.. 6. 1.1. Definíciók:

Adatbázis rendszerek 6.. 6. 1.1. Definíciók: Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A

Részletesebben

Információ menedzsment

Információ menedzsment Információ menedzsment Szendrői Etelka Rendszer- és Szoftvertechnológiai Tanszék szendroi@witch.pmmf.hu Infrastruktúra-menedzsment Informatikai szolgáltatások menedzsmentje Konfigurációkezelés Gyorssegélyszolgálat

Részletesebben

A CMMI alapú szoftverfejlesztési si folyamat

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

Részletesebben

VIR alapfogalmai. Előadásvázlat. dr. Kovács László

VIR alapfogalmai. Előadásvázlat. dr. Kovács László VIR alapfogalmai Előadásvázlat dr. Kovács László Információ szerepe Információ-éhes világban élünk Mi is az információ? - újszerű ismeret - jelentés Hogyan mérhető az információ? - statisztikai - szintaktikai

Részletesebben

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László A kockázat alapú felülvizsgálati és karbantartási stratégia alkalmazása a MOL Rt.-nél megvalósuló Statikus Készülékek Állapot-felügyeleti Rendszerének kialakításában II. rész: a rendszer felülvizsgálati

Részletesebben

SZÁMALK SZAKKÖZÉPISKOLA

SZÁMALK SZAKKÖZÉPISKOLA KÉPZÉS MEGNEVEZÉSE: Felhasználóbarát digitális szolgáltatások fejlesztése (Használhatósági szakértő/usability expert alapok fakultáció) Készítette: dr. Mlinarics József ügyvezető elnök Magyar Tartalomipari

Részletesebben

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu Integrált (Elektronikus) Nyomonkövető Rendszer Miért használjuk? Hogyan használjuk?

Részletesebben

Kockázatok az új minőségirányítási rendszerszabvány tervezetében

Kockázatok az új minőségirányítási rendszerszabvány tervezetében Kockázatok az új minőségirányítási rendszerszabvány tervezetében Dr. Horváth Zsolt 2014 A kockázat az új ISO 9001-ben MSZ/T ISO/DIS 9001:2014 (ISO/DIS 9001:2014): Bevezetés 05. Kockázatalapú gondolkodás

Részletesebben

Hő- és füstelvezetés, elmélet-gyakorlat

Hő- és füstelvezetés, elmélet-gyakorlat Hő- és füstelvezetés, elmélet-gyakorlat Mérnöki módszerek alkalmazásának lehetőségei Szikra Csaba tudományos munkatárs BME Építészmérnöki Kar Épületenergetikai és Épületgépészeti Tanszék szikra@egt.bme.hu

Részletesebben

Vállalási szerződés minta

Vállalási szerződés minta Vállalási szerződés minta www.ateoldalad.hu weboldal kivitelezésére. Jelen dokumentum egy szerződésminta, mely kizárólag tájékoztatásra szolgál. Sem ajánlattételnek nem minősül, sem kötelezettséget nem

Részletesebben

Servicedesk bevezetés tapasztalatai Nagy Gábor

Servicedesk bevezetés tapasztalatai Nagy Gábor Servicedesk bevezetés tapasztalatai Nagy Gábor Bevezetés előtti helyzet, kiinduló állapot Szervezet: 4 megoldó csoport, 40 fő megoldó, 20 sap 10 kliens 5 alkalmazás 5 szerver hálózat, területileg széttagolt

Részletesebben

7. számú melléklet Két forduló közötti projektfejlesztési szakasz eljárásrendje a Társadalmi Infrastruktúra Operatív Program

7. számú melléklet Két forduló közötti projektfejlesztési szakasz eljárásrendje a Társadalmi Infrastruktúra Operatív Program 7. számú melléklet Két forduló közötti projektfejlesztési szakasz eljárásrendje a Társadalmi Infrastruktúra Operatív Program A felsőoktatási tevékenységek színvonalának emeléséhez szükséges infrastrukturális

Részletesebben

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében): Követelményrendszer 1. Tantárgynév, kód, kredit, választhatóság: Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K 2. Felelős tanszék: Informatika Szakcsoport 3. Szak, szakirány, tagozat: Műszaki

Részletesebben

Programzás I. - 1. gyakorlat

Programzás I. - 1. gyakorlat Programzás I. - 1. gyakorlat Alapok Tar Péter 1 Pannon Egyetem Műszaki Informatikai Kar Számítástudomány Alkalmazása Tanszék Utolsó frissítés: September 15, 2007 1 tar@dcs.vein.hu Tar Péter (PE-MIK-DCS)

Részletesebben

gyakorlatban nagy.gusztav@gamf.kefo.hu Nagy Gusztáv

gyakorlatban nagy.gusztav@gamf.kefo.hu Nagy Gusztáv A WSDM weboldaltervezési módszer a gyakorlatban nagy.gusztav@gamf.kefo.hu Nagy Gusztáv Webfejlesztés Technikai feladatok: (X)HTML oldalak szerkesztése CSS adatbázis tervezés, megvalósítás programozás Ezekrıl

Részletesebben

Nyílt forráskódú technológiák központi és Önkormányzati környezetekben

Nyílt forráskódú technológiák központi és Önkormányzati környezetekben Nyílt Forráskódú Szoftverek a Közigazgatásban konferencia Nyílt forráskódú technológiák központi és Önkormányzati környezetekben Dr. Szentiványi Gábor ügyvezető ULX Open Source Consulting & Distribution

Részletesebben

Cégprofil publikus CÉGPROFIL 1

Cégprofil publikus CÉGPROFIL 1 CÉGPROFIL 1 BEMUTATKOZÁS A Molaris Kft-t magyar magánszemélyek alapították 2006-ban, jelenleg is 100%-ban magyar tulajdonban van. Cégünk legfontosabb célkitűzése, hogy kiemelkedő színvonalú szolgáltatásai

Részletesebben

EGYSZERŰSÉG ÉS ÁTTEKINTHETŐSÉG AZ ÜZLETI ANALITIKÁBAN CRS PORTÁL AVENSOFT KFT. 1072 BUDAPEST, RÁKÓCZI ÚT 42. WWW.CRSPORTAL.HU WWW.AVENSOFT.

EGYSZERŰSÉG ÉS ÁTTEKINTHETŐSÉG AZ ÜZLETI ANALITIKÁBAN CRS PORTÁL AVENSOFT KFT. 1072 BUDAPEST, RÁKÓCZI ÚT 42. WWW.CRSPORTAL.HU WWW.AVENSOFT. CRS PORTÁL AVENSOFT KFT. 1072 BUDAPEST, RÁKÓCZI ÚT 42. WWW.CRSPORTAL.HU WWW.AVENSOFT.HU EGYSZERŰ KEZELHETŐSÉG ÁTTEKINTHETŐ LOGIKA A CRS Portál egy olyan, web alapú üzleti intelligencia (BI) megoldás, amely

Részletesebben

Döntéselőkészítés. I. előadás. Döntéselőkészítés. Előadó: Dr. Égertné dr. Molnár Éva. Informatika Tanszék A 602 szoba

Döntéselőkészítés. I. előadás. Döntéselőkészítés. Előadó: Dr. Égertné dr. Molnár Éva. Informatika Tanszék A 602 szoba I. előadás Előadó: Dr. Égertné dr. Molnár Éva Informatika Tanszék A 602 szoba Tárggyal kapcsolatos anyagok megtalálhatók: http://www.sze.hu/~egertne Konzultációs idő: (páros tan. hét) csütörtök 10-11 30

Részletesebben

SOA Start.... és összeáll, ami összetett

SOA Start.... és összeáll, ami összetett Start... és összeáll, ami összetett Start szolgáltatások A egy olyan IT-stratégia, mely a teljes vállalat mûködésére hatással van. A stratégia támogatására már több eszköz ESB, BPM, Registry is rendelkezésre

Részletesebben

TECHNOLÓGIÁK A GYAKORLATBAN. Projektmenedzsment. Konstantinusz Kft.

TECHNOLÓGIÁK A GYAKORLATBAN. Projektmenedzsment. Konstantinusz Kft. TECHNOLÓGIÁK A GYAKORLATBAN Projektmenedzsment Konstantinusz Kft. 2010 Esettanulmányomban egy új termék projektmenedzsmentjét szeretném elemezni. A projekt egy konkrét, a kontextustól függő cél vagy célok

Részletesebben

Schindler Útmutató A cél meghatározása. Az út kijelölése. Stratégiai iránymutatás a felvonó és mozgólépcső piacon való siker eléréséhez.

Schindler Útmutató A cél meghatározása. Az út kijelölése. Stratégiai iránymutatás a felvonó és mozgólépcső piacon való siker eléréséhez. Schindler Útmutató A cél meghatározása. Az út kijelölése. Stratégiai iránymutatás a felvonó és mozgólépcső piacon való siker eléréséhez. 2 l Schindler Útmutató Kötelezettségvállalásunk Kedves Kollégák,

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

2. Követelmények (Requirements)

2. Követelmények (Requirements) 2. Követelmények (Requirements) A szoftverfejlesztés első lépése a specifikáció, vagy más néven a követelménytervezés, amelynek célja, hogy meghatározzuk milyen szolgáltatásokat követelünk meg a rendszertől,

Részletesebben

Szakterület modell. Bővítés attribútumokkal. BCE, Információrendszer tanszék, Dr. Molnár Bálint, egyetemi

Szakterület modell. Bővítés attribútumokkal. BCE, Információrendszer tanszék, Dr. Molnár Bálint, egyetemi Szakterület modell Bővítés attribútumokkal Előadás célja A szakterületi modellen belül az attribútumok felismerése és leírása, meghatározása (specifikálása). Az attribútumok elkülönítésének korrekt eljárása

Részletesebben

ELŐADÁS ÁTTEKINTÉSE 9. ea.: Projektek végrehajtása I. Projekt megvalósítás fázisa. Szerződések Projektirányítás

ELŐADÁS ÁTTEKINTÉSE 9. ea.: Projektek végrehajtása I. Projekt megvalósítás fázisa. Szerződések Projektirányítás ELŐADÁS ÁTTEKINTÉSE 9. ea.: Projektek végrehajtása I. Projekt megvalósítás fázisa Projekt napló Szerződések Projektirányítás A PROJEKT MEGVALÓSÍTÁS A MEGVALÓSÍTÁS (2.FÁZIS ) HEFOP 3.3.1. PROJEKT NAPLÓ

Részletesebben

1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT. Az eszköz három fő folyamatot ölel fel három szakaszban:

1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT. Az eszköz három fő folyamatot ölel fel három szakaszban: 1.1. HOGYAN HASZNÁLJUK AZ ÖNÉRTÉKELÉSI ESZKÖZT 1. melléklet Az eszköz három fő folyamatot ölel fel három szakaszban: a pályázók kiválasztása (a táblázat 1. munkalapja); a projekt kedvezményezettek általi

Részletesebben

Szerepjáték Project Story of my life

Szerepjáték Project Story of my life Szerepjáték Project Story of my life Leírás A feladat egy konzol felületű játék elkészítése, amely betekintést kíván adni egy egyetemista életébe. A játék felépítését tekintve szerepjáték, de nem a szokásos

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (11) Szoftverminőségbiztosítás Tesztautomatizálás A tesztelés kivitelezése Tesztelési feladatok Detektálatlan maradék hibák számának csökkentése hatásosan és hatékonyan megfelelő

Részletesebben

Szoftverdokumentáció

Szoftverdokumentáció Szoftverdokumentáció Minden emberi használatra előállított terméket dokumentálni kell. Definíció: A dokumentum tényeket (adatokat) és/vagy szabályokat (eljárásokat, utasításokat, relációkat) tartalmazó,

Részletesebben

Oracle adatkezelési megoldások helye az EA világában. Előadó: Tar Zoltán

Oracle adatkezelési megoldások helye az EA világában. Előadó: Tar Zoltán Oracle adatkezelési megoldások helye az EA világában Előadó: Tar Zoltán Témák Bemutatkozás Enterprise Architecture bemutatása Mi az az EA? TOGAF bemutatása OEAF bemutatása Oracle megoldások Oracle termékek

Részletesebben

ELŐTERJESZTÉS. - a Képviselő-testülethez. A belső ellenőrzésről

ELŐTERJESZTÉS. - a Képviselő-testülethez. A belső ellenőrzésről Mátészalka Város Önkormányzat J e g y z ő j é t ő l 4700 Mátészalka Hősök tere 9.sz. Tel:(44) 501-364 Fax:(44) 501-367 Száma:./2007. ELŐTERJESZTÉS - a Képviselő-testülethez A belső ellenőrzésről Tisztelt

Részletesebben

E-learning tananyagfejlesztő képzés tematika oktatott modulok

E-learning tananyagfejlesztő képzés tematika oktatott modulok E-learning tananyagfejlesztő képzés tematika oktatott modulok 1142-06 - Számítógépkezelés, szoftverhasználat, munkaszervezés o Hardvert üzemeltet, szoftvert telepít o Irodai programcsomagot egyedi és integrált

Részletesebben

Szoftver technológia - 2005 ProgMat -

Szoftver technológia - 2005 ProgMat - Szoftver technológia - 2005 ProgMat - 1. Szoftver életciklus modellek 1.1 Klasszikus waterfall vízesés modell Jellemzői: Technikai problémának tekintia fejlesztést. Nem foglalkozik a kommunikációs csatornákkal.

Részletesebben

STRATÉGIAALKOTÁS, ÜZLETI TERVEZÉS A VÁLLALKOZÁS KREATÍV RÉSZE

STRATÉGIAALKOTÁS, ÜZLETI TERVEZÉS A VÁLLALKOZÁS KREATÍV RÉSZE STRATÉGIAALKOTÁS, ÜZLETI TERVEZÉS A VÁLLALKOZÁS KREATÍV RÉSZE Mi az üzleti tervezés A józan ész diadala az önámítás felett A tervezés tisztán matematika Nagy számok törvénye Egy egész szám felírható néhány

Részletesebben

Component Soft 1994-2013 és tovább

Component Soft 1994-2013 és tovább Component Soft 1994-2013 és tovább IT szakemberek oktatása, tanácsadás Fő témáink: UNIX/Linux rendszerek, virtualizációs, fürtözési, tároló menedzsment és mentési technológiák Adatbázisok és middleware

Részletesebben

Frederick Taylor (1900 körül) A Pennsylvania-i acélműben tanulmányozta a munkafolyamatokat. A munkafolyamatokat szakaszokra bontotta, és különböző méréseket végzett a szakaszokon belüli és a szakaszok

Részletesebben

IT 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 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észletesebben

Részletes ismertetô. Projektmenedzsment

Részletes ismertetô. Projektmenedzsment Részletes ismertetô Projektmenedzsment proalpha - Projektmenedzsment A proalpha projektmenedzsment modul egy olyan eszköz, amellyel minden, a projekttel kapcsolatban felmerülô feladat kezelhetô. A többfelhasználós

Részletesebben