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

01. gyakorlat - Projektalapítás

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

Részletesebben

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

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

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

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

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

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

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,

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

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra

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

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

30 MB INFORMATIKAI PROJEKTELLENŐR

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

Részletesebben

Szoftver-technológia I.

Szoftver-technológia I. Szoftver technológia I. Oktatók Sziray József B602 Heckenast Tamás B603 2 Tananyag Elektronikus segédletek www.sze.hu/~sziray/ www.sze.hu/~heckenas/okt/ (www.sze.hu/~orbang/) Nyomtatott könyv Ian Sommerville:

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

TOGAF elemei a gyakorlatban

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

Részletesebben

Félévi követelmények Bemutatkozás és követelmények

Félévi követelmények Bemutatkozás és követelmények Félévi követelmények Dr. Mileff Péter Féléves feladat: egy objektum orientált alkalmazás szoftverspecifikációját és tervét kell elkészíteni. Csoportos munka: 5-7 fős csoportok alakítása. Minden csoporthoz

Részletesebben

MIÉRT KELL TESZTELNI?

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

Részletesebben

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

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

Miskolci Egyetem Általános Informatikai Tanszék

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

Részletesebben

A tesztelés feladata. Verifikáció

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

Részletesebben

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

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

Programfejlesztési Modellek

Programfejlesztési Modellek Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció

Részletesebben

Szoftvertechnológia ellenőrző kérdések 2005

Szoftvertechnológia ellenőrző kérdések 2005 Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?

Részletesebben

Félévi követelmények. Gyakorlatvezetők

Félévi követelmények. Gyakorlatvezetők Dr. Mileff Péter Bemutatkozás és követelmények Dr. Mileff Péter Helyileg: A/1-303. szoba. Fizika Tanszék Konzultációs idő: Szerda 10 12 mileff@iit.uni-miskolc.hu Követelmények: Vezetett gyakorlat nincs.

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

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver

Részletesebben

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

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

Részletesebben

5. Témakör TARTALOMJEGYZÉK

5. Témakör TARTALOMJEGYZÉK 5. Témakör A méretpontosság technológiai biztosítása az építőiparban. Geodéziai terv. Minőségirányítási terv A témakör tanulmányozásához a Paksi Atomerőmű tervezési feladataiból adunk példákat. TARTALOMJEGYZÉK

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

Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség

Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség Tartalom 6. Unified Process & Rational Unified Process lmi a szoftverfejlesztési módszertan? lunified Process lrational Unified Process (RUP) la Rational XDE CASE eszköz lpélda BMF-NIK-SZTI Tick: Szoftver

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

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

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

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

Részletesebben

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

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

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

Nagy bonyolultságú rendszerek fejlesztőeszközei

Nagy bonyolultságú rendszerek fejlesztőeszközei Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő

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

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver

Részletesebben

Bevezetés a programozásba előadás: Alapvető programtervezési elvek

Bevezetés a programozásba előadás: Alapvető programtervezési elvek Bevezetés a programozásba 2 12. előadás: Alapvető programtervezési elvek Miről lesz szó A félév célja a nagyobb programrendszerek felépítésében való részvétel képességét megszerezni Mindenki a saját widgetkészletének

Részletesebben

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

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

Részletesebben

A követelm. vetelmény. analízis fázis. Az analízis fázis célja. fázis feladata

A követelm. vetelmény. analízis fázis. Az analízis fázis célja. fázis feladata A követelm vetelmény analízis fázis Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006.02.15. ANAL / 1 Az analízis fázis célja A projekttel szemben támasztott követelmények meghatározása

Részletesebben

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

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

Részletesebben

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

Méréselmélet MI BSc 1

Méréselmélet MI BSc 1 Mérés és s modellezés 2008.02.15. 1 Méréselmélet - bevezetés a mérnöki problémamegoldás menete 1. A probléma kitűzése 2. A hipotézis felállítása 3. Kísérlettervezés 4. Megfigyelések elvégzése 5. Adatok

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

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

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

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

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

Ü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

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

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

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):

Részletesebben

Objektumorientált paradigma és programfejlesztés Bevezető

