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

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

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

Részletesebben

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

Információtartalom vázlata

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

Részletesebben

Bevezetés a programozásba

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

Részletesebben

Szoftvertermékek csoportjai. A szoftver. Bemutatkozás és követelmények 2011.09.04.

Szoftvertermékek csoportjai. A szoftver. Bemutatkozás és követelmények 2011.09.04. Bemutatkozás és követelmények Dr. Mileff Péter Dr. Mileff Péter - Általános Informatikai Tanszék Fizika Tanszék A/1-303. szoba. Konzultációs idő:???. Követelmények: Vezetett gyakorlat nincs. Jelenléti

Részletesebben

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár Software Engineering Dr. Barabás László Ismétlés/Kitekintő Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, Személyek és szerepkörök Kitekintő: Modell, módszertan 2 Dr. Barabá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

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

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

Részletesebben

Szoftver újrafelhasználás

Szoftver újrafelhasználás Szoftver újrafelhasználá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

Szoftverfejlesztési modellek

Szoftverfejlesztési modellek i modellek Ha egy kitűzött célt el akarunk érni, elképzeljük, megtervezzük a hozzá vezető utat. A szoftverfejlesztés esetében a cél a szoftvertermék előállítása az ehhez elvezető utat fejlesztési módszernek

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 szoftverfejlesztés eszközei

A szoftverfejlesztés eszközei A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató

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

Az Egységesített Eljárás módszertan

Az Egységesített Eljárás módszertan Az Egységesített Eljárás módszertan Az Egységesített Eljárás (RUP, Rational Unified Process) továbbiakban RUP egy iteratív és inkrementációs szoftverfejlesztési eljárás, amelyet a Rational Corporation

Részletesebben

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

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

Részletesebben

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

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

Részletesebben

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

The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos

The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos The Unified Software Development Process Rational Unified Process Krizsán Zoltán Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 12. 04. Történet The Rational Rational

Részletesebben

Termékhasználat. Helyes helytelen termékhasználat. Felhasználók. Ergonómiai hagyományok. Az ergonómia integrálása a termékfejlesztés folyamatába

Termékhasználat. Helyes helytelen termékhasználat. Felhasználók. Ergonómiai hagyományok. Az ergonómia integrálása a termékfejlesztés folyamatába Termékhasználat Helyes helytelen termékhasználat A felhasználók bevonása a Gyermek Interakció Termék termékfejlesztésbe A termékhasználat ergonómiai megközelítése Helytelen, veszélyes, tilos Baleset Ergonómiai

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

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

Ami a vízesésen túl van

Ami 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é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

Minőségmenedzsment és Informatika Test-Driven Development

Minő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észletesebben

Követelmény alapú minőségbiztosítás az államigazgatásban

Kö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észletesebben

A CMMI alapú szoftverfejlesztési folyamat

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

Részletesebben

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

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

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

Ü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

Modell alapú tesztelés mobil környezetben

Modell alapú tesztelés mobil környezetben Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed

Részletesebben

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

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

Részletesebben

Software Engineering

Software Engineering Software Engineering Software Engineering Software Engineering értelmezése Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. Tevékenységek, technológia,

Részletesebben

55 481 04 0000 00 00 Web-programozó Web-programozó

55 481 04 0000 00 00 Web-programozó Web-programozó A /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é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

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

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

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

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

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

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

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

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

Részletesebben

Előzmények 2011.10.23.

Előzmények 2011.10.23. Előzmények Dr. Mileff Péter A 80-as évek közepétől a szoftverek komplexitása egyre növekszik. Megjelentek az OO nyelvek. Az OO fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el.

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

Intelligens partner rendszer virtuális kórházi osztály megvalósításához

Intelligens partner rendszer virtuális kórházi osztály megvalósításához Intelligens partner rendszer virtuális kórházi osztály megvalósításához 1. Célkitűzések A pályázat célja egy virtuális immunológiai osztály kialakítása, amelynek segítségével a különböző betegségekkel

Részletesebben

SLA RÉSZLETESEN. 14. óra

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

Értékesítések (összes, geográfiai -, ügyfelenkénti-, termékenkénti megoszlás)

Értékesítések (összes, geográfiai -, ügyfelenkénti-, termékenkénti megoszlás) Saját vállalkozás Értékesítések (összes, geográfiai -, ügyfelenkénti-, termékenkénti megoszlás) Piaci részesedés Haszonkulcs Marketing folyamatok Marketing szervezet Értékesítési/marketing kontrol adatok

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

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

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31 IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma

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

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

Programozás alapjai Bevezetés

Programozás alapjai Bevezetés Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma

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

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

Az építészeti öregedéskezelés rendszere és alkalmazása

Az építészeti öregedéskezelés rendszere és alkalmazása DR. MÓGA ISTVÁN -DR. GŐSI PÉTER Az építészeti öregedéskezelés rendszere és alkalmazása Magyar Energetika, 2007. 5. sz. A Paksi Atomerőmű üzemidő hosszabbítása előkészítésének fontos feladata annak biztosítása

Részletesebben

Vezetői információs rendszerek

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

Részletesebben

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

Feladataink, kötelességeink, önkéntes és szabadidős tevékenységeink elvégzése, a közösségi életformák gyakorlása döntések sorozatából tevődik össze.

Feladataink, kötelességeink, önkéntes és szabadidős tevékenységeink elvégzése, a közösségi életformák gyakorlása döntések sorozatából tevődik össze. INFORMATIKA Az informatika tantárgy ismeretkörei, fejlesztési területei hozzájárulnak ahhoz, hogy a tanuló az információs társadalom aktív tagjává válhasson. Az informatikai eszközök használata olyan eszköztudást

Részletesebben

A TakarNet24 projekt