Objektumorientált paradigma és programfejlesztés Bevezető Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján

Részletesebben

Mérés és modellezés Méréstechnika VM, GM, MM 1

Mérés és modellezés Méréstechnika VM, GM, MM 1 Mérés és modellezés 2008.02.04. 1 Mérés és modellezés A mérnöki tevékenység alapeleme a mérés. A mérés célja valamely jelenség megismerése, vizsgálata. A mérés tervszerűen végzett tevékenység: azaz rögzíteni

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

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 Segédeszközök szükségessége Szoftver

Részletesebben

Software engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz:

Software engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz: Software engineering (Software techológia) Bevezetés, alapfogalmak Utolsó módosítás: 2006. 02. 16. SWENGBEV / 1 Történelem 1. 60-as évek Megoldandó problémák: egyedi problémákra kis programok Fejlesztő:

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

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

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS 1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS A Norvég Alapból finanszírozott HU12-0001-PP1-2016 azonosítószámú, A roma közösségekben dolgozó védőnők munkafeltételeinek javítása című projekt (a továbbiakban: Projekt)

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

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

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

Objektumorientált paradigma és a programfejlesztés

Objektumorientált paradigma és a programfejlesztés Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált

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

Verziókövető rendszerek használata a szoftverfejlesztésben

Verziókövető rendszerek használata a szoftverfejlesztésben Verziókövető rendszerek használata a szoftverfejlesztésben Dezső Balázs Szakszeminárium vezető: Molnár Bálint Budapesti Corvinus Egyetem Budapest, 2009. június 24. 1 Bevezetés 2 Verziókövetőrendszerek

Részletesebben

Dr. Mileff Péter

Dr. Mileff Péter Dr. Mileff Péter 1 2 1 Szekvencia diagram Szekvencia diagram Feladata: objektumok egymás közti üzenetváltásainak ábrázolása egy időtengely mentén elhelyezve. Az objektumok életvonala egy felülről lefelé

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

Software project management Áttekintés

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

Részletesebben

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

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

10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique)

10-es Kurzus. OMT modellek és diagramok OMT metodológia. OMT (Object Modelling Technique) 10-es Kurzus OMT modellek és diagramok OMT metodológia OMT (Object Modelling Technique) 1 3 Modell és 6 Diagram Statikus modell : OMT Modellek és diagramok: Statikus leírása az összes objektumnak (Név,

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

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

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

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

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

Parametrikus tervezés

Parametrikus tervezés 2012.03.31. Statikus modell Dinamikus modell Parametrikus tervezés Módosítások a tervezés folyamán Konstrukciós variánsok (termékcsaládok) Parametrikus Modell Parametrikus tervezés Paraméterek (változók

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

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

SDM. Adatbáziskezelés és könyvtári rendszerszervezés. Konkrét problémamegoldásra orientált elvek, szabályok együttese

SDM. Adatbáziskezelés és könyvtári rendszerszervezés. Konkrét problémamegoldásra orientált elvek, szabályok együttese SDM Adatbáziskezelés és könyvtári rendszerszervezés Módszertanok Módszer fogalma: Konkrét problémamegoldásra orientált elvek, szabályok együttese Módszertan fogalma: Az információs rendszer létrehozásához

Részletesebben

Dr. Topár József (BME)

Dr. Topár József (BME) (BME) Budapesti Műszaki és Gazdaságtudományi Egyetem XXII. Magyar Minőség Hét 2013. november 6. 1 Projekt minőségbiztosítás?? minőségmenedzsment??? Projekt K+F+I Mit várunk e rendszerektől? Összehangolás-

Részletesebben

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és Függvénysablonok Gyakorlatorientált szoftverfejlesztés C++ nyelven Visual Studio Community fejlesztőkörnyezetben

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

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

(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

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

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

Mérés és modellezés 1

Mérés és modellezés 1 Mérés és modellezés 1 Mérés és modellezés A mérnöki tevékenység alapeleme a mérés. A mérés célja valamely jelenség megismerése, vizsgálata. A mérés tervszerűen végzett tevékenység: azaz rögzíteni kell

Részletesebben