A TakarNet24 projekt országos földhivatali hálózat A TakarNet24 projekt Zalaba Piroska főtanácsos Földművelésügyi és Vidékfejlesztési Minisztérium Földügyi és Térinformatikai Főosztály Jogi keretek Eljárások TAKAROS koncepción

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

Csoportos üzenetszórás optimalizálása klaszter rendszerekben

Csoportos üzenetszórás optimalizálása klaszter rendszerekben Csoportos üzenetszórás optimalizálása klaszter rendszerekben Készítette: Juhász Sándor Csikvári András Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási

Részletesebben

Bevezetés Mi a szoftver? Általános termékek: Mi a szoftvertervezés?

Bevezetés Mi a szoftver? Általános termékek: Mi a szoftvertervezés? Bevezetés Mi a szoftver? Számítógép-programok és kapcsolódó dokumentációk, illetve konfigurációs adatok, amelyek elengedhetetlenek ahhoz, hogy ezek a programok helyesen működjenek. Szoftvertermékek fejleszthető

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

A cloud szolgáltatási modell a közigazgatásban

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

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

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

Részletesebben

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

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

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

Részletesebben

(Teszt)automatizálás. Bevezető

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

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

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

Részletesebben

Projekt menedzser teszt

Projekt menedzser teszt Question 1 A módszertanok szerint (3 helyes válasz) Projekt menedzser teszt a. A projektek hossza előre nem meghatározható. b. Meghatározott és egyedi termékek jönnek létre a projektek során. c. A projektek

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

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

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

Részletesebben

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni?

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni? Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni? Kritikus pontok Ethernet interfész soros eszközbe ágyazásakor Az ipari Ethernet technológia az alacsony költségeinek és jelentős hálózati

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

Nyilvántartási Rendszer

Nyilvántartási Rendszer Nyilvántartási Rendszer Veszprém Megyei Levéltár 2011.04.14. Készítette: Juszt Miklós Honnan indultunk? Rövid történeti áttekintés 2003 2007 2008-2011 Access alapú raktári topográfia Adatbázis optimalizálás,

Részletesebben

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

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

Részletesebben

A benchmarking fogalma

A benchmarking fogalma Benchmarking Dr. Koczor Zoltán 1 A fogalma Összevetésként használt szervezet Felhasznált erőforrások ESZKÖZÖK CÉLOK Belső folyamatszabályozás Dr. Koczor Zoltán 2 1 A célja Értékelnünk kell a jelenlegi

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

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

IBM felhő menedzsment

IBM felhő menedzsment IBM Váltsunk stratégiát! Budapest, 2012 november 14. IBM felhő menedzsment SmartCloud Provisioning és Service Delivery Manager Felhő alapú szolgáltatások Felhasználás alapú számlázás és dinamikus kapacitás

Részletesebben

Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba

Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba Témavezető: Horváth Zoltán és Simon Thompson OTDK 2007, Miskolc Egy Erlang refaktor lépés: Függvényparaméterek összevonása tuple-ba OTDK

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

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

Tárgyszavak: vevőkapcsolatok; CRM; szoftverértékelés.

Tárgyszavak: vevőkapcsolatok; CRM; szoftverértékelés. A VÁLLALATVEZETÉS EGYES TERÜLETEI CRM-rendszerek értékelése és felépítése Bármerre tekintünk a verseny egyre élesebb. A vállalatok nagy feladat előtt állnak: régi ügyfeleiket meg kell tartaniuk, és újakat

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

stratégiai kutatási terve

stratégiai kutatási terve A NESSI-Hungary stratégiai kutatási terve Dr. Kondorosi osi Károly BME IIT 2 Vázlat Bevezető Alakulás, motivációk Mit csinál a NESSI az EU-s anya Mit csinál a NESSI-Hungary A Stratégiai kutatási terv (SKT)

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

Programozás. Adatbázis-kezelés (alapok) Fodor Attila

Programozás. Adatbázis-kezelés (alapok) Fodor Attila Programozás Adatbázis-kezelés (alapok) Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék foa@almos.vein.hu 2010. április 22. Bevezetés Adatbáziskezelés

Részletesebben

Software Engineering Szoftver fejlesztés

Software Engineering Szoftver fejlesztés Software Engineering Szoftver fejlesztés Követelmény (kezelés, elemzés, specifikáció) Elemzés Tervezés (Architektúra) Engineering (Fejlesztés) System Engineering Business process engineering üzleti folyamatok

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

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

ITIL alapú folyamat optimalizációs tapasztalatok

ITIL 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é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

Hálózati szolgáltatások biztosításának felügyeleti elemei

Hálózati szolgáltatások biztosításának felügyeleti elemei Budai Károly IT architekt 2012. október 11. Hálózati szolgáltatások biztosításának felügyeleti elemei Szolgáltatás biztosítás általános modellje FELHASZNÁLÓ szolgáltató ügyfélszolgálat szolgáltató üzemeltetői

Részletesebben

Planning and Design of Information Systems. André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987.

Planning and Design of Information Systems. André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987. Planning and Design of Information Systems André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987. 4.3 A tervezés határai Mi a tető, mi a lent, mi a centrum - tisztázni kell előre. A 4 modell milyen részlet

Részletesebben

Szoftverfejlesztés. Created by XMLmind XSL-FO Converter.

Szoftverfejlesztés. Created by XMLmind XSL-FO Converter. Szoftverfejlesztés Ficsor Lajos (1,3,4,7,8,9,10,11,12,13 fejezet) Krizsán Zoltán (14,16 fejezet) Dr. Mileff Péter (2,5,6,15 fejezet) 2011, Miskolci Egyetem, Általános Informatikai Tanszék Szoftverfejlesztés

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

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